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:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user