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,151 @@
|
||||
# Correct Course Task - Game Development
|
||||
|
||||
## Purpose
|
||||
|
||||
- Guide a structured response to game development change triggers using the `{root}/checklists/game-change-checklist`.
|
||||
- Analyze the impacts of changes on game features, technical systems, and milestone deliverables.
|
||||
- Explore game-specific solutions (e.g., performance optimizations, feature scaling, platform adjustments).
|
||||
- Draft specific, actionable proposed updates to affected game artifacts (e.g., GDD sections, technical specs, Unity configurations).
|
||||
- Produce a consolidated "Game Development Change Proposal" document for review and approval.
|
||||
- Ensure clear handoff path for changes requiring fundamental redesign or technical architecture updates.
|
||||
|
||||
## Instructions
|
||||
|
||||
### 1. Initial Setup & Mode Selection
|
||||
|
||||
- **Acknowledge Task & Inputs:**
|
||||
|
||||
- Confirm with the user that the "Game Development Correct Course Task" is being initiated.
|
||||
- Verify the change trigger (e.g., performance issue, platform constraint, gameplay feedback, technical blocker).
|
||||
- Confirm access to relevant game artifacts:
|
||||
- Game Design Document (GDD)
|
||||
- Technical Design Documents
|
||||
- Unity Architecture specifications
|
||||
- Performance budgets and platform requirements
|
||||
- Current sprint's game stories and epics
|
||||
- Asset specifications and pipelines
|
||||
- Confirm access to `{root}/checklists/game-change-checklist`.
|
||||
|
||||
- **Establish Interaction Mode:**
|
||||
- Ask the user their preferred interaction mode:
|
||||
- **"Incrementally (Default & Recommended):** Work through the game-change-checklist section by section, discussing findings and drafting changes collaboratively. Best for complex technical or gameplay changes."
|
||||
- **"YOLO Mode (Batch Processing):** Conduct batched analysis and present consolidated findings. Suitable for straightforward performance optimizations or minor adjustments."
|
||||
- Confirm the selected mode and inform: "We will now use the game-change-checklist to analyze the change and draft proposed updates specific to our Unity game development context."
|
||||
|
||||
### 2. Execute Game Development Checklist Analysis
|
||||
|
||||
- Systematically work through the game-change-checklist sections:
|
||||
|
||||
1. **Change Context & Game Impact**
|
||||
2. **Feature/System Impact Analysis**
|
||||
3. **Technical Artifact Conflict Resolution**
|
||||
4. **Performance & Platform Evaluation**
|
||||
5. **Path Forward Recommendation**
|
||||
|
||||
- For each checklist section:
|
||||
- Present game-specific prompts and considerations
|
||||
- Analyze impacts on:
|
||||
- Unity scenes and prefabs
|
||||
- Component dependencies
|
||||
- Performance metrics (FPS, memory, build size)
|
||||
- Platform-specific code paths
|
||||
- Asset loading and management
|
||||
- Third-party plugins/SDKs
|
||||
- Discuss findings with clear technical context
|
||||
- Record status: `[x] Addressed`, `[N/A]`, `[!] Further Action Needed`
|
||||
- Document Unity-specific decisions and constraints
|
||||
|
||||
### 3. Draft Game-Specific Proposed Changes
|
||||
|
||||
Based on the analysis and agreed path forward:
|
||||
|
||||
- **Identify affected game artifacts requiring updates:**
|
||||
|
||||
- GDD sections (mechanics, systems, progression)
|
||||
- Technical specifications (architecture, performance targets)
|
||||
- Unity-specific configurations (build settings, quality settings)
|
||||
- Game story modifications (scope, acceptance criteria)
|
||||
- Asset pipeline adjustments
|
||||
- Platform-specific adaptations
|
||||
|
||||
- **Draft explicit changes for each artifact:**
|
||||
|
||||
- **Game Stories:** Revise story text, Unity-specific acceptance criteria, technical constraints
|
||||
- **Technical Specs:** Update architecture diagrams, component hierarchies, performance budgets
|
||||
- **Unity Configurations:** Propose settings changes, optimization strategies, platform variants
|
||||
- **GDD Updates:** Modify feature descriptions, balance parameters, progression systems
|
||||
- **Asset Specifications:** Adjust texture sizes, model complexity, audio compression
|
||||
- **Performance Targets:** Update FPS goals, memory limits, load time requirements
|
||||
|
||||
- **Include Unity-specific details:**
|
||||
- Prefab structure changes
|
||||
- Scene organization updates
|
||||
- Component refactoring needs
|
||||
- Shader/material optimizations
|
||||
- Build pipeline modifications
|
||||
|
||||
### 4. Generate "Game Development Change Proposal"
|
||||
|
||||
- Create a comprehensive proposal document containing:
|
||||
|
||||
**A. Change Summary:**
|
||||
|
||||
- Original issue (performance, gameplay, technical constraint)
|
||||
- Game systems affected
|
||||
- Platform/performance implications
|
||||
- Chosen solution approach
|
||||
|
||||
**B. Technical Impact Analysis:**
|
||||
|
||||
- Unity architecture changes needed
|
||||
- Performance implications (with metrics)
|
||||
- Platform compatibility effects
|
||||
- Asset pipeline modifications
|
||||
- Third-party dependency impacts
|
||||
|
||||
**C. Specific Proposed Edits:**
|
||||
|
||||
- For each game story: "Change Story GS-X.Y from: [old] To: [new]"
|
||||
- For technical specs: "Update Unity Architecture Section X: [changes]"
|
||||
- For GDD: "Modify [Feature] in Section Y: [updates]"
|
||||
- For configurations: "Change [Setting] from [old_value] to [new_value]"
|
||||
|
||||
**D. Implementation Considerations:**
|
||||
|
||||
- Required Unity version updates
|
||||
- Asset reimport needs
|
||||
- Shader recompilation requirements
|
||||
- Platform-specific testing needs
|
||||
|
||||
### 5. Finalize & Determine Next Steps
|
||||
|
||||
- Obtain explicit approval for the "Game Development Change Proposal"
|
||||
- Provide the finalized document to the user
|
||||
|
||||
- **Based on change scope:**
|
||||
|
||||
- **Minor adjustments (can be handled in current sprint):**
|
||||
- Confirm task completion
|
||||
- Suggest handoff to game-dev agent for implementation
|
||||
- Note any required playtesting validation
|
||||
- **Major changes (require replanning):**
|
||||
- Clearly state need for deeper technical review
|
||||
- Recommend engaging Game Architect or Technical Lead
|
||||
- Provide proposal as input for architecture revision
|
||||
- Flag any milestone/deadline impacts
|
||||
|
||||
## Output Deliverables
|
||||
|
||||
- **Primary:** "Game Development Change Proposal" document containing:
|
||||
|
||||
- Game-specific change analysis
|
||||
- Technical impact assessment with Unity context
|
||||
- Platform and performance considerations
|
||||
- Clearly drafted updates for all affected game artifacts
|
||||
- Implementation guidance and constraints
|
||||
|
||||
- **Secondary:** Annotated game-change-checklist showing:
|
||||
- Technical decisions made
|
||||
- Performance trade-offs considered
|
||||
- Platform-specific accommodations
|
||||
- Unity-specific implementation notes
|
||||
@@ -1,217 +1,184 @@
|
||||
# Create Game Development Story Task
|
||||
# Create Game Story Task
|
||||
|
||||
## Purpose
|
||||
|
||||
Create detailed, actionable game development stories that enable AI developers to implement specific game features in Unity without requiring additional design decisions.
|
||||
To identify the next logical game story based on project progress and epic definitions, and then to prepare a comprehensive, self-contained, and actionable story file using the `Game Story Template`. This task ensures the story is enriched with all necessary technical context, Unity-specific requirements, and acceptance criteria, making it ready for efficient implementation by a Game Developer Agent with minimal need for additional research or finding its own context.
|
||||
|
||||
## When to Use
|
||||
## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
|
||||
|
||||
- Breaking down game epics into implementable stories
|
||||
- Converting GDD features into development tasks
|
||||
- Preparing work for game developers
|
||||
- Ensuring clear handoffs from design to development
|
||||
### 0. Load Core Configuration and Check Workflow
|
||||
|
||||
## Prerequisites
|
||||
- Load `{root}/core-config.yaml` from the project root
|
||||
- If the file does not exist, HALT and inform the user: "core-config.yaml not found. This file is required for story creation. You can either: 1) Copy core-config.yaml from GITHUB bmad-core/ and configure it for your game project OR 2) Run the BMad installer against your project to upgrade and add the file automatically. Please add and configure before proceeding."
|
||||
- Extract key configurations: `devStoryLocation`, `gdd.*`, `gamearchitecture.*`, `workflow.*`
|
||||
|
||||
Before creating stories, ensure you have:
|
||||
### 1. Identify Next Story for Preparation
|
||||
|
||||
- Completed Game Design Document (GDD)
|
||||
- Game Architecture Document
|
||||
- Epic definition this story belongs to
|
||||
- Clear understanding of the specific game feature
|
||||
#### 1.1 Locate Epic Files and Review Existing Stories
|
||||
|
||||
## Process
|
||||
- Based on `gddSharded` from config, locate epic files (sharded location/pattern or monolithic GDD sections)
|
||||
- If `devStoryLocation` has story files, load the highest `{epicNum}.{storyNum}.story.md` file
|
||||
- **If highest story exists:**
|
||||
- Verify status is 'Done'. If not, alert user: "ALERT: Found incomplete story! File: {lastEpicNum}.{lastStoryNum}.story.md Status: [current status] You should fix this story first, but would you like to accept risk & override to create the next story in draft?"
|
||||
- If proceeding, select next sequential story in the current epic
|
||||
- If epic is complete, prompt user: "Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed. Would you like to: 1) Begin Epic {epicNum + 1} with story 1 2) Select a specific story to work on 3) Cancel story creation"
|
||||
- **CRITICAL**: NEVER automatically skip to another epic. User MUST explicitly instruct which story to create.
|
||||
- **If no story files exist:** The next story is ALWAYS 1.1 (first story of first epic)
|
||||
- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}"
|
||||
|
||||
### 1. Story Identification
|
||||
### 2. Gather Story Requirements and Previous Story Context
|
||||
|
||||
**Review Epic Context:**
|
||||
- Extract story requirements from the identified epic file or GDD section
|
||||
- If previous story exists, review Dev Agent Record sections for:
|
||||
- Completion Notes and Debug Log References
|
||||
- Implementation deviations and technical decisions
|
||||
- Unity-specific challenges (prefab issues, scene management, performance)
|
||||
- Asset pipeline decisions and optimizations
|
||||
- Extract relevant insights that inform the current story's preparation
|
||||
|
||||
- Understand the epic's overall goal
|
||||
- Identify specific features that need implementation
|
||||
- Review any existing stories in the epic
|
||||
- Ensure no duplicate work
|
||||
### 3. Gather Architecture Context
|
||||
|
||||
**Feature Analysis:**
|
||||
#### 3.1 Determine Architecture Reading Strategy
|
||||
|
||||
- Reference specific GDD sections
|
||||
- Understand player experience goals
|
||||
- Identify technical complexity
|
||||
- Estimate implementation scope
|
||||
- **If `gamearchitectureVersion: >= v3` and `gamearchitectureSharded: true`**: Read `{gamearchitectureShardedLocation}/index.md` then follow structured reading order below
|
||||
- **Else**: Use monolithic `gamearchitectureFile` for similar sections
|
||||
|
||||
### 2. Story Scoping
|
||||
#### 3.2 Read Architecture Documents Based on Story Type
|
||||
|
||||
**Single Responsibility:**
|
||||
**For ALL Game Stories:** tech-stack.md, unity-project-structure.md, coding-standards.md, testing-resilience-architecture.md
|
||||
|
||||
- Focus on one specific game feature
|
||||
- Ensure story is completable in 1-3 days
|
||||
- Break down complex features into multiple stories
|
||||
- Maintain clear boundaries with other stories
|
||||
**For Gameplay/Mechanics Stories, additionally:** gameplay-systems-architecture.md, component-architecture-details.md, physics-config.md, input-system.md, state-machines.md, game-data-models.md
|
||||
|
||||
**Implementation Clarity:**
|
||||
**For UI/UX Stories, additionally:** ui-architecture.md, ui-components.md, ui-state-management.md, scene-management.md
|
||||
|
||||
- Define exactly what needs to be built
|
||||
- Specify all technical requirements
|
||||
- Include all necessary integration points
|
||||
- Provide clear success criteria
|
||||
**For Backend/Services Stories, additionally:** game-data-models.md, data-persistence.md, save-system.md, analytics-integration.md, multiplayer-architecture.md
|
||||
|
||||
### 3. Template Execution
|
||||
**For Graphics/Rendering Stories, additionally:** rendering-pipeline.md, shader-guidelines.md, sprite-management.md, particle-systems.md
|
||||
|
||||
**Load Template:**
|
||||
Use `templates#game-story-tmpl` following all embedded LLM instructions
|
||||
**For Audio Stories, additionally:** audio-architecture.md, audio-mixing.md, sound-banks.md
|
||||
|
||||
**Key Focus Areas:**
|
||||
#### 3.3 Extract Story-Specific Technical Details
|
||||
|
||||
- Clear, actionable description
|
||||
- Specific acceptance criteria
|
||||
- Detailed technical specifications
|
||||
- Complete implementation task list
|
||||
- Comprehensive testing requirements
|
||||
Extract ONLY information directly relevant to implementing the current story. Do NOT invent new patterns, systems, or standards not in the source documents.
|
||||
|
||||
### 4. Story Validation
|
||||
Extract:
|
||||
|
||||
**Technical Review:**
|
||||
- Specific Unity components and MonoBehaviours the story will use
|
||||
- Unity Package Manager dependencies and their APIs (e.g., Cinemachine, Input System, URP)
|
||||
- Package-specific configurations and setup requirements
|
||||
- Prefab structures and scene organization requirements
|
||||
- Input system bindings and configurations
|
||||
- Physics settings and collision layers
|
||||
- UI canvas and layout specifications
|
||||
- Asset naming conventions and folder structures
|
||||
- Performance budgets (target FPS, memory limits, draw calls)
|
||||
- Platform-specific considerations (mobile vs desktop)
|
||||
- Testing requirements specific to Unity features
|
||||
|
||||
- Verify all technical specifications are complete
|
||||
- Ensure integration points are clearly defined
|
||||
- Confirm file paths match architecture
|
||||
- Validate C# interfaces and classes
|
||||
- Check for proper use of prefabs and scenes
|
||||
ALWAYS cite source documents: `[Source: gamearchitecture/{filename}.md#{section}]`
|
||||
|
||||
**Game Design Alignment:**
|
||||
### 4. Unity-Specific Technical Analysis
|
||||
|
||||
- Confirm story implements GDD requirements
|
||||
- Verify player experience goals are met
|
||||
- Check balance parameters are included
|
||||
- Ensure game mechanics are correctly interpreted
|
||||
#### 4.1 Package Dependencies Analysis
|
||||
|
||||
**Implementation Readiness:**
|
||||
- Identify Unity Package Manager packages required for the story
|
||||
- Document package versions from manifest.json
|
||||
- Note any package-specific APIs or components being used
|
||||
- List package configuration requirements (e.g., Input System settings, URP asset config)
|
||||
- Identify any third-party Asset Store packages and their integration points
|
||||
|
||||
- All dependencies identified
|
||||
- Assets requirements specified
|
||||
- Testing criteria defined
|
||||
- Definition of Done complete
|
||||
#### 4.2 Scene and Prefab Planning
|
||||
|
||||
### 5. Quality Assurance
|
||||
- Identify which scenes will be modified or created
|
||||
- List prefabs that need to be created or updated
|
||||
- Document prefab variant requirements
|
||||
- Specify scene loading/unloading requirements
|
||||
|
||||
**Apply Checklist:**
|
||||
Execute `checklists#game-story-dod-checklist` against completed story
|
||||
#### 4.3 Component Architecture
|
||||
|
||||
**Story Criteria:**
|
||||
- Define MonoBehaviour scripts needed
|
||||
- Specify ScriptableObject assets required
|
||||
- Document component dependencies and execution order
|
||||
- Identify required Unity Events and UnityActions
|
||||
- Note any package-specific components (e.g., Cinemachine VirtualCamera, InputActionAsset)
|
||||
|
||||
- Story is immediately actionable
|
||||
- No design decisions left to developer
|
||||
- Technical requirements are complete
|
||||
- Testing requirements are comprehensive
|
||||
- Performance requirements are specified
|
||||
#### 4.4 Asset Requirements
|
||||
|
||||
### 6. Story Refinement
|
||||
- List sprite/texture requirements with resolution specs
|
||||
- Define animation clips and animator controllers needed
|
||||
- Specify audio clips and their import settings
|
||||
- Document any shader or material requirements
|
||||
- Note any package-specific assets (e.g., URP materials, Input Action maps)
|
||||
|
||||
**Developer Perspective:**
|
||||
### 5. Populate Story Template with Full Context
|
||||
|
||||
- Can a developer start implementation immediately?
|
||||
- Are all technical questions answered?
|
||||
- Is the scope appropriate for the estimated points?
|
||||
- Are all dependencies clearly identified?
|
||||
- Create new story file: `{devStoryLocation}/{epicNum}.{storyNum}.story.md` using Game Story Template
|
||||
- Fill in basic story information: Title, Status (Draft), Story statement, Acceptance Criteria from Epic/GDD
|
||||
- **`Dev Notes` section (CRITICAL):**
|
||||
- CRITICAL: This section MUST contain ONLY information extracted from gamearchitecture documents and GDD. NEVER invent or assume technical details.
|
||||
- Include ALL relevant technical details from Steps 2-4, organized by category:
|
||||
- **Previous Story Insights**: Key learnings from previous story implementation
|
||||
- **Package Dependencies**: Unity packages required, versions, configurations [with source references]
|
||||
- **Unity Components**: Specific MonoBehaviours, ScriptableObjects, systems [with source references]
|
||||
- **Scene & Prefab Specs**: Scene modifications, prefab structures, variants [with source references]
|
||||
- **Input Configuration**: Input actions, bindings, control schemes [with source references]
|
||||
- **UI Implementation**: Canvas setup, layout groups, UI events [with source references]
|
||||
- **Asset Pipeline**: Asset requirements, import settings, optimization notes
|
||||
- **Performance Targets**: FPS targets, memory budgets, profiler metrics
|
||||
- **Platform Considerations**: Mobile vs desktop differences, input variations
|
||||
- **Testing Requirements**: PlayMode tests, Unity Test Framework specifics
|
||||
- Every technical detail MUST include its source reference: `[Source: gamearchitecture/{filename}.md#{section}]`
|
||||
- If information for a category is not found in the gamearchitecture docs, explicitly state: "No specific guidance found in gamearchitecture docs"
|
||||
- **`Tasks / Subtasks` section:**
|
||||
- Generate detailed, sequential list of technical tasks based ONLY on: Epic/GDD Requirements, Story AC, Reviewed GameArchitecture Information
|
||||
- Include Unity-specific tasks:
|
||||
- Scene setup and configuration
|
||||
- Prefab creation and testing
|
||||
- Component implementation with proper lifecycle methods
|
||||
- Input system integration
|
||||
- Physics configuration
|
||||
- UI implementation with proper anchoring
|
||||
- Performance profiling checkpoints
|
||||
- Each task must reference relevant gamearchitecture documentation
|
||||
- Include PlayMode testing as explicit subtasks
|
||||
- Link tasks to ACs where applicable (e.g., `Task 1 (AC: 1, 3)`)
|
||||
- Add notes on Unity project structure alignment or discrepancies found in Step 4
|
||||
|
||||
**Iterative Improvement:**
|
||||
### 6. Story Draft Completion and Review
|
||||
|
||||
- Address any gaps or ambiguities
|
||||
- Clarify complex technical requirements
|
||||
- Ensure story fits within epic scope
|
||||
- Verify story points estimation
|
||||
- Review all sections for completeness and accuracy
|
||||
- Verify all source references are included for technical details
|
||||
- Ensure Unity-specific requirements are comprehensive:
|
||||
- All scenes and prefabs documented
|
||||
- Component dependencies clear
|
||||
- Asset requirements specified
|
||||
- Performance targets defined
|
||||
- Update status to "Draft" and save the story file
|
||||
- Execute `{root}/tasks/execute-checklist` `{root}/checklists/game-story-dod-checklist`
|
||||
- Provide summary to user including:
|
||||
- Story created: `{devStoryLocation}/{epicNum}.{storyNum}.story.md`
|
||||
- Status: Draft
|
||||
- Key Unity components and systems included
|
||||
- Scene/prefab modifications required
|
||||
- Asset requirements identified
|
||||
- Any deviations or conflicts noted between GDD and gamearchitecture
|
||||
- Checklist Results
|
||||
- Next steps: For complex Unity features, suggest the user review the story draft and optionally test critical assumptions in Unity Editor
|
||||
|
||||
## Story Elements Checklist
|
||||
### 7. Unity-Specific Validation
|
||||
|
||||
### Required Sections
|
||||
Before finalizing, ensure:
|
||||
|
||||
- [ ] Clear, specific description
|
||||
- [ ] Complete acceptance criteria (functional, technical, game design)
|
||||
- [ ] Detailed technical specifications
|
||||
- [ ] File creation/modification list
|
||||
- [ ] C# interfaces and classes
|
||||
- [ ] Integration point specifications
|
||||
- [ ] Ordered implementation tasks
|
||||
- [ ] Comprehensive testing requirements
|
||||
- [ ] Performance criteria
|
||||
- [ ] Dependencies clearly identified
|
||||
- [ ] Definition of Done checklist
|
||||
- [ ] All required Unity packages are documented with versions
|
||||
- [ ] Package-specific APIs and configurations are included
|
||||
- [ ] All MonoBehaviour lifecycle methods are considered
|
||||
- [ ] Prefab workflows are clearly defined
|
||||
- [ ] Scene management approach is specified
|
||||
- [ ] Input system integration is complete (legacy or new Input System)
|
||||
- [ ] UI canvas setup follows Unity best practices
|
||||
- [ ] Performance profiling points are identified
|
||||
- [ ] Asset import settings are documented
|
||||
- [ ] Platform-specific code paths are noted
|
||||
- [ ] Package compatibility is verified (e.g., URP vs Built-in pipeline)
|
||||
|
||||
### Game-Specific Requirements
|
||||
|
||||
- [ ] GDD section references
|
||||
- [ ] Game mechanic implementation details
|
||||
- [ ] Player experience goals
|
||||
- [ ] Balance parameters
|
||||
- [ ] Unity-specific requirements (components, prefabs, scenes)
|
||||
- [ ] Performance targets (stable frame rate)
|
||||
- [ ] Cross-platform considerations
|
||||
|
||||
### Technical Quality
|
||||
|
||||
- [ ] C# best practices compliance
|
||||
- [ ] Architecture document alignment
|
||||
- [ ] Code organization follows standards
|
||||
- [ ] Error handling requirements
|
||||
- [ ] Memory management considerations
|
||||
- [ ] Testing strategy defined
|
||||
|
||||
## Common Pitfalls
|
||||
|
||||
**Scope Issues:**
|
||||
|
||||
- Story too large (break into multiple stories)
|
||||
- Story too vague (add specific requirements)
|
||||
- Missing dependencies (identify all prerequisites)
|
||||
- Unclear boundaries (define what's in/out of scope)
|
||||
|
||||
**Technical Issues:**
|
||||
|
||||
- Missing integration details
|
||||
- Incomplete technical specifications
|
||||
- Undefined interfaces or classes
|
||||
- Missing performance requirements
|
||||
|
||||
**Game Design Issues:**
|
||||
|
||||
- Not referencing GDD properly
|
||||
- Missing player experience context
|
||||
- Unclear game mechanic implementation
|
||||
- Missing balance parameters
|
||||
|
||||
## Success Criteria
|
||||
|
||||
**Story Readiness:**
|
||||
|
||||
- [ ] Developer can start implementation immediately
|
||||
- [ ] No additional design decisions required
|
||||
- [ ] All technical questions answered
|
||||
- [ ] Testing strategy is complete
|
||||
- [ ] Performance requirements are clear
|
||||
- [ ] Story fits within epic scope
|
||||
|
||||
**Quality Validation:**
|
||||
|
||||
- [ ] Game story DOD checklist passes
|
||||
- [ ] Architecture alignment confirmed
|
||||
- [ ] GDD requirements covered
|
||||
- [ ] Implementation tasks are ordered and specific
|
||||
- [ ] Dependencies are complete and accurate
|
||||
|
||||
## Handoff Protocol
|
||||
|
||||
**To Game Developer:**
|
||||
|
||||
1. Provide story document
|
||||
2. Confirm GDD and architecture access
|
||||
3. Verify all dependencies are met
|
||||
4. Answer any clarification questions
|
||||
5. Establish check-in schedule
|
||||
|
||||
**Story Status Updates:**
|
||||
|
||||
- Draft → Ready for Development
|
||||
- In Development → Code Review
|
||||
- Code Review → Testing
|
||||
- Testing → Done
|
||||
|
||||
This task ensures game development stories are immediately actionable and enable efficient AI-driven development of game features in Unity.
|
||||
This task ensures game development stories are immediately actionable and enable efficient AI-driven development of Unity 2D game features.
|
||||
|
||||
@@ -0,0 +1,200 @@
|
||||
# Validate Game Story Task
|
||||
|
||||
## Purpose
|
||||
|
||||
To comprehensively validate a Unity 2D game development story draft before implementation begins, ensuring it contains all necessary Unity-specific technical context, game development requirements, and implementation details. This specialized validation prevents hallucinations, ensures Unity development readiness, and validates game-specific acceptance criteria and testing approaches.
|
||||
|
||||
## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
|
||||
|
||||
### 0. Load Core Configuration and Inputs
|
||||
|
||||
- Load `{root}/core-config.yaml` from the project root
|
||||
- If the file does not exist, HALT and inform the user: "core-config.yaml not found. This file is required for story validation."
|
||||
- Extract key configurations: `devStoryLocation`, `gdd.*`, `gamearchitecture.*`, `workflow.*`
|
||||
- Identify and load the following inputs:
|
||||
- **Story file**: The drafted game story to validate (provided by user or discovered in `devStoryLocation`)
|
||||
- **Parent epic**: The epic containing this story's requirements from GDD
|
||||
- **Architecture documents**: Based on configuration (sharded or monolithic)
|
||||
- **Game story template**: `expansion-packs/bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml` for completeness validation
|
||||
|
||||
### 1. Game Story Template Completeness Validation
|
||||
|
||||
- Load `expansion-packs/bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml` and extract all required sections
|
||||
- **Missing sections check**: Compare story sections against game story template sections to verify all Unity-specific sections are present:
|
||||
- Unity Technical Context
|
||||
- Component Architecture
|
||||
- Scene & Prefab Requirements
|
||||
- Asset Dependencies
|
||||
- Performance Requirements
|
||||
- Platform Considerations
|
||||
- Integration Points
|
||||
- Testing Strategy (Unity Test Framework)
|
||||
- **Placeholder validation**: Ensure no template placeholders remain unfilled (e.g., `{{EpicNum}}`, `{{StoryNum}}`, `{{GameMechanic}}`, `_TBD_`)
|
||||
- **Game-specific sections**: Verify presence of Unity development specific sections
|
||||
- **Structure compliance**: Verify story follows game story template structure and formatting
|
||||
|
||||
### 2. Unity Project Structure and Asset Validation
|
||||
|
||||
- **Unity file paths clarity**: Are Unity-specific paths clearly specified (Assets/, Scripts/, Prefabs/, Scenes/, etc.)?
|
||||
- **Package dependencies**: Are required Unity packages identified and version-locked?
|
||||
- **Scene structure relevance**: Is relevant scene hierarchy and GameObject structure included?
|
||||
- **Prefab organization**: Are prefab creation/modification requirements clearly specified?
|
||||
- **Asset pipeline**: Are sprite imports, animation controllers, and audio assets properly planned?
|
||||
- **Directory structure**: Do new Unity assets follow project structure according to architecture docs?
|
||||
- **ScriptableObject requirements**: Are data containers and configuration objects identified?
|
||||
- **Namespace compliance**: Are C# namespaces following project conventions?
|
||||
|
||||
### 3. Unity Component Architecture Validation
|
||||
|
||||
- **MonoBehaviour specifications**: Are Unity component classes sufficiently detailed for implementation?
|
||||
- **Component dependencies**: Are Unity component interdependencies clearly mapped?
|
||||
- **Unity lifecycle usage**: Are Start(), Update(), Awake() methods appropriately planned?
|
||||
- **Event system integration**: Are UnityEvents, C# events, or custom messaging systems specified?
|
||||
- **Serialization requirements**: Are [SerializeField] and public field requirements clear?
|
||||
- **Component interfaces**: Are required interfaces and abstract base classes defined?
|
||||
- **Performance considerations**: Are component update patterns optimized (Update vs FixedUpdate vs coroutines)?
|
||||
|
||||
### 4. Game Mechanics and Systems Validation
|
||||
|
||||
- **Core loop integration**: Does the story properly integrate with established game core loop?
|
||||
- **Player input handling**: Are input mappings and input system requirements specified?
|
||||
- **Game state management**: Are state transitions and persistence requirements clear?
|
||||
- **UI/UX integration**: Are Canvas setup, UI components, and player feedback systems defined?
|
||||
- **Audio integration**: Are AudioSource, AudioMixer, and sound effect requirements specified?
|
||||
- **Animation systems**: Are Animator Controllers, Animation Clips, and transition requirements clear?
|
||||
- **Physics integration**: Are Rigidbody2D, Collider2D, and physics material requirements specified?
|
||||
|
||||
### 5. Unity-Specific Acceptance Criteria Assessment
|
||||
|
||||
- **Functional testing**: Can all acceptance criteria be tested within Unity's Play Mode?
|
||||
- **Visual validation**: Are visual/aesthetic acceptance criteria measurable and testable?
|
||||
- **Performance criteria**: Are frame rate, memory usage, and build size criteria specified?
|
||||
- **Platform compatibility**: Are mobile vs desktop specific acceptance criteria addressed?
|
||||
- **Input validation**: Are different input methods (touch, keyboard, gamepad) covered?
|
||||
- **Audio criteria**: Are audio mixing levels, sound trigger timing, and audio quality specified?
|
||||
- **Animation validation**: Are animation smoothness, timing, and visual polish criteria defined?
|
||||
|
||||
### 6. Unity Testing and Validation Instructions Review
|
||||
|
||||
- **Unity Test Framework**: Are EditMode and PlayMode test approaches clearly specified?
|
||||
- **Performance profiling**: Are Unity Profiler usage and performance benchmarking steps defined?
|
||||
- **Build testing**: Are build process validation steps for target platforms specified?
|
||||
- **Scene testing**: Are scene loading, unloading, and transition testing approaches clear?
|
||||
- **Asset validation**: Are texture compression, audio compression, and asset optimization tests defined?
|
||||
- **Platform testing**: Are device-specific testing requirements (mobile performance, input methods) specified?
|
||||
- **Memory leak testing**: Are Unity memory profiling and leak detection steps included?
|
||||
|
||||
### 7. Unity Performance and Optimization Validation
|
||||
|
||||
- **Frame rate targets**: Are target FPS requirements clearly specified for different platforms?
|
||||
- **Memory budgets**: Are texture memory, audio memory, and runtime memory limits defined?
|
||||
- **Draw call optimization**: Are batching strategies and draw call reduction approaches specified?
|
||||
- **Mobile performance**: Are mobile-specific performance considerations (battery, thermal) addressed?
|
||||
- **Asset optimization**: Are texture compression, audio compression, and mesh optimization requirements clear?
|
||||
- **Garbage collection**: Are GC-friendly coding patterns and object pooling requirements specified?
|
||||
- **Loading time targets**: Are scene loading and asset streaming performance requirements defined?
|
||||
|
||||
### 8. Unity Security and Platform Considerations (if applicable)
|
||||
|
||||
- **Platform store requirements**: Are app store guidelines and submission requirements addressed?
|
||||
- **Data privacy**: Are player data storage and analytics integration requirements specified?
|
||||
- **Platform integration**: Are platform-specific features (achievements, leaderboards) requirements clear?
|
||||
- **Content filtering**: Are age rating and content appropriateness considerations addressed?
|
||||
- **Anti-cheat considerations**: Are client-side validation and server communication security measures specified?
|
||||
- **Build security**: Are code obfuscation and asset protection requirements defined?
|
||||
|
||||
### 9. Unity Development Task Sequence Validation
|
||||
|
||||
- **Unity workflow order**: Do tasks follow proper Unity development sequence (prefabs before scenes, scripts before UI)?
|
||||
- **Asset creation dependencies**: Are asset creation tasks properly ordered (sprites before animations, audio before mixers)?
|
||||
- **Component dependencies**: Are script dependencies clear and implementation order logical?
|
||||
- **Testing integration**: Are Unity test creation and execution properly sequenced with development tasks?
|
||||
- **Build integration**: Are build process tasks appropriately placed in development sequence?
|
||||
- **Platform deployment**: Are platform-specific build and deployment tasks properly sequenced?
|
||||
|
||||
### 10. Unity Anti-Hallucination Verification
|
||||
|
||||
- **Unity API accuracy**: Every Unity API reference must be verified against current Unity documentation
|
||||
- **Package version verification**: All Unity package references must specify valid versions
|
||||
- **Component architecture alignment**: Unity component relationships must match architecture specifications
|
||||
- **Performance claims verification**: All performance targets must be realistic and based on platform capabilities
|
||||
- **Asset pipeline accuracy**: All asset import settings and pipeline configurations must be valid
|
||||
- **Platform capability verification**: All platform-specific features must be verified as available on target platforms
|
||||
|
||||
### 11. Unity Development Agent Implementation Readiness
|
||||
|
||||
- **Unity context completeness**: Can the story be implemented without consulting external Unity documentation?
|
||||
- **Technical specification clarity**: Are all Unity-specific implementation details unambiguous?
|
||||
- **Asset requirements clarity**: Are all required assets, their specifications, and import settings clearly defined?
|
||||
- **Component relationship clarity**: Are all Unity component interactions and dependencies explicitly defined?
|
||||
- **Testing approach completeness**: Are Unity-specific testing approaches fully specified and actionable?
|
||||
- **Performance validation readiness**: Are all performance testing and optimization approaches clearly defined?
|
||||
|
||||
### 12. Generate Unity Game Story Validation Report
|
||||
|
||||
Provide a structured validation report including:
|
||||
|
||||
#### Game Story Template Compliance Issues
|
||||
|
||||
- Missing Unity-specific sections from game story template
|
||||
- Unfilled placeholders or template variables specific to game development
|
||||
- Missing Unity component specifications or asset requirements
|
||||
- Structural formatting issues in game-specific sections
|
||||
|
||||
#### Critical Unity Issues (Must Fix - Story Blocked)
|
||||
|
||||
- Missing essential Unity technical information for implementation
|
||||
- Inaccurate or unverifiable Unity API references or package dependencies
|
||||
- Incomplete game mechanics or systems integration
|
||||
- Missing required Unity testing framework specifications
|
||||
- Performance requirements that are unrealistic or unmeasurable
|
||||
|
||||
#### Unity-Specific Should-Fix Issues (Important Quality Improvements)
|
||||
|
||||
- Unclear Unity component architecture or dependency relationships
|
||||
- Missing platform-specific performance considerations
|
||||
- Incomplete asset pipeline specifications or optimization requirements
|
||||
- Task sequencing problems specific to Unity development workflow
|
||||
- Missing Unity Test Framework integration or testing approaches
|
||||
|
||||
#### Game Development Nice-to-Have Improvements (Optional Enhancements)
|
||||
|
||||
- Additional Unity performance optimization context
|
||||
- Enhanced asset creation guidance and best practices
|
||||
- Clarifications for Unity-specific development patterns
|
||||
- Additional platform compatibility considerations
|
||||
- Enhanced debugging and profiling guidance
|
||||
|
||||
#### Unity Anti-Hallucination Findings
|
||||
|
||||
- Unverifiable Unity API claims or outdated Unity references
|
||||
- Missing Unity package version specifications
|
||||
- Inconsistencies with Unity project architecture documents
|
||||
- Invented Unity components, packages, or development patterns
|
||||
- Unrealistic performance claims or platform capability assumptions
|
||||
|
||||
#### Unity Platform and Performance Validation
|
||||
|
||||
- **Mobile Performance Assessment**: Frame rate targets, memory usage, and thermal considerations
|
||||
- **Platform Compatibility Check**: Input methods, screen resolutions, and platform-specific features
|
||||
- **Asset Pipeline Validation**: Texture compression, audio formats, and build size considerations
|
||||
- **Unity Version Compliance**: Compatibility with specified Unity version and package versions
|
||||
|
||||
#### Final Unity Game Development Assessment
|
||||
|
||||
- **GO**: Story is ready for Unity implementation with all technical context
|
||||
- **NO-GO**: Story requires Unity-specific fixes before implementation
|
||||
- **Unity Implementation Readiness Score**: 1-10 scale based on Unity technical completeness
|
||||
- **Game Development Confidence Level**: High/Medium/Low for successful Unity implementation
|
||||
- **Platform Deployment Readiness**: Assessment of multi-platform deployment preparedness
|
||||
- **Performance Optimization Readiness**: Assessment of performance testing and optimization preparedness
|
||||
|
||||
#### Recommended Next Steps
|
||||
|
||||
Based on validation results, provide specific recommendations for:
|
||||
|
||||
- Unity technical documentation improvements needed
|
||||
- Asset creation or acquisition requirements
|
||||
- Performance testing and profiling setup requirements
|
||||
- Platform-specific development environment setup needs
|
||||
- Unity Test Framework implementation recommendations
|
||||
Reference in New Issue
Block a user