ros/BMAD-METHOD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Godot Game Dev expansion pack for BMAD (#532)

Browse Source 
* Godot Game Dev expansion pack for BMAD

* Workflow changes

* Workflow changes

* Fixing config.yaml, editing README.md to indicate correct workflow

* Fixing references to config.yaml, adding missing QA review to game-dev agent

* More game story creation fixes

* More game story creation fixes

* Adding built web agent file

* - Adding ability for QA agent to have preloaded context files similar to Dev agent.
- Fixing stray Unity references in game-architecture-tmpl.yaml

---------

Co-authored-by: Brian <bmadcode@gmail.com>
This commit is contained in:
sjennings
2025-09-06 13:49:21 -05:00
committed by GitHub
parent 076c104b2c
commit f20d572216
71 changed files with 64443 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

156
expansion-packs/bmad-godot-game-dev/templates/brainstorming-output-tmpl.yaml Normal file
View File

@@ -0,0 +1,156 @@
template:
id: brainstorming-output-template-v2
name: Brainstorming Session Results
version: 2.0
output:
format: markdown
filename: docs/brainstorming-session-results.md
title: "Brainstorming Session Results"
workflow:
mode: non-interactive
sections:
- id: header
content: |
**Session Date:** {{date}}
**Facilitator:** {{agent_role}} {{agent_name}}
**Participant:** {{user_name}}
- id: executive-summary
title: Executive Summary
sections:
- id: summary-details
template: |
**Topic:** {{session_topic}}
**Session Goals:** {{stated_goals}}
**Techniques Used:** {{techniques_list}}
**Total Ideas Generated:** {{total_ideas}}
- id: key-themes
title: "Key Themes Identified:"
type: bullet-list
template: "- {{theme}}"
- id: technique-sessions
title: Technique Sessions
repeatable: true
sections:
- id: technique
title: "{{technique_name}} - {{duration}}"
sections:
- id: description
template: "**Description:** {{technique_description}}"
- id: ideas-generated
title: "Ideas Generated:"
type: numbered-list
template: "{{idea}}"
- id: insights
title: "Insights Discovered:"
type: bullet-list
template: "- {{insight}}"
- id: connections
title: "Notable Connections:"
type: bullet-list
template: "- {{connection}}"
- id: idea-categorization
title: Idea Categorization
sections:
- id: immediate-opportunities
title: Immediate Opportunities
content: "*Ideas ready to implement now*"
repeatable: true
type: numbered-list
template: |
**{{idea_name}}**
- Description: {{description}}
- Why immediate: {{rationale}}
- Resources needed: {{requirements}}
- id: future-innovations
title: Future Innovations
content: "*Ideas requiring development/research*"
repeatable: true
type: numbered-list
template: |
**{{idea_name}}**
- Description: {{description}}
- Development needed: {{development_needed}}
- Timeline estimate: {{timeline}}
- id: moonshots
title: Moonshots
content: "*Ambitious, transformative concepts*"
repeatable: true
type: numbered-list
template: |
**{{idea_name}}**
- Description: {{description}}
- Transformative potential: {{potential}}
- Challenges to overcome: {{challenges}}
- id: insights-learnings
title: Insights & Learnings
content: "*Key realizations from the session*"
type: bullet-list
template: "- {{insight}}: {{description_and_implications}}"
- id: action-planning
title: Action Planning
sections:
- id: top-priorities
title: Top 3 Priority Ideas
sections:
- id: priority-1
title: "#1 Priority: {{idea_name}}"
template: |
- Rationale: {{rationale}}
- Next steps: {{next_steps}}
- Resources needed: {{resources}}
- Timeline: {{timeline}}
- id: priority-2
title: "#2 Priority: {{idea_name}}"
template: |
- Rationale: {{rationale}}
- Next steps: {{next_steps}}
- Resources needed: {{resources}}
- Timeline: {{timeline}}
- id: priority-3
title: "#3 Priority: {{idea_name}}"
template: |
- Rationale: {{rationale}}
- Next steps: {{next_steps}}
- Resources needed: {{resources}}
- Timeline: {{timeline}}
- id: reflection-followup
title: Reflection & Follow-up
sections:
- id: what-worked
title: What Worked Well
type: bullet-list
template: "- {{aspect}}"
- id: areas-exploration
title: Areas for Further Exploration
type: bullet-list
template: "- {{area}}: {{reason}}"
- id: recommended-techniques
title: Recommended Follow-up Techniques
type: bullet-list
template: "- {{technique}}: {{reason}}"
- id: questions-emerged
title: Questions That Emerged
type: bullet-list
template: "- {{question}}"
- id: next-session
title: Next Session Planning
template: |
- **Suggested topics:** {{followup_topics}}
- **Recommended timeframe:** {{timeframe}}
- **Preparation needed:** {{preparation}}
- id: footer
content: |
---
*Session facilitated using the BMAD-METHOD brainstorming framework*

281
expansion-packs/bmad-godot-game-dev/templates/brownfield-prd-tmpl.yaml Normal file
View File

@@ -0,0 +1,281 @@
# <!-- Powered by BMAD™ Core -->
template:
id: brownfield-prd-template-v2
name: Brownfield Enhancement PRD
version: 2.0
output:
format: markdown
filename: docs/prd.md
title: "{{project_name}} Brownfield Enhancement PRD"
workflow:
mode: interactive
elicitation: advanced-elicitation
sections:
- id: intro-analysis
title: Intro Project Analysis and Context
instruction: |
IMPORTANT - SCOPE ASSESSMENT REQUIRED:
This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding:
1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories."
2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first.
3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions.
Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements.
CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?"
Do not proceed with any recommendations until the user has validated your understanding of the existing system.
sections:
- id: existing-project-overview
title: Existing Project Overview
instruction: Check if document-project analysis was already performed. If yes, reference that output instead of re-analyzing.
sections:
- id: analysis-source
title: Analysis Source
instruction: |
Indicate one of the following:
- Document-project output available at: {{path}}
- IDE-based fresh analysis
- User-provided information
- id: current-state
title: Current Project State
instruction: |
- If document-project output exists: Extract summary from "High Level Architecture" and "Technical Summary" sections
- Otherwise: Brief description of what the project currently does and its primary purpose
- id: documentation-analysis
title: Available Documentation Analysis
instruction: |
If document-project was run:
- Note: "Document-project analysis available - using existing technical documentation"
- List key documents created by document-project
- Skip the missing documentation check below
Otherwise, check for existing documentation:
sections:
- id: available-docs
title: Available Documentation
type: checklist
items:
- Tech Stack Documentation [[LLM: If from document-project, check ✓]]
- Source Tree/Architecture [[LLM: If from document-project, check ✓]]
- Coding Standards [[LLM: If from document-project, may be partial]]
- API Documentation [[LLM: If from document-project, check ✓]]
- External API Documentation [[LLM: If from document-project, check ✓]]
- UX/UI Guidelines [[LLM: May not be in document-project]]
- Technical Debt Documentation [[LLM: If from document-project, check ✓]]
- "Other: {{other_docs}}"
instruction: |
- If document-project was already run: "Using existing project analysis from document-project output."
- If critical documentation is missing and no document-project: "I recommend running the document-project task first..."
- id: enhancement-scope
title: Enhancement Scope Definition
instruction: Work with user to clearly define what type of enhancement this is. This is critical for scoping and approach.
sections:
- id: enhancement-type
title: Enhancement Type
type: checklist
instruction: Determine with user which applies
items:
- New Feature Addition
- Major Feature Modification
- Integration with New Systems
- Performance/Scalability Improvements
- UI/UX Overhaul
- Technology Stack Upgrade
- Bug Fix and Stability Improvements
- "Other: {{other_type}}"
- id: enhancement-description
title: Enhancement Description
instruction: 2-3 sentences describing what the user wants to add or change
- id: impact-assessment
title: Impact Assessment
type: checklist
instruction: Assess the scope of impact on existing codebase
items:
- Minimal Impact (isolated additions)
- Moderate Impact (some existing code changes)
- Significant Impact (substantial existing code changes)
- Major Impact (architectural changes required)
- id: goals-context
title: Goals and Background Context
sections:
- id: goals
title: Goals
type: bullet-list
instruction: Bullet list of 1-line desired outcomes this enhancement will deliver if successful
- id: background
title: Background Context
type: paragraphs
instruction: 1-2 short paragraphs explaining why this enhancement is needed, what problem it solves, and how it fits with the existing project
- id: changelog
title: Change Log
type: table
columns: [Change, Date, Version, Description, Author]
- id: requirements
title: Requirements
instruction: |
Draft functional and non-functional requirements based on your validated understanding of the existing project. Before presenting requirements, confirm: "These requirements are based on my understanding of your existing system. Please review carefully and confirm they align with your project's reality."
elicit: true
sections:
- id: functional
title: Functional
type: numbered-list
prefix: FR
instruction: Each Requirement will be a bullet markdown with identifier starting with FR
examples:
- "FR1: The existing Todo List will integrate with the new AI duplicate detection service without breaking current functionality."
- id: non-functional
title: Non Functional
type: numbered-list
prefix: NFR
instruction: Each Requirement will be a bullet markdown with identifier starting with NFR. Include constraints from existing system
examples:
- "NFR1: Enhancement must maintain existing performance characteristics and not exceed current memory usage by more than 20%."
- id: compatibility
title: Compatibility Requirements
instruction: Critical for brownfield - what must remain compatible
type: numbered-list
prefix: CR
template: "{{requirement}}: {{description}}"
items:
- id: cr1
template: "CR1: {{existing_api_compatibility}}"
- id: cr2
template: "CR2: {{database_schema_compatibility}}"
- id: cr3
template: "CR3: {{ui_ux_consistency}}"
- id: cr4
template: "CR4: {{integration_compatibility}}"
- id: ui-enhancement-goals
title: User Interface Enhancement Goals
condition: Enhancement includes UI changes
instruction: For UI changes, capture how they will integrate with existing UI patterns and design systems
sections:
- id: existing-ui-integration
title: Integration with Existing UI
instruction: Describe how new UI elements will fit with existing design patterns, style guides, and component libraries
- id: modified-screens
title: Modified/New Screens and Views
instruction: List only the screens/views that will be modified or added
- id: ui-consistency
title: UI Consistency Requirements
instruction: Specific requirements for maintaining visual and interaction consistency with existing application
- id: technical-constraints
title: Technical Constraints and Integration Requirements
instruction: This section replaces separate architecture documentation. Gather detailed technical constraints from existing project analysis.
sections:
- id: existing-tech-stack
title: Existing Technology Stack
instruction: |
If document-project output available:
- Extract from "Actual Tech Stack" table in High Level Architecture section
- Include version numbers and any noted constraints
Otherwise, document the current technology stack:
template: |
**Languages**: {{languages}}
**Frameworks**: {{frameworks}}
**Database**: {{database}}
**Infrastructure**: {{infrastructure}}
**External Dependencies**: {{external_dependencies}}
- id: integration-approach
title: Integration Approach
instruction: Define how the enhancement will integrate with existing architecture
template: |
**Database Integration Strategy**: {{database_integration}}
**API Integration Strategy**: {{api_integration}}
**Frontend Integration Strategy**: {{frontend_integration}}
**Testing Integration Strategy**: {{testing_integration}}
- id: code-organization
title: Code Organization and Standards
instruction: Based on existing project analysis, define how new code will fit existing patterns
template: |
**File Structure Approach**: {{file_structure}}
**Naming Conventions**: {{naming_conventions}}
**Coding Standards**: {{coding_standards}}
**Documentation Standards**: {{documentation_standards}}
- id: deployment-operations
title: Deployment and Operations
instruction: How the enhancement fits existing deployment pipeline
template: |
**Build Process Integration**: {{build_integration}}
**Deployment Strategy**: {{deployment_strategy}}
**Monitoring and Logging**: {{monitoring_logging}}
**Configuration Management**: {{config_management}}
- id: risk-assessment
title: Risk Assessment and Mitigation
instruction: |
If document-project output available:
- Reference "Technical Debt and Known Issues" section
- Include "Workarounds and Gotchas" that might impact enhancement
- Note any identified constraints from "Critical Technical Debt"
Build risk assessment incorporating existing known issues:
template: |
**Technical Risks**: {{technical_risks}}
**Integration Risks**: {{integration_risks}}
**Deployment Risks**: {{deployment_risks}}
**Mitigation Strategies**: {{mitigation_strategies}}
- id: epic-structure
title: Epic and Story Structure
instruction: |
For brownfield projects, favor a single comprehensive epic unless the user is clearly requesting multiple unrelated enhancements. Before presenting the epic structure, confirm: "Based on my analysis of your existing project, I believe this enhancement should be structured as [single epic/multiple epics] because [rationale based on actual project analysis]. Does this align with your understanding of the work required?"
elicit: true
sections:
- id: epic-approach
title: Epic Approach
instruction: Explain the rationale for epic structure - typically single epic for brownfield unless multiple unrelated features
template: "**Epic Structure Decision**: {{epic_decision}} with rationale"
- id: epic-details
title: "Epic 1: {{enhancement_title}}"
instruction: |
Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
CRITICAL STORY SEQUENCING FOR BROWNFIELD:
- Stories must ensure existing functionality remains intact
- Each story should include verification that existing features still work
- Stories should be sequenced to minimize risk to existing system
- Include rollback considerations for each story
- Focus on incremental integration rather than big-bang changes
- Size stories for AI agent execution in existing codebase context
- MANDATORY: Present the complete story sequence and ask: "This story sequence is designed to minimize risk to your existing system. Does this order make sense given your project's architecture and constraints?"
- Stories must be logically sequential with clear dependencies identified
- Each story must deliver value while maintaining system integrity
template: |
**Epic Goal**: {{epic_goal}}
**Integration Requirements**: {{integration_requirements}}
sections:
- id: story
title: "Story 1.{{story_number}} {{story_title}}"
repeatable: true
template: |
As a {{user_type}},
I want {{action}},
so that {{benefit}}.
sections:
- id: acceptance-criteria
title: Acceptance Criteria
type: numbered-list
instruction: Define criteria that include both new functionality and existing system integrity
item_template: "{{criterion_number}}: {{criteria}}"
- id: integration-verification
title: Integration Verification
instruction: Specific verification steps to ensure existing functionality remains intact
type: numbered-list
prefix: IV
items:
- template: "IV1: {{existing_functionality_verification}}"
- template: "IV2: {{integration_point_verification}}"
- template: "IV3: {{performance_impact_verification}}"

306
expansion-packs/bmad-godot-game-dev/templates/competitor-analysis-tmpl.yaml Normal file
View File

@@ -0,0 +1,306 @@
template:
id: competitor-analysis-template-v2
name: Competitive Analysis Report
version: 2.0
output:
format: markdown
filename: docs/competitor-analysis.md
title: "Competitive Analysis Report: {{project_product_name}}"
workflow:
mode: interactive
elicitation: advanced-elicitation
custom_elicitation:
title: "Competitive Analysis Elicitation Actions"
options:
- "Deep dive on a specific competitor's strategy"
- "Analyze competitive dynamics in a specific segment"
- "War game competitive responses to your moves"
- "Explore partnership vs. competition scenarios"
- "Stress test differentiation claims"
- "Analyze disruption potential (yours or theirs)"
- "Compare to competition in adjacent markets"
- "Generate win/loss analysis insights"
- "If only we had known about [competitor X's plan]..."
- "Proceed to next section"
sections:
- id: executive-summary
title: Executive Summary
instruction: Provide high-level competitive insights, main threats and opportunities, and recommended strategic actions. Write this section LAST after completing all analysis.
- id: analysis-scope
title: Analysis Scope & Methodology
instruction: This template guides comprehensive competitor analysis. Start by understanding the user's competitive intelligence needs and strategic objectives. Help them identify and prioritize competitors before diving into detailed analysis.
sections:
- id: analysis-purpose
title: Analysis Purpose
instruction: |
Define the primary purpose:
- New market entry assessment
- Product positioning strategy
- Feature gap analysis
- Pricing strategy development
- Partnership/acquisition targets
- Competitive threat assessment
- id: competitor-categories
title: Competitor Categories Analyzed
instruction: |
List categories included:
- Direct Competitors: Same product/service, same target market
- Indirect Competitors: Different product, same need/problem
- Potential Competitors: Could enter market easily
- Substitute Products: Alternative solutions
- Aspirational Competitors: Best-in-class examples
- id: research-methodology
title: Research Methodology
instruction: |
Describe approach:
- Information sources used
- Analysis timeframe
- Confidence levels
- Limitations
- id: competitive-landscape
title: Competitive Landscape Overview
sections:
- id: market-structure
title: Market Structure
instruction: |
Describe the competitive environment:
- Number of active competitors
- Market concentration (fragmented/consolidated)
- Competitive dynamics
- Recent market entries/exits
- id: prioritization-matrix
title: Competitor Prioritization Matrix
instruction: |
Help categorize competitors by market share and strategic threat level
Create a 2x2 matrix:
- Priority 1 (Core Competitors): High Market Share + High Threat
- Priority 2 (Emerging Threats): Low Market Share + High Threat
- Priority 3 (Established Players): High Market Share + Low Threat
- Priority 4 (Monitor Only): Low Market Share + Low Threat
- id: competitor-profiles
title: Individual Competitor Profiles
instruction: Create detailed profiles for each Priority 1 and Priority 2 competitor. For Priority 3 and 4, create condensed profiles.
repeatable: true
sections:
- id: competitor
title: "{{competitor_name}} - Priority {{priority_level}}"
sections:
- id: company-overview
title: Company Overview
template: |
- **Founded:** {{year_founders}}
- **Headquarters:** {{location}}
- **Company Size:** {{employees_revenue}}
- **Funding:** {{total_raised_investors}}
- **Leadership:** {{key_executives}}
- id: business-model
title: Business Model & Strategy
template: |
- **Revenue Model:** {{revenue_model}}
- **Target Market:** {{customer_segments}}
- **Value Proposition:** {{value_promise}}
- **Go-to-Market Strategy:** {{gtm_approach}}
- **Strategic Focus:** {{current_priorities}}
- id: product-analysis
title: Product/Service Analysis
template: |
- **Core Offerings:** {{main_products}}
- **Key Features:** {{standout_capabilities}}
- **User Experience:** {{ux_assessment}}
- **Technology Stack:** {{tech_stack}}
- **Pricing:** {{pricing_model}}
- id: strengths-weaknesses
title: Strengths & Weaknesses
sections:
- id: strengths
title: Strengths
type: bullet-list
template: "- {{strength}}"
- id: weaknesses
title: Weaknesses
type: bullet-list
template: "- {{weakness}}"
- id: market-position
title: Market Position & Performance
template: |
- **Market Share:** {{market_share_estimate}}
- **Customer Base:** {{customer_size_notables}}
- **Growth Trajectory:** {{growth_trend}}
- **Recent Developments:** {{key_news}}
- id: comparative-analysis
title: Comparative Analysis
sections:
- id: feature-comparison
title: Feature Comparison Matrix
instruction: Create a detailed comparison table of key features across competitors
type: table
columns:
[
"Feature Category",
"{{your_company}}",
"{{competitor_1}}",
"{{competitor_2}}",
"{{competitor_3}}",
]
rows:
- category: "Core Functionality"
items:
- ["Feature A", "{{status}}", "{{status}}", "{{status}}", "{{status}}"]
- ["Feature B", "{{status}}", "{{status}}", "{{status}}", "{{status}}"]
- category: "User Experience"
items:
- ["Mobile App", "{{rating}}", "{{rating}}", "{{rating}}", "{{rating}}"]
- ["Onboarding Time", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
- category: "Integration & Ecosystem"
items:
- [
"API Availability",
"{{availability}}",
"{{availability}}",
"{{availability}}",
"{{availability}}",
]
- ["Third-party Integrations", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
- category: "Pricing & Plans"
items:
- ["Starting Price", "{{price}}", "{{price}}", "{{price}}", "{{price}}"]
- ["Free Tier", "{{yes_no}}", "{{yes_no}}", "{{yes_no}}", "{{yes_no}}"]
- id: swot-comparison
title: SWOT Comparison
instruction: Create SWOT analysis for your solution vs. top competitors
sections:
- id: your-solution
title: Your Solution
template: |
- **Strengths:** {{strengths}}
- **Weaknesses:** {{weaknesses}}
- **Opportunities:** {{opportunities}}
- **Threats:** {{threats}}
- id: vs-competitor
title: "vs. {{main_competitor}}"
template: |
- **Competitive Advantages:** {{your_advantages}}
- **Competitive Disadvantages:** {{their_advantages}}
- **Differentiation Opportunities:** {{differentiation}}
- id: positioning-map
title: Positioning Map
instruction: |
Describe competitor positions on key dimensions
Create a positioning description using 2 key dimensions relevant to the market, such as:
- Price vs. Features
- Ease of Use vs. Power
- Specialization vs. Breadth
- Self-Serve vs. High-Touch
- id: strategic-analysis
title: Strategic Analysis
sections:
- id: competitive-advantages
title: Competitive Advantages Assessment
sections:
- id: sustainable-advantages
title: Sustainable Advantages
instruction: |
Identify moats and defensible positions:
- Network effects
- Switching costs
- Brand strength
- Technology barriers
- Regulatory advantages
- id: vulnerable-points
title: Vulnerable Points
instruction: |
Where competitors could be challenged:
- Weak customer segments
- Missing features
- Poor user experience
- High prices
- Limited geographic presence
- id: blue-ocean
title: Blue Ocean Opportunities
instruction: |
Identify uncontested market spaces
List opportunities to create new market space:
- Underserved segments
- Unaddressed use cases
- New business models
- Geographic expansion
- Different value propositions
- id: strategic-recommendations
title: Strategic Recommendations
sections:
- id: differentiation-strategy
title: Differentiation Strategy
instruction: |
How to position against competitors:
- Unique value propositions to emphasize
- Features to prioritize
- Segments to target
- Messaging and positioning
- id: competitive-response
title: Competitive Response Planning
sections:
- id: offensive-strategies
title: Offensive Strategies
instruction: |
How to gain market share:
- Target competitor weaknesses
- Win competitive deals
- Capture their customers
- id: defensive-strategies
title: Defensive Strategies
instruction: |
How to protect your position:
- Strengthen vulnerable areas
- Build switching costs
- Deepen customer relationships
- id: partnership-ecosystem
title: Partnership & Ecosystem Strategy
instruction: |
Potential collaboration opportunities:
- Complementary players
- Channel partners
- Technology integrations
- Strategic alliances
- id: monitoring-plan
title: Monitoring & Intelligence Plan
sections:
- id: key-competitors
title: Key Competitors to Track
instruction: Priority list with rationale
- id: monitoring-metrics
title: Monitoring Metrics
instruction: |
What to track:
- Product updates
- Pricing changes
- Customer wins/losses
- Funding/M&A activity
- Market messaging
- id: intelligence-sources
title: Intelligence Sources
instruction: |
Where to gather ongoing intelligence:
- Company websites/blogs
- Customer reviews
- Industry reports
- Social media
- Patent filings
- id: update-cadence
title: Update Cadence
instruction: |
Recommended review schedule:
- Weekly: {{weekly_items}}
- Monthly: {{monthly_items}}
- Quarterly: {{quarterly_analysis}}

1111
expansion-packs/bmad-godot-game-dev/templates/game-architecture-tmpl.yaml Normal file
View File

File diff suppressed because it is too large Load Diff

356
expansion-packs/bmad-godot-game-dev/templates/game-brief-tmpl.yaml Normal file
View File

@@ -0,0 +1,356 @@
template:
id: game-brief-template-v3
name: Game Brief
version: 3.0
output:
format: markdown
filename: docs/game-brief.md
title: "{{game_title}} Game Brief"
workflow:
mode: interactive
sections:
- id: initial-setup
instruction: |
This template creates a comprehensive game brief that serves as the foundation for all subsequent game development work. The brief should capture the essential vision, scope, and requirements needed to create a detailed Game Design Document.
This brief is typically created early in the ideation process, often after brainstorming sessions, to crystallize the game concept before moving into detailed design.
- id: game-vision
title: Game Vision
instruction: Establish the core vision and identity of the game. Present each subsection and gather user feedback before proceeding.
sections:
- id: core-concept
title: Core Concept
instruction: 2-3 sentences that clearly capture what the game is and why it will be compelling to players
- id: elevator-pitch
title: Elevator Pitch
instruction: Single sentence that captures the essence of the game in a memorable way
template: |
**"{{game_description_in_one_sentence}}"**
- id: vision-statement
title: Vision Statement
instruction: Inspirational statement about what the game will achieve for players and why it matters
- id: target-market
title: Target Market
instruction: Define the audience and market context. Apply `tasks#advanced-elicitation` after presenting this section.
sections:
- id: primary-audience
title: Primary Audience
template: |
**Demographics:** {{age_range}}, {{platform_preference}}, {{gaming_experience}}
**Psychographics:** {{interests}}, {{motivations}}, {{play_patterns}}
**Gaming Preferences:** {{preferred_genres}}, {{session_length}}, {{difficulty_preference}}
- id: secondary-audiences
title: Secondary Audiences
template: |
**Audience 2:** {{description}}
**Audience 3:** {{description}}
- id: market-context
title: Market Context
template: |
**Genre:** {{primary_genre}} / {{secondary_genre}}
**Platform Strategy:** {{platform_focus}}
**Competitive Positioning:** {{differentiation_statement}}
- id: game-fundamentals
title: Game Fundamentals
instruction: Define the core gameplay elements. Each subsection should be specific enough to guide detailed design work.
sections:
- id: core-gameplay-pillars
title: Core Gameplay Pillars
instruction: 3-5 fundamental principles that guide all design decisions
type: numbered-list
template: |
**{{pillar_name}}** - {{description_and_rationale}}
- id: primary-mechanics
title: Primary Mechanics
instruction: List the 3-5 most important gameplay mechanics that define the player experience
repeatable: true
template: |
**Core Mechanic: {{mechanic_name}}**
- **Description:** {{how_it_works}}
- **Player Value:** {{why_its_fun}}
- **Implementation Scope:** {{complexity_estimate}}
- id: player-experience-goals
title: Player Experience Goals
instruction: Define what emotions and experiences the game should create for players
template: |
**Primary Experience:** {{main_emotional_goal}}
**Secondary Experiences:** {{supporting_emotional_goals}}
**Engagement Pattern:** {{how_player_engagement_evolves}}
- id: scope-constraints
title: Scope and Constraints
instruction: Define the boundaries and limitations that will shape development. Apply `tasks#advanced-elicitation` to clarify any constraints.
sections:
- id: project-scope
title: Project Scope
template: |
**Game Length:** {{estimated_content_hours}}
**Content Volume:** {{levels_areas_content_amount}}
**Feature Complexity:** {{simple|moderate|complex}}
**Scope Comparison:** "Similar to {{reference_game}} but with {{key_differences}}"
- id: technical-constraints
title: Technical Constraints
template: |
**Platform Requirements:**
- Primary: {{platform_1}} - {{requirements}}
- Secondary: {{platform_2}} - {{requirements}}
**Technical Specifications:**
- Engine: Godot and C#/GDScript
- Performance Target: {{fps_target}} FPS on {{target_device}}
- Memory Budget: <{{memory_limit}}MB
- Load Time Goal: <{{load_time_seconds}}s
- id: resource-constraints
title: Resource Constraints
template: |
**Team Size:** {{team_composition}}
**Timeline:** {{development_duration}}
**Budget Considerations:** {{budget_constraints_or_targets}}
**Asset Requirements:** {{art_audio_content_needs}}
- id: business-constraints
title: Business Constraints
condition: has_business_goals
template: |
**Monetization Model:** {{free|premium|freemium|subscription}}
**Revenue Goals:** {{revenue_targets_if_applicable}}
**Platform Requirements:** {{store_certification_needs}}
**Launch Timeline:** {{target_launch_window}}
- id: reference-framework
title: Reference Framework
instruction: Provide context through references and competitive analysis
sections:
- id: inspiration-games
title: Inspiration Games
sections:
- id: primary-references
title: Primary References
type: numbered-list
repeatable: true
template: |
**{{reference_game}}** - {{what_we_learn_from_it}}
- id: competitive-analysis
title: Competitive Analysis
template: |
**Direct Competitors:**
- {{competitor_1}}: {{strengths_and_weaknesses}}
- {{competitor_2}}: {{strengths_and_weaknesses}}
**Differentiation Strategy:**
{{how_we_differ_and_why_thats_valuable}}
- id: market-opportunity
title: Market Opportunity
template: |
**Market Gap:** {{underserved_need_or_opportunity}}
**Timing Factors:** {{why_now_is_the_right_time}}
**Success Metrics:** {{how_well_measure_success}}
- id: content-framework
title: Content Framework
instruction: Outline the content structure and progression without full design detail
sections:
- id: game-structure
title: Game Structure
template: |
**Overall Flow:** {{linear|hub_world|open_world|procedural}}
**Progression Model:** {{how_players_advance}}
**Session Structure:** {{typical_play_session_flow}}
- id: content-categories
title: Content Categories
template: |
**Core Content:**
- {{content_type_1}}: {{quantity_and_description}}
- {{content_type_2}}: {{quantity_and_description}}
**Optional Content:**
- {{optional_content_type}}: {{quantity_and_description}}
**Replay Elements:**
- {{replayability_features}}
- id: difficulty-accessibility
title: Difficulty and Accessibility
template: |
**Difficulty Approach:** {{how_challenge_is_structured}}
**Accessibility Features:** {{planned_accessibility_support}}
**Skill Requirements:** {{what_skills_players_need}}
- id: art-audio-direction
title: Art and Audio Direction
instruction: Establish the aesthetic vision that will guide asset creation
sections:
- id: visual-style
title: Visual Style
template: |
**Art Direction:** {{style_description}}
**Reference Materials:** {{visual_inspiration_sources}}
**Technical Approach:** {{2d_style_pixel_vector_etc}}
**Color Strategy:** {{color_palette_mood}}
- id: audio-direction
title: Audio Direction
template: |
**Music Style:** {{genre_and_mood}}
**Sound Design:** {{audio_personality}}
**Implementation Needs:** {{technical_audio_requirements}}
- id: ui-ux-approach
title: UI/UX Approach
template: |
**Interface Style:** {{ui_aesthetic}}
**User Experience Goals:** {{ux_priorities}}
**Platform Adaptations:** {{cross_platform_considerations}}
- id: risk-assessment
title: Risk Assessment
instruction: Identify potential challenges and mitigation strategies
sections:
- id: technical-risks
title: Technical Risks
type: table
template: |
| Risk | Probability | Impact | Mitigation Strategy |
| ---- | ----------- | ------ | ------------------- |
| {{technical_risk}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
- id: design-risks
title: Design Risks
type: table
template: |
| Risk | Probability | Impact | Mitigation Strategy |
| ---- | ----------- | ------ | ------------------- |
| {{design_risk}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
- id: market-risks
title: Market Risks
type: table
template: |
| Risk | Probability | Impact | Mitigation Strategy |
| ---- | ----------- | ------ | ------------------- |
| {{market_risk}} | {{high|med|low}} | {{high|med|low}} | {{mitigation_approach}} |
- id: success-criteria
title: Success Criteria
instruction: Define measurable goals for the project
sections:
- id: player-experience-metrics
title: Player Experience Metrics
template: |
**Engagement Goals:**
- Tutorial completion rate: >{{percentage}}%
- Average session length: {{duration}} minutes
- Player retention: D1 {{d1}}%, D7 {{d7}}%, D30 {{d30}}%
**Quality Benchmarks:**
- Player satisfaction: >{{rating}}/10
- Completion rate: >{{percentage}}%
- Technical performance: {{fps_target}} FPS consistent
- id: development-metrics
title: Development Metrics
template: |
**Technical Targets:**
- Zero critical bugs at launch
- Performance targets met on all platforms
- Load times under {{seconds}}s
**Process Goals:**
- Development timeline adherence
- Feature scope completion
- Quality assurance standards
- id: business-metrics
title: Business Metrics
condition: has_business_goals
template: |
**Commercial Goals:**
- {{revenue_target}} in first {{time_period}}
- {{user_acquisition_target}} players in first {{time_period}}
- {{retention_target}} monthly active users
- id: next-steps
title: Next Steps
instruction: Define immediate actions following the brief completion
sections:
- id: immediate-actions
title: Immediate Actions
type: numbered-list
template: |
**{{action_item}}** - {{details_and_timeline}}
- id: development-roadmap
title: Development Roadmap
sections:
- id: phase-1-preproduction
title: "Phase 1: Pre-Production ({{duration}})"
type: bullet-list
template: |
- Detailed Game Design Document creation
- Technical architecture planning
- Art style exploration and pipeline setup
- id: phase-2-prototype
title: "Phase 2: Prototype ({{duration}})"
type: bullet-list
template: |
- Core mechanic implementation
- Technical proof of concept
- Initial playtesting and iteration
- id: phase-3-production
title: "Phase 3: Production ({{duration}})"
type: bullet-list
template: |
- Full feature development
- Content creation and integration
- Comprehensive testing and optimization
- id: documentation-pipeline
title: Documentation Pipeline
sections:
- id: required-documents
title: Required Documents
type: numbered-list
template: |
Game Design Document (GDD) - {{target_completion}}
Technical Architecture Document - {{target_completion}}
Art Style Guide - {{target_completion}}
Production Plan - {{target_completion}}
- id: validation-plan
title: Validation Plan
template: |
**Concept Testing:**
- {{validation_method_1}} - {{timeline}}
- {{validation_method_2}} - {{timeline}}
**Prototype Testing:**
- {{testing_approach}} - {{timeline}}
- {{feedback_collection_method}} - {{timeline}}
- id: appendices
title: Appendices
sections:
- id: research-materials
title: Research Materials
instruction: Include any supporting research, competitive analysis, or market data that informed the brief
- id: brainstorming-notes
title: Brainstorming Session Notes
instruction: Reference any brainstorming sessions that led to this brief
- id: stakeholder-input
title: Stakeholder Input
instruction: Include key input from stakeholders that shaped the vision
- id: change-log
title: Change Log
instruction: Track document versions and changes
type: table
template: |
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |

724
expansion-packs/bmad-godot-game-dev/templates/game-design-doc-tmpl.yaml Normal file
View File

@@ -0,0 +1,724 @@
template:
id: game-design-doc-template-v3
name: Game Design Document (GDD)
version: 4.0
output:
format: markdown
filename: docs/game-design-document.md
title: "{{game_title}} Game Design Document (GDD)"
workflow:
mode: interactive
elicitation: advanced-elicitation
sections:
- id: goals-context
title: Goals and Background Context
instruction: |
Ask if Project Brief document is available. If NO Project Brief exists, STRONGLY recommend creating one first using project-brief-tmpl (it provides essential foundation: problem statement, target users, success metrics, MVP scope, constraints). If user insists on GDD without brief, gather this information during Goals section. If Project Brief exists, review and use it to populate Goals (bullet list of desired game development outcomes) and Background Context (1-2 paragraphs on what game concept this will deliver and why) so we can determine what is and is not in scope for the GDD. Include Change Log table for version tracking.
sections:
- id: goals
title: Goals
type: bullet-list
instruction: Bullet list of 1 line desired outcomes the GDD will deliver if successful - game development and player experience goals
examples:
- Create an engaging 2D platformer that teaches players basic programming concepts
- Deliver a polished mobile game that runs smoothly on low-end Android devices
- Build a foundation for future expansion packs and content updates
- id: background
title: Background Context
type: paragraphs
instruction: 1-2 short paragraphs summarizing the game concept background, target audience needs, market opportunity, and what problem this game solves
- id: changelog
title: Change Log
type: table
columns: [Date, Version, Description, Author]
instruction: Track document versions and changes
- id: executive-summary
title: Executive Summary
instruction: Create a compelling overview that captures the essence of the game. Present this section first and get user feedback before proceeding.
elicit: true
sections:
- id: core-concept
title: Core Concept
instruction: 2-3 sentences that clearly describe what the game is and why players will love it
examples:
- A fast-paced 2D platformer where players manipulate gravity to solve puzzles and defeat enemies in a hand-drawn world.
- An educational puzzle game that teaches coding concepts through visual programming blocks in a fantasy adventure setting.
- id: target-audience
title: Target Audience
instruction: Define the primary and secondary audience with demographics and gaming preferences
template: |
**Primary:** {{age_range}}, {{player_type}}, {{platform_preference}}
**Secondary:** {{secondary_audience}}
examples:
- "Primary: Ages 8-16, casual mobile gamers, prefer short play sessions"
- "Secondary: Adult puzzle enthusiasts, educators looking for teaching tools"
- id: platform-technical
title: Platform & Technical Requirements
instruction: Based on the technical preferences or user input, define the target platforms and Godot-specific requirements
template: |
**Primary Platform:** {{platform}}
**Engine:** Godot {{godot_version}} with GDScript & C#
**Language Strategy:** {{gdscript_for}} (GDScript), {{csharp_for}} (C#)
**Performance Target:** 60+ FPS minimum on {{minimum_device}}
**Screen Support:** {{resolution_range}}
**Export Templates:** {{export_targets}}
**TDD Approach:** GUT for GDScript, GoDotTest for C#
examples:
- "Primary Platform: Mobile (iOS/Android), Engine: Godot 4.3, Performance: 60+ FPS on iPhone 8/Galaxy S8"
- "Language Strategy: Game logic/UI (GDScript), Physics/AI systems (C#)"
- id: unique-selling-points
title: Unique Selling Points
instruction: List 3-5 key features that differentiate this game from competitors
type: numbered-list
examples:
- Innovative gravity manipulation mechanic that affects both player and environment
- Seamless integration of educational content without compromising fun gameplay
- Adaptive difficulty system that learns from player behavior
- id: core-gameplay
title: Core Gameplay
instruction: This section defines the fundamental game mechanics. After presenting each subsection, apply advanced elicitation to ensure completeness and gather additional details.
elicit: true
sections:
- id: game-pillars
title: Game Pillars
instruction: Define 3-5 core pillars that guide all design decisions. These should be specific and actionable for Godot development.
type: numbered-list
template: |
**{{pillar_name}}** - {{description}}
examples:
- Performance First - Maintain 60+ FPS across all target platforms
- Intuitive Controls - All interactions learnable within 30 seconds using InputMap
- Immediate Feedback - Every player action provides signal response within 50ms
- Progressive Challenge - Difficulty increases through mechanic complexity, not unfair timing
- id: core-gameplay-loop
title: Core Gameplay Loop
instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions for Godot implementation.
template: |
**Primary Loop ({{duration}} seconds):**
1. {{action_1}} ({{time_1}}s) - {{godot_node}}
2. {{action_2}} ({{time_2}}s) - {{godot_node}}
3. {{action_3}} ({{time_3}}s) - {{godot_node}}
4. {{reward_feedback}} ({{time_4}}s) - {{godot_node}}
**Performance Target:** Loop maintains 60+ FPS
examples:
- Observe environment (2s) - Camera2D node, Identify puzzle elements (3s) - Area2D detection
- id: win-loss-conditions
title: Win/Loss Conditions
instruction: Clearly define success and failure states with Godot-specific implementation notes
template: |
**Victory Conditions:**
- {{win_condition_1}} - Godot Signal: {{signal_name}}
- {{win_condition_2}} - Godot Signal: {{signal_name}}
**Failure States:**
- {{loss_condition_1}} - Trigger: {{godot_trigger}}
- {{loss_condition_2}} - Trigger: {{godot_trigger}}
examples:
- "Victory: Player reaches exit portal - Signal: area_entered from Area2D"
- "Failure: Health reaches zero - Trigger: health_depleted signal"
- id: game-mechanics
title: Game Mechanics
instruction: Detail each major mechanic that will need Godot implementation. Each mechanic should be specific enough for developers to create nodes, scripts (GDScript/C#), and scenes with TDD approach.
elicit: true
sections:
- id: primary-mechanics
title: Primary Mechanics
repeatable: true
sections:
- id: mechanic
title: "{{mechanic_name}}"
template: |
**Description:** {{detailed_description}}
**Player Input:** {{input_method}} - InputMap Action: {{input_action}}
**System Response:** {{game_response}}
**Godot Implementation Notes:**
- **Nodes Needed:** {{node_list}}
- **Language Choice:** {{gdscript_or_csharp}} - {{language_rationale}}
- **Physics Requirements:** {{physics_2d_3d_setup}}
- **Animation:** {{animation_player_states}}
- **Performance:** Must maintain 60+ FPS
- **Object Pooling:** {{pooling_requirements}}
**Dependencies:** {{other_mechanics_needed}}
**Script Architecture:**
- {{script_name}}.gd/.cs - {{responsibility}}
- {{autoload_script}}.gd/.cs - {{singleton_role}}
**TDD Requirements:**
- GUT tests for GDScript components
- GoDotTest for C# components
examples:
- "Nodes Needed: RigidBody2D, CollisionShape2D, PlayerController node"
- "Language: GDScript for game logic, C# for physics calculations"
- "Physics Requirements: Physics material for friction, gravity scale 3"
- id: controls
title: Controls
instruction: Define all input methods for different platforms using Godot's InputMap
type: table
template: |
| Action | Desktop | Mobile | Gamepad | InputMap Action |
| ------ | ------- | ------ | ------- | --------------- |
| {{action}} | {{key}} | {{gesture}} | {{button}} | {{action_name}} |
examples:
- Move Left, A/Left Arrow, Touch Left, Left Stick, move_left
- id: progression-balance
title: Progression & Balance
instruction: Define how players advance and how difficulty scales. This section should provide clear parameters for Godot implementation with Resources and language strategy.
elicit: true
sections:
- id: player-progression
title: Player Progression
template: |
**Progression Type:** {{linear|branching|metroidvania}}
**Key Milestones:**
1. **{{milestone_1}}** - {{unlock_description}} - Godot: {{resource_update}}
2. **{{milestone_2}}** - {{unlock_description}} - Godot: {{resource_update}}
3. **{{milestone_3}}** - {{unlock_description}} - Godot: {{resource_update}}
**Save Data Structure:**
```csharp
[System.Serializable]
public class PlayerProgress
{
{{progress_fields}}
}
```
examples:
- public int currentLevel, public bool[] unlockedAbilities, public float totalPlayTime
- id: difficulty-curve
title: Difficulty Curve
instruction: Provide specific parameters for balancing that can be implemented as Godot Resources with performance focus
template: |
**Tutorial Phase:** {{duration}} - {{difficulty_description}}
- Godot Config: {{resource_values}} - Language: {{gdscript_or_csharp}}
**Early Game:** {{duration}} - {{difficulty_description}}
- Godot Config: {{resource_values}} - Must maintain 60+ FPS
**Mid Game:** {{duration}} - {{difficulty_description}}
- Godot Config: {{resource_values}} - Object pooling required
**Late Game:** {{duration}} - {{difficulty_description}}
- Godot Config: {{resource_values}} - C# optimization for performance
examples:
- "enemy speed: 2.0f, jump height: 4.5f, obstacle density: 0.3f"
- id: economy-resources
title: Economy & Resources
condition: has_economy
instruction: Define any in-game currencies, resources, or collectibles with Godot implementation details
type: table
template: |
| Resource | Earn Rate | Spend Rate | Purpose | Cap | Godot Resource |
| -------- | --------- | ---------- | ------- | --- | --------------- |
| {{resource}} | {{rate}} | {{rate}} | {{use}} | {{max}} | {{resource_name}} |
examples:
- Coins, 1-3 per enemy, 10-50 per upgrade, Buy abilities, 9999, CurrencyData
- id: level-design-framework
title: Level Design Framework
instruction: Provide guidelines for level creation that developers can use to create Godot scenes and nodes. Focus on modular design, scene inheritance, and performance optimization.
elicit: true
sections:
- id: level-types
title: Level Types
repeatable: true
sections:
- id: level-type
title: "{{level_type_name}}"
template: |
**Purpose:** {{gameplay_purpose}}
**Target Duration:** {{target_time}}
**Key Elements:** {{required_mechanics}}
**Difficulty Rating:** {{relative_difficulty}}
**Godot Scene Structure:**
- **Environment:** {{tilemap_setup}}
- **Gameplay Objects:** {{node_list}}
- **Lighting:** {{lighting_setup}}
- **Audio:** {{audio_sources}}
**Level Flow Template:**
- **Introduction:** {{intro_description}} - Area: {{godot_area_bounds}}
- **Challenge:** {{main_challenge}} - Mechanics: {{active_components}}
- **Resolution:** {{completion_requirement}} - Trigger: {{completion_trigger}}
**Reusable Scenes:**
- {{scene_name}}.tscn - {{scene_purpose}}
examples:
- "Environment: TileMap node with Platform tileset, Lighting: DirectionalLight2D + PointLight2D nodes"
- id: level-progression
title: Level Progression
template: |
**World Structure:** {{linear|hub|open}}
**Total Levels:** {{number}}
**Unlock Pattern:** {{progression_method}}
**Scene Management:** {{godot_scene_loading}}
**Godot Scene Organization:**
- Scene Naming: {{naming_convention}}
- Resource Preloading: {{preload_groups}}
- Loading Screens: {{loading_implementation}}
examples:
- "Scene Naming: world_{x}_level_{y}_name.tscn, Preload Groups: levels_world1.tres, world_environments.tres"
- id: technical-specifications
title: Technical Specifications
instruction: Define Godot-specific technical requirements that will guide architecture and implementation decisions. Reference Godot documentation and best practices.
elicit: true
choices:
renderer: [Forward+, Mobile, Compatibility]
language_primary: [GDScript, C#, Both]
physics: [2D Only, 3D Only, Hybrid]
sections:
- id: godot-configuration
title: Godot Project Configuration
template: |
**Godot Version:** {{godot_version}} (4.3+ recommended)
**Renderer:** {{Forward+|Mobile|Compatibility}}
**Primary Language:** {{GDScript|C#|Both}}
**Physics:** {{2D Only|3D Only|Hybrid}}
**Export Templates:** {{platforms}}
**.NET Version:** {{.NET 6.0|.NET 7.0}} (if using C#)
**Language Strategy:**
- GDScript: {{gdscript_usage}} (with static typing mandatory)
- C#: {{csharp_usage}} (for performance-critical systems)
**Project Settings:**
- Rendering Method: {{rendering_method}}
- MSAA: {{msaa_setting}}
- Physics Settings: {{physics_config}}
- Object Pooling: Required for spawned entities
examples:
- GDScript for game logic and UI (10-20% performance gain with static typing)
- C# for physics simulation and procedural generation (no LINQ in hot paths)
- "Color Space: Linear, Quality: Mobile/Desktop presets, Gravity: -20"
- id: performance-requirements
title: Performance Requirements
template: |
**Frame Rate:** {{fps_target}} FPS (minimum {{min_fps}} on low-end devices)
**Memory Usage:** <{{memory_limit}}MB heap, <{{texture_memory}}MB textures
**Load Times:** <{{load_time}}s initial, <{{level_load}}s between levels
**Battery Usage:** Optimized for mobile devices - {{battery_target}} hours gameplay
**Godot Profiler Targets:**
- Frame Time: <16.67ms (60+ FPS mandatory)
- CPU Time: <{{cpu_time}}ms
- GPU Time: <{{gpu_time}}ms
- Physics Frame: <{{physics_time}}ms
- Draw Calls: <{{draw_calls}} per frame
- Object Pools: Active for all spawned entities
examples:
- "60 FPS (minimum 30), CPU: <16.67ms, GPU: <16.67ms, GC: <4KB, Draws: <50"
- id: platform-specific
title: Platform Specific Requirements
template: |
**Desktop:**
- Resolution: {{min_resolution}} - {{max_resolution}}
- Input: Keyboard, Mouse, Gamepad ({{gamepad_support}})
- Build Target: {{desktop_targets}}
**Mobile:**
- Resolution: {{mobile_min}} - {{mobile_max}}
- Input: Touch, Accelerometer ({{sensor_support}})
- OS: iOS {{ios_min}}+, Android {{android_min}}+ (API {{api_level}})
- Device Requirements: {{device_specs}}
**Web (if applicable):**
- WebGL Version: {{webgl_version}}
- Browser Support: {{browser_list}}
- Compression: {{compression_format}}
examples:
- "Resolution: 1280x720 - 4K, Gamepad: Xbox/PlayStation controllers via Input System"
- id: asset-requirements
title: Asset Requirements
instruction: Define asset specifications for Godot pipeline optimization with performance focus
template: |
**2D Art Assets:**
- Sprites: {{sprite_resolution}} at {{ppu}} PPU
- Texture Format: {{texture_compression}}
- Atlas Strategy: {{sprite_atlas_setup}}
- Animation: {{animation_type}} at {{framerate}} FPS
**Audio Assets:**
- Music: {{audio_format}} at {{sample_rate}} Hz
- SFX: {{sfx_format}} at {{sfx_sample_rate}} Hz
- Compression: {{audio_compression}}
- 3D Audio: {{spatial_audio}}
**UI Assets:**
- Canvas Resolution: {{ui_resolution}}
- UI Scale Mode: {{scale_mode}}
- Font: {{font_requirements}}
- Icon Sizes: {{icon_specifications}}
examples:
- "Sprites: 32x32 to 256x256 at 16 PPU, Format: RGBA32 for quality/RGBA16 for performance"
- id: technical-architecture-requirements
title: Technical Architecture Requirements
instruction: Define high-level Godot architecture patterns and systems that the game must support. Focus on scalability, TDD, and 60+ FPS performance.
elicit: true
choices:
architecture_pattern: [Node-Based, MVC, Component-Based, Signal-Driven]
save_system: [ConfigFile, JSON, Binary, Cloud]
audio_system: [Godot Audio, FMOD]
sections:
- id: code-architecture
title: Code Architecture Pattern
template: |
**Architecture Pattern:** {{MVC|MVVM|ECS|Component-Based|Custom}}
**Core Systems Required:**
- **Scene Management:** {{scene_manager_approach}}
- **State Management:** {{state_pattern_implementation}}
- **Event System:** {{event_system_choice}}
- **Object Pooling:** {{pooling_strategy}}
- **Save/Load System:** {{save_system_approach}}
**Folder Structure:**
```
Assets/
├── _Project/
│ ├── Scripts/
│ │ ├── {{folder_structure}}
│ ├── Scenes/
│ ├── Scenes/
│ └── {{additional_folders}}
```
**Naming Conventions:**
- Scripts: {{script_naming}}
- Scenes: {{scene_naming}}
- Scenes: {{scene_naming}}
examples:
- "Architecture: Node-Based with Resource (.tres) data containers"
- "Scripts: PascalCase (PlayerController.gd), snake_case (player_controller.gd), Scenes: player.tscn, level_01_forest.tscn"
- id: godot-systems-integration
title: Godot Systems Integration
template: |
**Required Godot Systems:**
- **Input System:** {{input_implementation}}
- **Animation System:** {{animation_approach}}
- **Physics Integration:** {{physics_usage}}
- **Rendering Features:** {{rendering_requirements}}
- **Asset Streaming:** {{asset_loading_strategy}}
**Third-Party Integrations:**
- {{integration_name}}: {{integration_purpose}}
**Performance Systems:**
- **Profiling Integration:** {{profiling_setup}}
- **Memory Management:** {{memory_strategy}}
- **Build Pipeline:** {{build_automation}}
examples:
- "Input System: Action Maps for Menu/Gameplay contexts with device switching"
- "DOTween: Smooth UI transitions and gameplay animations"
- id: data-management
title: Data Management
template: |
**Save Data Architecture:**
- **Format:** {{PlayerPrefs|JSON|Binary|Cloud}}
- **Structure:** {{save_data_organization}}
- **Encryption:** {{security_approach}}
- **Cloud Sync:** {{cloud_integration}}
**Configuration Data:**
- **Resources:** {{resource_usage}}
- **Settings Management:** {{settings_system}}
- **Localization:** {{localization_approach}}
**Runtime Data:**
- **Caching Strategy:** {{cache_implementation}}
- **Memory Pools:** {{pooling_objects}}
- **Asset References:** {{asset_reference_system}}
examples:
- "Save Data: JSON format with AES encryption, stored in persistent data path"
- "Resources: Game settings (.tres), level configurations, character data with static typing"
- id: development-phases
title: Development Phases & Epic Planning
instruction: Break down the Godot development into phases that can be converted to agile epics. Each phase should deliver deployable functionality following TDD practices with 60+ FPS performance.
elicit: true
sections:
- id: phases-overview
title: Phases Overview
instruction: Present a high-level list of all phases for user approval. Each phase's design should deliver significant Godot functionality with TDD and performance validation.
type: numbered-list
examples:
- "Phase 1: Godot Foundation & Core Systems: Project setup with TDD (GUT/GoDotTest), node architecture, InputMap configuration"
- "Phase 2: Core Game Mechanics: Player controller (GDScript), physics systems (C# for performance), 60+ FPS validation"
- "Phase 3: Level Systems & Content Pipeline: Scene loading, inheritance patterns, object pooling implementation"
- "Phase 4: Polish & Platform Optimization: Performance profiling to 60+ FPS, export templates, platform deployment"
- id: phase-1-foundation
title: "Phase 1: Godot Foundation & Core Systems ({{duration}})"
sections:
- id: foundation-design
title: "Design: Godot Project Foundation"
type: bullet-list
template: |
- Godot project setup with node hierarchy and resource organization
- Core architecture implementation ({{architecture_pattern}}) with TDD setup
- InputMap configuration for cross-platform input handling
- Node-based scene management with signal system
- GUT (GDScript) and GoDotTest (C#) test framework setup
- Profiler integration for 60+ FPS validation
- Export template configuration for target platforms
examples:
- "Input System: Configure PlayerInput component with Action Maps for movement and UI"
- id: core-systems-design
title: "Design: Essential Game Systems"
type: bullet-list
template: |
- Save/Load system using user:// path with {{save_format}} format
- Audio bus system setup with {{audio_system}} integration
- Signal system for decoupled node communication
- Object pooling system for spawned entities (mandatory)
- Control node UI framework with anchoring and themes
- Settings and configuration management with Resources (.tres)
- id: phase-2-gameplay
title: "Phase 2: Core Gameplay Implementation ({{duration}})"
sections:
- id: gameplay-mechanics-design
title: "Design: Primary Game Mechanics"
type: bullet-list
template: |
- Player controller with {{movement_type}} using GDScript (static typing)
- {{primary_mechanic}} implementation with Godot physics (C# if performance-critical)
- {{secondary_mechanic}} system with 60+ FPS maintained
- Game state management (playing, paused, game over)
- Collision detection with Area2D/3D and physics bodies
- AnimationPlayer and AnimationTree integration with blend spaces
- id: level-systems-design
title: "Design: Level & Content Systems"
type: bullet-list
template: |
- Scene loading with transitions <3 seconds
- Level progression with Resource-based unlock system
- Scene inheritance and composition patterns
- {{level_generation}} level creation with TDD tests
- Collectibles with object pooling for performance
- Victory/defeat conditions with signal emissions
- id: phase-3-polish
title: "Phase 3: Polish & Optimization ({{duration}})"
sections:
- id: performance-design
title: "Design: Performance & Platform Optimization"
type: bullet-list
template: |
- Godot Profiler analysis to ensure 60+ FPS
- Memory management and garbage collection optimization
- Asset optimization (import settings, compression)
- Platform-specific performance tuning for 60+ FPS
- Export size optimization with stripping
- Renderer settings for different device tiers
- id: user-experience-design
title: "Design: User Experience & Polish"
type: bullet-list
template: |
- Control node UI with responsive anchoring
- Audio bus system with dynamic mixing
- GPUParticles2D/3D with object pooling
- Accessibility features with InputMap remapping
- Tutorial flow with GUT test coverage
- Cross-platform testing for 60+ FPS on all targets
- id: epic-list
title: Epic List
instruction: |
Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
CRITICAL: Epics MUST be logically sequential following agile best practices:
- Each epic should be focused on a single phase and it's design from the development-phases section and deliver a significant, end-to-end, fully deployable increment of testable functionality
- Epic 1 must establish Phase 1: Godot Foundation & Core Systems (Project setup with TDD, node architecture, InputMap) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality with 60+ FPS performance!
- Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
- Not every project needs multiple epics, an epic needs to deliver value. For example, an API, component, or Resource completed can deliver value even if a scene or node is not complete and planned for a separate epic.
- Err on the side of less epics, but let the user know your rationale and offer options for splitting them if it seems some are too large or focused on disparate things.
- Cross Cutting Concerns should flow through epics and stories and not be final stories. For example, adding a logging framework as a last story of an epic, or at the end of a project as a final epic or story would be terrible as we would not have logging from the beginning.
elicit: true
examples:
- "Epic 1: Godot Foundation & Core Systems: TDD setup (GUT/GoDotTest), node architecture, InputMap configuration"
- "Epic 2: Core Game Mechanics: Player controller (GDScript), physics (C# if needed), 60+ FPS validation"
- "Epic 3: Level Systems & Content Pipeline: Scene inheritance, resource preloading, object pooling"
- "Epic 4: Polish & Platform Optimization: Performance profiling to 60+ FPS, export templates, deployment"
- id: epic-details
title: Epic {{epic_number}} {{epic_title}}
repeatable: true
instruction: |
After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit.
For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve).
CRITICAL STORY SEQUENCING REQUIREMENTS:
- Stories within each epic MUST be logically sequential
- Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation
- No story should depend on work from a later story or epic
- Identify and note any direct prerequisite stories
- Focus on "what" and "why" not "how" (leave technical implementation to Architect) yet be precise enough to support a logical sequential order of operations from story to story.
- Ensure each story delivers clear user or business value, try to avoid enablers and build them into stories that deliver value.
- Size stories for AI agent execution: Each story must be completable by a single AI agent in one focused session without context overflow
- Think "junior developer working for 2-4 hours" - stories must be small, focused, and self-contained
- If a story seems complex, break it down further as long as it can deliver a vertical slice
elicit: true
template: "{{epic_goal}}"
sections:
- id: story
title: Story {{epic_number}}.{{story_number}} {{story_title}}
repeatable: true
instruction: Provide a clear, concise description of what this story implements. Focus on the specific game feature or system being built. Reference the GDD section that defines this feature and reference the gamearchitecture section for additional implementation and integration specifics.
template: "{{clear_description_of_what_needs_to_be_implemented}}"
sections:
- id: acceptance-criteria
title: Acceptance Criteria
instruction: Define specific, testable conditions that must be met for the story to be considered complete. Each criterion should be verifiable and directly related to gameplay functionality.
sections:
- id: functional-requirements
title: Functional Requirements
type: checklist
items:
- "{{specific_functional_requirement}}"
- id: technical-requirements
title: Technical Requirements
type: checklist
items:
- Code follows GDScript/C# best practices with static typing
- Maintains 60+ FPS on all target devices
- No memory leaks, proper signal cleanup, object pooling active
- "{{specific_technical_requirement}}"
- id: game-design-requirements
title: Game Design Requirements
type: checklist
items:
- "{{gameplay_requirement_from_gdd}}"
- "{{balance_requirement_if_applicable}}"
- "{{player_experience_requirement}}"
- id: success-metrics
title: Success Metrics & Quality Assurance
instruction: Define measurable goals for the Godot game development project with specific targets that can be validated through Godot profiler and performance monitoring.
elicit: true
sections:
- id: technical-metrics
title: Technical Performance Metrics
type: bullet-list
template: |
- **Frame Rate:** Consistent {{fps_target}} FPS with <5% drops below {{min_fps}}
- **Load Times:** Initial load <{{initial_load}}s, level transitions <{{level_load}}s
- **Memory Usage:** Heap memory <{{heap_limit}}MB, texture memory <{{texture_limit}}MB
- **Crash Rate:** <{{crash_threshold}}% across all supported platforms
- **Build Size:** Final build <{{size_limit}}MB for mobile, <{{desktop_limit}}MB for desktop
- **Battery Life:** Mobile gameplay sessions >{{battery_target}} hours on average device
examples:
- "Frame Rate: Consistent 60 FPS with <5% drops below 45 FPS on target hardware"
- "Crash Rate: <0.5% across iOS/Android, <0.1% on desktop platforms"
- id: gameplay-metrics
title: Gameplay & User Engagement Metrics
type: bullet-list
template: |
- **Tutorial Completion:** {{tutorial_rate}}% of players complete basic tutorial
- **Level Progression:** {{progression_rate}}% reach level {{target_level}} within first session
- **Session Duration:** Average session length {{session_target}} minutes
- **Player Retention:** Day 1: {{d1_retention}}%, Day 7: {{d7_retention}}%, Day 30: {{d30_retention}}%
- **Gameplay Completion:** {{completion_rate}}% complete main game content
- **Control Responsiveness:** Input lag <{{input_lag}}ms on all platforms
examples:
- "Tutorial Completion: 85% of players complete movement and basic mechanics tutorial"
- "Session Duration: Average 15-20 minutes per session for mobile, 30-45 minutes for desktop"
- id: platform-specific-metrics
title: Platform-Specific Quality Metrics
type: table
template: |
| Platform | Frame Rate | Load Time | Memory | Build Size | Battery |
| -------- | ---------- | --------- | ------ | ---------- | ------- |
| {{platform}} | {{fps}} | {{load}} | {{memory}} | {{size}} | {{battery}} |
examples:
- iOS, 60 FPS, <3s, <150MB, <80MB, 3+ hours
- Android, 60 FPS, <5s, <200MB, <100MB, 2.5+ hours
- id: next-steps-integration
title: Next Steps & BMad Integration
instruction: Define how this GDD integrates with BMad's agent workflow and what follow-up documents or processes are needed.
sections:
- id: architecture-handoff
title: Godot Architecture Requirements
instruction: Summary of key architectural decisions that need to be implemented in Godot project setup with TDD and performance focus
type: bullet-list
template: |
- Godot {{godot_version}} project with {{renderer}} renderer
- {{architecture_pattern}} node architecture with {{folder_structure}}
- Language strategy: GDScript for {{gdscript_use}}, C# for {{csharp_use}}
- Performance targets: 60+ FPS mandatory, {{key_performance_metrics}}
- Platform exports: {{deployment_targets}} with export templates
- id: story-creation-guidance
title: Story Creation Guidance for SM Agent
instruction: Provide guidance for the Story Manager (SM) agent on how to break down this GDD into implementable user stories
template: |
**Epic Prioritization:** {{epic_order_rationale}}
**Story Sizing Guidelines:**
- Foundation stories: {{foundation_story_scope}}
- Feature stories: {{feature_story_scope}}
- Polish stories: {{polish_story_scope}}
**Godot-Specific Story Considerations:**
- Each story should result in testable Godot scenes with GUT/GoDotTest coverage
- Include specific node hierarchies and signal flows in acceptance criteria
- Enforce 60+ FPS performance validation in each story
- Account for export template configuration and deployment
- Specify language choice (GDScript vs C#) for each component
examples:
- "Foundation stories: Individual Godot systems with TDD (InputMap, Audio Bus, Scene Tree) - 1-2 days each"
- "Feature stories: Complete gameplay mechanics with 60+ FPS validation - 2-4 days each"
- id: recommended-agents
title: Recommended BMad Agent Sequence
type: numbered-list
template: |
1. **{{agent_name}}**: {{agent_responsibility}}
examples:
- "Godot Architect: Create detailed technical architecture with node patterns and language strategy"
- "Godot Developer: Implement systems with TDD (GUT/GoDotTest) maintaining 60+ FPS"
- "QA Tester: Validate performance targets, signal cleanup, and platform exports"

209
expansion-packs/bmad-godot-game-dev/templates/game-prd-tmpl.yaml Normal file
View File

@@ -0,0 +1,209 @@
# <!-- Powered by BMAD™ Core -->
template:
id: game-prd-template-v2
name: Product Requirements Document
version: 2.0
output:
format: markdown
filename: docs/game-prd.md
title: "{{project_name}} Godot Product Requirements Document (PRD)"
workflow:
mode: interactive
elicitation: advanced-elicitation
sections:
- id: goals-context
title: Goals and Background Context
instruction: |
Ask if Project Brief document is available. If NO Project Brief exists, STRONGLY recommend creating one first using game-brief-tmpl (it provides essential foundation: problem statement, target users, success metrics, MVP scope, constraints). If user insists on PRD without brief, gather this information during Goals section. If Project Brief exists, review and use it to populate Goals (bullet list of desired outcomes) and Background Context (1-2 paragraphs on what this solves and why) so we can determine what is and is not in scope for PRD mvp. Either way this is critical to determine the requirements. Include Change Log table.
sections:
- id: goals
title: Goals
type: bullet-list
instruction: Bullet list of 1 line desired outcomes the game will deliver if successful - player experiences and gameplay goals
- id: background
title: Background Context
type: paragraphs
instruction: 1-2 short paragraphs summarizing the game concept, target audience, genre influences, what player need or desire this game fulfills, competitive landscape
- id: changelog
title: Change Log
type: table
columns: [Date, Version, Description, Author]
instruction: Track document versions and changes
- id: requirements
title: Requirements
instruction: Draft the list of functional and non functional requirements under the two child sections
elicit: true
sections:
- id: functional
title: Functional
type: numbered-list
prefix: FR
instruction: Each Requirement will be a bullet markdown and an identifier sequence starting with FR
examples:
- "FR6: The player character can double jump after collecting the Wing Boots power-up."
- "FR7: Enemy AI uses Godot's NavigationAgent2D to pathfind around obstacles."
- "FR8: The inventory system supports drag-and-drop item management."
- id: non-functional
title: Non Functional
type: numbered-list
prefix: NFR
instruction: Each Requirement will be a bullet markdown and an identifier sequence starting with NFR
examples:
- "NFR1: Game must maintain 60 FPS on mid-range hardware (GTX 1060 or equivalent)."
- "NFR2: All UI elements must be readable at 720p resolution minimum."
- "NFR3: Save files must be compatible across all target platforms."
- id: ui-goals
title: Game UI/UX Design Goals
condition: Game has UI/menu requirements
instruction: |
Capture high-level game UI/UX vision to guide Game Designer and inform implementation. Steps:
1. Pre-fill all subsections with educated guesses based on game genre and platform
2. Present the complete rendered section to user
3. Clearly let the user know where assumptions were made
4. Ask targeted questions for unclear/missing elements or areas needing more specification
5. This is NOT detailed UI spec - focus on player experience and game feel
elicit: true
choices:
accessibility: [None, Basic, Colorblind Support, Full Accessibility]
platforms: [PC Only, Mobile Only, PC + Mobile, PC + Console, All Platforms]
sections:
- id: ux-vision
title: Overall Game UX Vision
- id: interaction-paradigms
title: Control Schemes and Input Methods
- id: core-screens
title: Core Game Screens and Menus
instruction: From a game design perspective, what are the most critical screens, menus, and HUD elements necessary to deliver the gameplay experience? This is meant to be Conceptual High Level to Drive Rough Epic or Game Stories
examples:
- "Main Menu"
- "Game HUD (health, score, inventory)"
- "Pause Menu"
- "Level Select Screen"
- "Character Customization"
- "Settings/Options Menu"
- id: accessibility
title: "Accessibility: {None|Basic|Colorblind Support|Full Accessibility}"
- id: branding
title: Branding
instruction: Any known branding elements or style guides that must be incorporated?
examples:
- "Pixel art style inspired by 16-bit era JRPGs with modern lighting effects."
- "Dark fantasy aesthetic with muted colors and Gothic UI elements."
- "Vibrant cartoon style with thick outlines and cel-shading."
- id: target-platforms
title: "Target Platforms: {PC Only|Mobile Only|PC + Mobile|PC + Console|All Platforms}"
examples:
- "Windows, Linux, Mac via Steam"
- "iOS and Android via App Stores"
- "PC (Steam) + Nintendo Switch"
- "Web export for itch.io"
- id: technical-assumptions
title: Godot Technical Assumptions
instruction: |
Gather Godot-specific technical decisions that will guide development. Steps:
1. Check if {root}/data/godot-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices
2. Ask user about: Godot version, 2D/3D, GDScript/C#, plugins/addons, target platforms, networking needs
3. For unknowns, offer guidance based on game type and target platforms
4. Document ALL technical choices with rationale (why this choice fits the game)
5. These become constraints for development - be specific and complete
elicit: true
choices:
godot_version: [Godot 4.4, Godot 4.3, Godot 3.x]
architecture: [Single Player, Local Multiplayer, Online Multiplayer, MMO]
testing: [Manual Playtesting, Automated Tests, Both]
sections:
- id: godot-version
title: "Godot Version: {4.4|4.3|3.x}"
- id: game-architecture
title: Game Architecture
instruction: "CRITICAL DECISION - Document the game architecture (e.g., Single Player, Local Co-op, Online PvP, Server-Authoritative Multiplayer, P2P)."
- id: testing-requirements
title: Testing & QA Requirements
instruction: "CRITICAL DECISION - Document playtesting approach, automated testing needs (if any), performance profiling requirements, platform certification requirements."
- id: additional-assumptions
title: Additional Godot Technical Assumptions
instruction: Throughout the entire process of drafting this document, if any other Godot-specific technical assumptions are raised (rendering pipeline, physics engine settings, audio system, input handling), add them here as additional bulleted items
- id: epic-list
title: Epic List
instruction: |
Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
CRITICAL: Epics MUST be logically sequential following agile best practices:
- Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
- Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic!
- Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
- Not every project needs multiple epics, an epic needs to deliver value. For example, an API completed can deliver value even if a UI is not complete and planned for a separate epic.
- Err on the side of less epics, but let the user know your rationale and offer options for splitting them if it seems some are too large or focused on disparate things.
- Cross Cutting Concerns should flow through epics and stories and not be final stories. For example, adding a logging framework as a last story of an epic, or at the end of a project as a final epic or story would be terrible as we would not have logging from the beginning.
elicit: true
examples:
- "Epic 1: Foundation & Core Systems: Setup Godot project, implement player controller, and basic game loop"
- "Epic 2: Core Gameplay Mechanics: Implement primary game mechanics, combat/interaction systems"
- "Epic 3: Level Design & Content: Create levels, enemies, and game progression"
- "Epic 4: Polish & Game Feel: Add VFX, audio, juice, and game polish"
- "Epic 5: Menus & Meta Systems: Implement save/load, settings, achievements"
- id: epic-details
title: Epic {{epic_number}} {{epic_title}}
repeatable: true
instruction: |
After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit.
For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve).
CRITICAL STORY SEQUENCING REQUIREMENTS:
- Stories within each epic MUST be logically sequential
- Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation
- No story should depend on work from a later story or epic
- Identify and note any direct prerequisite stories
- Focus on "what" and "why" not "how" (leave technical implementation to Architect) yet be precise enough to support a logical sequential order of operations from story to story.
- Ensure each story delivers clear user or business value, try to avoid enablers and build them into stories that deliver value.
- Size stories for AI agent execution: Each story must be completable by a single AI agent in one focused session without context overflow
- Think "junior developer working for 2-4 hours" - stories must be small, focused, and self-contained
- If a story seems complex, break it down further as long as it can deliver a vertical slice
elicit: true
template: "{{epic_goal}}"
sections:
- id: story
title: Story {{epic_number}}.{{story_number}} {{story_title}}
repeatable: true
template: |
As a {{user_type}},
I want {{action}},
so that {{benefit}}.
sections:
- id: acceptance-criteria
title: Acceptance Criteria
type: numbered-list
item_template: "{{criterion_number}}: {{criteria}}"
repeatable: true
instruction: |
Define clear, comprehensive, and testable acceptance criteria that:
- Precisely define what "done" means from a functional perspective
- Are unambiguous and serve as basis for verification
- Include any critical non-functional requirements from the PRD
- Consider local testability for backend/data components
- Specify UI/UX requirements and framework adherence where applicable
- Avoid cross-cutting concerns that should be in other stories or PRD sections
- id: checklist-results
title: Checklist Results Report
instruction: Before running the checklist and drafting the prompts, offer to output the full updated PRD. If outputting it, confirm with the user that you will be proceeding to run the checklist and produce the report. Once the user confirms, execute the pm-checklist and populate the results in this section.
- id: next-steps
title: Next Steps
sections:
- id: architect-prompt
title: Game Architect Prompt
instruction: This section will contain the prompt for the Game Architect, keep it short and to the point to initiate Godot architecture design using this document as input.

186
expansion-packs/bmad-godot-game-dev/templates/game-qa-gate-tmpl.yaml Normal file
View File

@@ -0,0 +1,186 @@
template:
id: godot-qa-gate-template-v2
name: Godot Game Quality Gate Decision
version: 2.0
output:
format: yaml
filename: docs/qa/gates/{{epic_num}}.{{story_num}}-{{story_slug}}.yml
title: "Godot Quality Gate: {{epic_num}}.{{story_num}}"
# Required fields (keep these first)
schema: 1
story: "{{epic_num}}.{{story_num}}"
story_title: "{{story_title}}"
gate: "{{gate_status}}" # PASS|CONCERNS|FAIL|WAIVED
status_reason: "{{status_reason}}" # 1-2 sentence summary focusing on TDD compliance and 60+ FPS performance
reviewer: "Linus (Godot Game Test Architect)"
updated: "{{iso_timestamp}}"
# Always present but only active when WAIVED
waiver: { active: false }
# Godot-specific Issues (if any) - Use fixed severity: low | medium | high
top_issues: [] # Focus on performance drops below 60 FPS, missing TDD tests, wrong language choices
# Risk summary (from risk-profile task if run)
risk_summary:
totals: { critical: 0, high: 0, medium: 0, low: 0 }
recommendations:
must_fix: []
monitor: []
# Godot examples section using block scalars for clarity
examples:
with_issues: |
top_issues:
- id: "PERF-001"
severity: high # ONLY: low|medium|high
finding: "Frame rate drops to 45 FPS during particle spawning"
suggested_action: "Implement object pooling for particle systems"
- id: "TDD-001"
severity: high
finding: "No GUT tests for player controller despite GDScript implementation"
suggested_action: "Add GUT test coverage before marking story complete"
- id: "LANG-001"
severity: medium
finding: "Physics system using GDScript instead of C# causing performance issues"
suggested_action: "Refactor physics calculations to C# for better performance"
when_waived: |
waiver:
active: true
reason: "Performance at 55 FPS acceptable for early access - optimization planned for next sprint"
approved_by: "Product Owner"
# ============ Optional Extended Fields ============
# Uncomment and use if your team wants more detail
# CRITICAL: Gates should FAIL if performance drops below 60 FPS or TDD is not followed
optional_fields_examples:
quality_and_expiry: |
quality_score: 75 # 100 - (20*FAILs) - (10*CONCERNS) - (5*FPS_drops_below_60)
expires: "2025-01-26T00:00:00Z" # Optional gate freshness window
evidence: |
evidence:
gut_tests_reviewed: 15 # GDScript tests
godottest_reviewed: 8 # C# tests
performance_validated: true # 60+ FPS confirmed
language_strategy_verified: true # GDScript/C# choices appropriate
trace:
ac_covered: [1, 2, 3] # AC numbers with GUT/GoDotTest coverage
ac_gaps: [4] # AC numbers lacking TDD coverage
fps_validation: "60+ FPS on all target platforms"
nfr_validation: |
nfr_validation:
performance: { status: PASS, notes: "60+ FPS maintained, frame time <16.67ms" }
tdd_compliance: { status: PASS, notes: "GUT coverage 85%, GoDotTest coverage 80%" }
language_strategy: { status: PASS, notes: "GDScript for logic, C# for physics - appropriate" }
object_pooling: { status: CONCERNS, notes: "Pooling missing for bullet spawns" }
signal_cleanup: { status: PASS, notes: "All signals properly disconnected" }
platform_exports: { status: PASS, notes: "Export templates configured for all targets" }
history: |
history: # Append-only audit trail
- at: "2025-01-12T10:00:00Z"
gate: FAIL
note: "Initial review - FPS dropped to 45, no GUT tests"
- at: "2025-01-12T15:00:00Z"
gate: CONCERNS
note: "GUT tests added, FPS improved to 58 - needs object pooling"
risk_summary: |
risk_summary: # From Godot risk-profile task
totals:
critical: 0 # FPS < 30 or no TDD
high: 0 # FPS < 60 or wrong language choice
medium: 0 # Missing optimizations
low: 0 # Minor issues
# 'highest' is emitted only when risks exist
recommendations:
must_fix: [] # Performance below 60 FPS, missing TDD
monitor: [] # Language strategy concerns
recommendations: |
recommendations:
immediate: # Must fix before production
- action: "Implement object pooling for all spawned entities"
refs: ["res://scripts/spawners/bullet_spawner.gd:42-68"]
- action: "Add GUT tests for player controller"
refs: ["res://scripts/player/player_controller.gd"]
- action: "Optimize particle system to maintain 60+ FPS"
refs: ["res://scenes/effects/particles.tscn"]
future: # Can be addressed later
- action: "Consider migrating physics to C# for 20% performance gain"
refs: ["res://scripts/physics/physics_manager.gd"]
- action: "Add performance benchmarks to GUT test suite"
refs: ["res://tests/"]
godot_performance_metrics: |
godot_metrics:
frame_rate:
current: 62 # Current FPS
target: 60 # Minimum acceptable (FAIL if below)
peak: 120 # Best achieved
frame_time:
current_ms: 16.1 # Current frame time
target_ms: 16.67 # Maximum for 60 FPS
memory:
scene_mb: 45 # Scene memory usage
texture_mb: 128 # Texture memory
pool_count: 5 # Active object pools
draw_calls:
current: 85
budget: 100 # Platform-specific budget
language_distribution:
gdscript_files: 45 # With static typing
csharp_files: 12 # Performance-critical systems
test_coverage_metrics: |
test_coverage:
gut_tests:
total: 45
passing: 43
coverage_percent: 85
performance_tests: 8 # Tests validating 60+ FPS
godottest_tests:
total: 20
passing: 20
coverage_percent: 80
physics_tests: 15 # C# physics validation
tdd_compliance:
stories_with_tests_first: 18
stories_without_tests: 2
compliance_percent: 90
# ============ Godot Gate Decision Criteria ============
# Apply these rules in order to determine gate status:
gate_decision_rules: |
1. AUTOMATIC FAIL CONDITIONS:
- Performance below 60 FPS on any target platform
- No TDD tests (neither GUT nor GoDotTest)
- Memory leaks detected (signals not cleaned up)
- Wrong language choice causing performance issues
- Object pooling missing for frequently spawned entities
2. CONCERNS CONDITIONS:
- Performance between 55-59 FPS
- TDD coverage below 80%
- Static typing not used in GDScript
- LINQ usage in C# hot paths
- Scene transitions exceeding 3 seconds
3. PASS CONDITIONS:
- Consistent 60+ FPS across all platforms
- GUT/GoDotTest coverage >= 80%
- Appropriate language choices (GDScript for logic, C# for performance)
- Object pooling implemented for all spawned entities
- All signals properly connected and cleaned up
4. WAIVER ONLY WITH:
- Product Owner approval
- Clear remediation plan
- Timeline for fixing issues
- Risk acceptance documented

406
expansion-packs/bmad-godot-game-dev/templates/game-story-tmpl.yaml Normal file
View File

@@ -0,0 +1,406 @@
template:
id: godot-game-story-template-v4
name: Godot Game Development Story
version: 4.0
output:
format: markdown
filename: "stories/{{epic_name}}/{{story_id}}-{{story_name}}.md"
title: "Godot Story: {{story_title}}"
workflow:
mode: interactive
sections:
- id: initial-setup
instruction: |
This template creates detailed Godot game development stories with TDD focus and 60+ FPS performance requirements. Each story should focus on a single, implementable feature using appropriate language choices (GDScript for logic, C# for performance-critical systems).
Before starting, ensure you have access to:
- Game Design Document (GDD) with Godot specifications
- Game Architecture Document with node hierarchy
- Language strategy decisions (GDScript vs C#)
- Performance targets (60+ FPS mandatory)
- Any existing stories in this epic
The story must include TDD requirements (GUT for GDScript, GoDotTest for C#) and performance validation steps.
- id: story-header
content: |
**Epic:** {{epic_name}}
**Story ID:** {{story_id}}
**Priority:** {{High|Medium|Low}}
**Points:** {{story_points}}
**Status:** Draft
**Language:** {{GDScript|C#|Both}}
**Performance Target:** 60+ FPS
- id: description
title: Description
instruction: Provide a clear, concise description of what this story implements in Godot. Focus on the specific game feature, node architecture, and language choice rationale. Reference the GDD section and performance requirements.
template: |
{{clear_description_of_what_needs_to_be_implemented}}
**Godot Implementation:** Using {{node_types}} with {{language_choice}} for {{performance_reason}}
**Performance Impact:** {{expected_fps_impact}}
- id: acceptance-criteria
title: Acceptance Criteria
instruction: Define specific, testable conditions that must be met for the story to be considered complete. Each criterion should be verifiable and directly related to gameplay functionality.
sections:
- id: functional-requirements
title: Functional Requirements
type: checklist
items:
- "{{specific_functional_requirement}}"
- id: technical-requirements
title: Technical Requirements
type: checklist
items:
- Code follows GDScript/C# best practices with static typing
- Maintains 60+ FPS on all target devices (frame time <16.67ms)
- Object pooling implemented for spawned entities
- Signals properly connected and cleaned up
- GUT/GoDotTest coverage >= 80%
- "{{specific_technical_requirement}}"
- id: game-design-requirements
title: Game Design Requirements
type: checklist
items:
- "{{gameplay_requirement_from_gdd}}"
- "{{balance_requirement_if_applicable}}"
- "{{player_experience_requirement}}"
- id: technical-specifications
title: Technical Specifications
instruction: Provide specific Godot technical details including node hierarchy, signal flow, and language decisions. Include scene structure and resource requirements.
sections:
- id: files-to-modify
title: Files to Create/Modify
template: |
**New Scenes (.tscn):**
- `res://scenes/{{scene_name}}.tscn` - {{purpose}}
**New Scripts:**
- `res://scripts/{{script_name}}.gd` - {{gdscript_purpose}} (static typing required)
- `res://scripts/{{script_name}}.cs` - {{csharp_purpose}} (for performance)
**New Resources (.tres):**
- `res://resources/{{resource_name}}.tres` - {{resource_purpose}}
**Modified Files:**
- `{{existing_file_1}}` - {{changes_needed}}
- `{{existing_file_2}}` - {{changes_needed}}
- id: class-interface-definitions
title: Node/Class Definitions
instruction: Define specific Godot node structures and classes with language strategy
template: |
**GDScript Implementation (for game logic):**
```gdscript
# {{script_name}}.gd
class_name {{ClassName}}
extends {{Node2D|Control|Node3D}}
# Static typing mandatory for 10-20% performance gain
@export var {{property_name}}: {{type}} = {{default_value}}
var _{{private_property}}: {{type}}
signal {{signal_name}}({{params}})
func _ready() -> void:
# TDD: Write GUT tests first
pass
func _physics_process(delta: float) -> void:
# Must maintain 60+ FPS
pass
```
**C# Implementation (for performance-critical systems):**
```csharp
// {{script_name}}.cs
using Godot;
[GlobalClass]
public partial class {{ClassName}} : {{Node2D|Control|Node3D}}
{
[Export] public {{type}} {{PropertyName}} { get; set; }
[Signal]
public delegate void {{SignalName}}EventHandler({{params}});
public override void _Ready()
{
// TDD: Write GoDotTest tests first
// No LINQ in hot paths
}
public override void _PhysicsProcess(double delta)
{
// Optimize for 60+ FPS, no allocations
}
}
```
- id: integration-points
title: Integration Points
instruction: Specify how this feature integrates with existing Godot systems
template: |
**Scene Tree Integration:**
- Parent Scene: `res://scenes/{{parent_scene}}.tscn`
- Node Path: `/root/{{node_path}}`
- Scene Instancing: {{instancing_details}}
**Node Dependencies:**
- {{node_name}}: {{dependency_description}}
- Language: {{GDScript|C#}} - {{language_reason}}
**Signal Connections:**
- Emits: `{{signal_name}}` when {{condition}}
- Connects to: `{{node_path}}.{{signal_name}}` for {{response}}
- Cleanup: Signals disconnected in `_exit_tree()`
**Resource Dependencies:**
- `res://resources/{{resource}}.tres` - {{usage}}
- Preloaded: {{yes|no}} - {{preload_reason}}
- id: tdd-workflow
title: TDD Workflow (Red-Green-Refactor)
instruction: Define the Test-Driven Development approach for this story
template: |
**RED Phase - Write Failing Tests First:**
GDScript (GUT):
- [ ] Create test file: `res://tests/unit/test_{{component}}.gd`
- [ ] Write test for {{behavior_1}} - expect failure
- [ ] Write test for {{behavior_2}} - expect failure
- [ ] Write performance test for 60+ FPS - expect failure
C# (GoDotTest):
- [ ] Create test file: `res://tests/unit/{{Component}}Tests.cs`
- [ ] Write test for {{behavior_1}} - expect failure
- [ ] Write optimization test (no allocations) - expect failure
**GREEN Phase - Make Tests Pass:**
- [ ] Implement minimal code to pass {{behavior_1}} test
- [ ] Implement minimal code to pass {{behavior_2}} test
- [ ] Ensure 60+ FPS requirement is met
- [ ] Verify all tests are green
**REFACTOR Phase - Optimize and Clean:**
- [ ] Add static typing to all GDScript (10-20% perf gain)
- [ ] Remove LINQ from C# hot paths
- [ ] Implement object pooling for {{spawned_entities}}
- [ ] Clean up signal connections
- [ ] Profile and verify 60+ FPS maintained
- [ ] Ensure test coverage >= 80%
- id: implementation-tasks
title: Implementation Tasks
instruction: Break down the implementation into TDD-focused tasks following Red-Green-Refactor cycle. Each task should maintain 60+ FPS.
sections:
- id: dev-agent-record
title: Dev Agent Record
template: |
**TDD Tasks (Red-Green-Refactor):**
- [ ] Write GUT/GoDotTest tests for {{component}} (RED phase)
- [ ] Implement {{node_structure}} to pass tests (GREEN phase)
- [ ] Refactor with static typing and optimization (REFACTOR phase)
- [ ] Create object pool for {{spawned_entities}}
- [ ] Implement signal connections with cleanup
- [ ] Profile performance to ensure 60+ FPS
- [ ] Language optimization (GDScript static typing or C# no-LINQ)
- [ ] Integration testing with {{related_system}}
- [ ] Final performance validation (must maintain 60+ FPS)
**Debug Log:**
| Task | File | Change | Reverted? |
|------|------|--------|-----------|
| | | | |
**Completion Notes:**
<!-- Only note deviations from requirements, keep under 50 words -->
**Change Log:**
<!-- Only requirement changes during implementation -->
- id: godot-technical-context
title: Godot Technical Context
instruction: Define the Godot-specific technical implementation details
template: |
**Engine Version:** Godot {{version}} (4.3+ recommended)
**Renderer:** {{Forward+|Mobile|Compatibility}}
**Primary Language:** {{GDScript|C#}} - {{reason}}
**Node Architecture:**
```
{{parent_node}}
└── {{child_node_1}} ({{node_type}})
├── {{child_node_2}} ({{node_type}})
└── {{child_node_3}} ({{node_type}})
```
**Performance Requirements:**
- Target FPS: 60+ (mandatory)
- Frame Budget: 16.67ms
- Memory Budget: {{memory_mb}}MB
- Draw Calls: < {{draw_calls}}
**Object Pooling Required:**
- {{entity_type}}: Pool size {{pool_size}}
- Recycling strategy: {{strategy}}
- id: game-design-context
title: Game Design Context
instruction: Reference the specific sections of the GDD that this story implements with Godot-specific details
template: |
**GDD Reference:** {{section_name}} ({{page_or_section_number}})
**Game Mechanic:** {{mechanic_name}}
**Godot Implementation Approach:**
- Node Architecture: {{node_hierarchy}}
- Language Choice: {{GDScript|C#}} for {{reason}}
- Performance Target: 60+ FPS with {{expected_load}}
**Player Experience Goal:** {{experience_description}}
**Balance Parameters (Resource-based):**
- {{parameter_1}}: {{value_or_range}} (stored in .tres)
- {{parameter_2}}: {{value_or_range}} (exported variable)
- id: testing-requirements
title: Testing Requirements
instruction: Define specific TDD testing criteria with GUT (GDScript) and GoDotTest (C#) frameworks
sections:
- id: unit-tests
title: Unit Tests (TDD Mandatory)
template: |
**GUT Test Files (GDScript):**
- `res://tests/unit/test_{{component_name}}.gd`
- Coverage Target: 80% minimum
**GoDotTest Files (C#):**
- `res://tests/unit/{{ComponentName}}Tests.cs`
- No LINQ in test hot paths
**Test Scenarios (Write First - Red Phase):**
- {{test_scenario_1}} - Must validate 60+ FPS
- {{test_scenario_2}} - Signal emission verification
- {{edge_case_test}} - Object pool boundary testing
- Performance test: Frame time < 16.67ms
- id: game-testing
title: Game Testing
template: |
**Manual Test Cases (Godot Editor):**
1. {{test_case_1_description}}
- Expected: {{expected_behavior}}
- Performance: Must maintain 60+ FPS
- Profiler Check: Frame time < 16.67ms
- Language Validation: {{GDScript|C#}} performing as expected
2. {{test_case_2_description}}
- Expected: {{expected_behavior}}
- Signal Flow: {{signal_verification}}
- Memory: No leaks, signals cleaned up
- Object Pools: Verify pooling active
- id: performance-tests
title: Performance Tests
template: |
**Godot Profiler Metrics (Mandatory):**
- Frame rate: 60+ FPS consistently (FAIL if below)
- Frame time: < 16.67ms average
- Physics frame: < {{physics_time}}ms
- Memory usage: < {{memory_limit}}MB
- Draw calls: < {{draw_call_budget}}
- Object pools: Active and recycling properly
- GDScript static typing: Verified (10-20% perf gain)
- C# optimization: No LINQ, no allocations in hot paths
- {{feature_specific_performance_metric}}
- id: dependencies
title: Dependencies
instruction: List any dependencies including Godot-specific requirements
template: |
**Story Dependencies:**
- {{story_id}}: {{dependency_description}}
**Godot System Dependencies:**
- Node: {{parent_node}} must exist in scene tree
- Autoload: {{autoload_singleton}} configured
- Language: {{prerequisite_language_setup}}
**Resource Dependencies:**
- Resource Type: {{.tres|.tscn}}
- Asset: {{asset_description}}
- Location: `res://{{asset_path}}`
- Import Settings: {{import_configuration}}
- id: definition-of-done
title: Definition of Done
instruction: Checklist that must be completed with focus on Godot, TDD, and performance
type: checklist
items:
- All acceptance criteria met
- TDD followed (tests written first, then implementation)
- GUT tests passing (GDScript) with 80%+ coverage
- GoDotTest passing (C#) with 80%+ coverage
- Performance: 60+ FPS maintained on all platforms
- Static typing used in all GDScript
- C# optimized (no LINQ in hot paths)
- Object pooling active for spawned entities
- Signals properly connected and cleaned up
- No GDScript or C# errors/warnings
- Node hierarchy follows architecture
- Resources (.tres) configured properly
- Export templates tested
- Documentation updated
- "{{game_specific_dod_item}}"
- id: notes
title: Notes
instruction: Any additional Godot-specific context, language decisions, or optimization notes
template: |
**Godot Implementation Notes:**
- Language Choice: {{GDScript|C#}} because {{performance_reason}}
- Node Architecture: {{node_pattern}} for {{benefit}}
- Signal Pattern: {{signal_strategy}}
- {{note_1}}
**Performance Decisions:**
- Static Typing: {{gdscript_typing_strategy}} for 10-20% gain
- C# Usage: {{csharp_systems}} for critical performance
- Object Pooling: {{pooling_strategy}} for spawned entities
- {{decision_1}}: {{rationale}}
**Future Optimizations:**
- Consider migrating {{system}} to C# if FPS drops
- Implement LOD for {{complex_nodes}}
- Add performance benchmarks to test suite
- {{future_optimization_1}}

601
expansion-packs/bmad-godot-game-dev/templates/game-ui-spec-tmpl.yaml Normal file
View File

@@ -0,0 +1,601 @@
template:
id: frontend-spec-template-v2
name: UI/UX Specification
version: 2.0
output:
format: markdown
filename: docs/front-end-spec.md
title: "{{project_name}} UI/UX Specification"
workflow:
mode: interactive
elicitation: advanced-elicitation
sections:
- id: introduction
title: Introduction
instruction: |
Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification.
Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.
content: |
This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience.
sections:
- id: ux-goals-principles
title: Overall UX Goals & Principles
instruction: |
Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine:
1. Target User Personas - elicit details or confirm existing ones from PRD
2. Key Usability Goals - understand what success looks like for users
3. Core Design Principles - establish 3-5 guiding principles
elicit: true
sections:
- id: user-personas
title: Target User Personas
template: "{{persona_descriptions}}"
examples:
- "**Power User:** Technical professionals who need advanced features and efficiency"
- "**Casual User:** Occasional users who prioritize ease of use and clear guidance"
- "**Administrator:** System managers who need control and oversight capabilities"
- id: usability-goals
title: Usability Goals
template: "{{usability_goals}}"
examples:
- "Ease of learning: New users can complete core tasks within 5 minutes"
- "Efficiency of use: Power users can complete frequent tasks with minimal clicks"
- "Error prevention: Clear validation and confirmation for destructive actions"
- "Memorability: Infrequent users can return without relearning"
- id: design-principles
title: Design Principles
template: "{{design_principles}}"
type: numbered-list
examples:
- "**Clarity over cleverness** - Prioritize clear communication over aesthetic innovation"
- "**Progressive disclosure** - Show only what's needed, when it's needed"
- "**Consistent patterns** - Use familiar UI patterns throughout the application"
- "**Immediate feedback** - Every action should have a clear, immediate response"
- "**Accessible by default** - Design for all users from the start"
- id: changelog
title: Change Log
type: table
columns: [Date, Version, Description, Author]
instruction: Track document versions and changes
- id: information-architecture
title: Information Architecture (IA)
instruction: |
Collaborate with the user to create a comprehensive information architecture:
1. Build a Site Map or Screen Inventory showing all major areas
2. Define the Navigation Structure (primary, secondary, breadcrumbs)
3. Use Mermaid diagrams for visual representation
4. Consider user mental models and expected groupings
elicit: true
sections:
- id: sitemap
title: Site Map / Screen Inventory
type: mermaid
mermaid_type: graph
template: "{{sitemap_diagram}}"
examples:
- |
graph TD
A[Homepage] --> B[Dashboard]
A --> C[Products]
A --> D[Account]
B --> B1[Analytics]
B --> B2[Recent Activity]
C --> C1[Browse]
C --> C2[Search]
C --> C3[Product Details]
D --> D1[Profile]
D --> D2[Settings]
D --> D3[Billing]
- id: navigation-structure
title: Navigation Structure
template: |
**Primary Navigation:** {{primary_nav_description}}
**Secondary Navigation:** {{secondary_nav_description}}
**Breadcrumb Strategy:** {{breadcrumb_strategy}}
- id: user-flows
title: User Flows
instruction: |
For each critical user task identified in the PRD:
1. Define the user's goal clearly
2. Map out all steps including decision points
3. Consider edge cases and error states
4. Use Mermaid flow diagrams for clarity
5. Link to external tools (Figma/Miro) if detailed flows exist there
Create subsections for each major flow.
elicit: true
repeatable: true
sections:
- id: flow
title: "{{flow_name}}"
template: |
**Player Goal:** {{flow_goal}}
**Entry Scene:** {{entry_scene}}.tscn
**Input Methods:** {{supported_inputs}}
**Performance Target:** 60+ FPS throughout
**Success Criteria:** {{success_criteria}}
sections:
- id: flow-diagram
title: Flow Diagram
type: mermaid
mermaid_type: graph
template: "{{flow_diagram}}"
- id: edge-cases
title: "Edge Cases & Error Handling:"
type: bullet-list
template: "- {{edge_case}}"
- id: notes
template: "**Notes:** {{flow_notes}}"
- id: wireframes-mockups
title: Wireframes & Mockups
instruction: |
Clarify where detailed visual designs will be created (Figma, Sketch, etc.) and how to reference them. If low-fidelity wireframes are needed, offer to help conceptualize layouts for key screens.
elicit: true
sections:
- id: design-files
template: "**Primary Design Files:** {{design_tool_link}}"
- id: key-scene-layouts
title: Key UI Scene Layouts
repeatable: true
sections:
- id: scene
title: "{{scene_name}}.tscn"
template: |
**Purpose:** {{scene_purpose}}
**Control Node Hierarchy:**
```
Control (root)
├── MarginContainer
│ └── VBoxContainer
│ ├── {{element_1}}
│ ├── {{element_2}}
│ └── {{element_3}}
```
**Anchoring Strategy:** {{anchor_preset}}
**InputMap Actions:** {{input_actions}}
**Performance Impact:** {{fps_impact}}
**Theme Resource:** res://themes/{{theme_name}}.tres
- id: component-library
title: Godot UI Component Library
instruction: |
Define reusable Godot UI scenes and Control node patterns. Specify theme resources, custom Control classes, and performance considerations. Focus on scene inheritance and instancing patterns.
elicit: true
sections:
- id: godot-ui-approach
template: |
**Godot UI Approach:** {{ui_approach}}
**Theme Strategy:** {{theme_strategy}}
- Base Theme: res://themes/base_theme.tres
- Theme Overrides: {{override_strategy}}
**Language Choice:** {{GDScript|C#}} for UI logic
- Rationale: {{language_reason}}
- id: core-components
title: Core Components
repeatable: true
sections:
- id: component
title: "{{component_name}}"
template: |
**Scene Path:** res://ui/components/{{component_name}}.tscn
**Purpose:** {{component_purpose}}
**Control Type:** {{control_node_type}}
**Signals:**
- {{signal_1}}
- {{signal_2}}
**Export Variables:**
- @export var {{var_name}}: {{type}}
**States:** {{component_states}}
**Performance:** {{performance_notes}}
**Usage Guidelines:** {{usage_guidelines}}
- id: branding-style
title: Game Visual Style Guide
instruction: Define visual style for Godot UI using themes, stylebox resources, and shader materials. Ensure consistency across all UI scenes while maintaining 60+ FPS.
elicit: true
sections:
- id: visual-identity
title: Visual Identity
template: |
**Game Art Style:** {{art_style}}
**Godot Theme Resources:**
- Main Theme: res://themes/main_theme.tres
- Dark Theme: res://themes/dark_theme.tres
**StyleBox Resources:**
- Panel: res://themes/styles/panel_style.tres
- Button: res://themes/styles/button_style.tres
- id: color-palette
title: Color Palette
type: table
columns: ["Color Type", "Hex Code", "Usage"]
rows:
- ["Primary", "{{primary_color}}", "{{primary_usage}}"]
- ["Secondary", "{{secondary_color}}", "{{secondary_usage}}"]
- ["Accent", "{{accent_color}}", "{{accent_usage}}"]
- ["Success", "{{success_color}}", "Positive feedback, confirmations"]
- ["Warning", "{{warning_color}}", "Cautions, important notices"]
- ["Error", "{{error_color}}", "Errors, destructive actions"]
- ["Neutral", "{{neutral_colors}}", "Text, borders, backgrounds"]
- id: typography
title: Typography
sections:
- id: font-families
title: Font Resources
template: |
- **Primary:** res://fonts/{{primary_font}}.ttf
- **Secondary:** res://fonts/{{secondary_font}}.ttf
- **Monospace:** res://fonts/{{mono_font}}.ttf
**Dynamic Font Settings:**
- Use Mipmaps: true (for scaling)
- Antialiasing: true
- Hinting: Light
- id: type-scale
title: Type Scale
type: table
columns: ["Element", "Size", "Weight", "Line Height"]
rows:
- ["H1", "{{h1_size}}", "{{h1_weight}}", "{{h1_line}}"]
- ["H2", "{{h2_size}}", "{{h2_weight}}", "{{h2_line}}"]
- ["H3", "{{h3_size}}", "{{h3_weight}}", "{{h3_line}}"]
- ["Body", "{{body_size}}", "{{body_weight}}", "{{body_line}}"]
- ["Small", "{{small_size}}", "{{small_weight}}", "{{small_line}}"]
- id: iconography
title: Iconography
template: |
**Icon Atlas:** res://ui/icons/icon_atlas.png
**Icon Size Standards:**
- Small: 16x16
- Medium: 32x32
- Large: 64x64
**Texture Import Settings:**
- Filter: Linear (for smooth scaling)
- Mipmaps: Generate
**Usage Guidelines:** {{icon_guidelines}}
- id: spacing-layout
title: Spacing & Layout
template: |
**Container System:**
- MarginContainer: {{margin_values}}
- Separation (H/VBox): {{separation_pixels}}
- GridContainer columns: {{grid_columns}}
**Anchor Presets:** {{anchor_strategy}}
**Spacing Scale:** {{spacing_scale}} (in pixels)
**Safe Area Margins:** {{safe_margins}} (for mobile)
- id: accessibility
title: Game Accessibility Requirements
instruction: Define specific accessibility requirements for Godot game UI, including input remapping through InputMap, visual adjustments through themes, and performance considerations for accessibility features.
elicit: true
sections:
- id: compliance-target
title: Compliance Target
template: |
**Standard:** {{compliance_standard}}
**Godot Accessibility Features:**
- InputMap remapping support
- Theme system for high contrast
- Font scaling through DynamicFont
- Performance: Accessibility features maintain 60+ FPS
- id: key-requirements
title: Key Requirements
template: |
**Visual (Godot Theme System):**
- Color contrast ratios: {{contrast_requirements}}
- Focus indicators: Custom StyleBox for focused state
- Text sizing: DynamicFont with size range {{min_size}}-{{max_size}}
- Colorblind modes: Theme variants for different types
**Interaction (InputMap):**
- Full keyboard navigation through ui_* actions
- Gamepad support with proper button prompts
- Touch targets: Minimum 44x44 pixels
- Hold-to-confirm for destructive actions
- Input buffer: {{buffer_frames}} frames for combo inputs
**Performance:**
- Accessibility features maintain 60+ FPS
- No additional draw calls for focus indicators
- Theme switching without frame drops
- id: testing-strategy
title: Testing Strategy
template: |
**Godot-Specific Testing:**
- InputMap verification for all UI actions
- Theme contrast validation
- Performance testing with accessibility features enabled
- Touch target size verification
- {{additional_testing}}
- id: responsiveness
title: Godot UI Responsiveness Strategy
instruction: Define viewport scaling, anchor presets, and Control node adaptation strategies for different screen sizes. Consider Godot's stretch modes and aspect ratios while maintaining 60+ FPS.
elicit: true
sections:
- id: viewport-settings
title: Viewport Configuration
template: |
**Project Settings:**
- Base Resolution: {{base_width}}x{{base_height}}
- Stretch Mode: {{canvas_items|viewport|2d}}
- Stretch Aspect: {{keep|keep_width|keep_height|expand}}
**Resolution Support:**
| Resolution | Aspect | Platform | UI Scale |
|------------|--------|----------|----------|
| 1280x720 | 16:9 | Mobile | 1.0x |
| 1920x1080 | 16:9 | Desktop | 1.5x |
| 2560x1440 | 16:9 | Desktop | 2.0x |
| {{custom}} | {{asp}}| {{plat}} | {{scale}}|
- id: adaptation-patterns
title: Godot UI Adaptation Patterns
template: |
**Anchor Presets:**
- Mobile: Full Rect with margins
- Desktop: Center with fixed size
- Wide: Proportional margins
**Container Adjustments:**
- Mobile: VBoxContainer for vertical layout
- Desktop: HBoxContainer or GridContainer
**Control Visibility:**
- Hide/show nodes based on viewport size
- Use Control.visible property
**Font Scaling:**
- DynamicFont size based on viewport
- Maintain readability at all scales
**Performance:** All adaptations maintain 60+ FPS
- id: animation
title: Godot UI Animation & Transitions
instruction: Define AnimationPlayer and Tween-based animations for UI. Ensure all animations maintain 60+ FPS and can be disabled for accessibility.
elicit: true
sections:
- id: motion-principles
title: Motion Principles
template: |
**Godot Animation Guidelines:**
- Use AnimationPlayer for complex sequences
- Use Tweens for simple property animations
- All animations < 0.3s for responsiveness
- Maintain 60+ FPS during animations
- Provide animation_speed setting for accessibility
{{additional_principles}}
- id: key-animations
title: Key UI Animations
repeatable: true
template: |
- **{{animation_name}}:**
- Method: {{AnimationPlayer|Tween}}
- Properties: {{animated_properties}}
- Duration: {{duration}}s
- Easing: {{Trans.LINEAR|Trans.QUAD|Trans.CUBIC}}
- Performance Impact: {{fps_impact}}
- Can Disable: {{yes|no}}
- id: performance
title: UI Performance Requirements
instruction: Define Godot UI performance goals ensuring 60+ FPS is maintained. Consider draw calls, Control node count, and theme complexity.
sections:
- id: performance-goals
title: Performance Goals
template: |
- **Frame Rate:** 60+ FPS mandatory (frame time <16.67ms)
- **Scene Load:** <3 seconds for UI scene transitions
- **Input Response:** <50ms (3 frames at 60 FPS)
- **Draw Calls:** UI should add <20 draw calls
- **Control Nodes:** <100 active Control nodes per scene
- **Theme Complexity:** <10 StyleBox resources active
- id: optimization-strategies
title: Godot UI Optimization Strategies
template: |
**Node Optimization:**
- Use scene instancing for repeated UI elements
- Hide off-screen Control nodes (visible = false)
- Pool dynamic UI elements (popups, tooltips)
**Rendering Optimization:**
- Batch UI draw calls through theme consistency
- Use nine-patch rect for scalable backgrounds
- Minimize transparent overlays
**Update Optimization:**
- Use signals instead of polling for UI updates
- Update UI only when values change
- Batch multiple UI updates in single frame
**Language Choice:**
- GDScript for simple UI logic (with static typing)
- C# for complex UI systems (inventory, crafting)
{{additional_strategies}}
- id: godot-implementation
title: Godot UI Implementation Guide
instruction: |
Define specific Godot implementation details for UI developers including scene structure, script organization, and resource management.
sections:
- id: scene-organization
title: UI Scene Organization
template: |
**Scene Structure:**
```
res://
├── ui/
│ ├── scenes/
│ │ ├── main_menu.tscn
│ │ ├── hud.tscn
│ │ └── {{scene}}.tscn
│ ├── components/
│ │ ├── button.tscn
│ │ └── {{component}}.tscn
│ └── popups/
│ └── {{popup}}.tscn
```
**Script Organization:**
- UI Logic: GDScript with static typing
- Performance-critical: C# for complex systems
- Autoload: UI manager singleton
- id: theme-resources
title: Theme Resource Setup
template: |
**Theme Hierarchy:**
- Base Theme: res://themes/base_theme.tres
- Variations: {{theme_variations}}
**Resource Preloading:**
- Preload frequently used UI scenes
- Load themes at startup
- Cache StyleBox resources
- id: input-configuration
title: InputMap Configuration
template: |
**UI Actions:**
- ui_accept: Space, Enter, Gamepad A
- ui_cancel: Escape, Gamepad B
- ui_up/down/left/right: Arrow keys, WASD, D-pad
- ui_focus_next: Tab, Gamepad RB
- ui_focus_prev: Shift+Tab, Gamepad LB
- {{custom_actions}}
**Touch Gestures:**
- Tap: ui_accept
- Swipe: Navigation
- Pinch: Zoom (if applicable)
- id: next-steps
title: Next Steps
instruction: |
After completing the Godot UI/UX specification:
1. Review with game design team
2. Create UI mockups considering Godot's Control nodes
3. Prepare theme resources and StyleBoxes
4. Set up TDD with GUT tests for UI components
5. Note performance requirements (60+ FPS)
sections:
- id: immediate-actions
title: Immediate Actions
type: numbered-list
template: |
1. Create base theme resource (res://themes/base_theme.tres)
2. Set up UI scene templates with proper anchoring
3. Configure InputMap for UI navigation
4. Write GUT tests for UI components
5. Profile UI scenes to ensure 60+ FPS
6. {{additional_action}}
- id: godot-handoff-checklist
title: Godot UI Handoff Checklist
type: checklist
items:
- "All UI scenes mapped with .tscn files"
- "Control node hierarchies defined"
- "Theme resources prepared"
- "InputMap actions configured"
- "Anchor presets documented"
- "60+ FPS performance validated"
- "GUT test coverage planned"
- "Language strategy decided (GDScript vs C#)"
- "Accessibility features implemented"
- "Touch controls configured"
- id: godot-ui-patterns
title: Godot UI Design Patterns
instruction: Document common Godot UI patterns and best practices used in the game.
sections:
- id: common-patterns
title: Common UI Patterns
template: |
**Dialog System:**
- Use PopupPanel nodes for modal dialogs
- AcceptDialog/ConfirmationDialog for prompts
- Signal pattern: dialog.popup_hide.connect(callback)
**Menu Navigation:**
- TabContainer for multi-page interfaces
- Tree node for hierarchical menus
- Focus management with grab_focus()
**HUD Layout:**
- MarginContainer for screen edges
- Anchor presets for corner elements
- CanvasLayer for overlay UI (stays on top)
**Inventory Grid:**
- GridContainer with fixed columns
- ItemList for scrollable lists
- Drag and drop with Control._gui_input()
**Health/Mana Bars:**
- ProgressBar with custom StyleBox
- TextureProgressBar for themed bars
- Tween for smooth value changes
- id: signal-patterns
title: UI Signal Patterns
template: |
**Button Signals:**
```gdscript
button.pressed.connect(_on_button_pressed)
button.button_down.connect(_on_button_down)
button.toggled.connect(_on_button_toggled)
```
**Input Handling:**
```gdscript
func _gui_input(event: InputEvent) -> void:
if event.is_action_pressed("ui_accept"):
# Handle input with 60+ FPS maintained
```
**Custom Signals:**
```gdscript
signal value_changed(new_value: float)
signal item_selected(item_id: int)
```
- id: checklist-results
title: Checklist Results
instruction: If a Godot UI/UX checklist exists, run it against this document and report results here.

620
expansion-packs/bmad-godot-game-dev/templates/level-design-doc-tmpl.yaml Normal file
View File

@@ -0,0 +1,620 @@
template:
id: godot-level-design-doc-template-v3
name: Godot Level Design Document
version: 3.0
output:
format: markdown
filename: docs/godot-level-design-document.md
title: "{{game_title}} Godot Level Design Document"
workflow:
mode: interactive
sections:
- id: initial-setup
instruction: |
This template creates comprehensive Godot level design documentation focusing on scene structure, TileMap implementation, and performance optimization (60+ FPS). This document provides detail for creating Godot scenes (.tscn), implementing node hierarchies, and optimizing with object pooling.
If available, review: Game Design Document (GDD), Game Architecture Document, Language Strategy (GDScript vs C#). This document must align with 60+ FPS performance requirements and TDD practices (GUT/GoDotTest).
- id: introduction
title: Introduction
instruction: Establish the purpose and scope of level design for this game
content: |
This document defines the Godot level design framework for {{game_title}}, providing guidelines for creating performant, engaging levels using Godot's scene system, TileMap nodes, and Area2D/3D collision systems while maintaining 60+ FPS.
This framework ensures consistency across all level scenes (.tscn) while leveraging Godot's node inheritance, scene instancing, and object pooling for optimal performance.
sections:
- id: change-log
title: Change Log
instruction: Track document versions and changes
type: table
template: |
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
- id: level-design-philosophy
title: Level Design Philosophy
instruction: Establish the overall approach to level design based on the game's core pillars and mechanics. Apply `tasks#advanced-elicitation` after presenting this section.
sections:
- id: design-principles
title: Design Principles
instruction: Define 3-5 core principles that guide all level design decisions
type: numbered-list
template: |
**{{principle_name}}** - {{description}}
- id: player-experience-goals
title: Player Experience Goals
instruction: Define what players should feel and learn in each level category
template: |
**Tutorial Levels:** {{experience_description}}
**Standard Levels:** {{experience_description}}
**Challenge Levels:** {{experience_description}}
**Boss Levels:** {{experience_description}}
- id: level-flow-framework
title: Level Flow Framework
instruction: Define the standard structure for level progression with performance targets
template: |
**Introduction Phase:** {{duration}} - {{purpose}} - Target: 60+ FPS
**Development Phase:** {{duration}} - {{purpose}} - Object pooling active
**Climax Phase:** {{duration}} - {{purpose}} - Peak performance critical
**Resolution Phase:** {{duration}} - {{purpose}} - Scene cleanup required
- id: level-categories
title: Level Categories
instruction: Define different types of levels based on the GDD requirements. Each category should be specific enough for implementation.
repeatable: true
sections:
- id: level-category
title: "{{category_name}} Levels"
template: |
**Purpose:** {{gameplay_purpose}}
**Target Duration:** {{min_time}} - {{max_time}} minutes
**Difficulty Range:** {{difficulty_scale}}
**Key Mechanics Featured:**
- {{mechanic_1}} - {{usage_description}}
- {{mechanic_2}} - {{usage_description}}
**Player Objectives:**
- Primary: {{primary_objective}}
- Secondary: {{secondary_objective}}
- Hidden: {{secret_objective}}
**Success Criteria:**
- {{completion_requirement_1}}
- {{completion_requirement_2}}
**Godot Technical Requirements:**
- Maximum nodes: {{node_limit}} active nodes
- Performance target: 60+ FPS mandatory (frame time <16.67ms)
- Memory budget: {{memory_limit}}MB scene memory
- Draw calls: <{{draw_call_limit}} for level geometry
- Object pools: Required for {{spawned_entities}}
- Language: {{GDScript|C#}} for level logic - {{reason}}
- id: level-progression-system
title: Level Progression System
instruction: Define how players move through levels and how difficulty scales
sections:
- id: world-structure
title: World Structure
instruction: Define the Godot scene organization and resource structure
template: |
**Scene Organization:** {{linear|hub_world|open_world}}
**Total Level Scenes:** {{number}} .tscn files
**World Scene Breakdown:**
- World 1: {{level_count}} scenes - res://levels/world1/ - {{difficulty_range}}
- World 2: {{level_count}} scenes - res://levels/world2/ - {{difficulty_range}}
- World 3: {{level_count}} scenes - res://levels/world3/ - {{difficulty_range}}
**Scene Loading:** < 3 seconds with loading screen if needed
**Scene Instancing:** Use PackedScene for repeated elements
- id: difficulty-progression
title: Difficulty Progression
instruction: Define how challenge increases across the game
sections:
- id: progression-curve
title: Progression Curve
type: code
language: text
template: |
Difficulty
^ ___/```
| /
| / ___/```
| / /
| / /
|/ /
+-----------> Level Number
Tutorial Early Mid Late
- id: scaling-parameters
title: Scaling Parameters
type: bullet-list
template: |
- Enemy count: {{start_count}} → {{end_count}} (pooled)
- Enemy difficulty: {{start_diff}} → {{end_diff}}
- Level complexity: {{start_complex}} → {{end_complex}}
- Time pressure: {{start_time}} → {{end_time}}
- Performance impact: Must maintain 60+ FPS at peak
- id: unlock-requirements
title: Unlock Requirements
instruction: Define how players access new levels
template: |
**Progression Gates:**
- Linear progression: Complete previous level
- Star requirements: {{star_count}} stars to unlock
- Skill gates: Demonstrate {{skill_requirement}}
- Optional content: {{unlock_condition}}
- id: level-design-components
title: Level Design Components
instruction: Define the building blocks used to create levels
sections:
- id: environmental-elements
title: Environmental Elements
instruction: Define Godot nodes and resources for level components
template: |
**TileMap Layers:**
- Background: TileMap node - {{tile_size}}px tiles
- Collision: TileMap with physics layers
- Foreground: TileMap for overlays
**Interactive Nodes:**
- {{node_1}}: Area2D/3D - {{signals_emitted}}
- {{node_2}}: RigidBody2D/3D - {{physics_properties}}
**Hazard Nodes:**
- {{hazard_1}}: Area2D with damage signal
- {{hazard_2}}: AnimationPlayer for moving hazards
**Performance:** All interactive elements use object pooling
- id: collectibles-rewards
title: Collectibles and Rewards
instruction: Define all collectible items and their placement rules
template: |
**Collectible Types:**
- {{collectible_1}}: {{value_and_purpose}}
- {{collectible_2}}: {{value_and_purpose}}
**Placement Guidelines:**
- Mandatory collectibles: {{placement_rules}}
- Optional collectibles: {{placement_rules}}
- Secret collectibles: {{placement_rules}}
**Reward Distribution:**
- Easy to find: {{percentage}}%
- Moderate challenge: {{percentage}}%
- High skill required: {{percentage}}%
- id: enemy-placement-framework
title: Enemy Placement Framework
instruction: Define enemy node placement and pooling strategies
template: |
**Enemy Scene Types:**
- {{enemy_scene_1}}.tscn: {{node_type}} - {{ai_behavior}}
- {{enemy_scene_2}}.tscn: {{node_type}} - {{ai_behavior}}
**Godot Placement Methods:**
- Spawn Points: Position2D/3D markers in scene
- Dynamic Spawning: Object pool with max {{pool_size}}
- Wave System: Timer-based with performance monitoring
**Performance Scaling:**
- Max active enemies: {{max_count}} to maintain 60+ FPS
- LOD system: Disable AI beyond {{distance}} units
- Pooling strategy: Reuse instances, never instantiate in gameplay
- id: level-creation-guidelines
title: Level Creation Guidelines
instruction: Provide specific guidelines for creating individual levels
sections:
- id: level-layout-principles
title: Godot Level Layout Principles
template: |
**TileMap Design:**
- Tile size: {{tile_size}}x{{tile_size}} pixels
- Grid dimensions: {{grid_width}}x{{grid_height}} tiles
- Collision layers: {{collision_layer_count}}
- Autotiling: {{autotile_enabled}} for efficiency
**Node-Based Navigation:**
- Navigation2D/3D setup: {{nav_mesh_config}}
- Path2D for guided movement
- Area2D triggers for zone transitions
- Position2D markers for spawn points
**Performance Layout:**
- Chunk size for streaming: {{chunk_size}}
- Occlusion culling setup: {{occlusion_config}}
- Draw call optimization: Batch similar tiles
- id: pacing-and-flow
title: Pacing and Flow
instruction: Define how to control the rhythm and pace of gameplay within levels
template: |
**Action Sequences:**
- High intensity duration: {{max_duration}}
- Rest period requirement: {{min_rest_time}}
- Intensity variation: {{pacing_pattern}}
**Learning Sequences:**
- New mechanic introduction: {{teaching_method}}
- Practice opportunity: {{practice_duration}}
- Skill application: {{application_context}}
- id: challenge-design
title: Challenge Design
instruction: Define how to create appropriate challenges for each level type
template: |
**Challenge Types:**
- Execution challenges: {{skill_requirements}}
- Puzzle challenges: {{complexity_guidelines}}
- Time challenges: {{time_pressure_rules}}
- Resource challenges: {{resource_management}}
**Difficulty Calibration:**
- Skill check frequency: {{frequency_guidelines}}
- Failure recovery: {{retry_mechanics}}
- Hint system integration: {{help_system}}
- id: technical-implementation
title: Godot Technical Implementation
instruction: Define Godot-specific technical requirements for level scenes
sections:
- id: level-scene-structure
title: Level Scene Structure
instruction: Define Godot scene hierarchy and resource organization
template: |
**Scene File Format:**
- File type: .tscn (Godot scene)
- Naming: `level_{{world}}_{{number}}.tscn`
- Location: res://levels/{{world}}/
- Resource format: .tres for level data
**Scene Hierarchy:**
```
Level (Node2D/Spatial)
├── TileMap (background)
├── TileMap (collision)
├── TileMap (foreground)
├── Entities (Node2D)
│ ├── Enemies (pooled)
│ └── Pickups (pooled)
├── Triggers (Node2D)
└── LevelLogic (Node with script)
```
sections:
- id: level-resource-data
title: Level Resource Data (.tres)
type: code
language: gdscript
template: |
# LevelData.gd - extends Resource
class_name LevelData
extends Resource
@export var level_id: String = "{{unique_identifier}}"
@export var world_id: String = "{{world_identifier}}"
@export var difficulty: float = {{difficulty_value}}
@export var target_time: float = {{completion_time_seconds}}
@export var target_fps: int = 60 # Mandatory
@export var objectives: Dictionary = {
"primary": "{{primary_objective}}",
"secondary": ["{{secondary_objectives}}"],
"hidden": ["{{secret_objectives}}"]
}
@export var performance_limits: Dictionary = {
"max_enemies": {{enemy_pool_size}},
"max_particles": {{particle_limit}},
"max_draw_calls": {{draw_call_limit}}
}
# Entity spawn data
@export var spawn_points: Array[Vector2] = []
@export var enemy_waves: Array[Resource] = []
- id: godot-asset-integration
title: Godot Asset Integration
instruction: Define how Godot resources and assets are organized
template: |
**TileSet Resource:**
- Resource path: res://tilesets/{{tileset_name}}.tres
- Tile size: {{tile_dimensions}}x{{tile_dimensions}}px
- Physics layers: {{collision_layers}}
- Autotile setup: {{autotile_config}}
- Custom data layers: {{custom_properties}}
**Audio Integration:**
- AudioStreamPlayer2D for positional audio
- Audio bus: "Level" for volume control
- Stream format: .ogg for music, .wav for SFX
- Preload critical sounds to avoid frame drops
**Texture Import Settings:**
- Filter: Nearest (for pixel art) or Linear
- Mipmaps: Disabled for 2D, Enabled for 3D
- Compression: Lossless for important visuals
- id: godot-performance-optimization
title: Godot Performance Optimization
instruction: Define Godot-specific optimization for 60+ FPS
template: |
**Node Limits (for 60+ FPS):**
- Maximum active nodes: {{node_limit}}
- Maximum physics bodies: {{physics_limit}}
- Maximum particles: {{particle_limit}} (use GPUParticles2D/3D)
- Maximum lights: {{light_limit}}
**Memory Management:**
- Scene memory budget: {{scene_memory}}MB
- Texture memory: {{texture_memory}}MB
- Object pooling: Mandatory for all spawned entities
- Scene loading: <3 seconds (show loading screen if longer)
**Godot Optimization Techniques:**
- VisibilityEnabler2D/3D for automatic culling
- LOD using visibility ranges
- Static body optimization for non-moving collision
- YSort for efficient 2D depth sorting
- Multimesh for repeated elements
**Language Strategy:**
- Level logic: GDScript with static typing
- Performance-critical systems: C# (no LINQ)
- id: godot-level-patterns
title: Godot Level Design Patterns
instruction: Document common Godot patterns for level implementation
sections:
- id: scene-inheritance
title: Scene Inheritance Pattern
template: |
**Base Level Scene:**
- res://levels/base_level.tscn
- Contains common nodes (UI, pause, music)
- Child scenes inherit and override
**Inherited Scenes:**
- Each level extends base_level.tscn
- Override specific properties
- Maintain 60+ FPS through shared resources
- id: tilemap-patterns
title: TileMap Best Practices
template: |
**Layer Organization:**
- Background: Decorative, no collision
- Collision: Physics bodies, one-way platforms
- Foreground: Overlay effects
**Autotiling Setup:**
- 3x3 minimal or 16-tile for complex terrain
- Custom data for gameplay properties
- Collision shapes optimized per tile
- id: spawning-patterns
title: Entity Spawning Patterns
template: |
**Object Pooling (Mandatory):**
```gdscript
# Enemy pool manager
var enemy_pool: Array = []
var max_enemies: int = {{max_count}}
func _ready() -> void:
# Pre-instantiate enemies
for i in max_enemies:
var enemy = enemy_scene.instantiate()
enemy.set_process(false)
enemy_pool.append(enemy)
```
**Spawn Points:**
- Use Position2D/3D markers
- Group spawn points for wave management
- Signal when spawn completes
- id: performance-patterns
title: Performance Optimization Patterns
template: |
**Visibility Management:**
- VisibilityEnabler2D for off-screen culling
- LOD groups for distance-based quality
- Disable process for inactive entities
**Memory Management:**
- Preload frequently used resources
- Queue_free() with object pool return
- Signal cleanup in _exit_tree()
**Draw Call Batching:**
- Use same material/shader where possible
- Batch static geometry
- Minimize transparent overdraw
- id: level-testing-framework
title: Level Testing Framework
instruction: Define how levels should be tested and validated
sections:
- id: automated-testing
title: Automated Testing
template: |
**Performance Testing (GUT/GoDotTest):**
- Frame rate validation: Must maintain 60+ FPS
- Frame time monitoring: <16.67ms average
- Memory leak detection: Check signal cleanup
- Object pool verification: Ensure recycling works
- Loading time: <3 seconds per scene
**Gameplay Testing (TDD Approach):**
- Write GUT tests for level completion paths
- Test all Area2D triggers fire correctly
- Verify collectible spawn points accessible
- Test enemy AI with performance monitoring
- Validate all signals connect/disconnect properly
- id: manual-testing-protocol
title: Manual Testing Protocol
sections:
- id: playtesting-checklist
title: Godot Playtesting Checklist
type: checklist
items:
- Level maintains 60+ FPS throughout gameplay
- TileMap collision works correctly
- All Area2D triggers activate properly
- Object pooling functions without hiccups
- Scene transitions take <3 seconds
- Input responsiveness <50ms (3 frames)
- No memory leaks from signals
- Navigation mesh pathfinding works
- id: player-experience-testing
title: Player Experience Testing
type: checklist
items:
- Tutorial levels teach effectively
- Challenge feels fair and rewarding
- Flow and pacing maintain engagement
- Audio and visual feedback support gameplay
- id: balance-validation
title: Balance Validation
template: |
**Godot Metrics Collection:**
- FPS consistency: >95% of time at 60+ FPS
- Completion rate: Target {{completion_percentage}}%
- Average completion time: {{target_time}} ± {{variance}}
- Object pool efficiency: >90% reuse rate
- Draw calls per level: <{{draw_call_target}}
**Performance-Based Iteration:**
- If FPS drops: Reduce active enemies/particles
- If loading slow: Optimize texture imports
- If memory high: Check for signal leaks
- Testing with Godot profiler mandatory
- id: content-creation-pipeline
title: Godot Level Creation Pipeline
instruction: Define the workflow for creating new Godot level scenes
sections:
- id: design-phase
title: Design Phase
template: |
**Concept Development:**
1. Define level goals and performance targets (60+ FPS)
2. Sketch TileMap layout and node placement
3. Plan object pooling for spawned entities
4. Choose language (GDScript vs C#) for level logic
5. Estimate memory and draw call budget
**Godot Documentation Requirements:**
- Level scene hierarchy diagram
- TileSet resource requirements
- Signal flow documentation
- Performance budget allocation
- TDD test plan (GUT/GoDotTest)
- id: implementation-phase
title: Godot Implementation Phase
template: |
**Scene Creation (TDD Approach):**
1. Write GUT tests for level mechanics (RED phase)
2. Create level scene (.tscn) structure
3. Build TileMap layers (collision, visual, background)
4. Implement object pools for enemies/pickups
5. Add Area2D triggers and signals (GREEN phase)
6. Configure Navigation2D mesh
7. Optimize with static typing (REFACTOR phase)
**Godot Quality Assurance:**
1. Run GUT/GoDotTest suites
2. Profile with Godot debugger (60+ FPS check)
3. Verify object pooling efficiency
4. Check memory usage and draw calls
5. Test on minimum spec hardware
- id: integration-phase
title: Godot Integration Phase
template: |
**Scene Integration:**
1. Add to level scene autoload manager
2. Connect to game state signals
3. Integrate with save system (user:// path)
4. Link achievements via signal system
5. Set up scene transitions (<3 seconds)
**Final Godot Validation:**
1. Test scene in full game context
2. Verify 60+ FPS with all systems active
3. Export template testing (all platforms)
4. Check InputMap works for all devices
5. Validate object pools don't leak memory
- id: success-metrics
title: Godot Level Success Metrics
instruction: Define metrics for level design success with performance focus
sections:
- id: player-engagement
title: Player Engagement
type: bullet-list
template: |
- Level completion rate: {{target_rate}}%
- Replay rate: {{replay_target}}%
- Time spent per level: {{engagement_time}}
- Player satisfaction: {{satisfaction_target}}/10
- Input responsiveness: <50ms feedback
- id: godot-performance
title: Godot Technical Performance
type: bullet-list
template: |
- Frame rate: 60+ FPS maintained {{fps_consistency}}%
- Frame time: <16.67ms average
- Scene loading: <3 seconds {{load_compliance}}%
- Memory efficiency: {{memory_efficiency}}%
- Object pool reuse: >90% efficiency
- Draw calls: Within budget {{draw_compliance}}%
- Signal leaks: 0 tolerance
- Crash rate: <{{crash_threshold}}%
- id: design-quality
title: Design Quality
type: bullet-list
template: |
- Difficulty curve adherence: {{curve_accuracy}}
- Node architecture efficiency: {{node_score}}
- TileMap optimization: {{tilemap_score}}
- Signal flow clarity: {{signal_score}}
- TDD coverage: >80% (GUT/GoDotTest)
- Language strategy appropriateness: {{language_score}}
- Content accessibility: {{accessibility_rate}}%

418
expansion-packs/bmad-godot-game-dev/templates/market-research-tmpl.yaml Normal file
View File

@@ -0,0 +1,418 @@
template:
id: game-market-research-template-v3
name: Game Market Research Report
version: 3.0
output:
format: markdown
filename: docs/game-market-research.md
title: "Game Market Research Report: {{game_title}}"
workflow:
mode: interactive
elicitation: advanced-elicitation
custom_elicitation:
title: "Game Market Research Elicitation Actions"
options:
- "Expand platform market analysis (PC, Console, Mobile)"
- "Deep dive into a specific player demographic"
- "Analyze genre trends and player preferences"
- "Compare to successful games in similar genre"
- "Analyze monetization models (F2P, Premium, Hybrid)"
- "Explore cross-platform opportunities"
- "Evaluate streaming and content creator potential"
- "Assess esports and competitive gaming potential"
- "Analyze seasonal and regional market variations"
- "Proceed to next section"
sections:
- id: executive-summary
title: Executive Summary
instruction: Provide a high-level overview of key findings, target platforms, player demographics, monetization opportunities, and launch strategy recommendations. Write this section LAST after completing all other sections.
- id: research-objectives
title: Research Objectives & Methodology
instruction: This template guides the creation of a comprehensive game market research report. Begin by understanding target platforms, player demographics, genre positioning, and monetization strategies. Consider both direct competitors and substitute entertainment options.
sections:
- id: objectives
title: Research Objectives
instruction: |
List the primary objectives of this game market research:
- Target platform selection (PC/Console/Mobile/Cross-platform)
- Genre positioning and differentiation
- Player demographic identification
- Monetization model selection
- Launch timing and strategy
- Marketing channel prioritization
- id: methodology
title: Research Methodology
instruction: |
Describe the research approach:
- Data sources used (primary/secondary)
- Analysis frameworks applied
- Data collection timeframe
- Limitations and assumptions
- id: market-overview
title: Market Overview
sections:
- id: market-definition
title: Game Market Definition
instruction: |
Define the game market being analyzed:
- Genre and sub-genre classification
- Platform scope (PC/Steam, Console/PS5/Xbox, Mobile/iOS/Android)
- Geographic regions (NA, EU, Asia, Global)
- Player segments (Casual, Core, Hardcore)
- Age ratings and content restrictions
- id: market-size-growth
title: Game Market Size & Growth
instruction: |
Calculate market opportunity for the game. Consider:
- Global games market size by platform
- Genre-specific market share
- Regional market variations
- Seasonal trends (launch windows)
- Digital vs physical distribution
sections:
- id: tam
title: Total Addressable Market (TAM)
instruction: |
Calculate total game market opportunity:
- Platform market size (PC: $X, Console: $Y, Mobile: $Z)
- Genre market share (e.g., RPG: 15% of total)
- Geographic reach potential
- id: sam
title: Serviceable Addressable Market (SAM)
instruction: |
Define reachable market based on:
- Target platforms and distribution channels
- Language localization plans
- Age rating restrictions
- Technical requirements (minimum specs)
- id: som
title: Serviceable Obtainable Market (SOM)
instruction: |
Realistic capture estimates:
- Launch year projections
- Marketing budget constraints
- Competition intensity in genre
- Platform holder relationships
- id: market-trends
title: Gaming Industry Trends & Drivers
instruction: Analyze key trends shaping the gaming market including technology, player behavior, and business models
sections:
- id: key-trends
title: Key Gaming Trends
instruction: |
Identify 5-7 major gaming trends:
- Platform shifts (PC gaming growth, mobile dominance)
- Genre popularity cycles (Battle Royale, Roguelike, etc.)
- Monetization evolution (Battle Pass, NFTs, Subscriptions)
- Social/Streaming integration (Twitch, YouTube Gaming)
- Cross-platform play adoption
- Cloud gaming emergence
- VR/AR market development
- id: growth-drivers
title: Growth Drivers
instruction: |
Gaming market growth factors:
- Expanding player demographics
- Improved internet infrastructure
- Mobile device penetration
- Esports and streaming culture
- Social gaming trends
- Pandemic-driven adoption
- id: market-inhibitors
title: Market Inhibitors
instruction: |
Factors constraining growth:
- Market saturation in genres
- Rising development costs
- Platform holder fees (30% cut)
- Regulatory challenges (loot boxes, age ratings)
- Discovery challenges (Steam has 50k+ games)
- Player time constraints
- id: player-analysis
title: Player Analysis
sections:
- id: player-segments
title: Target Player Segments
instruction: For each player segment, create detailed profiles including demographics, play patterns, platform preferences, and spending behavior
repeatable: true
sections:
- id: segment
title: "Player Segment {{segment_number}}: {{segment_name}}"
template: |
- **Description:** {{player_type_overview}}
- **Size:** {{number_of_players_market_value}}
- **Demographics:** {{age_gender_location}}
- **Play Patterns:** {{hours_per_week_session_length}}
- **Platform Preference:** {{PC_console_mobile}}
- **Genre Preferences:** {{favorite_genres}}
- **Spending Behavior:** {{F2P_premium_whale_status}}
- **Social Behavior:** {{solo_coop_competitive}}
- id: player-motivations
title: Player Motivation Analysis
instruction: Understand why players engage with games using Bartle's taxonomy and SDT
sections:
- id: achievement-motivated
title: Achievers
instruction: Players who seek mastery, completion, high scores
- id: social-motivated
title: Socializers
instruction: Players who value interaction, community, cooperation
- id: exploration-motivated
title: Explorers
instruction: Players who enjoy discovery, lore, secrets
- id: competition-motivated
title: Killers/Competitors
instruction: Players who seek dominance, PvP, rankings
- id: player-journey
title: Player Journey Mapping
instruction: Map the player lifecycle from discovery to advocacy
template: |
For primary player segment:
1. **Discovery:** {{streamers_ads_friends_app_stores}}
2. **Evaluation:** {{reviews_gameplay_videos_demos}}
3. **Acquisition:** {{purchase_download_game_pass}}
4. **Onboarding:** {{tutorial_difficulty_curve}}
5. **Engagement:** {{core_loop_progression_social}}
6. **Retention:** {{updates_seasons_events}}
7. **Monetization:** {{DLC_MTX_battle_pass}}
8. **Advocacy:** {{streaming_reviews_word_of_mouth}}
- id: competitive-landscape
title: Game Competitive Landscape
sections:
- id: genre-competition
title: Genre Competition Analysis
instruction: |
Analyze the competitive environment:
- Direct genre competitors
- Substitute entertainment (other genres, media)
- Platform exclusives impact
- Indie vs AAA dynamics
- Release window competition
- id: competitor-analysis
title: Direct Competitor Analysis
instruction: |
For top 5-10 competing games:
- Game title and developer/publisher
- Platform availability
- Launch date and lifecycle stage
- Player count/sales estimates
- Metacritic/Steam reviews
- Monetization model
- Content update cadence
- Community size and engagement
- id: competitive-positioning
title: Competitive Positioning
instruction: |
Analyze positioning strategies:
- Unique gameplay mechanics
- Art style differentiation
- Narrative/IP strength
- Technical innovation (graphics, physics)
- Community features
- Monetization fairness
- Platform optimization
- id: gaming-industry-analysis
title: Gaming Industry Analysis
sections:
- id: gaming-five-forces
title: Gaming Industry Five Forces
instruction: Analyze forces specific to game development
sections:
- id: platform-power
title: "Platform Holder Power: {{power_level}}"
template: |
- Steam/Epic/Console manufacturers control
- 30% revenue share standard
- Certification requirements
- Featured placement influence
- id: player-power
title: "Player Power: {{power_level}}"
template: |
- Abundant game choices
- Review bombing capability
- Refund policies
- Community influence
- id: genre-rivalry
title: "Genre Competition: {{intensity_level}}"
template: |
- Number of similar games
- Release timing conflicts
- Marketing spend requirements
- Talent competition
- id: entry-barriers
title: "Barriers to Entry: {{barrier_level}}"
template: |
- Development costs
- Technical expertise requirements
- Marketing/visibility challenges
- Platform relationships
- id: entertainment-substitutes
title: "Entertainment Alternatives: {{threat_level}}"
template: |
- Other game genres
- Streaming services
- Social media
- Traditional entertainment
- id: genre-lifecycle
title: Genre Lifecycle Stage
instruction: |
Identify where your game genre is in its lifecycle:
- Emerging (new mechanics, small audience)
- Growth (expanding player base, innovation)
- Mature (established conventions, large market)
- Decline (decreasing interest, oversaturation)
- Revival potential (nostalgia, modernization)
- id: opportunity-assessment
title: Game Market Opportunity Assessment
sections:
- id: market-opportunities
title: Game Market Opportunities
instruction: Identify specific opportunities in the gaming market
repeatable: true
sections:
- id: opportunity
title: "Opportunity {{opportunity_number}}: {{name}}"
template: |
- **Description:** {{opportunity_description}}
- **Market Size:** {{player_base_revenue_potential}}
- **Platform Focus:** {{PC_console_mobile}}
- **Development Requirements:** {{time_budget_team}}
- **Technical Requirements:** {{engine_tools_infrastructure}}
- **Marketing Requirements:** {{budget_channels_influencers}}
- **Risks:** {{competition_timing_execution}}
- id: strategic-recommendations
title: Game Launch Strategic Recommendations
sections:
- id: go-to-market
title: Game Go-to-Market Strategy
instruction: |
Recommend game launch approach:
- Platform launch sequence (PC first, console later, etc.)
- Early Access vs Full Release
- Geographic rollout (soft launch regions)
- Marketing campaign timing
- Influencer/streamer strategy
- Community building approach
- Steam wishlist campaign
- id: monetization-strategy
title: Monetization Strategy
instruction: |
Based on player analysis and genre standards:
- Business model (Premium, F2P, Freemium, Subscription)
- Price points ($19.99, $39.99, $59.99)
- DLC/Season Pass strategy
- Microtransaction approach (cosmetic only, P2W, etc.)
- Battle Pass potential
- Platform fees consideration (30% cut)
- id: risk-mitigation
title: Game Development Risk Mitigation
instruction: |
Key game industry risks and mitigation:
- Launch window competition (AAA releases)
- Platform certification delays
- Streamer/influencer reception
- Review bombing potential
- Server/online infrastructure
- Post-launch content pipeline
- Community management needs
- Regulatory (ESRB, PEGI, loot boxes)
- id: platform-analysis
title: Platform-Specific Analysis
sections:
- id: platform-comparison
title: Platform Comparison
template: |
| Platform | Market Size | Competition | Dev Cost | Revenue Share |
|----------|------------|-------------|----------|---------------|
| Steam/PC | {{size}} | {{competition}} | {{cost}} | 30% |
| PlayStation | {{size}} | {{competition}} | {{cost}} | 30% |
| Xbox | {{size}} | {{competition}} | {{cost}} | 30% |
| Nintendo | {{size}} | {{competition}} | {{cost}} | 30% |
| iOS | {{size}} | {{competition}} | {{cost}} | 30% |
| Android | {{size}} | {{competition}} | {{cost}} | 30% |
- id: distribution-channels
title: Distribution Channel Analysis
template: |
**Digital Storefronts:**
- Steam: {{pros_cons_requirements}}
- Epic Games Store: {{12_percent_exclusivity}}
- GOG: {{DRM_free_considerations}}
- Itch.io: {{indie_friendly_revenue_share}}
- Platform stores: {{certification_requirements}}
**Subscription Services:**
- Game Pass: {{opportunity_requirements}}
- PlayStation Plus: {{tier_considerations}}
- Apple Arcade: {{exclusive_requirements}}
- id: marketing-channels
title: Game Marketing Channel Analysis
sections:
- id: channel-effectiveness
title: Marketing Channel Effectiveness
template: |
**Organic Channels:**
- Steam Discovery: {{algorithm_factors}}
- Platform Features: {{visibility_opportunities}}
- Word of Mouth: {{virality_potential}}
**Paid Channels:**
- Digital Ads: {{ROI_targeting_options}}
- Influencer Partnerships: {{cost_reach_engagement}}
- Gaming Media: {{PR_review_coverage}}
**Community Channels:**
- Discord: {{community_building}}
- Reddit: {{subreddit_engagement}}
- Social Media: {{platform_specific_strategies}}
- id: content-creator-strategy
title: Content Creator & Streaming Strategy
template: |
**Streaming Platforms:**
- Twitch: {{viewer_demographics_peak_times}}
- YouTube Gaming: {{long_form_content}}
- TikTok: {{viral_clips_potential}}
**Creator Engagement:**
- Early access keys: {{timing_selection}}
- Creator programs: {{incentives_support}}
- Stream-friendly features: {{built_in_tools}}
- id: appendices
title: Appendices
sections:
- id: data-sources
title: A. Data Sources
instruction: |
Game industry sources:
- Newzoo reports
- SteamSpy/SteamDB data
- App Annie/Sensor Tower mobile data
- NPD/GfK/GSD sales data
- Platform holder reports
- id: genre-benchmarks
title: B. Genre Success Benchmarks
instruction: |
Success metrics by genre:
- Sales thresholds
- Player retention rates
- Monetization benchmarks
- Review score correlations
- id: seasonal-analysis
title: C. Seasonal & Event Analysis
instruction: |
Release timing considerations:
- Holiday seasons
- Steam sales events
- Competition calendar
- Platform holder promotions