Godot Game Dev expansion pack for BMAD (#532)
* 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
@@ -0,0 +1,377 @@
|
||||
# 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.]]
|
||||
@@ -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.
|
||||
|
||||
---
|
||||
@@ -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._
|
||||
@@ -0,0 +1,448 @@
|
||||
# Game Product Owner (PO) Master Validation Checklist (Godot)
|
||||
|
||||
This checklist serves as a comprehensive framework for the Game Product Owner to validate game project plans before Godot development execution. It adapts based on project type (new game vs existing game enhancement) and includes platform considerations.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - GAME PO MASTER CHECKLIST
|
||||
|
||||
PROJECT TYPE DETECTION:
|
||||
First, determine the game project type by checking:
|
||||
|
||||
1. Is this a NEW GAME project (greenfield)?
|
||||
- Look for: New Godot project initialization, no existing game code
|
||||
- Check for: game-design-doc.md, architecture.md, new game setup
|
||||
- Godot version selection (4.x vs 3.x)
|
||||
|
||||
2. Is this an EXISTING GAME enhancement (brownfield)?
|
||||
- Look for: References to existing Godot project, enhancement language
|
||||
- Check for: existing .godot folder, project.godot file
|
||||
- Existing scenes, scripts, and resources
|
||||
|
||||
3. What platforms are targeted?
|
||||
- Desktop (Windows/Mac/Linux)
|
||||
- Mobile (iOS/Android)
|
||||
- Web (HTML5)
|
||||
- Console (requires special export templates)
|
||||
|
||||
DOCUMENT REQUIREMENTS:
|
||||
Based on project type, ensure you have access to:
|
||||
|
||||
For NEW GAME projects:
|
||||
|
||||
- game-design-doc.md - The Game Design Document
|
||||
- architecture.md - The technical architecture
|
||||
- platform-requirements.md - Platform specifications
|
||||
- All epic and story definitions
|
||||
|
||||
For EXISTING GAME enhancements:
|
||||
|
||||
- enhancement-doc.md - The enhancement requirements
|
||||
- existing Godot project access (CRITICAL)
|
||||
- Current performance metrics
|
||||
- Player feedback and analytics data
|
||||
- Existing save game compatibility requirements
|
||||
|
||||
SKIP INSTRUCTIONS:
|
||||
|
||||
- Skip sections marked [[EXISTING GAME ONLY]] for new games
|
||||
- Skip sections marked [[NEW GAME ONLY]] for existing games
|
||||
- Skip sections marked [[MOBILE ONLY]] for desktop-only games
|
||||
- Note all skipped sections in your final report
|
||||
|
||||
VALIDATION APPROACH:
|
||||
|
||||
1. Performance Focus - Every decision must support 60+ FPS target
|
||||
2. Player Experience - Fun and engagement drive all choices
|
||||
3. Platform Reality - Constraints guide implementation
|
||||
4. Technical Feasibility - Godot capabilities define boundaries
|
||||
|
||||
EXECUTION MODE:
|
||||
Ask if they want to work through:
|
||||
|
||||
- Section by section (interactive) - Review each, get confirmation
|
||||
- All at once (comprehensive) - Complete analysis, present report]]
|
||||
|
||||
## 1. GODOT PROJECT SETUP & INITIALIZATION
|
||||
|
||||
[[LLM: Foundation is critical. For new games, ensure proper Godot setup. For existing games, ensure safe integration without breaking current gameplay.]]
|
||||
|
||||
### 1.1 New Game Project Setup [[NEW GAME ONLY]]
|
||||
|
||||
- [ ] Godot version (4.x or 3.x) explicitly chosen with justification
|
||||
- [ ] Project.godot initial configuration defined
|
||||
- [ ] Folder structure follows Godot best practices
|
||||
- [ ] Initial scene hierarchy planned
|
||||
- [ ] Version control .gitignore for Godot configured
|
||||
- [ ] Language strategy decided (GDScript vs C# vs both)
|
||||
|
||||
### 1.2 Existing Game Integration [[EXISTING GAME ONLY]]
|
||||
|
||||
- [ ] Current Godot version compatibility verified
|
||||
- [ ] Existing scene structure analyzed and documented
|
||||
- [ ] Save game compatibility maintained
|
||||
- [ ] Player progression preservation ensured
|
||||
- [ ] Performance baseline measured (current FPS)
|
||||
- [ ] Rollback strategy for each change defined
|
||||
|
||||
### 1.3 Development Environment
|
||||
|
||||
- [ ] Godot Editor version specified and installed
|
||||
- [ ] .NET/Mono setup for C# development (if needed)
|
||||
- [ ] Export templates downloaded for target platforms
|
||||
- [ ] Asset import presets configured
|
||||
- [ ] Editor settings standardized across team
|
||||
- [ ] Performance profiling tools configured
|
||||
|
||||
### 1.4 Core Game Systems
|
||||
|
||||
- [ ] Autoload/singleton architecture defined early
|
||||
- [ ] Input mapping configured for all platforms
|
||||
- [ ] Audio bus layout established
|
||||
- [ ] Scene transition system implemented
|
||||
- [ ] Save/load system architecture defined
|
||||
- [ ] [[EXISTING GAME ONLY]] Compatibility with existing systems verified
|
||||
|
||||
## 2. GAME ARCHITECTURE & PERFORMANCE
|
||||
|
||||
[[LLM: Architecture determines performance. Every system must support 60+ FPS target. Language choices (GDScript vs C#) impact performance.]]
|
||||
|
||||
### 2.1 Scene & Node Architecture
|
||||
|
||||
- [ ] Main scene structure defined before implementation
|
||||
- [ ] Node naming conventions established
|
||||
- [ ] Scene inheritance patterns planned
|
||||
- [ ] Packed scenes for reusability identified
|
||||
- [ ] Signal connections architecture documented
|
||||
- [ ] [[EXISTING GAME ONLY]] Integration with existing scenes planned
|
||||
|
||||
### 2.2 Performance Systems
|
||||
|
||||
- [ ] Object pooling for bullets/enemies/particles planned
|
||||
- [ ] LOD system for complex scenes defined
|
||||
- [ ] Occlusion culling strategy established
|
||||
- [ ] Draw call batching approach documented
|
||||
- [ ] Memory budget per scene defined
|
||||
- [ ] [[MOBILE ONLY]] Mobile-specific optimizations planned
|
||||
|
||||
### 2.3 Language Strategy
|
||||
|
||||
- [ ] GDScript systems identified (rapid iteration needs)
|
||||
- [ ] C# systems identified (performance-critical code)
|
||||
- [ ] Interop boundaries minimized and defined
|
||||
- [ ] Static typing enforced in GDScript for performance
|
||||
- [ ] [[EXISTING GAME ONLY]] Migration path from existing code
|
||||
|
||||
### 2.4 Resource Management
|
||||
|
||||
- [ ] Custom Resource classes for game data defined
|
||||
- [ ] Texture import settings standardized
|
||||
- [ ] Audio compression settings optimized
|
||||
- [ ] Mesh and material optimization planned
|
||||
- [ ] Asset loading strategy (preload vs lazy load)
|
||||
|
||||
## 3. PLATFORM & DEPLOYMENT
|
||||
|
||||
[[LLM: Platform constraints drive many decisions. Mobile has strict performance limits. Web has size constraints. Consoles need certification.]]
|
||||
|
||||
### 3.1 Platform Requirements
|
||||
|
||||
- [ ] Target platforms explicitly listed with priorities
|
||||
- [ ] Minimum hardware specifications defined
|
||||
- [ ] Platform-specific features identified
|
||||
- [ ] Control schemes per platform defined
|
||||
- [ ] Performance targets per platform (60 FPS minimum)
|
||||
- [ ] [[MOBILE ONLY]] Touch controls and gestures designed
|
||||
|
||||
### 3.2 Export Configuration
|
||||
|
||||
- [ ] Export presets created for each platform
|
||||
- [ ] Platform-specific settings configured
|
||||
- [ ] Icon and splash screens prepared
|
||||
- [ ] Code signing requirements identified
|
||||
- [ ] [[MOBILE ONLY]] App store requirements checked
|
||||
- [ ] [[WEB ONLY]] Browser compatibility verified
|
||||
|
||||
### 3.3 Build Pipeline
|
||||
|
||||
- [ ] Automated build process using Godot headless
|
||||
- [ ] Version numbering strategy defined
|
||||
- [ ] Build size optimization planned
|
||||
- [ ] Platform-specific optimizations configured
|
||||
- [ ] [[EXISTING GAME ONLY]] Patch/update system maintained
|
||||
|
||||
### 3.4 Testing Infrastructure
|
||||
|
||||
- [ ] GUT framework setup for GDScript tests
|
||||
- [ ] GoDotTest configured for C# tests
|
||||
- [ ] Performance testing benchmarks defined
|
||||
- [ ] Platform testing matrix created
|
||||
- [ ] [[EXISTING GAME ONLY]] Regression testing for existing features
|
||||
|
||||
## 4. GAME FEATURES & CONTENT
|
||||
|
||||
[[LLM: Features must be fun AND performant. Every feature impacts frame rate. Content must be optimized for target platforms.]]
|
||||
|
||||
### 4.1 Core Gameplay Features
|
||||
|
||||
- [ ] Core loop implemented with performance validation
|
||||
- [ ] Player controls responsive (<50ms input latency)
|
||||
- [ ] Game state management efficient
|
||||
- [ ] Progression systems data-driven
|
||||
- [ ] [[EXISTING GAME ONLY]] New features integrated smoothly
|
||||
|
||||
### 4.2 Content Pipeline
|
||||
|
||||
- [ ] Level/scene creation workflow defined
|
||||
- [ ] Asset production pipeline established
|
||||
- [ ] Localization system implemented
|
||||
- [ ] Content validation process created
|
||||
- [ ] [[EXISTING GAME ONLY]] Content compatibility ensured
|
||||
|
||||
### 4.3 Multiplayer Systems [[IF APPLICABLE]]
|
||||
|
||||
- [ ] Network architecture (P2P vs dedicated) chosen
|
||||
- [ ] RPC usage planned and optimized
|
||||
- [ ] State synchronization strategy defined
|
||||
- [ ] Lag compensation implemented
|
||||
- [ ] Bandwidth requirements validated
|
||||
|
||||
## 5. PLAYER EXPERIENCE & MONETIZATION
|
||||
|
||||
[[LLM: Player experience drives retention. Monetization must be ethical and balanced. Performance must never suffer for monetization.]]
|
||||
|
||||
### 5.1 Player Journey
|
||||
|
||||
- [ ] Onboarding experience optimized
|
||||
- [ ] Tutorial system non-intrusive
|
||||
- [ ] Difficulty curve properly balanced
|
||||
- [ ] Progression feels rewarding
|
||||
- [ ] [[EXISTING GAME ONLY]] Existing player experience preserved
|
||||
|
||||
### 5.2 Monetization Strategy [[IF APPLICABLE]]
|
||||
|
||||
- [ ] Monetization model clearly defined
|
||||
- [ ] IAP implementation planned
|
||||
- [ ] Ad integration performance impact assessed
|
||||
- [ ] Economy balanced for free and paying players
|
||||
- [ ] [[EXISTING GAME ONLY]] Existing economy not disrupted
|
||||
|
||||
### 5.3 Analytics & Metrics
|
||||
|
||||
- [ ] Key metrics identified (retention, engagement)
|
||||
- [ ] Analytics integration planned
|
||||
- [ ] Performance tracking implemented
|
||||
- [ ] A/B testing framework considered
|
||||
- [ ] [[EXISTING GAME ONLY]] Historical data preserved
|
||||
|
||||
## 6. QUALITY & PERFORMANCE VALIDATION
|
||||
|
||||
[[LLM: Quality determines success. Performance determines playability. Testing prevents player frustration.]]
|
||||
|
||||
### 6.1 Performance Standards
|
||||
|
||||
- [ ] 60+ FPS target on all platforms confirmed
|
||||
- [ ] Frame time budget per system defined
|
||||
- [ ] Memory usage limits established
|
||||
- [ ] Load time targets set (<3 seconds)
|
||||
- [ ] Battery usage optimized for mobile
|
||||
|
||||
### 6.2 Testing Strategy
|
||||
|
||||
- [ ] Unit tests for game logic (GUT/GoDotTest)
|
||||
- [ ] Integration tests for scenes
|
||||
- [ ] Performance tests automated
|
||||
- [ ] Playtesting schedule defined
|
||||
- [ ] [[EXISTING GAME ONLY]] Regression testing comprehensive
|
||||
|
||||
### 6.3 Polish & Game Feel
|
||||
|
||||
- [ ] Juice and polish planned
|
||||
- [ ] Particle effects budgeted
|
||||
- [ ] Screen shake and effects optimized
|
||||
- [ ] Audio feedback immediate
|
||||
- [ ] Visual feedback responsive
|
||||
|
||||
## 7. RISK MANAGEMENT
|
||||
|
||||
[[LLM: Games fail from poor performance, bugs, or lack of fun. Identify and mitigate risks early.]]
|
||||
|
||||
### 7.1 Technical Risks
|
||||
|
||||
- [ ] Performance bottlenecks identified
|
||||
- [ ] Platform limitations acknowledged
|
||||
- [ ] Third-party dependencies minimized
|
||||
- [ ] Godot version stability assessed
|
||||
- [ ] [[EXISTING GAME ONLY]] Breaking change risks evaluated
|
||||
|
||||
### 7.2 Game Design Risks
|
||||
|
||||
- [ ] Fun factor validation planned
|
||||
- [ ] Difficulty spike risks identified
|
||||
- [ ] Player frustration points addressed
|
||||
- [ ] Monetization balance risks assessed
|
||||
- [ ] [[EXISTING GAME ONLY]] Player backlash risks considered
|
||||
|
||||
### 7.3 Mitigation Strategies
|
||||
|
||||
- [ ] Performance fallbacks defined
|
||||
- [ ] Feature flags for risky features
|
||||
- [ ] Rollback procedures documented
|
||||
- [ ] Player communication plan ready
|
||||
- [ ] [[EXISTING GAME ONLY]] Save game migration tested
|
||||
|
||||
## 8. MVP SCOPE & PRIORITIES
|
||||
|
||||
[[LLM: MVP means Minimum VIABLE Product. Must be fun, performant, and complete. No half-features.]]
|
||||
|
||||
### 8.1 Core Features
|
||||
|
||||
- [ ] Essential gameplay features identified
|
||||
- [ ] Nice-to-have features deferred
|
||||
- [ ] Complete player journey possible
|
||||
- [ ] All platforms equally playable
|
||||
- [ ] [[EXISTING GAME ONLY]] Enhancement value justified
|
||||
|
||||
### 8.2 Content Scope
|
||||
|
||||
- [ ] Minimum viable content defined
|
||||
- [ ] Vertical slice fully polished
|
||||
- [ ] Replayability considered
|
||||
- [ ] Content production realistic
|
||||
- [ ] [[EXISTING GAME ONLY]] Existing content maintained
|
||||
|
||||
### 8.3 Technical Scope
|
||||
|
||||
- [ ] Performance targets achievable
|
||||
- [ ] Platform requirements met
|
||||
- [ ] Testing coverage adequate
|
||||
- [ ] Technical debt acceptable
|
||||
- [ ] [[EXISTING GAME ONLY]] Integration complexity managed
|
||||
|
||||
## 9. TEAM & TIMELINE
|
||||
|
||||
[[LLM: Game development is iterative. Teams need clear milestones. Realistic timelines prevent crunch.]]
|
||||
|
||||
### 9.1 Development Phases
|
||||
|
||||
- [ ] Prototype phase defined (core loop)
|
||||
- [ ] Production phase planned (content creation)
|
||||
- [ ] Polish phase allocated (juice and optimization)
|
||||
- [ ] Certification time included (if console)
|
||||
- [ ] [[EXISTING GAME ONLY]] Integration phases defined
|
||||
|
||||
### 9.2 Team Capabilities
|
||||
|
||||
- [ ] Godot expertise adequate
|
||||
- [ ] GDScript/C# skills matched to needs
|
||||
- [ ] Art pipeline capabilities confirmed
|
||||
- [ ] Testing resources allocated
|
||||
- [ ] [[EXISTING GAME ONLY]] Domain knowledge preserved
|
||||
|
||||
## 10. POST-LAUNCH CONSIDERATIONS
|
||||
|
||||
[[LLM: Games are living products. Plan for success. Updates and content keep players engaged.]]
|
||||
|
||||
### 10.1 Live Operations
|
||||
|
||||
- [ ] Update delivery mechanism planned
|
||||
- [ ] Content pipeline sustainable
|
||||
- [ ] Bug fix process defined
|
||||
- [ ] Player support prepared
|
||||
- [ ] [[EXISTING GAME ONLY]] Compatibility maintained
|
||||
|
||||
### 10.2 Future Content
|
||||
|
||||
- [ ] DLC/expansion architecture supports
|
||||
- [ ] Season pass structure considered
|
||||
- [ ] Event system architecture ready
|
||||
- [ ] Community features planned
|
||||
- [ ] [[EXISTING GAME ONLY]] Expansion doesn't break base game
|
||||
|
||||
## VALIDATION SUMMARY
|
||||
|
||||
[[LLM: FINAL GAME PO VALIDATION REPORT
|
||||
|
||||
Generate comprehensive validation report:
|
||||
|
||||
1. Executive Summary
|
||||
- Project type: [New Game/Game Enhancement]
|
||||
- Target platforms: [List]
|
||||
- Performance risk: [High/Medium/Low]
|
||||
- Go/No-Go recommendation
|
||||
- Language strategy assessment (GDScript/C#)
|
||||
|
||||
2. Performance Analysis
|
||||
- 60 FPS achievability per platform
|
||||
- Memory budget compliance
|
||||
- Load time projections
|
||||
- Battery impact (mobile)
|
||||
- Optimization opportunities
|
||||
|
||||
3. Player Experience Assessment
|
||||
- Fun factor validation
|
||||
- Progression balance
|
||||
- Monetization ethics
|
||||
- Retention projections
|
||||
- [EXISTING GAME] Player disruption
|
||||
|
||||
4. Technical Readiness
|
||||
- Godot architecture completeness
|
||||
- Language strategy appropriateness
|
||||
- Testing coverage adequacy
|
||||
- Platform requirements met
|
||||
- [EXISTING GAME] Integration complexity
|
||||
|
||||
5. Risk Assessment
|
||||
- Top 5 risks by severity
|
||||
- Performance bottlenecks
|
||||
- Platform constraints
|
||||
- Timeline concerns
|
||||
- Mitigation recommendations
|
||||
|
||||
6. MVP Validation
|
||||
- Core loop completeness
|
||||
- Platform parity
|
||||
- Content sufficiency
|
||||
- Polish level adequacy
|
||||
- True MVP vs over-scope
|
||||
|
||||
7. Recommendations
|
||||
- Must-fix before development
|
||||
- Should-fix for quality
|
||||
- Consider for improvement
|
||||
- Post-launch additions
|
||||
|
||||
Ask if user wants:
|
||||
|
||||
- Detailed performance analysis
|
||||
- Platform-specific deep dive
|
||||
- Risk mitigation strategies
|
||||
- Timeline optimization suggestions]]
|
||||
|
||||
### Category Statuses
|
||||
|
||||
| Category | Status | Critical Issues |
|
||||
| ----------------------------- | ------ | --------------- |
|
||||
| 1. Godot Project Setup | _TBD_ | |
|
||||
| 2. Architecture & Performance | _TBD_ | |
|
||||
| 3. Platform & Deployment | _TBD_ | |
|
||||
| 4. Game Features & Content | _TBD_ | |
|
||||
| 5. Player Experience | _TBD_ | |
|
||||
| 6. Quality & Performance | _TBD_ | |
|
||||
| 7. Risk Management | _TBD_ | |
|
||||
| 8. MVP Scope | _TBD_ | |
|
||||
| 9. Team & Timeline | _TBD_ | |
|
||||
| 10. Post-Launch | _TBD_ | |
|
||||
|
||||
### Critical Performance Risks
|
||||
|
||||
(To be populated during validation)
|
||||
|
||||
### Platform-Specific Concerns
|
||||
|
||||
(To be populated during validation)
|
||||
|
||||
### Final Decision
|
||||
|
||||
- **APPROVED**: Game plan is comprehensive, performant, and ready for Godot development
|
||||
- **CONDITIONAL**: Plan requires specific adjustments for performance/platform requirements
|
||||
- **REJECTED**: Plan requires significant revision to meet quality and performance standards
|
||||
@@ -0,0 +1,202 @@
|
||||
# Game Development Story Definition of Done (DoD) Checklist (Godot)
|
||||
|
||||
## Instructions for Developer Agent
|
||||
|
||||
Before marking a story as 'Ready for Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - GODOT GAME STORY DOD VALIDATION
|
||||
|
||||
This checklist is for GAME DEVELOPER AGENTS to self-validate their Godot implementation work before marking a story complete.
|
||||
|
||||
IMPORTANT: This is a self-assessment following TDD principles. Be honest about what's actually done vs what should be done. Performance targets (60+ FPS) are non-negotiable.
|
||||
|
||||
EXECUTION APPROACH:
|
||||
|
||||
1. Verify tests were written FIRST (TDD compliance)
|
||||
2. Go through each section systematically
|
||||
3. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
|
||||
4. Add brief comments explaining any [ ] or [N/A] items
|
||||
5. Report performance metrics (FPS, draw calls, memory)
|
||||
6. Flag any technical debt or optimization needs
|
||||
|
||||
The goal is performant, tested, quality delivery following John Carmack's optimization philosophy.]]
|
||||
|
||||
## Checklist Items
|
||||
|
||||
1. **Test-Driven Development Compliance:**
|
||||
|
||||
[[LLM: TDD is mandatory. Tests must be written FIRST. No exceptions.]]
|
||||
- [ ] Tests were written BEFORE implementation (Red phase)
|
||||
- [ ] Tests initially failed as expected
|
||||
- [ ] Implementation made tests pass (Green phase)
|
||||
- [ ] Code was refactored while maintaining passing tests (Refactor phase)
|
||||
- [ ] GUT tests written for all GDScript code
|
||||
- [ ] GoDotTest tests written for all C# code
|
||||
- [ ] Test coverage meets 80% minimum requirement
|
||||
- [ ] Performance benchmarks defined and passing
|
||||
|
||||
2. **Requirements & Game Design:**
|
||||
|
||||
[[LLM: Requirements drive implementation. GDD alignment is critical.]]
|
||||
- [ ] All functional requirements from story implemented
|
||||
- [ ] All acceptance criteria met and tested
|
||||
- [ ] Game Design Document (GDD) requirements implemented
|
||||
- [ ] Player experience goals achieved
|
||||
- [ ] Core gameplay loop functions correctly
|
||||
- [ ] Fun factor validated through testing
|
||||
|
||||
3. **Godot Standards & Architecture:**
|
||||
|
||||
[[LLM: Godot best practices ensure maintainability and performance.]]
|
||||
- [ ] Node hierarchy follows Godot conventions
|
||||
- [ ] Scene composition patterns properly used
|
||||
- [ ] Signal connections documented and optimized
|
||||
- [ ] Autoload/singleton usage justified
|
||||
- [ ] Resource system used appropriately
|
||||
- [ ] Export variables properly configured
|
||||
- [ ] Node groups used for efficient queries
|
||||
- [ ] Scene inheritance utilized where appropriate
|
||||
|
||||
4. **Code Quality & Language Strategy:**
|
||||
|
||||
[[LLM: Language choice impacts performance. GDScript for iteration, C# for computation.]]
|
||||
- [ ] GDScript code uses static typing throughout
|
||||
- [ ] C# code follows .NET conventions
|
||||
- [ ] Language choice (GDScript vs C#) justified for each system
|
||||
- [ ] Interop between languages minimized
|
||||
- [ ] Memory management patterns followed (pooling, references)
|
||||
- [ ] No GDScript/C# marshalling in hot paths
|
||||
- [ ] Code comments explain optimization decisions
|
||||
- [ ] No new script errors or warnings
|
||||
|
||||
5. **Performance Validation:**
|
||||
|
||||
[[LLM: 60+ FPS is the minimum, not the target. Profile everything.]]
|
||||
- [ ] Stable 60+ FPS achieved on target hardware
|
||||
- [ ] Frame time consistently under 16.67ms
|
||||
- [ ] Draw calls within budget for scene type
|
||||
- [ ] Memory usage within platform limits
|
||||
- [ ] No memory leaks detected
|
||||
- [ ] Object pooling implemented where needed
|
||||
- [ ] Godot profiler shows no bottlenecks
|
||||
- [ ] Performance regression tests pass
|
||||
|
||||
6. **Platform Testing:**
|
||||
|
||||
[[LLM: Test on all target platforms. Platform-specific issues kill games.]]
|
||||
- [ ] Functionality verified in Godot Editor
|
||||
- [ ] Desktop export tested (Windows/Mac/Linux)
|
||||
- [ ] Mobile export tested if applicable (iOS/Android)
|
||||
- [ ] Web export tested if applicable (HTML5)
|
||||
- [ ] Input handling works on all platforms
|
||||
- [ ] Platform-specific optimizations applied
|
||||
- [ ] Export settings properly configured
|
||||
- [ ] Build sizes within acceptable limits
|
||||
|
||||
7. **Game Functionality:**
|
||||
|
||||
[[LLM: Games must be fun AND functional. Test the player experience.]]
|
||||
- [ ] Game mechanics work as specified
|
||||
- [ ] Player controls responsive (<50ms input latency)
|
||||
- [ ] UI elements function correctly (Control nodes)
|
||||
- [ ] Audio integration works (AudioStreamPlayer)
|
||||
- [ ] Visual feedback and animations smooth
|
||||
- [ ] Particle effects within performance budget
|
||||
- [ ] Save/load system functions correctly
|
||||
- [ ] Scene transitions work smoothly
|
||||
|
||||
8. **Testing Coverage:**
|
||||
|
||||
[[LLM: Comprehensive testing prevents player frustration.]]
|
||||
- [ ] Unit tests (GUT/GoDotTest) all passing
|
||||
- [ ] Integration tests for scene interactions pass
|
||||
- [ ] Performance tests meet benchmarks
|
||||
- [ ] Edge cases and error conditions handled
|
||||
- [ ] Multiplayer tests pass (if applicable)
|
||||
- [ ] Platform-specific tests complete
|
||||
- [ ] Regression tests for existing features pass
|
||||
- [ ] Manual playtesting completed
|
||||
|
||||
9. **Story Administration:**
|
||||
|
||||
[[LLM: Documentation enables team collaboration.]]
|
||||
- [ ] All tasks within story marked complete [x]
|
||||
- [ ] Implementation decisions documented
|
||||
- [ ] Performance optimizations noted
|
||||
- [ ] File List section updated with all changes
|
||||
- [ ] Debug Log references added
|
||||
- [ ] Completion Notes comprehensive
|
||||
- [ ] Change Log updated
|
||||
- [ ] Status set to 'Ready for Review'
|
||||
|
||||
10. **Project & Dependencies:**
|
||||
|
||||
[[LLM: Project must build and run. Dependencies must be justified.]]
|
||||
- [ ] Godot project opens without errors
|
||||
- [ ] Project exports successfully for all platforms
|
||||
- [ ] Any new plugins/addons pre-approved
|
||||
- [ ] Asset import settings optimized
|
||||
- [ ] Project settings properly configured
|
||||
- [ ] Version control files (.tscn/.tres) clean
|
||||
- [ ] No uncommitted debug code
|
||||
- [ ] Build automation scripts updated
|
||||
|
||||
11. **Optimization & Polish:**
|
||||
|
||||
[[LLM: Following Carmack's philosophy - measure, optimize, verify.]]
|
||||
- [ ] Hot paths identified and optimized
|
||||
- [ ] Critical code moved to C# if needed
|
||||
- [ ] Draw call batching implemented
|
||||
- [ ] Texture atlasing used where appropriate
|
||||
- [ ] LOD system implemented if needed
|
||||
- [ ] Occlusion culling configured
|
||||
- [ ] Static typing used throughout GDScript
|
||||
- [ ] Signal connections optimized
|
||||
|
||||
12. **Documentation:**
|
||||
|
||||
[[LLM: Good documentation prevents future confusion.]]
|
||||
- [ ] GDScript documentation comments complete
|
||||
- [ ] C# XML documentation complete
|
||||
- [ ] Node purposes documented in scenes
|
||||
- [ ] Export variable tooltips added
|
||||
- [ ] Performance notes included
|
||||
- [ ] Platform-specific notes documented
|
||||
- [ ] Known issues or limitations noted
|
||||
|
||||
## Performance Metrics Report
|
||||
|
||||
[[LLM: Report actual performance metrics, not estimates.]]
|
||||
|
||||
- **Frame Rate:** \_\_\_ FPS (Target: 60+)
|
||||
- **Frame Time:** \_\_\_ ms (Target: <16.67ms)
|
||||
- **Draw Calls:** **_ (Budget: _**)
|
||||
- **Memory Usage:** **_ MB (Limit: _**)
|
||||
- **Scene Load Time:** \_\_\_ seconds
|
||||
- **Input Latency:** \_\_\_ ms
|
||||
- **Test Coverage:** \_\_\_% (Minimum: 80%)
|
||||
|
||||
## Final Confirmation
|
||||
|
||||
[[LLM: FINAL GODOT DOD SUMMARY
|
||||
|
||||
After completing the checklist:
|
||||
|
||||
1. Confirm TDD was followed (tests written first)
|
||||
2. Report performance metrics with specific numbers
|
||||
3. List any items marked [ ] with explanations
|
||||
4. Identify optimization opportunities
|
||||
5. Note any technical debt created
|
||||
6. Confirm the story is truly ready for review
|
||||
7. State whether 60+ FPS target is met
|
||||
|
||||
Remember Carmack's principle: "Focus on what matters: framerate and responsiveness."
|
||||
|
||||
Be honest - performance issues and bugs found now are easier to fix than after release.]]
|
||||
|
||||
- [ ] I, the Game Developer Agent, confirm that:
|
||||
- [ ] TDD was followed (tests written first)
|
||||
- [ ] All applicable items above have been addressed
|
||||
- [ ] Performance targets (60+ FPS) are met
|
||||
- [ ] Tests provide 80%+ coverage
|
||||
- [ ] The story is ready for review
|
||||
Reference in New Issue
Block a user