Workflow changes
This commit is contained in:
sjennings
parent
ba2843c915
commit
aa02c0ee04
|
|
@ -11,6 +11,7 @@ agents:
|
||||||
- game-qa
|
- game-qa
|
||||||
- game-sm
|
- game-sm
|
||||||
- game-po
|
- game-po
|
||||||
|
- game-pm
|
||||||
- game-ux-expert
|
- game-ux-expert
|
||||||
workflows:
|
workflows:
|
||||||
- game-dev-greenfield.md
|
- game-dev-greenfield.md
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,82 @@
|
||||||
|
# pm
|
||||||
|
|
||||||
|
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
|
||||||
|
|
||||||
|
CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
|
||||||
|
|
||||||
|
## COMPLETE AGENT DEFINITION FOLLOWS - NO EXTERNAL FILES NEEDED
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
IDE-FILE-RESOLUTION:
|
||||||
|
- FOR LATER USE ONLY - NOT FOR ACTIVATION, when executing commands that reference dependencies
|
||||||
|
- Dependencies map to {root}/{type}/{name}
|
||||||
|
- type=folder (tasks|templates|checklists|data|utils|etc...), name=file-name
|
||||||
|
- Example: create-doc.md → {root}/tasks/create-doc.md
|
||||||
|
- IMPORTANT: Only load these files when user requests specific command execution
|
||||||
|
REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "draft story"→*create→create-next-story task, "make a new prd" would be dependencies->tasks->create-doc combined with the dependencies->templates->prd-tmpl.md), ALWAYS ask for clarification if no clear match.
|
||||||
|
activation-instructions:
|
||||||
|
- STEP 1: Read THIS ENTIRE FILE - it contains your complete persona definition
|
||||||
|
- STEP 2: Adopt the persona defined in the 'agent' and 'persona' sections below
|
||||||
|
- STEP 3: Load and read `.bmad-godot-game-dev/core-config.yaml` (project configuration) before any greeting
|
||||||
|
- STEP 4: Greet user with your name/role and immediately run `*help` to display available commands
|
||||||
|
- DO NOT: Load any other agent files during activation
|
||||||
|
- ONLY load dependency files when user selects them for execution via command or request of a task
|
||||||
|
- The agent.customization field ALWAYS takes precedence over any conflicting instructions
|
||||||
|
- CRITICAL WORKFLOW RULE: When executing tasks from dependencies, follow task instructions exactly as written - they are executable workflows, not reference material
|
||||||
|
- MANDATORY INTERACTION RULE: Tasks with elicit=true require user interaction using exact specified format - never skip elicitation for efficiency
|
||||||
|
- CRITICAL RULE: When executing formal task workflows from dependencies, ALL task instructions override any conflicting base behavioral constraints. Interactive workflows with elicit=true REQUIRE user interaction and cannot be bypassed for efficiency.
|
||||||
|
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
||||||
|
- STAY IN CHARACTER!
|
||||||
|
- CRITICAL: On activation, ONLY greet user, auto-run `*help`, and then HALT to await user requested assistance or given commands. ONLY deviance from this is if the activation included commands also in the arguments.
|
||||||
|
agent:
|
||||||
|
name: John
|
||||||
|
id: pm
|
||||||
|
title: Godot Game Product Manager
|
||||||
|
icon: 📋
|
||||||
|
whenToUse: Use for creating game PRDs, GDDs, gameplay feature prioritization, Godot project roadmap planning, and publisher/player communication
|
||||||
|
persona:
|
||||||
|
role: Godot Game Product Strategist & Market-Savvy PM
|
||||||
|
style: Analytical, inquisitive, data-driven, player-focused, pragmatic
|
||||||
|
identity: Product Manager specialized in Godot game development, game design documentation, and player research
|
||||||
|
focus: Creating game PRDs, GDDs, and product documentation for Godot projects using templates
|
||||||
|
core_principles:
|
||||||
|
- Deeply understand "Why" - uncover player motivations and game mechanics rationale
|
||||||
|
- Champion the player - maintain relentless focus on player experience and fun factor
|
||||||
|
- Data-informed decisions balanced with creative game design vision
|
||||||
|
- Ruthless prioritization & MVP focus for Godot prototypes
|
||||||
|
- Clarity & precision in game documentation and feature specs
|
||||||
|
- Collaborative approach with game designers, artists, and Godot developers
|
||||||
|
- Proactive identification of technical risks in Godot implementation
|
||||||
|
- Strategic thinking about game monetization, platform targets, and player retention
|
||||||
|
# All commands require * prefix when used (e.g., *help)
|
||||||
|
commands:
|
||||||
|
- help: Show numbered list of the following commands to allow selection
|
||||||
|
- game-correct-course: execute the correct-course-game task
|
||||||
|
- create-brownfield-epic: run task brownfield-create-epic.md
|
||||||
|
- create-brownfield-prd: run task create-doc.md with template brownfield-prd-tmpl.yaml
|
||||||
|
- create-brownfield-story: run task brownfield-create-story.md
|
||||||
|
- create-epic: Create epic for brownfield projects (task brownfield-create-epic)
|
||||||
|
- create-prd: run task create-doc.md with template game-prd-tmpl.yaml
|
||||||
|
- create-story: Create user story from requirements (task brownfield-create-story)
|
||||||
|
- doc-out: Output full document to current destination file
|
||||||
|
- shard-doc: run the task shard-doc.md for the provided document (ask if not found)
|
||||||
|
- yolo: Toggle Yolo Mode
|
||||||
|
- exit: Exit (confirm)
|
||||||
|
dependencies:
|
||||||
|
checklists:
|
||||||
|
- game-change-checklist.md
|
||||||
|
- pm-checklist.md
|
||||||
|
data:
|
||||||
|
- technical-preferences.md
|
||||||
|
tasks:
|
||||||
|
- brownfield-create-epic.md
|
||||||
|
- brownfield-create-story.md
|
||||||
|
- correct-course-game.md
|
||||||
|
- create-deep-research-prompt.md
|
||||||
|
- create-doc.md
|
||||||
|
- execute-checklist.md
|
||||||
|
- shard-doc.md
|
||||||
|
templates:
|
||||||
|
- brownfield-prd-tmpl.yaml
|
||||||
|
- game-prd-tmpl.yaml
|
||||||
|
```
|
||||||
|
|
@ -143,11 +143,14 @@ commands:
|
||||||
Validates: Test coverage, performance targets, TDD compliance.
|
Validates: Test coverage, performance targets, TDD compliance.
|
||||||
Produces: QA Results with TDD validation + gate file (PASS/FAIL).
|
Produces: QA Results with TDD validation + gate file (PASS/FAIL).
|
||||||
Gate file location: docs/qa/gates/{epic}.{story}-{slug}.yml
|
Gate file location: docs/qa/gates/{epic}.{story}-{slug}.yml
|
||||||
- test-design {story}: Execute test-design task to create comprehensive test scenarios
|
- risk-profile {story}: Execute game-risk-profile task to generate risk assessment matrix
|
||||||
|
- test-design {story}: Execute game-test-design task to create comprehensive test scenarios
|
||||||
- exit: Say goodbye as the Game Test Architect, and then abandon inhabiting this persona
|
- exit: Say goodbye as the Game Test Architect, and then abandon inhabiting this persona
|
||||||
dependencies:
|
dependencies:
|
||||||
tasks:
|
tasks:
|
||||||
- review-game-story.md
|
- review-game-story.md
|
||||||
|
- game-test-design.md
|
||||||
|
- game-risk-profile.md
|
||||||
data:
|
data:
|
||||||
- technical-preferences.md
|
- technical-preferences.md
|
||||||
templates:
|
templates:
|
||||||
|
|
|
||||||
|
|
@ -6,7 +6,7 @@ This checklist serves as a comprehensive framework for the Game Architect to val
|
||||||
|
|
||||||
Before proceeding with this checklist, ensure you have access to:
|
Before proceeding with this checklist, ensure you have access to:
|
||||||
|
|
||||||
1. game-architecture.md - The primary game architecture document (check docs/game-architecture.md)
|
1. architecture.md - The primary game architecture document (check docs/architecture.md)
|
||||||
2. game-design-doc.md - Game Design Document for game requirements alignment (check docs/game-design-doc.md)
|
2. game-design-doc.md - Game Design Document for game requirements alignment (check docs/game-design-doc.md)
|
||||||
3. Any system diagrams referenced in the architecture
|
3. Any system diagrams referenced in the architecture
|
||||||
4. Godot project structure documentation
|
4. Godot project structure documentation
|
||||||
|
|
|
||||||
|
|
@ -9,7 +9,7 @@ First, determine the game project type by checking:
|
||||||
|
|
||||||
1. Is this a NEW GAME project (greenfield)?
|
1. Is this a NEW GAME project (greenfield)?
|
||||||
- Look for: New Godot project initialization, no existing game code
|
- Look for: New Godot project initialization, no existing game code
|
||||||
- Check for: game-design-doc.md, game-architecture.md, new game setup
|
- Check for: game-design-doc.md, architecture.md, new game setup
|
||||||
- Godot version selection (4.x vs 3.x)
|
- Godot version selection (4.x vs 3.x)
|
||||||
|
|
||||||
2. Is this an EXISTING GAME enhancement (brownfield)?
|
2. Is this an EXISTING GAME enhancement (brownfield)?
|
||||||
|
|
@ -29,7 +29,7 @@ Based on project type, ensure you have access to:
|
||||||
For NEW GAME projects:
|
For NEW GAME projects:
|
||||||
|
|
||||||
- game-design-doc.md - The Game Design Document
|
- game-design-doc.md - The Game Design Document
|
||||||
- game-architecture.md - The technical architecture
|
- architecture.md - The technical architecture
|
||||||
- platform-requirements.md - Platform specifications
|
- platform-requirements.md - Platform specifications
|
||||||
- All epic and story definitions
|
- All epic and story definitions
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,162 @@
|
||||||
|
<!-- Powered by BMAD™ Core -->
|
||||||
|
|
||||||
|
# Create Brownfield Epic Task
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Create a single epic for smaller brownfield enhancements that don't require the full PRD and Architecture documentation process. This task is for isolated features or modifications that can be completed within a focused scope.
|
||||||
|
|
||||||
|
## When to Use This Task
|
||||||
|
|
||||||
|
**Use this task when:**
|
||||||
|
|
||||||
|
- The enhancement can be completed in 1-3 stories
|
||||||
|
- No significant architectural changes are required
|
||||||
|
- The enhancement follows existing project patterns
|
||||||
|
- Integration complexity is minimal
|
||||||
|
- Risk to existing system is low
|
||||||
|
|
||||||
|
**Use the full brownfield PRD/Architecture process when:**
|
||||||
|
|
||||||
|
- The enhancement requires multiple coordinated stories
|
||||||
|
- Architectural planning is needed
|
||||||
|
- Significant integration work is required
|
||||||
|
- Risk assessment and mitigation planning is necessary
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
|
||||||
|
### 1. Project Analysis (Required)
|
||||||
|
|
||||||
|
Before creating the epic, gather essential information about the existing project:
|
||||||
|
|
||||||
|
**Existing Project Context:**
|
||||||
|
|
||||||
|
- [ ] Project purpose and current functionality understood
|
||||||
|
- [ ] Existing technology stack identified
|
||||||
|
- [ ] Current architecture patterns noted
|
||||||
|
- [ ] Integration points with existing system identified
|
||||||
|
|
||||||
|
**Enhancement Scope:**
|
||||||
|
|
||||||
|
- [ ] Enhancement clearly defined and scoped
|
||||||
|
- [ ] Impact on existing functionality assessed
|
||||||
|
- [ ] Required integration points identified
|
||||||
|
- [ ] Success criteria established
|
||||||
|
|
||||||
|
### 2. Epic Creation
|
||||||
|
|
||||||
|
Create a focused epic following this structure:
|
||||||
|
|
||||||
|
#### Epic Title
|
||||||
|
|
||||||
|
{{Enhancement Name}} - Brownfield Enhancement
|
||||||
|
|
||||||
|
#### Epic Goal
|
||||||
|
|
||||||
|
{{1-2 sentences describing what the epic will accomplish and why it adds value}}
|
||||||
|
|
||||||
|
#### Epic Description
|
||||||
|
|
||||||
|
**Existing System Context:**
|
||||||
|
|
||||||
|
- Current relevant functionality: {{brief description}}
|
||||||
|
- Technology stack: {{relevant existing technologies}}
|
||||||
|
- Integration points: {{where new work connects to existing system}}
|
||||||
|
|
||||||
|
**Enhancement Details:**
|
||||||
|
|
||||||
|
- What's being added/changed: {{clear description}}
|
||||||
|
- How it integrates: {{integration approach}}
|
||||||
|
- Success criteria: {{measurable outcomes}}
|
||||||
|
|
||||||
|
#### Stories
|
||||||
|
|
||||||
|
List 1-3 focused stories that complete the epic:
|
||||||
|
|
||||||
|
1. **Story 1:** {{Story title and brief description}}
|
||||||
|
2. **Story 2:** {{Story title and brief description}}
|
||||||
|
3. **Story 3:** {{Story title and brief description}}
|
||||||
|
|
||||||
|
#### Compatibility Requirements
|
||||||
|
|
||||||
|
- [ ] Existing APIs remain unchanged
|
||||||
|
- [ ] Database schema changes are backward compatible
|
||||||
|
- [ ] UI changes follow existing patterns
|
||||||
|
- [ ] Performance impact is minimal
|
||||||
|
|
||||||
|
#### Risk Mitigation
|
||||||
|
|
||||||
|
- **Primary Risk:** {{main risk to existing system}}
|
||||||
|
- **Mitigation:** {{how risk will be addressed}}
|
||||||
|
- **Rollback Plan:** {{how to undo changes if needed}}
|
||||||
|
|
||||||
|
#### Definition of Done
|
||||||
|
|
||||||
|
- [ ] All stories completed with acceptance criteria met
|
||||||
|
- [ ] Existing functionality verified through testing
|
||||||
|
- [ ] Integration points working correctly
|
||||||
|
- [ ] Documentation updated appropriately
|
||||||
|
- [ ] No regression in existing features
|
||||||
|
|
||||||
|
### 3. Validation Checklist
|
||||||
|
|
||||||
|
Before finalizing the epic, ensure:
|
||||||
|
|
||||||
|
**Scope Validation:**
|
||||||
|
|
||||||
|
- [ ] Epic can be completed in 1-3 stories maximum
|
||||||
|
- [ ] No architectural documentation is required
|
||||||
|
- [ ] Enhancement follows existing patterns
|
||||||
|
- [ ] Integration complexity is manageable
|
||||||
|
|
||||||
|
**Risk Assessment:**
|
||||||
|
|
||||||
|
- [ ] Risk to existing system is low
|
||||||
|
- [ ] Rollback plan is feasible
|
||||||
|
- [ ] Testing approach covers existing functionality
|
||||||
|
- [ ] Team has sufficient knowledge of integration points
|
||||||
|
|
||||||
|
**Completeness Check:**
|
||||||
|
|
||||||
|
- [ ] Epic goal is clear and achievable
|
||||||
|
- [ ] Stories are properly scoped
|
||||||
|
- [ ] Success criteria are measurable
|
||||||
|
- [ ] Dependencies are identified
|
||||||
|
|
||||||
|
### 4. Handoff to Story Manager
|
||||||
|
|
||||||
|
Once the epic is validated, provide this handoff to the Story Manager:
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Story Manager Handoff:**
|
||||||
|
|
||||||
|
"Please develop detailed user stories for this brownfield epic. Key considerations:
|
||||||
|
|
||||||
|
- This is an enhancement to an existing system running {{technology stack}}
|
||||||
|
- Integration points: {{list key integration points}}
|
||||||
|
- Existing patterns to follow: {{relevant existing patterns}}
|
||||||
|
- Critical compatibility requirements: {{key requirements}}
|
||||||
|
- Each story must include verification that existing functionality remains intact
|
||||||
|
|
||||||
|
The epic should maintain system integrity while delivering {{epic goal}}."
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Success Criteria
|
||||||
|
|
||||||
|
The epic creation is successful when:
|
||||||
|
|
||||||
|
1. Enhancement scope is clearly defined and appropriately sized
|
||||||
|
2. Integration approach respects existing system architecture
|
||||||
|
3. Risk to existing functionality is minimized
|
||||||
|
4. Stories are logically sequenced for safe implementation
|
||||||
|
5. Compatibility requirements are clearly specified
|
||||||
|
6. Rollback plan is feasible and documented
|
||||||
|
|
||||||
|
## Important Notes
|
||||||
|
|
||||||
|
- This task is specifically for SMALL brownfield enhancements
|
||||||
|
- If the scope grows beyond 3 stories, consider the full brownfield PRD process
|
||||||
|
- Always prioritize existing system integrity over new functionality
|
||||||
|
- When in doubt about scope or complexity, escalate to full brownfield planning
|
||||||
|
|
@ -0,0 +1,149 @@
|
||||||
|
<!-- Powered by BMAD™ Core -->
|
||||||
|
|
||||||
|
# Create Brownfield Story Task
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Create a single user story for very small brownfield enhancements that can be completed in one focused development session. This task is for minimal additions or bug fixes that require existing system integration awareness.
|
||||||
|
|
||||||
|
## When to Use This Task
|
||||||
|
|
||||||
|
**Use this task when:**
|
||||||
|
|
||||||
|
- The enhancement can be completed in a single story
|
||||||
|
- No new architecture or significant design is required
|
||||||
|
- The change follows existing patterns exactly
|
||||||
|
- Integration is straightforward with minimal risk
|
||||||
|
- Change is isolated with clear boundaries
|
||||||
|
|
||||||
|
**Use brownfield-create-epic when:**
|
||||||
|
|
||||||
|
- The enhancement requires 2-3 coordinated stories
|
||||||
|
- Some design work is needed
|
||||||
|
- Multiple integration points are involved
|
||||||
|
|
||||||
|
**Use the full brownfield PRD/Architecture process when:**
|
||||||
|
|
||||||
|
- The enhancement requires multiple coordinated stories
|
||||||
|
- Architectural planning is needed
|
||||||
|
- Significant integration work is required
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
|
||||||
|
### 1. Quick Project Assessment
|
||||||
|
|
||||||
|
Gather minimal but essential context about the existing project:
|
||||||
|
|
||||||
|
**Current System Context:**
|
||||||
|
|
||||||
|
- [ ] Relevant existing functionality identified
|
||||||
|
- [ ] Technology stack for this area noted
|
||||||
|
- [ ] Integration point(s) clearly understood
|
||||||
|
- [ ] Existing patterns for similar work identified
|
||||||
|
|
||||||
|
**Change Scope:**
|
||||||
|
|
||||||
|
- [ ] Specific change clearly defined
|
||||||
|
- [ ] Impact boundaries identified
|
||||||
|
- [ ] Success criteria established
|
||||||
|
|
||||||
|
### 2. Story Creation
|
||||||
|
|
||||||
|
Create a single focused story following this structure:
|
||||||
|
|
||||||
|
#### Story Title
|
||||||
|
|
||||||
|
{{Specific Enhancement}} - Brownfield Addition
|
||||||
|
|
||||||
|
#### User Story
|
||||||
|
|
||||||
|
As a {{user type}},
|
||||||
|
I want {{specific action/capability}},
|
||||||
|
So that {{clear benefit/value}}.
|
||||||
|
|
||||||
|
#### Story Context
|
||||||
|
|
||||||
|
**Existing System Integration:**
|
||||||
|
|
||||||
|
- Integrates with: {{existing component/system}}
|
||||||
|
- Technology: {{relevant tech stack}}
|
||||||
|
- Follows pattern: {{existing pattern to follow}}
|
||||||
|
- Touch points: {{specific integration points}}
|
||||||
|
|
||||||
|
#### Acceptance Criteria
|
||||||
|
|
||||||
|
**Functional Requirements:**
|
||||||
|
|
||||||
|
1. {{Primary functional requirement}}
|
||||||
|
2. {{Secondary functional requirement (if any)}}
|
||||||
|
3. {{Integration requirement}}
|
||||||
|
|
||||||
|
**Integration Requirements:** 4. Existing {{relevant functionality}} continues to work unchanged 5. New functionality follows existing {{pattern}} pattern 6. Integration with {{system/component}} maintains current behavior
|
||||||
|
|
||||||
|
**Quality Requirements:** 7. Change is covered by appropriate tests 8. Documentation is updated if needed 9. No regression in existing functionality verified
|
||||||
|
|
||||||
|
#### Technical Notes
|
||||||
|
|
||||||
|
- **Integration Approach:** {{how it connects to existing system}}
|
||||||
|
- **Existing Pattern Reference:** {{link or description of pattern to follow}}
|
||||||
|
- **Key Constraints:** {{any important limitations or requirements}}
|
||||||
|
|
||||||
|
#### Definition of Done
|
||||||
|
|
||||||
|
- [ ] Functional requirements met
|
||||||
|
- [ ] Integration requirements verified
|
||||||
|
- [ ] Existing functionality regression tested
|
||||||
|
- [ ] Code follows existing patterns and standards
|
||||||
|
- [ ] Tests pass (existing and new)
|
||||||
|
- [ ] Documentation updated if applicable
|
||||||
|
|
||||||
|
### 3. Risk and Compatibility Check
|
||||||
|
|
||||||
|
**Minimal Risk Assessment:**
|
||||||
|
|
||||||
|
- **Primary Risk:** {{main risk to existing system}}
|
||||||
|
- **Mitigation:** {{simple mitigation approach}}
|
||||||
|
- **Rollback:** {{how to undo if needed}}
|
||||||
|
|
||||||
|
**Compatibility Verification:**
|
||||||
|
|
||||||
|
- [ ] No breaking changes to existing APIs
|
||||||
|
- [ ] Database changes (if any) are additive only
|
||||||
|
- [ ] UI changes follow existing design patterns
|
||||||
|
- [ ] Performance impact is negligible
|
||||||
|
|
||||||
|
### 4. Validation Checklist
|
||||||
|
|
||||||
|
Before finalizing the story, confirm:
|
||||||
|
|
||||||
|
**Scope Validation:**
|
||||||
|
|
||||||
|
- [ ] Story can be completed in one development session
|
||||||
|
- [ ] Integration approach is straightforward
|
||||||
|
- [ ] Follows existing patterns exactly
|
||||||
|
- [ ] No design or architecture work required
|
||||||
|
|
||||||
|
**Clarity Check:**
|
||||||
|
|
||||||
|
- [ ] Story requirements are unambiguous
|
||||||
|
- [ ] Integration points are clearly specified
|
||||||
|
- [ ] Success criteria are testable
|
||||||
|
- [ ] Rollback approach is simple
|
||||||
|
|
||||||
|
## Success Criteria
|
||||||
|
|
||||||
|
The story creation is successful when:
|
||||||
|
|
||||||
|
1. Enhancement is clearly defined and appropriately scoped for single session
|
||||||
|
2. Integration approach is straightforward and low-risk
|
||||||
|
3. Existing system patterns are identified and will be followed
|
||||||
|
4. Rollback plan is simple and feasible
|
||||||
|
5. Acceptance criteria include existing functionality verification
|
||||||
|
|
||||||
|
## Important Notes
|
||||||
|
|
||||||
|
- This task is for VERY SMALL brownfield changes only
|
||||||
|
- If complexity grows during analysis, escalate to brownfield-create-epic
|
||||||
|
- Always prioritize existing system integrity
|
||||||
|
- When in doubt about integration complexity, use brownfield-create-epic instead
|
||||||
|
- Stories should take no more than 4 hours of focused development work
|
||||||
|
|
@ -0,0 +1,368 @@
|
||||||
|
<!-- Powered by BMAD™ Core -->
|
||||||
|
|
||||||
|
# game-risk-profile
|
||||||
|
|
||||||
|
Generate a comprehensive risk assessment matrix for a Godot game story implementation using probability × impact analysis focused on game development challenges.
|
||||||
|
|
||||||
|
## Inputs
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
required:
|
||||||
|
- story_id: '{epic}.{story}' # e.g., "1.3"
|
||||||
|
- story_path: 'docs/stories/{epic}.{story}.*.md'
|
||||||
|
- story_title: '{title}' # If missing, derive from story file H1
|
||||||
|
- story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Identify, assess, and prioritize risks in Godot game feature implementation. Provide risk mitigation strategies and playtesting focus areas based on game development risk levels.
|
||||||
|
|
||||||
|
## Risk Assessment Framework
|
||||||
|
|
||||||
|
### Risk Categories
|
||||||
|
|
||||||
|
**Category Prefixes:**
|
||||||
|
|
||||||
|
- `TECH`: Technical/Engine Risks
|
||||||
|
- `PERF`: Performance/Optimization Risks
|
||||||
|
- `GAME`: Gameplay/Mechanics Risks
|
||||||
|
- `ART`: Art/Asset Pipeline Risks
|
||||||
|
- `PLAT`: Platform/Deployment Risks
|
||||||
|
- `PLAY`: Player Experience Risks
|
||||||
|
|
||||||
|
1. **Technical/Engine Risks (TECH)**
|
||||||
|
- Godot version compatibility issues
|
||||||
|
- GDScript/C# integration problems
|
||||||
|
- Node tree architecture complexity
|
||||||
|
- Signal connection failures
|
||||||
|
- Plugin/addon conflicts
|
||||||
|
- Memory leak in scene transitions
|
||||||
|
|
||||||
|
2. **Performance/Optimization Risks (PERF)**
|
||||||
|
- Frame rate drops below 60 FPS
|
||||||
|
- Draw call bottlenecks
|
||||||
|
- Physics engine slowdowns
|
||||||
|
- Particle system overload
|
||||||
|
- Texture memory exhaustion
|
||||||
|
- Shader compilation spikes
|
||||||
|
|
||||||
|
3. **Gameplay/Mechanics Risks (GAME)**
|
||||||
|
- Game balance issues
|
||||||
|
- Control responsiveness problems
|
||||||
|
- Collision detection failures
|
||||||
|
- AI behavior bugs
|
||||||
|
- Progression breaking bugs
|
||||||
|
- Save/load system corruption
|
||||||
|
|
||||||
|
4. **Art/Asset Pipeline Risks (ART)**
|
||||||
|
- Asset import failures
|
||||||
|
- Texture atlas overflow
|
||||||
|
- Animation sync issues
|
||||||
|
- Audio streaming problems
|
||||||
|
- Font rendering issues
|
||||||
|
- Sprite batching failures
|
||||||
|
|
||||||
|
5. **Platform/Deployment Risks (PLAT)**
|
||||||
|
- Export template issues
|
||||||
|
- Platform-specific bugs
|
||||||
|
- Mobile performance degradation
|
||||||
|
- Web build compatibility
|
||||||
|
- Console certification failures
|
||||||
|
- Steam/itch.io integration problems
|
||||||
|
|
||||||
|
6. **Player Experience Risks (PLAY)**
|
||||||
|
- Tutorial unclear or broken
|
||||||
|
- Difficulty curve too steep/shallow
|
||||||
|
- Multiplayer desync issues
|
||||||
|
- Achievements not triggering
|
||||||
|
- Localization text overflow
|
||||||
|
- Accessibility features missing
|
||||||
|
|
||||||
|
## Risk Analysis Process
|
||||||
|
|
||||||
|
### 1. Risk Identification
|
||||||
|
|
||||||
|
For each category, identify specific risks:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
risk:
|
||||||
|
id: 'PERF-001' # Use prefixes: TECH, PERF, GAME, ART, PLAT, PLAY
|
||||||
|
category: performance
|
||||||
|
title: 'Particle system causing frame drops in boss battle'
|
||||||
|
description: 'Multiple particle emitters active during boss fight drops FPS below 30'
|
||||||
|
affected_components:
|
||||||
|
- 'BossArena.tscn'
|
||||||
|
- 'ParticleManager.gd'
|
||||||
|
- 'BossAttackEffects'
|
||||||
|
detection_method: 'Profiler showed 80% GPU usage on particles'
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. Risk Assessment
|
||||||
|
|
||||||
|
Evaluate each risk using probability × impact:
|
||||||
|
|
||||||
|
**Probability Levels:**
|
||||||
|
|
||||||
|
- `High (3)`: Likely to occur (>70% chance)
|
||||||
|
- `Medium (2)`: Possible occurrence (30-70% chance)
|
||||||
|
- `Low (1)`: Unlikely to occur (<30% chance)
|
||||||
|
|
||||||
|
**Impact Levels:**
|
||||||
|
|
||||||
|
- `High (3)`: Severe consequences (game unplayable, save corruption, platform rejection)
|
||||||
|
- `Medium (2)`: Moderate consequences (noticeable lag, minor bugs, progression issues)
|
||||||
|
- `Low (1)`: Minor consequences (visual glitches, UI issues, quality of life problems)
|
||||||
|
|
||||||
|
### Risk Score = Probability × Impact
|
||||||
|
|
||||||
|
- 9: Critical Risk (Red)
|
||||||
|
- 6: High Risk (Orange)
|
||||||
|
- 4: Medium Risk (Yellow)
|
||||||
|
- 2-3: Low Risk (Green)
|
||||||
|
- 1: Minimal Risk (Blue)
|
||||||
|
|
||||||
|
### 3. Risk Prioritization
|
||||||
|
|
||||||
|
Create risk matrix:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Risk Matrix
|
||||||
|
|
||||||
|
| Risk ID | Description | Probability | Impact | Score | Priority |
|
||||||
|
| -------- | ---------------------------- | ----------- | ---------- | ----- | -------- |
|
||||||
|
| GAME-001 | Boss fight progression block | High (3) | High (3) | 9 | Critical |
|
||||||
|
| PERF-001 | Particle FPS drops | Medium (2) | Medium (2) | 4 | Medium |
|
||||||
|
| PLAT-001 | Mobile export crashes | Low (1) | High (3) | 3 | Low |
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. Risk Mitigation Strategies
|
||||||
|
|
||||||
|
For each identified risk, provide mitigation:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
mitigation:
|
||||||
|
risk_id: 'PERF-001'
|
||||||
|
strategy: 'preventive' # preventive|detective|corrective
|
||||||
|
actions:
|
||||||
|
- 'Implement particle pooling system'
|
||||||
|
- 'Add LOD (Level of Detail) for particle effects'
|
||||||
|
- 'Use GPU particles instead of CPU particles'
|
||||||
|
- 'Limit max particle count per emitter'
|
||||||
|
testing_requirements:
|
||||||
|
- 'Performance profiling on min spec hardware'
|
||||||
|
- 'Stress test with all effects active'
|
||||||
|
- 'FPS monitoring during boss encounters'
|
||||||
|
residual_risk: 'Low - May still drop to 45 FPS on very low-end devices'
|
||||||
|
owner: 'game-dev'
|
||||||
|
timeline: 'Before beta release'
|
||||||
|
```
|
||||||
|
|
||||||
|
## Outputs
|
||||||
|
|
||||||
|
### Output 1: Gate YAML Block
|
||||||
|
|
||||||
|
Generate for pasting into gate file under `risk_summary`:
|
||||||
|
|
||||||
|
**Output rules:**
|
||||||
|
|
||||||
|
- Only include assessed risks; do not emit placeholders
|
||||||
|
- Sort risks by score (desc) when emitting highest and any tabular lists
|
||||||
|
- If no risks: totals all zeros, omit highest, keep recommendations arrays empty
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
# risk_summary (paste into gate file):
|
||||||
|
risk_summary:
|
||||||
|
totals:
|
||||||
|
critical: X # score 9
|
||||||
|
high: Y # score 6
|
||||||
|
medium: Z # score 4
|
||||||
|
low: W # score 2-3
|
||||||
|
highest:
|
||||||
|
id: GAME-001
|
||||||
|
score: 9
|
||||||
|
title: 'Boss fight progression blocker'
|
||||||
|
recommendations:
|
||||||
|
must_fix:
|
||||||
|
- 'Fix collision detection in boss arena'
|
||||||
|
monitor:
|
||||||
|
- 'Track FPS metrics during gameplay'
|
||||||
|
```
|
||||||
|
|
||||||
|
### Output 2: Markdown Report
|
||||||
|
|
||||||
|
**Save to:** `qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md`
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# Risk Profile: Story {epic}.{story}
|
||||||
|
|
||||||
|
Date: {date}
|
||||||
|
Reviewer: Linus (Test Architect)
|
||||||
|
|
||||||
|
## Executive Summary
|
||||||
|
|
||||||
|
- Total Risks Identified: X
|
||||||
|
- Critical Risks: Y
|
||||||
|
- High Risks: Z
|
||||||
|
- Risk Score: XX/100 (calculated)
|
||||||
|
|
||||||
|
## Critical Risks Requiring Immediate Attention
|
||||||
|
|
||||||
|
### 1. [ID]: Risk Title
|
||||||
|
|
||||||
|
**Score: 9 (Critical)**
|
||||||
|
**Probability**: High - Detailed reasoning
|
||||||
|
**Impact**: High - Potential consequences
|
||||||
|
**Mitigation**:
|
||||||
|
|
||||||
|
- Immediate action required
|
||||||
|
- Specific steps to take
|
||||||
|
**Testing Focus**: Specific test scenarios needed
|
||||||
|
|
||||||
|
## Risk Distribution
|
||||||
|
|
||||||
|
### By Category
|
||||||
|
|
||||||
|
- Technical/Engine: X risks (Y critical)
|
||||||
|
- Performance: X risks (Y critical)
|
||||||
|
- Gameplay: X risks (Y critical)
|
||||||
|
- Art/Assets: X risks (Y critical)
|
||||||
|
- Platform: X risks (Y critical)
|
||||||
|
- Player Experience: X risks (Y critical)
|
||||||
|
|
||||||
|
### By Component
|
||||||
|
|
||||||
|
- Game Scenes: X risks
|
||||||
|
- Player Controller: X risks
|
||||||
|
- Enemy AI: X risks
|
||||||
|
- UI/Menus: X risks
|
||||||
|
- Audio System: X risks
|
||||||
|
- Save System: X risks
|
||||||
|
|
||||||
|
## Detailed Risk Register
|
||||||
|
|
||||||
|
[Full table of all risks with scores and mitigations]
|
||||||
|
|
||||||
|
## Risk-Based Testing Strategy
|
||||||
|
|
||||||
|
### Priority 1: Critical Risk Tests
|
||||||
|
|
||||||
|
- Playtesting scenarios for game-breaking bugs
|
||||||
|
- Performance testing on target platforms
|
||||||
|
- Save/load integrity testing
|
||||||
|
- Multiplayer stress testing (if applicable)
|
||||||
|
|
||||||
|
### Priority 2: High Risk Tests
|
||||||
|
|
||||||
|
- Integration test scenarios
|
||||||
|
- Edge case coverage
|
||||||
|
|
||||||
|
### Priority 3: Medium/Low Risk Tests
|
||||||
|
|
||||||
|
- Standard functional tests
|
||||||
|
- Regression test suite
|
||||||
|
|
||||||
|
## Risk Acceptance Criteria
|
||||||
|
|
||||||
|
### Must Fix Before Production
|
||||||
|
|
||||||
|
- All critical risks (score 9)
|
||||||
|
- High risks affecting security/data
|
||||||
|
|
||||||
|
### Can Deploy with Mitigation
|
||||||
|
|
||||||
|
- Medium risks with compensating controls
|
||||||
|
- Low risks with monitoring in place
|
||||||
|
|
||||||
|
### Accepted Risks
|
||||||
|
|
||||||
|
- Document any risks team accepts
|
||||||
|
- Include sign-off from appropriate authority
|
||||||
|
|
||||||
|
## Monitoring Requirements
|
||||||
|
|
||||||
|
Post-release monitoring for:
|
||||||
|
|
||||||
|
- Frame rate metrics and performance stats
|
||||||
|
- Crash reports and error logs
|
||||||
|
- Player progression analytics
|
||||||
|
- Achievement completion rates
|
||||||
|
- Player retention metrics
|
||||||
|
|
||||||
|
## Risk Review Triggers
|
||||||
|
|
||||||
|
Review and update risk profile when:
|
||||||
|
|
||||||
|
- Major gameplay mechanics added
|
||||||
|
- New platforms targeted
|
||||||
|
- Godot engine version upgraded
|
||||||
|
- Performance issues reported by playtesters
|
||||||
|
- Art style or asset pipeline changes
|
||||||
|
- Multiplayer features added
|
||||||
|
```
|
||||||
|
|
||||||
|
## Risk Scoring Algorithm
|
||||||
|
|
||||||
|
Calculate overall story risk score:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Base Score = 100
|
||||||
|
For each risk:
|
||||||
|
- Critical (9): Deduct 20 points
|
||||||
|
- High (6): Deduct 10 points
|
||||||
|
- Medium (4): Deduct 5 points
|
||||||
|
- Low (2-3): Deduct 2 points
|
||||||
|
|
||||||
|
Minimum score = 0 (extremely risky)
|
||||||
|
Maximum score = 100 (minimal risk)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Risk-Based Recommendations
|
||||||
|
|
||||||
|
Based on risk profile, recommend:
|
||||||
|
|
||||||
|
1. **Testing Priority**
|
||||||
|
- Which tests to run first
|
||||||
|
- Additional test types needed
|
||||||
|
- Test environment requirements
|
||||||
|
|
||||||
|
2. **Development Focus**
|
||||||
|
- Code review emphasis areas
|
||||||
|
- Additional validation needed
|
||||||
|
- Security controls to implement
|
||||||
|
|
||||||
|
3. **Deployment Strategy**
|
||||||
|
- Phased rollout for high-risk changes
|
||||||
|
- Feature flags for risky features
|
||||||
|
- Rollback procedures
|
||||||
|
|
||||||
|
4. **Monitoring Setup**
|
||||||
|
- Metrics to track
|
||||||
|
- Alerts to configure
|
||||||
|
- Dashboard requirements
|
||||||
|
|
||||||
|
## Integration with Quality Gates
|
||||||
|
|
||||||
|
**Deterministic gate mapping:**
|
||||||
|
|
||||||
|
- Any risk with score ≥ 9 → Gate = FAIL (unless waived)
|
||||||
|
- Else if any score ≥ 6 → Gate = CONCERNS
|
||||||
|
- Else → Gate = PASS
|
||||||
|
- Unmitigated risks → Document in gate
|
||||||
|
|
||||||
|
### Output 3: Story Hook Line
|
||||||
|
|
||||||
|
**Print this line for review task to quote:**
|
||||||
|
|
||||||
|
```text
|
||||||
|
Risk profile: qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
|
||||||
|
```
|
||||||
|
|
||||||
|
## Key Principles
|
||||||
|
|
||||||
|
- Identify risks early and systematically
|
||||||
|
- Use consistent probability × impact scoring
|
||||||
|
- Provide actionable mitigation strategies
|
||||||
|
- Link risks to specific test requirements
|
||||||
|
- Track residual risk after mitigation
|
||||||
|
- Update risk profile as story evolves
|
||||||
|
|
@ -0,0 +1,219 @@
|
||||||
|
<!-- Powered by BMAD™ Core -->
|
||||||
|
|
||||||
|
# game-test-design
|
||||||
|
|
||||||
|
Create comprehensive Godot game test scenarios using GUT (GDScript) or GoDotTest/GodotTestDriver (C#) with appropriate test level recommendations for game feature implementation.
|
||||||
|
|
||||||
|
## Inputs
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
required:
|
||||||
|
- story_id: '{epic}.{story}' # e.g., "1.3"
|
||||||
|
- story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
|
||||||
|
- story_title: '{title}' # If missing, derive from story file H1
|
||||||
|
- story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Design a complete Godot game test strategy that identifies what to test, at which level (unit/integration/playtesting), and which testing framework to use (GUT for GDScript, GoDotTest/GodotTestDriver for C#). This ensures efficient test coverage for game mechanics, systems, and player experience while maintaining appropriate test boundaries.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
data:
|
||||||
|
- game-test-levels-framework.md # Unit/Integration/Playtesting decision criteria
|
||||||
|
- game-test-priorities-matrix.md # P0/P1/P2/P3 classification for game features
|
||||||
|
frameworks:
|
||||||
|
gdscript:
|
||||||
|
- GUT (Godot Unit Test) # Native GDScript testing framework
|
||||||
|
csharp:
|
||||||
|
- GoDotTest # xUnit-based testing for C#
|
||||||
|
- GodotTestDriver # UI automation and integration testing
|
||||||
|
```
|
||||||
|
|
||||||
|
## Godot Testing Frameworks
|
||||||
|
|
||||||
|
### GUT (Godot Unit Test) - GDScript
|
||||||
|
|
||||||
|
- **Best for**: Game logic, state machines, inventory systems, damage calculations
|
||||||
|
- **Setup**: Install via AssetLib or GitHub
|
||||||
|
- **Test location**: `res://tests/unit/`
|
||||||
|
- **Example**: Testing player health system, weapon damage modifiers
|
||||||
|
|
||||||
|
### GoDotTest - C#
|
||||||
|
|
||||||
|
- **Best for**: C# game systems, complex algorithms, data structures
|
||||||
|
- **Setup**: NuGet package with xUnit integration
|
||||||
|
- **Test location**: `tests/` directory in project root
|
||||||
|
- **Example**: Testing procedural generation, AI decision trees
|
||||||
|
|
||||||
|
### GodotTestDriver - C#
|
||||||
|
|
||||||
|
- **Best for**: UI automation, integration testing, scene transitions
|
||||||
|
- **Setup**: NuGet package for UI testing
|
||||||
|
- **Test location**: `tests/integration/`
|
||||||
|
- **Example**: Testing menu navigation, save/load flows, multiplayer lobbies
|
||||||
|
|
||||||
|
## Process
|
||||||
|
|
||||||
|
### 1. Analyze Story Requirements
|
||||||
|
|
||||||
|
Break down each acceptance criterion into testable game scenarios. For each AC:
|
||||||
|
|
||||||
|
- Identify the core game mechanic or system to test
|
||||||
|
- Determine input variations (controls, player actions)
|
||||||
|
- Consider edge cases (collision boundaries, resource limits)
|
||||||
|
- Note platform-specific behaviors
|
||||||
|
- Identify performance requirements (FPS, memory)
|
||||||
|
|
||||||
|
### 2. Apply Game Test Level Framework
|
||||||
|
|
||||||
|
**Reference:** Load `game-test-levels-framework.md` for detailed criteria
|
||||||
|
|
||||||
|
Quick rules for Godot:
|
||||||
|
|
||||||
|
- **Unit Tests (GUT/GoDotTest)**: Game logic, damage calculations, inventory systems, state machines
|
||||||
|
- **Integration Tests (GUT/GodotTestDriver)**: Scene interactions, signal connections, save/load, physics
|
||||||
|
- **Playtesting**: Full gameplay loops, difficulty balance, fun factor, performance on target hardware
|
||||||
|
|
||||||
|
### 3. Assign Priorities
|
||||||
|
|
||||||
|
**Reference:** Load `test-priorities-matrix.md` for classification
|
||||||
|
|
||||||
|
Quick priority assignment for games:
|
||||||
|
|
||||||
|
- **P0**: Game-breaking bugs, save corruption, core mechanics, progression blockers
|
||||||
|
- **P1**: Combat systems, player movement, UI responsiveness, multiplayer sync
|
||||||
|
- **P2**: Visual effects, audio, achievements, secondary mechanics
|
||||||
|
- **P3**: Cosmetics, easter eggs, optional content
|
||||||
|
|
||||||
|
### 4. Design Test Scenarios
|
||||||
|
|
||||||
|
For each identified test need, create:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
test_scenario:
|
||||||
|
id: '{epic}.{story}-{LEVEL}-{SEQ}'
|
||||||
|
requirement: 'AC reference'
|
||||||
|
priority: P0|P1|P2|P3
|
||||||
|
level: unit|integration|playtest
|
||||||
|
framework: GUT|GoDotTest|GodotTestDriver|Manual
|
||||||
|
description: 'What game feature/mechanic is being tested'
|
||||||
|
justification: 'Why this level and framework were chosen'
|
||||||
|
test_scene: 'res://tests/{TestSceneName}.tscn' # For automated tests
|
||||||
|
mitigates_risks: ['PERF-001', 'GAME-002'] # From risk profile
|
||||||
|
```
|
||||||
|
|
||||||
|
### 5. Validate Coverage
|
||||||
|
|
||||||
|
Ensure:
|
||||||
|
|
||||||
|
- Every AC has at least one test
|
||||||
|
- No duplicate coverage across levels
|
||||||
|
- Critical paths have multiple levels
|
||||||
|
- Risk mitigations are addressed
|
||||||
|
|
||||||
|
## Outputs
|
||||||
|
|
||||||
|
### Output 1: Test Design Document
|
||||||
|
|
||||||
|
**Save to:** `qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md`
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# Test Design: Story {epic}.{story}
|
||||||
|
|
||||||
|
Date: {date}
|
||||||
|
Designer: Quinn (Game Test Architect)
|
||||||
|
|
||||||
|
## Game Test Strategy Overview
|
||||||
|
|
||||||
|
- Total test scenarios: X
|
||||||
|
- Unit tests (GUT/GoDotTest): Y (A%)
|
||||||
|
- Integration tests (GodotTestDriver): Z (B%)
|
||||||
|
- Playtesting scenarios: W (C%)
|
||||||
|
- Framework distribution: GUT: X%, GoDotTest: Y%, Manual: Z%
|
||||||
|
- Priority distribution: P0: X, P1: Y, P2: Z
|
||||||
|
|
||||||
|
## Test Scenarios by Acceptance Criteria
|
||||||
|
|
||||||
|
### AC1: {description}
|
||||||
|
|
||||||
|
#### Scenarios
|
||||||
|
|
||||||
|
| ID | Level | Framework | Priority | Test | Justification |
|
||||||
|
| ------------ | ----------- | --------- | -------- | ----------------------------- | ---------------------------- |
|
||||||
|
| 1.3-UNIT-001 | Unit | GUT | P0 | Player damage calculation | Core combat logic |
|
||||||
|
| 1.3-INT-001 | Integration | GoDotTest | P0 | Enemy AI pathfinding | NavigationAgent2D behavior |
|
||||||
|
| 1.3-PLAY-001 | Playtest | Manual | P1 | Boss fight difficulty balance | Player experience validation |
|
||||||
|
|
||||||
|
[Continue for all ACs...]
|
||||||
|
|
||||||
|
## Risk Coverage
|
||||||
|
|
||||||
|
[Map test scenarios to identified risks if risk profile exists]
|
||||||
|
|
||||||
|
## Recommended Execution Order
|
||||||
|
|
||||||
|
1. P0 Unit tests (fail fast)
|
||||||
|
2. P0 Integration tests
|
||||||
|
3. P0 E2E tests
|
||||||
|
4. P1 tests in order
|
||||||
|
5. P2+ as time permits
|
||||||
|
```
|
||||||
|
|
||||||
|
### Output 2: Gate YAML Block
|
||||||
|
|
||||||
|
Generate for inclusion in quality gate:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
test_design:
|
||||||
|
scenarios_total: X
|
||||||
|
by_level:
|
||||||
|
unit: Y
|
||||||
|
integration: Z
|
||||||
|
playtest: W
|
||||||
|
by_framework:
|
||||||
|
gut: A
|
||||||
|
godottest: B
|
||||||
|
testdriver: C
|
||||||
|
manual: D
|
||||||
|
by_priority:
|
||||||
|
p0: A
|
||||||
|
p1: B
|
||||||
|
p2: C
|
||||||
|
coverage_gaps: [] # List any ACs without tests
|
||||||
|
performance_tests: [] # FPS, memory, load time tests
|
||||||
|
```
|
||||||
|
|
||||||
|
### Output 3: Trace References
|
||||||
|
|
||||||
|
Print for use by trace-requirements task:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Test design matrix: qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
|
||||||
|
P0 tests identified: {count}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Game Testing Quality Checklist
|
||||||
|
|
||||||
|
Before finalizing, verify:
|
||||||
|
|
||||||
|
- [ ] Every AC has test coverage
|
||||||
|
- [ ] Test frameworks match language (GUT for GDScript, GoDotTest for C#)
|
||||||
|
- [ ] Physics and collision tests use proper test scenes
|
||||||
|
- [ ] Performance tests target minimum spec hardware
|
||||||
|
- [ ] Multiplayer tests cover desync scenarios
|
||||||
|
- [ ] Save/load tests verify data integrity
|
||||||
|
- [ ] Platform-specific tests for each export target
|
||||||
|
- [ ] Test scenes are properly organized in res://tests/
|
||||||
|
|
||||||
|
## Key Game Testing Principles
|
||||||
|
|
||||||
|
- **Shift left**: Test game logic early with GUT/GoDotTest before full integration
|
||||||
|
- **Performance first**: Profile early and often, test on min spec
|
||||||
|
- **Player experience**: Balance automated tests with human playtesting
|
||||||
|
- **Framework selection**: GUT for GDScript game logic, GoDotTest for C# systems, GodotTestDriver for UI
|
||||||
|
- **Scene isolation**: Test components in minimal scenes to reduce dependencies
|
||||||
|
- **Fast feedback**: Unit tests in CI/CD, integration tests nightly, playtests per sprint
|
||||||
|
- **Platform coverage**: Test exports on all target platforms regularly
|
||||||
|
|
@ -0,0 +1,281 @@
|
||||||
|
# <!-- Powered by BMAD™ Core -->
|
||||||
|
template:
|
||||||
|
id: brownfield-prd-template-v2
|
||||||
|
name: Brownfield Enhancement PRD
|
||||||
|
version: 2.0
|
||||||
|
output:
|
||||||
|
format: markdown
|
||||||
|
filename: docs/prd.md
|
||||||
|
title: "{{project_name}} Brownfield Enhancement PRD"
|
||||||
|
|
||||||
|
workflow:
|
||||||
|
mode: interactive
|
||||||
|
elicitation: advanced-elicitation
|
||||||
|
|
||||||
|
sections:
|
||||||
|
- id: intro-analysis
|
||||||
|
title: Intro Project Analysis and Context
|
||||||
|
instruction: |
|
||||||
|
IMPORTANT - SCOPE ASSESSMENT REQUIRED:
|
||||||
|
|
||||||
|
This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding:
|
||||||
|
|
||||||
|
1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories."
|
||||||
|
|
||||||
|
2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first.
|
||||||
|
|
||||||
|
3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions.
|
||||||
|
|
||||||
|
Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements.
|
||||||
|
|
||||||
|
CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?"
|
||||||
|
|
||||||
|
Do not proceed with any recommendations until the user has validated your understanding of the existing system.
|
||||||
|
sections:
|
||||||
|
- id: existing-project-overview
|
||||||
|
title: Existing Project Overview
|
||||||
|
instruction: Check if document-project analysis was already performed. If yes, reference that output instead of re-analyzing.
|
||||||
|
sections:
|
||||||
|
- id: analysis-source
|
||||||
|
title: Analysis Source
|
||||||
|
instruction: |
|
||||||
|
Indicate one of the following:
|
||||||
|
- Document-project output available at: {{path}}
|
||||||
|
- IDE-based fresh analysis
|
||||||
|
- User-provided information
|
||||||
|
- id: current-state
|
||||||
|
title: Current Project State
|
||||||
|
instruction: |
|
||||||
|
- If document-project output exists: Extract summary from "High Level Architecture" and "Technical Summary" sections
|
||||||
|
- Otherwise: Brief description of what the project currently does and its primary purpose
|
||||||
|
- id: documentation-analysis
|
||||||
|
title: Available Documentation Analysis
|
||||||
|
instruction: |
|
||||||
|
If document-project was run:
|
||||||
|
- Note: "Document-project analysis available - using existing technical documentation"
|
||||||
|
- List key documents created by document-project
|
||||||
|
- Skip the missing documentation check below
|
||||||
|
|
||||||
|
Otherwise, check for existing documentation:
|
||||||
|
sections:
|
||||||
|
- id: available-docs
|
||||||
|
title: Available Documentation
|
||||||
|
type: checklist
|
||||||
|
items:
|
||||||
|
- Tech Stack Documentation [[LLM: If from document-project, check ✓]]
|
||||||
|
- Source Tree/Architecture [[LLM: If from document-project, check ✓]]
|
||||||
|
- Coding Standards [[LLM: If from document-project, may be partial]]
|
||||||
|
- API Documentation [[LLM: If from document-project, check ✓]]
|
||||||
|
- External API Documentation [[LLM: If from document-project, check ✓]]
|
||||||
|
- UX/UI Guidelines [[LLM: May not be in document-project]]
|
||||||
|
- Technical Debt Documentation [[LLM: If from document-project, check ✓]]
|
||||||
|
- "Other: {{other_docs}}"
|
||||||
|
instruction: |
|
||||||
|
- If document-project was already run: "Using existing project analysis from document-project output."
|
||||||
|
- If critical documentation is missing and no document-project: "I recommend running the document-project task first..."
|
||||||
|
- id: enhancement-scope
|
||||||
|
title: Enhancement Scope Definition
|
||||||
|
instruction: Work with user to clearly define what type of enhancement this is. This is critical for scoping and approach.
|
||||||
|
sections:
|
||||||
|
- id: enhancement-type
|
||||||
|
title: Enhancement Type
|
||||||
|
type: checklist
|
||||||
|
instruction: Determine with user which applies
|
||||||
|
items:
|
||||||
|
- New Feature Addition
|
||||||
|
- Major Feature Modification
|
||||||
|
- Integration with New Systems
|
||||||
|
- Performance/Scalability Improvements
|
||||||
|
- UI/UX Overhaul
|
||||||
|
- Technology Stack Upgrade
|
||||||
|
- Bug Fix and Stability Improvements
|
||||||
|
- "Other: {{other_type}}"
|
||||||
|
- id: enhancement-description
|
||||||
|
title: Enhancement Description
|
||||||
|
instruction: 2-3 sentences describing what the user wants to add or change
|
||||||
|
- id: impact-assessment
|
||||||
|
title: Impact Assessment
|
||||||
|
type: checklist
|
||||||
|
instruction: Assess the scope of impact on existing codebase
|
||||||
|
items:
|
||||||
|
- Minimal Impact (isolated additions)
|
||||||
|
- Moderate Impact (some existing code changes)
|
||||||
|
- Significant Impact (substantial existing code changes)
|
||||||
|
- Major Impact (architectural changes required)
|
||||||
|
- id: goals-context
|
||||||
|
title: Goals and Background Context
|
||||||
|
sections:
|
||||||
|
- id: goals
|
||||||
|
title: Goals
|
||||||
|
type: bullet-list
|
||||||
|
instruction: Bullet list of 1-line desired outcomes this enhancement will deliver if successful
|
||||||
|
- id: background
|
||||||
|
title: Background Context
|
||||||
|
type: paragraphs
|
||||||
|
instruction: 1-2 short paragraphs explaining why this enhancement is needed, what problem it solves, and how it fits with the existing project
|
||||||
|
- id: changelog
|
||||||
|
title: Change Log
|
||||||
|
type: table
|
||||||
|
columns: [Change, Date, Version, Description, Author]
|
||||||
|
|
||||||
|
- id: requirements
|
||||||
|
title: Requirements
|
||||||
|
instruction: |
|
||||||
|
Draft functional and non-functional requirements based on your validated understanding of the existing project. Before presenting requirements, confirm: "These requirements are based on my understanding of your existing system. Please review carefully and confirm they align with your project's reality."
|
||||||
|
elicit: true
|
||||||
|
sections:
|
||||||
|
- id: functional
|
||||||
|
title: Functional
|
||||||
|
type: numbered-list
|
||||||
|
prefix: FR
|
||||||
|
instruction: Each Requirement will be a bullet markdown with identifier starting with FR
|
||||||
|
examples:
|
||||||
|
- "FR1: The existing Todo List will integrate with the new AI duplicate detection service without breaking current functionality."
|
||||||
|
- id: non-functional
|
||||||
|
title: Non Functional
|
||||||
|
type: numbered-list
|
||||||
|
prefix: NFR
|
||||||
|
instruction: Each Requirement will be a bullet markdown with identifier starting with NFR. Include constraints from existing system
|
||||||
|
examples:
|
||||||
|
- "NFR1: Enhancement must maintain existing performance characteristics and not exceed current memory usage by more than 20%."
|
||||||
|
- id: compatibility
|
||||||
|
title: Compatibility Requirements
|
||||||
|
instruction: Critical for brownfield - what must remain compatible
|
||||||
|
type: numbered-list
|
||||||
|
prefix: CR
|
||||||
|
template: "{{requirement}}: {{description}}"
|
||||||
|
items:
|
||||||
|
- id: cr1
|
||||||
|
template: "CR1: {{existing_api_compatibility}}"
|
||||||
|
- id: cr2
|
||||||
|
template: "CR2: {{database_schema_compatibility}}"
|
||||||
|
- id: cr3
|
||||||
|
template: "CR3: {{ui_ux_consistency}}"
|
||||||
|
- id: cr4
|
||||||
|
template: "CR4: {{integration_compatibility}}"
|
||||||
|
|
||||||
|
- id: ui-enhancement-goals
|
||||||
|
title: User Interface Enhancement Goals
|
||||||
|
condition: Enhancement includes UI changes
|
||||||
|
instruction: For UI changes, capture how they will integrate with existing UI patterns and design systems
|
||||||
|
sections:
|
||||||
|
- id: existing-ui-integration
|
||||||
|
title: Integration with Existing UI
|
||||||
|
instruction: Describe how new UI elements will fit with existing design patterns, style guides, and component libraries
|
||||||
|
- id: modified-screens
|
||||||
|
title: Modified/New Screens and Views
|
||||||
|
instruction: List only the screens/views that will be modified or added
|
||||||
|
- id: ui-consistency
|
||||||
|
title: UI Consistency Requirements
|
||||||
|
instruction: Specific requirements for maintaining visual and interaction consistency with existing application
|
||||||
|
|
||||||
|
- id: technical-constraints
|
||||||
|
title: Technical Constraints and Integration Requirements
|
||||||
|
instruction: This section replaces separate architecture documentation. Gather detailed technical constraints from existing project analysis.
|
||||||
|
sections:
|
||||||
|
- id: existing-tech-stack
|
||||||
|
title: Existing Technology Stack
|
||||||
|
instruction: |
|
||||||
|
If document-project output available:
|
||||||
|
- Extract from "Actual Tech Stack" table in High Level Architecture section
|
||||||
|
- Include version numbers and any noted constraints
|
||||||
|
|
||||||
|
Otherwise, document the current technology stack:
|
||||||
|
template: |
|
||||||
|
**Languages**: {{languages}}
|
||||||
|
**Frameworks**: {{frameworks}}
|
||||||
|
**Database**: {{database}}
|
||||||
|
**Infrastructure**: {{infrastructure}}
|
||||||
|
**External Dependencies**: {{external_dependencies}}
|
||||||
|
- id: integration-approach
|
||||||
|
title: Integration Approach
|
||||||
|
instruction: Define how the enhancement will integrate with existing architecture
|
||||||
|
template: |
|
||||||
|
**Database Integration Strategy**: {{database_integration}}
|
||||||
|
**API Integration Strategy**: {{api_integration}}
|
||||||
|
**Frontend Integration Strategy**: {{frontend_integration}}
|
||||||
|
**Testing Integration Strategy**: {{testing_integration}}
|
||||||
|
- id: code-organization
|
||||||
|
title: Code Organization and Standards
|
||||||
|
instruction: Based on existing project analysis, define how new code will fit existing patterns
|
||||||
|
template: |
|
||||||
|
**File Structure Approach**: {{file_structure}}
|
||||||
|
**Naming Conventions**: {{naming_conventions}}
|
||||||
|
**Coding Standards**: {{coding_standards}}
|
||||||
|
**Documentation Standards**: {{documentation_standards}}
|
||||||
|
- id: deployment-operations
|
||||||
|
title: Deployment and Operations
|
||||||
|
instruction: How the enhancement fits existing deployment pipeline
|
||||||
|
template: |
|
||||||
|
**Build Process Integration**: {{build_integration}}
|
||||||
|
**Deployment Strategy**: {{deployment_strategy}}
|
||||||
|
**Monitoring and Logging**: {{monitoring_logging}}
|
||||||
|
**Configuration Management**: {{config_management}}
|
||||||
|
- id: risk-assessment
|
||||||
|
title: Risk Assessment and Mitigation
|
||||||
|
instruction: |
|
||||||
|
If document-project output available:
|
||||||
|
- Reference "Technical Debt and Known Issues" section
|
||||||
|
- Include "Workarounds and Gotchas" that might impact enhancement
|
||||||
|
- Note any identified constraints from "Critical Technical Debt"
|
||||||
|
|
||||||
|
Build risk assessment incorporating existing known issues:
|
||||||
|
template: |
|
||||||
|
**Technical Risks**: {{technical_risks}}
|
||||||
|
**Integration Risks**: {{integration_risks}}
|
||||||
|
**Deployment Risks**: {{deployment_risks}}
|
||||||
|
**Mitigation Strategies**: {{mitigation_strategies}}
|
||||||
|
|
||||||
|
- id: epic-structure
|
||||||
|
title: Epic and Story Structure
|
||||||
|
instruction: |
|
||||||
|
For brownfield projects, favor a single comprehensive epic unless the user is clearly requesting multiple unrelated enhancements. Before presenting the epic structure, confirm: "Based on my analysis of your existing project, I believe this enhancement should be structured as [single epic/multiple epics] because [rationale based on actual project analysis]. Does this align with your understanding of the work required?"
|
||||||
|
elicit: true
|
||||||
|
sections:
|
||||||
|
- id: epic-approach
|
||||||
|
title: Epic Approach
|
||||||
|
instruction: Explain the rationale for epic structure - typically single epic for brownfield unless multiple unrelated features
|
||||||
|
template: "**Epic Structure Decision**: {{epic_decision}} with rationale"
|
||||||
|
|
||||||
|
- id: epic-details
|
||||||
|
title: "Epic 1: {{enhancement_title}}"
|
||||||
|
instruction: |
|
||||||
|
Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
|
||||||
|
|
||||||
|
CRITICAL STORY SEQUENCING FOR BROWNFIELD:
|
||||||
|
- Stories must ensure existing functionality remains intact
|
||||||
|
- Each story should include verification that existing features still work
|
||||||
|
- Stories should be sequenced to minimize risk to existing system
|
||||||
|
- Include rollback considerations for each story
|
||||||
|
- Focus on incremental integration rather than big-bang changes
|
||||||
|
- Size stories for AI agent execution in existing codebase context
|
||||||
|
- MANDATORY: Present the complete story sequence and ask: "This story sequence is designed to minimize risk to your existing system. Does this order make sense given your project's architecture and constraints?"
|
||||||
|
- Stories must be logically sequential with clear dependencies identified
|
||||||
|
- Each story must deliver value while maintaining system integrity
|
||||||
|
template: |
|
||||||
|
**Epic Goal**: {{epic_goal}}
|
||||||
|
|
||||||
|
**Integration Requirements**: {{integration_requirements}}
|
||||||
|
sections:
|
||||||
|
- id: story
|
||||||
|
title: "Story 1.{{story_number}} {{story_title}}"
|
||||||
|
repeatable: true
|
||||||
|
template: |
|
||||||
|
As a {{user_type}},
|
||||||
|
I want {{action}},
|
||||||
|
so that {{benefit}}.
|
||||||
|
sections:
|
||||||
|
- id: acceptance-criteria
|
||||||
|
title: Acceptance Criteria
|
||||||
|
type: numbered-list
|
||||||
|
instruction: Define criteria that include both new functionality and existing system integrity
|
||||||
|
item_template: "{{criterion_number}}: {{criteria}}"
|
||||||
|
- id: integration-verification
|
||||||
|
title: Integration Verification
|
||||||
|
instruction: Specific verification steps to ensure existing functionality remains intact
|
||||||
|
type: numbered-list
|
||||||
|
prefix: IV
|
||||||
|
items:
|
||||||
|
- template: "IV1: {{existing_functionality_verification}}"
|
||||||
|
- template: "IV2: {{integration_point_verification}}"
|
||||||
|
- template: "IV3: {{performance_impact_verification}}"
|
||||||
|
|
@ -4,7 +4,7 @@ template:
|
||||||
version: 3.0
|
version: 3.0
|
||||||
output:
|
output:
|
||||||
format: markdown
|
format: markdown
|
||||||
filename: docs/game-architecture.md
|
filename: docs/architecture.md
|
||||||
title: "{{project_name}} Game Architecture Document"
|
title: "{{project_name}} Game Architecture Document"
|
||||||
|
|
||||||
workflow:
|
workflow:
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,209 @@
|
||||||
|
# <!-- Powered by BMAD™ Core -->
|
||||||
|
template:
|
||||||
|
id: game-prd-template-v2
|
||||||
|
name: Product Requirements Document
|
||||||
|
version: 2.0
|
||||||
|
output:
|
||||||
|
format: markdown
|
||||||
|
filename: docs/game-prd.md
|
||||||
|
title: "{{project_name}} Godot Product Requirements Document (PRD)"
|
||||||
|
|
||||||
|
workflow:
|
||||||
|
mode: interactive
|
||||||
|
elicitation: advanced-elicitation
|
||||||
|
|
||||||
|
sections:
|
||||||
|
- id: goals-context
|
||||||
|
title: Goals and Background Context
|
||||||
|
instruction: |
|
||||||
|
Ask if Project Brief document is available. If NO Project Brief exists, STRONGLY recommend creating one first using game-brief-tmpl (it provides essential foundation: problem statement, target users, success metrics, MVP scope, constraints). If user insists on PRD without brief, gather this information during Goals section. If Project Brief exists, review and use it to populate Goals (bullet list of desired outcomes) and Background Context (1-2 paragraphs on what this solves and why) so we can determine what is and is not in scope for PRD mvp. Either way this is critical to determine the requirements. Include Change Log table.
|
||||||
|
sections:
|
||||||
|
- id: goals
|
||||||
|
title: Goals
|
||||||
|
type: bullet-list
|
||||||
|
instruction: Bullet list of 1 line desired outcomes the game will deliver if successful - player experiences and gameplay goals
|
||||||
|
- id: background
|
||||||
|
title: Background Context
|
||||||
|
type: paragraphs
|
||||||
|
instruction: 1-2 short paragraphs summarizing the game concept, target audience, genre influences, what player need or desire this game fulfills, competitive landscape
|
||||||
|
- id: changelog
|
||||||
|
title: Change Log
|
||||||
|
type: table
|
||||||
|
columns: [Date, Version, Description, Author]
|
||||||
|
instruction: Track document versions and changes
|
||||||
|
|
||||||
|
- id: requirements
|
||||||
|
title: Requirements
|
||||||
|
instruction: Draft the list of functional and non functional requirements under the two child sections
|
||||||
|
elicit: true
|
||||||
|
sections:
|
||||||
|
- id: functional
|
||||||
|
title: Functional
|
||||||
|
type: numbered-list
|
||||||
|
prefix: FR
|
||||||
|
instruction: Each Requirement will be a bullet markdown and an identifier sequence starting with FR
|
||||||
|
examples:
|
||||||
|
- "FR6: The player character can double jump after collecting the Wing Boots power-up."
|
||||||
|
- "FR7: Enemy AI uses Godot's NavigationAgent2D to pathfind around obstacles."
|
||||||
|
- "FR8: The inventory system supports drag-and-drop item management."
|
||||||
|
- id: non-functional
|
||||||
|
title: Non Functional
|
||||||
|
type: numbered-list
|
||||||
|
prefix: NFR
|
||||||
|
instruction: Each Requirement will be a bullet markdown and an identifier sequence starting with NFR
|
||||||
|
examples:
|
||||||
|
- "NFR1: Game must maintain 60 FPS on mid-range hardware (GTX 1060 or equivalent)."
|
||||||
|
- "NFR2: All UI elements must be readable at 720p resolution minimum."
|
||||||
|
- "NFR3: Save files must be compatible across all target platforms."
|
||||||
|
|
||||||
|
- id: ui-goals
|
||||||
|
title: Game UI/UX Design Goals
|
||||||
|
condition: Game has UI/menu requirements
|
||||||
|
instruction: |
|
||||||
|
Capture high-level game UI/UX vision to guide Game Designer and inform implementation. Steps:
|
||||||
|
|
||||||
|
1. Pre-fill all subsections with educated guesses based on game genre and platform
|
||||||
|
2. Present the complete rendered section to user
|
||||||
|
3. Clearly let the user know where assumptions were made
|
||||||
|
4. Ask targeted questions for unclear/missing elements or areas needing more specification
|
||||||
|
5. This is NOT detailed UI spec - focus on player experience and game feel
|
||||||
|
elicit: true
|
||||||
|
choices:
|
||||||
|
accessibility: [None, Basic, Colorblind Support, Full Accessibility]
|
||||||
|
platforms: [PC Only, Mobile Only, PC + Mobile, PC + Console, All Platforms]
|
||||||
|
sections:
|
||||||
|
- id: ux-vision
|
||||||
|
title: Overall Game UX Vision
|
||||||
|
- id: interaction-paradigms
|
||||||
|
title: Control Schemes and Input Methods
|
||||||
|
- id: core-screens
|
||||||
|
title: Core Game Screens and Menus
|
||||||
|
instruction: From a game design perspective, what are the most critical screens, menus, and HUD elements necessary to deliver the gameplay experience? This is meant to be Conceptual High Level to Drive Rough Epic or Game Stories
|
||||||
|
examples:
|
||||||
|
- "Main Menu"
|
||||||
|
- "Game HUD (health, score, inventory)"
|
||||||
|
- "Pause Menu"
|
||||||
|
- "Level Select Screen"
|
||||||
|
- "Character Customization"
|
||||||
|
- "Settings/Options Menu"
|
||||||
|
- id: accessibility
|
||||||
|
title: "Accessibility: {None|Basic|Colorblind Support|Full Accessibility}"
|
||||||
|
- id: branding
|
||||||
|
title: Branding
|
||||||
|
instruction: Any known branding elements or style guides that must be incorporated?
|
||||||
|
examples:
|
||||||
|
- "Pixel art style inspired by 16-bit era JRPGs with modern lighting effects."
|
||||||
|
- "Dark fantasy aesthetic with muted colors and Gothic UI elements."
|
||||||
|
- "Vibrant cartoon style with thick outlines and cel-shading."
|
||||||
|
- id: target-platforms
|
||||||
|
title: "Target Platforms: {PC Only|Mobile Only|PC + Mobile|PC + Console|All Platforms}"
|
||||||
|
examples:
|
||||||
|
- "Windows, Linux, Mac via Steam"
|
||||||
|
- "iOS and Android via App Stores"
|
||||||
|
- "PC (Steam) + Nintendo Switch"
|
||||||
|
- "Web export for itch.io"
|
||||||
|
|
||||||
|
- id: technical-assumptions
|
||||||
|
title: Godot Technical Assumptions
|
||||||
|
instruction: |
|
||||||
|
Gather Godot-specific technical decisions that will guide development. Steps:
|
||||||
|
|
||||||
|
1. Check if {root}/data/godot-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices
|
||||||
|
2. Ask user about: Godot version, 2D/3D, GDScript/C#, plugins/addons, target platforms, networking needs
|
||||||
|
3. For unknowns, offer guidance based on game type and target platforms
|
||||||
|
4. Document ALL technical choices with rationale (why this choice fits the game)
|
||||||
|
5. These become constraints for development - be specific and complete
|
||||||
|
elicit: true
|
||||||
|
choices:
|
||||||
|
godot_version: [Godot 4.4, Godot 4.3, Godot 3.x]
|
||||||
|
architecture: [Single Player, Local Multiplayer, Online Multiplayer, MMO]
|
||||||
|
testing: [Manual Playtesting, Automated Tests, Both]
|
||||||
|
sections:
|
||||||
|
- id: godot-version
|
||||||
|
title: "Godot Version: {4.4|4.3|3.x}"
|
||||||
|
- id: game-architecture
|
||||||
|
title: Game Architecture
|
||||||
|
instruction: "CRITICAL DECISION - Document the game architecture (e.g., Single Player, Local Co-op, Online PvP, Server-Authoritative Multiplayer, P2P)."
|
||||||
|
- id: testing-requirements
|
||||||
|
title: Testing & QA Requirements
|
||||||
|
instruction: "CRITICAL DECISION - Document playtesting approach, automated testing needs (if any), performance profiling requirements, platform certification requirements."
|
||||||
|
- id: additional-assumptions
|
||||||
|
title: Additional Godot Technical Assumptions
|
||||||
|
instruction: Throughout the entire process of drafting this document, if any other Godot-specific technical assumptions are raised (rendering pipeline, physics engine settings, audio system, input handling), add them here as additional bulleted items
|
||||||
|
|
||||||
|
- id: epic-list
|
||||||
|
title: Epic List
|
||||||
|
instruction: |
|
||||||
|
Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
|
||||||
|
|
||||||
|
CRITICAL: Epics MUST be logically sequential following agile best practices:
|
||||||
|
|
||||||
|
- Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
|
||||||
|
- Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic!
|
||||||
|
- Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
|
||||||
|
- Not every project needs multiple epics, an epic needs to deliver value. For example, an API completed can deliver value even if a UI is not complete and planned for a separate epic.
|
||||||
|
- Err on the side of less epics, but let the user know your rationale and offer options for splitting them if it seems some are too large or focused on disparate things.
|
||||||
|
- Cross Cutting Concerns should flow through epics and stories and not be final stories. For example, adding a logging framework as a last story of an epic, or at the end of a project as a final epic or story would be terrible as we would not have logging from the beginning.
|
||||||
|
elicit: true
|
||||||
|
examples:
|
||||||
|
- "Epic 1: Foundation & Core Systems: Setup Godot project, implement player controller, and basic game loop"
|
||||||
|
- "Epic 2: Core Gameplay Mechanics: Implement primary game mechanics, combat/interaction systems"
|
||||||
|
- "Epic 3: Level Design & Content: Create levels, enemies, and game progression"
|
||||||
|
- "Epic 4: Polish & Game Feel: Add VFX, audio, juice, and game polish"
|
||||||
|
- "Epic 5: Menus & Meta Systems: Implement save/load, settings, achievements"
|
||||||
|
|
||||||
|
- id: epic-details
|
||||||
|
title: Epic {{epic_number}} {{epic_title}}
|
||||||
|
repeatable: true
|
||||||
|
instruction: |
|
||||||
|
After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit.
|
||||||
|
|
||||||
|
For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve).
|
||||||
|
|
||||||
|
CRITICAL STORY SEQUENCING REQUIREMENTS:
|
||||||
|
|
||||||
|
- Stories within each epic MUST be logically sequential
|
||||||
|
- Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation
|
||||||
|
- No story should depend on work from a later story or epic
|
||||||
|
- Identify and note any direct prerequisite stories
|
||||||
|
- Focus on "what" and "why" not "how" (leave technical implementation to Architect) yet be precise enough to support a logical sequential order of operations from story to story.
|
||||||
|
- Ensure each story delivers clear user or business value, try to avoid enablers and build them into stories that deliver value.
|
||||||
|
- Size stories for AI agent execution: Each story must be completable by a single AI agent in one focused session without context overflow
|
||||||
|
- Think "junior developer working for 2-4 hours" - stories must be small, focused, and self-contained
|
||||||
|
- If a story seems complex, break it down further as long as it can deliver a vertical slice
|
||||||
|
elicit: true
|
||||||
|
template: "{{epic_goal}}"
|
||||||
|
sections:
|
||||||
|
- id: story
|
||||||
|
title: Story {{epic_number}}.{{story_number}} {{story_title}}
|
||||||
|
repeatable: true
|
||||||
|
template: |
|
||||||
|
As a {{user_type}},
|
||||||
|
I want {{action}},
|
||||||
|
so that {{benefit}}.
|
||||||
|
sections:
|
||||||
|
- id: acceptance-criteria
|
||||||
|
title: Acceptance Criteria
|
||||||
|
type: numbered-list
|
||||||
|
item_template: "{{criterion_number}}: {{criteria}}"
|
||||||
|
repeatable: true
|
||||||
|
instruction: |
|
||||||
|
Define clear, comprehensive, and testable acceptance criteria that:
|
||||||
|
|
||||||
|
- Precisely define what "done" means from a functional perspective
|
||||||
|
- Are unambiguous and serve as basis for verification
|
||||||
|
- Include any critical non-functional requirements from the PRD
|
||||||
|
- Consider local testability for backend/data components
|
||||||
|
- Specify UI/UX requirements and framework adherence where applicable
|
||||||
|
- Avoid cross-cutting concerns that should be in other stories or PRD sections
|
||||||
|
|
||||||
|
- id: checklist-results
|
||||||
|
title: Checklist Results Report
|
||||||
|
instruction: Before running the checklist and drafting the prompts, offer to output the full updated PRD. If outputting it, confirm with the user that you will be proceeding to run the checklist and produce the report. Once the user confirms, execute the pm-checklist and populate the results in this section.
|
||||||
|
|
||||||
|
- id: next-steps
|
||||||
|
title: Next Steps
|
||||||
|
sections:
|
||||||
|
- id: architect-prompt
|
||||||
|
title: Game Architect Prompt
|
||||||
|
instruction: This section will contain the prompt for the Game Architect, keep it short and to the point to initiate Godot architecture design using this document as input.
|
||||||
|
|
@ -10,209 +10,236 @@ workflow:
|
||||||
- godot-web-export
|
- godot-web-export
|
||||||
- godot-vr-game
|
- godot-vr-game
|
||||||
- godot-multiplayer-game
|
- godot-multiplayer-game
|
||||||
full_game_sequence:
|
sequence:
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
creates: game-brief.md
|
creates: project-brief.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
- godot_genre_analysis
|
- godot_genre_analysis
|
||||||
- godot_asset_store_research
|
- godot_asset_store_research
|
||||||
- target_platform_capabilities
|
- target_platform_capabilities
|
||||||
notes: "Define game concept with Godot's strengths in mind (2D pixel-perfect, procedural generation, shader effects). Consider Godot's export targets and platform-specific features. SAVE OUTPUT: Copy final game-brief.md to your project's docs/design/ folder."
|
notes: "Define game concept with Godot's strengths in mind (2D pixel-perfect, procedural generation, shader effects). Consider Godot's export targets and platform-specific features. SAVE OUTPUT: Copy final project-brief.md to your project's docs/design/ folder."
|
||||||
|
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
creates: game-design-doc.md
|
creates: game-design-doc.md
|
||||||
requires: game-brief.md
|
requires: project-brief.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
- godot_node_system_planning
|
- godot_node_system_planning
|
||||||
- scene_hierarchy_design
|
- scene_hierarchy_design
|
||||||
- input_map_configuration
|
- input_map_configuration
|
||||||
notes: "Create Godot-specific GDD defining node hierarchies, scene transitions, input actions, and resource preloading strategies. Map mechanics to Godot's built-in nodes (Area2D, CharacterBody2D, RigidBody2D). SAVE OUTPUT: Copy final game-design-doc.md to your project's docs/design/ folder."
|
notes: "Create Godot-specific GDD defining node hierarchies, scene transitions, input actions, and resource preloading strategies. Map mechanics to Godot's built-in nodes (Area2D, CharacterBody2D, RigidBody2D). SAVE OUTPUT: Copy final game-design-doc.md to your project's docs/design/ folder."
|
||||||
|
|
||||||
- agent: game-designer
|
- agent: game-designer
|
||||||
creates: level-design-doc.md
|
creates: level-design-doc.md (optional)
|
||||||
requires: game-design-doc.md
|
requires: game-design-doc.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
- tilemap_system_design
|
- tilemap_system_design
|
||||||
- scene_instancing_strategy
|
- scene_instancing_strategy
|
||||||
- godot_room_system_planning
|
- godot_room_system_planning
|
||||||
notes: "Design levels using Godot's TileMap, GridMap, or modular scene approach. Define scene instancing patterns, resource groups, and level streaming strategy. SAVE OUTPUT: Copy final level-design-doc.md to your project's docs/design/ folder."
|
notes: "OPTIONAL BUT RECOMMENDED: Design levels using Godot's TileMap, GridMap, or modular scene approach. Define scene instancing patterns, resource groups, and level streaming strategy. SAVE OUTPUT: Copy final level-design-doc.md to your project's docs/design/ folder."
|
||||||
|
|
||||||
|
- agent: game-pm
|
||||||
|
creates: prd.md
|
||||||
|
requires:
|
||||||
|
- project-brief.md
|
||||||
|
- game-design-doc.md
|
||||||
|
notes: "Creates PRD from project brief using game-prd-tmpl. SAVE OUTPUT: Copy final prd.md to your project's docs/ folder."
|
||||||
|
|
||||||
- agent: game-architect
|
- agent: game-architect
|
||||||
creates: game-architecture.md
|
creates: architecture.md
|
||||||
requires:
|
requires:
|
||||||
- game-design-doc.md
|
- game-design-doc.md
|
||||||
- level-design-doc.md
|
- prd.md
|
||||||
optional_steps:
|
optional_steps:
|
||||||
- godot_autoload_architecture
|
- godot_autoload_architecture
|
||||||
- signal_bus_design
|
- signal_bus_design
|
||||||
- resource_loading_strategy
|
- resource_loading_strategy
|
||||||
- gdextension_evaluation
|
- gdextension_evaluation
|
||||||
notes: "Design Godot-specific architecture: autoload singletons, signal bus patterns, scene tree organization, resource loading (preload vs load), and GDScript/C#/GDExtension strategy. Define custom nodes, resources, and editor tools. SAVE OUTPUT: Copy final game-architecture.md to your project's docs/architecture/ folder."
|
notes: "Design Godot-specific architecture: autoload singletons, signal bus patterns, scene tree organization, resource loading (preload vs load), and GDScript/C#/GDExtension strategy. Define custom nodes, resources, and editor tools. SAVE OUTPUT: Copy final architecture.md to your project's docs/architecture/ folder."
|
||||||
- agent: game-designer
|
|
||||||
validates: design_consistency
|
- agent: game-pm
|
||||||
requires: all_design_documents
|
updates: prd.md (if needed)
|
||||||
uses: game-design-checklist
|
requires: architecture.md
|
||||||
notes: Validate all design documents for consistency, completeness, and implementability. May require updates to any design document.
|
condition: architecture_suggests_prd_changes
|
||||||
|
notes: "If game-architect suggests story changes, update PRD and re-export the complete unredacted prd.md to docs/ folder."
|
||||||
|
|
||||||
|
- agent: game-po
|
||||||
|
validates: all_artifacts
|
||||||
|
uses: po-master-checklist
|
||||||
|
notes: "Validates all documents for consistency and completeness. May require updates to any document."
|
||||||
|
|
||||||
- agent: various
|
- agent: various
|
||||||
updates: flagged_design_documents
|
updates: any_flagged_documents
|
||||||
condition: design_validation_issues
|
condition: po_checklist_issues
|
||||||
notes: If design validation finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder.
|
notes: "If game-po finds issues, return to relevant agent to fix and re-export updated documents to docs/ folder."
|
||||||
project_setup_guidance:
|
|
||||||
action: initialize_godot_project
|
- project_setup_guidance:
|
||||||
notes: "Create Godot 4.x project with proper folder structure: scenes/, scripts/, resources/, shaders/, addons/. Configure project settings: rendering (Forward+/Mobile), physics tick rate, input map, autoloads. Install GUT for GDScript testing, configure export presets for target platforms."
|
action: initialize_godot_project
|
||||||
workflow_end:
|
notes: "Create Godot 4.x project with proper folder structure: scenes/, scripts/, resources/, shaders/, addons/. Configure project settings: rendering (Forward+/Mobile), physics tick rate, input map, autoloads. Install GUT for GDScript testing, configure export presets for target platforms."
|
||||||
action: move_to_story_development
|
|
||||||
notes: All design artifacts complete. Begin story-driven development phase. Use Game Scrum Master to create implementation stories from design documents.
|
- agent: game-po
|
||||||
prototype_sequence:
|
action: shard_documents
|
||||||
- step: prototype_scope
|
creates: sharded_docs
|
||||||
action: assess_prototype_complexity
|
requires: all_artifacts_in_project
|
||||||
notes: First, assess if this needs full game design (use full_game_sequence) or can be a rapid prototype.
|
notes: |
|
||||||
- agent: game-designer
|
Shard documents for IDE development:
|
||||||
creates: game-brief.md
|
- Option A: Use PO agent to shard: @game-po then ask to shard docs/prd.md
|
||||||
optional_steps:
|
- Option B: Manual: Drag shard-doc task + docs/prd.md into chat
|
||||||
- godot_rapid_prototyping
|
- Creates docs/prd/ and docs/architecture/ folders with sharded content
|
||||||
- built_in_node_selection
|
|
||||||
notes: "Create focused brief leveraging Godot's rapid prototyping capabilities. Use built-in nodes and CSG for quick iteration. SAVE OUTPUT: Copy final game-brief.md to your project's docs/ folder."
|
- agent: game-sm
|
||||||
- agent: game-designer
|
action: create_story
|
||||||
creates: prototype-design.md
|
creates: story.md
|
||||||
uses: create-doc prototype-design OR create-game-story
|
requires: sharded_docs
|
||||||
requires: game-brief.md
|
repeats: for_each_epic
|
||||||
notes: "Define minimal viable scenes and node structure. Focus on Godot's built-in nodes for rapid development. Use @tool scripts for in-editor prototyping."
|
notes: |
|
||||||
prototype_workflow_end:
|
Story creation cycle:
|
||||||
action: move_to_rapid_implementation
|
- SM Agent (New Chat): @game-sm → *create
|
||||||
notes: Prototype defined. Begin immediate implementation with Game Developer. Focus on core mechanics first, then iterate based on playtesting.
|
- Creates next story from sharded docs
|
||||||
|
- Story starts in "Draft" status
|
||||||
|
|
||||||
|
- agent: game-qa
|
||||||
|
action: test_design
|
||||||
|
updates: story.md
|
||||||
|
requires: story.md
|
||||||
|
optional: true
|
||||||
|
condition: user_wants_test_design
|
||||||
|
notes: |
|
||||||
|
OPTIONAL: Design tests for draft story
|
||||||
|
- Analyze story for possible risks
|
||||||
|
- Create tests to mitigate those risks
|
||||||
|
|
||||||
|
- agent: game-po
|
||||||
|
action: review_draft_story
|
||||||
|
updates: story.md
|
||||||
|
requires: story.md
|
||||||
|
optional: true
|
||||||
|
condition: user_wants_story_review
|
||||||
|
notes: |
|
||||||
|
OPTIONAL: Review and approve draft story
|
||||||
|
- Review story completeness and alignment
|
||||||
|
- Update story status: Draft → Approved
|
||||||
|
|
||||||
|
- agent: game-dev
|
||||||
|
action: implement_story
|
||||||
|
creates: implementation_files
|
||||||
|
requires: story.md
|
||||||
|
notes: |
|
||||||
|
Dev Agent (New Chat): @game-dev
|
||||||
|
- Implements approved story
|
||||||
|
- Updates File List with all changes
|
||||||
|
- Marks story as "Review" when complete
|
||||||
|
|
||||||
|
- agent: game-qa
|
||||||
|
action: review_implementation
|
||||||
|
updates: implementation_files
|
||||||
|
requires: implementation_files
|
||||||
|
optional: true
|
||||||
|
notes: |
|
||||||
|
OPTIONAL: QA Agent (New Chat): @qa → review-story
|
||||||
|
- Senior dev review with refactoring ability
|
||||||
|
- Fixes small issues directly
|
||||||
|
- Leaves checklist for remaining items
|
||||||
|
- Updates story status (Review → Done or stays Review)
|
||||||
|
|
||||||
|
- agent: game-dev
|
||||||
|
action: address_qa_feedback
|
||||||
|
updates: implementation_files
|
||||||
|
condition: qa_left_unchecked_items
|
||||||
|
notes: |
|
||||||
|
If QA left unchecked items:
|
||||||
|
- Dev Agent (New Chat): Address remaining items
|
||||||
|
- Return to QA for final approval
|
||||||
|
|
||||||
|
- repeat_development_cycle: ""
|
||||||
|
action: continue_for_all_stories
|
||||||
|
notes: |
|
||||||
|
Repeat story cycle (SM → Dev → QA) for all epic stories
|
||||||
|
Continue until all stories in PRD are complete
|
||||||
|
|
||||||
|
- agent: game-po
|
||||||
|
action: epic_retrospective
|
||||||
|
creates: epic-retrospective.md
|
||||||
|
condition: epic_complete
|
||||||
|
optional: true
|
||||||
|
notes: |
|
||||||
|
OPTIONAL: After epic completion
|
||||||
|
- NOTE: epic-retrospective task coming soon
|
||||||
|
- Validate epic was completed correctly
|
||||||
|
- Document learnings and improvements
|
||||||
|
|
||||||
|
- workflow_end: ""
|
||||||
|
action: project_complete
|
||||||
|
notes: |
|
||||||
|
All stories implemented and reviewed!
|
||||||
|
Project development phase complete.
|
||||||
|
|
||||||
|
Reference: {root}/data/bmad-kb.md#IDE Development Workflow
|
||||||
|
|
||||||
flow_diagram: |
|
flow_diagram: |
|
||||||
```mermaid
|
```mermaid
|
||||||
graph TD
|
graph TD
|
||||||
A[Start: Game Development Project] --> B{Project Scope?}
|
A[Start: Greenfield Project] --> B[game-designer: project-brief.md]
|
||||||
B -->|Full Game/Production| C[game-designer: game-brief.md]
|
B --> C[game-pm: prd.md]
|
||||||
B -->|Prototype/Game Jam| D[game-designer: focused game-brief.md]
|
C --> D[game-architect: architecture.md]
|
||||||
|
D --> E{Architecture suggests PRD changes?}
|
||||||
C --> E[game-designer: game-design-doc.md]
|
E -->|Yes| F[game-pm: update prd.md]
|
||||||
E --> F[game-designer: level-design-doc.md]
|
E-->|No| G[game-po: validate all artifacts]
|
||||||
F --> G[game-architect: game-architecture.md]
|
F--> G
|
||||||
G --> H[game-designer: validate design consistency]
|
G --> I{game-po finds issues?}
|
||||||
H --> I{Design validation issues?}
|
|
||||||
I -->|Yes| J[Return to relevant agent for fixes]
|
I -->|Yes| J[Return to relevant agent for fixes]
|
||||||
I -->|No| K[Set up game project structure]
|
I -->|No| K[game-po: shard documents]
|
||||||
J --> H
|
J --> H
|
||||||
K --> L[Move to Story Development Phase]
|
|
||||||
|
|
||||||
D --> M[game-designer: prototype-design.md]
|
K --> L[game-sm: create story]
|
||||||
M --> N[Move to Rapid Implementation]
|
L --> M{Review draft story?}
|
||||||
|
M -->|Yes| N[game-po: review & approve story]
|
||||||
|
M -->|No| O[game-dev: implement story]
|
||||||
|
N --> O
|
||||||
|
O --> P{QA review?}
|
||||||
|
P -->|Yes| Q[game-qa: review implementation]
|
||||||
|
P -->|No| R{More stories?}
|
||||||
|
Q --> S{QA found issues?}
|
||||||
|
S -->|Yes| T[game-dev: address QA feedback]
|
||||||
|
S -->|No| R
|
||||||
|
T --> Q
|
||||||
|
R -->|Yes| L
|
||||||
|
R -->|No| U{Epic retrospective?}
|
||||||
|
U -->|Yes| V[game-po: epic retrospective]
|
||||||
|
U -->|No| W[Project Complete]
|
||||||
|
V --> W
|
||||||
|
|
||||||
C -.-> C1[Optional: brainstorming]
|
B -.-> B1[Optional: brainstorming]
|
||||||
C -.-> C2[Optional: game research]
|
B -.-> B2[Optional: market research]
|
||||||
E -.-> E1[Optional: competitive analysis]
|
C -.-> C1[Optional: user research]
|
||||||
F -.-> F1[Optional: level prototyping]
|
F -.-> D1[Optional: technical research]
|
||||||
G -.-> G1[Optional: technical research]
|
|
||||||
D -.-> D1[Optional: quick brainstorming]
|
|
||||||
|
|
||||||
style L fill:#90EE90
|
style W fill:#90EE90
|
||||||
style N fill:#90EE90
|
style K fill:#ADD8E6
|
||||||
|
style L fill:#ADD8E6
|
||||||
|
style O fill:#ADD8E6
|
||||||
|
style B fill:#FFE4B5
|
||||||
style C fill:#FFE4B5
|
style C fill:#FFE4B5
|
||||||
|
style D fill:#FFE4B5
|
||||||
style E fill:#FFE4B5
|
style E fill:#FFE4B5
|
||||||
style F fill:#FFE4B5
|
style N fill:#F0E68C
|
||||||
style G fill:#FFE4B5
|
style Q fill:#F0E68C
|
||||||
style D fill:#FFB6C1
|
style V fill:#F0E68C
|
||||||
style M fill:#FFB6C1
|
|
||||||
```
|
```
|
||||||
godot_specific_guidance:
|
|
||||||
scene_organization:
|
|
||||||
- Main.tscn as root scene with game state management
|
|
||||||
- Modular scenes for reusable components
|
|
||||||
- Inherited scenes for variations
|
|
||||||
- Packed scenes for dynamic instantiation
|
|
||||||
node_patterns:
|
|
||||||
- Use Area2D for triggers and detection zones
|
|
||||||
- CharacterBody2D for player and NPCs
|
|
||||||
- RigidBody2D for physics objects
|
|
||||||
- Control nodes for all UI elements
|
|
||||||
- Node2D for logical grouping
|
|
||||||
resource_management:
|
|
||||||
- Custom resources (.tres) for game data
|
|
||||||
- Preload vs dynamic loading strategies
|
|
||||||
- Resource groups for batch loading
|
|
||||||
- Import settings optimization per asset type
|
|
||||||
godot_tools:
|
|
||||||
- Use Godot's built-in profiler throughout development
|
|
||||||
- Debug with remote scene tree inspection
|
|
||||||
- Leverage editor plugins for workflow enhancement
|
|
||||||
- Create @tool scripts for design-time helpers
|
|
||||||
decision_guidance:
|
decision_guidance:
|
||||||
use_full_sequence_when:
|
when_to_use:
|
||||||
- Building complex Godot games with multiple scenes
|
- Building complex Godot games with multiple scenes
|
||||||
- Implementing networked multiplayer with Godot's high-level API
|
- Implementing networked multiplayer with Godot's high-level API
|
||||||
- Creating games with complex shader pipelines
|
- Complex feature requirements
|
||||||
- Developing for multiple Godot export targets (Desktop, Mobile, Web)
|
- Need comprehensive documentation
|
||||||
- Using GDExtension for performance-critical systems
|
- Long-term maintenance expected
|
||||||
- Building modular games with Godot's resource system
|
|
||||||
- Requiring custom editor tools and plugins
|
|
||||||
use_prototype_sequence_when:
|
|
||||||
- Game jams using Godot's rapid development features
|
|
||||||
- Testing Godot-specific mechanics (physics, particles, shaders)
|
|
||||||
- Leveraging Godot's built-in nodes without custom code
|
|
||||||
- Single-scene prototypes or tech demos
|
|
||||||
- Learning Godot's node and signal systems
|
|
||||||
- Quick experiments with Godot's animation tools
|
|
||||||
handoff_prompts:
|
handoff_prompts:
|
||||||
designer_to_gdd: Game brief is complete. Save it as docs/design/game-brief.md in your project, then create the comprehensive Game Design Document.
|
analyst_to_pm: "Project brief is complete. Save it as docs/project-brief.md in your project, then create the PRD."
|
||||||
gdd_to_level: Game Design Document ready. Save it as docs/design/game-design-doc.md, then create the level design framework.
|
pm_to_ux: "PRD is ready. Save it as docs/prd.md in your project, then create the UI/UX specification."
|
||||||
level_to_architect: Level design complete. Save it as docs/design/level-design-doc.md, then create the technical architecture.
|
ux_to_architect: "UI/UX spec complete. Save it as docs/front-end-spec.md in your project, then create the fullstack architecture."
|
||||||
architect_review: Architecture complete. Save it as docs/architecture/game-architecture.md. Please validate all design documents for consistency.
|
architect_review: "Architecture complete. Save it as docs/architecture.md. Do you suggest any changes to the PRD stories or need new stories added?"
|
||||||
validation_issues: Design validation found issues with [document]. Please return to [agent] to fix and re-save the updated document.
|
architect_to_pm: "Please update the PRD with the suggested story changes, then re-export the complete prd.md to docs/."
|
||||||
full_complete: All design artifacts validated and saved. Set up game project structure and move to story development phase.
|
updated_to_po: "All documents ready in docs/ folder. Please validate all artifacts for consistency."
|
||||||
prototype_designer_to_dev: Prototype brief complete. Save it as docs/game-brief.md, then create minimal design or jump directly to implementation stories.
|
po_issues: "PO found issues with [document]. Please return to [agent] to fix and re-save the updated document."
|
||||||
prototype_complete: Prototype defined. Begin rapid implementation focusing on core mechanics and immediate playability.
|
complete: "All planning artifacts validated and saved in docs/ folder. Move to IDE environment to begin development."
|
||||||
story_development_guidance:
|
|
||||||
epic_breakdown:
|
|
||||||
- Godot Scene Architecture" - Main scene tree, autoloads, and scene transitions
|
|
||||||
- Node Systems" - Player controllers, enemies, pickups using Godot nodes
|
|
||||||
- Physics & Collision" - Godot physics layers, areas, and collision shapes
|
|
||||||
- UI & Control Nodes" - Godot Control nodes, themes, and responsive UI
|
|
||||||
- Audio with AudioStreamPlayer" - Godot audio buses, effects, and 3D audio
|
|
||||||
- Shader & Visual Effects" - Godot shader language, particles, and post-processing
|
|
||||||
- Platform Export & Optimization" - Export templates, platform-specific features
|
|
||||||
story_creation_process:
|
|
||||||
- Create stories with specific Godot node types and scene structures
|
|
||||||
- Reference Godot documentation and built-in class requirements
|
|
||||||
- Include Godot performance monitors targets (draw calls, physics process)
|
|
||||||
- Specify signal connections and node paths
|
|
||||||
- Define resource types (.tres, .tscn, .gdshader)
|
|
||||||
- Enforce GUT test creation before implementation
|
|
||||||
- Include export settings and platform considerations
|
|
||||||
- Reference Godot's scene inheritance and composition patterns
|
|
||||||
godot_development_best_practices:
|
|
||||||
performance_targets:
|
|
||||||
- Monitor Godot Profiler: 60+ FPS, <1000 draw calls, <16ms frame time
|
|
||||||
- Use Godot's performance monitors for memory tracking
|
|
||||||
- Optimize with Godot's occlusion culling and LOD systems
|
|
||||||
- Leverage Godot's threading (WorkerThreadPool) for heavy operations
|
|
||||||
godot_technical_standards:
|
|
||||||
- Use @export annotations for inspector variables
|
|
||||||
- Implement _ready(), _process(), _physics_process() correctly
|
|
||||||
- Prefer signals over hard references between nodes
|
|
||||||
- Use Godot's resource system for data-driven design
|
|
||||||
- Implement @tool scripts for editor functionality
|
|
||||||
- Configure Project Settings for target platform optimization
|
|
||||||
- Use Godot's built-in pooling (PackedArrays) for performance
|
|
||||||
godot_specific_patterns:
|
|
||||||
- Scene inheritance for variant creation
|
|
||||||
- Composition over inheritance with scene instancing
|
|
||||||
- Resource scripts for custom data types
|
|
||||||
- AnimationTree for complex state machines
|
|
||||||
- Navigation2D/3D for pathfinding
|
|
||||||
- MultiplayerAPI for networking
|
|
||||||
success_criteria:
|
|
||||||
design_phase_complete:
|
|
||||||
- Godot-specific design documents validated
|
|
||||||
- Node hierarchy and scene structure defined
|
|
||||||
- Signal architecture documented
|
|
||||||
- Resource loading strategy established
|
|
||||||
- Autoload singletons identified
|
|
||||||
godot_implementation_readiness:
|
|
||||||
- Godot 4.x installed with required export templates
|
|
||||||
- Project settings configured (rendering, physics, input)
|
|
||||||
- GUT addon installed and test structure created
|
|
||||||
- Version control configured with .gitignore for Godot
|
|
||||||
- Editor settings standardized across team
|
|
||||||
- Custom editor tools/plugins identified
|
|
||||||
- First scene structure and node hierarchy created
|
|
||||||
- Base scripts with proper Godot lifecycle methods ready
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue