BMAD-METHOD/expansion-packs/bmad-godot-game-dev/checklists/game-architect-checklist.md

Game Architect Solution Validation Checklist (Godot)

This checklist serves as a comprehensive framework for the Game Architect to validate the technical design and architecture for Godot game development. The Game Architect should systematically work through each item, ensuring the game architecture is robust, scalable, performant, and aligned with the Game Design Document requirements while leveraging Godot's strengths.

[[LLM: INITIALIZATION INSTRUCTIONS - REQUIRED ARTIFACTS

Before proceeding with this checklist, ensure you have access to:

1. architecture.md - The primary game architecture document (check docs/architecture.md)
2. game-design-doc.md - Game Design Document for game requirements alignment (check docs/game-design-doc.md)
3. Any system diagrams referenced in the architecture
4. Godot project structure documentation
5. Game balance and configuration specifications
6. Platform target specifications
7. Performance profiling data if available

IMPORTANT: If any required documents are missing or inaccessible, immediately ask the user for their location or content before proceeding.

GAME PROJECT TYPE DETECTION: First, determine the game project type by checking:

• Is this a 2D or 3D Godot game project?
• What platforms are targeted (mobile, desktop, web, console)?
• What are the core game mechanics from the GDD?
• Are there specific performance requirements (60 FPS, mobile constraints)?
• Will the project use GDScript, C#, or both?

VALIDATION APPROACH: For each section, you must:

1. Deep Analysis - Don't just check boxes, thoroughly analyze each item against the provided documentation
2. Evidence-Based - Cite specific sections or quotes from the documents when validating
3. Critical Thinking - Question assumptions and identify gaps, not just confirm what's present
4. Performance Focus - Consider frame rate impact, draw calls, and memory usage for every architectural decision
5. Language Balance - Evaluate whether GDScript vs C# choices are appropriate for each system

EXECUTION MODE: Ask the user if they want to work through the checklist:

• Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
• All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]

1. GAME DESIGN REQUIREMENTS ALIGNMENT

LLM: Before evaluating this section, fully understand the game's core mechanics and player experience from the GDD. What type of gameplay is this? What are the player's primary actions? What must feel responsive and smooth? Consider Godot's node-based architecture and how it serves these requirements.

1.1 Core Mechanics Coverage

• Architecture supports all core game mechanics from GDD
• Node hierarchy properly represents game entities and systems
• Player controls and input handling leverage Godot's Input system
• Game state management uses Godot's scene tree effectively
• All gameplay features map to appropriate Godot nodes and scenes

1.2 Performance & Platform Requirements

• Target frame rate requirements (60+ FPS) with specific solutions
• Mobile platform constraints addressed (draw calls, texture memory)
• Memory usage optimization strategies using Godot's monitoring tools
• Battery life considerations for mobile platforms
• Cross-platform compatibility leveraging Godot's export system

1.3 Godot-Specific Requirements Adherence

• Godot version (4.x or 3.x) is specified with justification
• .NET/Mono version requirements for C# projects defined
• Target platform export templates identified
• Asset import pipeline configuration specified
• Node lifecycle usage (_ready, _process, _physics_process) planned

2. GAME ARCHITECTURE FUNDAMENTALS

LLM: Godot's node-based architecture requires different thinking than component systems. As you review, consider: Are scenes properly composed? Is the node tree structure optimal? Are signals used effectively for decoupling? Is the architecture leveraging Godot's strengths?

2.1 Game Systems Clarity

• Game architecture documented with node tree diagrams
• Major scenes and their responsibilities defined
• Signal connections and event flows mapped
• Resource data flows clearly illustrated
• Scene inheritance and composition patterns specified

2.2 Godot Node Architecture

• Clear separation between scenes, nodes, and resources
• Node lifecycle methods used appropriately
• Scene instantiation and queue_free patterns defined
• Scene transition and management strategies clear
• Autoload/singleton usage justified and documented

2.3 Game Design Patterns & Practices

• Appropriate patterns for Godot (signals, groups, autoloads)
• GDScript and C# patterns used consistently
• Common Godot anti-patterns avoided (deep node paths, circular deps)
• Consistent architectural style across game systems
• Pattern usage documented with Godot-specific examples

2.4 Scalability & Performance Optimization

• Object pooling implemented for frequently spawned entities
• Draw call batching strategies defined
• LOD systems planned for complex scenes
• Occlusion culling configured appropriately
• Memory management patterns established

3. GODOT TECHNOLOGY STACK & LANGUAGE DECISIONS

LLM: Language choice (GDScript vs C#) impacts performance and development speed. For each system, verify the language choice is justified. GDScript for rapid iteration and Godot-native features, C# for compute-intensive operations and complex algorithms.

3.1 Language Strategy

• GDScript vs C# decision matrix for each system
• Performance-critical systems identified for C# implementation
• Rapid iteration systems appropriate for GDScript
• Interop boundaries between languages minimized
• Language-specific best practices documented

3.2 Godot Technology Selection

• Godot version with specific features needed
• Rendering backend choice (Vulkan/OpenGL) justified
• Physics engine (2D/3D) configuration specified
• Navigation system usage planned
• Third-party plugins justified and version-locked

3.3 Game Systems Architecture

• Game Manager using autoload pattern defined
• Audio system using AudioStreamPlayers and buses specified
• Input system with InputMap configuration outlined
• UI system using Control nodes or immediate mode determined
• Scene management and loading architecture clear
• Save/load system using Godot's serialization defined
• Multiplayer architecture using RPCs detailed (if applicable)
• Rendering optimization strategies documented
• Shader usage guidelines and performance limits
• Particle system budgets and pooling strategies
• Animation system using AnimationPlayer/AnimationTree

3.4 Data Architecture & Resources

• Resource usage for game data properly planned
• Custom Resource classes for game configuration
• Save game serialization approach specified
• Data validation and versioning handled
• Hot-reload support for development iteration

4. PERFORMANCE OPTIMIZATION & PROFILING

LLM: Performance is critical. Focus on Godot-specific optimizations: draw calls, physics bodies, node count, signal connections. Consider both GDScript and C# performance characteristics. Look for specific profiling strategies using Godot's built-in tools.

4.1 Rendering Performance

• Draw call optimization through batching
• Texture atlasing strategy defined
• Viewport usage and render targets optimized
• Shader complexity budgets established
• Culling and LOD systems configured

4.2 Memory Management

• Object pooling for bullets, particles, enemies
• Resource preloading vs lazy loading strategy
• Scene instance caching approach
• Reference cleanup patterns defined
• C# garbage collection mitigation (if using C#)

4.3 CPU Optimization

• Process vs physics_process usage optimized
• Signal connection overhead minimized
• Node tree depth optimization
• GDScript static typing for performance
• C# for compute-intensive operations

4.4 Profiling & Monitoring

• Godot profiler usage documented
• Performance metrics and budgets defined
• Frame time analysis approach
• Memory leak detection strategy
• Platform-specific profiling planned

5. TESTING & QUALITY ASSURANCE

LLM: Testing in Godot requires specific approaches. GUT for GDScript, GoDotTest for C#. Consider how TDD will be enforced, how performance will be validated, and how gameplay will be tested.

5.1 Test Framework Strategy

• GUT framework setup for GDScript testing
• GoDotTest/GodotTestDriver configuration for C# testing
• Test scene organization defined
• CI/CD pipeline with test automation
• Performance benchmark tests specified

5.2 Test Coverage Requirements

• Unit test coverage targets (80%+)
• Integration test scenarios defined
• Performance test baselines established
• Platform-specific test plans
• Gameplay experience validation tests

5.3 TDD Enforcement

• Red-Green-Refactor cycle mandated
• Test-first development workflow documented
• Code review includes test verification
• Performance tests before optimization
• Regression test automation

6. GAME DEVELOPMENT WORKFLOW

LLM: Efficient Godot development requires clear workflows. Consider scene organization, asset pipelines, version control with .tscn/.tres files, and collaboration patterns.

6.1 Godot Project Organization

• Project folder structure clearly defined
• Scene and resource naming conventions
• Asset organization (sprites, audio, scenes)
• Script attachment patterns documented
• Version control strategy for Godot files

6.2 Asset Pipeline

• Texture import settings standardized
• Audio import configuration defined
• 3D model pipeline established (if 3D)
• Font and UI asset management
• Asset compression strategies

6.3 Build & Deployment

• Export preset configuration documented
• Platform-specific export settings
• Build automation using Godot headless
• Debug vs release build optimization
• Distribution pipeline defined

7. GODOT-SPECIFIC IMPLEMENTATION GUIDANCE

LLM: Clear Godot patterns prevent common mistakes. Consider node lifecycle, signal patterns, resource management, and language-specific idioms.

7.1 GDScript Best Practices

• Static typing usage enforced
• Signal naming conventions defined
• Export variable usage guidelines
• Coroutine patterns documented
• Performance idioms specified

7.2 C# Integration Patterns

• C# coding standards for Godot
• Marshalling optimization patterns
• Dispose patterns for Godot objects
• Collection usage guidelines
• Async/await patterns in Godot

7.3 Node & Scene Patterns

• Scene composition strategies
• Node group usage patterns
• Signal vs method call guidelines
• Tool scripts usage defined
• Custom node development patterns

8. MULTIPLAYER & NETWORKING (if applicable)

LLM: Godot's high-level multiplayer API has specific patterns. If multiplayer is required, validate the architecture leverages Godot's networking strengths.

8.1 Network Architecture

• Client-server vs peer-to-peer decision
• RPC usage patterns defined
• State synchronization approach
• Lag compensation strategies
• Security considerations addressed

8.2 Multiplayer Implementation

• Network node ownership clear
• Reliable vs unreliable RPC usage
• Bandwidth optimization strategies
• Connection handling robust
• Testing approach for various latencies

9. AI AGENT IMPLEMENTATION SUITABILITY

LLM: This architecture may be implemented by AI agents. Review for clarity: Are Godot patterns consistent? Is the node hierarchy logical? Are GDScript/C# responsibilities clear? Would an AI understand the signal flows?

9.1 Implementation Clarity

• Node responsibilities singular and clear
• Signal connections documented explicitly
• Resource usage patterns consistent
• Scene composition rules defined
• Language choice per system justified

9.2 Development Patterns

• Common Godot patterns documented
• Anti-patterns explicitly called out
• Performance pitfalls identified
• Testing patterns clearly defined
• Debugging approaches specified

9.3 AI Implementation Support

• Template scenes provided
• Code snippets for common patterns
• Performance profiling examples
• Test case templates included
• Build automation scripts ready

10. PLATFORM & PERFORMANCE TARGETS

LLM: Different platforms have different constraints in Godot. Mobile needs special attention for performance, web has size constraints, desktop can leverage more features.

10.1 Platform-Specific Optimization

• Mobile performance targets achieved (60 FPS)
• Desktop feature utilization maximized
• Web build size optimization planned
• Console certification requirements met
• Platform input handling comprehensive

10.2 Performance Validation

• Frame time budgets per system defined
• Memory usage limits established
• Load time targets specified
• Battery usage goals for mobile
• Network bandwidth limits defined

[[LLM: FINAL GODOT ARCHITECTURE VALIDATION REPORT

Generate a comprehensive validation report that includes:

1. Executive Summary

   • Overall architecture readiness (High/Medium/Low)
   • Critical performance risks
   • Key architectural strengths
   • Language strategy assessment (GDScript/C#)

2. Godot Systems Analysis

   • Pass rate for each major section
   • Node architecture completeness
   • Signal system usage effectiveness
   • Resource management approach

3. Performance Risk Assessment

   • Top 5 performance bottlenecks
   • Platform-specific concerns
   • Memory management risks
   • Draw call and rendering concerns

4. Implementation Recommendations

   • Must-fix items before development
   • Godot-specific improvements needed
   • Language choice optimizations
   • Testing strategy gaps

5. Development Workflow Assessment

   • Asset pipeline completeness
   • Build system readiness
   • Testing framework setup
   • Version control preparedness

6. AI Agent Implementation Readiness

   • Clarity of Godot patterns
   • Complexity assessment
   • Areas needing clarification
   • Template completeness

After presenting the report, ask the user if they would like detailed analysis of any specific system, performance concern, or language consideration.]]