mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00:00
feat: Extract BMGD module and implement workflow vendoring
This commit extracts game development functionality from BMM into a standalone BMGD (BMad Game Development) module and implements workflow vendoring to enable module independence. BMGD Module Creation: - Moved agents: game-designer, game-dev, game-architect from BMM to BMGD - Moved team config: team-gamedev - Created new Game Dev Scrum Master agent using workflow vendoring pattern - Reorganized workflows into industry-standard game dev phases: * Phase 1 (Preproduction): brainstorm-game, game-brief * Phase 2 (Design): gdd, narrative * Phase 3 (Technical): game-architecture * Phase 4 (Production): vendored from BMM workflows - Updated all module metadata and config_source references Workflow Vendoring Feature: - Enables modules to copy workflows from other modules during installation - Build-time process that updates config_source in vendored workflows - New agent YAML attribute: workflow-install (build-time metadata) - Final compiled agents use workflow-install value for workflow attribute - Implementation in module manager: vendorCrossModuleWorkflows() - Allows standalone module installation without forced dependencies Technical Changes: - tools/cli/lib/yaml-xml-builder.js: Use workflow-install for workflow attribute - tools/cli/installers/lib/modules/manager.js: Add vendoring functions - tools/schema/agent.js: Add workflow-install to menu item schema - Updated 3 documentation files with workflow vendoring details BMM Workflow Updates: - workflow-status/init: Added game detection checkpoint - workflow-status/paths/game-design.yaml: Redirect to BMGD module - prd/instructions.md: Route game projects to BMGD - research/instructions-market.md: Reference BMGD for game development Documentation: - Created comprehensive BMGD module README - Added workflow vendoring documentation - Updated BMB agent creation and module creation guides
This commit is contained in:
Brian Madison
208
src/modules/bmgd/README.md
Normal file
208
src/modules/bmgd/README.md
Normal file
@@ -0,0 +1,208 @@
|
||||
# BMad Game Development (BMGD)
|
||||
|
||||
A comprehensive game development toolkit providing specialized agents and workflows for creating games from initial concept through production.
|
||||
|
||||
## Overview
|
||||
|
||||
The BMGD module brings together game-specific development workflows organized around industry-standard development phases:
|
||||
|
||||
- **Preproduction** - Concept development, brainstorming, game brief creation
|
||||
- **Design** - Game Design Document (GDD) and narrative design
|
||||
- **Technical** - Game architecture and technical specifications
|
||||
- **Production** - Sprint-based implementation using BMM workflows
|
||||
|
||||
## Installation
|
||||
|
||||
```bash
|
||||
bmad install bmgd
|
||||
```
|
||||
|
||||
During installation, you'll be asked to configure:
|
||||
|
||||
- Game project name
|
||||
- Document storage locations
|
||||
- Development experience level
|
||||
- Primary target platform
|
||||
|
||||
## Components
|
||||
|
||||
### Agents (4)
|
||||
|
||||
**Game Designer** 🎨
|
||||
Creative vision and game design documentation specialist. Creates compelling GDDs and defines game mechanics.
|
||||
|
||||
**Game Developer** 🕹️
|
||||
Senior implementation specialist with expertise across Unity, Unreal, and custom engines. Handles gameplay programming, physics, AI, and optimization.
|
||||
|
||||
**Game Architect** 🏗️
|
||||
Technical systems and infrastructure expert. Designs scalable game architecture and engine-level solutions.
|
||||
|
||||
**Game Dev Scrum Master** 🎯
|
||||
Sprint orchestrator specialized in game development workflows. Coordinates multi-disciplinary teams and translates GDDs into actionable development stories.
|
||||
|
||||
### Team Bundle
|
||||
|
||||
**Team Game Development** 🎮
|
||||
Pre-configured team including Game Designer, Game Developer, and Game Architect for comprehensive game projects.
|
||||
|
||||
### Workflows
|
||||
|
||||
#### Phase 1: Preproduction
|
||||
|
||||
- **brainstorm-game** - Interactive game concept brainstorming
|
||||
- **game-brief** - Create focused game brief document
|
||||
|
||||
#### Phase 2: Design
|
||||
|
||||
- **gdd** - Generate comprehensive Game Design Document
|
||||
- **narrative** - Design narrative structure and story elements
|
||||
|
||||
#### Phase 3: Technical
|
||||
|
||||
- **game-architecture** - Define technical architecture (adapted from BMM architecture workflow)
|
||||
|
||||
#### Phase 4: Production
|
||||
|
||||
Production workflows are provided by the BMM module and accessible through the Game Dev Scrum Master agent:
|
||||
|
||||
- Sprint planning
|
||||
- Story creation and management
|
||||
- Epic technical specifications
|
||||
- Code review and retrospectives
|
||||
|
||||
## Quick Start
|
||||
|
||||
### 1. Start with Concept Development
|
||||
|
||||
```
|
||||
Load agent: game-designer
|
||||
Run workflow: brainstorm-game
|
||||
```
|
||||
|
||||
### 2. Create Game Brief
|
||||
|
||||
```
|
||||
Run workflow: game-brief
|
||||
```
|
||||
|
||||
### 3. Develop Game Design Document
|
||||
|
||||
```
|
||||
Run workflow: gdd
|
||||
```
|
||||
|
||||
### 4. Define Technical Architecture
|
||||
|
||||
```
|
||||
Load agent: game-architect
|
||||
Run workflow: game-architecture
|
||||
```
|
||||
|
||||
### 5. Begin Production Sprints
|
||||
|
||||
```
|
||||
Load agent: game-scrum-master
|
||||
Run: *sprint-planning
|
||||
```
|
||||
|
||||
## Module Structure
|
||||
|
||||
```
|
||||
bmgd/
|
||||
├── agents/
|
||||
│ ├── game-designer.agent.yaml
|
||||
│ ├── game-dev.agent.yaml
|
||||
│ ├── game-architect.agent.yaml
|
||||
│ └── game-scrum-master.agent.yaml
|
||||
├── teams/
|
||||
│ └── team-gamedev.yaml
|
||||
├── workflows/
|
||||
│ ├── 1-preproduction/
|
||||
│ │ ├── brainstorm-game/
|
||||
│ │ └── game-brief/
|
||||
│ ├── 2-design/
|
||||
│ │ ├── gdd/
|
||||
│ │ └── narrative/
|
||||
│ ├── 3-technical/
|
||||
│ │ └── game-architecture/
|
||||
│ └── 4-production/
|
||||
│ (Uses BMM workflows via cross-module references)
|
||||
├── templates/
|
||||
├── data/
|
||||
└── _module-installer/
|
||||
└── install-config.yaml
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
After installation, configure the module in `bmad/bmgd/config.yaml`
|
||||
|
||||
Key settings:
|
||||
|
||||
- **game_project_name** - Your game's working title
|
||||
- **game_design_docs** - Location for GDD and design documents
|
||||
- **game_tech_docs** - Location for technical documentation
|
||||
- **game_story_location** - Location for development user stories
|
||||
- **game_dev_experience** - Your experience level (affects agent communication)
|
||||
- **primary_platform** - Target platform (PC, mobile, console, web, multi-platform)
|
||||
|
||||
## Workflow Integration
|
||||
|
||||
BMGD leverages the BMM module for production/implementation workflows. The Game Dev Scrum Master agent provides access to:
|
||||
|
||||
- Sprint planning and management
|
||||
- Story creation from GDD specifications
|
||||
- Epic technical context generation
|
||||
- Code review workflows
|
||||
- Retrospectives and course correction
|
||||
|
||||
This separation allows BMGD to focus on game-specific design and architecture while using battle-tested agile implementation workflows.
|
||||
|
||||
## Example: Creating a 2D Platformer
|
||||
|
||||
1. **Brainstorm** concepts with `brainstorm-game` workflow
|
||||
2. **Define** the vision with `game-brief` workflow
|
||||
3. **Design** mechanics and progression with `gdd` workflow
|
||||
4. **Craft** character arcs and story with `narrative` workflow
|
||||
5. **Architect** technical systems with `game-architecture` workflow
|
||||
6. **Implement** via Game Dev Scrum Master sprint workflows
|
||||
|
||||
## Development Roadmap
|
||||
|
||||
### Phase 1: Core Enhancement
|
||||
|
||||
- [ ] Customize game-architecture workflow for game-specific patterns
|
||||
- [ ] Add game-specific templates (level design, character sheets, etc.)
|
||||
- [ ] Create asset pipeline workflows
|
||||
|
||||
### Phase 2: Expanded Features
|
||||
|
||||
- [ ] Add monetization planning workflows
|
||||
- [ ] Create playtesting and feedback workflows
|
||||
- [ ] Develop game balancing tools
|
||||
|
||||
### Phase 3: Platform Integration
|
||||
|
||||
- [ ] Add platform-specific deployment workflows
|
||||
- [ ] Create build and release automation
|
||||
- [ ] Develop live ops workflows
|
||||
|
||||
## Contributing
|
||||
|
||||
To extend this module:
|
||||
|
||||
1. Add new agents using `/bmad:bmb:workflows:create-agent`
|
||||
2. Add new workflows using `/bmad:bmb:workflows:create-workflow`
|
||||
3. Submit improvements via pull request
|
||||
|
||||
## Dependencies
|
||||
|
||||
- **BMM Module** - Required for production/implementation workflows
|
||||
|
||||
## Author
|
||||
|
||||
Extracted and refined from BMM module on 2025-11-05
|
||||
|
||||
## License
|
||||
|
||||
Part of the BMAD Method ecosystem
|
||||
66
src/modules/bmgd/_module-installer/install-config.yaml
Normal file
66
src/modules/bmgd/_module-installer/install-config.yaml
Normal file
@@ -0,0 +1,66 @@
|
||||
# BMad Game Dev Module Configuration
|
||||
|
||||
code: bmgd
|
||||
name: "BMGD: BMad Game Development"
|
||||
default_selected: false
|
||||
|
||||
prompt:
|
||||
- "Welcome to the BMad Game Development Module!"
|
||||
- "This module provides specialized agents and workflows for game creation,"
|
||||
- "from initial concept through production, covering all major game dev phases."
|
||||
- "All paths are relative to project root, with no leading slash."
|
||||
|
||||
# Core config values automatically inherited:
|
||||
## user_name
|
||||
## communication_language
|
||||
## document_output_language
|
||||
## output_folder
|
||||
|
||||
game_project_name:
|
||||
prompt: "What is the name of your game project?"
|
||||
default: "{directory_name}"
|
||||
result: "{value}"
|
||||
|
||||
game_design_docs:
|
||||
prompt: "Where should game design documents (GDD, narrative, etc.) be stored?"
|
||||
default: "docs/design"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
game_tech_docs:
|
||||
prompt: "Where should game technical documentation be stored?"
|
||||
default: "docs/technical"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
game_story_location:
|
||||
prompt: "Where should game development stories be stored?"
|
||||
default: "docs/stories"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
game_dev_experience:
|
||||
prompt: "What is your game development experience level?"
|
||||
default: "intermediate"
|
||||
result: "{value}"
|
||||
single-select:
|
||||
- value: "beginner"
|
||||
label: "Beginner - New to game development, provide detailed guidance"
|
||||
- value: "intermediate"
|
||||
label: "Intermediate - Familiar with game dev concepts, balanced approach"
|
||||
- value: "expert"
|
||||
label: "Expert - Experienced game developer, be direct and technical"
|
||||
|
||||
specified_framework:
|
||||
prompt: "Which game development framework or engine do you want to install support for?"
|
||||
default: "unity"
|
||||
result: "{value}"
|
||||
multi-select:
|
||||
- value: "unity"
|
||||
label: "Unity"
|
||||
- value: "unreal"
|
||||
label: "Unreal Engine"
|
||||
- value: "godot"
|
||||
label: "Godot"
|
||||
- value: "custom"
|
||||
label: "Custom / Other"
|
||||
|
||||
data_path:
|
||||
result: "{project-root}/bmad/bmgd/data"
|
||||
28
src/modules/bmgd/agents/game-architect.agent.yaml
Normal file
28
src/modules/bmgd/agents/game-architect.agent.yaml
Normal file
@@ -0,0 +1,28 @@
|
||||
# Game Architect Agent Definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: bmad/bmgd/agents/game-architect.md
|
||||
name: Cloud Dragonborn
|
||||
title: Game Architect
|
||||
icon: 🏛️
|
||||
module: bmgd
|
||||
|
||||
persona:
|
||||
role: Principal Game Systems Architect + Technical Director
|
||||
identity: Master architect with 20+ years designing scalable game systems and technical foundations. Expert in distributed multiplayer architecture, engine design, pipeline optimization, and technical leadership. Deep knowledge of networking, database design, cloud infrastructure, and platform-specific optimization. Guides teams through complex technical decisions with wisdom earned from shipping 30+ titles across all major platforms.
|
||||
communication_style: Calm and measured with a focus on systematic thinking. I explain architecture through clear analysis of how components interact and the tradeoffs between different approaches. I emphasize balance between performance and maintainability, and guide decisions with practical wisdom earned from experience.
|
||||
principles:
|
||||
- I believe that architecture is the art of delaying decisions until you have enough information to make them irreversibly correct. Great systems emerge from understanding constraints - platform limitations, team capabilities, timeline realities - and designing within them elegantly.
|
||||
- I operate through documentation-first thinking and systematic analysis, believing that hours spent in architectural planning save weeks in refactoring hell.
|
||||
- Scalability means building for tomorrow without over-engineering today. Simplicity is the ultimate sophistication in system design.
|
||||
|
||||
menu:
|
||||
- trigger: correct-course
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/correct-course/workflow.yaml"
|
||||
description: Course Correction Analysis
|
||||
|
||||
- trigger: create-architecture
|
||||
workflow: "{project-root}/bmad/bmgd/workflows/3-technical/game-architecture/workflow.yaml"
|
||||
description: Produce a Scale Adaptive Game Architecture
|
||||
35
src/modules/bmgd/agents/game-designer.agent.yaml
Normal file
35
src/modules/bmgd/agents/game-designer.agent.yaml
Normal file
@@ -0,0 +1,35 @@
|
||||
# Game Designer Agent Definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: bmad/bmgd/agents/game-designer.md
|
||||
name: Samus Shepard
|
||||
title: Game Designer
|
||||
icon: 🎲
|
||||
module: bmgd
|
||||
|
||||
persona:
|
||||
role: Lead Game Designer + Creative Vision Architect
|
||||
identity: Veteran game designer with 15+ years crafting immersive experiences across AAA and indie titles. Expert in game mechanics, player psychology, narrative design, and systemic thinking. Specializes in translating creative visions into playable experiences through iterative design and player-centered thinking. Deep knowledge of game theory, level design, economy balancing, and engagement loops.
|
||||
communication_style: Enthusiastic and player-focused. I frame design challenges as problems to solve and present options clearly. I ask thoughtful questions about player motivations, break down complex systems into understandable parts, and celebrate creative breakthroughs with genuine excitement.
|
||||
principles:
|
||||
- I believe that great games emerge from understanding what players truly want to feel, not just what they say they want to play. Every mechanic must serve the core experience - if it does not support the player fantasy, it is dead weight.
|
||||
- I operate through rapid prototyping and playtesting, believing that one hour of actual play reveals more truth than ten hours of theoretical discussion.
|
||||
- Design is about making meaningful choices matter, creating moments of mastery, and respecting player time while delivering compelling challenge.
|
||||
|
||||
menu:
|
||||
- trigger: brainstorm-game
|
||||
workflow: "{project-root}/bmad/bmgd/workflows/1-preproduction/brainstorm-game/workflow.yaml"
|
||||
description: 1. Guide me through Game Brainstorming
|
||||
|
||||
- trigger: create-game-brief
|
||||
workflow: "{project-root}/bmad/bmgd/workflows/1-preproduction/game-brief/workflow.yaml"
|
||||
description: 3. Create Game Brief
|
||||
|
||||
- trigger: create-gdd
|
||||
workflow: "{project-root}/bmad/bmgd/workflows/2-design/gdd/workflow.yaml"
|
||||
description: 4. Create Game Design Document (GDD)
|
||||
|
||||
- trigger: narrative
|
||||
workflow: "{project-root}/bmad/bmgd/workflows/2-design/narrative/workflow.yaml"
|
||||
description: 5. Create Narrative Design Document (story-driven games)
|
||||
34
src/modules/bmgd/agents/game-dev.agent.yaml
Normal file
34
src/modules/bmgd/agents/game-dev.agent.yaml
Normal file
@@ -0,0 +1,34 @@
|
||||
# Game Developer Agent Definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: bmad/bmgd/agents/game-dev.md
|
||||
name: Link Freeman
|
||||
title: Game Developer
|
||||
icon: 🕹️
|
||||
module: bmgd
|
||||
|
||||
persona:
|
||||
role: Senior Game Developer + Technical Implementation Specialist
|
||||
identity: Battle-hardened game developer with expertise across Unity, Unreal, and custom engines. Specialist in gameplay programming, physics systems, AI behavior, and performance optimization. Ten years shipping games across mobile, console, and PC platforms. Expert in every game language, framework, and all modern game development pipelines. Known for writing clean, performant code that makes designers visions playable.
|
||||
communication_style: Direct and energetic with a focus on execution. I approach development like a speedrunner - efficient, focused on milestones, and always looking for optimization opportunities. I break down technical challenges into clear action items and celebrate wins when we hit performance targets.
|
||||
principles:
|
||||
- I believe in writing code that game designers can iterate on without fear - flexibility is the foundation of good game code. Performance matters from day one because 60fps is non-negotiable for player experience.
|
||||
- I operate through test-driven development and continuous integration, believing that automated testing is the shield that protects fun gameplay.
|
||||
- Clean architecture enables creativity - messy code kills innovation. Ship early, ship often, iterate based on player feedback.
|
||||
|
||||
menu:
|
||||
- trigger: develop-story
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/dev-story/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/dev-story/workflow.yaml"
|
||||
description: "Execute Dev Story workflow, implementing tasks and tests, or performing updates to the story"
|
||||
|
||||
- trigger: code-review
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/code-review/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/code-review/workflow.yaml"
|
||||
description: "Perform a thorough clean context QA code review on a story flagged Ready for Review"
|
||||
|
||||
- trigger: story-done
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/story-done/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/story-done/workflow.yaml"
|
||||
description: "Mark story done after DoD complete"
|
||||
70
src/modules/bmgd/agents/game-scrum-master.agent.yaml
Normal file
70
src/modules/bmgd/agents/game-scrum-master.agent.yaml
Normal file
@@ -0,0 +1,70 @@
|
||||
# Game Dev Scrum Master Agent Definition
|
||||
|
||||
agent:
|
||||
metadata:
|
||||
id: bmad/bmgd/agents/game-scrum-master.md
|
||||
name: Max
|
||||
title: Game Dev Scrum Master
|
||||
icon: 🎯
|
||||
module: bmgd
|
||||
|
||||
persona:
|
||||
role: Game Development Scrum Master + Sprint Orchestrator
|
||||
identity: Certified Scrum Master specializing in game development workflows. Expert in agile game development, story preparation for game features, and coordinating multi-disciplinary game teams (designers, developers, artists). Experienced in managing sprints across all game development phases from preproduction through production. Skilled at translating game design documents into actionable development stories.
|
||||
communication_style: Energetic and milestone-focused. I speak in game dev terminology and celebrate hitting development milestones like hitting save points in a tough level. Clear handoffs and structured preparation are my special abilities. I keep the team moving forward through each phase of development.
|
||||
principles:
|
||||
- I maintain clean separation between design specification and implementation, ensuring GDDs and Tech Specs flow smoothly into developer-ready user stories that capture the essence of gameplay features.
|
||||
- My commitment to iterative development means every sprint delivers playable increments, enabling rapid playtesting and feedback loops that keep the game fun.
|
||||
- I coordinate across disciplines - ensuring designers, developers, and architects are aligned on feature implementation and technical approach.
|
||||
|
||||
critical_actions:
|
||||
- "When running *create-story for game features, use GDD, Architecture, and Tech Spec to generate complete draft stories without elicitation, focusing on playable outcomes."
|
||||
|
||||
menu:
|
||||
- trigger: sprint-planning
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/sprint-planning/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/sprint-planning/workflow.yaml"
|
||||
description: Generate or update sprint-status.yaml from epic files
|
||||
|
||||
- trigger: epic-tech-context
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/epic-tech-context/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/epic-tech-context/workflow.yaml"
|
||||
description: (Optional) Use the GDD and Architecture to create an Epic-Tech-Spec for a specific epic
|
||||
|
||||
- trigger: validate-epic-tech-context
|
||||
validate-workflow: "{project-root}/bmad/bmgd/workflows/4-production/epic-tech-context/workflow.yaml"
|
||||
description: (Optional) Validate latest Tech Spec against checklist
|
||||
|
||||
- trigger: create-story-draft
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/create-story/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/create-story/workflow.yaml"
|
||||
description: Create a Story Draft for a game feature
|
||||
|
||||
- trigger: validate-create-story
|
||||
validate-workflow: "{project-root}/bmad/bmgd/workflows/4-production/create-story/workflow.yaml"
|
||||
description: (Optional) Validate Story Draft with Independent Review
|
||||
|
||||
- trigger: story-context
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/story-context/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/story-context/workflow.yaml"
|
||||
description: (Optional) Assemble dynamic Story Context (XML) from latest docs and code and mark story ready for dev
|
||||
|
||||
- trigger: validate-story-context
|
||||
validate-workflow: "{project-root}/bmad/bmgd/workflows/4-production/story-context/workflow.yaml"
|
||||
description: (Optional) Validate latest Story Context XML against checklist
|
||||
|
||||
- trigger: story-ready-for-dev
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/story-ready/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/story-ready/workflow.yaml"
|
||||
description: (Optional) Mark drafted story ready for dev without generating Story Context
|
||||
|
||||
- trigger: epic-retrospective
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/retrospective/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/retrospective/workflow.yaml"
|
||||
data: "{project-root}/bmad/_cfg/agent-manifest.csv"
|
||||
description: (Optional) Facilitate team retrospective after a game development epic is completed
|
||||
|
||||
- trigger: correct-course
|
||||
workflow: "{project-root}/bmad/bmm/workflows/4-implementation/correct-course/workflow.yaml"
|
||||
workflow-install: "{project-root}/bmad/bmgd/workflows/4-production/correct-course/workflow.yaml"
|
||||
description: (Optional) Navigate significant changes during game dev sprint
|
||||
16
src/modules/bmgd/teams/team-gamedev.yaml
Normal file
16
src/modules/bmgd/teams/team-gamedev.yaml
Normal file
@@ -0,0 +1,16 @@
|
||||
# <!-- Powered by BMAD-CORE™ -->
|
||||
bundle:
|
||||
name: Team Game Development
|
||||
icon: 🎮
|
||||
description: Specialized game development team including Game Designer (creative vision and GDD), Game Developer (implementation and code), Game Architect (technical systems and infrastructure), and Game Dev Scrum Master (sprint coordination). Perfect for game projects across all scales and platforms.
|
||||
agents:
|
||||
- game-designer
|
||||
- game-dev
|
||||
- game-architect
|
||||
- game-scrum-master
|
||||
|
||||
workflows:
|
||||
- brainstorm-game
|
||||
- game-brief
|
||||
- gdd
|
||||
- narrative
|
||||
@@ -0,0 +1,26 @@
|
||||
category,technique_name,description,facilitation_prompts,best_for,energy_level,typical_duration
|
||||
game_design,MDA Framework Exploration,Explore game concepts through Mechanics-Dynamics-Aesthetics lens to ensure cohesive design from implementation to player experience,What mechanics create the core loop?|What dynamics emerge from these mechanics?|What aesthetic experience results?|How do they align?,holistic-design,moderate,20-30
|
||||
game_design,Core Loop Brainstorming,Design the fundamental moment-to-moment gameplay loop that players repeat - the heartbeat of your game,What does the player do?|What's the immediate reward?|Why do it again?|How does it evolve?,gameplay-foundation,high,15-25
|
||||
game_design,Player Fantasy Mining,Identify and amplify the core fantasy that players want to embody - what makes them feel powerful and engaged,What fantasy does the player live?|What makes them feel awesome?|What power do they wield?|What identity do they assume?,player-motivation,high,15-20
|
||||
game_design,Genre Mashup,Combine unexpected game genres to create innovative hybrid experiences that offer fresh gameplay,Take two unrelated genres|How do they merge?|What unique gameplay emerges?|What's the hook?,innovation,high,15-20
|
||||
game_design,Verbs Before Nouns,Focus on what players DO before what things ARE - prioritize actions over objects for engaging gameplay,What verbs define your game?|What actions feel good?|Build mechanics from verbs|Nouns support actions,mechanics-first,moderate,20-25
|
||||
game_design,Failure State Design,Work backwards from interesting failure conditions to create tension and meaningful choices,How can players fail interestingly?|What makes failure feel fair?|How does failure teach?|Recovery mechanics?,challenge-design,moderate,15-20
|
||||
game_design,Progression Curve Sculpting,Map the player's emotional and skill journey from tutorial to mastery - pace challenge and revelation,How does difficulty evolve?|When do we introduce concepts?|What's the skill ceiling?|How do we maintain flow?,pacing-balance,moderate,25-30
|
||||
game_design,Emergence Engineering,Design simple rule interactions that create complex unexpected player-driven outcomes,What simple rules combine?|What emerges from interactions?|How do players surprise you?|Systemic possibilities?,depth-complexity,moderate,20-25
|
||||
game_design,Accessibility Layers,Brainstorm how different skill levels and abilities can access your core experience meaningfully,Who might struggle with what?|What alternate inputs exist?|How do we preserve challenge?|Inclusive design options?,inclusive-design,moderate,20-25
|
||||
game_design,Reward Schedule Architecture,Design the timing and type of rewards to maintain player motivation and engagement,What rewards when?|Variable or fixed schedule?|Intrinsic vs extrinsic rewards?|Progression satisfaction?,engagement-retention,moderate,20-30
|
||||
narrative_game,Ludonarrative Harmony,Align story and gameplay so mechanics reinforce narrative themes - make meaning through play,What does gameplay express?|How do mechanics tell story?|Where do they conflict?|How to unify theme?,storytelling,moderate,20-25
|
||||
narrative_game,Environmental Storytelling,Use world design and ambient details to convey narrative without explicit exposition,What does the space communicate?|What happened here before?|Visual narrative clues?|Show don't tell?,world-building,moderate,15-20
|
||||
narrative_game,Player Agency Moments,Identify key decision points where player choice shapes narrative in meaningful ways,What choices matter?|How do consequences manifest?|Branch vs flavor choices?|Meaningful agency where?,player-choice,moderate,20-25
|
||||
narrative_game,Emotion Targeting,Design specific moments intended to evoke targeted emotional responses through integrated design,What emotion when?|How do all elements combine?|Music + mechanics + narrative?|Orchestrated feelings?,emotional-design,high,20-30
|
||||
systems_game,Economy Balancing Thought Experiments,Explore resource generation/consumption balance to prevent game-breaking exploits,What resources exist?|Generation vs consumption rates?|What loops emerge?|Where's the exploit?,economy-design,moderate,25-30
|
||||
systems_game,Meta-Game Layer Design,Brainstorm progression systems that persist beyond individual play sessions,What carries over between sessions?|Long-term goals?|How does meta feed core loop?|Retention hooks?,retention-systems,moderate,20-25
|
||||
multiplayer_game,Social Dynamics Mapping,Anticipate how players will interact and design mechanics that support desired social behaviors,How will players cooperate?|Competitive dynamics?|Toxic behavior prevention?|Positive interaction rewards?,social-design,moderate,20-30
|
||||
multiplayer_game,Spectator Experience Design,Consider how watching others play can be entertaining - esports and streaming potential,What's fun to watch?|Readable visual clarity?|Highlight moments?|Narrative for observers?,spectator-value,moderate,15-20
|
||||
creative_game,Constraint-Based Creativity,Embrace a specific limitation as your core design constraint and build everything around it,Pick a severe constraint|What if this was your ONLY mechanic?|Build a full game from limitation|Constraint as creativity catalyst,innovation,moderate,15-25
|
||||
creative_game,Game Feel Playground,Focus purely on how controls and feedback FEEL before worrying about context or goals,What feels juicy to do?|Controller response?|Visual/audio feedback?|Satisfying micro-interactions?,game-feel,high,20-30
|
||||
creative_game,One Button Game Challenge,Design interesting gameplay using only a single input - forces elegant simplicity,Only one button - what can it do?|Context changes meaning?|Timing variations?|Depth from simplicity?,minimalist-design,moderate,15-20
|
||||
wild_game,Remix an Existing Game,Take a well-known game and twist one core element - what new experience emerges?,Pick a famous game|Change ONE fundamental rule|What ripples from that change?|New game from mutation?,rapid-prototyping,high,10-15
|
||||
wild_game,Anti-Game Design,Design a game that deliberately breaks common conventions - subvert player expectations,What if we broke this rule?|Expectation subversion?|Anti-patterns as features?|Avant-garde possibilities?,experimental,moderate,15-20
|
||||
wild_game,Physics Playground,Start with an interesting physics interaction and build a game around that sensation,What physics are fun to play with?|Build game from physics toy|Emergent physics gameplay?|Sensation first?,prototype-first,high,15-25
|
||||
wild_game,Toy Before Game,Create a playful interactive toy with no goals first - then discover the game within it,What's fun to mess with?|No goals yet - just play|What game emerges organically?|Toy to game evolution?,discovery-design,high,20-30
|
||||
|
@@ -0,0 +1,115 @@
|
||||
# Game Brainstorming Context
|
||||
|
||||
This context guide provides game-specific considerations for brainstorming sessions focused on game design and development.
|
||||
|
||||
## Session Focus Areas
|
||||
|
||||
When brainstorming for games, consider exploring:
|
||||
|
||||
- **Core Gameplay Loop** - What players do moment-to-moment
|
||||
- **Player Fantasy** - What identity/power fantasy does the game fulfill?
|
||||
- **Game Mechanics** - Rules and interactions that define play
|
||||
- **Game Dynamics** - Emergent behaviors from mechanic interactions
|
||||
- **Aesthetic Experience** - Emotional responses and feelings evoked
|
||||
- **Progression Systems** - How players grow and unlock content
|
||||
- **Challenge and Difficulty** - How to create engaging difficulty curves
|
||||
- **Social/Multiplayer Features** - How players interact with each other
|
||||
- **Narrative and World** - Story, setting, and environmental storytelling
|
||||
- **Art Direction and Feel** - Visual style and game feel
|
||||
- **Monetization** - Business model and revenue approach (if applicable)
|
||||
|
||||
## Game Design Frameworks
|
||||
|
||||
### MDA Framework
|
||||
|
||||
- **Mechanics** - Rules and systems (what's in the code)
|
||||
- **Dynamics** - Runtime behavior (how mechanics interact)
|
||||
- **Aesthetics** - Emotional responses (what players feel)
|
||||
|
||||
### Player Motivation (Bartle's Taxonomy)
|
||||
|
||||
- **Achievers** - Goal completion and progression
|
||||
- **Explorers** - Discovery and understanding systems
|
||||
- **Socializers** - Interaction and relationships
|
||||
- **Killers** - Competition and dominance
|
||||
|
||||
### Core Experience Questions
|
||||
|
||||
- What does the player DO? (Verbs first, nouns second)
|
||||
- What makes them feel powerful/competent/awesome?
|
||||
- What's the central tension or challenge?
|
||||
- What's the "one more turn" factor?
|
||||
|
||||
## Recommended Brainstorming Techniques
|
||||
|
||||
### Game Design Specific Techniques
|
||||
|
||||
(These are available as additional techniques in game brainstorming sessions)
|
||||
|
||||
- **MDA Framework Exploration** - Design through mechanics-dynamics-aesthetics
|
||||
- **Core Loop Brainstorming** - Define the heartbeat of gameplay
|
||||
- **Player Fantasy Mining** - Identify and amplify player power fantasies
|
||||
- **Genre Mashup** - Combine unexpected genres for innovation
|
||||
- **Verbs Before Nouns** - Focus on actions before objects
|
||||
- **Failure State Design** - Work backwards from interesting failures
|
||||
- **Ludonarrative Harmony** - Align story and gameplay
|
||||
- **Game Feel Playground** - Focus purely on how controls feel
|
||||
|
||||
### Standard Techniques Well-Suited for Games
|
||||
|
||||
- **SCAMPER Method** - Innovate on existing game mechanics
|
||||
- **What If Scenarios** - Explore radical gameplay possibilities
|
||||
- **First Principles Thinking** - Rebuild game concepts from scratch
|
||||
- **Role Playing** - Generate ideas from player perspectives
|
||||
- **Analogical Thinking** - Find inspiration from other games/media
|
||||
- **Constraint-Based Creativity** - Design around limitations
|
||||
- **Morphological Analysis** - Explore mechanic combinations
|
||||
|
||||
## Output Guidance
|
||||
|
||||
Effective game brainstorming sessions should capture:
|
||||
|
||||
1. **Core Concept** - High-level game vision and hook
|
||||
2. **Key Mechanics** - Primary gameplay verbs and interactions
|
||||
3. **Player Experience** - What it feels like to play
|
||||
4. **Unique Elements** - What makes this game special/different
|
||||
5. **Design Challenges** - Obstacles to solve during development
|
||||
6. **Prototype Ideas** - What to test first
|
||||
7. **Reference Games** - Existing games that inspire or inform
|
||||
8. **Open Questions** - What needs further exploration
|
||||
|
||||
## Integration with Game Development Workflow
|
||||
|
||||
Game brainstorming sessions typically feed into:
|
||||
|
||||
- **Game Briefs** - High-level vision and core pillars
|
||||
- **Game Design Documents (GDD)** - Comprehensive design specifications
|
||||
- **Technical Design Docs** - Architecture for game systems
|
||||
- **Prototype Plans** - What to build to validate concepts
|
||||
- **Art Direction Documents** - Visual style and feel guides
|
||||
|
||||
## Special Considerations for Game Design
|
||||
|
||||
### Start With The Feel
|
||||
|
||||
- How should controls feel? Responsive? Weighty? Floaty?
|
||||
- What's the "game feel" - the juice and feedback?
|
||||
- Can we prototype the core interaction quickly?
|
||||
|
||||
### Think in Systems
|
||||
|
||||
- How do mechanics interact?
|
||||
- What emergent behaviors arise?
|
||||
- Are there dominant strategies or exploits?
|
||||
|
||||
### Design for Failure
|
||||
|
||||
- How do players fail?
|
||||
- Is failure interesting and instructive?
|
||||
- What's the cost of failure?
|
||||
|
||||
### Player Agency vs. Authored Experience
|
||||
|
||||
- Where do players have meaningful choices?
|
||||
- Where is the experience authored/scripted?
|
||||
- How do we balance freedom and guidance?
|
||||
@@ -0,0 +1,128 @@
|
||||
<critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>Communicate all responses in {communication_language}</critical>
|
||||
<critical>This is a meta-workflow that orchestrates the CIS brainstorming workflow with game-specific context and additional game design techniques</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Game brainstorming is optional - you can continue without status tracking.</output>
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "brainstorm-game" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_type != 'game'">
|
||||
<output>Note: This is a {{project_type}} project. Game brainstorming is designed for game projects.</output>
|
||||
<ask>Continue with game brainstorming anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="brainstorm-game status is file path (already completed)">
|
||||
<output>⚠️ Game brainstorming session already completed: {{brainstorm-game status}}</output>
|
||||
<ask>Re-running will create a new session. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="brainstorm-game is not the next expected workflow (latter items are completed already in the list)">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Game brainstorming is out of sequence.</output>
|
||||
<ask>Continue with game brainstorming anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Load game brainstorming context and techniques">
|
||||
<action>Read the game context document from: {game_context}</action>
|
||||
<action>This context provides game-specific guidance including:
|
||||
- Focus areas for game ideation (mechanics, narrative, experience, etc.)
|
||||
- Key considerations for game design
|
||||
- Recommended techniques for game brainstorming
|
||||
- Output structure guidance
|
||||
</action>
|
||||
<action>Load game-specific brain techniques from: {game_brain_methods}</action>
|
||||
<action>These additional techniques supplement the standard CIS brainstorming methods with game design-focused approaches like:
|
||||
- MDA Framework exploration
|
||||
- Core loop brainstorming
|
||||
- Player fantasy mining
|
||||
- Genre mashup
|
||||
- And other game-specific ideation methods
|
||||
</action>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Invoke CIS brainstorming with game context">
|
||||
<action>Execute the CIS brainstorming workflow with game context and additional techniques</action>
|
||||
<invoke-workflow path="{core_brainstorming}" data="{game_context}" techniques="{game_brain_methods}">
|
||||
The CIS brainstorming workflow will:
|
||||
- Merge game-specific techniques with standard techniques
|
||||
- Present interactive brainstorming techniques menu
|
||||
- Guide the user through selected ideation methods
|
||||
- Generate and capture brainstorming session results
|
||||
- Save output to: {output_folder}/brainstorming-session-results-{{date}}.md
|
||||
</invoke-workflow>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Update status and complete" tag="workflow-status">
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "brainstorm-game"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["brainstorm-game"] = "{output_folder}/bmm-brainstorming-session-{{date}}.md"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
</check>
|
||||
|
||||
<output>**✅ Game Brainstorming Session Complete, {user_name}!**
|
||||
|
||||
**Session Results:**
|
||||
|
||||
- Game brainstorming results saved to: {output_folder}/bmm-brainstorming-session-{{date}}.md
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
**Status Updated:**
|
||||
|
||||
- Progress tracking updated: brainstorm-game marked complete
|
||||
- Next workflow: {{next_workflow}}
|
||||
{{else}}
|
||||
**Note:** Running in standalone mode (no progress tracking)
|
||||
{{/if}}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
|
||||
- **Next workflow:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- **Optional:** You can run other analysis workflows (research, game-brief) before proceeding
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
{{else}}
|
||||
Since no workflow is in progress:
|
||||
|
||||
- Refer to the BMM workflow guide if unsure what to do next
|
||||
- Or run `workflow-init` to create a workflow path and get guided next steps
|
||||
{{/if}}
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,41 @@
|
||||
# Brainstorm Game Workflow Configuration
|
||||
name: "brainstorm-game"
|
||||
description: "Facilitate game brainstorming sessions by orchestrating the CIS brainstorming workflow with game-specific context, guidance, and additional game design techniques."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
game_dev_experience: "{config_source}:game_dev_experience"
|
||||
date: system-generated
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/bmad/bmgd/workflows/1-preproduction/brainstorm-game"
|
||||
template: false
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
|
||||
# Context and techniques for game brainstorming
|
||||
game_context: "{installed_path}/game-context.md"
|
||||
game_brain_methods: "{installed_path}/game-brain-methods.csv"
|
||||
|
||||
# CORE brainstorming workflow to invoke
|
||||
core_brainstorming: "{project-root}/bmad/core/workflows/brainstorming/workflow.yaml"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle:
|
||||
name: "brainstorm-game"
|
||||
description: "Facilitate game brainstorming sessions by orchestrating the CIS brainstorming workflow with game-specific context, guidance, and additional game design techniques."
|
||||
author: "BMad"
|
||||
instructions: "bmad/bmgd/workflows/1-preproduction/brainstorm-game/instructions.md"
|
||||
template: false
|
||||
web_bundle_files:
|
||||
- "bmad/bmgd/workflows/1-preproduction/brainstorm-game/instructions.md"
|
||||
- "bmad/bmgd/workflows/1-preproduction/brainstorm-game/game-context.md"
|
||||
- "bmad/bmgd/workflows/1-preproduction/brainstorm-game/game-brain-methods.csv"
|
||||
- "bmad/core/workflows/brainstorming/workflow.yaml"
|
||||
existing_workflows:
|
||||
- core_brainstorming: "bmad/core/workflows/brainstorming/workflow.yaml"
|
||||
@@ -0,0 +1,128 @@
|
||||
# Game Brief Validation Checklist
|
||||
|
||||
Use this checklist to ensure your game brief is complete and ready for GDD creation.
|
||||
|
||||
## Game Vision ✓
|
||||
|
||||
- [ ] **Core Concept** is clear and concise (one sentence)
|
||||
- [ ] **Elevator Pitch** hooks the reader in 2-3 sentences
|
||||
- [ ] **Vision Statement** is aspirational but achievable
|
||||
- [ ] Vision captures the emotional experience you want to create
|
||||
|
||||
## Target Market ✓
|
||||
|
||||
- [ ] **Primary Audience** is specific (not just "gamers")
|
||||
- [ ] Age range and experience level are defined
|
||||
- [ ] Play session expectations are realistic
|
||||
- [ ] **Market Context** demonstrates opportunity
|
||||
- [ ] Competitive landscape is understood
|
||||
- [ ] You know why this audience will care
|
||||
|
||||
## Game Fundamentals ✓
|
||||
|
||||
- [ ] **Core Gameplay Pillars** (2-4) are clearly defined
|
||||
- [ ] Each pillar is specific and measurable
|
||||
- [ ] **Primary Mechanics** describe what players actually DO
|
||||
- [ ] **Player Experience Goals** connect mechanics to emotions
|
||||
- [ ] Core loop is clear and compelling
|
||||
|
||||
## Scope and Constraints ✓
|
||||
|
||||
- [ ] **Target Platforms** are prioritized
|
||||
- [ ] **Development Timeline** is realistic
|
||||
- [ ] **Budget** aligns with scope
|
||||
- [ ] **Team Resources** (size, skills) are documented
|
||||
- [ ] **Technical Constraints** are identified
|
||||
- [ ] Scope matches team capability
|
||||
|
||||
## Reference Framework ✓
|
||||
|
||||
- [ ] **Inspiration Games** (3-5) are listed with specifics
|
||||
- [ ] You know what you're taking vs. NOT taking from each
|
||||
- [ ] **Competitive Analysis** covers direct and indirect competitors
|
||||
- [ ] **Key Differentiators** are genuine and valuable
|
||||
- [ ] Differentiators are specific (not "just better")
|
||||
|
||||
## Content Framework ✓
|
||||
|
||||
- [ ] **World and Setting** is defined
|
||||
- [ ] **Narrative Approach** matches game type
|
||||
- [ ] **Content Volume** is estimated (rough order of magnitude)
|
||||
- [ ] Playtime expectations are set
|
||||
- [ ] Replayability approach is clear
|
||||
|
||||
## Art and Audio Direction ✓
|
||||
|
||||
- [ ] **Visual Style** is described with references
|
||||
- [ ] 2D vs. 3D is decided
|
||||
- [ ] **Audio Style** matches game mood
|
||||
- [ ] **Production Approach** is realistic for team/budget
|
||||
- [ ] Style complexity matches capabilities
|
||||
|
||||
## Risk Assessment ✓
|
||||
|
||||
- [ ] **Key Risks** are honestly identified
|
||||
- [ ] **Technical Challenges** are documented
|
||||
- [ ] **Market Risks** are considered
|
||||
- [ ] **Mitigation Strategies** are actionable
|
||||
- [ ] Assumptions to validate are listed
|
||||
|
||||
## Success Criteria ✓
|
||||
|
||||
- [ ] **MVP Definition** is truly minimal
|
||||
- [ ] MVP can validate core gameplay hypothesis
|
||||
- [ ] **Success Metrics** are specific and measurable
|
||||
- [ ] **Launch Goals** are realistic
|
||||
- [ ] You know what "done" looks like for MVP
|
||||
|
||||
## Next Steps ✓
|
||||
|
||||
- [ ] **Immediate Actions** are prioritized
|
||||
- [ ] **Research Needs** are identified
|
||||
- [ ] **Open Questions** are documented
|
||||
- [ ] Critical path is clear
|
||||
- [ ] Blockers are identified
|
||||
|
||||
## Overall Quality ✓
|
||||
|
||||
- [ ] Brief is clear and concise (3-5 pages)
|
||||
- [ ] Sections are internally consistent
|
||||
- [ ] Scope is realistic for team/timeline/budget
|
||||
- [ ] Vision is compelling and achievable
|
||||
- [ ] You're excited to build this game
|
||||
- [ ] Team/stakeholders can understand the vision
|
||||
|
||||
## Red Flags 🚩
|
||||
|
||||
Watch for these warning signs:
|
||||
|
||||
- [ ] ❌ Scope too large for team/timeline
|
||||
- [ ] ❌ Unclear core loop or pillars
|
||||
- [ ] ❌ Target audience is "everyone"
|
||||
- [ ] ❌ Differentiators are vague or weak
|
||||
- [ ] ❌ No prototype plan for risky mechanics
|
||||
- [ ] ❌ Budget/timeline is wishful thinking
|
||||
- [ ] ❌ Market is saturated with no clear positioning
|
||||
- [ ] ❌ MVP is not actually minimal
|
||||
|
||||
## Ready for Next Steps?
|
||||
|
||||
If you've checked most boxes and have no major red flags:
|
||||
|
||||
✅ **Ready to proceed to:**
|
||||
|
||||
- Prototype core mechanic
|
||||
- GDD workflow
|
||||
- Team/stakeholder review
|
||||
- Market validation
|
||||
|
||||
⚠️ **Need more work if:**
|
||||
|
||||
- Multiple sections incomplete
|
||||
- Red flags present
|
||||
- Team/stakeholders don't align
|
||||
- Core concept unclear
|
||||
|
||||
---
|
||||
|
||||
_This checklist is a guide, not a gate. Use your judgment based on project needs._
|
||||
@@ -0,0 +1,371 @@
|
||||
# Game Brief - Interactive Workflow Instructions
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Concise, professional, game-design focused. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
|
||||
|
||||
<workflow>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Game brief is optional - you can continue without status tracking.</output>
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "game-brief" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_type != 'game'">
|
||||
<output>Note: This is a {{project_type}} project. Game brief is designed for game projects.</output>
|
||||
<ask>Continue with game brief anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="game-brief status is file path (already completed)">
|
||||
<output>⚠️ Game Brief already completed: {{game-brief status}}</output>
|
||||
<ask>Re-running will overwrite the existing brief. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="game-brief is not the next expected workflow (latter items are completed already in the list)">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Game Brief is out of sequence.</output>
|
||||
<ask>Continue with Game Brief anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Initialize game brief session">
|
||||
<action>Welcome the user in {communication_language} to the Game Brief creation process</action>
|
||||
<action>Explain this is a collaborative process to define their game vision, capturing the essence of what they want to create</action>
|
||||
<action>Ask for the working title of their game</action>
|
||||
<template-output>game_name</template-output>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Gather available inputs and context">
|
||||
<action>Explore what existing materials the user has available to inform the brief</action>
|
||||
<action>Offer options for input sources: market research, brainstorming results, competitive analysis, design notes, reference games, or starting fresh</action>
|
||||
<action>If documents are provided, load and analyze them to extract key insights, themes, and patterns</action>
|
||||
<action>Engage the user about their core vision: what gameplay experience they want to create, what emotions players should feel, and what sparked this game idea</action>
|
||||
<action>Build initial understanding through conversational exploration rather than rigid questioning</action>
|
||||
|
||||
<template-output>initial_context</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Choose collaboration mode">
|
||||
<ask>How would you like to work through the brief?
|
||||
|
||||
**1. Interactive Mode** - We'll work through each section together, discussing and refining as we go
|
||||
**2. YOLO Mode** - I'll generate a complete draft based on our conversation so far, then we'll refine it together
|
||||
|
||||
Which approach works best for you?</ask>
|
||||
|
||||
<action>Store the user's preference for mode</action>
|
||||
<template-output>collaboration_mode</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Define game vision" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide user to articulate their game vision across three levels of depth</action>
|
||||
<action>Help them craft a one-sentence core concept that captures the essence (reference successful games like "A roguelike deck-builder where you climb a mysterious spire" as examples)</action>
|
||||
<action>Develop an elevator pitch (2-3 sentences) that would compel a publisher or player - refine until it's concise but hooks attention</action>
|
||||
<action>Explore their aspirational vision statement: the experience they want to create and what makes it meaningful - ensure it's ambitious yet achievable</action>
|
||||
<action>Refine through conversation, challenging vague language and elevating compelling ideas</action>
|
||||
|
||||
<template-output>core_concept</template-output>
|
||||
<template-output>elevator_pitch</template-output>
|
||||
<template-output>vision_statement</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Identify target market" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide user to define their primary target audience with specific demographics, gaming preferences, and behavioral characteristics</action>
|
||||
<action>Push for specificity beyond generic descriptions like "people who like fun games" - challenge vague answers</action>
|
||||
<action>Explore secondary audiences if applicable and how their needs might differ</action>
|
||||
<action>Investigate the market context: opportunity size, competitive landscape, similar successful games, and why now is the right time</action>
|
||||
<action>Help identify a realistic and reachable audience segment based on evidence or well-reasoned assumptions</action>
|
||||
|
||||
<template-output>primary_audience</template-output>
|
||||
<template-output>secondary_audience</template-output>
|
||||
<template-output>market_context</template-output>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Define game fundamentals" if="collaboration_mode == 'interactive'">
|
||||
<action>Help user identify 2-4 core gameplay pillars that fundamentally define their game - everything should support these pillars</action>
|
||||
<action>Provide examples from successful games for inspiration (Hollow Knight's "tight controls + challenging combat + rewarding exploration")</action>
|
||||
<action>Explore what the player actually DOES - core actions, key systems, and interaction models</action>
|
||||
<action>Define the emotional experience goals: what feelings are you designing for (tension/relief, mastery/growth, creativity/expression, discovery/surprise)</action>
|
||||
<action>Ensure pillars are specific and measurable, focusing on player actions rather than implementation details</action>
|
||||
<action>Connect mechanics directly to emotional experiences through guided discussion</action>
|
||||
|
||||
<template-output>core_gameplay_pillars</template-output>
|
||||
<template-output>primary_mechanics</template-output>
|
||||
<template-output>player_experience_goals</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Define scope and constraints" if="collaboration_mode == 'interactive'">
|
||||
<action>Help user establish realistic project constraints across all key dimensions</action>
|
||||
<action>Explore target platforms and prioritization (PC, console, mobile, web)</action>
|
||||
<action>Discuss development timeline: release targets, fixed deadlines, phased release strategies</action>
|
||||
<action>Investigate budget reality: funding source, asset creation costs, marketing, tools and software</action>
|
||||
<action>Assess team resources: size, roles, availability, skills gaps, outsourcing needs</action>
|
||||
<action>Define technical constraints: engine choice, performance targets, file size limits, accessibility requirements</action>
|
||||
<action>Push for realism about scope - identify potential blockers early and document resource assumptions</action>
|
||||
|
||||
<template-output>target_platforms</template-output>
|
||||
<template-output>development_timeline</template-output>
|
||||
<template-output>budget_considerations</template-output>
|
||||
<template-output>team_resources</template-output>
|
||||
<template-output>technical_constraints</template-output>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Establish reference framework" if="collaboration_mode == 'interactive'">
|
||||
<action>Guide user to identify 3-5 inspiration games and articulate what they're drawing from each (mechanics, feel, art style) and explicitly what they're NOT taking</action>
|
||||
<action>Conduct competitive analysis: identify direct and indirect competitors, analyze what they do well and poorly, and define how this game will differ</action>
|
||||
<action>Explore key differentiators and unique value proposition - what's the hook that makes players choose this game over alternatives</action>
|
||||
<action>Challenge "just better" thinking - push for genuine, specific differentiation that's actually valuable to players</action>
|
||||
<action>Validate that differentiators are concrete, achievable, and compelling</action>
|
||||
|
||||
<template-output>inspiration_games</template-output>
|
||||
<template-output>competitive_analysis</template-output>
|
||||
<template-output>key_differentiators</template-output>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Define content framework" if="collaboration_mode == 'interactive'">
|
||||
<action>Explore the game's world and setting: location, time period, world-building depth, narrative importance, and genre context</action>
|
||||
<action>Define narrative approach: story-driven/light/absent, linear/branching/emergent, delivery methods (cutscenes, dialogue, environmental), writing scope</action>
|
||||
<action>Estimate content volume realistically: playthrough length, level/stage count, replayability strategy, total asset volume</action>
|
||||
<action>Identify if a dedicated narrative workflow will be needed later based on story complexity</action>
|
||||
<action>Flag content-heavy areas that require detailed planning and resource allocation</action>
|
||||
|
||||
<template-output>world_setting</template-output>
|
||||
<template-output>narrative_approach</template-output>
|
||||
<template-output>content_volume</template-output>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Define art and audio direction" if="collaboration_mode == 'interactive'">
|
||||
<action>Explore visual style direction: art style preference, color palette and mood, reference games/images, 2D vs 3D, animation requirements</action>
|
||||
<action>Define audio style: music genre and mood, SFX approach, voice acting scope, audio's importance to gameplay</action>
|
||||
<action>Discuss production approach: in-house creation vs outsourcing, asset store usage, AI/generative tools, style complexity vs team capability</action>
|
||||
<action>Ensure art and audio vision aligns realistically with budget and team skills - identify potential production bottlenecks early</action>
|
||||
<action>Note if a comprehensive style guide will be needed for consistent production</action>
|
||||
|
||||
<template-output>visual_style</template-output>
|
||||
<template-output>audio_style</template-output>
|
||||
<template-output>production_approach</template-output>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Assess risks" if="collaboration_mode == 'interactive'">
|
||||
<action>Facilitate honest risk assessment across all dimensions - what could prevent completion, what could make it unfun, what assumptions might be wrong</action>
|
||||
<action>Identify technical challenges: unproven elements, performance concerns, platform-specific issues, tool dependencies</action>
|
||||
<action>Explore market risks: saturation, trend dependency, competition intensity, discoverability challenges</action>
|
||||
<action>For each major risk, develop actionable mitigation strategies - how to validate assumptions, backup plans, early prototyping opportunities</action>
|
||||
<action>Prioritize risks by impact and likelihood, focusing on proactive mitigation rather than passive worry</action>
|
||||
|
||||
<template-output>key_risks</template-output>
|
||||
<template-output>technical_challenges</template-output>
|
||||
<template-output>market_risks</template-output>
|
||||
<template-output>mitigation_strategies</template-output>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Define success criteria" if="collaboration_mode == 'interactive'">
|
||||
<action>Define the MVP (Minimum Playable Version) - what's the absolute minimum where the core loop is fun and complete, with essential content only</action>
|
||||
<action>Establish specific, measurable success metrics: player acquisition, retention rates, session length, completion rate, review scores, revenue targets, community engagement</action>
|
||||
<action>Set concrete launch goals: first-month sales/downloads, review score targets, streamer/press coverage, community size</action>
|
||||
<action>Push for specificity and measurability - challenge vague aspirations with "how will you measure that?"</action>
|
||||
<action>Clearly distinguish between MVP milestones and full release goals, ensuring all targets are realistic given resources</action>
|
||||
|
||||
<template-output>mvp_definition</template-output>
|
||||
<template-output>success_metrics</template-output>
|
||||
<template-output>launch_goals</template-output>
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Identify immediate next steps" if="collaboration_mode == 'interactive'">
|
||||
<action>Identify immediate actions to take right after this brief: prototype core mechanics, create art style tests, validate technical feasibility, build vertical slice, playtest with target audience</action>
|
||||
<action>Determine research needs: market validation, technical proof of concept, player interest testing, competitive deep-dive</action>
|
||||
<action>Document open questions and uncertainties: unresolved design questions, technical unknowns, market validation needs, resource/budget questions</action>
|
||||
<action>Create actionable, specific next steps - prioritize by importance and dependency</action>
|
||||
<action>Identify blockers that must be resolved before moving forward</action>
|
||||
|
||||
<template-output>immediate_actions</template-output>
|
||||
<template-output>research_needs</template-output>
|
||||
<template-output>open_questions</template-output>
|
||||
</step>
|
||||
|
||||
<!-- YOLO Mode - Generate everything then refine -->
|
||||
<step n="3" goal="Generate complete brief draft" if="collaboration_mode == 'yolo'">
|
||||
<action>Based on initial context and any provided documents, generate a complete game brief covering all sections</action>
|
||||
<action>Make reasonable assumptions where information is missing</action>
|
||||
<action>Flag areas that need user validation with [NEEDS CONFIRMATION] tags</action>
|
||||
|
||||
<template-output>core_concept</template-output>
|
||||
<template-output>elevator_pitch</template-output>
|
||||
<template-output>vision_statement</template-output>
|
||||
<template-output>primary_audience</template-output>
|
||||
<template-output>secondary_audience</template-output>
|
||||
<template-output>market_context</template-output>
|
||||
<template-output>core_gameplay_pillars</template-output>
|
||||
<template-output>primary_mechanics</template-output>
|
||||
<template-output>player_experience_goals</template-output>
|
||||
<template-output>target_platforms</template-output>
|
||||
<template-output>development_timeline</template-output>
|
||||
<template-output>budget_considerations</template-output>
|
||||
<template-output>team_resources</template-output>
|
||||
<template-output>technical_constraints</template-output>
|
||||
<template-output>inspiration_games</template-output>
|
||||
<template-output>competitive_analysis</template-output>
|
||||
<template-output>key_differentiators</template-output>
|
||||
<template-output>world_setting</template-output>
|
||||
<template-output>narrative_approach</template-output>
|
||||
<template-output>content_volume</template-output>
|
||||
<template-output>visual_style</template-output>
|
||||
<template-output>audio_style</template-output>
|
||||
<template-output>production_approach</template-output>
|
||||
<template-output>key_risks</template-output>
|
||||
<template-output>technical_challenges</template-output>
|
||||
<template-output>market_risks</template-output>
|
||||
<template-output>mitigation_strategies</template-output>
|
||||
<template-output>mvp_definition</template-output>
|
||||
<template-output>success_metrics</template-output>
|
||||
<template-output>launch_goals</template-output>
|
||||
<template-output>immediate_actions</template-output>
|
||||
<template-output>research_needs</template-output>
|
||||
<template-output>open_questions</template-output>
|
||||
|
||||
<action>Present the complete draft to the user</action>
|
||||
<ask>Here's the complete game brief draft. What would you like to adjust or refine?</ask>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Refine brief sections" repeat="until-approved" if="collaboration_mode == 'yolo'">
|
||||
<ask>Which section would you like to refine?
|
||||
|
||||
1. Game Vision
|
||||
2. Target Market
|
||||
3. Game Fundamentals
|
||||
4. Scope and Constraints
|
||||
5. Reference Framework
|
||||
6. Content Framework
|
||||
7. Art and Audio Direction
|
||||
8. Risk Assessment
|
||||
9. Success Criteria
|
||||
10. Next Steps
|
||||
11. Save and continue</ask>
|
||||
|
||||
<action>Work with user to refine selected section</action>
|
||||
<action>Update relevant template outputs</action>
|
||||
</step>
|
||||
|
||||
<!-- Final steps for both modes -->
|
||||
<step n="13" goal="Create executive summary">
|
||||
<action>Synthesize all sections into a compelling executive summary</action>
|
||||
<action>Include:
|
||||
- Game concept in 1-2 sentences
|
||||
- Target audience and market
|
||||
- Core gameplay pillars
|
||||
- Key differentiators
|
||||
- Success vision</action>
|
||||
|
||||
<template-output>executive_summary</template-output>
|
||||
</step>
|
||||
|
||||
<step n="14" goal="Compile supporting materials">
|
||||
<action>If research documents were provided, create a summary of key findings</action>
|
||||
<action>Document any stakeholder input received during the process</action>
|
||||
<action>Compile list of reference games and resources</action>
|
||||
|
||||
<template-output>research_summary</template-output>
|
||||
<template-output>stakeholder_input</template-output>
|
||||
<template-output>references</template-output>
|
||||
</step>
|
||||
|
||||
<step n="15" goal="Final review and handoff">
|
||||
<action>Generate the complete game brief document</action>
|
||||
<action>Review all sections for completeness and consistency</action>
|
||||
<action>Flag any areas that need design attention with [DESIGN-TODO] tags</action>
|
||||
|
||||
<ask>The game brief is complete! Would you like to:
|
||||
|
||||
1. Review the entire document
|
||||
2. Make final adjustments
|
||||
3. Generate an executive summary version (3-page limit)
|
||||
4. Save and prepare for GDD creation
|
||||
|
||||
This brief will serve as the primary input for creating the Game Design Document (GDD).
|
||||
|
||||
**Recommended next steps:**
|
||||
|
||||
- Create prototype of core mechanic
|
||||
- Proceed to GDD workflow: `workflow gdd`
|
||||
- Validate assumptions with target players</ask>
|
||||
|
||||
<check if="user chooses option 3 (executive summary)">
|
||||
<action>Create condensed 3-page executive brief focusing on: core concept, target market, gameplay pillars, key differentiators, and success criteria</action>
|
||||
<action>Save as: {output_folder}/game-brief-executive-{{game_name}}-{{date}}.md</action>
|
||||
</check>
|
||||
|
||||
<template-output>final_brief</template-output>
|
||||
<template-output>executive_brief</template-output>
|
||||
</step>
|
||||
|
||||
<step n="16" goal="Update status and complete" tag="workflow-status">
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "game-brief"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["game-brief"] = "{output_folder}/bmm-game-brief-{{game_name}}-{{date}}.md"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
</check>
|
||||
|
||||
<output>**✅ Game Brief Complete, {user_name}!**
|
||||
|
||||
**Brief Document:**
|
||||
|
||||
- Game brief saved to {output_folder}/bmm-game-brief-{{game_name}}-{{date}}.md
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
**Status Updated:**
|
||||
|
||||
- Progress tracking updated: game-brief marked complete
|
||||
- Next workflow: {{next_workflow}}
|
||||
{{else}}
|
||||
**Note:** Running in standalone mode (no progress tracking)
|
||||
{{/if}}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
|
||||
- **Next workflow:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- **Optional:** Consider creating a prototype of core mechanic or validating assumptions with target players before proceeding
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
{{else}}
|
||||
Since no workflow is in progress:
|
||||
|
||||
- Refer to the BMM workflow guide if unsure what to do next
|
||||
- Or run `workflow-init` to create a workflow path and get guided next steps
|
||||
{{/if}}
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,205 @@
|
||||
# Game Brief: {{game_name}}
|
||||
|
||||
**Date:** {{date}}
|
||||
**Author:** {{user_name}}
|
||||
**Status:** Draft for GDD Development
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
---
|
||||
|
||||
## Game Vision
|
||||
|
||||
### Core Concept
|
||||
|
||||
{{core_concept}}
|
||||
|
||||
### Elevator Pitch
|
||||
|
||||
{{elevator_pitch}}
|
||||
|
||||
### Vision Statement
|
||||
|
||||
{{vision_statement}}
|
||||
|
||||
---
|
||||
|
||||
## Target Market
|
||||
|
||||
### Primary Audience
|
||||
|
||||
{{primary_audience}}
|
||||
|
||||
### Secondary Audience
|
||||
|
||||
{{secondary_audience}}
|
||||
|
||||
### Market Context
|
||||
|
||||
{{market_context}}
|
||||
|
||||
---
|
||||
|
||||
## Game Fundamentals
|
||||
|
||||
### Core Gameplay Pillars
|
||||
|
||||
{{core_gameplay_pillars}}
|
||||
|
||||
### Primary Mechanics
|
||||
|
||||
{{primary_mechanics}}
|
||||
|
||||
### Player Experience Goals
|
||||
|
||||
{{player_experience_goals}}
|
||||
|
||||
---
|
||||
|
||||
## Scope and Constraints
|
||||
|
||||
### Target Platforms
|
||||
|
||||
{{target_platforms}}
|
||||
|
||||
### Development Timeline
|
||||
|
||||
{{development_timeline}}
|
||||
|
||||
### Budget Considerations
|
||||
|
||||
{{budget_considerations}}
|
||||
|
||||
### Team Resources
|
||||
|
||||
{{team_resources}}
|
||||
|
||||
### Technical Constraints
|
||||
|
||||
{{technical_constraints}}
|
||||
|
||||
---
|
||||
|
||||
## Reference Framework
|
||||
|
||||
### Inspiration Games
|
||||
|
||||
{{inspiration_games}}
|
||||
|
||||
### Competitive Analysis
|
||||
|
||||
{{competitive_analysis}}
|
||||
|
||||
### Key Differentiators
|
||||
|
||||
{{key_differentiators}}
|
||||
|
||||
---
|
||||
|
||||
## Content Framework
|
||||
|
||||
### World and Setting
|
||||
|
||||
{{world_setting}}
|
||||
|
||||
### Narrative Approach
|
||||
|
||||
{{narrative_approach}}
|
||||
|
||||
### Content Volume
|
||||
|
||||
{{content_volume}}
|
||||
|
||||
---
|
||||
|
||||
## Art and Audio Direction
|
||||
|
||||
### Visual Style
|
||||
|
||||
{{visual_style}}
|
||||
|
||||
### Audio Style
|
||||
|
||||
{{audio_style}}
|
||||
|
||||
### Production Approach
|
||||
|
||||
{{production_approach}}
|
||||
|
||||
---
|
||||
|
||||
## Risk Assessment
|
||||
|
||||
### Key Risks
|
||||
|
||||
{{key_risks}}
|
||||
|
||||
### Technical Challenges
|
||||
|
||||
{{technical_challenges}}
|
||||
|
||||
### Market Risks
|
||||
|
||||
{{market_risks}}
|
||||
|
||||
### Mitigation Strategies
|
||||
|
||||
{{mitigation_strategies}}
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### MVP Definition
|
||||
|
||||
{{mvp_definition}}
|
||||
|
||||
### Success Metrics
|
||||
|
||||
{{success_metrics}}
|
||||
|
||||
### Launch Goals
|
||||
|
||||
{{launch_goals}}
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### Immediate Actions
|
||||
|
||||
{{immediate_actions}}
|
||||
|
||||
### Research Needs
|
||||
|
||||
{{research_needs}}
|
||||
|
||||
### Open Questions
|
||||
|
||||
{{open_questions}}
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
### A. Research Summary
|
||||
|
||||
{{research_summary}}
|
||||
|
||||
### B. Stakeholder Input
|
||||
|
||||
{{stakeholder_input}}
|
||||
|
||||
### C. References
|
||||
|
||||
{{references}}
|
||||
|
||||
---
|
||||
|
||||
_This Game Brief serves as the foundational input for Game Design Document (GDD) creation._
|
||||
|
||||
_Next Steps: Use the `workflow gdd` command to create detailed game design documentation._
|
||||
@@ -0,0 +1,44 @@
|
||||
# Game Brief - Interactive Workflow Configuration
|
||||
name: game-brief
|
||||
description: "Interactive game brief creation workflow that guides users through defining their game vision with multiple input sources and conversational collaboration"
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
game_dev_experience: "{config_source}:game_dev_experience"
|
||||
date: system-generated
|
||||
|
||||
# Optional input documents
|
||||
recommended_inputs:
|
||||
- market_research: "Market research document (optional)"
|
||||
- brainstorming_results: "Brainstorming session outputs (optional)"
|
||||
- competitive_analysis: "Competitive game analysis (optional)"
|
||||
- initial_ideas: "Initial game ideas or notes (optional)"
|
||||
- reference_games: "List of inspiration games (optional)"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/bmad/bmgd/workflows/1-preproduction/game-brief"
|
||||
template: "{installed_path}/template.md"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/game-brief-{{game_name}}-{{date}}.md"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle:
|
||||
name: "game-brief"
|
||||
description: "Interactive game brief creation workflow that guides users through defining their game vision with multiple input sources and conversational collaboration"
|
||||
author: "BMad"
|
||||
instructions: "bmad/bmgd/workflows/1-preproduction/game-brief/instructions.md"
|
||||
validation: "bmad/bmgd/workflows/1-preproduction/game-brief/checklist.md"
|
||||
template: "bmad/bmgd/workflows/1-preproduction/game-brief/template.md"
|
||||
web_bundle_files:
|
||||
- "bmad/bmgd/workflows/1-preproduction/game-brief/instructions.md"
|
||||
- "bmad/bmgd/workflows/1-preproduction/game-brief/checklist.md"
|
||||
- "bmad/bmgd/workflows/1-preproduction/game-brief/template.md"
|
||||
148
src/modules/bmgd/workflows/2-design/gdd/checklist.md
Normal file
148
src/modules/bmgd/workflows/2-design/gdd/checklist.md
Normal file
@@ -0,0 +1,148 @@
|
||||
# GDD Workflow Validation Checklist
|
||||
|
||||
**Purpose**: Validate GDD workflow outputs are complete, playable, and ready for solutioning.
|
||||
|
||||
**Scope**: All game project levels (0-4)
|
||||
|
||||
**Expected Outputs**: GDD.md, epics.md
|
||||
|
||||
---
|
||||
|
||||
## 1. Output Files Exist
|
||||
|
||||
- [ ] GDD.md created in output folder
|
||||
- [ ] epics.md created in output folder (separate file)
|
||||
- [ ] bmm-workflow-status.md updated
|
||||
- [ ] No unfilled {{template_variables}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Core Gameplay Definition (CRITICAL)
|
||||
|
||||
### Game Pillars
|
||||
|
||||
- [ ] **2-4 game pillars defined** (fundamental gameplay elements)
|
||||
- [ ] Each pillar is game-defining (not superficial)
|
||||
- [ ] Pillars are distinct (don't overlap)
|
||||
|
||||
### Core Gameplay Loop
|
||||
|
||||
- [ ] **Complete cycle documented** (what player does repeatedly)
|
||||
- [ ] Loop shows: player action → outcome → reward → motivation to repeat
|
||||
- [ ] Loop sounds compelling and repeatable
|
||||
|
||||
### Win/Loss Conditions
|
||||
|
||||
- [ ] Victory conditions clearly defined
|
||||
- [ ] Failure conditions defined (or N/A for sandbox games)
|
||||
- [ ] Conditions are testable
|
||||
|
||||
---
|
||||
|
||||
## 3. Game Mechanics and Systems
|
||||
|
||||
### Mechanics
|
||||
|
||||
- [ ] Primary mechanics described in detail
|
||||
- [ ] Mechanics support the game pillars
|
||||
- [ ] Player interaction with mechanics is clear
|
||||
|
||||
### Progression
|
||||
|
||||
- [ ] Player progression system defined (skill/power/unlock/narrative)
|
||||
- [ ] Difficulty curve explained
|
||||
- [ ] Progression feels rewarding
|
||||
|
||||
### Platform and Controls
|
||||
|
||||
- [ ] Target platforms specified
|
||||
- [ ] Control scheme appropriate for platforms
|
||||
- [ ] Input method clear (keyboard/gamepad/touch/etc.)
|
||||
|
||||
---
|
||||
|
||||
## 4. Story Quality (If epics.md exists)
|
||||
|
||||
### Epic Structure
|
||||
|
||||
- [ ] Epics represent deliverable game features
|
||||
- [ ] Epic sequence makes sense for game development
|
||||
- [ ] Stories show implementation path
|
||||
|
||||
### Story Sequencing (If stories present)
|
||||
|
||||
- [ ] **Vertical slices**: Each story delivers playable functionality
|
||||
- [ ] **Sequential ordering**: Stories build progressively
|
||||
- [ ] **No forward dependencies**: Each story builds on previous work only
|
||||
- [ ] Stories result in testable game features
|
||||
|
||||
---
|
||||
|
||||
## 5. Technical Specifications
|
||||
|
||||
### Performance and Platform
|
||||
|
||||
- [ ] Performance requirements specified (frame rate, resolution, etc.)
|
||||
- [ ] Platform-specific considerations noted
|
||||
- [ ] Asset requirements estimated
|
||||
|
||||
### Production Scope
|
||||
|
||||
- [ ] Art requirements realistic for project scale
|
||||
- [ ] Audio requirements documented
|
||||
- [ ] Scope matches project level and resources
|
||||
|
||||
---
|
||||
|
||||
## 6. Narrative Integration (If Applicable)
|
||||
|
||||
**If narrative-design.md was generated:**
|
||||
|
||||
- [ ] Narrative aligns with GDD game design
|
||||
- [ ] Story supports gameplay (not fighting it)
|
||||
- [ ] Tone consistent across GDD and narrative docs
|
||||
|
||||
---
|
||||
|
||||
## 7. Consistency
|
||||
|
||||
- [ ] Epic titles match between GDD.md and epics.md
|
||||
- [ ] Game type identified and appropriate
|
||||
- [ ] Terminology consistent throughout
|
||||
- [ ] No contradictions between sections
|
||||
|
||||
---
|
||||
|
||||
## 8. Readiness for Solutioning
|
||||
|
||||
- [ ] Sufficient detail for engine/platform selection
|
||||
- [ ] Game systems defined enough for technical architecture
|
||||
- [ ] Clear what needs to be built
|
||||
- [ ] Playable vision (reader can envision playing the game)
|
||||
|
||||
---
|
||||
|
||||
## 9. Critical Failures (Auto-Fail)
|
||||
|
||||
- [ ] ❌ **No core gameplay loop** (can't be a game without this)
|
||||
- [ ] ❌ **No game pillars** (game-defining elements missing)
|
||||
- [ ] ❌ **No mechanics** (what does player actually DO?)
|
||||
- [ ] ❌ **No epics.md file** (implementation roadmap required)
|
||||
- [ ] ❌ **Engine/tech in GDD** (should defer to solutioning workflow)
|
||||
|
||||
---
|
||||
|
||||
## Validation Notes
|
||||
|
||||
**Document any findings:**
|
||||
|
||||
- Game concept strength: [Compelling / Interesting / Unclear / Weak]
|
||||
- Strengths:
|
||||
- Issues to address:
|
||||
- Recommended actions:
|
||||
|
||||
**Ready for solutioning?** [Yes / No - explain]
|
||||
|
||||
---
|
||||
|
||||
_Adapt based on game type and narrative complexity. Core gameplay must always be solid._
|
||||
25
src/modules/bmgd/workflows/2-design/gdd/game-types.csv
Normal file
25
src/modules/bmgd/workflows/2-design/gdd/game-types.csv
Normal file
@@ -0,0 +1,25 @@
|
||||
id,name,description,genre_tags,fragment_file
|
||||
action-platformer,Action Platformer,"Side-scrolling or 3D platforming with combat mechanics","action,platformer,combat,movement",action-platformer.md
|
||||
puzzle,Puzzle,"Logic-based challenges and problem-solving","puzzle,logic,cerebral",puzzle.md
|
||||
rpg,RPG,"Character progression, stats, inventory, quests","rpg,stats,inventory,quests,narrative",rpg.md
|
||||
strategy,Strategy,"Resource management, tactical decisions, long-term planning","strategy,tactics,resources,planning",strategy.md
|
||||
shooter,Shooter,"Projectile combat, aiming mechanics, arena/level design","shooter,combat,aiming,fps,tps",shooter.md
|
||||
adventure,Adventure,"Story-driven exploration and narrative","adventure,narrative,exploration,story",adventure.md
|
||||
simulation,Simulation,"Realistic systems, management, building","simulation,management,sandbox,systems",simulation.md
|
||||
roguelike,Roguelike,"Procedural generation, permadeath, run-based progression","roguelike,procedural,permadeath,runs",roguelike.md
|
||||
moba,MOBA,"Multiplayer team battles, hero/champion selection, lanes","moba,multiplayer,pvp,heroes,lanes",moba.md
|
||||
fighting,Fighting,"1v1 combat, combos, frame data, competitive","fighting,combat,competitive,combos,pvp",fighting.md
|
||||
racing,Racing,"Vehicle control, tracks, speed, lap times","racing,vehicles,tracks,speed",racing.md
|
||||
sports,Sports,"Team-based or individual sports simulation","sports,teams,realistic,physics",sports.md
|
||||
survival,Survival,"Resource gathering, crafting, persistent threats","survival,crafting,resources,danger",survival.md
|
||||
horror,Horror,"Atmosphere, tension, limited resources, fear mechanics","horror,atmosphere,tension,fear",horror.md
|
||||
idle-incremental,Idle/Incremental,"Passive progression, upgrades, automation","idle,incremental,automation,progression",idle-incremental.md
|
||||
card-game,Card Game,"Deck building, card mechanics, turn-based strategy","card,deck-building,strategy,turns",card-game.md
|
||||
tower-defense,Tower Defense,"Wave-based defense, tower placement, resource management","tower-defense,waves,placement,strategy",tower-defense.md
|
||||
metroidvania,Metroidvania,"Interconnected world, ability gating, exploration","metroidvania,exploration,abilities,interconnected",metroidvania.md
|
||||
visual-novel,Visual Novel,"Narrative choices, branching story, dialogue","visual-novel,narrative,choices,story",visual-novel.md
|
||||
rhythm,Rhythm,"Music synchronization, timing-based gameplay","rhythm,music,timing,beats",rhythm.md
|
||||
turn-based-tactics,Turn-Based Tactics,"Grid-based movement, turn order, positioning","tactics,turn-based,grid,positioning",turn-based-tactics.md
|
||||
sandbox,Sandbox,"Creative freedom, building, minimal objectives","sandbox,creative,building,freedom",sandbox.md
|
||||
text-based,Text-Based,"Text input/output, parser or choice-based","text,parser,interactive-fiction,mud",text-based.md
|
||||
party-game,Party Game,"Local multiplayer, minigames, casual fun","party,multiplayer,minigames,casual",party-game.md
|
||||
|
@@ -0,0 +1,45 @@
|
||||
## Action Platformer Specific Elements
|
||||
|
||||
### Movement System
|
||||
|
||||
{{movement_mechanics}}
|
||||
|
||||
**Core movement abilities:**
|
||||
|
||||
- Jump mechanics (height, air control, coyote time)
|
||||
- Running/walking speed
|
||||
- Special movement (dash, wall-jump, double-jump, etc.)
|
||||
|
||||
### Combat System
|
||||
|
||||
{{combat_system}}
|
||||
|
||||
**Combat mechanics:**
|
||||
|
||||
- Attack types (melee, ranged, special)
|
||||
- Combo system
|
||||
- Enemy AI behavior patterns
|
||||
- Hit feedback and impact
|
||||
|
||||
### Level Design Patterns
|
||||
|
||||
{{level_design_patterns}}
|
||||
|
||||
**Level structure:**
|
||||
|
||||
- Platforming challenges
|
||||
- Combat arenas
|
||||
- Secret areas and collectibles
|
||||
- Checkpoint placement
|
||||
- Difficulty spikes and pacing
|
||||
|
||||
### Player Abilities and Unlocks
|
||||
|
||||
{{player_abilities}}
|
||||
|
||||
**Ability progression:**
|
||||
|
||||
- Starting abilities
|
||||
- Unlockable abilities
|
||||
- Ability synergies
|
||||
- Upgrade paths
|
||||
@@ -0,0 +1,84 @@
|
||||
## Adventure Specific Elements
|
||||
|
||||
<narrative-workflow-recommended>
|
||||
This game type is **narrative-heavy**. Consider running the Narrative Design workflow after completing the GDD to create:
|
||||
- Detailed story structure and beats
|
||||
- Character profiles and arcs
|
||||
- World lore and history
|
||||
- Dialogue framework
|
||||
- Environmental storytelling
|
||||
</narrative-workflow-recommended>
|
||||
|
||||
### Exploration Mechanics
|
||||
|
||||
{{exploration_mechanics}}
|
||||
|
||||
**Exploration design:**
|
||||
|
||||
- World structure (linear, open, hub-based, interconnected)
|
||||
- Movement and traversal
|
||||
- Observation and inspection mechanics
|
||||
- Discovery rewards (story reveals, items, secrets)
|
||||
- Pacing of exploration vs. story
|
||||
|
||||
### Story Integration
|
||||
|
||||
{{story_integration}}
|
||||
|
||||
**Narrative gameplay:**
|
||||
|
||||
- Story delivery methods (cutscenes, in-game, environmental)
|
||||
- Player agency in story (linear, branching, player-driven)
|
||||
- Story pacing (acts, beats, tension/release)
|
||||
- Character introduction and development
|
||||
- Climax and resolution structure
|
||||
|
||||
**Note:** Detailed story elements (plot, characters, lore) belong in the Narrative Design Document.
|
||||
|
||||
### Puzzle Systems
|
||||
|
||||
{{puzzle_systems}}
|
||||
|
||||
**Puzzle integration:**
|
||||
|
||||
- Puzzle types (inventory, logic, environmental, dialogue)
|
||||
- Puzzle difficulty curve
|
||||
- Hint systems
|
||||
- Puzzle-story connection (narrative purpose)
|
||||
- Optional vs. required puzzles
|
||||
|
||||
### Character Interaction
|
||||
|
||||
{{character_interaction}}
|
||||
|
||||
**NPC systems:**
|
||||
|
||||
- Dialogue system (branching, linear, choice-based)
|
||||
- Character relationships
|
||||
- NPC schedules/behaviors
|
||||
- Companion mechanics (if applicable)
|
||||
- Memorable character moments
|
||||
|
||||
### Inventory and Items
|
||||
|
||||
{{inventory_items}}
|
||||
|
||||
**Item systems:**
|
||||
|
||||
- Inventory scope (key items, collectibles, consumables)
|
||||
- Item examination/description
|
||||
- Combination/crafting (if applicable)
|
||||
- Story-critical items vs. optional items
|
||||
- Item-based progression gates
|
||||
|
||||
### Environmental Storytelling
|
||||
|
||||
{{environmental_storytelling}}
|
||||
|
||||
**World narrative:**
|
||||
|
||||
- Visual storytelling techniques
|
||||
- Audio atmosphere
|
||||
- Readable documents (journals, notes, signs)
|
||||
- Environmental clues
|
||||
- Show vs. tell balance
|
||||
@@ -0,0 +1,76 @@
|
||||
## Card Game Specific Elements
|
||||
|
||||
### Card Types and Effects
|
||||
|
||||
{{card_types}}
|
||||
|
||||
**Card design:**
|
||||
|
||||
- Card categories (creatures, spells, enchantments, etc.)
|
||||
- Card rarity tiers (common, rare, epic, legendary)
|
||||
- Card attributes (cost, power, health, etc.)
|
||||
- Effect types (damage, healing, draw, control, etc.)
|
||||
- Keywords and abilities
|
||||
- Card synergies
|
||||
|
||||
### Deck Building
|
||||
|
||||
{{deck_building}}
|
||||
|
||||
**Deck construction:**
|
||||
|
||||
- Deck size limits (minimum, maximum)
|
||||
- Card quantity limits (e.g., max 2 copies)
|
||||
- Class/faction restrictions
|
||||
- Deck archetypes (aggro, control, combo, midrange)
|
||||
- Sideboard mechanics (if applicable)
|
||||
- Pre-built vs. custom decks
|
||||
|
||||
### Mana/Resource System
|
||||
|
||||
{{mana_resources}}
|
||||
|
||||
**Resource mechanics:**
|
||||
|
||||
- Mana generation (per turn, from cards, etc.)
|
||||
- Mana curve design
|
||||
- Resource types (colored mana, energy, etc.)
|
||||
- Ramp mechanics
|
||||
- Resource denial strategies
|
||||
|
||||
### Turn Structure
|
||||
|
||||
{{turn_structure}}
|
||||
|
||||
**Game flow:**
|
||||
|
||||
- Turn phases (draw, main, combat, end)
|
||||
- Priority and response windows
|
||||
- Simultaneous vs. alternating turns
|
||||
- Time limits per turn
|
||||
- Match length targets
|
||||
|
||||
### Card Collection and Progression
|
||||
|
||||
{{collection_progression}}
|
||||
|
||||
**Player progression:**
|
||||
|
||||
- Card acquisition (packs, rewards, crafting)
|
||||
- Deck unlocks
|
||||
- Currency systems (gold, dust, wildcards)
|
||||
- Free-to-play balance
|
||||
- Collection completion incentives
|
||||
|
||||
### Game Modes
|
||||
|
||||
{{game_modes}}
|
||||
|
||||
**Mode variety:**
|
||||
|
||||
- Ranked ladder
|
||||
- Draft/Arena modes
|
||||
- Campaign/story mode
|
||||
- Casual/unranked
|
||||
- Special event modes
|
||||
- Tournament formats
|
||||
@@ -0,0 +1,89 @@
|
||||
## Fighting Game Specific Elements
|
||||
|
||||
### Character Roster
|
||||
|
||||
{{character_roster}}
|
||||
|
||||
**Fighter design:**
|
||||
|
||||
- Roster size (launch + planned DLC)
|
||||
- Character archetypes (rushdown, zoner, grappler, all-rounder, etc.)
|
||||
- Move list diversity
|
||||
- Complexity tiers (beginner vs. expert characters)
|
||||
- Balance philosophy (everyone viable vs. tier system)
|
||||
|
||||
### Move Lists and Frame Data
|
||||
|
||||
{{moves_frame_data}}
|
||||
|
||||
**Combat mechanics:**
|
||||
|
||||
- Normal moves (light, medium, heavy)
|
||||
- Special moves (quarter-circle, charge, etc.)
|
||||
- Super/ultimate moves
|
||||
- Frame data (startup, active, recovery, advantage)
|
||||
- Hit/hurt boxes
|
||||
- Command inputs vs. simplified inputs
|
||||
|
||||
### Combo System
|
||||
|
||||
{{combo_system}}
|
||||
|
||||
**Combo design:**
|
||||
|
||||
- Combo structure (links, cancels, chains)
|
||||
- Juggle system
|
||||
- Wall/ground bounces
|
||||
- Combo scaling
|
||||
- Reset opportunities
|
||||
- Optimal vs. practical combos
|
||||
|
||||
### Defensive Mechanics
|
||||
|
||||
{{defensive_mechanics}}
|
||||
|
||||
**Defense options:**
|
||||
|
||||
- Blocking (high, low, crossup protection)
|
||||
- Dodging/rolling/backdashing
|
||||
- Parries/counters
|
||||
- Pushblock/advancing guard
|
||||
- Invincibility frames
|
||||
- Escape options (burst, breaker, etc.)
|
||||
|
||||
### Stage Design
|
||||
|
||||
{{stage_design}}
|
||||
|
||||
**Arena design:**
|
||||
|
||||
- Stage size and boundaries
|
||||
- Wall mechanics (wall combos, wall break)
|
||||
- Interactive elements
|
||||
- Ring-out mechanics (if applicable)
|
||||
- Visual clarity vs. aesthetics
|
||||
|
||||
### Single Player Modes
|
||||
|
||||
{{single_player}}
|
||||
|
||||
**Offline content:**
|
||||
|
||||
- Arcade/story mode
|
||||
- Training mode features
|
||||
- Mission/challenge mode
|
||||
- Boss fights
|
||||
- Unlockables
|
||||
|
||||
### Competitive Features
|
||||
|
||||
{{competitive_features}}
|
||||
|
||||
**Tournament-ready:**
|
||||
|
||||
- Ranked matchmaking
|
||||
- Lobby systems
|
||||
- Replay features
|
||||
- Frame delay/rollback netcode
|
||||
- Spectator mode
|
||||
- Tournament mode
|
||||
86
src/modules/bmgd/workflows/2-design/gdd/game-types/horror.md
Normal file
86
src/modules/bmgd/workflows/2-design/gdd/game-types/horror.md
Normal file
@@ -0,0 +1,86 @@
|
||||
## Horror Game Specific Elements
|
||||
|
||||
<narrative-workflow-recommended>
|
||||
This game type is **narrative-important**. Consider running the Narrative Design workflow after completing the GDD to create:
|
||||
- Detailed story structure and scares
|
||||
- Character backstories and motivations
|
||||
- World lore and mythology
|
||||
- Environmental storytelling
|
||||
- Tension pacing and narrative beats
|
||||
</narrative-workflow-recommended>
|
||||
|
||||
### Atmosphere and Tension Building
|
||||
|
||||
{{atmosphere}}
|
||||
|
||||
**Horror atmosphere:**
|
||||
|
||||
- Visual design (lighting, shadows, color palette)
|
||||
- Audio design (soundscape, silence, music cues)
|
||||
- Environmental storytelling
|
||||
- Pacing of tension and release
|
||||
- Jump scares vs. psychological horror
|
||||
- Safe zones vs. danger zones
|
||||
|
||||
### Fear Mechanics
|
||||
|
||||
{{fear_mechanics}}
|
||||
|
||||
**Core horror systems:**
|
||||
|
||||
- Visibility/darkness mechanics
|
||||
- Limited resources (ammo, health, light)
|
||||
- Vulnerability (combat avoidance, hiding)
|
||||
- Sanity/fear meter (if applicable)
|
||||
- Pursuer/stalker mechanics
|
||||
- Detection systems (line of sight, sound)
|
||||
|
||||
### Enemy/Threat Design
|
||||
|
||||
{{enemy_threat}}
|
||||
|
||||
**Threat systems:**
|
||||
|
||||
- Enemy types (stalker, environmental, psychological)
|
||||
- Enemy behavior (patrol, hunt, ambush)
|
||||
- Telegraphing and tells
|
||||
- Invincible vs. killable enemies
|
||||
- Boss encounters
|
||||
- Encounter frequency and pacing
|
||||
|
||||
### Resource Scarcity
|
||||
|
||||
{{resource_scarcity}}
|
||||
|
||||
**Limited resources:**
|
||||
|
||||
- Ammo/weapon durability
|
||||
- Health items
|
||||
- Light sources (batteries, fuel)
|
||||
- Save points (if limited)
|
||||
- Inventory constraints
|
||||
- Risk vs. reward of exploration
|
||||
|
||||
### Safe Zones and Respite
|
||||
|
||||
{{safe_zones}}
|
||||
|
||||
**Tension management:**
|
||||
|
||||
- Safe room design
|
||||
- Save point placement
|
||||
- Temporary refuge mechanics
|
||||
- Calm before storm pacing
|
||||
- Item management areas
|
||||
|
||||
### Puzzle Integration
|
||||
|
||||
{{puzzles}}
|
||||
|
||||
**Environmental puzzles:**
|
||||
|
||||
- Puzzle types (locks, codes, environmental)
|
||||
- Difficulty balance (accessibility vs. challenge)
|
||||
- Hint systems
|
||||
- Puzzle-tension balance
|
||||
- Narrative purpose of puzzles
|
||||
@@ -0,0 +1,78 @@
|
||||
## Idle/Incremental Game Specific Elements
|
||||
|
||||
### Core Click/Interaction
|
||||
|
||||
{{core_interaction}}
|
||||
|
||||
**Primary mechanic:**
|
||||
|
||||
- Click action (what happens on click)
|
||||
- Click value progression
|
||||
- Auto-click mechanics
|
||||
- Combo/streak systems (if applicable)
|
||||
- Satisfaction and feedback (visual, audio)
|
||||
|
||||
### Upgrade Trees
|
||||
|
||||
{{upgrade_trees}}
|
||||
|
||||
**Upgrade systems:**
|
||||
|
||||
- Upgrade categories (click power, auto-generation, multipliers)
|
||||
- Upgrade costs and scaling
|
||||
- Unlock conditions
|
||||
- Synergies between upgrades
|
||||
- Upgrade branches and choices
|
||||
- Meta-upgrades (affect future runs)
|
||||
|
||||
### Automation Systems
|
||||
|
||||
{{automation}}
|
||||
|
||||
**Passive mechanics:**
|
||||
|
||||
- Auto-clicker unlocks
|
||||
- Manager/worker systems
|
||||
- Multiplier stacking
|
||||
- Offline progression
|
||||
- Automation tiers
|
||||
- Balance between active and idle play
|
||||
|
||||
### Prestige and Reset Mechanics
|
||||
|
||||
{{prestige_reset}}
|
||||
|
||||
**Long-term progression:**
|
||||
|
||||
- Prestige conditions (when to reset)
|
||||
- Persistent bonuses after reset
|
||||
- Prestige currency
|
||||
- Multiple prestige layers (if applicable)
|
||||
- Scaling between runs
|
||||
- Endgame infinite scaling
|
||||
|
||||
### Number Balancing
|
||||
|
||||
{{number_balancing}}
|
||||
|
||||
**Economy design:**
|
||||
|
||||
- Exponential growth curves
|
||||
- Notation systems (K, M, B, T or scientific)
|
||||
- Soft caps and plateaus
|
||||
- Time gates
|
||||
- Pacing of progression
|
||||
- Wall breaking mechanics
|
||||
|
||||
### Meta-Progression
|
||||
|
||||
{{meta_progression}}
|
||||
|
||||
**Long-term engagement:**
|
||||
|
||||
- Achievement system
|
||||
- Collectibles
|
||||
- Alternate game modes
|
||||
- Seasonal content
|
||||
- Challenge runs
|
||||
- Endgame goals
|
||||
@@ -0,0 +1,87 @@
|
||||
## Metroidvania Specific Elements
|
||||
|
||||
<narrative-workflow-recommended>
|
||||
This game type is **narrative-moderate**. Consider running the Narrative Design workflow after completing the GDD to create:
|
||||
- World lore and environmental storytelling
|
||||
- Character encounters and NPC arcs
|
||||
- Backstory reveals through exploration
|
||||
- Optional narrative depth
|
||||
</narrative-workflow-recommended>
|
||||
|
||||
### Interconnected World Map
|
||||
|
||||
{{world_map}}
|
||||
|
||||
**Map design:**
|
||||
|
||||
- World structure (regions, zones, biomes)
|
||||
- Interconnection points (shortcuts, elevators, warps)
|
||||
- Verticality and layering
|
||||
- Secret areas
|
||||
- Map reveal mechanics
|
||||
- Fast travel system (if applicable)
|
||||
|
||||
### Ability-Gating System
|
||||
|
||||
{{ability_gating}}
|
||||
|
||||
**Progression gates:**
|
||||
|
||||
- Core abilities (double jump, dash, wall climb, swim, etc.)
|
||||
- Ability locations and pacing
|
||||
- Soft gates vs. hard gates
|
||||
- Optional abilities
|
||||
- Sequence breaking considerations
|
||||
- Ability synergies
|
||||
|
||||
### Backtracking Design
|
||||
|
||||
{{backtracking}}
|
||||
|
||||
**Return mechanics:**
|
||||
|
||||
- Obvious backtrack opportunities
|
||||
- Hidden backtrack rewards
|
||||
- Fast travel to reduce tedium
|
||||
- Enemy respawn considerations
|
||||
- Changed world state (if applicable)
|
||||
- Completionist incentives
|
||||
|
||||
### Exploration Rewards
|
||||
|
||||
{{exploration_rewards}}
|
||||
|
||||
**Discovery incentives:**
|
||||
|
||||
- Health/energy upgrades
|
||||
- Ability upgrades
|
||||
- Collectibles (lore, cosmetics)
|
||||
- Secret bosses
|
||||
- Optional areas
|
||||
- Completion percentage tracking
|
||||
|
||||
### Combat System
|
||||
|
||||
{{combat_system}}
|
||||
|
||||
**Combat mechanics:**
|
||||
|
||||
- Attack types (melee, ranged, magic)
|
||||
- Boss fight design
|
||||
- Enemy variety and placement
|
||||
- Combat progression
|
||||
- Defensive options
|
||||
- Difficulty balance
|
||||
|
||||
### Sequence Breaking
|
||||
|
||||
{{sequence_breaking}}
|
||||
|
||||
**Advanced play:**
|
||||
|
||||
- Intended vs. unintended skips
|
||||
- Speedrun considerations
|
||||
- Difficulty of sequence breaks
|
||||
- Reward for sequence breaking
|
||||
- Developer stance on breaks
|
||||
- Game completion without all abilities
|
||||
74
src/modules/bmgd/workflows/2-design/gdd/game-types/moba.md
Normal file
74
src/modules/bmgd/workflows/2-design/gdd/game-types/moba.md
Normal file
@@ -0,0 +1,74 @@
|
||||
## MOBA Specific Elements
|
||||
|
||||
### Hero/Champion Roster
|
||||
|
||||
{{hero_roster}}
|
||||
|
||||
**Character design:**
|
||||
|
||||
- Hero count (initial roster, planned additions)
|
||||
- Hero roles (tank, support, carry, assassin, mage, etc.)
|
||||
- Unique abilities per hero (Q, W, E, R + passive)
|
||||
- Hero complexity tiers (beginner-friendly vs. advanced)
|
||||
- Visual and thematic diversity
|
||||
- Counter-pick dynamics
|
||||
|
||||
### Lane Structure and Map
|
||||
|
||||
{{lane_map}}
|
||||
|
||||
**Map design:**
|
||||
|
||||
- Lane configuration (3-lane, 2-lane, custom)
|
||||
- Jungle/neutral areas
|
||||
- Objective locations (towers, inhibitors, nexus/ancient)
|
||||
- Spawn points and fountains
|
||||
- Vision mechanics (wards, fog of war)
|
||||
|
||||
### Item and Build System
|
||||
|
||||
{{item_build}}
|
||||
|
||||
**Itemization:**
|
||||
|
||||
- Item categories (offensive, defensive, utility, consumables)
|
||||
- Gold economy
|
||||
- Build paths and item trees
|
||||
- Situational itemization
|
||||
- Starting items vs. late-game items
|
||||
|
||||
### Team Composition and Roles
|
||||
|
||||
{{team_composition}}
|
||||
|
||||
**Team strategy:**
|
||||
|
||||
- Role requirements (1-3-1, 2-1-2, etc.)
|
||||
- Team synergies
|
||||
- Draft/ban phase (if applicable)
|
||||
- Meta considerations
|
||||
- Flexible vs. rigid compositions
|
||||
|
||||
### Match Phases
|
||||
|
||||
{{match_phases}}
|
||||
|
||||
**Game flow:**
|
||||
|
||||
- Early game (laning phase)
|
||||
- Mid game (roaming, objectives)
|
||||
- Late game (team fights, sieging)
|
||||
- Phase transition mechanics
|
||||
- Comeback mechanics
|
||||
|
||||
### Objectives and Win Conditions
|
||||
|
||||
{{objectives_victory}}
|
||||
|
||||
**Strategic objectives:**
|
||||
|
||||
- Primary objective (destroy base/nexus/ancient)
|
||||
- Secondary objectives (towers, dragons, baron, roshan, etc.)
|
||||
- Neutral camps
|
||||
- Vision control objectives
|
||||
- Time limits and sudden death (if applicable)
|
||||
@@ -0,0 +1,79 @@
|
||||
## Party Game Specific Elements
|
||||
|
||||
### Minigame Variety
|
||||
|
||||
{{minigame_variety}}
|
||||
|
||||
**Minigame design:**
|
||||
|
||||
- Minigame count (launch + DLC)
|
||||
- Genre variety (racing, puzzle, reflex, trivia, etc.)
|
||||
- Minigame length (15-60 seconds typical)
|
||||
- Skill vs. luck balance
|
||||
- Team vs. FFA minigames
|
||||
- Accessibility across skill levels
|
||||
|
||||
### Turn Structure
|
||||
|
||||
{{turn_structure}}
|
||||
|
||||
**Game flow:**
|
||||
|
||||
- Board game structure (if applicable)
|
||||
- Turn order (fixed, random, earned)
|
||||
- Turn actions (roll dice, move, minigame, etc.)
|
||||
- Event spaces
|
||||
- Special mechanics (warp, steal, bonus)
|
||||
- Match length (rounds, turns, time)
|
||||
|
||||
### Player Elimination vs. Points
|
||||
|
||||
{{scoring_elimination}}
|
||||
|
||||
**Competition design:**
|
||||
|
||||
- Points-based (everyone plays to the end)
|
||||
- Elimination (last player standing)
|
||||
- Hybrid systems
|
||||
- Comeback mechanics
|
||||
- Handicap systems
|
||||
- Victory conditions
|
||||
|
||||
### Local Multiplayer UX
|
||||
|
||||
{{local_multiplayer}}
|
||||
|
||||
**Couch co-op design:**
|
||||
|
||||
- Controller sharing vs. individual controllers
|
||||
- Screen layout (split-screen, shared screen)
|
||||
- Turn clarity (whose turn indicators)
|
||||
- Spectator experience (watching others play)
|
||||
- Player join/drop mechanics
|
||||
- Tutorial integration for new players
|
||||
|
||||
### Accessibility and Skill Range
|
||||
|
||||
{{accessibility}}
|
||||
|
||||
**Inclusive design:**
|
||||
|
||||
- Skill floor (easy to understand)
|
||||
- Skill ceiling (depth for experienced players)
|
||||
- Luck elements to balance skill gaps
|
||||
- Assist modes or handicaps
|
||||
- Child-friendly content
|
||||
- Colorblind modes and accessibility
|
||||
|
||||
### Session Length
|
||||
|
||||
{{session_length}}
|
||||
|
||||
**Time management:**
|
||||
|
||||
- Quick play (5-10 minutes)
|
||||
- Standard match (15-30 minutes)
|
||||
- Extended match (30+ minutes)
|
||||
- Drop-in/drop-out support
|
||||
- Pause and resume
|
||||
- Party management (hosting, invites)
|
||||
58
src/modules/bmgd/workflows/2-design/gdd/game-types/puzzle.md
Normal file
58
src/modules/bmgd/workflows/2-design/gdd/game-types/puzzle.md
Normal file
@@ -0,0 +1,58 @@
|
||||
## Puzzle Game Specific Elements
|
||||
|
||||
### Core Puzzle Mechanics
|
||||
|
||||
{{puzzle_mechanics}}
|
||||
|
||||
**Puzzle elements:**
|
||||
|
||||
- Primary puzzle mechanic(s)
|
||||
- Supporting mechanics
|
||||
- Mechanic interactions
|
||||
- Constraint systems
|
||||
|
||||
### Puzzle Progression
|
||||
|
||||
{{puzzle_progression}}
|
||||
|
||||
**Difficulty progression:**
|
||||
|
||||
- Tutorial/introduction puzzles
|
||||
- Core concept puzzles
|
||||
- Combined mechanic puzzles
|
||||
- Expert/bonus puzzles
|
||||
- Pacing and difficulty curve
|
||||
|
||||
### Level Structure
|
||||
|
||||
{{level_structure}}
|
||||
|
||||
**Level organization:**
|
||||
|
||||
- Number of levels/puzzles
|
||||
- World/chapter grouping
|
||||
- Unlock progression
|
||||
- Optional/bonus content
|
||||
|
||||
### Player Assistance
|
||||
|
||||
{{player_assistance}}
|
||||
|
||||
**Help systems:**
|
||||
|
||||
- Hint system
|
||||
- Undo/reset mechanics
|
||||
- Skip puzzle options
|
||||
- Tutorial integration
|
||||
|
||||
### Replayability
|
||||
|
||||
{{replayability}}
|
||||
|
||||
**Replay elements:**
|
||||
|
||||
- Par time/move goals
|
||||
- Perfect solution challenges
|
||||
- Procedural generation (if applicable)
|
||||
- Daily/weekly puzzles
|
||||
- Challenge modes
|
||||
88
src/modules/bmgd/workflows/2-design/gdd/game-types/racing.md
Normal file
88
src/modules/bmgd/workflows/2-design/gdd/game-types/racing.md
Normal file
@@ -0,0 +1,88 @@
|
||||
## Racing Game Specific Elements
|
||||
|
||||
### Vehicle Handling and Physics
|
||||
|
||||
{{vehicle_physics}}
|
||||
|
||||
**Handling systems:**
|
||||
|
||||
- Physics model (arcade vs. simulation vs. hybrid)
|
||||
- Vehicle stats (speed, acceleration, handling, braking, weight)
|
||||
- Drift mechanics
|
||||
- Collision physics
|
||||
- Vehicle damage system (if applicable)
|
||||
|
||||
### Vehicle Roster
|
||||
|
||||
{{vehicle_roster}}
|
||||
|
||||
**Vehicle design:**
|
||||
|
||||
- Vehicle types (cars, bikes, boats, etc.)
|
||||
- Vehicle classes (lightweight, balanced, heavyweight)
|
||||
- Unlock progression
|
||||
- Customization options (visual, performance)
|
||||
- Balance considerations
|
||||
|
||||
### Track Design
|
||||
|
||||
{{track_design}}
|
||||
|
||||
**Course design:**
|
||||
|
||||
- Track variety (circuits, point-to-point, open world)
|
||||
- Track length and lap counts
|
||||
- Hazards and obstacles
|
||||
- Shortcuts and alternate paths
|
||||
- Track-specific mechanics
|
||||
- Environmental themes
|
||||
|
||||
### Race Mechanics
|
||||
|
||||
{{race_mechanics}}
|
||||
|
||||
**Core racing:**
|
||||
|
||||
- Starting mechanics (countdown, reaction time)
|
||||
- Checkpoint system
|
||||
- Lap tracking and position
|
||||
- Slipstreaming/drafting
|
||||
- Pit stops (if applicable)
|
||||
- Weather and time-of-day effects
|
||||
|
||||
### Powerups and Boost
|
||||
|
||||
{{powerups_boost}}
|
||||
|
||||
**Enhancement systems (if arcade-style):**
|
||||
|
||||
- Powerup types (offensive, defensive, utility)
|
||||
- Boost mechanics (drift boost, nitro, slipstream)
|
||||
- Item balance
|
||||
- Counterplay mechanics
|
||||
- Powerup placement on track
|
||||
|
||||
### Game Modes
|
||||
|
||||
{{game_modes}}
|
||||
|
||||
**Mode variety:**
|
||||
|
||||
- Standard race
|
||||
- Time trial
|
||||
- Elimination/knockout
|
||||
- Battle/arena modes
|
||||
- Career/campaign mode
|
||||
- Online multiplayer modes
|
||||
|
||||
### Progression and Unlocks
|
||||
|
||||
{{progression}}
|
||||
|
||||
**Player advancement:**
|
||||
|
||||
- Career structure
|
||||
- Unlockable vehicles and tracks
|
||||
- Currency/rewards system
|
||||
- Achievements and challenges
|
||||
- Skill-based unlocks vs. time-based
|
||||
79
src/modules/bmgd/workflows/2-design/gdd/game-types/rhythm.md
Normal file
79
src/modules/bmgd/workflows/2-design/gdd/game-types/rhythm.md
Normal file
@@ -0,0 +1,79 @@
|
||||
## Rhythm Game Specific Elements
|
||||
|
||||
### Music Synchronization
|
||||
|
||||
{{music_sync}}
|
||||
|
||||
**Core mechanics:**
|
||||
|
||||
- Beat/rhythm detection
|
||||
- Note types (tap, hold, slide, etc.)
|
||||
- Synchronization accuracy
|
||||
- Audio-visual feedback
|
||||
- Lane systems (4-key, 6-key, circular, etc.)
|
||||
- Offset calibration
|
||||
|
||||
### Note Charts and Patterns
|
||||
|
||||
{{note_charts}}
|
||||
|
||||
**Chart design:**
|
||||
|
||||
- Charting philosophy (fun, challenge, accuracy to song)
|
||||
- Pattern vocabulary (streams, jumps, chords, etc.)
|
||||
- Difficulty representation
|
||||
- Special patterns (gimmicks, memes)
|
||||
- Chart preview
|
||||
- Custom chart support (if applicable)
|
||||
|
||||
### Timing Windows
|
||||
|
||||
{{timing_windows}}
|
||||
|
||||
**Judgment system:**
|
||||
|
||||
- Judgment tiers (perfect, great, good, bad, miss)
|
||||
- Timing windows (frame-perfect vs. lenient)
|
||||
- Visual feedback for timing
|
||||
- Audio feedback
|
||||
- Combo system
|
||||
- Health/life system (if applicable)
|
||||
|
||||
### Scoring System
|
||||
|
||||
{{scoring}}
|
||||
|
||||
**Score design:**
|
||||
|
||||
- Base score calculation
|
||||
- Combo multipliers
|
||||
- Accuracy weighting
|
||||
- Max score calculation
|
||||
- Grade/rank system (S, A, B, C)
|
||||
- Leaderboards and competition
|
||||
|
||||
### Difficulty Tiers
|
||||
|
||||
{{difficulty_tiers}}
|
||||
|
||||
**Progression:**
|
||||
|
||||
- Difficulty levels (easy, normal, hard, expert, etc.)
|
||||
- Difficulty representation (stars, numbers)
|
||||
- Unlock conditions
|
||||
- Difficulty curve
|
||||
- Accessibility options
|
||||
- Expert+ content
|
||||
|
||||
### Song Selection
|
||||
|
||||
{{song_selection}}
|
||||
|
||||
**Music library:**
|
||||
|
||||
- Song count (launch + planned DLC)
|
||||
- Genre diversity
|
||||
- Licensing vs. original music
|
||||
- Song length targets
|
||||
- Song unlock progression
|
||||
- Favorites and playlists
|
||||
@@ -0,0 +1,69 @@
|
||||
## Roguelike Specific Elements
|
||||
|
||||
### Run Structure
|
||||
|
||||
{{run_structure}}
|
||||
|
||||
**Run design:**
|
||||
|
||||
- Run length (time, stages)
|
||||
- Starting conditions
|
||||
- Difficulty scaling per run
|
||||
- Victory conditions
|
||||
|
||||
### Procedural Generation
|
||||
|
||||
{{procedural_generation}}
|
||||
|
||||
**Generation systems:**
|
||||
|
||||
- Level generation algorithm
|
||||
- Enemy placement
|
||||
- Item/loot distribution
|
||||
- Biome/theme variation
|
||||
- Seed system (if deterministic)
|
||||
|
||||
### Permadeath and Progression
|
||||
|
||||
{{permadeath_progression}}
|
||||
|
||||
**Death mechanics:**
|
||||
|
||||
- Permadeath rules
|
||||
- What persists between runs
|
||||
- Meta-progression systems
|
||||
- Unlock conditions
|
||||
|
||||
### Item and Upgrade System
|
||||
|
||||
{{item_upgrade_system}}
|
||||
|
||||
**Item mechanics:**
|
||||
|
||||
- Item types (passive, active, consumable)
|
||||
- Rarity system
|
||||
- Item synergies
|
||||
- Build variety
|
||||
- Curse/risk mechanics
|
||||
|
||||
### Character Selection
|
||||
|
||||
{{character_selection}}
|
||||
|
||||
**Playable characters:**
|
||||
|
||||
- Starting characters
|
||||
- Unlockable characters
|
||||
- Character unique abilities
|
||||
- Character playstyle differences
|
||||
|
||||
### Difficulty Modifiers
|
||||
|
||||
{{difficulty_modifiers}}
|
||||
|
||||
**Challenge systems:**
|
||||
|
||||
- Difficulty tiers
|
||||
- Modifiers/curses
|
||||
- Challenge runs
|
||||
- Achievement conditions
|
||||
70
src/modules/bmgd/workflows/2-design/gdd/game-types/rpg.md
Normal file
70
src/modules/bmgd/workflows/2-design/gdd/game-types/rpg.md
Normal file
@@ -0,0 +1,70 @@
|
||||
## RPG Specific Elements
|
||||
|
||||
### Character System
|
||||
|
||||
{{character_system}}
|
||||
|
||||
**Character attributes:**
|
||||
|
||||
- Stats (Strength, Dexterity, Intelligence, etc.)
|
||||
- Classes/roles
|
||||
- Leveling system
|
||||
- Skill trees
|
||||
|
||||
### Inventory and Equipment
|
||||
|
||||
{{inventory_equipment}}
|
||||
|
||||
**Equipment system:**
|
||||
|
||||
- Item types (weapons, armor, accessories)
|
||||
- Rarity tiers
|
||||
- Item stats and modifiers
|
||||
- Inventory management
|
||||
|
||||
### Quest System
|
||||
|
||||
{{quest_system}}
|
||||
|
||||
**Quest structure:**
|
||||
|
||||
- Main story quests
|
||||
- Side quests
|
||||
- Quest tracking
|
||||
- Branching questlines
|
||||
- Quest rewards
|
||||
|
||||
### World and Exploration
|
||||
|
||||
{{world_exploration}}
|
||||
|
||||
**World design:**
|
||||
|
||||
- Map structure (open world, hub-based, linear)
|
||||
- Towns and safe zones
|
||||
- Dungeons and combat zones
|
||||
- Fast travel system
|
||||
- Points of interest
|
||||
|
||||
### NPC and Dialogue
|
||||
|
||||
{{npc_dialogue}}
|
||||
|
||||
**NPC interaction:**
|
||||
|
||||
- Dialogue trees
|
||||
- Relationship/reputation system
|
||||
- Companion system
|
||||
- Merchant NPCs
|
||||
|
||||
### Combat System
|
||||
|
||||
{{combat_system}}
|
||||
|
||||
**Combat mechanics:**
|
||||
|
||||
- Combat style (real-time, turn-based, tactical)
|
||||
- Ability system
|
||||
- Magic/skill system
|
||||
- Status effects
|
||||
- Party composition (if applicable)
|
||||
@@ -0,0 +1,79 @@
|
||||
## Sandbox Game Specific Elements
|
||||
|
||||
### Creation Tools
|
||||
|
||||
{{creation_tools}}
|
||||
|
||||
**Building mechanics:**
|
||||
|
||||
- Tool types (place, delete, modify, paint)
|
||||
- Object library (blocks, props, entities)
|
||||
- Precision controls (snap, free, grid)
|
||||
- Copy/paste and templates
|
||||
- Undo/redo system
|
||||
- Import/export functionality
|
||||
|
||||
### Physics and Building Systems
|
||||
|
||||
{{physics_building}}
|
||||
|
||||
**System simulation:**
|
||||
|
||||
- Physics engine (rigid body, soft body, fluids)
|
||||
- Structural integrity (if applicable)
|
||||
- Destruction mechanics
|
||||
- Material properties
|
||||
- Constraint systems (joints, hinges, motors)
|
||||
- Interactive simulations
|
||||
|
||||
### Sharing and Community
|
||||
|
||||
{{sharing_community}}
|
||||
|
||||
**Social features:**
|
||||
|
||||
- Creation sharing (workshop, gallery)
|
||||
- Discoverability (search, trending, featured)
|
||||
- Rating and feedback systems
|
||||
- Collaboration tools
|
||||
- Modding support
|
||||
- User-generated content moderation
|
||||
|
||||
### Constraints and Rules
|
||||
|
||||
{{constraints_rules}}
|
||||
|
||||
**Game design:**
|
||||
|
||||
- Creative mode (unlimited resources, no objectives)
|
||||
- Challenge mode (limited resources, objectives)
|
||||
- Budget/point systems (if competitive)
|
||||
- Build limits (size, complexity)
|
||||
- Rulesets and game modes
|
||||
- Victory conditions (if applicable)
|
||||
|
||||
### Tools and Editing
|
||||
|
||||
{{tools_editing}}
|
||||
|
||||
**Advanced features:**
|
||||
|
||||
- Logic gates/scripting (if applicable)
|
||||
- Animation tools
|
||||
- Terrain editing
|
||||
- Weather/environment controls
|
||||
- Lighting and effects
|
||||
- Testing/preview modes
|
||||
|
||||
### Emergent Gameplay
|
||||
|
||||
{{emergent_gameplay}}
|
||||
|
||||
**Player creativity:**
|
||||
|
||||
- Unintended creations (embracing exploits)
|
||||
- Community-defined challenges
|
||||
- Speedrunning player creations
|
||||
- Cross-creation interaction
|
||||
- Viral moments and showcases
|
||||
- Evolution of the meta
|
||||
@@ -0,0 +1,62 @@
|
||||
## Shooter Specific Elements
|
||||
|
||||
### Weapon Systems
|
||||
|
||||
{{weapon_systems}}
|
||||
|
||||
**Weapon design:**
|
||||
|
||||
- Weapon types (pistol, rifle, shotgun, sniper, explosive, etc.)
|
||||
- Weapon stats (damage, fire rate, accuracy, reload time, ammo capacity)
|
||||
- Weapon progression (starting weapons, unlocks, upgrades)
|
||||
- Weapon feel (recoil patterns, sound design, impact feedback)
|
||||
- Balance considerations (risk/reward, situational use)
|
||||
|
||||
### Aiming and Combat Mechanics
|
||||
|
||||
{{aiming_combat}}
|
||||
|
||||
**Combat systems:**
|
||||
|
||||
- Aiming system (first-person, third-person, twin-stick, lock-on)
|
||||
- Hit detection (hitscan vs. projectile)
|
||||
- Accuracy mechanics (spread, recoil, movement penalties)
|
||||
- Critical hits / weak points
|
||||
- Melee integration (if applicable)
|
||||
|
||||
### Enemy Design and AI
|
||||
|
||||
{{enemy_ai}}
|
||||
|
||||
**Enemy systems:**
|
||||
|
||||
- Enemy types (fodder, elite, tank, ranged, melee, boss)
|
||||
- AI behavior patterns (aggressive, defensive, flanking, cover use)
|
||||
- Spawn systems (waves, triggers, procedural)
|
||||
- Difficulty scaling (health, damage, AI sophistication)
|
||||
- Enemy tells and telegraphing
|
||||
|
||||
### Arena and Level Design
|
||||
|
||||
{{arena_level_design}}
|
||||
|
||||
**Level structure:**
|
||||
|
||||
- Arena flow (choke points, open spaces, verticality)
|
||||
- Cover system design (destructible, dynamic, static)
|
||||
- Spawn points and safe zones
|
||||
- Power-up placement
|
||||
- Environmental hazards
|
||||
- Sightlines and engagement distances
|
||||
|
||||
### Multiplayer Considerations
|
||||
|
||||
{{multiplayer}}
|
||||
|
||||
**Multiplayer systems (if applicable):**
|
||||
|
||||
- Game modes (deathmatch, team deathmatch, objective-based, etc.)
|
||||
- Map design for PvP
|
||||
- Loadout systems
|
||||
- Matchmaking and ranking
|
||||
- Balance considerations (skill ceiling, counter-play)
|
||||
@@ -0,0 +1,73 @@
|
||||
## Simulation Specific Elements
|
||||
|
||||
### Core Simulation Systems
|
||||
|
||||
{{simulation_systems}}
|
||||
|
||||
**What's being simulated:**
|
||||
|
||||
- Primary simulation focus (city, farm, business, ecosystem, etc.)
|
||||
- Simulation depth (abstract vs. realistic)
|
||||
- System interconnections
|
||||
- Emergent behaviors
|
||||
- Simulation tickrate and performance
|
||||
|
||||
### Management Mechanics
|
||||
|
||||
{{management_mechanics}}
|
||||
|
||||
**Management systems:**
|
||||
|
||||
- Resource management (budget, materials, time)
|
||||
- Decision-making mechanics
|
||||
- Automation vs. manual control
|
||||
- Delegation systems (if applicable)
|
||||
- Efficiency optimization
|
||||
|
||||
### Building and Construction
|
||||
|
||||
{{building_construction}}
|
||||
|
||||
**Construction systems:**
|
||||
|
||||
- Placeable objects/structures
|
||||
- Grid system (free placement, snap-to-grid, tiles)
|
||||
- Building prerequisites and unlocks
|
||||
- Upgrade/demolition mechanics
|
||||
- Space constraints and planning
|
||||
|
||||
### Economic and Resource Loops
|
||||
|
||||
{{economic_loops}}
|
||||
|
||||
**Economic design:**
|
||||
|
||||
- Income sources
|
||||
- Expenses and maintenance
|
||||
- Supply chains (if applicable)
|
||||
- Market dynamics
|
||||
- Economic balance and pacing
|
||||
|
||||
### Progression and Unlocks
|
||||
|
||||
{{progression_unlocks}}
|
||||
|
||||
**Progression systems:**
|
||||
|
||||
- Unlock conditions (achievements, milestones, levels)
|
||||
- Tech/research tree
|
||||
- New mechanics/features over time
|
||||
- Difficulty scaling
|
||||
- Endgame content
|
||||
|
||||
### Sandbox vs. Scenario
|
||||
|
||||
{{sandbox_scenario}}
|
||||
|
||||
**Game modes:**
|
||||
|
||||
- Sandbox mode (unlimited resources, creative freedom)
|
||||
- Scenario/campaign mode (specific goals, constraints)
|
||||
- Challenge modes
|
||||
- Random/procedural scenarios
|
||||
- Custom scenario creation
|
||||
75
src/modules/bmgd/workflows/2-design/gdd/game-types/sports.md
Normal file
75
src/modules/bmgd/workflows/2-design/gdd/game-types/sports.md
Normal file
@@ -0,0 +1,75 @@
|
||||
## Sports Game Specific Elements
|
||||
|
||||
### Sport-Specific Rules
|
||||
|
||||
{{sport_rules}}
|
||||
|
||||
**Rule implementation:**
|
||||
|
||||
- Core sport rules (scoring, fouls, violations)
|
||||
- Match/game structure (quarters, periods, innings, etc.)
|
||||
- Referee/umpire system
|
||||
- Rule variations (if applicable)
|
||||
- Simulation vs. arcade rule adherence
|
||||
|
||||
### Team and Player Systems
|
||||
|
||||
{{team_player}}
|
||||
|
||||
**Roster design:**
|
||||
|
||||
- Player attributes (speed, strength, skill, etc.)
|
||||
- Position-specific stats
|
||||
- Team composition
|
||||
- Substitution mechanics
|
||||
- Stamina/fatigue system
|
||||
- Injury system (if applicable)
|
||||
|
||||
### Match Structure
|
||||
|
||||
{{match_structure}}
|
||||
|
||||
**Game flow:**
|
||||
|
||||
- Pre-match setup (lineups, strategies)
|
||||
- In-match actions (plays, tactics, timeouts)
|
||||
- Half-time/intermission
|
||||
- Overtime/extra time rules
|
||||
- Post-match results and stats
|
||||
|
||||
### Physics and Realism
|
||||
|
||||
{{physics_realism}}
|
||||
|
||||
**Simulation balance:**
|
||||
|
||||
- Physics accuracy (ball/puck physics, player movement)
|
||||
- Realism vs. fun tradeoffs
|
||||
- Animation systems
|
||||
- Collision detection
|
||||
- Weather/field condition effects
|
||||
|
||||
### Career and Season Modes
|
||||
|
||||
{{career_season}}
|
||||
|
||||
**Long-term modes:**
|
||||
|
||||
- Career mode structure
|
||||
- Season/tournament progression
|
||||
- Transfer/draft systems
|
||||
- Team management
|
||||
- Contract negotiations
|
||||
- Sponsor/financial systems
|
||||
|
||||
### Multiplayer Modes
|
||||
|
||||
{{multiplayer}}
|
||||
|
||||
**Competitive play:**
|
||||
|
||||
- Local multiplayer (couch co-op)
|
||||
- Online multiplayer
|
||||
- Ranked/casual modes
|
||||
- Ultimate team/card collection (if applicable)
|
||||
- Co-op vs. AI
|
||||
@@ -0,0 +1,71 @@
|
||||
## Strategy Specific Elements
|
||||
|
||||
### Resource Systems
|
||||
|
||||
{{resource_systems}}
|
||||
|
||||
**Resource management:**
|
||||
|
||||
- Resource types (gold, food, energy, population, etc.)
|
||||
- Gathering mechanics (auto-generate, harvesting, capturing)
|
||||
- Resource spending (units, buildings, research, upgrades)
|
||||
- Economic balance (income vs. expenses)
|
||||
- Scarcity and strategic choices
|
||||
|
||||
### Unit Types and Stats
|
||||
|
||||
{{unit_types}}
|
||||
|
||||
**Unit design:**
|
||||
|
||||
- Unit roster (basic, advanced, specialized, hero units)
|
||||
- Unit stats (health, attack, defense, speed, range)
|
||||
- Unit abilities (active, passive, unique)
|
||||
- Counter systems (rock-paper-scissors dynamics)
|
||||
- Unit production (cost, build time, prerequisites)
|
||||
|
||||
### Technology and Progression
|
||||
|
||||
{{tech_progression}}
|
||||
|
||||
**Progression systems:**
|
||||
|
||||
- Tech tree structure (linear, branching, era-based)
|
||||
- Research mechanics (time, cost, prerequisites)
|
||||
- Upgrade paths (unit upgrades, building improvements)
|
||||
- Unlock conditions (progression gates, achievements)
|
||||
|
||||
### Map and Terrain
|
||||
|
||||
{{map_terrain}}
|
||||
|
||||
**Strategic space:**
|
||||
|
||||
- Map size and structure (small/medium/large, symmetric/asymmetric)
|
||||
- Terrain types (passable, impassable, elevated, water)
|
||||
- Terrain effects (movement, combat bonuses, vision)
|
||||
- Strategic points (resources, objectives, choke points)
|
||||
- Fog of war / vision system
|
||||
|
||||
### AI Opponent
|
||||
|
||||
{{ai_opponent}}
|
||||
|
||||
**AI design:**
|
||||
|
||||
- AI difficulty levels (easy, medium, hard, expert)
|
||||
- AI behavior patterns (aggressive, defensive, economic, adaptive)
|
||||
- AI cheating considerations (fair vs. challenge-focused)
|
||||
- AI personality types (if multiple opponents)
|
||||
|
||||
### Victory Conditions
|
||||
|
||||
{{victory_conditions}}
|
||||
|
||||
**Win/loss design:**
|
||||
|
||||
- Victory types (domination, economic, technological, diplomatic, etc.)
|
||||
- Time limits (if applicable)
|
||||
- Score systems (if applicable)
|
||||
- Defeat conditions
|
||||
- Early surrender / concession mechanics
|
||||
@@ -0,0 +1,79 @@
|
||||
## Survival Game Specific Elements
|
||||
|
||||
### Resource Gathering and Crafting
|
||||
|
||||
{{resource_crafting}}
|
||||
|
||||
**Resource systems:**
|
||||
|
||||
- Resource types (wood, stone, food, water, etc.)
|
||||
- Gathering methods (mining, foraging, hunting, looting)
|
||||
- Crafting recipes and trees
|
||||
- Tool/weapon crafting
|
||||
- Durability and repair
|
||||
- Storage and inventory management
|
||||
|
||||
### Survival Needs
|
||||
|
||||
{{survival_needs}}
|
||||
|
||||
**Player vitals:**
|
||||
|
||||
- Hunger/thirst systems
|
||||
- Health and healing
|
||||
- Temperature/exposure
|
||||
- Sleep/rest (if applicable)
|
||||
- Sanity/morale (if applicable)
|
||||
- Status effects (poison, disease, etc.)
|
||||
|
||||
### Environmental Threats
|
||||
|
||||
{{environmental_threats}}
|
||||
|
||||
**Danger systems:**
|
||||
|
||||
- Wildlife (predators, hostile creatures)
|
||||
- Environmental hazards (weather, terrain)
|
||||
- Day/night cycle threats
|
||||
- Seasonal changes (if applicable)
|
||||
- Natural disasters
|
||||
- Dynamic threat scaling
|
||||
|
||||
### Base Building
|
||||
|
||||
{{base_building}}
|
||||
|
||||
**Construction systems:**
|
||||
|
||||
- Building materials and recipes
|
||||
- Structure types (shelter, storage, defenses)
|
||||
- Base location and planning
|
||||
- Upgrade paths
|
||||
- Defensive structures
|
||||
- Automation (if applicable)
|
||||
|
||||
### Progression and Technology
|
||||
|
||||
{{progression_tech}}
|
||||
|
||||
**Advancement:**
|
||||
|
||||
- Tech tree or skill progression
|
||||
- Tool/weapon tiers
|
||||
- Unlock conditions
|
||||
- New biomes/areas access
|
||||
- Endgame objectives (if applicable)
|
||||
- Prestige/restart mechanics (if applicable)
|
||||
|
||||
### World Structure
|
||||
|
||||
{{world_structure}}
|
||||
|
||||
**Map design:**
|
||||
|
||||
- World size and boundaries
|
||||
- Biome diversity
|
||||
- Procedural vs. handcrafted
|
||||
- Points of interest
|
||||
- Risk/reward zones
|
||||
- Fast travel or navigation systems
|
||||
@@ -0,0 +1,91 @@
|
||||
## Text-Based Game Specific Elements
|
||||
|
||||
<narrative-workflow-critical>
|
||||
This game type is **narrative-critical**. You MUST run the Narrative Design workflow after completing the GDD to create:
|
||||
- Complete story and all narrative paths
|
||||
- Room descriptions and atmosphere
|
||||
- Puzzle solutions and hints
|
||||
- Character dialogue
|
||||
- World lore and backstory
|
||||
- Parser vocabulary (if parser-based)
|
||||
</narrative-workflow-critical>
|
||||
|
||||
### Input System
|
||||
|
||||
{{input_system}}
|
||||
|
||||
**Core interface:**
|
||||
|
||||
- Parser-based (natural language commands)
|
||||
- Choice-based (numbered/lettered options)
|
||||
- Hybrid system
|
||||
- Command vocabulary depth
|
||||
- Synonyms and flexibility
|
||||
- Error messaging and hints
|
||||
|
||||
### Room/Location Structure
|
||||
|
||||
{{location_structure}}
|
||||
|
||||
**World design:**
|
||||
|
||||
- Room count and scope
|
||||
- Room descriptions (length, detail)
|
||||
- Connection types (doors, paths, obstacles)
|
||||
- Map structure (linear, branching, maze-like, open)
|
||||
- Landmarks and navigation aids
|
||||
- Fast travel or mapping system
|
||||
|
||||
### Item and Inventory System
|
||||
|
||||
{{item_inventory}}
|
||||
|
||||
**Object interaction:**
|
||||
|
||||
- Examinable objects
|
||||
- Takeable vs. scenery objects
|
||||
- Item use and combinations
|
||||
- Inventory management
|
||||
- Object descriptions
|
||||
- Hidden objects and clues
|
||||
|
||||
### Puzzle Design
|
||||
|
||||
{{puzzle_design}}
|
||||
|
||||
**Challenge structure:**
|
||||
|
||||
- Puzzle types (logic, inventory, knowledge, exploration)
|
||||
- Difficulty curve
|
||||
- Hint system (gradual reveals)
|
||||
- Red herrings vs. crucial clues
|
||||
- Puzzle integration with story
|
||||
- Non-linear puzzle solving
|
||||
|
||||
### Narrative and Writing
|
||||
|
||||
{{narrative_writing}}
|
||||
|
||||
**Story delivery:**
|
||||
|
||||
- Writing tone and style
|
||||
- Descriptive density
|
||||
- Character voice
|
||||
- Dialogue systems
|
||||
- Branching narrative (if applicable)
|
||||
- Multiple endings (if applicable)
|
||||
|
||||
**Note:** All narrative content must be written in the Narrative Design Document.
|
||||
|
||||
### Game Flow and Pacing
|
||||
|
||||
{{game_flow}}
|
||||
|
||||
**Structure:**
|
||||
|
||||
- Game length target
|
||||
- Acts or chapters
|
||||
- Save system
|
||||
- Undo/rewind mechanics
|
||||
- Walkthrough or hint accessibility
|
||||
- Replayability considerations
|
||||
@@ -0,0 +1,79 @@
|
||||
## Tower Defense Specific Elements
|
||||
|
||||
### Tower Types and Upgrades
|
||||
|
||||
{{tower_types}}
|
||||
|
||||
**Tower design:**
|
||||
|
||||
- Tower categories (damage, slow, splash, support, special)
|
||||
- Tower stats (damage, range, fire rate, cost)
|
||||
- Upgrade paths (linear, branching)
|
||||
- Tower synergies
|
||||
- Tier progression
|
||||
- Special abilities and targeting
|
||||
|
||||
### Enemy Wave Design
|
||||
|
||||
{{wave_design}}
|
||||
|
||||
**Enemy systems:**
|
||||
|
||||
- Enemy types (fast, tank, flying, immune, boss)
|
||||
- Wave composition
|
||||
- Wave difficulty scaling
|
||||
- Wave scheduling and pacing
|
||||
- Boss encounters
|
||||
- Endless mode scaling (if applicable)
|
||||
|
||||
### Path and Placement Strategy
|
||||
|
||||
{{path_placement}}
|
||||
|
||||
**Strategic space:**
|
||||
|
||||
- Path structure (fixed, custom, maze-building)
|
||||
- Placement restrictions (grid, free placement)
|
||||
- Terrain types (buildable, non-buildable, special)
|
||||
- Choke points and strategic locations
|
||||
- Multiple paths (if applicable)
|
||||
- Line of sight and range visualization
|
||||
|
||||
### Economy and Resources
|
||||
|
||||
{{economy}}
|
||||
|
||||
**Resource management:**
|
||||
|
||||
- Starting resources
|
||||
- Resource generation (per wave, per kill, passive)
|
||||
- Resource spending (towers, upgrades, abilities)
|
||||
- Selling/refund mechanics
|
||||
- Special currencies (if applicable)
|
||||
- Economic optimization strategies
|
||||
|
||||
### Abilities and Powers
|
||||
|
||||
{{abilities_powers}}
|
||||
|
||||
**Active mechanics:**
|
||||
|
||||
- Player-activated abilities (airstrikes, freezes, etc.)
|
||||
- Cooldown systems
|
||||
- Ability unlocks
|
||||
- Ability upgrade paths
|
||||
- Strategic timing
|
||||
- Resource cost vs. cooldown
|
||||
|
||||
### Difficulty and Replayability
|
||||
|
||||
{{difficulty_replay}}
|
||||
|
||||
**Challenge systems:**
|
||||
|
||||
- Difficulty levels
|
||||
- Mission objectives (perfect clear, no lives lost, etc.)
|
||||
- Star ratings
|
||||
- Challenge modifiers
|
||||
- Randomized elements
|
||||
- New Game+ or prestige modes
|
||||
@@ -0,0 +1,88 @@
|
||||
## Turn-Based Tactics Specific Elements
|
||||
|
||||
<narrative-workflow-recommended>
|
||||
This game type is **narrative-moderate to heavy**. Consider running the Narrative Design workflow after completing the GDD to create:
|
||||
- Campaign story and mission briefings
|
||||
- Character backstories and development
|
||||
- Faction lore and motivations
|
||||
- Mission narratives
|
||||
</narrative-workflow-recommended>
|
||||
|
||||
### Grid System and Movement
|
||||
|
||||
{{grid_movement}}
|
||||
|
||||
**Spatial design:**
|
||||
|
||||
- Grid type (square, hex, free-form)
|
||||
- Movement range calculation
|
||||
- Movement types (walk, fly, teleport)
|
||||
- Terrain movement costs
|
||||
- Zone of control
|
||||
- Pathfinding visualization
|
||||
|
||||
### Unit Types and Classes
|
||||
|
||||
{{unit_classes}}
|
||||
|
||||
**Unit design:**
|
||||
|
||||
- Class roster (warrior, archer, mage, healer, etc.)
|
||||
- Class abilities and specializations
|
||||
- Unit progression (leveling, promotions)
|
||||
- Unit customization
|
||||
- Unique units (heroes, named characters)
|
||||
- Class balance and counters
|
||||
|
||||
### Action Economy
|
||||
|
||||
{{action_economy}}
|
||||
|
||||
**Turn structure:**
|
||||
|
||||
- Action points system (fixed, variable, pooled)
|
||||
- Action types (move, attack, ability, item, wait)
|
||||
- Free actions vs. costing actions
|
||||
- Opportunity attacks
|
||||
- Turn order (initiative, simultaneous, alternating)
|
||||
- Time limits per turn (if applicable)
|
||||
|
||||
### Positioning and Tactics
|
||||
|
||||
{{positioning_tactics}}
|
||||
|
||||
**Strategic depth:**
|
||||
|
||||
- Flanking mechanics
|
||||
- High ground advantage
|
||||
- Cover system
|
||||
- Formation bonuses
|
||||
- Area denial
|
||||
- Chokepoint tactics
|
||||
- Line of sight and vision
|
||||
|
||||
### Terrain and Environmental Effects
|
||||
|
||||
{{terrain_effects}}
|
||||
|
||||
**Map design:**
|
||||
|
||||
- Terrain types (grass, water, lava, ice, etc.)
|
||||
- Terrain effects (defense bonus, movement penalty, damage)
|
||||
- Destructible terrain
|
||||
- Interactive objects
|
||||
- Weather effects
|
||||
- Elevation and verticality
|
||||
|
||||
### Campaign Structure
|
||||
|
||||
{{campaign}}
|
||||
|
||||
**Mission design:**
|
||||
|
||||
- Campaign length and pacing
|
||||
- Mission variety (defeat all, survive, escort, capture, etc.)
|
||||
- Optional objectives
|
||||
- Branching campaigns
|
||||
- Permadeath vs. casualty systems
|
||||
- Resource management between missions
|
||||
@@ -0,0 +1,89 @@
|
||||
## Visual Novel Specific Elements
|
||||
|
||||
<narrative-workflow-critical>
|
||||
This game type is **narrative-critical**. You MUST run the Narrative Design workflow after completing the GDD to create:
|
||||
- Complete story structure and script
|
||||
- All character profiles and development arcs
|
||||
- Branching story flowcharts
|
||||
- Scene-by-scene breakdown
|
||||
- Dialogue drafts
|
||||
- Multiple route planning
|
||||
</narrative-workflow-critical>
|
||||
|
||||
### Branching Story Structure
|
||||
|
||||
{{branching_structure}}
|
||||
|
||||
**Narrative design:**
|
||||
|
||||
- Story route types (character routes, plot branches)
|
||||
- Branch points (choices, stats, flags)
|
||||
- Convergence points
|
||||
- Route length and pacing
|
||||
- True/golden ending requirements
|
||||
- Branch complexity (simple, moderate, complex)
|
||||
|
||||
### Choice Impact System
|
||||
|
||||
{{choice_impact}}
|
||||
|
||||
**Decision mechanics:**
|
||||
|
||||
- Choice types (immediate, delayed, hidden)
|
||||
- Choice visualization (explicit, subtle, invisible)
|
||||
- Point systems (affection, alignment, stats)
|
||||
- Flag tracking
|
||||
- Choice consequences
|
||||
- Meaningful vs. cosmetic choices
|
||||
|
||||
### Route Design
|
||||
|
||||
{{route_design}}
|
||||
|
||||
**Route structure:**
|
||||
|
||||
- Common route (shared beginning)
|
||||
- Individual routes (character-specific paths)
|
||||
- Route unlock conditions
|
||||
- Route length balance
|
||||
- Route independence vs. interconnection
|
||||
- Recommended play order
|
||||
|
||||
### Character Relationship Systems
|
||||
|
||||
{{relationship_systems}}
|
||||
|
||||
**Character mechanics:**
|
||||
|
||||
- Affection/friendship points
|
||||
- Relationship milestones
|
||||
- Character-specific scenes
|
||||
- Dialogue variations based on relationship
|
||||
- Multiple romance options (if applicable)
|
||||
- Platonic vs. romantic paths
|
||||
|
||||
### Save/Load and Flowchart
|
||||
|
||||
{{save_flowchart}}
|
||||
|
||||
**Player navigation:**
|
||||
|
||||
- Save point frequency
|
||||
- Quick save/load
|
||||
- Scene skip functionality
|
||||
- Flowchart/scene select (after completion)
|
||||
- Branch tracking visualization
|
||||
- Completion percentage
|
||||
|
||||
### Art Asset Requirements
|
||||
|
||||
{{art_assets}}
|
||||
|
||||
**Visual content:**
|
||||
|
||||
- Character sprites (poses, expressions)
|
||||
- Background art (locations, times of day)
|
||||
- CG artwork (key moments, endings)
|
||||
- UI elements
|
||||
- Special effects
|
||||
- Asset quantity estimates
|
||||
153
src/modules/bmgd/workflows/2-design/gdd/gdd-template.md
Normal file
153
src/modules/bmgd/workflows/2-design/gdd/gdd-template.md
Normal file
@@ -0,0 +1,153 @@
|
||||
# {{game_name}} - Game Design Document
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Game Type:** {{game_type}}
|
||||
**Target Platform(s):** {{platforms}}
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
### Core Concept
|
||||
|
||||
{{description}}
|
||||
|
||||
### Target Audience
|
||||
|
||||
{{target_audience}}
|
||||
|
||||
### Unique Selling Points (USPs)
|
||||
|
||||
{{unique_selling_points}}
|
||||
|
||||
---
|
||||
|
||||
## Goals and Context
|
||||
|
||||
### Project Goals
|
||||
|
||||
{{goals}}
|
||||
|
||||
### Background and Rationale
|
||||
|
||||
{{context}}
|
||||
|
||||
---
|
||||
|
||||
## Core Gameplay
|
||||
|
||||
### Game Pillars
|
||||
|
||||
{{game_pillars}}
|
||||
|
||||
### Core Gameplay Loop
|
||||
|
||||
{{gameplay_loop}}
|
||||
|
||||
### Win/Loss Conditions
|
||||
|
||||
{{win_loss_conditions}}
|
||||
|
||||
---
|
||||
|
||||
## Game Mechanics
|
||||
|
||||
### Primary Mechanics
|
||||
|
||||
{{primary_mechanics}}
|
||||
|
||||
### Controls and Input
|
||||
|
||||
{{controls}}
|
||||
|
||||
---
|
||||
|
||||
{{GAME_TYPE_SPECIFIC_SECTIONS}}
|
||||
|
||||
---
|
||||
|
||||
## Progression and Balance
|
||||
|
||||
### Player Progression
|
||||
|
||||
{{player_progression}}
|
||||
|
||||
### Difficulty Curve
|
||||
|
||||
{{difficulty_curve}}
|
||||
|
||||
### Economy and Resources
|
||||
|
||||
{{economy_resources}}
|
||||
|
||||
---
|
||||
|
||||
## Level Design Framework
|
||||
|
||||
### Level Types
|
||||
|
||||
{{level_types}}
|
||||
|
||||
### Level Progression
|
||||
|
||||
{{level_progression}}
|
||||
|
||||
---
|
||||
|
||||
## Art and Audio Direction
|
||||
|
||||
### Art Style
|
||||
|
||||
{{art_style}}
|
||||
|
||||
### Audio and Music
|
||||
|
||||
{{audio_music}}
|
||||
|
||||
---
|
||||
|
||||
## Technical Specifications
|
||||
|
||||
### Performance Requirements
|
||||
|
||||
{{performance_requirements}}
|
||||
|
||||
### Platform-Specific Details
|
||||
|
||||
{{platform_details}}
|
||||
|
||||
### Asset Requirements
|
||||
|
||||
{{asset_requirements}}
|
||||
|
||||
---
|
||||
|
||||
## Development Epics
|
||||
|
||||
### Epic Structure
|
||||
|
||||
{{epics}}
|
||||
|
||||
---
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Technical Metrics
|
||||
|
||||
{{technical_metrics}}
|
||||
|
||||
### Gameplay Metrics
|
||||
|
||||
{{gameplay_metrics}}
|
||||
|
||||
---
|
||||
|
||||
## Out of Scope
|
||||
|
||||
{{out_of_scope}}
|
||||
|
||||
---
|
||||
|
||||
## Assumptions and Dependencies
|
||||
|
||||
{{assumptions_and_dependencies}}
|
||||
506
src/modules/bmgd/workflows/2-design/gdd/instructions-gdd.md
Normal file
506
src/modules/bmgd/workflows/2-design/gdd/instructions-gdd.md
Normal file
@@ -0,0 +1,506 @@
|
||||
# GDD Workflow - Game Projects (All Levels)
|
||||
|
||||
<workflow>
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>This is the GDD instruction set for GAME projects - replaces PRD with Game Design Document</critical>
|
||||
<critical>Project analysis already completed - proceeding with game-specific design</critical>
|
||||
<critical>Uses gdd_template for GDD output, game_types.csv for type-specific sections</critical>
|
||||
<critical>Routes to 3-solutioning for architecture (platform-specific decisions handled there)</critical>
|
||||
<critical>If users mention technical details, append to technical_preferences with timestamp</critical>
|
||||
|
||||
<critical>DOCUMENT OUTPUT: Concise, clear, actionable game design specs. Use tables/lists over prose. User skill level ({user_skill_level}) affects conversation style ONLY, not document content.</critical>
|
||||
|
||||
## Input Document Discovery
|
||||
|
||||
This workflow requires: game brief, and may reference market research or brownfield project documentation.
|
||||
|
||||
**Discovery Process** (execute for each referenced document):
|
||||
|
||||
1. **Search for whole document first** - Use fuzzy file matching to find the complete document
|
||||
2. **Check for sharded version** - If whole document not found, look for `{doc-name}/index.md`
|
||||
3. **If sharded version found**:
|
||||
- Read `index.md` to understand the document structure
|
||||
- Read ALL section files listed in the index
|
||||
- Treat the combined content as if it were a single document
|
||||
4. **Brownfield projects**: The `document-project` workflow always creates `{output_folder}/docs/index.md`
|
||||
|
||||
**Priority**: If both whole and sharded versions exist, use the whole document.
|
||||
|
||||
**Fuzzy matching**: Be flexible with document names - users may use variations in naming conventions.
|
||||
|
||||
<step n="0" goal="Validate workflow and extract project configuration">
|
||||
|
||||
<invoke-workflow path="{project-root}/bmad/bmm/workflows/workflow-status">
|
||||
<param>mode: data</param>
|
||||
<param>data_request: project_config</param>
|
||||
</invoke-workflow>
|
||||
|
||||
<check if="status_exists == false">
|
||||
<output>**Note: No Workflow Status File Found**
|
||||
|
||||
The GDD workflow can run standalone or as part of the BMM workflow path.
|
||||
|
||||
**Recommended:** Run `workflow-init` first for:
|
||||
|
||||
- Project context tracking
|
||||
- Workflow sequencing guidance
|
||||
- Progress monitoring across workflows
|
||||
|
||||
**Or continue standalone** without progress tracking.
|
||||
</output>
|
||||
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
||||
<check if="continue">
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
<check if="exit">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="status_exists == true">
|
||||
<action>Store {{status_file_path}} for later updates</action>
|
||||
|
||||
<check if="project_type != 'game'">
|
||||
<output>**Incorrect Workflow for Software Projects**
|
||||
|
||||
Your project is type: {{project_type}}
|
||||
|
||||
**Correct workflows for software projects:**
|
||||
|
||||
- Level 0-1: `tech-spec` (Architect agent)
|
||||
- Level 2-4: `prd` (PM agent)
|
||||
|
||||
{{#if project_level <= 1}}
|
||||
Use: `tech-spec`
|
||||
{{else}}
|
||||
Use: `prd`
|
||||
{{/if}}
|
||||
</output>
|
||||
<action>Exit and redirect to appropriate workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="0.5" goal="Validate workflow sequencing" tag="workflow-status">
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Check status of "gdd" workflow in loaded status file</action>
|
||||
|
||||
<check if="gdd status is file path (already completed)">
|
||||
<output>⚠️ GDD already completed: {{gdd status}}</output>
|
||||
<ask>Re-running will overwrite the existing GDD. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="gdd is not the next expected workflow (latter items are completed already in the list)">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. GDD is out of sequence.</output>
|
||||
<ask>Continue with GDD anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Load context and determine game type">
|
||||
|
||||
<action>Use {{project_type}} and {{project_level}} from status data</action>
|
||||
|
||||
<check if="continuation_mode == true">
|
||||
<action>Load existing GDD.md and check completion status</action>
|
||||
<ask>Found existing work. Would you like to:
|
||||
1. Review what's done and continue
|
||||
2. Modify existing sections
|
||||
3. Start fresh
|
||||
</ask>
|
||||
<action>If continuing, skip to first incomplete section</action>
|
||||
</check>
|
||||
|
||||
<action if="new or starting fresh">Check or existing game-brief in output_folder</action>
|
||||
|
||||
<check if="game-brief exists">
|
||||
<ask>Found existing game brief! Would you like to:
|
||||
|
||||
1. Use it as input (recommended - I'll extract key info)
|
||||
2. Ignore it and start fresh
|
||||
</ask>
|
||||
</check>
|
||||
|
||||
<check if="using game-brief">
|
||||
<action>Load and analyze game-brief document</action>
|
||||
<action>Extract: game_name, core_concept, target_audience, platforms, game_pillars, primary_mechanics</action>
|
||||
<action>Pre-fill relevant GDD sections with game-brief content</action>
|
||||
<action>Note which sections were pre-filled from brief</action>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="no game-brief was loaded">
|
||||
<ask>Describe your game. What is it about? What does the player do? What is the Genre or type?</ask>
|
||||
|
||||
<action>Analyze description to determine game type</action>
|
||||
<action>Map to closest game_types.csv id or use "custom"</action>
|
||||
</check>
|
||||
|
||||
<check if="else (game-brief was loaded)">
|
||||
<action>Use game concept from brief to determine game type</action>
|
||||
|
||||
<ask optional="true">
|
||||
I've identified this as a **{{game_type}}** game. Is that correct?
|
||||
If not, briefly describe what type it should be:
|
||||
</ask>
|
||||
|
||||
<action>Map selection to game_types.csv id</action>
|
||||
<action>Load corresponding fragment file from game-types/ folder</action>
|
||||
<action>Store game_type for later injection</action>
|
||||
|
||||
<action>Load gdd_template from workflow.yaml</action>
|
||||
|
||||
Get core game concept and vision.
|
||||
|
||||
<template-output>description</template-output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Define platforms and target audience">
|
||||
|
||||
<action>Guide user to specify target platform(s) for their game, exploring considerations like desktop, mobile, web, console, or multi-platform deployment</action>
|
||||
|
||||
<template-output>platforms</template-output>
|
||||
|
||||
<action>Guide user to define their target audience with specific demographics: age range, gaming experience level (casual/core/hardcore), genre familiarity, and preferred play session lengths</action>
|
||||
|
||||
<template-output>target_audience</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Define goals, context, and unique selling points">
|
||||
|
||||
<action>Guide user to define project goals appropriate for their level (Level 0-1: 1-2 goals, Level 2: 2-3 goals, Level 3-4: 3-5 strategic goals) - what success looks like for this game</action>
|
||||
|
||||
<template-output>goals</template-output>
|
||||
|
||||
<action>Guide user to provide context on why this game matters now - the motivation and rationale behind the project</action>
|
||||
|
||||
<template-output>context</template-output>
|
||||
|
||||
<action>Guide user to identify the unique selling points (USPs) - what makes this game different from existing games in the market</action>
|
||||
|
||||
<template-output>unique_selling_points</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Core gameplay definition">
|
||||
|
||||
<critical>These are game-defining decisions</critical>
|
||||
|
||||
<action>Guide user to identify 2-4 core game pillars - the fundamental gameplay elements that define their game's experience (e.g., tight controls + challenging combat + rewarding exploration, or strategic depth + replayability + quick sessions)</action>
|
||||
|
||||
<template-output>game_pillars</template-output>
|
||||
|
||||
<action>Guide user to describe the core gameplay loop - what actions the player repeats throughout the game, creating a clear cyclical pattern of player behavior and rewards</action>
|
||||
|
||||
<template-output>gameplay_loop</template-output>
|
||||
|
||||
<action>Guide user to define win and loss conditions - how the player succeeds and fails in the game</action>
|
||||
|
||||
<template-output>win_loss_conditions</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Game mechanics and controls">
|
||||
|
||||
<action>Guide user to define the primary game mechanics that players will interact with throughout the game</action>
|
||||
|
||||
<template-output>primary_mechanics</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<action>Guide user to describe their control scheme and input method (keyboard/mouse, gamepad, touchscreen, etc.), including key bindings or button layouts if known</action>
|
||||
|
||||
<template-output>controls</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Inject game-type-specific sections">
|
||||
|
||||
<action>Load game-type fragment from: {installed_path}/gdd/game-types/{{game_type}}.md</action>
|
||||
|
||||
<critical>Process each section in the fragment template</critical>
|
||||
|
||||
For each {{placeholder}} in the fragment, elicit and capture that information.
|
||||
|
||||
<template-output file="GDD.md">GAME_TYPE_SPECIFIC_SECTIONS</template-output>
|
||||
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Progression and balance">
|
||||
|
||||
<action>Guide user to describe how player progression works in their game - whether through skill improvement, power gains, ability unlocking, narrative advancement, or a combination of approaches</action>
|
||||
|
||||
<template-output>player_progression</template-output>
|
||||
|
||||
<action>Guide user to define the difficulty curve: how challenge increases over time, pacing rhythm (steady/spikes/player-controlled), and any accessibility options planned</action>
|
||||
|
||||
<template-output>difficulty_curve</template-output>
|
||||
|
||||
<action>Ask if the game includes an in-game economy or resource system, and if so, guide user to describe it (skip if not applicable)</action>
|
||||
|
||||
<template-output>economy_resources</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Level design framework">
|
||||
|
||||
<action>Guide user to describe the types of levels/stages in their game (e.g., tutorial, themed biomes, boss arenas, procedural vs. handcrafted, etc.)</action>
|
||||
|
||||
<template-output>level_types</template-output>
|
||||
|
||||
<action>Guide user to explain how levels progress or unlock - whether through linear sequence, hub-based structure, open world exploration, or player-driven choices</action>
|
||||
|
||||
<template-output>level_progression</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Art and audio direction">
|
||||
|
||||
<action>Guide user to describe their art style vision: visual aesthetic (pixel art, low-poly, realistic, stylized), color palette preferences, and any inspirations or references</action>
|
||||
|
||||
<template-output>art_style</template-output>
|
||||
|
||||
<action>Guide user to describe their audio and music direction: music style/genre, sound effect tone, and how important audio is to the gameplay experience</action>
|
||||
|
||||
<template-output>audio_music</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Technical specifications">
|
||||
|
||||
<action>Guide user to define performance requirements: target frame rate, resolution, acceptable load times, and mobile battery considerations if applicable</action>
|
||||
|
||||
<template-output>performance_requirements</template-output>
|
||||
|
||||
<action>Guide user to identify platform-specific considerations (mobile touch controls/screen sizes, PC keyboard/mouse/settings, console controller/certification, web browser compatibility/file size)</action>
|
||||
|
||||
<template-output>platform_details</template-output>
|
||||
|
||||
<action>Guide user to document key asset requirements: art assets (sprites/models/animations), audio assets (music/SFX/voice), estimated counts/sizes, and asset pipeline needs</action>
|
||||
|
||||
<template-output>asset_requirements</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Epic structure">
|
||||
|
||||
<action>Work with user to translate game features into development epics, following level-appropriate guidelines (Level 1: 1 epic/1-10 stories, Level 2: 1-2 epics/5-15 stories, Level 3: 2-5 epics/12-40 stories, Level 4: 5+ epics/40+ stories)</action>
|
||||
|
||||
<template-output>epics</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Generate detailed epic breakdown in epics.md">
|
||||
|
||||
<action>Load epics_template from workflow.yaml</action>
|
||||
|
||||
<critical>Create separate epics.md with full story hierarchy</critical>
|
||||
|
||||
<action>Generate epic overview section with all epics listed</action>
|
||||
|
||||
<template-output file="epics.md">epic_overview</template-output>
|
||||
|
||||
<action>For each epic, generate detailed breakdown with expanded goals, capabilities, and success criteria</action>
|
||||
|
||||
<action>For each epic, generate all stories in user story format with prerequisites, acceptance criteria (3-8 per story), and high-level technical notes</action>
|
||||
|
||||
<for-each epic="epic_list">
|
||||
|
||||
<template-output file="epics.md">epic\_{{epic_number}}\_details</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</for-each>
|
||||
|
||||
</step>
|
||||
<step n="13" goal="Success metrics">
|
||||
|
||||
<action>Guide user to identify technical metrics they'll track (e.g., frame rate consistency, load times, crash rate, memory usage)</action>
|
||||
|
||||
<template-output>technical_metrics</template-output>
|
||||
|
||||
<action>Guide user to identify gameplay metrics they'll track (e.g., player completion rate, session length, difficulty pain points, feature engagement)</action>
|
||||
|
||||
<template-output>gameplay_metrics</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="14" goal="Document out of scope and assumptions">
|
||||
|
||||
<action>Guide user to document what is explicitly out of scope for this game - features, platforms, or content that won't be included in this version</action>
|
||||
|
||||
<template-output>out_of_scope</template-output>
|
||||
|
||||
<action>Guide user to document key assumptions and dependencies - technical assumptions, team capabilities, third-party dependencies, or external factors the project relies on</action>
|
||||
|
||||
<template-output>assumptions_and_dependencies</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="15" goal="Update status and populate story sequence" tag="workflow-status">
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "gdd"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["gdd"] = "{output_folder}/bmm-gdd-{{game_name}}-{{date}}.md"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Parse {epics_output_file} to extract all stories</action>
|
||||
<action>Populate story_sequence section in status file with story IDs</action>
|
||||
<action>Set each story status to "not-started"</action>
|
||||
<output>Loaded {{total_stories}} stories from epics into story sequence.</output>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
<output>Next workflow: {{next_workflow}} ({{next_agent}} agent)</output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="16" goal="Generate solutioning handoff and next steps">
|
||||
|
||||
<action>Check if game-type fragment contained narrative tags indicating narrative importance</action>
|
||||
|
||||
<check if="fragment had <narrative-workflow-critical> or <narrative-workflow-recommended>">
|
||||
<action>Set needs_narrative = true</action>
|
||||
<action>Extract narrative importance level from tag</action>
|
||||
|
||||
## Next Steps for {{game_name}}
|
||||
|
||||
</check>
|
||||
|
||||
<check if="needs_narrative == true">
|
||||
<action>Inform user that their game type benefits from narrative design, presenting the option to create a Narrative Design Document covering story structure, character arcs, world lore, dialogue framework, and environmental storytelling</action>
|
||||
|
||||
<ask>This game type ({{game_type}}) benefits from narrative design.
|
||||
|
||||
Would you like to create a Narrative Design Document now?
|
||||
|
||||
1. Yes, create Narrative Design Document (recommended)
|
||||
2. No, proceed directly to solutioning
|
||||
3. Skip for now, I'll do it later
|
||||
|
||||
Your choice:</ask>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="user selects option 1 or fuzzy indicates wanting to create the narrative design document">
|
||||
<invoke-workflow>{project-root}/bmad/bmm/workflows/2-plan-workflows/narrative/workflow.yaml</invoke-workflow>
|
||||
<action>Pass GDD context to narrative workflow</action>
|
||||
<action>Exit current workflow (narrative will hand off to solutioning when done)</action>
|
||||
|
||||
Since this is a Level {{project_level}} game project, you need solutioning for platform/engine architecture.
|
||||
|
||||
**Start new chat with solutioning workflow and provide:**
|
||||
|
||||
1. This GDD: `{{gdd_output_file}}`
|
||||
2. Project analysis: `{{analysis_file}}`
|
||||
|
||||
**The solutioning workflow will:**
|
||||
|
||||
- Determine game engine/platform (Unity, Godot, Phaser, custom, etc.)
|
||||
- Generate architecture.md with engine-specific decisions
|
||||
- Create per-epic tech specs
|
||||
- Handle platform-specific architecture (from registry.csv game-\* entries)
|
||||
|
||||
## Complete Next Steps Checklist
|
||||
|
||||
<action>Generate comprehensive checklist based on project analysis</action>
|
||||
|
||||
### Phase 1: Architecture and Engine Selection
|
||||
|
||||
- [ ] **Run solutioning workflow** (REQUIRED)
|
||||
- Command: `workflow create-architecture`
|
||||
- Input: GDD.md, bmm-workflow-status.md
|
||||
- Output: architecture.md with engine/platform specifics
|
||||
- Note: Registry.csv will provide engine-specific guidance
|
||||
|
||||
### Phase 2: Prototype and Playtesting
|
||||
|
||||
- [ ] **Create core mechanic prototype**
|
||||
- Validate game feel
|
||||
- Test control responsiveness
|
||||
- Iterate on game pillars
|
||||
|
||||
- [ ] **Playtest early and often**
|
||||
- Internal testing
|
||||
- External playtesting
|
||||
- Feedback integration
|
||||
|
||||
### Phase 3: Asset Production
|
||||
|
||||
- [ ] **Create asset pipeline**
|
||||
- Art style guides
|
||||
- Technical constraints
|
||||
- Asset naming conventions
|
||||
|
||||
- [ ] **Audio integration**
|
||||
- Music composition/licensing
|
||||
- SFX creation
|
||||
- Audio middleware setup
|
||||
|
||||
### Phase 4: Development
|
||||
|
||||
- [ ] **Generate detailed user stories**
|
||||
- Command: `workflow generate-stories`
|
||||
- Input: GDD.md + architecture.md
|
||||
|
||||
- [ ] **Sprint planning**
|
||||
- Vertical slices
|
||||
- Milestone planning
|
||||
- Demo/playable builds
|
||||
|
||||
<ask>**✅ GDD Complete, {user_name}!**
|
||||
|
||||
Next immediate action:
|
||||
|
||||
</check>
|
||||
|
||||
<check if="needs_narrative == true">
|
||||
|
||||
1. Create Narrative Design Document (recommended for {{game_type}})
|
||||
2. Start solutioning workflow (engine/architecture)
|
||||
3. Create prototype build
|
||||
4. Begin asset production planning
|
||||
5. Review GDD with team/stakeholders
|
||||
6. Exit workflow
|
||||
|
||||
</check>
|
||||
|
||||
<check if="else">
|
||||
|
||||
1. Start solutioning workflow (engine/architecture)
|
||||
2. Create prototype build
|
||||
3. Begin asset production planning
|
||||
4. Review GDD with team/stakeholders
|
||||
5. Exit workflow
|
||||
|
||||
Which would you like to proceed with?</ask>
|
||||
</check>
|
||||
|
||||
<check if="user selects narrative option">
|
||||
<invoke-workflow>{project-root}/bmad/bmm/workflows/2-plan-workflows/narrative/workflow.yaml</invoke-workflow>
|
||||
<action>Pass GDD context to narrative workflow</action>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
81
src/modules/bmgd/workflows/2-design/gdd/workflow.yaml
Normal file
81
src/modules/bmgd/workflows/2-design/gdd/workflow.yaml
Normal file
@@ -0,0 +1,81 @@
|
||||
# Game Design Document (GDD) Workflow
|
||||
name: gdd
|
||||
description: "Game Design Document workflow for all game project levels - from small prototypes to full AAA games. Generates comprehensive GDD with game mechanics, systems, progression, and implementation guidance."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
game_dev_experience: "{config_source}:game_dev_experience"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/bmad/bmgd/workflows/2-design/gdd"
|
||||
instructions: "{installed_path}/instructions-gdd.md"
|
||||
template: "{installed_path}/gdd-template.md"
|
||||
game_types_csv: "{installed_path}/game-types.csv"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/GDD.md"
|
||||
|
||||
# Game type references (loaded based on game type selection)
|
||||
game_type_guides: "{installed_path}/game-types/"
|
||||
|
||||
# Recommended input documents
|
||||
recommended_inputs:
|
||||
- game_brief: "{output_folder}/game-brief.md"
|
||||
- narrative_design: "{output_folder}/narrative-design.md"
|
||||
- market_research: "{output_folder}/market-research.md"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
input_file_patterns:
|
||||
game_brief:
|
||||
whole: "{output_folder}/*game-brief*.md"
|
||||
sharded: "{output_folder}/*game-brief*/index.md"
|
||||
|
||||
research:
|
||||
whole: "{output_folder}/*research*.md"
|
||||
sharded: "{output_folder}/*research*/index.md"
|
||||
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle:
|
||||
name: "gdd"
|
||||
description: "Game Design Document workflow for all game project levels - from small prototypes to full AAA games. Generates comprehensive GDD with game mechanics, systems, progression, and implementation guidance."
|
||||
author: "BMad"
|
||||
instructions: "bmad/bmgd/workflows/2-design/gdd/instructions-gdd.md"
|
||||
web_bundle_files:
|
||||
- "bmad/bmgd/workflows/2-design/gdd/instructions-gdd.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/gdd-template.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types.csv"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/action-platformer.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/adventure.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/card-game.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/fighting.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/horror.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/idle-incremental.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/metroidvania.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/moba.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/party-game.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/puzzle.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/racing.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/rhythm.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/roguelike.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/rpg.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/sandbox.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/shooter.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/simulation.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/sports.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/strategy.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/survival.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/text-based.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/tower-defense.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/turn-based-tactics.md"
|
||||
- "bmad/bmgd/workflows/2-design/gdd/game-types/visual-novel.md"
|
||||
139
src/modules/bmgd/workflows/2-design/narrative/checklist.md
Normal file
139
src/modules/bmgd/workflows/2-design/narrative/checklist.md
Normal file
@@ -0,0 +1,139 @@
|
||||
# Narrative Design Workflow Validation Checklist
|
||||
|
||||
**Purpose**: Validate narrative design outputs are complete, cohesive, and ready for implementation.
|
||||
|
||||
**Scope**: Story-driven games and applications (follows GDD workflow)
|
||||
|
||||
**Expected Output**: narrative-design.md
|
||||
|
||||
---
|
||||
|
||||
## 1. Output File Exists
|
||||
|
||||
- [ ] narrative-design.md created in output folder
|
||||
- [ ] GDD.md exists (narrative workflow requires GDD first)
|
||||
- [ ] No unfilled {{template_variables}}
|
||||
|
||||
---
|
||||
|
||||
## 2. Story Foundation
|
||||
|
||||
### Core Elements
|
||||
|
||||
- [ ] **Narrative premise** clearly stated (elevator pitch, 2-3 sentences)
|
||||
- [ ] **Core themes** identified (2-4 meaningful themes)
|
||||
- [ ] **Tone and atmosphere** established
|
||||
- [ ] Premise is compelling and fits game type
|
||||
|
||||
### Story Structure
|
||||
|
||||
- [ ] **Story structure chosen** (3-act, hero's journey, branching, etc.)
|
||||
- [ ] **Acts/sections broken down** with clear progression
|
||||
- [ ] **Major story beats** documented (key moments that drive narrative)
|
||||
- [ ] Structure fits narrative complexity level
|
||||
|
||||
---
|
||||
|
||||
## 3. Characters
|
||||
|
||||
### Protagonist(s)
|
||||
|
||||
- [ ] Background and motivation explained
|
||||
- [ ] Character arc defined (how they change)
|
||||
- [ ] Internal and external conflicts identified
|
||||
|
||||
### Antagonist(s)
|
||||
|
||||
- [ ] Motivation clear (why they oppose protagonist)
|
||||
- [ ] Goals and methods explained
|
||||
- [ ] Not one-dimensional
|
||||
|
||||
### Supporting Cast
|
||||
|
||||
- [ ] Major supporting characters documented
|
||||
- [ ] Each has distinct role in story
|
||||
- [ ] Character relationships mapped
|
||||
|
||||
### Character Arcs
|
||||
|
||||
- [ ] Major characters have starting → transformation → ending states
|
||||
- [ ] Arc progression makes sense
|
||||
|
||||
---
|
||||
|
||||
## 4. World and Lore
|
||||
|
||||
- [ ] **World setting** defined (time, place, world type)
|
||||
- [ ] **World rules** explained (magic, technology, society)
|
||||
- [ ] **History and backstory** documented
|
||||
- [ ] Key locations described with narrative significance
|
||||
|
||||
---
|
||||
|
||||
## 5. Dialogue and Delivery
|
||||
|
||||
### Dialogue Framework
|
||||
|
||||
- [ ] Dialogue style established
|
||||
- [ ] Key conversations identified
|
||||
- [ ] Branching dialogue system described (if applicable)
|
||||
|
||||
### Narrative Delivery
|
||||
|
||||
- [ ] Cutscenes/cinematics approach defined
|
||||
- [ ] In-game storytelling methods explained
|
||||
- [ ] Optional vs. required content distinguished
|
||||
- [ ] Multiple endings documented (if applicable)
|
||||
|
||||
---
|
||||
|
||||
## 6. Gameplay Integration
|
||||
|
||||
- [ ] **Narrative-gameplay harmony** addressed (how story and mechanics connect)
|
||||
- [ ] **Story gates** explained (how narrative controls progression)
|
||||
- [ ] **Player agency** level defined (can player affect story?)
|
||||
- [ ] Integration doesn't fight game design
|
||||
|
||||
---
|
||||
|
||||
## 7. Production Scope
|
||||
|
||||
- [ ] **Writing scope** estimated (word count, scene count, dialogue lines)
|
||||
- [ ] Scope realistic for project level
|
||||
- [ ] Localization considerations noted (if applicable)
|
||||
- [ ] Voice acting plans documented (if applicable)
|
||||
|
||||
---
|
||||
|
||||
## 8. Consistency with GDD
|
||||
|
||||
- [ ] Narrative aligns with GDD game design
|
||||
- [ ] Tone matches GDD art/audio direction
|
||||
- [ ] Story supports game mechanics (doesn't contradict)
|
||||
- [ ] No conflicts between narrative and gameplay
|
||||
|
||||
---
|
||||
|
||||
## 9. Critical Failures (Auto-Fail)
|
||||
|
||||
- [ ] ❌ **No GDD** (narrative workflow requires GDD first)
|
||||
- [ ] ❌ **No character arcs** (protagonist has no development)
|
||||
- [ ] ❌ **No story beats** (major moments not identified)
|
||||
- [ ] ❌ **Contradicts GDD** (narrative fights game design)
|
||||
|
||||
---
|
||||
|
||||
## Validation Notes
|
||||
|
||||
**Document any findings:**
|
||||
|
||||
- Narrative strength: [Compelling / Interesting / Adequate / Weak]
|
||||
- Strengths:
|
||||
- Issues to address:
|
||||
- Recommended actions:
|
||||
|
||||
**Ready for solutioning?** [Yes / No - explain]
|
||||
|
||||
---
|
||||
|
||||
_Adapt based on narrative complexity level (Critical/Heavy/Moderate/Light)._
|
||||
@@ -0,0 +1,608 @@
|
||||
# Narrative Design Workflow
|
||||
|
||||
<workflow>
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project_root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already completed the GDD workflow</critical>
|
||||
<critical>Communicate all responses in {communication_language}</critical>
|
||||
<critical>This workflow creates detailed narrative content for story-driven games</critical>
|
||||
<critical>Uses narrative_template for output</critical>
|
||||
<critical>If users mention gameplay mechanics, note them but keep focus on narrative</critical>
|
||||
<critical>Facilitate good brainstorming techniques throughout with the user, pushing them to come up with much of the narrative you will help weave together. The goal is for the user to feel that they crafted the narrative and story arc unless they push you to do it all or indicate YOLO</critical>
|
||||
|
||||
<step n="0" goal="Check for workflow status" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Narrative workflow is optional - you can continue without status tracking.</output>
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "narrative" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="narrative status is file path (already completed)">
|
||||
<output>⚠️ Narrative Design Document already completed: {{narrative status}}</output>
|
||||
<ask>Re-running will overwrite the existing narrative document. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="narrative is not the next expected workflow (latter items are completed already in the list)">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Narrative is out of sequence.</output>
|
||||
<ask>Continue with Narrative Design anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Load GDD context and assess narrative complexity">
|
||||
|
||||
<action>Load GDD.md from {output_folder}</action>
|
||||
<action>Extract game_type, game_name, and any narrative mentions</action>
|
||||
|
||||
<ask>What level of narrative complexity does your game have?
|
||||
|
||||
**Narrative Complexity:**
|
||||
|
||||
1. **Critical** - Story IS the game (Visual Novel, Text-Based Adventure)
|
||||
2. **Heavy** - Story drives the experience (Story-driven RPG, Narrative Adventure)
|
||||
3. **Moderate** - Story enhances gameplay (Metroidvania, Tactics RPG, Horror)
|
||||
4. **Light** - Story provides context (most other genres)
|
||||
|
||||
Your game type ({{game_type}}) suggests **{{suggested_complexity}}**. Confirm or adjust:</ask>
|
||||
|
||||
<action>Set narrative_complexity</action>
|
||||
|
||||
<check if="complexity == Light">
|
||||
<ask>Light narrative games usually don't need a full Narrative Design Document. Are you sure you want to continue?
|
||||
|
||||
- GDD story sections may be sufficient
|
||||
- Consider just expanding GDD narrative notes
|
||||
- Proceed with full narrative workflow
|
||||
|
||||
Your choice:</ask>
|
||||
|
||||
<action>Load narrative_template from workflow.yaml</action>
|
||||
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Define narrative premise and themes">
|
||||
|
||||
<ask>Describe your narrative premise in 2-3 sentences.
|
||||
|
||||
This is the "elevator pitch" of your story.
|
||||
|
||||
Examples:
|
||||
|
||||
- "A young knight discovers they're the last hope to stop an ancient evil, but must choose between saving the kingdom or their own family."
|
||||
- "After a mysterious pandemic, survivors must navigate a world where telling the truth is deadly but lying corrupts your soul."
|
||||
|
||||
Your premise:</ask>
|
||||
|
||||
<template-output>narrative_premise</template-output>
|
||||
|
||||
<ask>What are the core themes of your narrative? (2-4 themes)
|
||||
|
||||
Themes are the underlying ideas/messages.
|
||||
|
||||
Examples: redemption, sacrifice, identity, corruption, hope vs. despair, nature vs. technology
|
||||
|
||||
Your themes:</ask>
|
||||
|
||||
<template-output>core_themes</template-output>
|
||||
|
||||
<ask>Describe the tone and atmosphere.
|
||||
|
||||
Consider: dark, hopeful, comedic, melancholic, mysterious, epic, intimate, etc.
|
||||
|
||||
Your tone:</ask>
|
||||
|
||||
<template-output>tone_atmosphere</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Define story structure">
|
||||
|
||||
<ask>What story structure are you using?
|
||||
|
||||
Common structures:
|
||||
|
||||
- **3-Act** (Setup, Confrontation, Resolution)
|
||||
- **Hero's Journey** (Campbell's monomyth)
|
||||
- **Kishōtenketsu** (4-act: Introduction, Development, Twist, Conclusion)
|
||||
- **Episodic** (Self-contained episodes with arc)
|
||||
- **Branching** (Multiple paths and endings)
|
||||
- **Freeform** (Player-driven narrative)
|
||||
|
||||
Your structure:</ask>
|
||||
|
||||
<template-output>story_type</template-output>
|
||||
|
||||
<ask>Break down your story into acts/sections.
|
||||
|
||||
For 3-Act:
|
||||
|
||||
- Act 1: Setup and inciting incident
|
||||
- Act 2: Rising action and midpoint
|
||||
- Act 3: Climax and resolution
|
||||
|
||||
Describe each act/section for your game:</ask>
|
||||
|
||||
<template-output>act_breakdown</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Define major story beats">
|
||||
|
||||
<ask>List the major story beats (10-20 key moments).
|
||||
|
||||
Story beats are significant events that drive the narrative forward.
|
||||
|
||||
Format:
|
||||
|
||||
1. [Beat name] - Brief description
|
||||
2. [Beat name] - Brief description
|
||||
...
|
||||
|
||||
Your story beats:</ask>
|
||||
|
||||
<template-output>story_beats</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
<ask>Describe the pacing and flow of your narrative.
|
||||
|
||||
Consider:
|
||||
|
||||
- Slow burn vs. fast-paced
|
||||
- Tension/release rhythm
|
||||
- Story-heavy vs. gameplay-heavy sections
|
||||
- Optional vs. required narrative content
|
||||
|
||||
Your pacing:</ask>
|
||||
|
||||
<template-output>pacing_flow</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Develop protagonist(s)">
|
||||
|
||||
<ask>Describe your protagonist(s).
|
||||
|
||||
For each protagonist include:
|
||||
|
||||
- Name and brief description
|
||||
- Background and motivation
|
||||
- Character arc (how they change)
|
||||
- Strengths and flaws
|
||||
- Relationships to other characters
|
||||
- Internal and external conflicts
|
||||
|
||||
Your protagonist(s):</ask>
|
||||
|
||||
<template-output>protagonists</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Develop antagonist(s)">
|
||||
|
||||
<ask>Describe your antagonist(s).
|
||||
|
||||
For each antagonist include:
|
||||
|
||||
- Name and brief description
|
||||
- Background and motivation
|
||||
- Goals (what they want)
|
||||
- Methods (how they pursue goals)
|
||||
- Relationship to protagonist
|
||||
- Sympathetic elements (if any)
|
||||
|
||||
Your antagonist(s):</ask>
|
||||
|
||||
<template-output>antagonists</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Develop supporting characters">
|
||||
|
||||
<ask>Describe supporting characters (allies, mentors, companions, NPCs).
|
||||
|
||||
For each character include:
|
||||
|
||||
- Name and role
|
||||
- Personality and traits
|
||||
- Relationship to protagonist
|
||||
- Function in story (mentor, foil, comic relief, etc.)
|
||||
- Key scenes/moments
|
||||
|
||||
Your supporting characters:</ask>
|
||||
|
||||
<template-output>supporting_characters</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Map character arcs">
|
||||
|
||||
<ask>Describe the character arcs for major characters.
|
||||
|
||||
Character arc: How does the character change from beginning to end?
|
||||
|
||||
For each arc:
|
||||
|
||||
- Starting state
|
||||
- Key transformation moments
|
||||
- Ending state
|
||||
- Lessons learned
|
||||
|
||||
Your character arcs:</ask>
|
||||
|
||||
<template-output>character_arcs</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Build world and lore">
|
||||
|
||||
<ask>Describe your world.
|
||||
|
||||
Include:
|
||||
|
||||
- Setting (time period, location, world type)
|
||||
- World rules (magic systems, technology level, societal norms)
|
||||
- Atmosphere and aesthetics
|
||||
- What makes this world unique
|
||||
|
||||
Your world:</ask>
|
||||
|
||||
<template-output>world_overview</template-output>
|
||||
|
||||
<ask>What is the history and backstory of your world?
|
||||
|
||||
- Major historical events
|
||||
- How did the world reach its current state?
|
||||
- Legends and myths
|
||||
- Past conflicts
|
||||
|
||||
Your history:</ask>
|
||||
|
||||
<template-output>history_backstory</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Define factions and locations">
|
||||
|
||||
<ask optional="true">Describe factions, organizations, or groups (if applicable).
|
||||
|
||||
For each:
|
||||
|
||||
- Name and purpose
|
||||
- Leadership and structure
|
||||
- Goals and methods
|
||||
- Relationships with other factions
|
||||
|
||||
Your factions:</ask>
|
||||
|
||||
<template-output>factions_organizations</template-output>
|
||||
|
||||
<ask>Describe key locations in your world.
|
||||
|
||||
For each location:
|
||||
|
||||
- Name and description
|
||||
- Narrative significance
|
||||
- Atmosphere and mood
|
||||
- Key events that occur there
|
||||
|
||||
Your locations:</ask>
|
||||
|
||||
<template-output>locations</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Define dialogue framework">
|
||||
|
||||
<ask>Describe your dialogue style.
|
||||
|
||||
Consider:
|
||||
|
||||
- Formal vs. casual
|
||||
- Period-appropriate vs. modern
|
||||
- Verbose vs. concise
|
||||
- Humor level
|
||||
- Profanity/mature language
|
||||
|
||||
Your dialogue style:</ask>
|
||||
|
||||
<template-output>dialogue_style</template-output>
|
||||
|
||||
<ask>List key conversations/dialogue moments.
|
||||
|
||||
Include:
|
||||
|
||||
- Who is involved
|
||||
- When it occurs
|
||||
- What's discussed
|
||||
- Narrative purpose
|
||||
- Emotional tone
|
||||
|
||||
Your key conversations:</ask>
|
||||
|
||||
<template-output>key_conversations</template-output>
|
||||
|
||||
<check if="game has branching dialogue">
|
||||
<ask>Describe your branching dialogue system.
|
||||
|
||||
- How many branches/paths?
|
||||
- What determines branches? (stats, choices, flags)
|
||||
- Do branches converge?
|
||||
- How much unique dialogue?
|
||||
|
||||
Your branching system:</ask>
|
||||
|
||||
<template-output>branching_dialogue</template-output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Environmental storytelling">
|
||||
|
||||
<ask>How will you tell story through the environment?
|
||||
|
||||
Visual storytelling:
|
||||
|
||||
- Set dressing and props
|
||||
- Environmental damage/aftermath
|
||||
- Visual symbolism
|
||||
- Color and lighting
|
||||
|
||||
Your visual storytelling:</ask>
|
||||
|
||||
<template-output>visual_storytelling</template-output>
|
||||
|
||||
<ask>How will audio contribute to storytelling?
|
||||
|
||||
- Ambient sounds
|
||||
- Music emotional cues
|
||||
- Voice acting
|
||||
- Audio logs/recordings
|
||||
|
||||
Your audio storytelling:</ask>
|
||||
|
||||
<template-output>audio_storytelling</template-output>
|
||||
|
||||
<ask optional="true">Will you have found documents (journals, notes, emails)?
|
||||
|
||||
If yes, describe:
|
||||
|
||||
- Types of documents
|
||||
- How many
|
||||
- What they reveal
|
||||
- Optional vs. required reading
|
||||
|
||||
Your found documents:</ask>
|
||||
|
||||
<template-output>found_documents</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="13" goal="Narrative delivery methods">
|
||||
|
||||
<ask>How will you deliver narrative content?
|
||||
|
||||
**Cutscenes/Cinematics:**
|
||||
|
||||
- How many?
|
||||
- Skippable?
|
||||
- Real-time or pre-rendered?
|
||||
- Average length
|
||||
|
||||
Your cutscenes:</ask>
|
||||
|
||||
<template-output>cutscenes</template-output>
|
||||
|
||||
<ask>How will you deliver story during gameplay?
|
||||
|
||||
- NPC conversations
|
||||
- Radio/comm chatter
|
||||
- Environmental cues
|
||||
- Player actions
|
||||
- Show vs. tell balance
|
||||
|
||||
Your in-game storytelling:</ask>
|
||||
|
||||
<template-output>ingame_storytelling</template-output>
|
||||
|
||||
<ask>What narrative content is optional?
|
||||
|
||||
- Side quests
|
||||
- Collectible lore
|
||||
- Optional conversations
|
||||
- Secret endings
|
||||
|
||||
Your optional content:</ask>
|
||||
|
||||
<template-output>optional_content</template-output>
|
||||
|
||||
<check if="multiple endings">
|
||||
<ask>Describe your ending structure.
|
||||
|
||||
- How many endings?
|
||||
- What determines ending? (choices, stats, completion)
|
||||
- Ending variety (minor variations vs. drastically different)
|
||||
- True/golden ending?
|
||||
|
||||
Your endings:</ask>
|
||||
|
||||
<template-output>multiple_endings</template-output>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="14" goal="Gameplay integration">
|
||||
|
||||
<ask>How does narrative integrate with gameplay?
|
||||
|
||||
- Does story unlock mechanics?
|
||||
- Do mechanics reflect themes?
|
||||
- Ludonarrative harmony or dissonance?
|
||||
- Balance of story vs. gameplay
|
||||
|
||||
Your narrative-gameplay integration:</ask>
|
||||
|
||||
<template-output>narrative_gameplay</template-output>
|
||||
|
||||
<ask>How does story gate progression?
|
||||
|
||||
- Story-locked areas
|
||||
- Cutscene triggers
|
||||
- Mandatory story beats
|
||||
- Optional vs. required narrative
|
||||
|
||||
Your story gates:</ask>
|
||||
|
||||
<template-output>story_gates</template-output>
|
||||
|
||||
<ask>How much agency does the player have?
|
||||
|
||||
- Can player affect story?
|
||||
- Meaningful choices?
|
||||
- Role-playing freedom?
|
||||
- Predetermined vs. dynamic narrative
|
||||
|
||||
Your player agency:</ask>
|
||||
|
||||
<template-output>player_agency</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="15" goal="Production planning">
|
||||
|
||||
<ask>Estimate your writing scope.
|
||||
|
||||
- Word count estimate
|
||||
- Number of scenes/chapters
|
||||
- Dialogue lines estimate
|
||||
- Branching complexity
|
||||
|
||||
Your scope:</ask>
|
||||
|
||||
<template-output>writing_scope</template-output>
|
||||
|
||||
<ask>Localization considerations?
|
||||
|
||||
- Target languages
|
||||
- Cultural adaptation needs
|
||||
- Text expansion concerns
|
||||
- Dialogue recording implications
|
||||
|
||||
Your localization:</ask>
|
||||
|
||||
<template-output>localization</template-output>
|
||||
|
||||
<ask>Voice acting plans?
|
||||
|
||||
- Fully voiced, partially voiced, or text-only?
|
||||
- Number of characters needing voices
|
||||
- Dialogue volume
|
||||
- Budget considerations
|
||||
|
||||
Your voice acting:</ask>
|
||||
|
||||
<template-output>voice_acting</template-output>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="16" goal="Completion and next steps">
|
||||
|
||||
<action>Generate character relationship map (text-based diagram)</action>
|
||||
<template-output>relationship_map</template-output>
|
||||
|
||||
<action>Generate story timeline</action>
|
||||
<template-output>timeline</template-output>
|
||||
|
||||
<ask optional="true">Any references or inspirations to note?
|
||||
|
||||
- Books, movies, games that inspired you
|
||||
- Reference materials
|
||||
- Tone/theme references
|
||||
|
||||
Your references:</ask>
|
||||
|
||||
<template-output>references</template-output>
|
||||
|
||||
<ask>**✅ Narrative Design Complete, {user_name}!**
|
||||
|
||||
Next steps:
|
||||
|
||||
1. Proceed to solutioning (technical architecture)
|
||||
2. Create detailed script/screenplay (outside workflow)
|
||||
3. Review narrative with team/stakeholders
|
||||
4. Exit workflow
|
||||
|
||||
Which would you like?</ask>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="17" goal="Update status if tracking enabled" tag="workflow-status">
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "narrative"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["narrative"] = "{output_folder}/bmm-narrative-{{game_name}}-{{date}}.md"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
</check>
|
||||
|
||||
<output>**✅ Narrative Design Complete, {user_name}!**
|
||||
|
||||
**Narrative Document:**
|
||||
|
||||
- Narrative design saved to {output_folder}/bmm-narrative-{{game_name}}-{{date}}.md
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
**Status Updated:**
|
||||
|
||||
- Progress tracking updated: narrative marked complete
|
||||
- Next workflow: {{next_workflow}}
|
||||
{{else}}
|
||||
**Note:** Running in standalone mode (no progress tracking)
|
||||
{{/if}}
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
{{#if standalone_mode != true}}
|
||||
|
||||
- **Next workflow:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- **Optional:** Review narrative with writing team or stakeholders
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
{{else}}
|
||||
Since no workflow is in progress:
|
||||
|
||||
- Review narrative design with team
|
||||
- Refer to the BMM workflow guide if unsure what to do next
|
||||
- Or run `workflow-init` to create a workflow path and get guided next steps
|
||||
{{/if}}
|
||||
</output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,195 @@
|
||||
# {{game_name}} - Narrative Design Document
|
||||
|
||||
**Author:** {{user_name}}
|
||||
**Game Type:** {{game_type}}
|
||||
**Narrative Complexity:** {{narrative_complexity}}
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
### Narrative Premise
|
||||
|
||||
{{narrative_premise}}
|
||||
|
||||
### Core Themes
|
||||
|
||||
{{core_themes}}
|
||||
|
||||
### Tone and Atmosphere
|
||||
|
||||
{{tone_atmosphere}}
|
||||
|
||||
---
|
||||
|
||||
## Story Structure
|
||||
|
||||
### Story Type
|
||||
|
||||
{{story_type}}
|
||||
|
||||
**Structure used:** (3-act, hero's journey, kishōtenketsu, episodic, branching, etc.)
|
||||
|
||||
### Act Breakdown
|
||||
|
||||
{{act_breakdown}}
|
||||
|
||||
### Story Beats
|
||||
|
||||
{{story_beats}}
|
||||
|
||||
### Pacing and Flow
|
||||
|
||||
{{pacing_flow}}
|
||||
|
||||
---
|
||||
|
||||
## Characters
|
||||
|
||||
### Protagonist(s)
|
||||
|
||||
{{protagonists}}
|
||||
|
||||
### Antagonist(s)
|
||||
|
||||
{{antagonists}}
|
||||
|
||||
### Supporting Characters
|
||||
|
||||
{{supporting_characters}}
|
||||
|
||||
### Character Arcs
|
||||
|
||||
{{character_arcs}}
|
||||
|
||||
---
|
||||
|
||||
## World and Lore
|
||||
|
||||
### World Overview
|
||||
|
||||
{{world_overview}}
|
||||
|
||||
### History and Backstory
|
||||
|
||||
{{history_backstory}}
|
||||
|
||||
### Factions and Organizations
|
||||
|
||||
{{factions_organizations}}
|
||||
|
||||
### Locations
|
||||
|
||||
{{locations}}
|
||||
|
||||
### Cultural Elements
|
||||
|
||||
{{cultural_elements}}
|
||||
|
||||
---
|
||||
|
||||
## Dialogue Framework
|
||||
|
||||
### Dialogue Style
|
||||
|
||||
{{dialogue_style}}
|
||||
|
||||
### Key Conversations
|
||||
|
||||
{{key_conversations}}
|
||||
|
||||
### Branching Dialogue
|
||||
|
||||
{{branching_dialogue}}
|
||||
|
||||
### Voice and Characterization
|
||||
|
||||
{{voice_characterization}}
|
||||
|
||||
---
|
||||
|
||||
## Environmental Storytelling
|
||||
|
||||
### Visual Storytelling
|
||||
|
||||
{{visual_storytelling}}
|
||||
|
||||
### Audio Storytelling
|
||||
|
||||
{{audio_storytelling}}
|
||||
|
||||
### Found Documents
|
||||
|
||||
{{found_documents}}
|
||||
|
||||
### Environmental Clues
|
||||
|
||||
{{environmental_clues}}
|
||||
|
||||
---
|
||||
|
||||
## Narrative Delivery
|
||||
|
||||
### Cutscenes and Cinematics
|
||||
|
||||
{{cutscenes}}
|
||||
|
||||
### In-Game Storytelling
|
||||
|
||||
{{ingame_storytelling}}
|
||||
|
||||
### Optional Content
|
||||
|
||||
{{optional_content}}
|
||||
|
||||
### Multiple Endings
|
||||
|
||||
{{multiple_endings}}
|
||||
|
||||
---
|
||||
|
||||
## Integration with Gameplay
|
||||
|
||||
### Narrative-Gameplay Harmony
|
||||
|
||||
{{narrative_gameplay}}
|
||||
|
||||
### Story Gates
|
||||
|
||||
{{story_gates}}
|
||||
|
||||
### Player Agency
|
||||
|
||||
{{player_agency}}
|
||||
|
||||
---
|
||||
|
||||
## Production Notes
|
||||
|
||||
### Writing Scope
|
||||
|
||||
{{writing_scope}}
|
||||
|
||||
### Localization Considerations
|
||||
|
||||
{{localization}}
|
||||
|
||||
### Voice Acting
|
||||
|
||||
{{voice_acting}}
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Character Relationship Map
|
||||
|
||||
{{relationship_map}}
|
||||
|
||||
### Timeline
|
||||
|
||||
{{timeline}}
|
||||
|
||||
### References and Inspirations
|
||||
|
||||
{{references}}
|
||||
38
src/modules/bmgd/workflows/2-design/narrative/workflow.yaml
Normal file
38
src/modules/bmgd/workflows/2-design/narrative/workflow.yaml
Normal file
@@ -0,0 +1,38 @@
|
||||
# Narrative Design Workflow
|
||||
name: narrative
|
||||
description: "Narrative design workflow for story-driven games and applications. Creates comprehensive narrative documentation including story structure, character arcs, dialogue systems, and narrative implementation guidance."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables from config
|
||||
config_source: "{project-root}/bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
game_dev_experience: "{config_source}:game_dev_experience"
|
||||
date: system-generated
|
||||
|
||||
# Workflow components
|
||||
installed_path: "{project-root}/bmad/bmgd/workflows/2-design/narrative"
|
||||
instructions: "{installed_path}/instructions-narrative.md"
|
||||
template: "{installed_path}/narrative-template.md"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/narrative-design.md"
|
||||
|
||||
# Recommended input documents
|
||||
recommended_inputs:
|
||||
- game_brief: "{output_folder}/game-brief.md"
|
||||
- gdd: "{output_folder}/GDD.md"
|
||||
- product_brief: "{output_folder}/product-brief.md"
|
||||
|
||||
standalone: true
|
||||
|
||||
web_bundle:
|
||||
name: "narrative"
|
||||
description: "Narrative design workflow for story-driven games and applications. Creates comprehensive narrative documentation including story structure, character arcs, dialogue systems, and narrative implementation guidance."
|
||||
author: "BMad"
|
||||
instructions: "bmad/bmgd/workflows/2-design/narrative/instructions-narrative.md"
|
||||
web_bundle_files:
|
||||
- "bmad/bmgd/workflows/2-design/narrative/instructions-narrative.md"
|
||||
- "bmad/bmgd/workflows/2-design/narrative/narrative-template.md"
|
||||
@@ -0,0 +1,347 @@
|
||||
# Architecture Patterns - Common patterns identified from requirements
|
||||
|
||||
requirement_patterns:
|
||||
realtime_collaboration:
|
||||
triggers:
|
||||
- "real-time"
|
||||
- "collaborative"
|
||||
- "live updates"
|
||||
- "multi-user"
|
||||
- "simultaneous editing"
|
||||
decisions_needed:
|
||||
- websocket_solution
|
||||
- conflict_resolution
|
||||
- state_synchronization
|
||||
- presence_tracking
|
||||
- optimistic_updates
|
||||
suggested_stack:
|
||||
- "Socket.io or WebSocket native"
|
||||
- "Redis for pub/sub"
|
||||
- "Operational Transforms or CRDTs for conflict resolution"
|
||||
- "PostgreSQL for persistence"
|
||||
|
||||
ecommerce:
|
||||
triggers:
|
||||
- "shopping cart"
|
||||
- "checkout"
|
||||
- "payments"
|
||||
- "inventory"
|
||||
- "product catalog"
|
||||
decisions_needed:
|
||||
- payment_processor
|
||||
- cart_persistence
|
||||
- inventory_management
|
||||
- order_workflow
|
||||
- tax_calculation
|
||||
suggested_stack:
|
||||
- "Stripe or PayPal for payments"
|
||||
- "PostgreSQL for products and orders"
|
||||
- "Redis for cart sessions"
|
||||
- "BullMQ for order processing"
|
||||
|
||||
saas_platform:
|
||||
triggers:
|
||||
- "multi-tenant"
|
||||
- "subscription"
|
||||
- "billing"
|
||||
- "team management"
|
||||
- "roles and permissions"
|
||||
decisions_needed:
|
||||
- tenancy_model
|
||||
- subscription_billing
|
||||
- permission_system
|
||||
- team_collaboration
|
||||
- usage_tracking
|
||||
suggested_stack:
|
||||
- "PostgreSQL with Row Level Security"
|
||||
- "Stripe Billing for subscriptions"
|
||||
- "RBAC or ABAC for permissions"
|
||||
- "NextAuth or Clerk for auth"
|
||||
|
||||
content_platform:
|
||||
triggers:
|
||||
- "CMS"
|
||||
- "blog"
|
||||
- "publishing"
|
||||
- "content management"
|
||||
- "editorial workflow"
|
||||
decisions_needed:
|
||||
- content_storage
|
||||
- rich_text_editor
|
||||
- media_handling
|
||||
- version_control
|
||||
- publishing_workflow
|
||||
suggested_stack:
|
||||
- "PostgreSQL for structured content"
|
||||
- "S3 or Cloudinary for media"
|
||||
- "Tiptap or Slate for rich text"
|
||||
- "Algolia for search"
|
||||
|
||||
data_analytics:
|
||||
triggers:
|
||||
- "dashboards"
|
||||
- "reporting"
|
||||
- "metrics"
|
||||
- "analytics"
|
||||
- "data visualization"
|
||||
decisions_needed:
|
||||
- data_warehouse
|
||||
- etl_pipeline
|
||||
- visualization_library
|
||||
- query_optimization
|
||||
- caching_strategy
|
||||
suggested_stack:
|
||||
- "PostgreSQL or ClickHouse"
|
||||
- "Apache Airflow or Temporal for ETL"
|
||||
- "Chart.js or D3 for visualization"
|
||||
- "Redis for query caching"
|
||||
|
||||
social_platform:
|
||||
triggers:
|
||||
- "social network"
|
||||
- "feed"
|
||||
- "following"
|
||||
- "likes"
|
||||
- "comments"
|
||||
decisions_needed:
|
||||
- graph_relationships
|
||||
- feed_algorithm
|
||||
- notification_system
|
||||
- content_moderation
|
||||
- privacy_controls
|
||||
suggested_stack:
|
||||
- "PostgreSQL with graph extensions or Neo4j"
|
||||
- "Redis for feed caching"
|
||||
- "Elasticsearch for user search"
|
||||
- "WebSockets for notifications"
|
||||
|
||||
marketplace:
|
||||
triggers:
|
||||
- "marketplace"
|
||||
- "vendors"
|
||||
- "buyers and sellers"
|
||||
- "transactions"
|
||||
- "escrow"
|
||||
decisions_needed:
|
||||
- payment_splitting
|
||||
- escrow_handling
|
||||
- vendor_management
|
||||
- dispute_resolution
|
||||
- commission_model
|
||||
suggested_stack:
|
||||
- "Stripe Connect for payments"
|
||||
- "PostgreSQL for transactions"
|
||||
- "BullMQ for async processing"
|
||||
- "S3 for vendor assets"
|
||||
|
||||
streaming_platform:
|
||||
triggers:
|
||||
- "video streaming"
|
||||
- "live streaming"
|
||||
- "media delivery"
|
||||
- "broadcast"
|
||||
decisions_needed:
|
||||
- video_encoding
|
||||
- cdn_strategy
|
||||
- streaming_protocol
|
||||
- bandwidth_optimization
|
||||
- drm_protection
|
||||
suggested_stack:
|
||||
- "AWS MediaConvert or Mux"
|
||||
- "CloudFront or Fastly CDN"
|
||||
- "HLS or DASH protocol"
|
||||
- "S3 for video storage"
|
||||
|
||||
iot_platform:
|
||||
triggers:
|
||||
- "IoT"
|
||||
- "sensors"
|
||||
- "device management"
|
||||
- "telemetry"
|
||||
- "edge computing"
|
||||
decisions_needed:
|
||||
- message_protocol
|
||||
- time_series_database
|
||||
- device_authentication
|
||||
- data_ingestion
|
||||
- edge_processing
|
||||
suggested_stack:
|
||||
- "MQTT or CoAP protocol"
|
||||
- "TimescaleDB or InfluxDB"
|
||||
- "Apache Kafka for ingestion"
|
||||
- "Grafana for monitoring"
|
||||
|
||||
ai_application:
|
||||
triggers:
|
||||
- "machine learning"
|
||||
- "AI features"
|
||||
- "LLM integration"
|
||||
- "computer vision"
|
||||
- "NLP"
|
||||
decisions_needed:
|
||||
- model_serving
|
||||
- vector_database
|
||||
- prompt_management
|
||||
- token_optimization
|
||||
- fallback_strategy
|
||||
suggested_stack:
|
||||
- "OpenAI or Anthropic API"
|
||||
- "Pinecone or pgvector for embeddings"
|
||||
- "Redis for prompt caching"
|
||||
- "Langchain or LlamaIndex"
|
||||
|
||||
# Quality attribute patterns
|
||||
quality_attributes:
|
||||
high_availability:
|
||||
triggers:
|
||||
- "99.9% uptime"
|
||||
- "high availability"
|
||||
- "fault tolerance"
|
||||
- "disaster recovery"
|
||||
architectural_needs:
|
||||
- load_balancing
|
||||
- database_replication
|
||||
- health_checks
|
||||
- circuit_breakers
|
||||
- graceful_degradation
|
||||
|
||||
high_performance:
|
||||
triggers:
|
||||
- "millisecond response"
|
||||
- "high throughput"
|
||||
- "low latency"
|
||||
- "performance critical"
|
||||
architectural_needs:
|
||||
- caching_layers
|
||||
- database_optimization
|
||||
- cdn_strategy
|
||||
- code_splitting
|
||||
- lazy_loading
|
||||
|
||||
high_security:
|
||||
triggers:
|
||||
- "compliance"
|
||||
- "HIPAA"
|
||||
- "GDPR"
|
||||
- "financial data"
|
||||
- "PCI DSS"
|
||||
architectural_needs:
|
||||
- encryption_at_rest
|
||||
- encryption_in_transit
|
||||
- audit_logging
|
||||
- access_controls
|
||||
- data_isolation
|
||||
|
||||
scalability:
|
||||
triggers:
|
||||
- "millions of users"
|
||||
- "elastic scale"
|
||||
- "global reach"
|
||||
- "viral growth"
|
||||
architectural_needs:
|
||||
- horizontal_scaling
|
||||
- database_sharding
|
||||
- microservices
|
||||
- queue_systems
|
||||
- auto_scaling
|
||||
|
||||
# Integration patterns
|
||||
integration_requirements:
|
||||
payment_processing:
|
||||
common_choices:
|
||||
- "Stripe - most developer friendly"
|
||||
- "PayPal - widest consumer adoption"
|
||||
- "Square - best for in-person + online"
|
||||
considerations:
|
||||
- transaction_fees
|
||||
- international_support
|
||||
- subscription_handling
|
||||
- marketplace_capabilities
|
||||
|
||||
email_service:
|
||||
common_choices:
|
||||
- "Resend - modern, developer friendly"
|
||||
- "SendGrid - mature, scalable"
|
||||
- "Amazon SES - cost effective at scale"
|
||||
- "Postmark - transactional focus"
|
||||
considerations:
|
||||
- deliverability
|
||||
- template_management
|
||||
- analytics_needs
|
||||
- cost_per_email
|
||||
|
||||
sms_notifications:
|
||||
common_choices:
|
||||
- "Twilio - most comprehensive"
|
||||
- "Amazon SNS - AWS integrated"
|
||||
- "Vonage - competitive pricing"
|
||||
considerations:
|
||||
- international_coverage
|
||||
- delivery_rates
|
||||
- two_way_messaging
|
||||
- cost_per_message
|
||||
|
||||
authentication_providers:
|
||||
social_providers:
|
||||
- "Google - highest adoption"
|
||||
- "GitHub - developer focused"
|
||||
- "Microsoft - enterprise"
|
||||
- "Apple - iOS users"
|
||||
enterprise_providers:
|
||||
- "SAML 2.0"
|
||||
- "OAuth 2.0"
|
||||
- "OpenID Connect"
|
||||
- "Active Directory"
|
||||
|
||||
# Decision heuristics
|
||||
decision_rules:
|
||||
database_selection:
|
||||
if_requirements_include:
|
||||
- complex_relationships: "PostgreSQL"
|
||||
- flexible_schema: "MongoDB"
|
||||
- time_series: "TimescaleDB"
|
||||
- graph_data: "Neo4j or PostgreSQL with extensions"
|
||||
- key_value: "Redis"
|
||||
- wide_column: "Cassandra"
|
||||
|
||||
api_pattern_selection:
|
||||
if_requirements_include:
|
||||
- simple_crud: "REST"
|
||||
- complex_queries: "GraphQL"
|
||||
- type_safety_critical: "tRPC"
|
||||
- microservices: "gRPC"
|
||||
- public_api: "REST with OpenAPI"
|
||||
|
||||
deployment_selection:
|
||||
if_requirements_include:
|
||||
- nextjs_only: "Vercel"
|
||||
- complex_infrastructure: "AWS"
|
||||
- quick_prototype: "Railway"
|
||||
- global_edge: "Fly.io"
|
||||
- kubernetes_needed: "GCP or AWS EKS"
|
||||
|
||||
# Anti-patterns to avoid
|
||||
anti_patterns:
|
||||
overengineering:
|
||||
signs:
|
||||
- "Microservices for < 10k users"
|
||||
- "Kubernetes for single app"
|
||||
- "GraphQL for 5 endpoints"
|
||||
- "Event sourcing for CRUD app"
|
||||
recommendation: "Start simple, evolve as needed"
|
||||
|
||||
underengineering:
|
||||
signs:
|
||||
- "No authentication strategy"
|
||||
- "No error handling plan"
|
||||
- "No monitoring approach"
|
||||
- "No backup strategy"
|
||||
recommendation: "Cover the fundamentals"
|
||||
|
||||
technology_soup:
|
||||
signs:
|
||||
- "5+ different databases"
|
||||
- "Multiple frontend frameworks"
|
||||
- "Inconsistent patterns"
|
||||
- "Too many languages"
|
||||
recommendation: "Maintain consistency"
|
||||
@@ -0,0 +1,103 @@
|
||||
# Architecture
|
||||
|
||||
## Executive Summary
|
||||
|
||||
{{executive_summary}}
|
||||
|
||||
{{project_initialization_section}}
|
||||
|
||||
## Decision Summary
|
||||
|
||||
| Category | Decision | Version | Affects Epics | Rationale |
|
||||
| -------- | -------- | ------- | ------------- | --------- |
|
||||
|
||||
{{decision_table_rows}}
|
||||
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
{{project_root}}/
|
||||
{{source_tree}}
|
||||
```
|
||||
|
||||
## Epic to Architecture Mapping
|
||||
|
||||
{{epic_mapping_table}}
|
||||
|
||||
## Technology Stack Details
|
||||
|
||||
### Core Technologies
|
||||
|
||||
{{core_stack_details}}
|
||||
|
||||
### Integration Points
|
||||
|
||||
{{integration_details}}
|
||||
|
||||
{{novel_pattern_designs_section}}
|
||||
|
||||
## Implementation Patterns
|
||||
|
||||
These patterns ensure consistent implementation across all AI agents:
|
||||
|
||||
{{implementation_patterns}}
|
||||
|
||||
## Consistency Rules
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
{{naming_conventions}}
|
||||
|
||||
### Code Organization
|
||||
|
||||
{{code_organization_patterns}}
|
||||
|
||||
### Error Handling
|
||||
|
||||
{{error_handling_approach}}
|
||||
|
||||
### Logging Strategy
|
||||
|
||||
{{logging_approach}}
|
||||
|
||||
## Data Architecture
|
||||
|
||||
{{data_models_and_relationships}}
|
||||
|
||||
## API Contracts
|
||||
|
||||
{{api_specifications}}
|
||||
|
||||
## Security Architecture
|
||||
|
||||
{{security_approach}}
|
||||
|
||||
## Performance Considerations
|
||||
|
||||
{{performance_strategies}}
|
||||
|
||||
## Deployment Architecture
|
||||
|
||||
{{deployment_approach}}
|
||||
|
||||
## Development Environment
|
||||
|
||||
### Prerequisites
|
||||
|
||||
{{development_prerequisites}}
|
||||
|
||||
### Setup Commands
|
||||
|
||||
```bash
|
||||
{{setup_commands}}
|
||||
```
|
||||
|
||||
## Architecture Decision Records (ADRs)
|
||||
|
||||
{{key_architecture_decisions}}
|
||||
|
||||
---
|
||||
|
||||
_Generated by BMAD Decision Architecture Workflow v1.0_
|
||||
_Date: {{date}}_
|
||||
_For: {{user_name}}_
|
||||
@@ -0,0 +1,244 @@
|
||||
# Architecture Document Validation Checklist
|
||||
|
||||
**Purpose**: Validate the architecture document itself is complete, implementable, and provides clear guidance for AI agents.
|
||||
|
||||
**Note**: This checklist validates the ARCHITECTURE DOCUMENT only. For cross-workflow validation (PRD → Architecture → Stories alignment), use the solutioning-gate-check workflow.
|
||||
|
||||
---
|
||||
|
||||
## 1. Decision Completeness
|
||||
|
||||
### All Decisions Made
|
||||
|
||||
- [ ] Every critical decision category has been resolved
|
||||
- [ ] All important decision categories addressed
|
||||
- [ ] No placeholder text like "TBD", "[choose]", or "{TODO}" remains
|
||||
- [ ] Optional decisions either resolved or explicitly deferred with rationale
|
||||
|
||||
### Decision Coverage
|
||||
|
||||
- [ ] Data persistence approach decided
|
||||
- [ ] API pattern chosen
|
||||
- [ ] Authentication/authorization strategy defined
|
||||
- [ ] Deployment target selected
|
||||
- [ ] All functional requirements have architectural support
|
||||
|
||||
---
|
||||
|
||||
## 2. Version Specificity
|
||||
|
||||
### Technology Versions
|
||||
|
||||
- [ ] Every technology choice includes a specific version number
|
||||
- [ ] Version numbers are current (verified via WebSearch, not hardcoded)
|
||||
- [ ] Compatible versions selected (e.g., Node.js version supports chosen packages)
|
||||
- [ ] Verification dates noted for version checks
|
||||
|
||||
### Version Verification Process
|
||||
|
||||
- [ ] WebSearch used during workflow to verify current versions
|
||||
- [ ] No hardcoded versions from decision catalog trusted without verification
|
||||
- [ ] LTS vs. latest versions considered and documented
|
||||
- [ ] Breaking changes between versions noted if relevant
|
||||
|
||||
---
|
||||
|
||||
## 3. Starter Template Integration (if applicable)
|
||||
|
||||
### Template Selection
|
||||
|
||||
- [ ] Starter template chosen (or "from scratch" decision documented)
|
||||
- [ ] Project initialization command documented with exact flags
|
||||
- [ ] Starter template version is current and specified
|
||||
- [ ] Command search term provided for verification
|
||||
|
||||
### Starter-Provided Decisions
|
||||
|
||||
- [ ] Decisions provided by starter marked as "PROVIDED BY STARTER"
|
||||
- [ ] List of what starter provides is complete
|
||||
- [ ] Remaining decisions (not covered by starter) clearly identified
|
||||
- [ ] No duplicate decisions that starter already makes
|
||||
|
||||
---
|
||||
|
||||
## 4. Novel Pattern Design (if applicable)
|
||||
|
||||
### Pattern Detection
|
||||
|
||||
- [ ] All unique/novel concepts from PRD identified
|
||||
- [ ] Patterns that don't have standard solutions documented
|
||||
- [ ] Multi-epic workflows requiring custom design captured
|
||||
|
||||
### Pattern Documentation Quality
|
||||
|
||||
- [ ] Pattern name and purpose clearly defined
|
||||
- [ ] Component interactions specified
|
||||
- [ ] Data flow documented (with sequence diagrams if complex)
|
||||
- [ ] Implementation guide provided for agents
|
||||
- [ ] Edge cases and failure modes considered
|
||||
- [ ] States and transitions clearly defined
|
||||
|
||||
### Pattern Implementability
|
||||
|
||||
- [ ] Pattern is implementable by AI agents with provided guidance
|
||||
- [ ] No ambiguous decisions that could be interpreted differently
|
||||
- [ ] Clear boundaries between components
|
||||
- [ ] Explicit integration points with standard patterns
|
||||
|
||||
---
|
||||
|
||||
## 5. Implementation Patterns
|
||||
|
||||
### Pattern Categories Coverage
|
||||
|
||||
- [ ] **Naming Patterns**: API routes, database tables, components, files
|
||||
- [ ] **Structure Patterns**: Test organization, component organization, shared utilities
|
||||
- [ ] **Format Patterns**: API responses, error formats, date handling
|
||||
- [ ] **Communication Patterns**: Events, state updates, inter-component messaging
|
||||
- [ ] **Lifecycle Patterns**: Loading states, error recovery, retry logic
|
||||
- [ ] **Location Patterns**: URL structure, asset organization, config placement
|
||||
- [ ] **Consistency Patterns**: UI date formats, logging, user-facing errors
|
||||
|
||||
### Pattern Quality
|
||||
|
||||
- [ ] Each pattern has concrete examples
|
||||
- [ ] Conventions are unambiguous (agents can't interpret differently)
|
||||
- [ ] Patterns cover all technologies in the stack
|
||||
- [ ] No gaps where agents would have to guess
|
||||
- [ ] Implementation patterns don't conflict with each other
|
||||
|
||||
---
|
||||
|
||||
## 6. Technology Compatibility
|
||||
|
||||
### Stack Coherence
|
||||
|
||||
- [ ] Database choice compatible with ORM choice
|
||||
- [ ] Frontend framework compatible with deployment target
|
||||
- [ ] Authentication solution works with chosen frontend/backend
|
||||
- [ ] All API patterns consistent (not mixing REST and GraphQL for same data)
|
||||
- [ ] Starter template compatible with additional choices
|
||||
|
||||
### Integration Compatibility
|
||||
|
||||
- [ ] Third-party services compatible with chosen stack
|
||||
- [ ] Real-time solutions (if any) work with deployment target
|
||||
- [ ] File storage solution integrates with framework
|
||||
- [ ] Background job system compatible with infrastructure
|
||||
|
||||
---
|
||||
|
||||
## 7. Document Structure
|
||||
|
||||
### Required Sections Present
|
||||
|
||||
- [ ] Executive summary exists (2-3 sentences maximum)
|
||||
- [ ] Project initialization section (if using starter template)
|
||||
- [ ] Decision summary table with ALL required columns:
|
||||
- Category
|
||||
- Decision
|
||||
- Version
|
||||
- Rationale
|
||||
- [ ] Project structure section shows complete source tree
|
||||
- [ ] Implementation patterns section comprehensive
|
||||
- [ ] Novel patterns section (if applicable)
|
||||
|
||||
### Document Quality
|
||||
|
||||
- [ ] Source tree reflects actual technology decisions (not generic)
|
||||
- [ ] Technical language used consistently
|
||||
- [ ] Tables used instead of prose where appropriate
|
||||
- [ ] No unnecessary explanations or justifications
|
||||
- [ ] Focused on WHAT and HOW, not WHY (rationale is brief)
|
||||
|
||||
---
|
||||
|
||||
## 8. AI Agent Clarity
|
||||
|
||||
### Clear Guidance for Agents
|
||||
|
||||
- [ ] No ambiguous decisions that agents could interpret differently
|
||||
- [ ] Clear boundaries between components/modules
|
||||
- [ ] Explicit file organization patterns
|
||||
- [ ] Defined patterns for common operations (CRUD, auth checks, etc.)
|
||||
- [ ] Novel patterns have clear implementation guidance
|
||||
- [ ] Document provides clear constraints for agents
|
||||
- [ ] No conflicting guidance present
|
||||
|
||||
### Implementation Readiness
|
||||
|
||||
- [ ] Sufficient detail for agents to implement without guessing
|
||||
- [ ] File paths and naming conventions explicit
|
||||
- [ ] Integration points clearly defined
|
||||
- [ ] Error handling patterns specified
|
||||
- [ ] Testing patterns documented
|
||||
|
||||
---
|
||||
|
||||
## 9. Practical Considerations
|
||||
|
||||
### Technology Viability
|
||||
|
||||
- [ ] Chosen stack has good documentation and community support
|
||||
- [ ] Development environment can be set up with specified versions
|
||||
- [ ] No experimental or alpha technologies for critical path
|
||||
- [ ] Deployment target supports all chosen technologies
|
||||
- [ ] Starter template (if used) is stable and well-maintained
|
||||
|
||||
### Scalability
|
||||
|
||||
- [ ] Architecture can handle expected user load
|
||||
- [ ] Data model supports expected growth
|
||||
- [ ] Caching strategy defined if performance is critical
|
||||
- [ ] Background job processing defined if async work needed
|
||||
- [ ] Novel patterns scalable for production use
|
||||
|
||||
---
|
||||
|
||||
## 10. Common Issues to Check
|
||||
|
||||
### Beginner Protection
|
||||
|
||||
- [ ] Not overengineered for actual requirements
|
||||
- [ ] Standard patterns used where possible (starter templates leveraged)
|
||||
- [ ] Complex technologies justified by specific needs
|
||||
- [ ] Maintenance complexity appropriate for team size
|
||||
|
||||
### Expert Validation
|
||||
|
||||
- [ ] No obvious anti-patterns present
|
||||
- [ ] Performance bottlenecks addressed
|
||||
- [ ] Security best practices followed
|
||||
- [ ] Future migration paths not blocked
|
||||
- [ ] Novel patterns follow architectural principles
|
||||
|
||||
---
|
||||
|
||||
## Validation Summary
|
||||
|
||||
### Document Quality Score
|
||||
|
||||
- Architecture Completeness: [Complete / Mostly Complete / Partial / Incomplete]
|
||||
- Version Specificity: [All Verified / Most Verified / Some Missing / Many Missing]
|
||||
- Pattern Clarity: [Crystal Clear / Clear / Somewhat Ambiguous / Ambiguous]
|
||||
- AI Agent Readiness: [Ready / Mostly Ready / Needs Work / Not Ready]
|
||||
|
||||
### Critical Issues Found
|
||||
|
||||
- [ ] Issue 1: **\*\***\_\_\_**\*\***
|
||||
- [ ] Issue 2: **\*\***\_\_\_**\*\***
|
||||
- [ ] Issue 3: **\*\***\_\_\_**\*\***
|
||||
|
||||
### Recommended Actions Before Implementation
|
||||
|
||||
1. ***
|
||||
2. ***
|
||||
3. ***
|
||||
|
||||
---
|
||||
|
||||
**Next Step**: Run the **solutioning-gate-check** workflow to validate alignment between PRD, Architecture, and Stories before beginning implementation.
|
||||
|
||||
---
|
||||
|
||||
_This checklist validates architecture document quality only. Use solutioning-gate-check for comprehensive readiness validation._
|
||||
@@ -0,0 +1,222 @@
|
||||
# Decision Catalog - Composability knowledge for architectural decisions
|
||||
# This provides RELATIONSHIPS and WORKFLOW LOGIC, not generic tech knowledge
|
||||
#
|
||||
# ⚠️ CRITICAL: All version/feature info MUST be verified via WebSearch during workflow
|
||||
# This file only provides: triggers, relationships (pairs_with), and opinionated stacks
|
||||
|
||||
decision_categories:
|
||||
data_persistence:
|
||||
triggers: ["database", "storage", "data model", "persistence", "state management"]
|
||||
importance: "critical"
|
||||
affects: "most epics"
|
||||
options:
|
||||
postgresql:
|
||||
pairs_with: ["Prisma ORM", "TypeORM", "Drizzle", "node-postgres"]
|
||||
mongodb:
|
||||
pairs_with: ["Mongoose", "Prisma", "MongoDB driver"]
|
||||
redis:
|
||||
pairs_with: ["ioredis", "node-redis"]
|
||||
supabase:
|
||||
pairs_with: ["@supabase/supabase-js"]
|
||||
firebase:
|
||||
pairs_with: ["firebase-admin"]
|
||||
|
||||
api_pattern:
|
||||
triggers: ["API", "client communication", "frontend backend", "service communication"]
|
||||
importance: "critical"
|
||||
affects: "all client-facing epics"
|
||||
options:
|
||||
rest:
|
||||
pairs_with: ["Express", "Fastify", "NestJS", "Hono"]
|
||||
graphql:
|
||||
pairs_with: ["Apollo Server", "GraphQL Yoga", "Mercurius"]
|
||||
trpc:
|
||||
pairs_with: ["Next.js", "React Query"]
|
||||
grpc:
|
||||
pairs_with: ["@grpc/grpc-js", "protobufjs"]
|
||||
|
||||
authentication:
|
||||
triggers: ["auth", "login", "user management", "security", "identity"]
|
||||
importance: "critical"
|
||||
affects: "security and user epics"
|
||||
options:
|
||||
nextauth:
|
||||
pairs_with: ["Next.js", "Prisma"]
|
||||
auth0:
|
||||
pairs_with: ["@auth0/nextjs-auth0"]
|
||||
clerk:
|
||||
pairs_with: ["@clerk/nextjs"]
|
||||
supabase_auth:
|
||||
pairs_with: ["@supabase/supabase-js"]
|
||||
firebase_auth:
|
||||
pairs_with: ["firebase-admin"]
|
||||
|
||||
real_time:
|
||||
triggers: ["real-time", "websocket", "live updates", "chat", "collaboration"]
|
||||
importance: "medium"
|
||||
affects: "real-time features"
|
||||
options:
|
||||
socket_io:
|
||||
pairs_with: ["Express", "socket.io-client"]
|
||||
pusher:
|
||||
pairs_with: ["pusher-js"]
|
||||
ably:
|
||||
pairs_with: ["ably"]
|
||||
supabase_realtime:
|
||||
pairs_with: ["@supabase/supabase-js"]
|
||||
firebase_realtime:
|
||||
pairs_with: ["firebase"]
|
||||
|
||||
email:
|
||||
triggers: ["email", "notifications", "transactional email"]
|
||||
importance: "medium"
|
||||
affects: "notification epics"
|
||||
options:
|
||||
resend:
|
||||
pairs_with: ["resend", "react-email"]
|
||||
sendgrid:
|
||||
pairs_with: ["@sendgrid/mail"]
|
||||
postmark:
|
||||
pairs_with: ["postmark"]
|
||||
ses:
|
||||
pairs_with: ["@aws-sdk/client-ses"]
|
||||
|
||||
file_storage:
|
||||
triggers: ["upload", "file storage", "images", "media", "CDN"]
|
||||
importance: "medium"
|
||||
affects: "media handling epics"
|
||||
options:
|
||||
s3:
|
||||
pairs_with: ["@aws-sdk/client-s3", "multer"]
|
||||
cloudinary:
|
||||
pairs_with: ["cloudinary"]
|
||||
uploadthing:
|
||||
pairs_with: ["uploadthing"]
|
||||
supabase_storage:
|
||||
pairs_with: ["@supabase/supabase-js"]
|
||||
|
||||
search:
|
||||
triggers: ["search", "full text", "elasticsearch", "algolia", "fuzzy"]
|
||||
importance: "medium"
|
||||
affects: "search and discovery epics"
|
||||
options:
|
||||
postgres_fts:
|
||||
pairs_with: ["PostgreSQL"]
|
||||
elasticsearch:
|
||||
pairs_with: ["@elastic/elasticsearch"]
|
||||
algolia:
|
||||
pairs_with: ["algoliasearch"]
|
||||
typesense:
|
||||
pairs_with: ["typesense"]
|
||||
|
||||
background_jobs:
|
||||
triggers: ["queue", "jobs", "workers", "async", "background processing", "scheduled"]
|
||||
importance: "medium"
|
||||
affects: "async processing epics"
|
||||
options:
|
||||
bullmq:
|
||||
pairs_with: ["Redis"]
|
||||
sqs:
|
||||
pairs_with: ["@aws-sdk/client-sqs"]
|
||||
temporal:
|
||||
pairs_with: ["@temporalio/client"]
|
||||
inngest:
|
||||
pairs_with: ["inngest"]
|
||||
|
||||
deployment_target:
|
||||
triggers: ["deployment", "hosting", "infrastructure", "cloud", "server"]
|
||||
importance: "high"
|
||||
affects: "all epics"
|
||||
options:
|
||||
vercel:
|
||||
pairs_with: ["Next.js", "serverless functions"]
|
||||
aws:
|
||||
pairs_with: ["any stack"]
|
||||
railway:
|
||||
pairs_with: ["any stack", "managed databases"]
|
||||
fly_io:
|
||||
pairs_with: ["Docker containers"]
|
||||
|
||||
# Opinionated stack combinations (BMM methodology)
|
||||
common_stacks:
|
||||
modern_fullstack:
|
||||
name: "Modern Full-Stack"
|
||||
components: ["Next.js", "PostgreSQL or Supabase", "Prisma ORM", "NextAuth.js", "Tailwind CSS", "TypeScript", "Vercel"]
|
||||
good_for: "Most web applications"
|
||||
|
||||
enterprise_stack:
|
||||
name: "Enterprise Stack"
|
||||
components: ["NestJS", "PostgreSQL", "TypeORM", "Auth0", "Redis", "Docker", "AWS"]
|
||||
good_for: "Large-scale enterprise applications"
|
||||
|
||||
rapid_prototype:
|
||||
name: "Rapid Prototype"
|
||||
components: ["Next.js", "Supabase", "shadcn/ui", "Vercel"]
|
||||
good_for: "MVP and rapid development"
|
||||
|
||||
real_time_app:
|
||||
name: "Real-Time Application"
|
||||
components: ["Next.js", "Supabase Realtime", "PostgreSQL", "Prisma", "Socket.io fallback"]
|
||||
good_for: "Chat, collaboration, live updates"
|
||||
|
||||
mobile_app:
|
||||
name: "Mobile Application"
|
||||
components: ["Expo", "React Native", "Supabase or Firebase", "React Query"]
|
||||
good_for: "Cross-platform mobile apps"
|
||||
|
||||
# Starter templates and what decisions they make
|
||||
starter_templates:
|
||||
create_next_app:
|
||||
name: "Create Next App"
|
||||
command_search: "npx create-next-app@latest"
|
||||
decisions_provided: ["Next.js framework", "TypeScript option", "App Router vs Pages", "Tailwind CSS option", "ESLint"]
|
||||
good_for: ["React web applications", "Full-stack apps", "SSR/SSG"]
|
||||
|
||||
create_t3_app:
|
||||
name: "Create T3 App"
|
||||
command_search: "npm create t3-app@latest"
|
||||
decisions_provided: ["Next.js", "TypeScript", "tRPC", "Prisma", "NextAuth", "Tailwind CSS"]
|
||||
good_for: ["Type-safe full-stack apps"]
|
||||
|
||||
create_vite:
|
||||
name: "Create Vite"
|
||||
command_search: "npm create vite@latest"
|
||||
decisions_provided: ["Framework choice (React/Vue/Svelte)", "TypeScript option", "Vite bundler"]
|
||||
good_for: ["Fast dev SPAs", "Library development"]
|
||||
|
||||
create_remix:
|
||||
name: "Create Remix"
|
||||
command_search: "npx create-remix@latest"
|
||||
decisions_provided: ["Remix framework", "TypeScript option", "Deployment target", "CSS solution"]
|
||||
good_for: ["Web standards", "Nested routing", "Progressive enhancement"]
|
||||
|
||||
nest_new:
|
||||
name: "NestJS CLI"
|
||||
command_search: "nest new project"
|
||||
decisions_provided: ["TypeScript (always)", "Package manager", "Testing framework (Jest)", "Project structure"]
|
||||
good_for: ["Enterprise APIs", "Microservices", "GraphQL APIs"]
|
||||
|
||||
create_expo_app:
|
||||
name: "Create Expo App"
|
||||
command_search: "npx create-expo-app"
|
||||
decisions_provided: ["React Native", "Expo SDK", "TypeScript option", "Navigation option"]
|
||||
good_for: ["Cross-platform mobile", "React Native apps"]
|
||||
|
||||
# Starter selection heuristics (workflow logic)
|
||||
starter_selection_rules:
|
||||
by_project_type:
|
||||
web_application:
|
||||
recommended: ["create_next_app", "create_t3_app", "create_vite"]
|
||||
considerations: "SSR needs? → Next.js. Type safety critical? → T3. SPA only? → Vite"
|
||||
|
||||
mobile_app:
|
||||
recommended: ["create_expo_app"]
|
||||
considerations: "Cross-platform → Expo. Native-heavy → React Native CLI"
|
||||
|
||||
api_backend:
|
||||
recommended: ["nest_new"]
|
||||
considerations: "Enterprise → NestJS. Simple → Express starter. Performance → Fastify"
|
||||
|
||||
full_stack:
|
||||
recommended: ["create_t3_app", "create_remix"]
|
||||
considerations: "Type safety → T3. Web standards → Remix. Monolith → RedwoodJS"
|
||||
@@ -0,0 +1,704 @@
|
||||
# Decision Architecture Workflow Instructions
|
||||
|
||||
<workflow name="architecture">
|
||||
|
||||
<critical>The workflow execution engine is governed by: {project-root}/bmad/core/tasks/workflow.xml</critical>
|
||||
<critical>You MUST have already loaded and processed: {installed_path}/workflow.yaml</critical>
|
||||
<critical>This workflow uses ADAPTIVE FACILITATION - adjust your communication style based on {user_skill_level}</critical>
|
||||
<critical>The goal is ARCHITECTURAL DECISIONS that prevent AI agent conflicts, not detailed implementation specs</critical>
|
||||
<critical>Communicate all responses in {communication_language} and tailor to {user_skill_level}</critical>
|
||||
<critical>Generate all documents in {document_output_language}</critical>
|
||||
<critical>This workflow replaces architecture with a conversation-driven approach</critical>
|
||||
<critical>Input documents specified in workflow.yaml input_file_patterns - workflow engine handles fuzzy matching, whole vs sharded document discovery automatically</critical>
|
||||
<critical>ELICITATION POINTS: After completing each major architectural decision area (identified by template-output tags for decision_record, project_structure, novel_pattern_designs, implementation_patterns, and architecture_document), invoke advanced elicitation to refine decisions before proceeding</critical>
|
||||
|
||||
<step n="0" goal="Validate workflow readiness" tag="workflow-status">
|
||||
<action>Check if {output_folder}/bmm-workflow-status.yaml exists</action>
|
||||
|
||||
<check if="status file not found">
|
||||
<output>No workflow status file found. Decision Architecture can run standalone or as part of BMM workflow path.</output>
|
||||
<output>**Recommended:** Run `workflow-init` first for project context tracking and workflow sequencing.</output>
|
||||
<ask>Continue in standalone mode or exit to run workflow-init? (continue/exit)</ask>
|
||||
<check if="continue">
|
||||
<action>Set standalone_mode = true</action>
|
||||
</check>
|
||||
<check if="exit">
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="status file found">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Parse workflow_status section</action>
|
||||
<action>Check status of "create-architecture" workflow</action>
|
||||
<action>Get project_level from YAML metadata</action>
|
||||
<action>Find first non-completed workflow (next expected workflow)</action>
|
||||
|
||||
<check if="project_level < 3">
|
||||
<output>**Note: Level {{project_level}} Project**
|
||||
|
||||
The Detailed Architecture is typically for Level 3-4 projects, but can be used for any project that needs architectural planning.
|
||||
|
||||
For Level {{project_level}}, we'll keep the architecture appropriately scoped.
|
||||
</output>
|
||||
</check>
|
||||
|
||||
<check if="create-architecture status is file path (already completed)">
|
||||
<output>⚠️ Architecture already completed: {{create-architecture status}}</output>
|
||||
<ask>Re-running will overwrite the existing architecture. Continue? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Use workflow-status to see your next step.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<check if="create-architecture is not the next expected workflow">
|
||||
<output>⚠️ Next expected workflow: {{next_workflow}}. Architecture is out of sequence.</output>
|
||||
<ask>Continue with Architecture anyway? (y/n)</ask>
|
||||
<check if="n">
|
||||
<output>Exiting. Run {{next_workflow}} instead.</output>
|
||||
<action>Exit workflow</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Set standalone_mode = false</action>
|
||||
</check>
|
||||
|
||||
<action>Check for existing PRD and epics files using fuzzy matching</action>
|
||||
|
||||
<action>Fuzzy match PRD file: {prd_file}</action>
|
||||
<check if="PRD_not_found">
|
||||
<output>**PRD Not Found**
|
||||
|
||||
Decision Architecture works from your Product Requirements Document (PRD).
|
||||
|
||||
Looking for: _PRD_, PRD.md, or prd/index.md + files in {output_folder}
|
||||
|
||||
Please run the PRD workflow first to define your requirements.
|
||||
|
||||
Architect: `create-prd`
|
||||
</output>
|
||||
<action>Exit workflow - PRD required</action>
|
||||
</check>
|
||||
|
||||
</step>
|
||||
|
||||
<step n="1" goal="Load and understand project context">
|
||||
<action>Load the PRD using fuzzy matching: {prd_file}, if the PRD is mulitple files in a folder, load the index file and all files associated with the PRD</action>
|
||||
<action>Load epics file using fuzzy matching: {epics_file}</action>
|
||||
|
||||
<action>Check for UX specification using fuzzy matching:
|
||||
<action>Attempt to locate: {ux_spec_file}</action>
|
||||
<check if="ux_spec_found">
|
||||
<action>Load UX spec and extract architectural implications: - Component complexity (simple forms vs rich interactions) - Animation/transition requirements - Real-time update needs (live data, collaborative features) - Platform-specific UI requirements - Accessibility standards (WCAG compliance level) - Responsive design breakpoints - Offline capability requirements - Performance expectations (load times, interaction responsiveness)
|
||||
</action>
|
||||
</check>
|
||||
</action>
|
||||
|
||||
<action>Extract and understand from PRD: - Functional Requirements (what it must do) - Non-Functional Requirements (performance, security, compliance, etc.) - Epic structure and user stories - Acceptance criteria - Any technical constraints mentioned
|
||||
</action>
|
||||
|
||||
<action>Count and assess project scale: - Number of epics: {{epic_count}} - Number of stories: {{story_count}} - Complexity indicators (real-time, multi-tenant, regulated, etc.) - UX complexity level (if UX spec exists) - Novel features
|
||||
</action>
|
||||
|
||||
<action>Reflect understanding back to {user_name}:
|
||||
"I'm reviewing your project documentation for {{project_name}}.
|
||||
I see {{epic_count}} epics with {{story_count}} total stories.
|
||||
{{if_ux_spec}}I also found your UX specification which defines the user experience requirements.{{/if_ux_spec}}
|
||||
|
||||
Key aspects I notice:
|
||||
- [Summarize core functionality]
|
||||
- [Note critical NFRs]
|
||||
{{if_ux_spec}}- [Note UX complexity and requirements]{{/if_ux_spec}}
|
||||
- [Identify unique challenges]
|
||||
|
||||
This will help me guide you through the architectural decisions needed
|
||||
to ensure AI agents implement this consistently."
|
||||
|
||||
</action>
|
||||
|
||||
<ask>Does this match your understanding of the project?</ask>
|
||||
<template-output>project_context_understanding</template-output>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Discover and evaluate starter templates">
|
||||
<critical>Modern starter templates make many good architectural decisions by default</critical>
|
||||
|
||||
<action>Based on PRD analysis, identify the primary technology domain: - Web application → Look for Next.js, Vite, Remix starters - Mobile app → Look for React Native, Expo, Flutter starters - API/Backend → Look for NestJS, Express, Fastify starters - CLI tool → Look for CLI framework starters - Full-stack → Look for T3, RedwoodJS, Blitz starters
|
||||
</action>
|
||||
|
||||
<check if="ux_spec_loaded">
|
||||
<action>Consider UX requirements when selecting starter:
|
||||
- Rich animations → Framer Motion compatible starter
|
||||
- Complex forms → React Hook Form included starter
|
||||
- Real-time features → Socket.io or WebSocket ready starter
|
||||
- Accessibility focus → WCAG-compliant component library starter
|
||||
- Design system → Storybook-enabled starter
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<action>Search for relevant starter templates with websearch, examples:
|
||||
<WebSearch>{{primary_technology}} starter template CLI create command latest {date}</WebSearch>
|
||||
<WebSearch>{{primary_technology}} boilerplate generator latest options</WebSearch>
|
||||
</action>
|
||||
|
||||
<check if="starter_templates_found">
|
||||
<action>Investigate what each starter provides:
|
||||
<WebSearch>{{starter_name}} default setup technologies included latest</WebSearch>
|
||||
<WebSearch>{{starter_name}} project structure file organization</WebSearch>
|
||||
</action>
|
||||
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
<action>Present starter options concisely:
|
||||
"Found {{starter_name}} which provides:
|
||||
{{quick_decision_list}}
|
||||
|
||||
This would establish our base architecture. Use it?"
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
<action>Explain starter benefits:
|
||||
"I found {{starter_name}}, which is like a pre-built foundation for your project.
|
||||
|
||||
Think of it like buying a prefab house frame instead of cutting each board yourself.
|
||||
|
||||
It makes these decisions for you:
|
||||
{{friendly_decision_list}}
|
||||
|
||||
This is a great starting point that follows best practices. Should we use it?"
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<ask>Use {{starter_name}} as the foundation? (recommended) [y/n]</ask>
|
||||
|
||||
<check if="user_accepts_starter">
|
||||
<action>Get current starter command and options:
|
||||
<WebSearch>{{starter_name}} CLI command options flags latest 2024</WebSearch>
|
||||
</action>
|
||||
|
||||
<action>Document the initialization command:
|
||||
Store command: {{full_starter_command_with_options}}
|
||||
Example: "npx create-next-app@latest my-app --typescript --tailwind --app"
|
||||
</action>
|
||||
|
||||
<action>Extract and document starter-provided decisions:
|
||||
Starter provides these architectural decisions:
|
||||
- Language/TypeScript: {{provided_or_not}}
|
||||
- Styling solution: {{provided_or_not}}
|
||||
- Testing framework: {{provided_or_not}}
|
||||
- Linting/Formatting: {{provided_or_not}}
|
||||
- Build tooling: {{provided_or_not}}
|
||||
- Project structure: {{provided_pattern}}
|
||||
</action>
|
||||
|
||||
<action>Mark these decisions as "PROVIDED BY STARTER" in our decision tracking</action>
|
||||
|
||||
<action>Note for first implementation story:
|
||||
"Project initialization using {{starter_command}} should be the first implementation story"
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<check if="user_rejects_starter">
|
||||
<ask>Any specific reason to avoid the starter? (helps me understand constraints)</ask>
|
||||
<action>Note: Manual setup required, all decisions need to be made explicitly</action>
|
||||
</check>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="no_starter_found_or_applicable">
|
||||
<action>Note: No standard starter template found for this project type.
|
||||
We will make all architectural decisions explicitly.</action>
|
||||
</check>
|
||||
|
||||
<template-output>starter_template_decision</template-output>
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Adapt facilitation style and identify remaining decisions">
|
||||
<action>Based on {user_skill_level} from config, set facilitation approach:
|
||||
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
Set mode: EXPERT
|
||||
- Use technical terminology freely
|
||||
- Move quickly through decisions
|
||||
- Assume familiarity with patterns and tools
|
||||
- Focus on edge cases and advanced concerns
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'intermediate'">
|
||||
Set mode: INTERMEDIATE
|
||||
- Balance technical accuracy with clarity
|
||||
- Explain complex patterns briefly
|
||||
- Confirm understanding at key points
|
||||
- Provide context for non-obvious choices
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
Set mode: BEGINNER
|
||||
- Use analogies and real-world examples
|
||||
- Explain technical concepts in simple terms
|
||||
- Provide education about why decisions matter
|
||||
- Protect from complexity overload
|
||||
</check>
|
||||
</action>
|
||||
|
||||
<action>Load decision catalog: {decision_catalog}</action>
|
||||
<action>Load architecture patterns: {architecture_patterns}</action>
|
||||
|
||||
<action>Analyze PRD against patterns to identify needed decisions: - Match functional requirements to known patterns - Identify which categories of decisions are needed - Flag any novel/unique aspects requiring special attention - Consider which decisions the starter template already made (if applicable)
|
||||
</action>
|
||||
|
||||
<action>Create decision priority list:
|
||||
CRITICAL (blocks everything): - {{list_of_critical_decisions}}
|
||||
|
||||
IMPORTANT (shapes architecture):
|
||||
- {{list_of_important_decisions}}
|
||||
|
||||
NICE-TO-HAVE (can defer):
|
||||
- {{list_of_optional_decisions}}
|
||||
|
||||
</action>
|
||||
|
||||
<action>Announce plan to {user_name} based on mode:
|
||||
<check if="mode == 'EXPERT'">
|
||||
"Based on your PRD, we need to make {{total_decision_count}} architectural decisions.
|
||||
{{starter_covered_count}} are covered by the starter template.
|
||||
Let's work through the remaining {{remaining_count}} decisions."
|
||||
</check>
|
||||
|
||||
<check if="mode == 'BEGINNER'">
|
||||
"Great! I've analyzed your requirements and found {{total_decision_count}} technical
|
||||
choices we need to make. Don't worry - I'll guide you through each one and explain
|
||||
why it matters. {{if_starter}}The starter template handles {{starter_covered_count}}
|
||||
of these automatically.{{/if_starter}}"
|
||||
</check>
|
||||
|
||||
</action>
|
||||
|
||||
<template-output>decision_identification</template-output>
|
||||
</step>
|
||||
|
||||
<step n="4" goal="Facilitate collaborative decision making" repeat="for-each-decision">
|
||||
<critical>Each decision must be made WITH the user, not FOR them</critical>
|
||||
<critical>ALWAYS verify current versions using WebSearch - NEVER trust hardcoded versions</critical>
|
||||
|
||||
<action>For each decision in priority order:</action>
|
||||
|
||||
<action>Present the decision based on mode:
|
||||
<check if="mode == 'EXPERT'">
|
||||
"{{Decision_Category}}: {{Specific_Decision}}
|
||||
|
||||
Options: {{concise_option_list_with_tradeoffs}}
|
||||
|
||||
Recommendation: {{recommendation}} for {{reason}}"
|
||||
|
||||
</check>
|
||||
|
||||
<check if="mode == 'INTERMEDIATE'">
|
||||
"Next decision: {{Human_Friendly_Category}}
|
||||
|
||||
We need to choose {{Specific_Decision}}.
|
||||
|
||||
Common options:
|
||||
{{option_list_with_brief_explanations}}
|
||||
|
||||
For your project, {{recommendation}} would work well because {{reason}}."
|
||||
|
||||
</check>
|
||||
|
||||
<check if="mode == 'BEGINNER'">
|
||||
"Let's talk about {{Human_Friendly_Category}}.
|
||||
|
||||
{{Educational_Context_About_Why_This_Matters}}
|
||||
|
||||
Think of it like {{real_world_analogy}}.
|
||||
|
||||
Your main options:
|
||||
{{friendly_options_with_pros_cons}}
|
||||
|
||||
My suggestion: {{recommendation}}
|
||||
This is good for you because {{beginner_friendly_reason}}."
|
||||
|
||||
</check>
|
||||
|
||||
</action>
|
||||
|
||||
<check if="decision_involves_specific_technology">
|
||||
<action>Verify current stable version:
|
||||
<WebSearch>{{technology}} latest stable version 2024</WebSearch>
|
||||
<WebSearch>{{technology}} current LTS version</WebSearch>
|
||||
</action>
|
||||
|
||||
<action>Update decision record with verified version:
|
||||
Technology: {{technology}}
|
||||
Verified Version: {{version_from_search}}
|
||||
Verification Date: {{today}}
|
||||
</action>
|
||||
|
||||
</check>
|
||||
|
||||
<ask>What's your preference? (or 'explain more' for details)</ask>
|
||||
|
||||
<check if="user_wants_more_info">
|
||||
<action>Provide deeper explanation appropriate to skill level</action>
|
||||
<check if="complex_tradeoffs">
|
||||
<action>Consider using advanced elicitation:
|
||||
"Would you like to explore innovative approaches to this decision?
|
||||
I can help brainstorm unconventional solutions if you have specific goals."
|
||||
</action>
|
||||
</check>
|
||||
</check>
|
||||
|
||||
<action>Record decision:
|
||||
Category: {{category}}
|
||||
Decision: {{user_choice}}
|
||||
Version: {{verified_version_if_applicable}}
|
||||
Affects Epics: {{list_of_affected_epics}}
|
||||
Rationale: {{user_reasoning_or_default}}
|
||||
Provided by Starter: {{yes_if_from_starter}}
|
||||
</action>
|
||||
|
||||
<action>Check for cascading implications:
|
||||
"This choice means we'll also need to {{related_decisions}}"
|
||||
</action>
|
||||
|
||||
<template-output>decision_record</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="5" goal="Address cross-cutting concerns">
|
||||
<critical>These decisions affect EVERY epic and story</critical>
|
||||
|
||||
<action>Facilitate decisions for consistency patterns: - Error handling strategy (How will all agents handle errors?) - Logging approach (Structured? Format? Levels?) - Date/time handling (Timezone? Format? Library?) - Authentication pattern (Where? How? Token format?) - API response format (Structure? Status codes? Errors?) - Testing strategy (Unit? Integration? E2E?)
|
||||
</action>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
<action>Explain why these matter why its critical to go through and decide these things now.</action>
|
||||
</check>
|
||||
|
||||
<template-output>cross_cutting_decisions</template-output>
|
||||
</step>
|
||||
|
||||
<step n="6" goal="Define project structure and boundaries">
|
||||
<action>Based on all decisions made, define the project structure</action>
|
||||
|
||||
<action>Create comprehensive source tree: - Root configuration files - Source code organization - Test file locations - Build/dist directories - Documentation structure
|
||||
</action>
|
||||
|
||||
<action>Map epics to architectural boundaries:
|
||||
"Epic: {{epic_name}} → Lives in {{module/directory/service}}"
|
||||
</action>
|
||||
|
||||
<action>Define integration points: - Where do components communicate? - What are the API boundaries? - How do services interact?
|
||||
</action>
|
||||
|
||||
<template-output>project_structure</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="7" goal="Design novel architectural patterns" optional="true">
|
||||
<critical>Some projects require INVENTING new patterns, not just choosing existing ones</critical>
|
||||
|
||||
<action>Scan PRD for concepts that don't have standard solutions: - Novel interaction patterns (e.g., "swipe to match" before Tinder existed) - Unique multi-component workflows (e.g., "viral invitation system") - New data relationships (e.g., "social graph" before Facebook) - Unprecedented user experiences (e.g., "ephemeral messages" before Snapchat) - Complex state machines crossing multiple epics
|
||||
</action>
|
||||
|
||||
<check if="novel_patterns_detected">
|
||||
<action>For each novel pattern identified:</action>
|
||||
|
||||
<action>Engage user in design collaboration:
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
"The {{pattern_name}} concept requires architectural innovation.
|
||||
|
||||
Core challenge: {{challenge_description}}
|
||||
|
||||
Let's design the component interaction model:"
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
"Your idea about {{pattern_name}} is unique - there isn't a standard way to build this yet!
|
||||
|
||||
This is exciting - we get to invent the architecture together.
|
||||
|
||||
Let me help you think through how this should work:"
|
||||
</check>
|
||||
</action>
|
||||
|
||||
<action>Facilitate pattern design:
|
||||
1. Identify core components involved
|
||||
2. Map data flow between components
|
||||
3. Design state management approach
|
||||
4. Create sequence diagrams for complex flows
|
||||
5. Define API contracts for the pattern
|
||||
6. Consider edge cases and failure modes
|
||||
</action>
|
||||
|
||||
<action>Use advanced elicitation for innovation:
|
||||
"What if we approached this differently?
|
||||
- What would the ideal user experience look like?
|
||||
- Are there analogies from other domains we could apply?
|
||||
- What constraints can we challenge?"
|
||||
</action>
|
||||
|
||||
<action>Document the novel pattern:
|
||||
Pattern Name: {{pattern_name}}
|
||||
Purpose: {{what_problem_it_solves}}
|
||||
Components:
|
||||
{{component_list_with_responsibilities}}
|
||||
Data Flow:
|
||||
{{sequence_description_or_diagram}}
|
||||
Implementation Guide:
|
||||
{{how_agents_should_build_this}}
|
||||
Affects Epics:
|
||||
{{epics_that_use_this_pattern}}
|
||||
</action>
|
||||
|
||||
<action>Validate pattern completeness:
|
||||
"Does this {{pattern_name}} design cover all the use cases in your epics?
|
||||
- {{use_case_1}}: ✓ Handled by {{component}}
|
||||
- {{use_case_2}}: ✓ Handled by {{component}}
|
||||
..."
|
||||
</action>
|
||||
|
||||
</check>
|
||||
|
||||
<check if="no_novel_patterns">
|
||||
<action>Note: All patterns in this project have established solutions.
|
||||
Proceeding with standard architectural patterns.</action>
|
||||
</check>
|
||||
|
||||
<template-output>novel_pattern_designs</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="8" goal="Define implementation patterns to prevent agent conflicts">
|
||||
<critical>These patterns ensure multiple AI agents write compatible code</critical>
|
||||
<critical>Focus on what agents could decide DIFFERENTLY if not specified</critical>
|
||||
|
||||
<action>Load pattern categories: {pattern_categories}</action>
|
||||
|
||||
<action>Based on chosen technologies, identify potential conflict points:
|
||||
"Given that we're using {{tech_stack}}, agents need consistency rules for:"
|
||||
</action>
|
||||
|
||||
<action>For each relevant pattern category, facilitate decisions:
|
||||
|
||||
NAMING PATTERNS (How things are named):
|
||||
<check if="has_api">
|
||||
- REST endpoint naming: /users or /user? Plural or singular?
|
||||
- Route parameter format: :id or {id}?
|
||||
</check>
|
||||
<check if="has_database">
|
||||
- Table naming: users or Users or user?
|
||||
- Column naming: user_id or userId?
|
||||
- Foreign key format: user_id or fk_user?
|
||||
</check>
|
||||
<check if="has_frontend">
|
||||
- Component naming: UserCard or user-card?
|
||||
- File naming: UserCard.tsx or user-card.tsx?
|
||||
</check>
|
||||
|
||||
STRUCTURE PATTERNS (How things are organized):
|
||||
- Where do tests live? __tests__/ or *.test.ts co-located?
|
||||
- How are components organized? By feature or by type?
|
||||
- Where do shared utilities go?
|
||||
|
||||
FORMAT PATTERNS (Data exchange formats):
|
||||
<check if="has_api">
|
||||
- API response wrapper? {data: ..., error: ...} or direct response?
|
||||
- Error format? {message, code} or {error: {type, detail}}?
|
||||
- Date format in JSON? ISO strings or timestamps?
|
||||
</check>
|
||||
|
||||
COMMUNICATION PATTERNS (How components interact):
|
||||
<check if="has_events">
|
||||
- Event naming convention?
|
||||
- Event payload structure?
|
||||
</check>
|
||||
<check if="has_state_management">
|
||||
- State update pattern?
|
||||
- Action naming convention?
|
||||
</check>
|
||||
|
||||
LIFECYCLE PATTERNS (State and flow):
|
||||
- How are loading states handled?
|
||||
- What's the error recovery pattern?
|
||||
- How are retries implemented?
|
||||
|
||||
LOCATION PATTERNS (Where things go):
|
||||
- API route structure?
|
||||
- Static asset organization?
|
||||
- Config file locations?
|
||||
|
||||
CONSISTENCY PATTERNS (Cross-cutting):
|
||||
- How are dates formatted in the UI?
|
||||
- What's the logging format?
|
||||
- How are user-facing errors written?
|
||||
|
||||
</action>
|
||||
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
<action>Rapid-fire through patterns:
|
||||
"Quick decisions on implementation patterns:
|
||||
- {{pattern}}: {{suggested_convention}} OK? [y/n/specify]"
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
<action>Explain each pattern's importance:
|
||||
"Let me explain why this matters:
|
||||
If one AI agent names database tables 'users' and another names them 'Users',
|
||||
your app will crash. We need to pick one style and make sure everyone follows it."
|
||||
</action>
|
||||
</check>
|
||||
|
||||
<action>Document implementation patterns:
|
||||
Category: {{pattern_category}}
|
||||
Pattern: {{specific_pattern}}
|
||||
Convention: {{decided_convention}}
|
||||
Example: {{concrete_example}}
|
||||
Enforcement: "All agents MUST follow this pattern"
|
||||
</action>
|
||||
|
||||
<template-output>implementation_patterns</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="9" goal="Validate architectural coherence">
|
||||
<action>Run coherence checks:</action>
|
||||
|
||||
<action>Check decision compatibility: - Do all decisions work together? - Are there any conflicting choices? - Do the versions align properly?
|
||||
</action>
|
||||
|
||||
<action>Verify epic coverage: - Does every epic have architectural support? - Are all user stories implementable with these decisions? - Are there any gaps?
|
||||
</action>
|
||||
|
||||
<action>Validate pattern completeness: - Are there any patterns we missed that agents would need? - Do novel patterns integrate with standard architecture? - Are implementation patterns comprehensive enough?
|
||||
</action>
|
||||
|
||||
<check if="issues_found">
|
||||
<action>Address issues with {user_name}:
|
||||
"I notice {{issue_description}}.
|
||||
We should {{suggested_resolution}}."
|
||||
</action>
|
||||
<ask>How would you like to resolve this?</ask>
|
||||
<action>Update decisions based on resolution</action>
|
||||
</check>
|
||||
|
||||
<template-output>coherence_validation</template-output>
|
||||
</step>
|
||||
|
||||
<step n="10" goal="Generate decision architecture document">
|
||||
<critical>The document must be complete, specific, and validation-ready</critical>
|
||||
<critical>This is the consistency contract for all AI agents</critical>
|
||||
|
||||
<action>Load template: {architecture_template}</action>
|
||||
|
||||
<action>Generate sections: 1. Executive Summary (2-3 sentences about the architecture approach) 2. Project Initialization (starter command if applicable) 3. Decision Summary Table (with verified versions and epic mapping) 4. Complete Project Structure (full tree, no placeholders) 5. Epic to Architecture Mapping (every epic placed) 6. Technology Stack Details (versions, configurations) 7. Integration Points (how components connect) 8. Novel Pattern Designs (if any were created) 9. Implementation Patterns (all consistency rules) 10. Consistency Rules (naming, organization, formats) 11. Data Architecture (models and relationships) 12. API Contracts (request/response formats) 13. Security Architecture (auth, authorization, data protection) 14. Performance Considerations (from NFRs) 15. Deployment Architecture (where and how) 16. Development Environment (setup and prerequisites) 17. Architecture Decision Records (key decisions with rationale)
|
||||
</action>
|
||||
|
||||
<action>Fill template with all collected decisions and patterns</action>
|
||||
|
||||
<action>Ensure starter command is first implementation story:
|
||||
<check if="using_starter_template">
|
||||
"## Project Initialization
|
||||
|
||||
First implementation story should execute:
|
||||
```bash
|
||||
{{starter_command_with_options}}
|
||||
```
|
||||
|
||||
This establishes the base architecture with these decisions:
|
||||
{{starter_provided_decisions}}"
|
||||
</check>
|
||||
|
||||
</action>
|
||||
|
||||
<template-output>architecture_document</template-output>
|
||||
<invoke-task halt="true">{project-root}/bmad/core/tasks/adv-elicit.xml</invoke-task>
|
||||
</step>
|
||||
|
||||
<step n="11" goal="Validate document completeness">
|
||||
<action>Load validation checklist: {installed_path}/checklist.md</action>
|
||||
|
||||
<action>Run validation checklist from {installed_path}/checklist.md</action>
|
||||
|
||||
<action>Verify MANDATORY items:
|
||||
□ Decision table has Version column with specific versions
|
||||
□ Every epic is mapped to architecture components
|
||||
□ Source tree is complete, not generic
|
||||
□ No placeholder text remains
|
||||
□ All FRs from PRD have architectural support
|
||||
□ All NFRs from PRD are addressed
|
||||
□ Implementation patterns cover all potential conflicts
|
||||
□ Novel patterns are fully documented (if applicable)
|
||||
</action>
|
||||
|
||||
<check if="validation_failed">
|
||||
<action>Fix missing items automatically</action>
|
||||
<goto step="10">Regenerate document section</goto>
|
||||
</check>
|
||||
|
||||
<template-output>validation_results</template-output>
|
||||
</step>
|
||||
|
||||
<step n="12" goal="Final review and update workflow status">
|
||||
<action>Present completion summary:</action>
|
||||
|
||||
<check if="{user_skill_level} == 'expert'">
|
||||
"Architecture complete. {{decision_count}} decisions documented.
|
||||
Ready for implementation phase."
|
||||
</check>
|
||||
|
||||
<check if="{user_skill_level} == 'beginner'">
|
||||
"Excellent! Your architecture is complete. You made {{decision_count}} important
|
||||
decisions that will keep AI agents consistent as they build your app.
|
||||
|
||||
What happens next:
|
||||
1. AI agents will read this architecture before implementing each story
|
||||
2. They'll follow your technical choices exactly
|
||||
3. Your app will be built with consistent patterns throughout
|
||||
|
||||
You're ready to move to the implementation phase!"
|
||||
|
||||
</check>
|
||||
|
||||
<action>Save document to {output_folder}/architecture.md</action>
|
||||
|
||||
<check if="standalone_mode != true">
|
||||
<action>Load the FULL file: {output_folder}/bmm-workflow-status.yaml</action>
|
||||
<action>Find workflow_status key "create-architecture"</action>
|
||||
<critical>ONLY write the file path as the status value - no other text, notes, or metadata</critical>
|
||||
<action>Update workflow_status["create-architecture"] = "{output_folder}/bmm-architecture-{{date}}.md"</action>
|
||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||
|
||||
<action>Find first non-completed workflow in workflow_status (next workflow to do)</action>
|
||||
<action>Determine next agent from path file based on next workflow</action>
|
||||
|
||||
</check>
|
||||
|
||||
<output>✅ Decision Architecture workflow complete!</output>
|
||||
|
||||
<output>**Deliverables Created:**
|
||||
|
||||
- ✅ architecture.md - Complete architectural decisions document
|
||||
{{if_novel_patterns}}
|
||||
- ✅ Novel pattern designs for unique concepts
|
||||
{{/if_novel_patterns}}
|
||||
{{if_starter_template}}
|
||||
- ✅ Project initialization command documented
|
||||
{{/if_starter_template}}
|
||||
|
||||
The architecture is ready to guide AI agents through consistent implementation.
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
- **Next required:** {{next_workflow}} ({{next_agent}} agent)
|
||||
- Review the architecture.md document before proceeding
|
||||
|
||||
Check status anytime with: `workflow-status`
|
||||
</output>
|
||||
|
||||
<template-output>completion_summary</template-output>
|
||||
</step>
|
||||
|
||||
</workflow>
|
||||
@@ -0,0 +1,13 @@
|
||||
category,when_needed,what_to_define,why_critical
|
||||
naming_patterns,Any technology with named entities,How things are named (format/case/structure),Agents will create different names for same concept
|
||||
structure_patterns,Any technology with organization,How things are organized (folders/modules/layers),Agents will put things in different places
|
||||
format_patterns,Any technology with data exchange,How data is formatted (JSON/XML/responses),Agents will use incompatible formats
|
||||
communication_patterns,Any technology with inter-component communication,How components talk (protocols/events/messages),Agents will use different communication methods
|
||||
lifecycle_patterns,Any technology with state or flow,How state changes and flows work,Agents will handle state transitions differently
|
||||
location_patterns,Any technology with storage or routing,Where things go (URLs/paths/storage),Agents will put things in different locations
|
||||
consistency_patterns,Always,Cross-cutting concerns (dates/errors/logs),Every agent will do these differently
|
||||
|
||||
# PRINCIPLE FOR LLM:
|
||||
# Any time multiple agents might make the SAME decision DIFFERENTLY, that's a pattern to capture.
|
||||
# Think about: What could an agent encounter where they'd have to guess?
|
||||
# If they'd guess, define the pattern. If it's obvious from the tech choice, skip it.
|
||||
|
@@ -0,0 +1,67 @@
|
||||
# Game Architecture Workflow Configuration
|
||||
name: game-architecture
|
||||
description: "Collaborative game architecture workflow for AI-agent consistency. Intelligent, adaptive conversation that produces a decision-focused game architecture document covering engine, systems, networking, and technical design optimized for game development."
|
||||
author: "BMad"
|
||||
|
||||
# Critical variables
|
||||
config_source: "{project-root}/bmad/bmgd/config.yaml"
|
||||
output_folder: "{config_source}:output_folder"
|
||||
user_name: "{config_source}:user_name"
|
||||
communication_language: "{config_source}:communication_language"
|
||||
document_output_language: "{config_source}:document_output_language"
|
||||
game_dev_experience: "{config_source}:game_dev_experience"
|
||||
date: system-generated
|
||||
|
||||
# Input requirements - We work from GDD, Epics, and optionally Narrative Design
|
||||
recommended_inputs:
|
||||
- gdd: "Game Design Document with mechanics, systems, and features"
|
||||
- epics: "Epic definitions with user stories and acceptance criteria"
|
||||
- narrative: "Narrative design document with story and character systems (optional)"
|
||||
|
||||
# Smart input file references - handles both whole docs and sharded docs
|
||||
# Priority: Whole document first, then sharded version
|
||||
input_file_patterns:
|
||||
gdd:
|
||||
whole: "{output_folder}/*gdd*.md"
|
||||
sharded: "{output_folder}/*gdd*/index.md"
|
||||
|
||||
epics:
|
||||
whole: "{output_folder}/*epic*.md"
|
||||
sharded: "{output_folder}/*epic*/index.md"
|
||||
|
||||
narrative:
|
||||
whole: "{output_folder}/*narrative*.md"
|
||||
sharded: "{output_folder}/*narrative*/index.md"
|
||||
|
||||
document_project:
|
||||
sharded: "{output_folder}/docs/index.md"
|
||||
|
||||
# Module path and component files
|
||||
installed_path: "{project-root}/bmad/bmgd/workflows/3-technical/game-architecture"
|
||||
instructions: "{installed_path}/instructions.md"
|
||||
validation: "{installed_path}/checklist.md"
|
||||
template: "{installed_path}/architecture-template.md"
|
||||
|
||||
# Knowledge bases for intelligent decision making
|
||||
decision_catalog: "{installed_path}/decision-catalog.yaml"
|
||||
architecture_patterns: "{installed_path}/architecture-patterns.yaml"
|
||||
pattern_categories: "{installed_path}/pattern-categories.csv"
|
||||
|
||||
# Output configuration
|
||||
default_output_file: "{output_folder}/game-architecture.md"
|
||||
|
||||
# Workflow metadata
|
||||
version: "1.3.2"
|
||||
replaces: "architecture"
|
||||
paradigm: "facilitation-driven"
|
||||
execution_time: "30-90 minutes depending on user skill level"
|
||||
features:
|
||||
- "Starter template discovery and integration"
|
||||
- "Dynamic version verification via web search"
|
||||
- "Adaptive facilitation by skill level"
|
||||
- "Decision-focused architecture"
|
||||
- "Novel pattern design for unique concepts"
|
||||
- "Intelligent pattern identification - LLM figures out what patterns matter"
|
||||
- "Implementation patterns for agent consistency"
|
||||
|
||||
standalone: true
|
||||
Reference in New Issue
Block a user