feat: Overhaul and Enhance 2D Unity Game Dev Expansion Pack (#350)
* Updated game-sm agent to match the new core framework patterns * feat:Created more comprehensive game story matching new format system as well * feat:Added Game specific course correct task * feat:Updated dod-checklist to match new DoD format * feat:Added new Architect agent for appropriate architecture doc creation and design * feat:Overhaul of game-architecture-tmpl template * feat:Updated rest of templates besides level which doesnt really need it * feat: Finished extended architecture documentation needed for new game story tasks * feat: Updated game Developer to new format * feat: Updated last agent to new format and updated bmad-kb. bmad-kb I did my best with but im not sure of it's valid usage in the expansion pack, the AI generated more of the file then myself. I made sure to include it due to the new core-config file * feat: Finished updating designer agent to new format and cleaned up template linting errors * Built dist for web bundle * Increased expansion pack minor verison number * Updated architecht and design for sharding built-in * chore: bump bmad-2d-unity-game-dev version (minor) * updated config.yaml for game-specific pieces to supplement core-config.yaml * Updated game-core-config and epic processing for game story and game design. Initial implementation was far too generic * chore: bump bmad-2d-unity-game-dev version (patch) * feat: Fixed issue with multi-configs being needed. chore: bump bmad-2d-unity-game-dev version (patch) * Chore: Built web-bundle * feat: Added the ability to specify the unity editor install location.\nchore: bump bmad-2d-unity-game-dev version (patch) * feat: core-config must be in two places to support inherited tasks at this time so added instructions to copy and create one in expansion pack folder as well. chore: bump bmad-2d-unity-game-dev version (patch)
This commit is contained in:
PinkyD
@@ -0,0 +1,396 @@
|
||||
# Game Architect Solution Validation Checklist
|
||||
|
||||
This checklist serves as a comprehensive framework for the Game Architect to validate the technical design and architecture before game development execution. 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.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - REQUIRED ARTIFACTS
|
||||
|
||||
Before proceeding with this checklist, ensure you have access to:
|
||||
|
||||
1. game-architecture.md - The primary game architecture document (check docs/game-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. Unity project structure documentation
|
||||
5. Game balance and configuration specifications
|
||||
6. Platform target specifications
|
||||
|
||||
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 Unity game project?
|
||||
- What platforms are targeted?
|
||||
- What are the core game mechanics from the GDD?
|
||||
- Are there specific performance requirements?
|
||||
|
||||
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 and mobile optimization for every architectural decision
|
||||
|
||||
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? Keep these in mind as you validate the technical architecture serves the game design.]]
|
||||
|
||||
### 1.1 Core Mechanics Coverage
|
||||
|
||||
- [ ] Architecture supports all core game mechanics from GDD
|
||||
- [ ] Technical approaches for all game systems are addressed
|
||||
- [ ] Player controls and input handling are properly architected
|
||||
- [ ] Game state management covers all required states
|
||||
- [ ] All gameplay features have corresponding technical systems
|
||||
|
||||
### 1.2 Performance & Platform Requirements
|
||||
|
||||
- [ ] Target frame rate requirements are addressed with specific solutions
|
||||
- [ ] Mobile platform constraints are considered in architecture
|
||||
- [ ] Memory usage optimization strategies are defined
|
||||
- [ ] Battery life considerations are addressed
|
||||
- [ ] Cross-platform compatibility is properly architected
|
||||
|
||||
### 1.3 Unity-Specific Requirements Adherence
|
||||
|
||||
- [ ] Unity version and LTS requirements are satisfied
|
||||
- [ ] Unity Package Manager dependencies are specified
|
||||
- [ ] Target platform build settings are addressed
|
||||
- [ ] Unity asset pipeline usage is optimized
|
||||
- [ ] MonoBehaviour lifecycle usage is properly planned
|
||||
|
||||
## 2. GAME ARCHITECTURE FUNDAMENTALS
|
||||
|
||||
[[LLM: Game architecture must be clear for rapid iteration. As you review this section, think about how a game developer would implement these systems. Are the component responsibilities clear? Would the architecture support quick gameplay tweaks and balancing changes? Look for Unity-specific patterns and clear separation of game logic.]]
|
||||
|
||||
### 2.1 Game Systems Clarity
|
||||
|
||||
- [ ] Game architecture is documented with clear system diagrams
|
||||
- [ ] Major game systems and their responsibilities are defined
|
||||
- [ ] System interactions and dependencies are mapped
|
||||
- [ ] Game data flows are clearly illustrated
|
||||
- [ ] Unity-specific implementation approaches are specified
|
||||
|
||||
### 2.2 Unity Component Architecture
|
||||
|
||||
- [ ] Clear separation between GameObjects, Components, and ScriptableObjects
|
||||
- [ ] MonoBehaviour usage follows Unity best practices
|
||||
- [ ] Prefab organization and instantiation patterns are defined
|
||||
- [ ] Scene management and loading strategies are clear
|
||||
- [ ] Unity's component-based architecture is properly leveraged
|
||||
|
||||
### 2.3 Game Design Patterns & Practices
|
||||
|
||||
- [ ] Appropriate game programming patterns are employed (Singleton, Observer, State Machine, etc.)
|
||||
- [ ] Unity best practices are followed throughout
|
||||
- [ ] Common game development anti-patterns are avoided
|
||||
- [ ] Consistent architectural style across game systems
|
||||
- [ ] Pattern usage is documented with Unity-specific examples
|
||||
|
||||
### 2.4 Scalability & Iteration Support
|
||||
|
||||
- [ ] Game systems support rapid iteration and balancing changes
|
||||
- [ ] Components can be developed and tested independently
|
||||
- [ ] Game configuration changes can be made without code changes
|
||||
- [ ] Architecture supports adding new content and features
|
||||
- [ ] System designed for AI agent implementation of game features
|
||||
|
||||
## 3. UNITY TECHNOLOGY STACK & DECISIONS
|
||||
|
||||
[[LLM: Unity technology choices impact long-term maintainability. For each Unity-specific decision, consider: Is this using Unity's strengths? Will this scale to full production? Are we fighting against Unity's paradigms? Verify that specific Unity versions and package versions are defined.]]
|
||||
|
||||
### 3.1 Unity Technology Selection
|
||||
|
||||
- [ ] Unity version (preferably LTS) is specifically defined
|
||||
- [ ] Required Unity packages are listed with versions
|
||||
- [ ] Unity features used are appropriate for 2D game development
|
||||
- [ ] Third-party Unity assets are justified and documented
|
||||
- [ ] Technology choices leverage Unity's 2D toolchain effectively
|
||||
|
||||
### 3.2 Game Systems Architecture
|
||||
|
||||
- [ ] Game Manager and core systems architecture is defined
|
||||
- [ ] Audio system using Unity's AudioMixer is specified
|
||||
- [ ] Input system using Unity's new Input System is outlined
|
||||
- [ ] UI system using Unity's UI Toolkit or UGUI is determined
|
||||
- [ ] Scene management and loading architecture is clear
|
||||
- [ ] Gameplay systems architecture covers core game mechanics and player interactions
|
||||
- [ ] Component architecture details define MonoBehaviour and ScriptableObject patterns
|
||||
- [ ] Physics configuration for Unity 2D is comprehensively defined
|
||||
- [ ] State machine architecture covers game states, player states, and entity behaviors
|
||||
- [ ] UI component system and data binding patterns are established
|
||||
- [ ] UI state management across screens and game states is defined
|
||||
- [ ] Data persistence and save system architecture is fully specified
|
||||
- [ ] Analytics integration approach is defined (if applicable)
|
||||
- [ ] Multiplayer architecture is detailed (if applicable)
|
||||
- [ ] Rendering pipeline configuration and optimization strategies are clear
|
||||
- [ ] Shader guidelines and performance considerations are documented
|
||||
- [ ] Sprite management and optimization strategies are defined
|
||||
- [ ] Particle system architecture and performance budgets are established
|
||||
- [ ] Audio architecture includes system design and category management
|
||||
- [ ] Audio mixing configuration with Unity AudioMixer is detailed
|
||||
- [ ] Sound bank management and asset organization is specified
|
||||
- [ ] Unity development conventions and best practices are documented
|
||||
|
||||
### 3.3 Data Architecture & Game Balance
|
||||
|
||||
- [ ] ScriptableObject usage for game data is properly planned
|
||||
- [ ] Game balance data structures are fully defined
|
||||
- [ ] Save/load system architecture is specified
|
||||
- [ ] Data serialization approach is documented
|
||||
- [ ] Configuration and tuning data management is outlined
|
||||
|
||||
### 3.4 Asset Pipeline & Management
|
||||
|
||||
- [ ] Sprite and texture management approach is defined
|
||||
- [ ] Audio asset organization is specified
|
||||
- [ ] Prefab organization and management is planned
|
||||
- [ ] Asset loading and memory management strategies are outlined
|
||||
- [ ] Build pipeline and asset bundling approach is defined
|
||||
|
||||
## 4. GAME PERFORMANCE & OPTIMIZATION
|
||||
|
||||
[[LLM: Performance is critical for games. This section focuses on Unity-specific performance considerations. Think about frame rate stability, memory allocation, and mobile constraints. Look for specific Unity profiling and optimization strategies.]]
|
||||
|
||||
### 4.1 Rendering Performance
|
||||
|
||||
- [ ] 2D rendering pipeline optimization is addressed
|
||||
- [ ] Sprite batching and draw call optimization is planned
|
||||
- [ ] UI rendering performance is considered
|
||||
- [ ] Particle system performance limits are defined
|
||||
- [ ] Target platform rendering constraints are addressed
|
||||
|
||||
### 4.2 Memory Management
|
||||
|
||||
- [ ] Object pooling strategies are defined for frequently instantiated objects
|
||||
- [ ] Memory allocation minimization approaches are specified
|
||||
- [ ] Asset loading and unloading strategies prevent memory leaks
|
||||
- [ ] Garbage collection impact is minimized through design
|
||||
- [ ] Mobile memory constraints are properly addressed
|
||||
|
||||
### 4.3 Game Logic Performance
|
||||
|
||||
- [ ] Update loop optimization strategies are defined
|
||||
- [ ] Physics system performance considerations are addressed
|
||||
- [ ] Coroutine usage patterns are optimized
|
||||
- [ ] Event system performance impact is minimized
|
||||
- [ ] AI and game logic performance budgets are established
|
||||
|
||||
### 4.4 Mobile & Cross-Platform Performance
|
||||
|
||||
- [ ] Mobile-specific performance optimizations are planned
|
||||
- [ ] Battery life optimization strategies are defined
|
||||
- [ ] Platform-specific performance tuning is addressed
|
||||
- [ ] Scalable quality settings system is designed
|
||||
- [ ] Performance testing approach for target devices is outlined
|
||||
|
||||
## 5. GAME SYSTEMS RESILIENCE & TESTING
|
||||
|
||||
[[LLM: Games need robust systems that handle edge cases gracefully. Consider what happens when the player does unexpected things, when systems fail, or when running on low-end devices. Look for specific testing strategies for game logic and Unity systems.]]
|
||||
|
||||
### 5.1 Game State Resilience
|
||||
|
||||
- [ ] Save/load system error handling is comprehensive
|
||||
- [ ] Game state corruption recovery is addressed
|
||||
- [ ] Invalid player input handling is specified
|
||||
- [ ] Game system failure recovery approaches are defined
|
||||
- [ ] Edge case handling in game logic is documented
|
||||
|
||||
### 5.2 Unity-Specific Testing
|
||||
|
||||
- [ ] Unity Test Framework usage is defined
|
||||
- [ ] Game logic unit testing approach is specified
|
||||
- [ ] Play mode testing strategies are outlined
|
||||
- [ ] Performance testing with Unity Profiler is planned
|
||||
- [ ] Device testing approach across target platforms is defined
|
||||
|
||||
### 5.3 Game Balance & Configuration Testing
|
||||
|
||||
- [ ] Game balance testing methodology is defined
|
||||
- [ ] Configuration data validation is specified
|
||||
- [ ] A/B testing support is considered if needed
|
||||
- [ ] Game metrics collection is planned
|
||||
- [ ] Player feedback integration approach is outlined
|
||||
|
||||
## 6. GAME DEVELOPMENT WORKFLOW
|
||||
|
||||
[[LLM: Efficient game development requires clear workflows. Consider how designers, artists, and programmers will collaborate. Look for clear asset pipelines, version control strategies, and build processes that support the team.]]
|
||||
|
||||
### 6.1 Unity Project Organization
|
||||
|
||||
- [ ] Unity project folder structure is clearly defined
|
||||
- [ ] Asset naming conventions are specified
|
||||
- [ ] Scene organization and workflow is documented
|
||||
- [ ] Prefab organization and usage patterns are defined
|
||||
- [ ] Version control strategy for Unity projects is outlined
|
||||
|
||||
### 6.2 Content Creation Workflow
|
||||
|
||||
- [ ] Art asset integration workflow is defined
|
||||
- [ ] Audio asset integration process is specified
|
||||
- [ ] Level design and creation workflow is outlined
|
||||
- [ ] Game data configuration process is clear
|
||||
- [ ] Iteration and testing workflow supports rapid changes
|
||||
|
||||
### 6.3 Build & Deployment
|
||||
|
||||
- [ ] Unity build pipeline configuration is specified
|
||||
- [ ] Multi-platform build strategy is defined
|
||||
- [ ] Build automation approach is outlined
|
||||
- [ ] Testing build deployment is addressed
|
||||
- [ ] Release build optimization is planned
|
||||
|
||||
## 7. GAME-SPECIFIC IMPLEMENTATION GUIDANCE
|
||||
|
||||
[[LLM: Clear implementation guidance prevents game development mistakes. Consider Unity-specific coding patterns, common pitfalls in game development, and clear examples of how game systems should be implemented.]]
|
||||
|
||||
### 7.1 Unity C# Coding Standards
|
||||
|
||||
- [ ] Unity-specific C# coding standards are defined
|
||||
- [ ] MonoBehaviour lifecycle usage patterns are specified
|
||||
- [ ] Coroutine usage guidelines are outlined
|
||||
- [ ] Event system usage patterns are defined
|
||||
- [ ] ScriptableObject creation and usage patterns are documented
|
||||
|
||||
### 7.2 Game System Implementation Patterns
|
||||
|
||||
- [ ] Singleton pattern usage for game managers is specified
|
||||
- [ ] State machine implementation patterns are defined
|
||||
- [ ] Observer pattern usage for game events is outlined
|
||||
- [ ] Object pooling implementation patterns are documented
|
||||
- [ ] Component communication patterns are clearly defined
|
||||
|
||||
### 7.3 Unity Development Environment
|
||||
|
||||
- [ ] Unity project setup and configuration is documented
|
||||
- [ ] Required Unity packages and versions are specified
|
||||
- [ ] Unity Editor workflow and tools usage is outlined
|
||||
- [ ] Debug and testing tools configuration is defined
|
||||
- [ ] Unity development best practices are documented
|
||||
|
||||
## 8. GAME CONTENT & ASSET MANAGEMENT
|
||||
|
||||
[[LLM: Games require extensive asset management. Consider how sprites, audio, prefabs, and data will be organized, loaded, and managed throughout the game's lifecycle. Look for scalable approaches that work with Unity's asset pipeline.]]
|
||||
|
||||
### 8.1 Game Asset Organization
|
||||
|
||||
- [ ] Sprite and texture organization is clearly defined
|
||||
- [ ] Audio asset organization and management is specified
|
||||
- [ ] Prefab organization and naming conventions are outlined
|
||||
- [ ] ScriptableObject organization for game data is defined
|
||||
- [ ] Asset dependency management is addressed
|
||||
|
||||
### 8.2 Dynamic Asset Loading
|
||||
|
||||
- [ ] Runtime asset loading strategies are specified
|
||||
- [ ] Asset bundling approach is defined if needed
|
||||
- [ ] Memory management for loaded assets is outlined
|
||||
- [ ] Asset caching and unloading strategies are defined
|
||||
- [ ] Platform-specific asset loading is addressed
|
||||
|
||||
### 8.3 Game Content Scalability
|
||||
|
||||
- [ ] Level and content organization supports growth
|
||||
- [ ] Modular content design patterns are defined
|
||||
- [ ] Content versioning and updates are addressed
|
||||
- [ ] User-generated content support is considered if needed
|
||||
- [ ] Content validation and testing approaches are specified
|
||||
|
||||
## 9. AI AGENT GAME DEVELOPMENT SUITABILITY
|
||||
|
||||
[[LLM: This game architecture may be implemented by AI agents. Review with game development clarity in mind. Are Unity patterns consistent? Is game logic complexity minimized? Would an AI agent understand Unity-specific concepts? Look for clear component responsibilities and implementation patterns.]]
|
||||
|
||||
### 9.1 Unity System Modularity
|
||||
|
||||
- [ ] Game systems are appropriately sized for AI implementation
|
||||
- [ ] Unity component dependencies are minimized and clear
|
||||
- [ ] MonoBehaviour responsibilities are singular and well-defined
|
||||
- [ ] ScriptableObject usage patterns are consistent
|
||||
- [ ] Prefab organization supports systematic implementation
|
||||
|
||||
### 9.2 Game Logic Clarity
|
||||
|
||||
- [ ] Game mechanics are broken down into clear, implementable steps
|
||||
- [ ] Unity-specific patterns are documented with examples
|
||||
- [ ] Complex game logic is simplified into component interactions
|
||||
- [ ] State machines and game flow are explicitly defined
|
||||
- [ ] Component communication patterns are predictable
|
||||
|
||||
### 9.3 Implementation Support
|
||||
|
||||
- [ ] Unity project structure templates are provided
|
||||
- [ ] Component implementation patterns are documented
|
||||
- [ ] Common Unity pitfalls are identified with solutions
|
||||
- [ ] Game system testing patterns are clearly defined
|
||||
- [ ] Performance optimization guidelines are explicit
|
||||
|
||||
## 10. PLATFORM & PUBLISHING CONSIDERATIONS
|
||||
|
||||
[[LLM: Different platforms have different requirements and constraints. Consider mobile app stores, desktop platforms, and web deployment. Look for platform-specific optimizations and compliance requirements.]]
|
||||
|
||||
### 10.1 Platform-Specific Architecture
|
||||
|
||||
- [ ] Mobile platform constraints are properly addressed
|
||||
- [ ] Desktop platform features are leveraged appropriately
|
||||
- [ ] Web platform limitations are considered if applicable
|
||||
- [ ] Console platform requirements are addressed if applicable
|
||||
- [ ] Platform-specific input handling is planned
|
||||
|
||||
### 10.2 Publishing & Distribution
|
||||
|
||||
- [ ] App store compliance requirements are addressed
|
||||
- [ ] Platform-specific build configurations are defined
|
||||
- [ ] Update and patch deployment strategy is planned
|
||||
- [ ] Platform analytics integration is considered
|
||||
- [ ] Platform-specific monetization is addressed if applicable
|
||||
|
||||
[[LLM: FINAL GAME ARCHITECTURE VALIDATION REPORT
|
||||
|
||||
Generate a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall game architecture readiness (High/Medium/Low)
|
||||
- Critical risks for game development
|
||||
- Key strengths of the game architecture
|
||||
- Unity-specific assessment
|
||||
|
||||
2. Game Systems Analysis
|
||||
|
||||
- Pass rate for each major system section
|
||||
- Most concerning gaps in game architecture
|
||||
- Systems requiring immediate attention
|
||||
- Unity integration completeness
|
||||
|
||||
3. Performance Risk Assessment
|
||||
|
||||
- Top 5 performance risks for the game
|
||||
- Mobile platform specific concerns
|
||||
- Frame rate stability risks
|
||||
- Memory usage concerns
|
||||
|
||||
4. Implementation Recommendations
|
||||
|
||||
- Must-fix items before development
|
||||
- Unity-specific improvements needed
|
||||
- Game development workflow enhancements
|
||||
|
||||
5. AI Agent Implementation Readiness
|
||||
|
||||
- Game-specific concerns for AI implementation
|
||||
- Unity component complexity assessment
|
||||
- Areas needing additional clarification
|
||||
|
||||
6. Game Development Workflow Assessment
|
||||
- Asset pipeline completeness
|
||||
- Team collaboration workflow clarity
|
||||
- Build and deployment readiness
|
||||
- Testing strategy completeness
|
||||
|
||||
After presenting the report, ask the user if they would like detailed analysis of any specific game system or Unity-specific concerns.]]
|
||||
@@ -0,0 +1,203 @@
|
||||
# Game Development Change Navigation Checklist
|
||||
|
||||
**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 Unity 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 and player experience are paramount
|
||||
|
||||
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
|
||||
|
||||
APPROACH:
|
||||
This is an interactive process. Discuss performance implications, platform constraints, and player impact. The user makes final decisions, but provide expert Unity/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, memory, load times)
|
||||
- Is this platform-specific or universal?
|
||||
- Can we reproduce it consistently?
|
||||
- What Unity profiler data do we have?
|
||||
- Is this a gameplay issue or technical constraint?
|
||||
|
||||
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)?
|
||||
- [ ] Platform-specific limitation?
|
||||
- [ ] Unity engine constraint?
|
||||
- [ ] Gameplay/balance issue from playtesting?
|
||||
- [ ] Asset pipeline or build size problem?
|
||||
- [ ] Third-party SDK/plugin conflict?
|
||||
- [ ] **Assess Performance Impact:** Document specific metrics (current FPS, target FPS, memory usage, build size).
|
||||
- [ ] **Gather Technical Evidence:** Note profiler data, crash logs, platform test results, player feedback.
|
||||
|
||||
## 2. Game Feature Impact Assessment
|
||||
|
||||
[[LLM: Game features are interconnected. Evaluate systematically:
|
||||
|
||||
1. Can we optimize the current feature without changing gameplay?
|
||||
2. Do dependent features need adjustment?
|
||||
3. Are there platform-specific workarounds?
|
||||
4. Does this affect our performance budget allocation?
|
||||
|
||||
Consider both technical and gameplay impacts.]]
|
||||
|
||||
- [ ] **Analyze Current Sprint Features:**
|
||||
- [ ] Can the current feature be optimized (LOD, pooling, batching)?
|
||||
- [ ] Does it need gameplay simplification?
|
||||
- [ ] Should it be platform-specific (high-end only)?
|
||||
- [ ] **Analyze Dependent Systems:**
|
||||
- [ ] Review all game systems interacting with the affected feature.
|
||||
- [ ] Do physics systems need adjustment?
|
||||
- [ ] Are UI/HUD systems impacted?
|
||||
- [ ] Do save/load systems require changes?
|
||||
- [ ] Are multiplayer systems affected?
|
||||
- [ ] **Summarize Feature Impact:** Document effects on gameplay systems 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?
|
||||
|
||||
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 Unity architecture (scene structure, prefab hierarchy)?
|
||||
- [ ] Are component systems impacted?
|
||||
- [ ] Do shader/rendering approaches need revision?
|
||||
- [ ] Are data structures optimal for the scale?
|
||||
- [ ] **Review Performance Specifications:**
|
||||
- [ ] Are target framerates still achievable?
|
||||
- [ ] Do memory budgets need reallocation?
|
||||
- [ ] Are load time targets realistic?
|
||||
- [ ] Do we need platform-specific targets?
|
||||
- [ ] **Review Asset Specifications:**
|
||||
- [ ] Do texture resolutions need adjustment?
|
||||
- [ ] Are model poly counts appropriate?
|
||||
- [ ] Do audio compression settings need changes?
|
||||
- [ ] Is the animation budget sustainable?
|
||||
- [ ] **Summarize Artifact Impact:** List all game documents requiring updates.
|
||||
|
||||
## 4. Path Forward Evaluation
|
||||
|
||||
[[LLM: Present game-specific solutions with technical trade-offs:
|
||||
|
||||
1. What's the performance gain?
|
||||
2. How much rework is required?
|
||||
3. What's the player experience impact?
|
||||
4. Are there platform-specific solutions?
|
||||
5. Is this maintainable across updates?
|
||||
|
||||
Be specific about Unity implementation details.]]
|
||||
|
||||
- [ ] **Option 1: Optimization Within Current Design:**
|
||||
- [ ] Can performance be improved through Unity optimizations?
|
||||
- [ ] Object pooling implementation?
|
||||
- [ ] LOD system addition?
|
||||
- [ ] Texture atlasing?
|
||||
- [ ] Draw call batching?
|
||||
- [ ] Shader optimization?
|
||||
- [ ] Define specific optimization techniques.
|
||||
- [ ] Estimate performance improvement potential.
|
||||
- [ ] **Option 2: 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 3: Architecture Refactor:**
|
||||
- [ ] Would restructuring improve performance significantly?
|
||||
- [ ] Identify Unity-specific refactoring needs:
|
||||
- [ ] Scene organization changes?
|
||||
- [ ] Prefab structure optimization?
|
||||
- [ ] Component system redesign?
|
||||
- [ ] State machine optimization?
|
||||
- [ ] Estimate development effort.
|
||||
- [ ] **Option 4: 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)
|
||||
2. Unity implementation details
|
||||
3. Platform-specific considerations
|
||||
4. Testing requirements
|
||||
5. 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 game systems and dependencies.
|
||||
- [ ] **Performance Projections:** Expected improvements from chosen solution.
|
||||
- [ ] **Implementation Plan:** Unity-specific technical approach.
|
||||
- [ ] **Platform Considerations:** Any platform-specific implementations.
|
||||
- [ ] **Testing Strategy:** Performance benchmarks and 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 clearly defined?
|
||||
2. Is the Unity implementation approach clear?
|
||||
3. Do we have rollback strategies?
|
||||
4. Are test scenarios defined?
|
||||
5. 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 gains
|
||||
- Implementation approach in Unity
|
||||
- Testing and validation plan
|
||||
- Timeline and milestone impacts
|
||||
|
||||
Keep it technically precise and actionable.]]
|
||||
|
||||
- [ ] **Review Checklist:** Confirm all technical aspects discussed.
|
||||
- [ ] **Review Change Proposal:** Ensure Unity implementation details are clear.
|
||||
- [ ] **Performance Validation:** Define how we'll measure success.
|
||||
- [ ] **User Approval:** Obtain approval for technical approach.
|
||||
- [ ] **Developer Handoff:** Ensure game-dev agent has all technical details needed.
|
||||
|
||||
---
|
||||
@@ -176,7 +176,7 @@
|
||||
|
||||
- [ ] **Story Creation Ready** - Document provides sufficient detail for story creation
|
||||
- [ ] **Architecture Alignment** - Game design aligns with technical capabilities
|
||||
- ] **Asset Production** - Asset requirements enable art and audio production
|
||||
- [ ] **Asset Production** - Asset requirements enable art and audio production
|
||||
- [ ] **Development Workflow** - Clear path from design to implementation
|
||||
- [ ] **Quality Assurance** - Testing and validation processes established
|
||||
|
||||
|
||||
@@ -1,160 +1,132 @@
|
||||
# Game Development Story Definition of Done Checklist
|
||||
# Game Development Story Definition of Done (DoD) Checklist
|
||||
|
||||
## Story Completeness
|
||||
## Instructions for Developer Agent
|
||||
|
||||
### Basic Story Elements
|
||||
Before marking a story as '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.
|
||||
|
||||
- [ ] **Story Title** - Clear, descriptive title that identifies the feature
|
||||
- [ ] **Epic Assignment** - Story is properly assigned to relevant epic
|
||||
- [ ] **Priority Level** - Appropriate priority assigned (High/Medium/Low)
|
||||
- [ ] **Story Points** - Realistic estimation for implementation complexity
|
||||
- [ ] **Description** - Clear, concise description of what needs to be implemented
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - GAME STORY DOD VALIDATION
|
||||
|
||||
### Game Design Alignment
|
||||
This checklist is for GAME DEVELOPER AGENTS to self-validate their work before marking a story complete.
|
||||
|
||||
- [ ] **GDD Reference** - Specific Game Design Document section referenced
|
||||
- [ ] **Game Mechanic Context** - Clear connection to game mechanics defined in GDD
|
||||
- [ ] **Player Experience Goal** - Describes the intended player experience
|
||||
- [ ] **Balance Parameters** - Includes any relevant game balance values
|
||||
- [ ] **Design Intent** - Purpose and rationale for the feature is clear
|
||||
IMPORTANT: This is a self-assessment. Be honest about what's actually done vs what should be done. It's better to identify issues now than have them found in review.
|
||||
|
||||
## Technical Specifications
|
||||
EXECUTION APPROACH:
|
||||
|
||||
### Architecture Compliance
|
||||
1. Go through each section systematically
|
||||
2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
|
||||
3. Add brief comments explaining any [ ] or [N/A] items
|
||||
4. Be specific about what was actually implemented
|
||||
5. Flag any concerns or technical debt created
|
||||
|
||||
- [ ] **File Organization** - Follows game architecture document structure (e.g., scripts, prefabs, scenes)
|
||||
- [ ] **Class Definitions** - C# classes and interfaces are properly defined
|
||||
- [ ] **Integration Points** - Clear specification of how feature integrates with existing systems
|
||||
- [ ] **Event Communication** - UnityEvents or C# events usage specified
|
||||
- [ ] **Dependencies** - All system dependencies clearly identified
|
||||
The goal is quality delivery, not just checking boxes.]]
|
||||
|
||||
### Unity Requirements
|
||||
## Checklist Items
|
||||
|
||||
- [ ] **Scene Integration** - Specifies which scenes are affected and how
|
||||
- [ ] **Prefab Usage** - Proper use of prefabs for reusable GameObjects
|
||||
- [ ] **Component Design** - Logic is encapsulated in well-defined MonoBehaviour components
|
||||
- [ ] **Asset Requirements** - All needed assets (sprites, audio, materials) identified
|
||||
- [ ] **Performance Considerations** - Stable frame rate target and optimization requirements
|
||||
1. **Requirements Met:**
|
||||
|
||||
### Code Quality Standards
|
||||
[[LLM: Be specific - list each requirement and whether it's complete. Include game-specific requirements from GDD]]
|
||||
|
||||
- [ ] **C# Best Practices** - All code must comply with modern C# standards
|
||||
- [ ] **Error Handling** - Error scenarios and handling requirements specified
|
||||
- [ ] **Memory Management** - Coroutine and object lifecycle management requirements where needed
|
||||
- [ ] **Cross-Platform Support** - Desktop and mobile considerations addressed
|
||||
- [ ] **Code Organization** - Follows established Unity project structure
|
||||
- [ ] All functional requirements specified in the story are implemented.
|
||||
- [ ] All acceptance criteria defined in the story are met.
|
||||
- [ ] Game Design Document (GDD) requirements referenced in the story are implemented.
|
||||
- [ ] Player experience goals specified in the story are achieved.
|
||||
|
||||
## Implementation Readiness
|
||||
2. **Coding Standards & Project Structure:**
|
||||
|
||||
### Acceptance Criteria
|
||||
[[LLM: Code quality matters for maintainability. Check Unity-specific patterns and C# standards]]
|
||||
|
||||
- [ ] **Functional Requirements** - All functional acceptance criteria are specific and testable
|
||||
- [ ] **Technical Requirements** - Technical acceptance criteria are complete and verifiable
|
||||
- [ ] **Game Design Requirements** - Game-specific requirements match GDD specifications
|
||||
- [ ] **Performance Requirements** - Frame rate and memory usage criteria specified
|
||||
- [ ] **Completeness** - No acceptance criteria are vague or unmeasurable
|
||||
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
|
||||
- [ ] All new/modified code aligns with `Project Structure` (Scripts/, Prefabs/, Scenes/, etc.).
|
||||
- [ ] Adherence to `Tech Stack` for Unity version and packages used.
|
||||
- [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
|
||||
- [ ] Unity best practices followed (prefab usage, component design, event handling).
|
||||
- [ ] C# coding standards followed (naming conventions, error handling, memory management).
|
||||
- [ ] Basic security best practices applied for new/modified code.
|
||||
- [ ] No new linter errors or warnings introduced.
|
||||
- [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
|
||||
|
||||
### Implementation Tasks
|
||||
3. **Testing:**
|
||||
|
||||
- [ ] **Task Breakdown** - Story broken into specific, ordered implementation tasks
|
||||
- [ ] **Task Scope** - Each task is completable in 1-4 hours
|
||||
- [ ] **Task Clarity** - Each task has clear, actionable instructions
|
||||
- [ ] **File Specifications** - Exact file paths and purposes specified (e.g., `Scripts/Player/PlayerMovement.cs`)
|
||||
- [ ] **Development Flow** - Tasks follow logical implementation order
|
||||
[[LLM: Testing proves your code works. Include Unity-specific testing with NUnit and manual testing]]
|
||||
|
||||
### Dependencies
|
||||
- [ ] All required unit tests (NUnit) as per the story and testing strategy are implemented.
|
||||
- [ ] All required integration tests (if applicable) are implemented.
|
||||
- [ ] Manual testing performed in Unity Editor for all game functionality.
|
||||
- [ ] All tests (unit, integration, manual) pass successfully.
|
||||
- [ ] Test coverage meets project standards (if defined).
|
||||
- [ ] Performance tests conducted (frame rate, memory usage).
|
||||
- [ ] Edge cases and error conditions tested.
|
||||
|
||||
- [ ] **Story Dependencies** - All prerequisite stories identified with IDs
|
||||
- [ ] **Technical Dependencies** - Required systems and files identified
|
||||
- [ ] **Asset Dependencies** - All needed assets specified with locations
|
||||
- [ ] **External Dependencies** - Any third-party or external requirements noted (e.g., Asset Store packages)
|
||||
- [ ] **Dependency Validation** - All dependencies are actually available
|
||||
4. **Functionality & Verification:**
|
||||
|
||||
## Testing Requirements
|
||||
[[LLM: Did you actually run and test your code in Unity? Be specific about game mechanics tested]]
|
||||
|
||||
### Test Coverage
|
||||
- [ ] Functionality has been manually verified in Unity Editor and play mode.
|
||||
- [ ] Game mechanics work as specified in the GDD.
|
||||
- [ ] Player controls and input handling work correctly.
|
||||
- [ ] UI elements function properly (if applicable).
|
||||
- [ ] Audio integration works correctly (if applicable).
|
||||
- [ ] Visual feedback and animations work as intended.
|
||||
- [ ] Edge cases and potential error conditions handled gracefully.
|
||||
- [ ] Cross-platform functionality verified (desktop/mobile as applicable).
|
||||
|
||||
- [ ] **Unit Test Requirements** - Specific unit test files and scenarios defined for NUnit
|
||||
- [ ] **Integration Test Cases** - Integration testing with other game systems specified
|
||||
- [ ] **Manual Test Cases** - Game-specific manual testing procedures defined in the Unity Editor
|
||||
- [ ] **Performance Tests** - Frame rate and memory testing requirements specified
|
||||
- [ ] **Edge Case Testing** - Edge cases and error conditions covered
|
||||
5. **Story Administration:**
|
||||
|
||||
### Test Implementation
|
||||
[[LLM: Documentation helps the next developer. Include Unity-specific implementation notes]]
|
||||
|
||||
- [ ] **Test File Paths** - Exact test file locations specified (e.g., `Assets/Tests/EditMode`)
|
||||
- [ ] **Test Scenarios** - All test scenarios are complete and executable
|
||||
- [ ] **Expected Behaviors** - Clear expected outcomes for all tests defined
|
||||
- [ ] **Performance Metrics** - Specific performance targets for testing
|
||||
- [ ] **Test Data** - Any required test data or mock objects specified
|
||||
- [ ] All tasks within the story file are marked as complete.
|
||||
- [ ] Any clarifications or decisions made during development are documented.
|
||||
- [ ] Unity-specific implementation details documented (scene changes, prefab modifications).
|
||||
- [ ] The story wrap up section has been completed with notes of changes.
|
||||
- [ ] Changelog properly updated with Unity version and package changes.
|
||||
|
||||
## Game-Specific Quality
|
||||
6. **Dependencies, Build & Configuration:**
|
||||
|
||||
### Gameplay Implementation
|
||||
[[LLM: Build issues block everyone. Ensure Unity project builds for all target platforms]]
|
||||
|
||||
- [ ] **Mechanic Accuracy** - Implementation matches GDD mechanic specifications
|
||||
- [ ] **Player Controls** - Input handling requirements are complete (e.g., Input System package)
|
||||
- [ ] **Game Feel** - Requirements for juice, feedback, and responsiveness specified
|
||||
- [ ] **Balance Implementation** - Numeric values and parameters from GDD included
|
||||
- [ ] **State Management** - Game state changes and persistence requirements defined
|
||||
- [ ] Unity project builds successfully without errors.
|
||||
- [ ] Project builds for all target platforms (desktop/mobile as specified).
|
||||
- [ ] Any new Unity packages or Asset Store items were pre-approved OR approved by user.
|
||||
- [ ] If new dependencies were added, they are recorded with justification.
|
||||
- [ ] No known security vulnerabilities in newly added dependencies.
|
||||
- [ ] Project settings and configurations properly updated.
|
||||
- [ ] Asset import settings optimized for target platforms.
|
||||
|
||||
### User Experience
|
||||
7. **Game-Specific Quality:**
|
||||
|
||||
- [ ] **UI Requirements** - User interface elements and behaviors specified (e.g., UI Toolkit or UGUI)
|
||||
- [ ] **Audio Integration** - Sound effect and music requirements defined
|
||||
- [ ] **Visual Feedback** - Animation and visual effect requirements specified (e.g., Animator, Particle System)
|
||||
- [ ] **Accessibility** - Mobile touch and responsive design considerations
|
||||
- [ ] **Error Recovery** - User-facing error handling and recovery specified
|
||||
[[LLM: Game quality matters. Check performance, game feel, and player experience]]
|
||||
|
||||
### Performance Optimization
|
||||
- [ ] Frame rate meets target (30/60 FPS) on all platforms.
|
||||
- [ ] Memory usage within acceptable limits.
|
||||
- [ ] Game feel and responsiveness meet design requirements.
|
||||
- [ ] Balance parameters from GDD correctly implemented.
|
||||
- [ ] State management and persistence work correctly.
|
||||
- [ ] Loading times and scene transitions acceptable.
|
||||
- [ ] Mobile-specific requirements met (touch controls, aspect ratios).
|
||||
|
||||
- [ ] **Frame Rate Targets** - Specific FPS requirements for different platforms
|
||||
- [ ] **Memory Usage** - Memory consumption limits and monitoring requirements (e.g., Profiler)
|
||||
- [ ] **Asset Optimization** - Texture, audio, and data optimization requirements
|
||||
- [ ] **Mobile Considerations** - Touch controls and mobile performance requirements
|
||||
- [ ] **Loading Performance** - Asset loading and scene transition requirements
|
||||
8. **Documentation (If Applicable):**
|
||||
|
||||
## Documentation and Communication
|
||||
[[LLM: Good documentation prevents future confusion. Include Unity-specific docs]]
|
||||
|
||||
### Story Documentation
|
||||
- [ ] Code documentation (XML comments) for public APIs complete.
|
||||
- [ ] Unity component documentation in Inspector updated.
|
||||
- [ ] User-facing documentation updated, if changes impact players.
|
||||
- [ ] Technical documentation (architecture, system diagrams) updated.
|
||||
- [ ] Asset documentation (prefab usage, scene setup) complete.
|
||||
|
||||
- [ ] **Implementation Notes** - Additional context and implementation guidance provided
|
||||
- [ ] **Design Decisions** - Key design choices documented with rationale
|
||||
- [ ] **Future Considerations** - Potential future enhancements or modifications noted
|
||||
- [ ] **Change Tracking** - Process for tracking any requirement changes during development
|
||||
- [ ] **Reference Materials** - Links to relevant GDD sections and architecture docs
|
||||
## Final Confirmation
|
||||
|
||||
### Developer Handoff
|
||||
[[LLM: FINAL GAME DOD SUMMARY
|
||||
|
||||
- [ ] **Immediate Actionability** - Developer can start implementation without additional questions
|
||||
- [ ] **Complete Context** - All necessary context provided within the story
|
||||
- [ ] **Clear Boundaries** - What is and isn't included in the story scope is clear
|
||||
- [ ] **Success Criteria** - Objective measures for story completion defined
|
||||
- [ ] **Communication Plan** - Process for developer questions and updates established
|
||||
After completing the checklist:
|
||||
|
||||
## Final Validation
|
||||
1. Summarize what game features/mechanics were implemented
|
||||
2. List any items marked as [ ] Not Done with explanations
|
||||
3. Identify any technical debt or performance concerns
|
||||
4. Note any challenges with Unity implementation or game design
|
||||
5. Confirm whether the story is truly ready for review
|
||||
6. Report final performance metrics (FPS, memory usage)
|
||||
|
||||
### Story Readiness
|
||||
Be honest - it's better to flag issues now than have them discovered during playtesting.]]
|
||||
|
||||
- [ ] **No Ambiguity** - No sections require interpretation or additional design decisions
|
||||
- [ ] **Technical Completeness** - All technical requirements are specified and actionable
|
||||
- [ ] **Scope Appropriateness** - Story scope matches assigned story points
|
||||
- [ ] **Quality Standards** - Story meets all game development quality standards
|
||||
- [ ] **Review Completion** - Story has been reviewed for completeness and accuracy
|
||||
|
||||
### Implementation Preparedness
|
||||
|
||||
- [ ] **Environment Ready** - Development environment requirements specified (e.g., Unity version)
|
||||
- [ ] **Resources Available** - All required resources (assets, docs, dependencies) accessible
|
||||
- [ ] **Testing Prepared** - Testing environment and data requirements specified
|
||||
- [ ] **Definition of Done** - Clear, objective completion criteria established
|
||||
- [ ] **Handoff Complete** - Story is ready for developer assignment and implementation
|
||||
|
||||
## Checklist Completion
|
||||
|
||||
**Overall Story Quality:** ⭐⭐⭐⭐⭐
|
||||
|
||||
**Ready for Development:** [ ] Yes [ ] No
|
||||
|
||||
**Additional Notes:**
|
||||
_Any specific concerns, recommendations, or clarifications needed before development begins._
|
||||
- [ ] I, the Game Developer Agent, confirm that all applicable items above have been addressed.
|
||||
|
||||
Reference in New Issue
Block a user