bmad-method 6.0.0-alpha.17 → 6.0.0-alpha.18

package/src/modules/bmgd/docs/glossary.md

@@ -0,0 +1,294 @@
+# BMGD Glossary
+
+Key game development terminology used in BMGD workflows.
+
+---
+
+## A
+
+### Acceptance Criteria
+
+Specific conditions that must be met for a story to be considered complete. Defines "done" for implementation.
+
+### Act Structure
+
+Story organization into major sections (typically 3 acts: Setup, Confrontation, Resolution).
+
+---
+
+## B
+
+### Backlog
+
+List of pending work items (epics, stories) waiting to be scheduled and implemented.
+
+### Boss Design
+
+Design of significant enemy encounters, typically featuring unique mechanics and increased challenge.
+
+---
+
+## C
+
+### Character Arc
+
+The transformation a character undergoes through the story, from initial state to final state.
+
+### Core Fantasy
+
+The emotional experience players seek from your game. What they want to FEEL.
+
+### Core Loop
+
+The fundamental cycle of actions players repeat throughout gameplay. The heart of your game.
+
+---
+
+## D
+
+### Definition of Done (DoD)
+
+Checklist of requirements that must be satisfied before work is considered complete.
+
+### Design Pillar
+
+Core principle that guides all design decisions. Typically 3-5 pillars define a game's identity.
+
+---
+
+## E
+
+### Environmental Storytelling
+
+Narrative communicated through the game world itself—visual details, audio, found documents—rather than explicit dialogue.
+
+### Epic
+
+Large body of work that can be broken down into smaller stories. Represents a major feature or system.
+
+---
+
+## F
+
+### Frame Data
+
+In fighting games, the precise timing information for moves (startup, active, recovery frames).
+
+### Frontmatter
+
+YAML metadata at the beginning of markdown files, used for workflow state tracking.
+
+---
+
+## G
+
+### Game Brief
+
+Document capturing the game's core vision, pillars, target audience, and scope. Foundation for the GDD.
+
+### Game Design Document (GDD)
+
+Comprehensive document detailing all aspects of game design: mechanics, systems, content, and more.
+
+### Game Type
+
+Genre classification that determines which specialized GDD sections are included.
+
+---
+
+## H
+
+### Hot Path
+
+Code that executes frequently (every frame). Must be optimized for performance.
+
+---
+
+## I
+
+### Idle Progression
+
+Game mechanics where progress continues even when the player isn't actively playing.
+
+---
+
+## K
+
+### Kishotenketsu
+
+Four-act story structure from East Asian narrative tradition (Introduction, Development, Twist, Conclusion).
+
+---
+
+## L
+
+### Localization
+
+Adapting game content for different languages and cultures.
+
+---
+
+## M
+
+### MDA Framework
+
+Mechanics → Dynamics → Aesthetics. Framework for analyzing and designing games.
+
+### Meta-Progression
+
+Persistent progression that carries between individual runs or sessions.
+
+### Metroidvania
+
+Genre featuring interconnected world exploration with ability-gated progression.
+
+---
+
+## N
+
+### Narrative Complexity
+
+How central story is to the game experience (Critical, Heavy, Moderate, Light).
+
+### Netcode
+
+Networking code handling multiplayer communication and synchronization.
+
+---
+
+## P
+
+### Permadeath
+
+Game mechanic where character death is permanent, typically requiring a new run.
+
+### Player Agency
+
+The degree to which players can make meaningful choices that affect outcomes.
+
+### Procedural Generation
+
+Algorithmic creation of game content (levels, items, characters) rather than hand-crafted.
+
+---
+
+## R
+
+### Retrospective
+
+Team meeting after completing work to reflect on what went well and what to improve.
+
+### Roguelike
+
+Genre featuring procedural generation, permadeath, and run-based progression.
+
+### Run
+
+A single playthrough in a roguelike or run-based game, from start to death/completion.
+
+---
+
+## S
+
+### Sprint
+
+Time-boxed period of development work, typically 1-2 weeks.
+
+### Sprint Status
+
+Tracking document showing current sprint progress, story states, and blockers.
+
+### Story
+
+Smallest unit of implementable work with clear acceptance criteria. Part of an epic.
+
+### Story Context
+
+Assembled documentation and code context needed to implement a specific story.
+
+### Story Gates
+
+Points where story progression is blocked until certain gameplay conditions are met.
+
+---
+
+## T
+
+### Tech Spec
+
+Technical specification document detailing how a feature will be implemented.
+
+### TDD (Test-Driven Development)
+
+Development approach: write tests first, then implement code to pass them.
+
+---
+
+## U
+
+### UI/UX
+
+User Interface / User Experience. How players interact with and experience the game.
+
+---
+
+## V
+
+### Visual Novel
+
+Genre focused on narrative with static images, dialogue, and player choices.
+
+### Voice Acting
+
+Recorded spoken dialogue for game characters.
+
+---
+
+## W
+
+### Workflow
+
+Structured process for completing a specific type of work (e.g., GDD creation, story implementation).
+
+### Workflow Status
+
+Current state of project workflows, tracking which phases and documents are complete.
+
+### World Building
+
+Creation of the game's setting, including history, culture, geography, and lore.
+
+---
+
+## BMGD-Specific Terms
+
+### A/P/C Menu
+
+Options presented after content generation:
+
+- **A** - Advanced Elicitation (explore deeper)
+- **P** - Party Mode (multi-agent discussion)
+- **C** - Continue (save and proceed)
+
+### Narrative Complexity Levels
+
+- **Critical** - Story IS the game (visual novels)
+- **Heavy** - Deep narrative with gameplay (RPGs)
+- **Moderate** - Meaningful story supporting gameplay
+- **Light** - Minimal story, gameplay-focused
+
+### Step-File Architecture
+
+BMGD workflow pattern using separate markdown files for each workflow step.
+
+### Workflow-Install Pattern
+
+Phase 4 workflows inherit from BMM base and add BMGD-specific overrides.
+
+---
+
+## Next Steps
+
+- **[Quick Start Guide](./quick-start.md)** - Get started with BMGD
+- **[Game Types Guide](./game-types-guide.md)** - Game genre reference
+- **[Troubleshooting](./troubleshooting.md)** - Common issues and solutions

package/src/modules/bmgd/docs/quick-flow-guide.md

@@ -0,0 +1,288 @@
+# BMGD Quick-Flow Guide
+
+Fast-track workflows for rapid game prototyping and flexible development.
+
+---
+
+## Game Solo Dev Agent
+
+For dedicated quick-flow development, use the **Game Solo Dev** agent (Indie). This agent is optimized for solo developers and small teams who want to skip the full planning phases and ship fast.
+
+**Switch to Game Solo Dev:** Type `@game-solo-dev` or select the agent from your IDE.
+
+The Game Solo Dev agent includes:
+
+- `quick-prototype` - Rapid mechanic testing
+- `quick-dev` - Flexible feature implementation
+- `create-tech-spec` - Create implementation-ready specs
+- `code-review` - Quality checks
+- `test-framework` - Automated testing setup
+
+---
+
+## Overview
+
+Quick-flow workflows skip the full BMGD planning phases when you need to move fast. Use them for:
+
+- Testing a game mechanic idea
+- Implementing a small feature
+- Rapid prototyping before committing to design
+- Bug fixes and tweaks
+
+```
+Full BMGD Flow:
+Brief → GDD → Architecture → Sprint Planning → Stories → Implementation
+
+Quick-Flow:
+Idea → Quick-Prototype → Quick-Dev → Done
+```
+
+---
+
+## Quick-Prototype
+
+**Command:** `quick-prototype`
+**Agent:** Game Designer, Game Developer
+**Purpose:** Rapidly test gameplay ideas with minimal setup
+
+### When to Use
+
+- You have a mechanic idea and want to test the "feel"
+- You're not sure if something will be fun
+- You want to experiment before committing to design
+- You need a proof of concept
+
+### Workflow Steps
+
+1. **Define Scope** - What are you prototyping? (mechanic, feature, system)
+2. **Set Success Criteria** - How will you know if it works?
+3. **Rapid Implementation** - Build the minimum to test the idea
+4. **Playtest and Evaluate** - Does it feel right?
+
+### Prototype Principles
+
+- **Minimum Viable Prototype** - Only what's needed to test the idea
+- **Hardcode First** - Magic numbers are fine, extract later
+- **Skip Edge Cases** - Happy path only for now
+- **Placeholder Everything** - Cubes, debug text, temp sounds
+- **Comment Intent** - Mark what's temporary vs keeper code
+
+### Example Session
+
+```
+You: quick-prototype
+
+Agent: What are you prototyping?
+
+You: I want to test a grappling hook mechanic. Player should be
+     able to aim at surfaces and pull themselves toward the hook point.
+
+Agent: What makes this prototype successful?
+
+You: 1. Aiming feels responsive and intuitive
+     2. The pull movement feels satisfying, not floaty
+     3. Player can chain hooks without awkward pauses
+
+Agent: [Implements minimal grappling hook]
+
+Agent: Prototype complete! Playtest results:
+     - Aiming: Works, consider adding aim assist
+     - Movement: Pull is smooth, might need speed curve
+     - Chaining: Currently has 0.2s delay, feels sluggish
+
+     Next: [d] Develop further | [i] Iterate | [a] Archive
+```
+
+### After Prototyping
+
+- **Develop** (`d`) - Use `quick-dev` to build production code
+- **Iterate** (`i`) - Adjust and re-test the prototype
+- **Archive** (`a`) - Keep as reference, move on to other ideas
+
+---
+
+## Quick-Dev
+
+**Command:** `quick-dev`
+**Agent:** Game Developer
+**Purpose:** Flexible development with game-specific considerations
+
+### When to Use
+
+- Implementing a feature from a tech-spec
+- Building on a successful prototype
+- Making changes that don't need full story workflow
+- Quick fixes and improvements
+
+### Workflow Modes
+
+**Mode A: Tech-Spec Driven**
+
+```
+You: quick-dev tech-spec-combat.md
+Agent: [Loads spec, extracts tasks, implements]
+```
+
+**Mode B: Direct Instructions**
+
+```
+You: quick-dev implement double-jump for the player
+Agent: [Evaluates complexity, offers planning options]
+```
+
+**Mode C: From Prototype**
+
+```
+You: quick-dev from the grappling hook prototype
+Agent: [Loads prototype, productionizes code]
+```
+
+### Game-Specific Checks
+
+Quick-dev includes automatic consideration of:
+
+- **Performance** - No allocations in hot paths, object pooling
+- **Feel** - Input responsiveness, visual/audio feedback
+- **Integration** - Save/load, multiplayer sync, platform testing
+
+### Example Session
+
+```
+You: quick-dev implement enemy patrol behavior
+
+Agent: This looks like a focused feature. Options:
+       [t] Plan first - Create tech-spec (recommended)
+       [r] Prototype first - Test the idea
+       [e] Execute directly
+
+You: e
+
+Agent: Any additional guidance? (patterns, files, constraints)
+
+You: Use the existing AIController base class. Enemies should
+     patrol between waypoints and return if player leaves range.
+
+Agent: [Implements patrol behavior]
+
+Agent: Implementation Complete!
+       Files Modified: EnemyAI.cs, PatrolBehavior.cs
+       Tests: Unit tests added for patrol state machine
+       Performance: No per-frame allocations
+
+       Recommended: Playtest the changes
+```
+
+### Complexity Routing
+
+Quick-dev automatically detects complex requests and offers alternatives:
+
+| Signals                                | Recommendation         |
+| -------------------------------------- | ---------------------- |
+| Single mechanic, bug fix, tweak        | Execute directly       |
+| Multiple systems, performance-critical | Plan first (tech-spec) |
+| Platform/system level work             | Use full BMGD workflow |
+
+---
+
+## Choosing Between Quick-Flows
+
+| Scenario                | Use                             |
+| ----------------------- | ------------------------------- |
+| "Will this be fun?"     | `quick-prototype`               |
+| "How should this feel?" | `quick-prototype`               |
+| "Build this feature"    | `quick-dev`                     |
+| "Fix this bug"          | `quick-dev`                     |
+| "Test then build"       | `quick-prototype` → `quick-dev` |
+
+---
+
+## Quick-Flow vs Full BMGD
+
+### Use Quick-Flow When
+
+- The scope is small and well-understood
+- You're experimenting or prototyping
+- You have a clear tech-spec already
+- The work doesn't affect core game systems significantly
+
+### Use Full BMGD When
+
+- Building a major feature or system
+- The scope is unclear or large
+- Multiple team members need alignment
+- The work affects game pillars or core loop
+- You need documentation for future reference
+
+---
+
+## Checklists
+
+### Quick-Prototype Checklist
+
+**Before:**
+
+- [ ] Prototype scope defined
+- [ ] Success criteria established (2-3 items)
+
+**During:**
+
+- [ ] Minimum viable code written
+- [ ] Placeholder assets used
+- [ ] Core functionality testable
+
+**After:**
+
+- [ ] Each criterion evaluated
+- [ ] Decision made (develop/iterate/archive)
+
+### Quick-Dev Checklist
+
+**Before:**
+
+- [ ] Context loaded (spec, prototype, or guidance)
+- [ ] Files to modify identified
+- [ ] Patterns understood
+
+**During:**
+
+- [ ] All tasks completed
+- [ ] No allocations in hot paths
+- [ ] Frame rate maintained
+
+**After:**
+
+- [ ] Game runs without errors
+- [ ] Feature works as specified
+- [ ] Manual playtest completed
+
+---
+
+## Tips for Success
+
+### 1. Timebox Prototypes
+
+Set a limit (e.g., 2 hours) for prototyping. If it's not working by then, step back and reconsider.
+
+### 2. Embrace Programmer Art
+
+Prototypes don't need to look good. Focus on feel, not visuals.
+
+### 3. Test on Target Hardware
+
+What feels right on your dev machine might not feel right on target platform.
+
+### 4. Document Learnings
+
+Even failed prototypes teach something. Note what you learned.
+
+### 5. Know When to Graduate
+
+If quick-dev keeps expanding scope, stop and create proper stories.
+
+---
+
+## Next Steps
+
+- **[Workflows Guide](./workflows-guide.md)** - Full workflow reference
+- **[Agents Guide](./agents-guide.md)** - Agent capabilities
+- **[Quick Start Guide](./quick-start.md)** - Getting started with BMGD