Files

T

2026-05-21 23:08:34 +02:00

15 KiB

Raw Permalink Blame History

stepsCompleted, session_active, workflow_completed, ideas_generated, inputDocuments, session_topic, session_goals, selected_approach, techniques_used, ideas_generated, context_file

stepsCompleted

session_active

workflow_completed

ideas_generated

inputDocuments

session_topic

session_goals

selected_approach

techniques_used

ideas_generated

context_file

false

true

FoundryVTT v14 webcam view manager module

Granular webcam visibility control per player, individual enable/disable, efficient and practical UI, who-sees-who selection between connected players

ai-recommended

Question Storming

SCAMPER Method

Role Playing

stepsCompleted: [1, 2, 3, 4] session_active: false workflow_completed: true ideas_generated: [21] inputDocuments: [] session_topic: 'FoundryVTT v14 webcam view manager module' session_goals: 'Granular webcam visibility control per player, individual enable/disable, efficient and practical UI, who-sees-who selection between connected players' selected_approach: 'ai-recommended' techniques_used: ['Question Storming', 'SCAMPER Method', 'Role Playing'] ideas_generated: [] context_file: ''

Brainstorming Session Results

Facilitator: Morr Date: 2026-05-19

Session Overview

Topic: FoundryVTT v14 webcam view manager module Goals: Granular webcam visibility control per player, individual enable/disable, efficient and practical UI, who-sees-who selection between connected players

Session Setup

Fresh session initialized. No context file provided.

Technique Selection

Approach: AI-Recommended Techniques Analysis Context: FoundryVTT v14 webcam view manager module with focus on granular player-to-player visibility control and practical UI design

Recommended Techniques:

Question Storming: Surface hidden requirements, edge cases, and unknowns before generating solutions — defines the correct problem space
SCAMPER Method: Systematic 7-lens feature/UI idea generation (Substitute, Combine, Adapt, Modify, Put to other use, Eliminate, Reverse)
Role Playing: Embody GM, players, streamers, mobile users to ground ideas in real human perspective

AI Rationale: This sequence moves from problem definition → systematic generation → human validation. Ideal for a technical product with multiple user roles and complex interaction states.

Technique Execution Results

Phase 1: Question Storming

Interactive Focus: Surfacing hidden requirements, edge cases, and architectural constraints before generating solutions.

Key Questions Generated:

Who has permission to change visibility? Only GM, or can players hide themselves?
What happens when a player joins mid-session — visible by default or hidden?
Should visibility be symmetric or asymmetric (GM sees all, players see what's allowed)?
What's the "panic button" — how does GM instantly hide all cams?
How does this interact with FoundryVTT's existing AV system (game.webrtc)?
If a webcam disconnects, does its slot disappear or leave a placeholder?
What if it disconnects mid-combat — does the layout reflow and disrupt players?
Is a disconnected cam different from a hidden cam?
What about reconnection — does it snap back to previous state or reset?
What if the GM's own webcam disconnects?
Should the UI communicate WHY a feed is absent? (Camera off vs Player disconnected vs GM hid this feed)
Where does this UI live? Sidebar? Floating overlay? Popout?
On a screen with 8 players, how do you display a visibility matrix without a spreadsheet nightmare?
Should there be presets? ("Cinematic mode", "Social mode")
What visual feedback tells a player their own feed is hidden from someone?
Should players know they're being hidden, or is it silent?
Does FoundryVTT's WebRTC even support per-viewer stream filtering, or must visibility be faked client-side?
How do settings persist across sessions?
What happens in combat vs exploration — should the module have scene-aware presets?

Breakthrough Insight — The Visibility Matrix: The module's data model isn't Map<playerId, boolean> — it's Map<playerId, Map<viewerId, VisibilityState>>. Every player has a visibility setting per observer. This is the architectural heart of "who sees what."

Participant State Machine (8 states identified):

active — Camera on, feed visible to permitted viewers
hidden — Camera on, but GM/module has hidden it
self-muted — Player turned off their own cam voluntarily
offline — Player's connection dropped entirely
cam-lost — Player connected but camera device failed
reconnecting — Transitional, feed expected to return
never-connected — Player joined with no camera
ghost — Secretly observing (GM special state)

3 Core Tensions Identified:

Asymmetric visibility — the matrix is powerful but complex to display
Silent vs announced changes — trust and social design
Technical layer — is filtering real (WebRTC) or cosmetic (CSS hide)?

Phase 2: SCAMPER Method

Interactive Focus: Systematic 7-lens feature and UI idea generation.

S — Substitute

Explored substituting the toggle metaphor with spatial/contextual alternatives. Key insight: the seating chart metaphor maps naturally to how TTRPG players think about the table.

C — Combine

Explored combining with combat tracker, scene transitions, character status. Key insight: Combat Cinematics Mode — the module acts as a live director during combat, auto-spotlighting the active combatant.

Decision captured: Dedicated popout window for the seating chart UI — low-frequency tool, opened at session start, closed during play.

A — Adapt

Adapted patterns from video conferencing (spotlight/pin), broadcast control rooms (switcher), and theater (lighting states). Key insight: Stage Lighting States — "Wash/Focus/Blackout" maps perfectly to TTRPG dramatic vocabulary.

M — Modify

Scaled up (token-anchored floating cams) and distorted (HP-reactive cam styling). Key insight: Token-Anchored Floating Cams — player faces float above tokens on the canvas.

P — Put to Other Uses

Discovered unexpected applications: NPC presence tiles, spectator curtain for streamers, murder mystery reveals. Key insight: Spectator Curtain opens the module to the actual-play streaming market.

E — Eliminate

Stripped features to find the irreducible core. Key insight: Progressive Enhancement Architecture — Level 1 (right-click) → Level 2 (Director's Board) → Level 3 (popout). MVP might be just Level 1.

R — Reverse

Flipped the control model. Key insight: Pull Visibility Model — nothing visible until someone actively requests to see it. Also: Reaction Clip System for players without webcams.

Phase 3: Role Playing

Interactive Focus: Embodying 4 stakeholder personas to stress-test all concepts.

Persona 1 — Marcus (Veteran GM):

Wants zero-clicks during play — automation is king
Scene-aware presets match his prep workflow perfectly
Every automation needs a one-click GM override
Reaction cam needs per-scene disable option

Persona 2 — Sofia (Privacy-Conscious Player):

Pull visibility model respects player agency
Reaction clip system includes her when bandwidth is poor
HP-reactive cam sizing must be opt-in per player
Reaction cam auto-popup is a privacy risk without opt-out

Persona 3 — Jake (Actual-Play Streamer):

Spectator curtain is critical — audience vs player views must be independent
Keyboard shortcuts essential during live broadcast
Browser Source API (OBS-ready tile URLs) transforms the module into a production stack
Seating chart popout needs instant keyboard shortcut access

Persona 4 — Alex (New Player):

Seating chart metaphor instantly understood; visibility matrix jargon was not
Plain language everywhere — "Show/Hide/Spotlight" not "Wash/Focus/Blackout"
Automation without feedback is terrifying — needs toast notifications
Portrait fallback for bad/missing cameras reduces anxiety

Key Tension Resolved: Marcus wants drama (reaction cam), Sofia wants privacy (no surprise reveals). → Resolution: Reaction cam is opt-in at character/player setup. Consent-aware design.

Complete Idea Inventory (21 Concepts)

#	Concept	Source	Theme
1	The Living Table	SCAMPER-S	Core Architecture
2	Table Manager Popout	SCAMPER-S	Core Architecture
3	Scene-Aware Visibility Presets	SCAMPER-C	Automation
4	Combat Cinematics Mode	SCAMPER-C	Automation + Cinematic
5	The Reaction Cam	SCAMPER-C	Cinematic
6	The Director's Board	SCAMPER-A	Cinematic
7	Stage Lighting States	SCAMPER-A	Cinematic
8	Token-Anchored Floating Cams	SCAMPER-M	Cinematic
9	HP-Reactive Cam Styling	SCAMPER-M	Cinematic
10	NPC Presence Tiles	SCAMPER-P	Extended Presence
11	Spectator Curtain	SCAMPER-P	Streaming
12	Zero-UI Automation Mode	SCAMPER-E	Automation
13	Progressive Enhancement Architecture	SCAMPER-E	Core Architecture
14	Pull Visibility Model	SCAMPER-R	Core Architecture
15	Reaction Clip System	SCAMPER-R	Privacy + Extended Presence
16	Player Privacy Preferences Panel	Role Playing	Privacy
17	Opt-In Reaction Cam	Role Playing	Privacy + Cinematic
18	Dual Layout System	Role Playing	Streaming
19	Browser Source API	Role Playing	Streaming
20	Contextual Action Notifications	Role Playing	Automation
21	Vocabulary Tiers	Role Playing	UX / Onboarding

Idea Organization and Prioritization

Thematic Clusters

🏗️ Theme 1: Core Architecture What the module IS — foundational data model and UI structure

#1 The Living Table, #2 Table Manager Popout, #13 Progressive Enhancement, #14 Pull Visibility Model

🤖 Theme 2: Automation & Intelligence The module as silent director — configure once, run forever

#3 Scene-Aware Presets, #4 Combat Cinematics Mode, #12 Zero-UI Automation Mode, #20 Contextual Notifications

🎬 Theme 3: Cinematic & Dramatic Effects Transforms sessions into cinematic experiences

#5 Reaction Cam, #6 Director's Board, #7 Stage Lighting States, #8 Token-Anchored Cams, #9 HP-Reactive Styling, #17 Opt-In Reaction Cam

🔒 Theme 4: Privacy & Player Agency No surprises — players always in control

#15 Reaction Clip System, #16 Player Privacy Panel, #17 Opt-In Reaction Cam, #21 Vocabulary Tiers

📺 Theme 5: Streaming & Extended Presence Actual-play production without a technical director

#10 NPC Presence Tiles, #11 Spectator Curtain, #18 Dual Layout System, #19 Browser Source API

⭐ North Star Feature (Confirmed by User)

As a GM, I can click a player's webcam tile and toggle it visible/hidden for all players — instantly, reliably, one click.

Everything else is either a smarter trigger for this toggle, a richer display of its state, an extension of who controls it, or an extra surface for its result.

Priority Stack

🥇 Day 1 — The Core Toggle

GM clicks a player's cam tile → cam hidden/shown for all players
State persists through player reconnection
Plain visual indicator: "this cam is hidden by GM"
Right-click context menu on existing AV tiles (Level 1 — zero new UI)
FoundryVTT v14 API scope: hook into game.webrtc / existing AV tiles, store state in game.settings or socket broadcast

🥈 Week 1–2 — Make it practical

#2 Table Manager Popout (bulk management for 6+ players)
#3 Scene-Aware Presets (configure at prep, not during play)
#20 Contextual Notifications ("GM hid Sofia's cam")
#16 Player Privacy Panel (opt-out of effects)
#21 Vocabulary Tiers (plain language default, power terms in advanced mode)

🥉 Later — Make it powerful

#4 Combat Cinematics Mode + #17 Opt-In Reaction Cam
#6 Director's Board + #7 Stage Lighting States
#12 Zero-UI Automation Mode
#1 Living Table / full seating chart UI
#11 Spectator Curtain + #18 Dual Layout + #19 Browser Source API
#8 Token-Anchored Cams, #9 HP-Reactive Styling, #10 NPC Presence Tiles, #15 Reaction Clip System

Action Planning

Day 1 Implementation Roadmap

1. Research — FoundryVTT v14 AV API

Read game.webrtc API and AVMaster hooks
Identify how existing cam tiles are rendered in the DOM
Determine if visibility is real (WebRTC track disable) or cosmetic (CSS)
Check game.settings for persistent storage approach
Review socketlib or native socket options for broadcasting state to all clients

2. Build — Core Toggle (MVP)

Register module in module.json for FoundryVTT v14
Hook into AV cam tile render to inject right-click context menu
Implement setPlayerCamVisible(playerId, visible) function
Broadcast state change via socket to all connected clients
Each client applies visibility to their local cam tile render
Persist state in game.settings (world-level)
Add visual indicator on hidden tiles (icon overlay or opacity change)

3. Test — Edge Cases from Question Storming

Player disconnects while hidden → reconnects → state restored correctly
GM cam hidden → what happens to GM's own view?
Player with no camera → graceful fallback (portrait shown)
Mid-combat hide → layout stable, no reflow disruption

4. Ship — Level 1

Zero new UI surface — pure right-click enhancement
Works on all existing FoundryVTT AV layouts
Document the 8-state participant model for future development

Session Summary and Insights

Key Achievements:

21 breakthrough concepts generated across 3 creative techniques
5 thematic clusters identified covering the full product surface
North star feature confirmed and scoped for Day 1 implementation
4 user personas stress-tested all concepts — critical tensions resolved
Clear 3-tier priority stack established (Day 1 → Week 1-2 → Later)
FoundryVTT v14 technical scope defined for MVP

Breakthrough Moments:

The seating chart metaphor reframed the UI from "settings panel" to "spatial social experience"
The visibility matrix (Map<playerId, Map<viewerId, State>>) clarified the true data model complexity
The 4-persona analysis revealed 3 distinct user tiers (GM power, player privacy, streamer production)
Progressive Enhancement Architecture ensures the module is useful at every complexity level
Reaction cam opt-in resolved the Marcus/Sofia privacy tension elegantly

Creative Facilitation Narrative: The session began with a simple goal — webcam visibility control — and evolved into a session cinematography platform. Question Storming surfaced the architectural complexity (8 participant states, visibility matrix). SCAMPER transformed the concept from utility to product, discovering the seating chart metaphor, combat cinematics, and streaming tools. Role Playing grounded the ideas in human reality, revealing the privacy-first design principle and the 4-level user tier model. The final anchor back to "GM toggle = Day 1" ensures the ambitious vision stays rooted in a shippable, focused MVP.

Your Next Steps:

Read FoundryVTT v14 AV API documentation (game.webrtc, AVMaster, cam tile hooks)
Build the right-click toggle on existing cam tiles (Day 1 MVP)
Test the 8 participant state transitions
Plan the Table Manager Popout and Scene Presets for Week 1–2
Keep the 21-concept inventory as the product backlog for future sprints

15 KiB Raw Permalink Blame History Unescape Escape