ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity

Built dist for web bundle

This commit is contained in:
pbean 2025-07-22 00:36:27 -07:00
parent b56833e73e
commit 5409b17c1e
9 changed files with 44996 additions and 3466 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3836
dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-architect.txt vendored Normal file
View File

File diff suppressed because it is too large Load Diff

641
dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt vendored
View File

@ -62,23 +62,23 @@ persona:
style: Creative, player-focused, systematic, data-informed
identity: Visionary who creates compelling game experiences through thoughtful design and player psychology understanding
focus: Defining engaging gameplay systems, balanced progression, and clear development requirements for implementation teams
core_principles:
core_principles:
- Player-First Design - Every mechanic serves player engagement and fun
- Checklist-Driven Validation - Apply game-design-checklist meticulously
- Document Everything - Clear specifications enable proper development
- Iterative Design - Prototype, test, refine approach to all systems
- Technical Awareness - Design within feasible implementation constraints
- Data-Driven Decisions - Use metrics and feedback to guide design choices
- Numbered Options Protocol - Always use numbered lists for user selections
- Numbered Options Protocol - Always use numbered lists for selections
commands:
- '*help" - Show numbered list of available commands for selection'
- '*chat-mode" - Conversational mode with advanced-elicitation for design advice'
- '*create" - Show numbered list of documents I can create (from templates below)'
- '*brainstorm {topic}" - Facilitate structured game design brainstorming session'
- '*research {topic}" - Generate deep research prompt for game-specific investigation'
- '*elicit" - Run advanced elicitation to clarify game design requirements'
- '*checklist {checklist}" - Show numbered list of checklists, execute selection'
- '*exit" - Say goodbye as the Game Designer, and then abandon inhabiting this persona'
- help: Show numbered list of available commands for selection
- chat-mode: Conversational mode with advanced-elicitation for design advice
- create: Show numbered list of documents I can create (from templates below)
- brainstorm {topic}: Facilitate structured game design brainstorming session
- research {topic}: Generate deep research prompt for game-specific investigation
- elicit: Run advanced elicitation to clarify game design requirements
- checklist {checklist}: Show numbered list of checklists, execute selection
- exit: Say goodbye as the Game Designer, and then abandon inhabiting this persona
dependencies:
tasks:
- create-doc.md
@ -1014,88 +1014,130 @@ The questions and perspectives offered should always consider:
==================== START: .bmad-2d-unity-game-dev/templates/game-design-doc-tmpl.yaml ====================
template:
id: game-design-doc-template-v2
id: game-design-doc-template-v3
name: Game Design Document (GDD)
version: 2.0
version: 3.0
output:
format: markdown
filename: "docs/{{game_name}}-game-design-document.md"
filename: docs/game-design-document.md
title: "{{game_title}} Game Design Document (GDD)"
workflow:
mode: interactive
elicitation: advanced-elicitation
sections:
- id: initial-setup
- id: goals-context
title: Goals and Background Context
instruction: |
This template creates a comprehensive Game Design Document that will serve as the foundation for all game development work. The GDD should be detailed enough that developers can create user stories and epics from it. Focus on gameplay systems, mechanics, and technical requirements that can be broken down into implementable features.
If available, review any provided documents or ask if any are optionally available: Project Brief, Market Research, Competitive Analysis
Ask if Project Brief document is available. If NO Project Brief exists, STRONGLY recommend creating one first using project-brief-tmpl (it provides essential foundation: problem statement, target users, success metrics, MVP scope, constraints). If user insists on GDD without brief, gather this information during Goals section. If Project Brief exists, review and use it to populate Goals (bullet list of desired game development outcomes) and Background Context (1-2 paragraphs on what game concept this will deliver and why) so we can determine what is and is not in scope for the GDD. Include Change Log table for version tracking.
sections:
- id: goals
title: Goals
type: bullet-list
instruction: Bullet list of 1 line desired outcomes the GDD will deliver if successful - game development and player experience goals
examples:
- Create an engaging 2D platformer that teaches players basic programming concepts
- Deliver a polished mobile game that runs smoothly on low-end Android devices
- Build a foundation for future expansion packs and content updates
- id: background
title: Background Context
type: paragraphs
instruction: 1-2 short paragraphs summarizing the game concept background, target audience needs, market opportunity, and what problem this game solves
- id: changelog
title: Change Log
type: table
columns: [Date, Version, Description, Author]
instruction: Track document versions and changes
- id: executive-summary
title: Executive Summary
instruction: Create a compelling overview that captures the essence of the game. Present this section first and get user feedback before proceeding.
elicit: true
sections:
- id: core-concept
title: Core Concept
instruction: 2-3 sentences that clearly describe what the game is and why players will love it
examples:
- A fast-paced 2D platformer where players manipulate gravity to solve puzzles and defeat enemies in a hand-drawn world.
- An educational puzzle game that teaches coding concepts through visual programming blocks in a fantasy adventure setting.
- id: target-audience
title: Target Audience
instruction: Define the primary and secondary audience with demographics and gaming preferences
template: |
**Primary:** {{age_range}}, {{player_type}}, {{platform_preference}}
**Secondary:** {{secondary_audience}}
examples:
- "Primary: Ages 8-16, casual mobile gamers, prefer short play sessions"
- "Secondary: Adult puzzle enthusiasts, educators looking for teaching tools"
- id: platform-technical
title: Platform & Technical Requirements
instruction: Based on the technical preferences or user input, define the target platforms
instruction: Based on the technical preferences or user input, define the target platforms and Unity-specific requirements
template: |
**Primary Platform:** {{platform}}
**Engine:** Unity & C#
**Performance Target:** Stable FPS on {{minimum_device}}
**Engine:** Unity {{unity_version}} & C#
**Performance Target:** Stable {{fps_target}} FPS on {{minimum_device}}
**Screen Support:** {{resolution_range}}
**Build Targets:** {{build_targets}}
examples:
- "Primary Platform: Mobile (iOS/Android), Engine: Unity 2022.3 LTS & C#, Performance: 60 FPS on iPhone 8/Galaxy S8"
- id: unique-selling-points
title: Unique Selling Points
instruction: List 3-5 key features that differentiate this game from competitors
type: numbered-list
template: "{{usp}}"
examples:
- Innovative gravity manipulation mechanic that affects both player and environment
- Seamless integration of educational content without compromising fun gameplay
- Adaptive difficulty system that learns from player behavior
- id: core-gameplay
title: Core Gameplay
instruction: This section defines the fundamental game mechanics. After presenting each subsection, apply `tasks#advanced-elicitation` protocol to ensure completeness.
instruction: This section defines the fundamental game mechanics. After presenting each subsection, apply advanced elicitation to ensure completeness and gather additional details.
elicit: true
sections:
- id: game-pillars
title: Game Pillars
instruction: Define 3-5 core pillars that guide all design decisions. These should be specific and actionable.
instruction: Define 3-5 core pillars that guide all design decisions. These should be specific and actionable for Unity development.
type: numbered-list
template: |
**{{pillar_name}}** - {{description}}
examples:
- Intuitive Controls - All interactions must be learnable within 30 seconds using touch or keyboard
- Immediate Feedback - Every player action provides visual and audio response within 0.1 seconds
- Progressive Challenge - Difficulty increases through mechanic complexity, not unfair timing
- id: core-gameplay-loop
title: Core Gameplay Loop
instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions.
instruction: Define the 30-60 second loop that players will repeat. Be specific about timing and player actions for Unity implementation.
template: |
**Primary Loop ({{duration}} seconds):**
1. {{action_1}} ({{time_1}}s)
2. {{action_2}} ({{time_2}}s)
3. {{action_3}} ({{time_3}}s)
4. {{reward_feedback}} ({{time_4}}s)
1. {{action_1}} ({{time_1}}s) - {{unity_component}}
2. {{action_2}} ({{time_2}}s) - {{unity_component}}
3. {{action_3}} ({{time_3}}s) - {{unity_component}}
4. {{reward_feedback}} ({{time_4}}s) - {{unity_component}}
examples:
- Observe environment (2s) - Camera Controller, Identify puzzle elements (3s) - Highlight System
- id: win-loss-conditions
title: Win/Loss Conditions
instruction: Clearly define success and failure states
instruction: Clearly define success and failure states with Unity-specific implementation notes
template: |
**Victory Conditions:**
- {{win_condition_1}}
- {{win_condition_2}}
- {{win_condition_1}} - Unity Event: {{unity_event}}
- {{win_condition_2}} - Unity Event: {{unity_event}}
**Failure States:**
- {{loss_condition_1}}
- {{loss_condition_2}}
- {{loss_condition_1}} - Trigger: {{unity_trigger}}
- {{loss_condition_2}} - Trigger: {{unity_trigger}}
examples:
- "Victory: Player reaches exit portal - Unity Event: OnTriggerEnter2D with Portal tag"
- "Failure: Health reaches zero - Trigger: Health component value <= 0"
- id: game-mechanics
title: Game Mechanics
instruction: Detail each major mechanic that will need to be implemented. Each mechanic should be specific enough for developers to create implementation stories.
instruction: Detail each major mechanic that will need Unity implementation. Each mechanic should be specific enough for developers to create C# scripts and prefabs.
elicit: true
sections:
- id: primary-mechanics
title: Primary Mechanics
@ -1106,29 +1148,41 @@ sections:
template: |
**Description:** {{detailed_description}}
**Player Input:** {{input_method}}
**Player Input:** {{input_method}} - Unity Input System: {{input_action}}
**System Response:** {{game_response}}
**Implementation Notes:**
**Unity Implementation Notes:**
- {{tech_requirement_1}}
- {{tech_requirement_2}}
- {{performance_consideration}}
- **Components Needed:** {{component_list}}
- **Physics Requirements:** {{physics_2d_setup}}
- **Animation States:** {{animator_states}}
- **Performance Considerations:** {{optimization_notes}}
**Dependencies:** {{other_mechanics_needed}}
**Script Architecture:**
- {{script_name}}.cs - {{responsibility}}
- {{manager_script}}.cs - {{management_role}}
examples:
- "Components Needed: Rigidbody2D, BoxCollider2D, PlayerMovement script"
- "Physics Requirements: 2D Physics material for ground friction, Gravity scale 3"
- id: controls
title: Controls
instruction: Define all input methods for different platforms
instruction: Define all input methods for different platforms using Unity's Input System
type: table
template: |
| Action | Desktop | Mobile | Gamepad |
| ------ | ------- | ------ | ------- |
| {{action}} | {{key}} | {{gesture}} | {{button}} |
| Action | Desktop | Mobile | Gamepad | Unity Input Action |
| ------ | ------- | ------ | ------- | ------------------ |
| {{action}} | {{key}} | {{gesture}} | {{button}} | {{input_action}} |
examples:
- Move Left, A/Left Arrow, Swipe Left, Left Stick, <Move>/x
- id: progression-balance
title: Progression & Balance
instruction: Define how players advance and how difficulty scales. This section should provide clear parameters for implementation.
instruction: Define how players advance and how difficulty scales. This section should provide clear parameters for Unity implementation and scriptable objects.
elicit: true
sections:
- id: player-progression
title: Player Progression
@ -1137,30 +1191,54 @@ sections:
**Key Milestones:**
1. **{{milestone_1}}** - {{unlock_description}}
2. **{{milestone_2}}** - {{unlock_description}}
3. **{{milestone_3}}** - {{unlock_description}}
1. **{{milestone_1}}** - {{unlock_description}} - Unity: {{scriptable_object_update}}
2. **{{milestone_2}}** - {{unlock_description}} - Unity: {{scriptable_object_update}}
3. **{{milestone_3}}** - {{unlock_description}} - Unity: {{scriptable_object_update}}
**Save Data Structure:**
```csharp
[System.Serializable]
public class PlayerProgress
{
{{progress_fields}}
}
```
examples:
- public int currentLevel, public bool[] unlockedAbilities, public float totalPlayTime
- id: difficulty-curve
title: Difficulty Curve
instruction: Provide specific parameters for balancing
instruction: Provide specific parameters for balancing that can be implemented as Unity ScriptableObjects
template: |
**Tutorial Phase:** {{duration}} - {{difficulty_description}}
- Unity Config: {{scriptable_object_values}}
**Early Game:** {{duration}} - {{difficulty_description}}
- Unity Config: {{scriptable_object_values}}
**Mid Game:** {{duration}} - {{difficulty_description}}
- Unity Config: {{scriptable_object_values}}
**Late Game:** {{duration}} - {{difficulty_description}}
- Unity Config: {{scriptable_object_values}}
examples:
- "enemy speed: 2.0f, jump height: 4.5f, obstacle density: 0.3f"
- id: economy-resources
title: Economy & Resources
condition: has_economy
instruction: Define any in-game currencies, resources, or collectibles
instruction: Define any in-game currencies, resources, or collectibles with Unity implementation details
type: table
template: |
| Resource | Earn Rate | Spend Rate | Purpose | Cap |
| -------- | --------- | ---------- | ------- | --- |
| {{resource}} | {{rate}} | {{rate}} | {{use}} | {{max}} |
| Resource | Earn Rate | Spend Rate | Purpose | Cap | Unity ScriptableObject |
| -------- | --------- | ---------- | ------- | --- | --------------------- |
| {{resource}} | {{rate}} | {{rate}} | {{use}} | {{max}} | {{so_name}} |
examples:
- Coins, 1-3 per enemy, 10-50 per upgrade, Buy abilities, 9999, CurrencyData
- id: level-design-framework
title: Level Design Framework
instruction: Provide guidelines for level creation that developers can use to create level implementation stories
instruction: Provide guidelines for level creation that developers can use to create Unity scenes and prefabs. Focus on modular design and reusable components.
elicit: true
sections:
- id: level-types
title: Level Types
@ -1170,202 +1248,413 @@ sections:
title: "{{level_type_name}}"
template: |
**Purpose:** {{gameplay_purpose}}
**Duration:** {{target_time}}
**Target Duration:** {{target_time}}
**Key Elements:** {{required_mechanics}}
**Difficulty:** {{relative_difficulty}}
**Difficulty Rating:** {{relative_difficulty}}
**Structure Template:**
**Unity Scene Structure:**
- Introduction: {{intro_description}}
- Challenge: {{main_challenge}}
- Resolution: {{completion_requirement}}
- **Environment:** {{tilemap_setup}}
- **Gameplay Objects:** {{prefab_list}}
- **Lighting:** {{lighting_setup}}
- **Audio:** {{audio_sources}}
**Level Flow Template:**
- **Introduction:** {{intro_description}} - Area: {{unity_area_bounds}}
- **Challenge:** {{main_challenge}} - Mechanics: {{active_components}}
- **Resolution:** {{completion_requirement}} - Trigger: {{completion_trigger}}
**Reusable Prefabs:**
- {{prefab_name}} - {{prefab_purpose}}
examples:
- "Environment: TilemapRenderer with Platform tileset, Lighting: 2D Global Light + Point Lights"
- id: level-progression
title: Level Progression
template: |
**World Structure:** {{linear|hub|open}}
**Total Levels:** {{number}}
**Unlock Pattern:** {{progression_method}}
**Scene Management:** {{unity_scene_loading}}
**Unity Scene Organization:**
- Scene Naming: {{naming_convention}}
- Addressable Assets: {{addressable_groups}}
- Loading Screens: {{loading_implementation}}
examples:
- "Scene Naming: World{X}_Level{Y}_Name, Addressable Groups: Levels_World1, World_Environments"
- id: technical-specifications
title: Technical Specifications
instruction: Define technical requirements that will guide architecture and implementation decisions. Review any existing technical preferences.
instruction: Define Unity-specific technical requirements that will guide architecture and implementation decisions. Reference Unity documentation and best practices.
elicit: true
choices:
render_pipeline: [Built-in, URP, HDRP]
input_system: [Legacy, New Input System, Both]
physics: [2D Only, 3D Only, Hybrid]
sections:
- id: unity-configuration
title: Unity Project Configuration
template: |
**Unity Version:** {{unity_version}} (LTS recommended)
**Render Pipeline:** {{Built-in|URP|HDRP}}
**Input System:** {{Legacy|New Input System|Both}}
**Physics:** {{2D Only|3D Only|Hybrid}}
**Scripting Backend:** {{Mono|IL2CPP}}
**API Compatibility:** {{.NET Standard 2.1|.NET Framework}}
**Required Packages:**
- {{package_name}} {{version}} - {{purpose}}
**Project Settings:**
- Color Space: {{Linear|Gamma}}
- Quality Settings: {{quality_levels}}
- Physics Settings: {{physics_config}}
examples:
- com.unity.addressables 1.20.5 - Asset loading and memory management
- "Color Space: Linear, Quality: Mobile/Desktop presets, Gravity: -20"
- id: performance-requirements
title: Performance Requirements
template: |
**Frame Rate:** Stable FPS (minimum 30 FPS on low-end devices)
**Memory Usage:** <{{memory_limit}}MB
**Frame Rate:** {{fps_target}} FPS (minimum {{min_fps}} on low-end devices)
**Memory Usage:** <{{memory_limit}}MB heap, <{{texture_memory}}MB textures
**Load Times:** <{{load_time}}s initial, <{{level_load}}s between levels
**Battery Usage:** Optimized for mobile devices
**Battery Usage:** Optimized for mobile devices - {{battery_target}} hours gameplay
**Unity Profiler Targets:**
- CPU Frame Time: <{{cpu_time}}ms
- GPU Frame Time: <{{gpu_time}}ms
- GC Allocs: <{{gc_limit}}KB per frame
- Draw Calls: <{{draw_calls}} per frame
examples:
- "60 FPS (minimum 30), CPU: <16.67ms, GPU: <16.67ms, GC: <4KB, Draws: <50"
- id: platform-specific
title: Platform Specific
title: Platform Specific Requirements
template: |
**Desktop:**
- Resolution: {{min_resolution}} - {{max_resolution}}
- Input: Keyboard, Mouse, Gamepad
- Browser: Chrome 80+, Firefox 75+, Safari 13+
- Input: Keyboard, Mouse, Gamepad ({{gamepad_support}})
- Build Target: {{desktop_targets}}
**Mobile:**
- Resolution: {{mobile_min}} - {{mobile_max}}
- Input: Touch, Tilt (optional)
- OS: iOS 13+, Android 8+
- Input: Touch, Accelerometer ({{sensor_support}})
- OS: iOS {{ios_min}}+, Android {{android_min}}+ (API {{api_level}})
- Device Requirements: {{device_specs}}
**Web (if applicable):**
- WebGL Version: {{webgl_version}}
- Browser Support: {{browser_list}}
- Compression: {{compression_format}}
examples:
- "Resolution: 1280x720 - 4K, Gamepad: Xbox/PlayStation controllers via Input System"
- id: asset-requirements
title: Asset Requirements
instruction: Define asset specifications for the art and audio teams
instruction: Define asset specifications for Unity pipeline optimization
template: |
**Visual Assets:**
**2D Art Assets:**
- Art Style: {{style_description}}
- Color Palette: {{color_specification}}
- Animation: {{animation_requirements}}
- UI Resolution: {{ui_specs}}
- Sprites: {{sprite_resolution}} at {{ppu}} PPU
- Texture Format: {{texture_compression}}
- Atlas Strategy: {{sprite_atlas_setup}}
- Animation: {{animation_type}} at {{framerate}} FPS
**Audio Assets:**
- Music Style: {{music_genre}}
- Sound Effects: {{sfx_requirements}}
- Voice Acting: {{voice_needs}}
- Music: {{audio_format}} at {{sample_rate}} Hz
- SFX: {{sfx_format}} at {{sfx_sample_rate}} Hz
- Compression: {{audio_compression}}
- 3D Audio: {{spatial_audio}}
**UI Assets:**
- Canvas Resolution: {{ui_resolution}}
- UI Scale Mode: {{scale_mode}}
- Font: {{font_requirements}}
- Icon Sizes: {{icon_specifications}}
examples:
- "Sprites: 32x32 to 256x256 at 16 PPU, Format: RGBA32 for quality/RGBA16 for performance"
- id: technical-architecture-requirements
title: Technical Architecture Requirements
instruction: Define high-level technical requirements that the game architecture must support
instruction: Define high-level Unity architecture patterns and systems that the game must support. Focus on scalability and maintainability.
elicit: true
choices:
architecture_pattern: [MVC, MVVM, ECS, Component-Based]
save_system: [PlayerPrefs, JSON, Binary, Cloud]
audio_system: [Unity Audio, FMOD, Wwise]
sections:
- id: engine-configuration
title: Engine Configuration
template: |
**Unity Setup:**
- C#: Latest stable version
- Physics: 2D Physics
- Renderer: 2D Renderer (URP)
- Input System: New Input System
- id: code-architecture
title: Code Architecture
title: Code Architecture Pattern
template: |
**Required Systems:**
**Architecture Pattern:** {{MVC|MVVM|ECS|Component-Based|Custom}}
- Scene Management
- State Management
- Asset Loading
- Save/Load System
- Input Management
- Audio System
- Performance Monitoring
**Core Systems Required:**
- **Scene Management:** {{scene_manager_approach}}
- **State Management:** {{state_pattern_implementation}}
- **Event System:** {{event_system_choice}}
- **Object Pooling:** {{pooling_strategy}}
- **Save/Load System:** {{save_system_approach}}
**Folder Structure:**
```
Assets/
├── _Project/
│ ├── Scripts/
│ │ ├── {{folder_structure}}
│ ├── Prefabs/
│ ├── Scenes/
│ └── {{additional_folders}}
```
**Naming Conventions:**
- Scripts: {{script_naming}}
- Prefabs: {{prefab_naming}}
- Scenes: {{scene_naming}}
examples:
- "Architecture: Component-Based with ScriptableObject data containers"
- "Scripts: PascalCase (PlayerController), Prefabs: Player_Prefab, Scenes: Level_01_Forest"
- id: unity-systems-integration
title: Unity Systems Integration
template: |
**Required Unity Systems:**
- **Input System:** {{input_implementation}}
- **Animation System:** {{animation_approach}}
- **Physics Integration:** {{physics_usage}}
- **Rendering Features:** {{rendering_requirements}}
- **Asset Streaming:** {{asset_loading_strategy}}
**Third-Party Integrations:**
- {{integration_name}}: {{integration_purpose}}
**Performance Systems:**
- **Profiling Integration:** {{profiling_setup}}
- **Memory Management:** {{memory_strategy}}
- **Build Pipeline:** {{build_automation}}
examples:
- "Input System: Action Maps for Menu/Gameplay contexts with device switching"
- "DOTween: Smooth UI transitions and gameplay animations"
- id: data-management
title: Data Management
template: |
**Save Data:**
**Save Data Architecture:**
- Progress tracking
- Settings persistence
- Statistics collection
- {{additional_data}}
- **Format:** {{PlayerPrefs|JSON|Binary|Cloud}}
- **Structure:** {{save_data_organization}}
- **Encryption:** {{security_approach}}
- **Cloud Sync:** {{cloud_integration}}
**Configuration Data:**
- **ScriptableObjects:** {{scriptable_object_usage}}
- **Settings Management:** {{settings_system}}
- **Localization:** {{localization_approach}}
**Runtime Data:**
- **Caching Strategy:** {{cache_implementation}}
- **Memory Pools:** {{pooling_objects}}
- **Asset References:** {{asset_reference_system}}
examples:
- "Save Data: JSON format with AES encryption, stored in persistent data path"
- "ScriptableObjects: Game settings, level configurations, character data"
- id: development-phases
title: Development Phases
instruction: Break down the development into phases that can be converted to epics
title: Development Phases & Epic Planning
instruction: Break down the Unity development into phases that can be converted to agile epics. Each phase should deliver deployable functionality following Unity best practices.
elicit: true
sections:
- id: phase-1-core-systems
title: "Phase 1: Core Systems ({{duration}})"
- id: epic-overview
title: Epic Overview
instruction: Present a high-level list of all epics for user approval. Each epic should deliver significant Unity functionality.
type: numbered-list
examples:
- "Epic 1: Unity Foundation & Core Systems: Project setup, input handling, basic scene management"
- "Epic 2: Core Game Mechanics: Player controller, physics systems, basic gameplay loop"
- "Epic 3: Level Systems & Content Pipeline: Scene loading, prefab systems, level progression"
- "Epic 4: Polish & Platform Optimization: Performance tuning, platform-specific features, deployment"
- id: phase-1-foundation
title: "Phase 1: Unity Foundation & Core Systems ({{duration}})"
sections:
- id: foundation-epic
title: "Epic: Foundation"
title: "Epic: Unity Project Foundation"
type: bullet-list
template: |
- Engine setup and configuration
- Basic scene management
- Core input handling
- Asset loading pipeline
- id: core-mechanics-epic
title: "Epic: Core Mechanics"
- Unity project setup with proper folder structure and naming conventions
- Core architecture implementation ({{architecture_pattern}})
- Input System configuration with action maps for all platforms
- Basic scene management and state handling
- Development tools setup (debugging, profiling integration)
- Initial build pipeline and platform configuration
examples:
- "Input System: Configure PlayerInput component with Action Maps for movement and UI"
- id: core-systems-epic
title: "Epic: Essential Game Systems"
type: bullet-list
template: |
- {{primary_mechanic}} implementation
- Basic physics and collision
- Player controller
- id: phase-2-gameplay-features
title: "Phase 2: Gameplay Features ({{duration}})"
- Save/Load system implementation with {{save_format}} format
- Audio system setup with {{audio_system}} integration
- Event system for decoupled component communication
- Object pooling system for performance optimization
- Basic UI framework and canvas configuration
- Settings and configuration management with ScriptableObjects
- id: phase-2-gameplay
title: "Phase 2: Core Gameplay Implementation ({{duration}})"
sections:
- id: game-systems-epic
title: "Epic: Game Systems"
- id: gameplay-mechanics-epic
title: "Epic: Primary Game Mechanics"
type: bullet-list
template: |
- {{mechanic_2}} implementation
- {{mechanic_3}} implementation
- Game state management
- id: content-creation-epic
title: "Epic: Content Creation"
- Player controller with {{movement_type}} movement system
- {{primary_mechanic}} implementation with Unity physics
- {{secondary_mechanic}} system with visual feedback
- Game state management (playing, paused, game over)
- Basic collision detection and response systems
- Animation system integration with Animator controllers
- id: level-systems-epic
title: "Epic: Level & Content Systems"
type: bullet-list
template: |
- Level loading system
- First playable levels
- Basic UI implementation
- id: phase-3-polish-optimization
- Scene loading and transition system
- Level progression and unlock system
- Prefab-based level construction tools
- {{level_generation}} level creation workflow
- Collectibles and pickup systems
- Victory/defeat condition implementation
- id: phase-3-polish
title: "Phase 3: Polish & Optimization ({{duration}})"
sections:
- id: performance-epic
title: "Epic: Performance"
title: "Epic: Performance & Platform Optimization"
type: bullet-list
template: |
- Optimization and profiling
- Mobile platform testing
- Memory management
- Unity Profiler analysis and optimization passes
- Memory management and garbage collection optimization
- Asset optimization (texture compression, audio compression)
- Platform-specific performance tuning
- Build size optimization and asset bundling
- Quality settings configuration for different device tiers
- id: user-experience-epic
title: "Epic: User Experience"
title: "Epic: User Experience & Polish"
type: bullet-list
template: |
- Audio implementation
- Visual effects and polish
- Final UI/UX refinement
- Complete UI/UX implementation with responsive design
- Audio implementation with dynamic mixing
- Visual effects and particle systems
- Accessibility features implementation
- Tutorial and onboarding flow
- Final testing and bug fixing across all platforms
- id: success-metrics
title: Success Metrics
instruction: Define measurable goals for the game
title: Success Metrics & Quality Assurance
instruction: Define measurable goals for the Unity game development project with specific targets that can be validated through Unity Analytics and profiling tools.
elicit: true
sections:
- id: technical-metrics
title: Technical Metrics
title: Technical Performance Metrics
type: bullet-list
template: |
- Frame rate: {{fps_target}}
- Load time: {{load_target}}
- Crash rate: <{{crash_threshold}}%
- Memory usage: <{{memory_target}}MB
- **Frame Rate:** Consistent {{fps_target}} FPS with <5% drops below {{min_fps}}
- **Load Times:** Initial load <{{initial_load}}s, level transitions <{{level_load}}s
- **Memory Usage:** Heap memory <{{heap_limit}}MB, texture memory <{{texture_limit}}MB
- **Crash Rate:** <{{crash_threshold}}% across all supported platforms
- **Build Size:** Final build <{{size_limit}}MB for mobile, <{{desktop_limit}}MB for desktop
- **Battery Life:** Mobile gameplay sessions >{{battery_target}} hours on average device
examples:
- "Frame Rate: Consistent 60 FPS with <5% drops below 45 FPS on target hardware"
- "Crash Rate: <0.5% across iOS/Android, <0.1% on desktop platforms"
- id: gameplay-metrics
title: Gameplay Metrics
title: Gameplay & User Engagement Metrics
type: bullet-list
template: |
- Tutorial completion: {{completion_rate}}%
- Average session: {{session_length}} minutes
- Level completion: {{level_completion}}%
- Player retention: D1 {{d1}}%, D7 {{d7}}%
- id: appendices
title: Appendices
sections:
- id: change-log
title: Change Log
instruction: Track document versions and changes
- **Tutorial Completion:** {{tutorial_rate}}% of players complete basic tutorial
- **Level Progression:** {{progression_rate}}% reach level {{target_level}} within first session
- **Session Duration:** Average session length {{session_target}} minutes
- **Player Retention:** Day 1: {{d1_retention}}%, Day 7: {{d7_retention}}%, Day 30: {{d30_retention}}%
- **Gameplay Completion:** {{completion_rate}}% complete main game content
- **Control Responsiveness:** Input lag <{{input_lag}}ms on all platforms
examples:
- "Tutorial Completion: 85% of players complete movement and basic mechanics tutorial"
- "Session Duration: Average 15-20 minutes per session for mobile, 30-45 minutes for desktop"
- id: platform-specific-metrics
title: Platform-Specific Quality Metrics
type: table
template: |
| Date | Version | Description | Author |
| :--- | :------ | :---------- | :----- |
- id: references
title: References
instruction: List any competitive analysis, inspiration, or research sources
| Platform | Frame Rate | Load Time | Memory | Build Size | Battery |
| -------- | ---------- | --------- | ------ | ---------- | ------- |
| {{platform}} | {{fps}} | {{load}} | {{memory}} | {{size}} | {{battery}} |
examples:
- iOS, 60 FPS, <3s, <150MB, <80MB, 3+ hours
- Android, 60 FPS, <5s, <200MB, <100MB, 2.5+ hours
- id: next-steps-integration
title: Next Steps & BMad Integration
instruction: Define how this GDD integrates with BMad's agent workflow and what follow-up documents or processes are needed.
sections:
- id: architecture-handoff
title: Unity Architecture Requirements
instruction: Summary of key architectural decisions that need to be implemented in Unity project setup
type: bullet-list
template: "{{reference}}"
template: |
- Unity {{unity_version}} project with {{render_pipeline}} pipeline
- {{architecture_pattern}} code architecture with {{folder_structure}}
- Required packages: {{essential_packages}}
- Performance targets: {{key_performance_metrics}}
- Platform builds: {{deployment_targets}}
- id: story-creation-guidance
title: Story Creation Guidance for SM Agent
instruction: Provide guidance for the Story Manager (SM) agent on how to break down this GDD into implementable user stories
template: |
**Epic Prioritization:** {{epic_order_rationale}}
**Story Sizing Guidelines:**
- Foundation stories: {{foundation_story_scope}}
- Feature stories: {{feature_story_scope}}
- Polish stories: {{polish_story_scope}}
**Unity-Specific Story Considerations:**
- Each story should result in testable Unity scenes or prefabs
- Include specific Unity components and systems in acceptance criteria
- Consider cross-platform testing requirements
- Account for Unity build and deployment steps
examples:
- "Foundation stories: Individual Unity systems (Input, Audio, Scene Management) - 1-2 days each"
- "Feature stories: Complete gameplay mechanics with UI and feedback - 2-4 days each"
- id: recommended-agents
title: Recommended BMad Agent Sequence
type: numbered-list
template: |
1. **{{agent_name}}**: {{agent_responsibility}}
examples:
- "Unity Architect: Create detailed technical architecture document with specific Unity implementation patterns"
- "Unity Developer: Implement core systems and gameplay mechanics according to architecture"
- "QA Tester: Validate performance metrics and cross-platform functionality"
==================== END: .bmad-2d-unity-game-dev/templates/game-design-doc-tmpl.yaml ====================
==================== START: .bmad-2d-unity-game-dev/templates/level-design-doc-tmpl.yaml ====================
template:
id: level-design-doc-template-v2
name: Level Design Document
version: 2.0
version: 2.1
output:
format: markdown
filename: "docs/{{game_name}}-level-design-document.md"
filename: docs/level-design-document.md
title: "{{game_title}} Level Design Document"
workflow:
@ -1732,19 +2021,19 @@ sections:
title: Playtesting Checklist
type: checklist
items:
- "Level completes within target time range"
- "All mechanics function correctly"
- "Difficulty feels appropriate for level category"
- "Player guidance is clear and effective"
- "No exploits or sequence breaks (unless intended)"
- Level completes within target time range
- All mechanics function correctly
- Difficulty feels appropriate for level category
- Player guidance is clear and effective
- No exploits or sequence breaks (unless intended)
- id: player-experience-testing
title: Player Experience Testing
type: checklist
items:
- "Tutorial levels teach effectively"
- "Challenge feels fair and rewarding"
- "Flow and pacing maintain engagement"
- "Audio and visual feedback support gameplay"
- Tutorial levels teach effectively
- Challenge feels fair and rewarding
- Flow and pacing maintain engagement
- Audio and visual feedback support gameplay
- id: balance-validation
title: Balance Validation
template: |
@ -1847,12 +2136,12 @@ sections:
==================== START: .bmad-2d-unity-game-dev/templates/game-brief-tmpl.yaml ====================
template:
id: game-brief-template-v2
id: game-brief-template-v3
name: Game Brief
version: 2.0
version: 3.0
output:
format: markdown
filename: "docs/{{game_name}}-game-brief.md"
filename: docs/game-brief.md
title: "{{game_title}} Game Brief"
workflow:
@ -2383,7 +2672,7 @@ sections:
- [ ] **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

1513
dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-developer.txt vendored
View File

File diff suppressed because it is too large Load Diff

488
dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt vendored
View File

@ -72,18 +72,18 @@ persona:
commands:
- help: Show numbered list of the following commands to allow selection
- draft: Execute task create-game-story.md
- correct-course: Execute task correct-course.md
- correct-course: Execute task correct-course-game.md
- story-checklist: Execute task execute-checklist.md with checklist game-story-dod-checklist.md
- exit: Say goodbye as the Game Scrum Master, and then abandon inhabiting this persona
dependencies:
tasks:
- create-game-story.md
- execute-checklist.md
- correct-course.md
- correct-course-game.md
templates:
- game-story-tmpl.yaml
checklists:
- game-story-dod-checklist.md
- game-change-checklist.md
```
==================== END: .bmad-2d-unity-game-dev/agents/game-sm.md ====================
@ -371,84 +371,165 @@ The LLM will:
- Offer to provide detailed analysis of any section, especially those with warnings or failures
==================== END: .bmad-2d-unity-game-dev/tasks/execute-checklist.md ====================
==================== START: .bmad-2d-unity-game-dev/tasks/correct-course.md ====================
# Correct Course Task
==================== START: .bmad-2d-unity-game-dev/tasks/correct-course-game.md ====================
# Correct Course Task - Game Development
## Purpose
- Guide a structured response to a change trigger using the `.bmad-2d-unity-game-dev/checklists/change-checklist`.
- Analyze the impacts of the change on epics, project artifacts, and the MVP, guided by the checklist's structure.
- Explore potential solutions (e.g., adjust scope, rollback elements, re-scope features) as prompted by the checklist.
- Draft specific, actionable proposed updates to any affected project artifacts (e.g., epics, user stories, PRD sections, architecture document sections) based on the analysis.
- Produce a consolidated "Sprint Change Proposal" document that contains the impact analysis and the clearly drafted proposed edits for user review and approval.
- Ensure a clear handoff path if the nature of the changes necessitates fundamental replanning by other core agents (like PM or Architect).
- Guide a structured response to game development change triggers using the `.bmad-2d-unity-game-dev/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 "Correct Course Task" (Change Navigation & Integration) is being initiated.
- Verify the change trigger and ensure you have the user's initial explanation of the issue and its perceived impact.
- Confirm access to all relevant project artifacts (e.g., PRD, Epics/Stories, Architecture Documents, UI/UX Specifications) and, critically, the `.bmad-2d-unity-game-dev/checklists/change-checklist`.
- 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 `.bmad-2d-unity-game-dev/checklists/game-change-checklist`.
- **Establish Interaction Mode:**
- Ask the user their preferred interaction mode for this task:
- **"Incrementally (Default & Recommended):** Shall we work through the change-checklist section by section, discussing findings and collaboratively drafting proposed changes for each relevant part before moving to the next? This allows for detailed, step-by-step refinement."
- **"YOLO Mode (Batch Processing):** Or, would you prefer I conduct a more batched analysis based on the checklist and then present a consolidated set of findings and proposed changes for a broader review? This can be quicker for initial assessment but might require more extensive review of the combined proposals."
- Once the user chooses, confirm the selected mode and then inform the user: "We will now use the change-checklist to analyze the change and draft proposed updates. I will guide you through the checklist items based on our chosen 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 Checklist Analysis (Iteratively or Batched, per Interaction Mode)
### 2. Execute Game Development Checklist Analysis
- Systematically work through Sections 1-4 of the change-checklist (typically covering Change Context, Epic/Story Impact Analysis, Artifact Conflict Resolution, and Path Evaluation/Recommendation).
- For each checklist item or logical group of items (depending on interaction mode):
- Present the relevant prompt(s) or considerations from the checklist to the user.
- Request necessary information and actively analyze the relevant project artifacts (PRD, epics, architecture documents, story history, etc.) to assess the impact.
- Discuss your findings for each item with the user.
- Record the status of each checklist item (e.g., `[x] Addressed`, `[N/A]`, `[!] Further Action Needed`) and any pertinent notes or decisions.
- Collaboratively agree on the "Recommended Path Forward" as prompted by Section 4 of the checklist.
- Systematically work through the game-change-checklist sections:
### 3. Draft Proposed Changes (Iteratively or Batched)
1. **Change Context & Game Impact**
2. **Feature/System Impact Analysis**
3. **Technical Artifact Conflict Resolution**
4. **Performance & Platform Evaluation**
5. **Path Forward Recommendation**
- Based on the completed checklist analysis (Sections 1-4) and the agreed "Recommended Path Forward" (excluding scenarios requiring fundamental replans that would necessitate immediate handoff to PM/Architect):
- Identify the specific project artifacts that require updates (e.g., specific epics, user stories, PRD sections, architecture document components, diagrams).
- **Draft the proposed changes directly and explicitly for each identified artifact.** Examples include:
- Revising user story text, acceptance criteria, or priority.
- Adding, removing, reordering, or splitting user stories within epics.
- Proposing modified architecture diagram snippets (e.g., providing an updated Mermaid diagram block or a clear textual description of the change to an existing diagram).
- Updating technology lists, configuration details, or specific sections within the PRD or architecture documents.
- Drafting new, small supporting artifacts if necessary (e.g., a brief addendum for a specific decision).
- If in "Incremental Mode," discuss and refine these proposed edits for each artifact or small group of related artifacts with the user as they are drafted.
- If in "YOLO Mode," compile all drafted edits for presentation in the next step.
- 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
### 4. Generate "Sprint Change Proposal" with Edits
### 3. Draft Game-Specific Proposed Changes
- Synthesize the complete change-checklist analysis (covering findings from Sections 1-4) and all the agreed-upon proposed edits (from Instruction 3) into a single document titled "Sprint Change Proposal." This proposal should align with the structure suggested by Section 5 of the change-checklist.
- The proposal must clearly present:
- **Analysis Summary:** A concise overview of the original issue, its analyzed impact (on epics, artifacts, MVP scope), and the rationale for the chosen path forward.
- **Specific Proposed Edits:** For each affected artifact, clearly show or describe the exact changes (e.g., "Change Story X.Y from: [old text] To: [new text]", "Add new Acceptance Criterion to Story A.B: [new AC]", "Update Section 3.2 of Architecture Document as follows: [new/modified text or diagram description]").
- Present the complete draft of the "Sprint Change Proposal" to the user for final review and feedback. Incorporate any final adjustments requested by the user.
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 user approval for the "Sprint Change Proposal," including all the specific edits documented within it.
- Provide the finalized "Sprint Change Proposal" document to the user.
- **Based on the nature of the approved changes:**
- **If the approved edits sufficiently address the change and can be implemented directly or organized by a PO/SM:** State that the "Correct Course Task" is complete regarding analysis and change proposal, and the user can now proceed with implementing or logging these changes (e.g., updating actual project documents, backlog items). Suggest handoff to a PO/SM agent for backlog organization if appropriate.
- **If the analysis and proposed path (as per checklist Section 4 and potentially Section 6) indicate that the change requires a more fundamental replan (e.g., significant scope change, major architectural rework):** Clearly state this conclusion. Advise the user that the next step involves engaging the primary PM or Architect agents, using the "Sprint Change Proposal" as critical input and context for that deeper replanning effort.
- 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:** A "Sprint Change Proposal" document (in markdown format). This document will contain:
- A summary of the change-checklist analysis (issue, impact, rationale for the chosen path).
- Specific, clearly drafted proposed edits for all affected project artifacts.
- **Implicit:** An annotated change-checklist (or the record of its completion) reflecting the discussions, findings, and decisions made during the process.
==================== END: .bmad-2d-unity-game-dev/tasks/correct-course.md ====================
- **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
==================== END: .bmad-2d-unity-game-dev/tasks/correct-course-game.md ====================
==================== START: .bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml ====================
template:
id: game-story-template-v2
id: game-story-template-v3
name: Game Development Story
version: 2.0
version: 3.0
output:
format: markdown
filename: "stories/{{epic_name}}/{{story_id}}-{{story_name}}.md"
@ -496,9 +577,9 @@ sections:
title: Technical Requirements
type: checklist
items:
- "Code follows C# best practices"
- "Maintains stable frame rate on target devices"
- "No memory leaks or performance degradation"
- Code follows C# best practices
- Maintains stable frame rate on target devices
- No memory leaks or performance degradation
- "{{specific_technical_requirement}}"
- id: game-design-requirements
title: Game Design Requirements
@ -674,13 +755,13 @@ sections:
instruction: Checklist that must be completed before the story is considered finished
type: checklist
items:
- "All acceptance criteria met"
- "Code reviewed and approved"
- "Unit tests written and passing"
- "Integration tests passing"
- "Performance targets met"
- "No C# compiler errors or warnings"
- "Documentation updated"
- All acceptance criteria met
- Code reviewed and approved
- Unit tests written and passing
- Integration tests passing
- Performance targets met
- No C# compiler errors or warnings
- Documentation updated
- "{{game_specific_dod_item}}"
- id: notes
@ -703,165 +784,208 @@ sections:
- {{future_optimization_1}}
==================== END: .bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml ====================
==================== START: .bmad-2d-unity-game-dev/checklists/game-story-dod-checklist.md ====================
# Game Development Story Definition of Done Checklist
==================== START: .bmad-2d-unity-game-dev/checklists/game-change-checklist.md ====================
# Game Development Change Navigation Checklist
## Story Completeness
**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.
### Basic Story Elements
**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
- [ ] **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 CHANGE NAVIGATION
### Game Design Alignment
Changes during game development are common - performance issues, platform constraints, gameplay feedback, and technical limitations are part of the process.
- [ ] **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
Before proceeding, understand:
## Technical Specifications
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
### Architecture Compliance
Required context:
- [ ] **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 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
### Unity Requirements
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.
- [ ] **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
REMEMBER: Game development is iterative. Changes often lead to better gameplay and performance.]]
### Code Quality Standards
---
- [ ] **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
## 1. Understand the Trigger & Context
## Implementation Readiness
[[LLM: Start by understanding the game-specific issue. Ask technical questions:
### Acceptance Criteria
- 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?
- [ ] **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
Focus on measurable impacts and technical specifics.]]
### Implementation Tasks
- [ ] **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.
- [ ] **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
## 2. Game Feature Impact Assessment
### Dependencies
[[LLM: Game features are interconnected. Evaluate systematically:
- [ ] **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
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?
## Testing Requirements
Consider both technical and gameplay impacts.]]
### Test Coverage
- [ ] **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.
- [ ] **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
## 3. Game Artifact Conflict & Impact Analysis
### Test Implementation
[[LLM: Game documentation drives development. Check each artifact:
- [ ] **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
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?
## Game-Specific Quality
Missing conflicts cause performance issues later.]]
### Gameplay Implementation
- [ ] **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.
- [ ] **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
## 4. Path Forward Evaluation
### User Experience
[[LLM: Present game-specific solutions with technical trade-offs:
- [ ] **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
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?
### Performance Optimization
Be specific about Unity implementation details.]]
- [ ] **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
- [ ] **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.
## Documentation and Communication
## 5. Game Development Change Proposal Components
### Story Documentation
[[LLM: The proposal must include technical specifics:
- [ ] **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
1. Performance metrics (before/after projections)
2. Unity implementation details
3. Platform-specific considerations
4. Testing requirements
5. Risk mitigation strategies
### Developer Handoff
Make it actionable for game developers.]]
- [ ] **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
(Ensure all points from previous sections are captured)
## Final Validation
- [ ] **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.
### Story Readiness
## 6. Final Review & Handoff
- [ ] **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
[[LLM: Game changes require technical validation. Before concluding:
### Implementation Preparedness
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?
- [ ] **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
Get explicit approval on technical approach.
## Checklist Completion
FINAL REPORT:
Provide a technical summary:
**Overall Story Quality:** ⭐⭐⭐⭐⭐
- Performance issue and root cause
- Chosen solution with expected gains
- Implementation approach in Unity
- Testing and validation plan
- Timeline and milestone impacts
**Ready for Development:** [ ] Yes [ ] No
Keep it technically precise and actionable.]]
**Additional Notes:**
_Any specific concerns, recommendations, or clarifications needed before development begins._
==================== END: .bmad-2d-unity-game-dev/checklists/game-story-dod-checklist.md ====================
- [ ] **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.
---
==================== END: .bmad-2d-unity-game-dev/checklists/game-change-checklist.md ====================

7882
dist/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt vendored
View File

File diff suppressed because it is too large Load Diff

11060
dist/teams/team-all.txt vendored Normal file
View File

File diff suppressed because it is too large Load Diff

10390
dist/teams/team-fullstack.txt vendored Normal file
View File

File diff suppressed because it is too large Load Diff

3507
dist/teams/team-ide-minimal.txt vendored Normal file
View File

File diff suppressed because it is too large Load Diff

8949
dist/teams/team-no-ui.txt vendored Normal file
View File

File diff suppressed because it is too large Load Diff