301 lines
15 KiB
Markdown
301 lines
15 KiB
Markdown
---
|
||
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:**
|
||
1. Asymmetric visibility — the matrix is powerful but complex to display
|
||
2. Silent vs announced changes — trust and social design
|
||
3. 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:**
|
||
1. Read FoundryVTT v14 AV API documentation (`game.webrtc`, `AVMaster`, cam tile hooks)
|
||
2. Build the right-click toggle on existing cam tiles (Day 1 MVP)
|
||
3. Test the 8 participant state transitions
|
||
4. Plan the Table Manager Popout and Scene Presets for Week 1–2
|
||
5. Keep the 21-concept inventory as the product backlog for future sprints
|