bmad-method 4.43.0 → 4.44.0

package/expansion-packs/bmad-godot-game-dev/checklists/game-change-checklist.md

@@ -0,0 +1,250 @@
+# Game Development Change Navigation Checklist (Godot)
+
+**Purpose:** To systematically guide the Game SM agent and user through analysis and planning when a significant change (performance issue, platform constraint, technical blocker, gameplay feedback) is identified during Godot game development.
+
+**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - GAME CHANGE NAVIGATION
+
+Changes during game development are common - performance issues, platform constraints, gameplay feedback, and technical limitations are part of the process.
+
+Before proceeding, understand:
+
+1. This checklist is for SIGNIFICANT changes affecting game architecture or features
+2. Minor tweaks (shader adjustments, UI positioning) don't require this process
+3. The goal is to maintain playability while adapting to technical realities
+4. Performance (60+ FPS) and player experience are paramount
+5. Consider both GDScript and C# implementation options
+
+Required context:
+
+- The triggering issue (performance metrics, crash logs, feedback)
+- Current development state (implemented features, current sprint)
+- Access to GDD, technical specs, and performance budgets
+- Understanding of remaining features and milestones
+- Current language usage (GDScript vs C#) per system
+
+APPROACH:
+This is an interactive process. Discuss performance implications, platform constraints, and player impact. The user makes final decisions, but provide expert Godot/game dev guidance.
+
+REMEMBER: Game development is iterative. Changes often lead to better gameplay and performance.]]
+
+---
+
+## 1. Understand the Trigger & Context
+
+[[LLM: Start by understanding the game-specific issue. Ask technical questions:
+
+- What performance metrics triggered this? (FPS, frame time, memory)
+- Is this platform-specific or universal?
+- Can we reproduce it consistently?
+- What Godot profiler data do we have?
+- Is this a GDScript performance issue that C# could solve?
+- Are we hitting Godot engine limits?
+
+Focus on measurable impacts and technical specifics.]]
+
+- [ ] **Identify Triggering Element:** Clearly identify the game feature/system revealing the issue.
+- [ ] **Define the Issue:** Articulate the core problem precisely.
+  - [ ] Performance bottleneck (CPU/GPU/Memory)?
+  - [ ] Draw call or batching issue?
+  - [ ] Platform-specific limitation?
+  - [ ] Godot engine constraint?
+  - [ ] GDScript vs C# performance difference?
+  - [ ] Node tree complexity issue?
+  - [ ] Signal overhead problem?
+  - [ ] Physics engine bottleneck?
+  - [ ] Gameplay/balance issue from playtesting?
+  - [ ] Asset import or resource loading problem?
+  - [ ] Export template or platform issue?
+- [ ] **Assess Performance Impact:** Document specific metrics (current FPS, target 60+ FPS, frame time ms, draw calls, memory usage).
+- [ ] **Gather Technical Evidence:** Note Godot profiler data, performance monitor stats, platform test results, player feedback.
+
+## 2. Game Feature Impact Assessment
+
+[[LLM: Game features are interconnected in Godot's node system. Evaluate systematically:
+
+1. Can we optimize the current feature without changing gameplay?
+2. Should this system move from GDScript to C#?
+3. Do dependent scenes/nodes need adjustment?
+4. Are there Godot-specific optimizations available?
+5. Does this affect our performance budget allocation?
+
+Consider both technical and gameplay impacts.]]
+
+- [ ] **Analyze Current Sprint Features:**
+  - [ ] Can the current feature be optimized?
+    - [ ] Object pooling for frequently instantiated nodes?
+    - [ ] LOD system implementation?
+    - [ ] Draw call batching improvements?
+    - [ ] Move hot code from GDScript to C#?
+    - [ ] Static typing in GDScript for performance?
+  - [ ] Does it need gameplay simplification?
+  - [ ] Should it be platform-specific (high-end only)?
+- [ ] **Analyze Dependent Systems:**
+  - [ ] Review all scenes and nodes interacting with the affected feature.
+  - [ ] Do physics bodies need optimization?
+  - [ ] Are Control nodes/UI systems impacted?
+  - [ ] Do Resource save/load systems require changes?
+  - [ ] Are multiplayer RPCs affected?
+  - [ ] Do signal connections need optimization?
+- [ ] **Language Migration Assessment:**
+  - [ ] Would moving this system to C# improve performance?
+  - [ ] What's the interop overhead if we split languages?
+  - [ ] Can we maintain rapid iteration with C#?
+- [ ] **Summarize Feature Impact:** Document effects on node hierarchy, scene structure, and technical architecture.
+
+## 3. Game Artifact Conflict & Impact Analysis
+
+[[LLM: Game documentation drives development. Check each artifact:
+
+1. Does this invalidate GDD mechanics?
+2. Are technical architecture assumptions still valid?
+3. Do performance budgets need reallocation?
+4. Are platform requirements still achievable?
+5. Does our language strategy (GDScript/C#) need revision?
+
+Missing conflicts cause performance issues later.]]
+
+- [ ] **Review GDD:**
+  - [ ] Does the issue conflict with core gameplay mechanics?
+  - [ ] Do game features need scaling for performance?
+  - [ ] Are progression systems affected?
+  - [ ] Do balance parameters need adjustment?
+- [ ] **Review Technical Architecture:**
+  - [ ] Does the issue conflict with Godot architecture (scene structure, node hierarchy)?
+  - [ ] Are autoload/singleton systems impacted?
+  - [ ] Do shader/rendering approaches need revision?
+  - [ ] Are Resource structures optimal for the scale?
+  - [ ] Is the GDScript/C# split still appropriate?
+- [ ] **Review Performance Specifications:**
+  - [ ] Are target framerates (60+ FPS) still achievable?
+  - [ ] Do memory budgets need reallocation?
+  - [ ] Are load time targets realistic?
+  - [ ] Do we need platform-specific targets?
+  - [ ] Are draw call budgets exceeded?
+- [ ] **Review Asset Specifications:**
+  - [ ] Do texture import settings need adjustment?
+  - [ ] Are mesh instance counts appropriate?
+  - [ ] Do audio bus configurations need changes?
+  - [ ] Is the animation tree complexity sustainable?
+  - [ ] Are particle system limits appropriate?
+- [ ] **Summarize Artifact Impact:** List all game documents requiring updates.
+
+## 4. Path Forward Evaluation
+
+[[LLM: Present Godot-specific solutions with technical trade-offs:
+
+1. What's the performance gain (FPS improvement)?
+2. How much rework is required?
+3. What's the player experience impact?
+4. Are there platform-specific solutions?
+5. Should we migrate systems from GDScript to C#?
+6. Can we leverage Godot 4.x features if on 3.x?
+
+Be specific about Godot implementation details.]]
+
+- [ ] **Option 1: Optimization Within Current Design:**
+  - [ ] Can performance be improved through Godot optimizations?
+    - [ ] Object pooling with node reuse?
+    - [ ] MultiMesh for instancing?
+    - [ ] Viewport optimization?
+    - [ ] Occlusion culling setup?
+    - [ ] Static typing in GDScript?
+    - [ ] Batch draw calls with CanvasItem?
+    - [ ] Optimize signal connections?
+    - [ ] Reduce node tree depth?
+  - [ ] Define specific optimization techniques.
+  - [ ] Estimate performance improvement potential.
+- [ ] **Option 2: Language Migration:**
+  - [ ] Would moving to C# provide needed performance?
+  - [ ] Identify hot paths for C# conversion.
+  - [ ] Define interop boundaries.
+  - [ ] Assess development velocity impact.
+- [ ] **Option 3: Feature Scaling/Simplification:**
+  - [ ] Can the feature be simplified while maintaining fun?
+  - [ ] Identify specific elements to scale down.
+  - [ ] Define platform-specific variations.
+  - [ ] Assess player experience impact.
+- [ ] **Option 4: Architecture Refactor:**
+  - [ ] Would restructuring improve performance significantly?
+  - [ ] Identify Godot-specific refactoring needs:
+    - [ ] Scene composition changes?
+    - [ ] Node hierarchy optimization?
+    - [ ] Signal system redesign?
+    - [ ] Autoload restructuring?
+    - [ ] Resource management improvements?
+  - [ ] Estimate development effort.
+- [ ] **Option 5: Scope Adjustment:**
+  - [ ] Can we defer features to post-launch?
+  - [ ] Should certain features be platform-exclusive?
+  - [ ] Do we need to adjust milestone deliverables?
+- [ ] **Select Recommended Path:** Choose based on performance gain vs. effort.
+
+## 5. Game Development Change Proposal Components
+
+[[LLM: The proposal must include technical specifics:
+
+1. Performance metrics (before/after projections with FPS targets)
+2. Godot implementation details (nodes, scenes, scripts)
+3. Language strategy (GDScript vs C# per system)
+4. Platform-specific considerations
+5. Testing requirements (GUT for GDScript, GoDotTest for C#)
+6. Risk mitigation strategies
+
+Make it actionable for game developers.]]
+
+(Ensure all points from previous sections are captured)
+
+- [ ] **Technical Issue Summary:** Performance/technical problem with metrics.
+- [ ] **Feature Impact Summary:** Affected nodes, scenes, and systems.
+- [ ] **Performance Projections:** Expected improvements from chosen solution (target 60+ FPS).
+- [ ] **Implementation Plan:** Godot-specific technical approach.
+  - [ ] Node hierarchy changes
+  - [ ] Scene restructuring needs
+  - [ ] Script migration (GDScript to C#)
+  - [ ] Resource optimization
+  - [ ] Signal flow improvements
+- [ ] **Platform Considerations:** Any platform-specific implementations.
+- [ ] **Testing Strategy:**
+  - [ ] GUT tests for GDScript changes
+  - [ ] GoDotTest for C# changes
+  - [ ] Performance benchmarks
+  - [ ] Platform validation approach
+- [ ] **Risk Assessment:** Technical risks and mitigation plans.
+- [ ] **Updated Game Stories:** Revised stories with technical constraints.
+
+## 6. Final Review & Handoff
+
+[[LLM: Game changes require technical validation. Before concluding:
+
+1. Are performance targets (60+ FPS) clearly defined?
+2. Is the Godot implementation approach clear?
+3. Is the language strategy (GDScript/C#) documented?
+4. Do we have rollback strategies?
+5. Are test scenarios defined for both languages?
+6. Is platform testing covered?
+
+Get explicit approval on technical approach.
+
+FINAL REPORT:
+Provide a technical summary:
+
+- Performance issue and root cause
+- Chosen solution with expected FPS gains
+- Implementation approach in Godot (nodes, scenes, languages)
+- GDScript vs C# decisions and rationale
+- Testing and validation plan (GUT/GoDotTest)
+- Timeline and milestone impacts
+
+Keep it technically precise and actionable.]]
+
+- [ ] **Review Checklist:** Confirm all technical aspects discussed.
+- [ ] **Review Change Proposal:** Ensure Godot implementation details are clear.
+- [ ] **Language Strategy:** Confirm GDScript vs C# decisions documented.
+- [ ] **Performance Validation:** Define how we'll measure success (profiler metrics).
+- [ ] **Test Coverage:** Ensure both GUT and GoDotTest coverage planned.
+- [ ] **User Approval:** Obtain approval for technical approach.
+- [ ] **Developer Handoff:** Ensure game-dev agent has all technical details needed.
+
+---

package/expansion-packs/bmad-godot-game-dev/checklists/game-design-checklist.md

@@ -0,0 +1,225 @@
+# Game Design Document Quality Checklist (Godot)
+
+## Document Completeness
+
+### Executive Summary
+
+- [ ] **Core Concept** - Game concept is clearly explained in 2-3 sentences
+- [ ] **Target Audience** - Primary and secondary audiences defined with demographics
+- [ ] **Platform Requirements** - Godot export targets and requirements specified
+- [ ] **Unique Selling Points** - 3-5 key differentiators from competitors identified
+- [ ] **Technical Foundation** - Godot version (4.x/3.x) and language strategy (GDScript/C#) confirmed
+
+### Game Design Foundation
+
+- [ ] **Game Pillars** - 3-5 core design pillars defined and actionable
+- [ ] **Core Gameplay Loop** - 30-60 second loop documented with specific timings
+- [ ] **Win/Loss Conditions** - Clear victory and failure states defined
+- [ ] **Player Motivation** - Clear understanding of why players will engage
+- [ ] **Scope Realism** - Game scope achievable with Godot's capabilities and resources
+
+## Gameplay Mechanics
+
+### Core Mechanics Documentation
+
+- [ ] **Primary Mechanics** - 3-5 core mechanics detailed with Godot implementation notes
+- [ ] **Node Architecture** - How mechanics map to Godot's node system
+- [ ] **Player Input** - InputMap configuration for each platform specified
+- [ ] **Signal Flow** - Game responses using Godot's signal system documented
+- [ ] **Performance Impact** - Frame time budget for each mechanic (target 60+ FPS)
+
+### Controls and Interaction
+
+- [ ] **Multi-Platform Controls** - Desktop, mobile, and gamepad InputMap defined
+- [ ] **Input Responsiveness** - Requirements for game feel using \_process vs \_physics_process
+- [ ] **Accessibility Options** - Control remapping and accessibility in Project Settings
+- [ ] **Touch Optimization** - TouchScreenButton and gesture handling designed
+- [ ] **Input Buffer System** - Frame-perfect input handling considerations
+
+## Progression and Balance
+
+### Player Progression
+
+- [ ] **Progression Type** - Linear, branching, or metroidvania approach defined
+- [ ] **Save System Design** - Godot Resource-based save/load architecture
+- [ ] **Unlock System** - What players unlock and how it's stored in Resources
+- [ ] **Difficulty Scaling** - How challenge increases using export variables
+- [ ] **Player Agency** - Meaningful choices affecting scene flow and game state
+
+### Game Balance
+
+- [ ] **Balance Parameters** - Export variables and Resources for tuning
+- [ ] **Difficulty Curve** - Appropriate challenge progression with scene variations
+- [ ] **Economy Design** - Resource systems using Godot's custom Resources
+- [ ] **Live Tuning** - Hot-reload support for balance iteration
+- [ ] **Data-Driven Design** - ScriptableObject-like Resources for configuration
+
+## Level Design Framework
+
+### Scene Structure
+
+- [ ] **Scene Types** - Different scene categories with Godot scene inheritance
+- [ ] **Scene Transitions** - How players move between scenes (loading strategy)
+- [ ] **Duration Targets** - Expected play time considering scene complexity
+- [ ] **Difficulty Distribution** - Scene variants for different difficulty levels
+- [ ] **Replay Value** - Procedural elements using Godot's randomization
+
+### Content Guidelines
+
+- [ ] **Scene Creation Rules** - Guidelines for Godot scene composition
+- [ ] **Mechanic Introduction** - Teaching through node activation and signals
+- [ ] **Pacing Variety** - Mix using different process modes and time scales
+- [ ] **Secret Content** - Hidden areas using Area2D/Area3D triggers
+- [ ] **Accessibility Modes** - Scene overrides for assist modes
+
+## Technical Implementation Readiness
+
+### Performance Requirements
+
+- [ ] **Frame Rate Targets** - 60+ FPS with Godot profiler validation
+- [ ] **Draw Call Budgets** - Maximum draw calls per scene type
+- [ ] **Memory Budgets** - Scene memory limits using Godot's monitors
+- [ ] **Mobile Optimization** - Battery usage and thermal considerations
+- [ ] **LOD Strategy** - Level of detail using visibility ranges
+
+### Platform Specifications
+
+- [ ] **Desktop Requirements** - Minimum specs for Windows/Mac/Linux exports
+- [ ] **Mobile Optimization** - iOS/Android specific Godot settings
+- [ ] **Web Compatibility** - HTML5 export constraints and optimizations
+- [ ] **Console Features** - Platform-specific Godot export templates
+- [ ] **Cross-Platform Save** - Cloud save compatibility considerations
+
+### Asset Requirements
+
+- [ ] **Art Style Definition** - Visual style with Godot import settings
+- [ ] **Texture Specifications** - Import presets for different asset types
+- [ ] **Audio Requirements** - Bus layout and compression settings
+- [ ] **UI/UX Guidelines** - Control node theming and responsiveness
+- [ ] **Localization Plan** - Translation system using Godot's localization
+
+## Godot-Specific Architecture
+
+### Node System Design
+
+- [ ] **Node Hierarchy** - Planned scene tree structure for major systems
+- [ ] **Scene Composition** - Reusable scene patterns and inheritance
+- [ ] **Autoload Systems** - Singleton managers and their responsibilities
+- [ ] **Signal Architecture** - Event flow between systems
+- [ ] **Group Management** - Node groups for gameplay systems
+
+### Language Strategy
+
+- [ ] **GDScript Usage** - Systems appropriate for rapid iteration
+- [ ] **C# Integration** - Performance-critical systems requiring C#
+- [ ] **Interop Design** - Boundaries between GDScript and C# code
+- [ ] **Plugin Requirements** - Required GDExtension or C# libraries
+- [ ] **Tool Scripts** - Editor tools for content creation
+
+### Resource Management
+
+- [ ] **Custom Resources** - Game-specific Resource classes planned
+- [ ] **Preload Strategy** - Resources to preload vs lazy load
+- [ ] **Instance Pooling** - Objects requiring pooling (bullets, effects)
+- [ ] **Memory Management** - Reference counting and cleanup strategy
+- [ ] **Asset Streaming** - Large asset loading approach
+
+## Development Planning
+
+### Implementation Phases
+
+- [ ] **Prototype Phase** - Core loop in minimal Godot project
+- [ ] **Vertical Slice** - Single polished level with all systems
+- [ ] **Production Phase** - Full content creation pipeline
+- [ ] **Polish Phase** - Performance optimization and juice
+- [ ] **Release Phase** - Platform exports and certification
+
+### Godot Workflow
+
+- [ ] **Version Control** - Git strategy for .tscn/.tres files
+- [ ] **Scene Workflow** - Prefab-like scene development process
+- [ ] **Asset Pipeline** - Import automation and validation
+- [ ] **Build Automation** - Godot headless export scripts
+- [ ] **Testing Pipeline** - GUT/GoDotTest integration
+
+## Quality Assurance
+
+### Performance Metrics
+
+- [ ] **Frame Time Targets** - Maximum ms per frame by system
+- [ ] **Draw Call Limits** - Per-scene rendering budgets
+- [ ] **Physics Budget** - Maximum active physics bodies
+- [ ] **Memory Footprint** - Platform-specific memory limits
+- [ ] **Load Time Goals** - Scene transition time requirements
+
+### Testing Strategy
+
+- [ ] **Unit Testing** - GUT tests for GDScript, GoDotTest for C#
+- [ ] **Integration Testing** - Scene and signal flow validation
+- [ ] **Performance Testing** - Profiler-based optimization workflow
+- [ ] **Platform Testing** - Export template validation process
+- [ ] **Playtesting Plan** - Godot analytics integration
+
+## Documentation Quality
+
+### Godot Integration
+
+- [ ] **Node Documentation** - Clear descriptions of node purposes
+- [ ] **Signal Documentation** - Event flow and parameters defined
+- [ ] **Export Variables** - All exposed parameters documented
+- [ ] **Resource Formats** - Custom Resource specifications
+- [ ] **API Documentation** - Public methods and properties described
+
+### Implementation Guidance
+
+- [ ] **Code Examples** - GDScript/C# snippets for complex systems
+- [ ] **Scene Templates** - Example scenes demonstrating patterns
+- [ ] **Performance Notes** - Optimization guidelines per feature
+- [ ] **Common Pitfalls** - Known Godot gotchas documented
+- [ ] **Best Practices** - Godot-specific patterns recommended
+
+## Multiplayer Considerations (if applicable)
+
+### Network Architecture
+
+- [ ] **Multiplayer Type** - P2P vs dedicated server using Godot's high-level API
+- [ ] **RPC Design** - Remote procedure calls and synchronization
+- [ ] **State Replication** - What state needs network synchronization
+- [ ] **Lag Compensation** - Client prediction and reconciliation
+- [ ] **Bandwidth Budget** - Network traffic limits per player
+
+## Final Readiness Assessment
+
+### Godot Implementation Ready
+
+- [ ] **Scene Planning Complete** - Node hierarchy and composition defined
+- [ ] **Performance Validated** - 60+ FPS achievable with design
+- [ ] **Language Strategy Clear** - GDScript vs C# decisions made
+- [ ] **Asset Pipeline Ready** - Import settings and workflow defined
+- [ ] **Testing Framework** - GUT/GoDotTest strategy established
+
+### Document Approval
+
+- [ ] **Design Review Complete** - Game design validated by team
+- [ ] **Technical Review Complete** - Godot feasibility confirmed
+- [ ] **Performance Review Complete** - Frame rate targets achievable
+- [ ] **Resource Review Complete** - Team capabilities match requirements
+- [ ] **Final Approval** - Document baselined for development
+
+## Overall Assessment
+
+**Document Quality Rating:** ⭐⭐⭐⭐⭐
+
+**Ready for Godot Development:** [ ] Yes [ ] No
+
+**Performance Risk Assessment:**
+_Identify any design elements that may challenge 60 FPS target._
+
+**Language Recommendations:**
+_Suggest which systems should use GDScript vs C# for optimal performance._
+
+**Key Recommendations:**
+_List critical items needing attention before Godot implementation._
+
+**Next Steps:**
+_Outline immediate actions for starting Godot development._