Godot Game Dev expansion pack for BMAD (#532)
* Godot Game Dev expansion pack for BMAD * Workflow changes * Workflow changes * Fixing config.yaml, editing README.md to indicate correct workflow * Fixing references to config.yaml, adding missing QA review to game-dev agent * More game story creation fixes * More game story creation fixes * Adding built web agent file * - Adding ability for QA agent to have preloaded context files similar to Dev agent. - Fixing stray Unity references in game-architecture-tmpl.yaml --------- Co-authored-by: Brian <bmadcode@gmail.com>
This commit is contained in:
sjennings
811
expansion-packs/bmad-godot-game-dev/data/bmad-kb.md
Normal file
811
expansion-packs/bmad-godot-game-dev/data/bmad-kb.md
Normal file
@@ -0,0 +1,811 @@
|
||||
# BMad Knowledge Base - Godot Game Development
|
||||
|
||||
## Overview
|
||||
|
||||
This is the game development expansion of BMad-Method (Breakthrough Method of Agile AI-driven Development), specializing in creating 2D and 3D games using Godot Engine with GDScript and C#. The system introduces a modular architecture with improved dependency management, bundle optimization, and support for both web and IDE environments, specifically optimized for Godot game development workflows.
|
||||
|
||||
### Key Features for Game Development
|
||||
|
||||
- **Game-Specialized Agent System**: AI agents for each game development role (Designer, Developer, Scrum Master, QA)
|
||||
- **Godot-Optimized Build System**: Automated dependency resolution for game assets and scenes
|
||||
- **Dual Environment Support**: Optimized for both web UIs and game development IDEs
|
||||
- **Game Development Resources**: Specialized templates, tasks, and checklists for Godot games
|
||||
- **Performance-First Approach**: Built-in optimization patterns for cross-platform game deployment (60+ FPS target)
|
||||
- **TDD Enforcement**: Test-driven development with GUT (GDScript) and GoDotTest (C#)
|
||||
|
||||
### Game Development Focus
|
||||
|
||||
- **Target Engine**: Godot 4.x (or 3.x LTS) with GDScript and C#/.NET support
|
||||
- **Platform Strategy**: Cross-platform (Desktop, Mobile, Web, Console) with 2D/3D support
|
||||
- **Development Approach**: Agile story-driven development with TDD and performance focus
|
||||
- **Performance Target**: 60+ FPS minimum on target devices (following Carmack's principles)
|
||||
- **Architecture**: Node-based architecture using Godot's scene system and signals
|
||||
- **Language Strategy**: GDScript for rapid iteration, C# for performance-critical systems
|
||||
|
||||
### When to Use BMad for Game Development
|
||||
|
||||
- **New Game Projects (Greenfield)**: Complete end-to-end game development from concept to deployment
|
||||
- **Existing Game Projects (Brownfield)**: Feature additions, level expansions, and gameplay enhancements
|
||||
- **Game Team Collaboration**: Multiple specialized roles working together on game features
|
||||
- **Game Quality Assurance**: Structured testing with TDD, performance validation, and gameplay balance
|
||||
- **Game Documentation**: Professional Game Design Documents, technical architecture, user stories
|
||||
|
||||
## How BMad Works for Game Development
|
||||
|
||||
### The Core Method
|
||||
|
||||
BMad transforms you into a "Player Experience CEO" - directing a team of specialized game development AI agents through structured workflows. Here's how:
|
||||
|
||||
1. **You Direct, AI Executes**: You provide game vision and creative decisions; agents handle implementation details
|
||||
2. **Specialized Game Agents**: Each agent masters one game development role (Designer, Developer, Scrum Master, QA)
|
||||
3. **Game-Focused Workflows**: Proven patterns guide you from game concept to deployed Godot game
|
||||
4. **Clean Handoffs**: Fresh context windows ensure agents stay focused and effective for game development
|
||||
|
||||
### The Two-Phase Game Development Approach
|
||||
|
||||
#### Phase 1: Game Design & Planning (Web UI - Cost Effective)
|
||||
|
||||
- Use large context windows for comprehensive game design
|
||||
- Generate complete Game Design Documents and technical architecture
|
||||
- Leverage multiple agents for creative brainstorming and mechanics refinement
|
||||
- Create once, use throughout game development
|
||||
|
||||
#### Phase 2: Game Development (IDE - Implementation)
|
||||
|
||||
- Shard game design documents into manageable pieces
|
||||
- Execute focused SM → Dev cycles for game features
|
||||
- One game story at a time, sequential progress
|
||||
- Real-time Godot operations, GDScript/C# coding, and game testing
|
||||
|
||||
### The Game Development Loop
|
||||
|
||||
```text
|
||||
1. Game SM Agent (New Chat) → Creates next game story from sharded docs
|
||||
2. You → Review and approve game story
|
||||
3. Game Dev Agent (New Chat) → Implements approved game feature in Godot (TDD-first)
|
||||
4. QA Agent (New Chat) → Reviews code, enforces TDD, validates performance
|
||||
5. You → Verify game feature completion and 60+ FPS
|
||||
6. Repeat until game epic complete
|
||||
```
|
||||
|
||||
### Why This Works for Games
|
||||
|
||||
- **Context Optimization**: Clean chats = better AI performance for complex game logic
|
||||
- **Role Clarity**: Agents don't context-switch = higher quality game features
|
||||
- **Incremental Progress**: Small game stories = manageable complexity
|
||||
- **Player-Focused Oversight**: You validate each game feature = quality control
|
||||
- **Design-Driven**: Game specs guide everything = consistent player experience
|
||||
- **Performance-First**: Every decision validated against 60+ FPS target
|
||||
|
||||
### Core Game Development Philosophy
|
||||
|
||||
#### Player-First Development
|
||||
|
||||
You are developing games as a "Player Experience CEO" - thinking like a game director with unlimited creative resources and a singular vision for player enjoyment.
|
||||
|
||||
#### Game Development Principles
|
||||
|
||||
1. **MAXIMIZE_PLAYER_ENGAGEMENT**: Push the AI to create compelling gameplay. Challenge mechanics and iterate.
|
||||
2. **PERFORMANCE_IS_KING**: 60+ FPS is the minimum, not the target. Profile everything.
|
||||
3. **TDD_MANDATORY**: Tests written first, no exceptions. GUT for GDScript, GoDotTest for C#.
|
||||
4. **GAMEPLAY_QUALITY_CONTROL**: You are the ultimate arbiter of fun. Review all game features.
|
||||
5. **CREATIVE_OVERSIGHT**: Maintain the high-level game vision and ensure design alignment.
|
||||
6. **ITERATIVE_REFINEMENT**: Expect to revisit game mechanics. Game development is not linear.
|
||||
7. **CLEAR_GAME_INSTRUCTIONS**: Precise game requirements lead to better implementations.
|
||||
8. **DOCUMENTATION_IS_KEY**: Good game design docs lead to good game features.
|
||||
9. **START_SMALL_SCALE_FAST**: Test core mechanics, then expand and polish.
|
||||
10. **EMBRACE_CREATIVE_CHAOS**: Adapt and overcome game development challenges.
|
||||
|
||||
## Getting Started with Game Development
|
||||
|
||||
### Quick Start Options for Game Development
|
||||
|
||||
#### Option 1: Web UI for Game Design
|
||||
|
||||
**Best for**: Game designers who want to start with comprehensive planning
|
||||
|
||||
1. Navigate to `dist/teams/` (after building)
|
||||
2. Copy `godot-game-team.txt` content
|
||||
3. Create new Gemini Gem or CustomGPT
|
||||
4. Upload file with instructions: "Your critical operating instructions are attached, do not break character as directed"
|
||||
5. Type `/help` to see available game development commands
|
||||
|
||||
#### Option 2: IDE Integration for Game Development
|
||||
|
||||
**Best for**: Godot developers using Cursor, Claude Code, Windsurf, Trae, Cline, Roo Code, Github Copilot
|
||||
|
||||
```bash
|
||||
# Interactive installation (recommended)
|
||||
npx bmad-method install
|
||||
# Select the bmad-godot-game-dev expansion pack when prompted
|
||||
```
|
||||
|
||||
**Installation Steps for Game Development**:
|
||||
|
||||
- Choose "Install expansion pack" when prompted
|
||||
- Select "bmad-godot-game-dev" from the list
|
||||
- Select your IDE from supported options:
|
||||
- **Cursor**: Native AI integration with Godot support
|
||||
- **Claude Code**: Anthropic's official IDE
|
||||
- **Windsurf**: Built-in AI capabilities
|
||||
- **Trae**: Built-in AI capabilities
|
||||
- **Cline**: VS Code extension with AI features
|
||||
- **Roo Code**: Web-based IDE with agent support
|
||||
- **GitHub Copilot**: VS Code extension with AI peer programming assistant
|
||||
|
||||
**Verify Game Development Installation**:
|
||||
|
||||
- `.bmad-core/` folder created with all core agents
|
||||
- `.bmad-godot-game-dev/` folder with game development agents
|
||||
- IDE-specific integration files created
|
||||
- Game development agents available with `/BmadG` prefix
|
||||
|
||||
### Environment Selection Guide for Game Development
|
||||
|
||||
**Use Web UI for**:
|
||||
|
||||
- Game design document creation and brainstorming
|
||||
- Cost-effective comprehensive game planning (especially with Gemini)
|
||||
- Multi-agent game design consultation
|
||||
- Creative ideation and mechanics refinement
|
||||
|
||||
**Use IDE for**:
|
||||
|
||||
- Godot project development and GDScript/C# coding
|
||||
- Scene operations and node hierarchy management
|
||||
- Game story management and implementation workflow
|
||||
- Godot testing with GUT/GoDotTest, profiling, and debugging
|
||||
|
||||
**Cost-Saving Tip for Game Development**: Create large game design documents in web UI, then copy to `docs/game-design-doc.md` and `docs/architecture.md` in your Godot project before switching to IDE for development.
|
||||
|
||||
### IDE-Only Game Development Workflow Considerations
|
||||
|
||||
**Can you do everything in IDE?** Yes, but understand the game development tradeoffs:
|
||||
|
||||
**Pros of IDE-Only Game Development**:
|
||||
|
||||
- Single environment workflow from design to Godot deployment
|
||||
- Direct Godot project operations from start
|
||||
- No copy/paste between environments
|
||||
- Immediate Godot project integration
|
||||
|
||||
**Cons of IDE-Only Game Development**:
|
||||
|
||||
- Higher token costs for large game design document creation
|
||||
- Smaller context windows for comprehensive game planning
|
||||
- May hit limits during creative brainstorming phases
|
||||
- Less cost-effective for extensive game design iteration
|
||||
- **Note**: Gemini CLI with Gemini Pro's 1m context window, for the planning phase, makes IDE-Only Game Development feasible
|
||||
|
||||
**CRITICAL RULE for Game Development**:
|
||||
|
||||
- **ALWAYS use Game SM agent for story creation** - Never use bmad-master or bmad-orchestrator
|
||||
- **ALWAYS use Game Dev agent for Godot implementation** - Never use bmad-master or bmad-orchestrator
|
||||
- **Why this matters**: Game SM and Game Dev agents are specifically optimized for Godot workflows
|
||||
- **No exceptions**: Even if using bmad-master for design, switch to Game SM → Game Dev for implementation
|
||||
|
||||
## Core Configuration for Game Development (core-config.yaml)
|
||||
|
||||
**New in V4**: The `expansion-packs/bmad-godot-game-dev/core-config.yaml` file enables BMad to work seamlessly with any Godot project structure, providing maximum flexibility for game development.
|
||||
|
||||
### Game Development Configuration
|
||||
|
||||
The expansion pack follows the standard BMad configuration patterns. Copy your core-config.yaml file to expansion-packs/bmad-godot-game-dev/ and add Game-specific configurations to your project's `core-config.yaml`:
|
||||
|
||||
```yaml
|
||||
markdownExploder: true
|
||||
prd:
|
||||
prdFile: docs/prd.md
|
||||
prdVersion: v4
|
||||
prdSharded: true
|
||||
prdShardedLocation: docs/prd
|
||||
epicFilePattern: epic-{n}*.md
|
||||
architecture:
|
||||
architectureFile: docs/architecture.md
|
||||
architectureVersion: v4
|
||||
architectureSharded: true
|
||||
architectureShardedLocation: docs/architecture
|
||||
gdd:
|
||||
gddVersion: v4
|
||||
gddSharded: true
|
||||
gddLocation: docs/game-design-doc.md
|
||||
gddShardedLocation: docs/gdd
|
||||
epicFilePattern: epic-{n}*.md
|
||||
gamearchitecture:
|
||||
gamearchitectureFile: docs/architecture.md
|
||||
gamearchitectureVersion: v3
|
||||
gamearchitectureLocation: docs/architecture.md
|
||||
gamearchitectureSharded: true
|
||||
gamearchitectureShardedLocation: docs/architecture
|
||||
gamebriefdocLocation: docs/game-brief.md
|
||||
levelDesignLocation: docs/level-design.md
|
||||
# Specify Godot executable location if needed
|
||||
godotExecutablePath: /Applications/Godot.app/Contents/MacOS/Godot
|
||||
customTechnicalDocuments: null
|
||||
devDebugLog: .ai/debug-log.md
|
||||
devStoryLocation: docs/stories
|
||||
slashPrefix: BmadG
|
||||
# Sharded architecture files for developer reference
|
||||
devLoadAlwaysFiles:
|
||||
- docs/architecture/9-coding-standards.md
|
||||
- docs/architecture/3-tech-stack.md
|
||||
- docs/architecture/8-godot-project-structure.md
|
||||
```
|
||||
|
||||
## Complete Game Development Workflow
|
||||
|
||||
### Planning Phase (Web UI Recommended - Especially Gemini for Game Design!)
|
||||
|
||||
**Ideal for cost efficiency with Gemini's massive context for game brainstorming:**
|
||||
|
||||
**For All Game Projects**:
|
||||
|
||||
1. **Game Concept Brainstorming**: `/bmadg/game-designer` - Use `*game-design-brainstorming` task
|
||||
2. **Game Brief**: Create foundation game document using `game-brief-tmpl`
|
||||
3. **Game Design Document Creation**: `/bmadg/game-designer` - Use `game-design-doc-tmpl` for comprehensive game requirements
|
||||
4. **Game Architecture Design**: `/bmadg/game-architect` - Use `game-architecture-tmpl` for Godot technical foundation
|
||||
5. **Level Design Framework**: `/bmadg/game-designer` - Use `level-design-doc-tmpl` for level structure planning
|
||||
6. **Document Preparation**: Copy final documents to Godot project as `docs/game-design-doc.md`, `docs/game-brief.md`, `docs/level-design.md` and `docs/architecture.md`
|
||||
|
||||
#### Example Game Planning Prompts
|
||||
|
||||
**For Game Design Document Creation**:
|
||||
|
||||
```text
|
||||
"I want to build a [genre] 2D game in Godot that [core gameplay].
|
||||
Help me brainstorm mechanics and create a comprehensive Game Design Document."
|
||||
```
|
||||
|
||||
**For Game Architecture Design**:
|
||||
|
||||
```text
|
||||
"Based on this Game Design Document, design a scalable Godot architecture
|
||||
that can handle [specific game requirements] with 60+ FPS performance.
|
||||
Consider both GDScript and C# for appropriate systems."
|
||||
```
|
||||
|
||||
### Critical Transition: Web UI to Godot IDE
|
||||
|
||||
**Once game planning is complete, you MUST switch to IDE for Godot development:**
|
||||
|
||||
- **Why**: Godot development workflow requires scene operations, GDScript/C# coding, and real-time testing
|
||||
- **Cost Benefit**: Web UI is more cost-effective for large game design creation; IDE is optimized for Godot development
|
||||
- **Required Files**: Ensure `docs/game-design-doc.md` and `docs/architecture.md` exist in your Godot project
|
||||
|
||||
### Godot IDE Development Workflow
|
||||
|
||||
**Prerequisites**: Game planning documents must exist in `docs/` folder of Godot project
|
||||
|
||||
1. **Document Sharding** (CRITICAL STEP for Game Development):
|
||||
- Documents created by Game Designer/Architect (in Web or IDE) MUST be sharded for development
|
||||
- Use core BMad agents or tools to shard:
|
||||
a) **Manual**: Use core BMad `shard-doc` task if available
|
||||
b) **Agent**: Ask core `@bmad-master` agent to shard documents
|
||||
- Shards `docs/game-design-doc.md` → `docs/game-design/` folder
|
||||
- Shards `docs/architecture.md` → `docs/architecture/` folder
|
||||
- **WARNING**: Do NOT shard in Web UI - copying many small files to Godot is painful!
|
||||
|
||||
2. **Verify Sharded Game Content**:
|
||||
- At least one `feature-n.md` file in `docs/game-design/` with game stories in development order
|
||||
- Godot system documents and coding standards for game dev agent reference
|
||||
- Sharded docs for Game SM agent story creation
|
||||
|
||||
Resulting Godot Project Folder Structure:
|
||||
|
||||
- `docs/game-design/` - Broken down game design sections
|
||||
- `docs/architecture/` - Broken down Godot architecture sections
|
||||
- `docs/game-stories/` - Generated game development stories
|
||||
|
||||
3. **Game Development Cycle** (Sequential, one game story at a time):
|
||||
|
||||
**CRITICAL CONTEXT MANAGEMENT for Godot Development**:
|
||||
- **Context windows matter!** Always use fresh, clean context windows
|
||||
- **Model selection matters!** Use most powerful thinking model for Game SM story creation
|
||||
- **ALWAYS start new chat between Game SM, Game Dev, and QA work**
|
||||
|
||||
**Step 1 - Game Story Creation**:
|
||||
- **NEW CLEAN CHAT** → Select powerful model → `/bmadgd/game-sm` → `*draft`
|
||||
- Game SM executes create-game-story task using `game-story-tmpl`
|
||||
- Review generated story in `docs/game-stories/`
|
||||
- _Optional_ - Use `/bmadg/game-po` -> `*validate-story-draft (story)` to confirm alignment
|
||||
- Update status from "Draft" to "Approved"
|
||||
|
||||
**Step 2 - Godot Game Story Implementation (TDD)**:
|
||||
- **NEW CLEAN CHAT** → `/bmadg/game-developer`
|
||||
- Agent asks which game story to implement
|
||||
- Include story file content to save game dev agent lookup time
|
||||
- **CRITICAL**: Game Dev writes tests FIRST (GUT/GoDotTest)
|
||||
- Game Dev implements to make tests pass
|
||||
- Game Dev maintains File List of all Godot/GDScript/C# changes
|
||||
- Game Dev validates 60+ FPS performance
|
||||
- Game Dev marks story as "Ready for Review" when complete with all tests passing
|
||||
|
||||
**Step 3 - Game QA Review**:
|
||||
- **NEW CLEAN CHAT** → `/bmadg/game-qa` → execute review-story task
|
||||
- QA enforces TDD compliance (tests written first)
|
||||
- QA validates 60+ FPS performance
|
||||
- QA can refactor and improve Godot code directly
|
||||
- QA appends results to story's QA Results section
|
||||
- If approved: Status → "Done"
|
||||
- If changes needed: Status stays "Review" with unchecked items for game dev
|
||||
|
||||
**Step 4 - Repeat**: Continue Game SM → Game Dev → QA cycle until all game feature stories complete
|
||||
|
||||
**Important**: Only 1 game story in progress at a time, worked sequentially until all game feature stories complete.
|
||||
|
||||
### Game Story Status Tracking Workflow
|
||||
|
||||
Game stories progress through defined statuses:
|
||||
|
||||
- **Draft** → **Approved** → **InProgress** → **Ready for Review** → **Done**
|
||||
|
||||
Each status change requires user verification and approval before proceeding.
|
||||
|
||||
### Game Development Workflow Types
|
||||
|
||||
#### Greenfield Game Development
|
||||
|
||||
- Game concept brainstorming and mechanics design
|
||||
- Game design requirements and feature definition
|
||||
- Godot system architecture and technical design
|
||||
- Game development execution with TDD
|
||||
- Game testing, performance optimization (60+ FPS), and deployment
|
||||
|
||||
#### Brownfield Game Enhancement (Existing Godot Projects)
|
||||
|
||||
**Key Concept**: Brownfield game development requires comprehensive documentation of your existing Godot project for AI agents to understand game mechanics, node patterns, and technical constraints.
|
||||
|
||||
**Brownfield Game Enhancement Workflow**:
|
||||
|
||||
1. **Upload Godot project to Web UI** (GitHub URL, files, or zip)
|
||||
2. **Create adapted Game Design Document**: `/bmadg/game-designer` - Modify `game-design-doc-tmpl` to include:
|
||||
- Analysis of existing scene structure
|
||||
- Integration points for new features
|
||||
- Save game compatibility requirements
|
||||
- Risk assessment for changes
|
||||
|
||||
3. **Game Architecture Planning**:
|
||||
- Use `/bmadg/game-architect` with `game-architecture-tmpl`
|
||||
- Focus on how new features integrate with existing Godot systems
|
||||
- Plan for gradual rollout and testing
|
||||
|
||||
4. **Story Creation for Enhancements**:
|
||||
- Use `/bmadg/game-sm` with `*create-game-story`
|
||||
- Stories should explicitly reference existing scenes/scripts to modify
|
||||
- Include integration testing requirements
|
||||
|
||||
**Critical Success Factors for Game Development**:
|
||||
|
||||
1. **Game Documentation First**: Always document existing code thoroughly before making changes
|
||||
2. **Godot Context Matters**: Provide agents access to relevant scenes and scripts
|
||||
3. **Gameplay Integration Focus**: Emphasize compatibility and non-breaking changes to game mechanics
|
||||
4. **Incremental Approach**: Plan for gradual rollout and extensive game testing
|
||||
5. **Performance Validation**: Every change must maintain 60+ FPS
|
||||
|
||||
## Document Creation Best Practices for Game Development
|
||||
|
||||
### Required File Naming for Game Framework Integration
|
||||
|
||||
- `docs/game-design-doc.md` - Game Design Document
|
||||
- `docs/architecture.md` - Godot System Architecture Document
|
||||
|
||||
**Why These Names Matter for Game Development**:
|
||||
|
||||
- Game agents automatically reference these files during Godot development
|
||||
- Game sharding tasks expect these specific filenames
|
||||
- Game workflow automation depends on standard naming
|
||||
|
||||
### Cost-Effective Game Document Creation Workflow
|
||||
|
||||
**Recommended for Large Game Documents (Game Design Document, Game Architecture):**
|
||||
|
||||
1. **Use Web UI**: Create game documents in web interface for cost efficiency
|
||||
2. **Copy Final Output**: Save complete markdown to your Godot project
|
||||
3. **Standard Names**: Save as `docs/game-design-doc.md` and `docs/architecture.md`
|
||||
4. **Switch to Godot IDE**: Use IDE agents for Godot development and smaller game documents
|
||||
|
||||
### Game Document Sharding
|
||||
|
||||
Game templates with Level 2 headings (`##`) can be automatically sharded:
|
||||
|
||||
**Original Game Design Document**:
|
||||
|
||||
```markdown
|
||||
## Core Gameplay Mechanics
|
||||
|
||||
## Player Progression System
|
||||
|
||||
## Level Design Framework
|
||||
|
||||
## Technical Requirements
|
||||
```
|
||||
|
||||
**After Sharding**:
|
||||
|
||||
- `docs/game-design/core-gameplay-mechanics.md`
|
||||
- `docs/game-design/player-progression-system.md`
|
||||
- `docs/game-design/level-design-framework.md`
|
||||
- `docs/game-design/technical-requirements.md`
|
||||
|
||||
Use the `shard-doc` task or `@kayvan/markdown-tree-parser` tool for automatic game document sharding.
|
||||
|
||||
## Game Agent System
|
||||
|
||||
### Core Game Development Team
|
||||
|
||||
| Agent | Role | Primary Functions | When to Use |
|
||||
| ---------------- | ---------------------- | ------------------------------------------------ | -------------------------------------------- |
|
||||
| `game-designer` | Game Designer | Game mechanics, creative design, GDD | Game concept, mechanics, creative direction |
|
||||
| `game-developer` | Godot Developer | GDScript/C# implementation, TDD, optimization | All Godot development tasks (tests first!) |
|
||||
| `game-sm` | Game Scrum Master | Game story creation, sprint planning | Game project management, workflow |
|
||||
| `game-architect` | Game Architect | Godot system design, performance architecture | Complex Godot systems, 60+ FPS planning |
|
||||
| `game-qa` | Game QA & TDD Enforcer | TDD enforcement, performance validation, testing | Code review, test verification, optimization |
|
||||
|
||||
### Game Agent Interaction Commands
|
||||
|
||||
#### IDE-Specific Syntax for Game Development
|
||||
|
||||
**Game Agent Loading by IDE**:
|
||||
|
||||
- **Claude Code**: `/bmadg/game-designer`, `/bmadg/game-developer`, `/bmadg/game-sm`, `/bmadg/game-architect`, `/bmadg/game-qa`
|
||||
- **Cursor**: `@bmadg/game-designer`, `@bmadg/game-developer`, `@bmadg/game-sm`, `@bmadg/game-architect`, `@bmadg/game-qa`
|
||||
- **Windsurf**: `/bmadg/game-designer`, `/bmadg/game-developer`, `/bmadg/game-sm`, `/bmadg/game-architect`, `/bmadg/game-qa`
|
||||
- **Trae**: `@bmadg/game-designer`, `@bmadg/game-developer`, `@bmadg/game-sm`, `@bmadg/game-architect`, `@bmadg/game-qa`
|
||||
- **Roo Code**: Select mode from mode selector with bmadg prefix
|
||||
- **GitHub Copilot**: Open the Chat view (`⌃⌘I` on Mac, `Ctrl+Alt+I` on Windows/Linux) and select the appropriate game agent
|
||||
|
||||
**Common Game Development Task Commands**:
|
||||
|
||||
- `*help` - Show available game development commands
|
||||
- `*status` - Show current game development context/progress
|
||||
- `*exit` - Exit the game agent mode
|
||||
- `*game-design-brainstorming` - Brainstorm game concepts and mechanics (Game Designer)
|
||||
- `*draft` - Create next game development story (Game SM agent)
|
||||
- `*review {story}` - Review story with TDD enforcement (Game QA agent)
|
||||
- `*enforce-tdd {story}` - Verify tests written first (Game QA agent)
|
||||
- `*correct-course-game` - Course correction for game development issues
|
||||
- `*advanced-elicitation` - Deep dive into game requirements
|
||||
|
||||
## Game-Specific Development Guidelines
|
||||
|
||||
### Godot + GDScript/C# Standards
|
||||
|
||||
**Project Structure**:
|
||||
|
||||
```text
|
||||
GodotProject/
|
||||
├── .godot/ # Godot cache (gitignore)
|
||||
├── scenes/ # Game scenes
|
||||
│ ├── main/ # Main game scenes
|
||||
│ ├── ui/ # UI scenes
|
||||
│ ├── levels/ # Level scenes
|
||||
│ └── components/ # Reusable scene components
|
||||
├── scripts/ # GDScript and C# scripts
|
||||
│ ├── player/ # Player-related scripts
|
||||
│ ├── enemies/ # Enemy scripts
|
||||
│ ├── systems/ # Game systems
|
||||
│ ├── ui/ # UI scripts
|
||||
│ └── utils/ # Utility scripts
|
||||
├── resources/ # Custom Resources
|
||||
│ ├── items/ # Item definitions
|
||||
│ ├── stats/ # Stat Resources
|
||||
│ └── settings/ # Game settings
|
||||
├── assets/ # Art and audio assets
|
||||
│ ├── sprites/ # 2D sprites
|
||||
│ ├── models/ # 3D models (if 3D)
|
||||
│ ├── audio/ # Sound effects and music
|
||||
│ └── fonts/ # Font files
|
||||
├── tests/ # Test suites
|
||||
│ ├── unit/ # GUT unit tests
|
||||
│ └── integration/ # Integration tests
|
||||
├── addons/ # Godot plugins
|
||||
│ ├── gut/ # GUT testing framework
|
||||
│ └── godottest/ # GoDotTest for C#
|
||||
├── export_presets.cfg # Export configurations
|
||||
└── project.godot # Project settings
|
||||
```
|
||||
|
||||
**Performance Requirements**:
|
||||
|
||||
- Maintain 60+ FPS minimum on target devices (Carmack's principle)
|
||||
- Frame time under 16.67ms consistently
|
||||
- Memory usage under platform-specific limits
|
||||
- Loading times under 3 seconds for scenes
|
||||
- Input latency under 50ms
|
||||
|
||||
**Code Quality**:
|
||||
|
||||
- GDScript with static typing enforced
|
||||
- C# for performance-critical systems
|
||||
- Node-based architecture (composition over inheritance)
|
||||
- Signal-based communication between systems
|
||||
- Resource-driven data management
|
||||
- TDD with 80% minimum test coverage
|
||||
|
||||
### Game Development Story Structure
|
||||
|
||||
**Story Requirements**:
|
||||
|
||||
- Clear reference to Game Design Document section
|
||||
- Specific acceptance criteria for game functionality
|
||||
- Technical implementation details for Godot
|
||||
- Performance requirements (60+ FPS validation)
|
||||
- Testing requirements (tests written FIRST)
|
||||
- Language selection justification (GDScript vs C#)
|
||||
|
||||
**Story Categories**:
|
||||
|
||||
- **Core Mechanics**: Fundamental gameplay systems
|
||||
- **Scene Content**: Individual scenes and level implementation
|
||||
- **UI/UX**: Control nodes and player experience features
|
||||
- **Performance**: Optimization and technical improvements
|
||||
- **Polish**: Visual effects, audio, and game feel enhancements
|
||||
|
||||
### Quality Assurance for Games
|
||||
|
||||
**Testing Approach (TDD Mandatory)**:
|
||||
|
||||
- Unit tests written FIRST (GUT for GDScript)
|
||||
- Integration tests for scene interactions (GoDotTest for C#)
|
||||
- Performance benchmarking with Godot profiler
|
||||
- Gameplay testing and balance validation
|
||||
- Cross-platform compatibility testing
|
||||
- 80% minimum test coverage
|
||||
|
||||
**Performance Monitoring**:
|
||||
|
||||
- Frame rate consistency tracking (60+ FPS)
|
||||
- Draw call optimization
|
||||
- Memory usage monitoring
|
||||
- Scene loading performance
|
||||
- Input responsiveness validation
|
||||
- Battery usage optimization (mobile)
|
||||
|
||||
## Usage Patterns and Best Practices for Game Development
|
||||
|
||||
### Environment-Specific Usage for Games
|
||||
|
||||
**Web UI Best For Game Development**:
|
||||
|
||||
- Initial game design and creative brainstorming phases
|
||||
- Cost-effective large game document creation
|
||||
- Game agent consultation and mechanics refinement
|
||||
- Multi-agent game workflows with orchestrator
|
||||
|
||||
**Godot IDE Best For Game Development**:
|
||||
|
||||
- Active Godot development with TDD
|
||||
- Scene and node hierarchy management
|
||||
- Game story management and development cycles
|
||||
- Performance profiling and optimization
|
||||
- GUT/GoDotTest execution
|
||||
|
||||
### Quality Assurance for Game Development
|
||||
|
||||
- Use appropriate game agents for specialized tasks
|
||||
- Follow Agile ceremonies and game review processes
|
||||
- Use game-specific checklists:
|
||||
- `game-architect-checklist` for architecture reviews
|
||||
- `game-change-checklist` for change validation
|
||||
- `game-design-checklist` for design reviews
|
||||
- `game-story-dod-checklist` for story quality (TDD compliance)
|
||||
- `game-po-checklist` for product owner validation
|
||||
- Regular validation with game templates
|
||||
|
||||
### Performance Optimization for Game Development
|
||||
|
||||
- Use specific game agents vs. `bmad-master` for focused Godot tasks
|
||||
- Choose appropriate game team size for project needs
|
||||
- Leverage game-specific technical preferences for consistency
|
||||
- Regular context management and cache clearing for Godot workflows
|
||||
- Profile everything, optimize based on data (Carmack's philosophy)
|
||||
|
||||
## Game Development Team Roles
|
||||
|
||||
### Game Designer
|
||||
|
||||
- **Primary Focus**: Game mechanics, player experience, design documentation
|
||||
- **Key Outputs**: Game Brief, Game Design Document, Level Design Framework
|
||||
- **Specialties**: Brainstorming, game balance, player psychology, creative direction
|
||||
|
||||
### Game Developer
|
||||
|
||||
- **Primary Focus**: Godot implementation with TDD, GDScript/C# excellence, 60+ FPS optimization
|
||||
- **Key Outputs**: Working game features with tests, optimized Godot code, performance validation
|
||||
- **Specialties**: TDD practices, GDScript/C#, node architecture, cross-platform development
|
||||
|
||||
### Game Scrum Master
|
||||
|
||||
- **Primary Focus**: Game story creation, development planning, agile process
|
||||
- **Key Outputs**: Detailed implementation stories, sprint planning, quality assurance
|
||||
- **Specialties**: Story breakdown, developer handoffs, process optimization
|
||||
|
||||
### Game Architect
|
||||
|
||||
- **Primary Focus**: Godot system design, performance architecture, language strategy
|
||||
- **Key Outputs**: Technical architecture, performance budgets, optimization strategies
|
||||
- **Specialties**: Node patterns, signal architecture, GDScript vs C# decisions, 60+ FPS planning
|
||||
|
||||
### Game QA
|
||||
|
||||
- **Primary Focus**: TDD enforcement, test verification, performance validation
|
||||
- **Key Outputs**: Test coverage reports, performance metrics, code quality assessment
|
||||
- **Specialties**: GUT/GoDotTest frameworks, profiling, optimization validation
|
||||
|
||||
## Platform-Specific Considerations
|
||||
|
||||
### Cross-Platform Development
|
||||
|
||||
- Use InputMap for platform-agnostic input
|
||||
- Export templates for each target platform
|
||||
- Test on all target platforms regularly
|
||||
- Optimize for different screen resolutions and aspect ratios
|
||||
- Platform-specific performance targets
|
||||
|
||||
### Mobile Optimization
|
||||
|
||||
- Touch input with TouchScreenButton nodes
|
||||
- Battery usage optimization
|
||||
- Performance scaling for different device capabilities
|
||||
- App store compliance and export settings
|
||||
- Reduced draw calls and texture memory
|
||||
|
||||
### Performance Targets
|
||||
|
||||
- **Desktop**: 60+ FPS at native resolution (144 FPS for high-refresh displays)
|
||||
- **Mobile**: 60 FPS on mid-range devices minimum
|
||||
- **Web**: 60 FPS with optimized export settings
|
||||
- **Loading**: Scene transitions under 2 seconds
|
||||
- **Memory**: Within platform-specific limits
|
||||
|
||||
## Success Metrics for Game Development
|
||||
|
||||
### Technical Metrics
|
||||
|
||||
- Frame rate consistency (>95% of time at 60+ FPS)
|
||||
- Frame time variance (<2ms variation)
|
||||
- Memory usage within budgets
|
||||
- Loading time targets met
|
||||
- Zero critical bugs in core gameplay systems
|
||||
- 80%+ test coverage (TDD compliance)
|
||||
|
||||
### Player Experience Metrics
|
||||
|
||||
- Input latency under 50ms
|
||||
- Tutorial completion rate >80%
|
||||
- Level completion rates appropriate for difficulty curve
|
||||
- Average session length meets design targets
|
||||
- Player retention and engagement metrics
|
||||
|
||||
### Development Process Metrics
|
||||
|
||||
- All stories have tests written FIRST
|
||||
- Story completion within estimated timeframes
|
||||
- Code quality metrics (test coverage, static analysis)
|
||||
- Documentation completeness and accuracy
|
||||
- Team velocity and delivery consistency
|
||||
|
||||
## Common Godot Development Patterns
|
||||
|
||||
### Scene Management
|
||||
|
||||
- Use scene inheritance for variant levels
|
||||
- Autoload singletons for persistent systems
|
||||
- Scene transitions with loading screens
|
||||
- Resource preloading for smooth gameplay
|
||||
|
||||
### Node Architecture
|
||||
|
||||
- Composition over inheritance with scene instances
|
||||
- Signal-based communication between nodes
|
||||
- Node groups for efficient queries
|
||||
- Tool scripts for editor enhancement
|
||||
|
||||
### Performance Patterns
|
||||
|
||||
- Object pooling for frequently spawned nodes
|
||||
- MultiMesh for many identical objects
|
||||
- LOD systems with visibility ranges
|
||||
- Occlusion culling for complex scenes
|
||||
- Static typing in GDScript for 10-20% performance gain
|
||||
|
||||
### Language Strategy
|
||||
|
||||
- GDScript for:
|
||||
- Rapid prototyping
|
||||
- UI and menu systems
|
||||
- Simple game logic
|
||||
- Editor tools
|
||||
- C# for:
|
||||
- Complex algorithms
|
||||
- Performance-critical systems
|
||||
- Heavy computation
|
||||
- External library integration
|
||||
|
||||
## Success Tips for Game Development
|
||||
|
||||
- **Use Gemini for game design planning** - The team-game-dev bundle provides collaborative game expertise
|
||||
- **Enforce TDD religiously** - Tests first, implementation second, no exceptions
|
||||
- **Profile constantly** - Measure don't guess (Carmack's philosophy)
|
||||
- **Follow the Game SM → Game Dev → QA cycle** - This ensures systematic game progress
|
||||
- **Keep conversations focused** - One game agent, one Godot task per conversation
|
||||
- **Review everything** - Always verify 60+ FPS before marking features complete
|
||||
- **Use appropriate language** - GDScript for iteration, C# for performance
|
||||
|
||||
## Contributing to BMad-Method Game Development
|
||||
|
||||
### Game Development Contribution Guidelines
|
||||
|
||||
For full details, see `CONTRIBUTING.md`. Key points for game development:
|
||||
|
||||
**Fork Workflow for Game Development**:
|
||||
|
||||
1. Fork the repository
|
||||
2. Create game development feature branches
|
||||
3. Submit PRs to `next` branch (default) or `main` for critical game development fixes only
|
||||
4. Keep PRs small: 200-400 lines ideal, 800 lines maximum
|
||||
5. One game feature/fix per PR
|
||||
|
||||
**Game Development PR Requirements**:
|
||||
|
||||
- Clear descriptions (max 200 words) with What/Why/How/Testing for game features
|
||||
- Use conventional commits (feat:, fix:, docs:) with game context
|
||||
- Atomic commits - one logical game change per commit
|
||||
- Must align with game development guiding principles
|
||||
- Include performance impact assessment
|
||||
|
||||
**Game Development Core Principles**:
|
||||
|
||||
- **Game Dev Agents Must Be Lean**: Minimize dependencies, save context for Godot code
|
||||
- **Natural Language First**: Everything in markdown, no code in game development core
|
||||
- **Core vs Game Expansion Packs**: Core for universal needs, game packs for Godot specialization
|
||||
- **Game Design Philosophy**: "Game dev agents code Godot, game planning agents plan gameplay"
|
||||
- **Performance First**: Every change validated against 60+ FPS target
|
||||
- **TDD Mandatory**: Tests before implementation, always
|
||||
|
||||
## Game Development Expansion Pack System
|
||||
|
||||
### This Game Development Expansion Pack
|
||||
|
||||
This Godot Game Development expansion pack extends BMad-Method beyond traditional software development into professional game development. It provides specialized game agent teams, Godot templates, and game workflows while keeping the core framework lean and focused on general development.
|
||||
|
||||
### Why Use This Game Development Expansion Pack?
|
||||
|
||||
1. **Keep Core Lean**: Game dev agents maintain maximum context for Godot coding
|
||||
2. **Game Domain Expertise**: Deep, specialized Godot and game development knowledge
|
||||
3. **Community Game Innovation**: Game developers can contribute and share Godot patterns
|
||||
4. **Modular Game Design**: Install only game development capabilities you need
|
||||
5. **Performance Focus**: Built-in 60+ FPS validation and optimization patterns
|
||||
6. **TDD Enforcement**: Mandatory test-first development practices
|
||||
|
||||
### Using This Game Development Expansion Pack
|
||||
|
||||
1. **Install via CLI**:
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
# Select "Install game development expansion pack" option
|
||||
```
|
||||
|
||||
2. **Use in Your Game Workflow**: Installed game agents integrate seamlessly with existing BMad agents
|
||||
|
||||
### Creating Custom Game Development Extensions
|
||||
|
||||
Use the **expansion-creator** pack to build your own game development extensions:
|
||||
|
||||
1. **Define Game Domain**: What game development expertise are you capturing?
|
||||
2. **Design Game Agents**: Create specialized game roles with clear Godot boundaries
|
||||
3. **Build Game Resources**: Tasks, templates, checklists for your game domain
|
||||
4. **Test & Share**: Validate with real Godot use cases, share with game development community
|
||||
|
||||
**Key Principle**: Game development expansion packs democratize game development expertise by making specialized Godot and game design knowledge accessible through AI agents.
|
||||
|
||||
## Getting Help with Game Development
|
||||
|
||||
- **Commands**: Use `*/*help` in any environment to see available game development commands
|
||||
- **Game Agent Switching**: Use `*/*switch game-agent-name` with orchestrator for role changes
|
||||
- **Game Documentation**: Check `docs/` folder for Godot project-specific context
|
||||
- **Game Community**: Discord and GitHub resources available for game development support
|
||||
- **Game Contributing**: See `CONTRIBUTING.md` for full game development guidelines
|
||||
|
||||
This knowledge base provides the foundation for effective game development using the BMad-Method framework with specialized focus on Godot game creation using GDScript and C# with mandatory TDD practices and 60+ FPS performance targets.
|
||||
@@ -0,0 +1,36 @@
|
||||
# Brainstorming Techniques Data
|
||||
|
||||
## Creative Expansion
|
||||
|
||||
1. **What If Scenarios**: Ask one provocative question, get their response, then ask another
|
||||
2. **Analogical Thinking**: Give one example analogy, ask them to find 2-3 more
|
||||
3. **Reversal/Inversion**: Pose the reverse question, let them work through it
|
||||
4. **First Principles Thinking**: Ask "What are the fundamentals?" and guide them to break it down
|
||||
|
||||
## Structured Frameworks
|
||||
|
||||
5. **SCAMPER Method**: Go through one letter at a time, wait for their ideas before moving to next
|
||||
6. **Six Thinking Hats**: Present one hat, ask for their thoughts, then move to next hat
|
||||
7. **Mind Mapping**: Start with central concept, ask them to suggest branches
|
||||
|
||||
## Collaborative Techniques
|
||||
|
||||
8. **"Yes, And..." Building**: They give idea, you "yes and" it, they "yes and" back - alternate
|
||||
9. **Brainwriting/Round Robin**: They suggest idea, you build on it, ask them to build on yours
|
||||
10. **Random Stimulation**: Give one random prompt/word, ask them to make connections
|
||||
|
||||
## Deep Exploration
|
||||
|
||||
11. **Five Whys**: Ask "why" and wait for their answer before asking next "why"
|
||||
12. **Morphological Analysis**: Ask them to list parameters first, then explore combinations together
|
||||
13. **Provocation Technique (PO)**: Give one provocative statement, ask them to extract useful ideas
|
||||
|
||||
## Advanced Techniques
|
||||
|
||||
14. **Forced Relationships**: Connect two unrelated concepts and ask them to find the bridge
|
||||
15. **Assumption Reversal**: Challenge their core assumptions and ask them to build from there
|
||||
16. **Role Playing**: Ask them to brainstorm from different stakeholder perspectives
|
||||
17. **Time Shifting**: "How would you solve this in 1995? 2030?"
|
||||
18. **Resource Constraints**: "What if you had only $10 and 1 hour?"
|
||||
19. **Metaphor Mapping**: Use extended metaphors to explore solutions
|
||||
20. **Question Storming**: Generate questions instead of answers first
|
||||
@@ -0,0 +1,893 @@
|
||||
# Game Development Guidelines (Godot, GDScript & C#)
|
||||
|
||||
## Overview
|
||||
|
||||
This document establishes coding standards, architectural patterns, and development practices for game development using Godot Engine with GDScript and C#. These guidelines ensure consistency, performance (60+ FPS target), maintainability, and enforce Test-Driven Development (TDD) across all game development stories.
|
||||
|
||||
## Performance Philosophy
|
||||
|
||||
Following John Carmack's principles:
|
||||
|
||||
- **"Measure, don't guess"** - Profile everything with Godot's built-in profiler
|
||||
- **"Focus on what matters: framerate and responsiveness"** - 60+ FPS is the minimum, not the target
|
||||
- **"The best code is no code"** - Simplicity beats cleverness
|
||||
- **"Think about cache misses, not instruction counts"** - Memory access patterns matter most
|
||||
|
||||
## GDScript Standards
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
**Classes and Scripts:**
|
||||
|
||||
- PascalCase for class names: `PlayerController`, `GameData`, `InventorySystem`
|
||||
- Snake_case for file names: `player_controller.gd`, `game_data.gd`
|
||||
- Descriptive names that indicate purpose: `GameStateManager` not `GSM`
|
||||
|
||||
**Functions and Methods:**
|
||||
|
||||
- Snake_case for functions: `calculate_damage()`, `process_input()`
|
||||
- Descriptive verb phrases: `activate_shield()` not `shield()`
|
||||
- Private methods prefix with underscore: `_update_health()`
|
||||
|
||||
**Variables and Properties:**
|
||||
|
||||
- Snake_case for variables: `player_health`, `movement_speed`
|
||||
- Constants in UPPER_SNAKE_CASE: `MAX_HEALTH`, `GRAVITY_FORCE`
|
||||
- Export variables with clear names: `@export var jump_height: float = 5.0`
|
||||
- Boolean variables with is/has/can prefix: `is_alive`, `has_key`, `can_jump`
|
||||
- Signal names in snake_case: `health_changed`, `level_completed`
|
||||
|
||||
### Static Typing (MANDATORY for Performance)
|
||||
|
||||
**Always use static typing for 10-20% performance gain:**
|
||||
|
||||
```gdscript
|
||||
# GOOD - Static typing
|
||||
extends CharacterBody2D
|
||||
|
||||
@export var max_health: int = 100
|
||||
@export var movement_speed: float = 300.0
|
||||
|
||||
var current_health: int
|
||||
var velocity_multiplier: float = 1.0
|
||||
|
||||
func take_damage(amount: int) -> void:
|
||||
current_health -= amount
|
||||
if current_health <= 0:
|
||||
_die()
|
||||
|
||||
func _die() -> void:
|
||||
queue_free()
|
||||
|
||||
# BAD - Dynamic typing (avoid)
|
||||
var health = 100 # No type specified
|
||||
func take_damage(amount): # No parameter or return type
|
||||
health -= amount
|
||||
```
|
||||
|
||||
## C# Standards (for Performance-Critical Systems)
|
||||
|
||||
### When to Use C# vs GDScript
|
||||
|
||||
**Use C# for:**
|
||||
|
||||
- Complex algorithms (pathfinding, procedural generation)
|
||||
- Heavy mathematical computations
|
||||
- Performance-critical systems identified by profiler
|
||||
- External .NET library integration
|
||||
- Large-scale data processing
|
||||
|
||||
**Use GDScript for:**
|
||||
|
||||
- Rapid prototyping and iteration
|
||||
- UI and menu systems
|
||||
- Simple game logic
|
||||
- Editor tools and scene management
|
||||
- Quick gameplay tweaks
|
||||
|
||||
### C# Naming Conventions
|
||||
|
||||
```csharp
|
||||
using Godot;
|
||||
|
||||
public partial class PlayerController : CharacterBody2D
|
||||
{
|
||||
// Public fields (use sparingly, prefer properties)
|
||||
[Export] public float MoveSpeed = 300.0f;
|
||||
|
||||
// Private fields with underscore prefix
|
||||
private int _currentHealth;
|
||||
private float _jumpVelocity;
|
||||
|
||||
// Properties with PascalCase
|
||||
public int MaxHealth { get; set; } = 100;
|
||||
|
||||
// Methods with PascalCase
|
||||
public void TakeDamage(int amount)
|
||||
{
|
||||
_currentHealth -= amount;
|
||||
if (_currentHealth <= 0)
|
||||
{
|
||||
Die();
|
||||
}
|
||||
}
|
||||
|
||||
private void Die()
|
||||
{
|
||||
QueueFree();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Godot Architecture Patterns
|
||||
|
||||
### Node-Based Architecture
|
||||
|
||||
**Scene Composition Over Inheritance:**
|
||||
|
||||
```gdscript
|
||||
# Player.tscn structure:
|
||||
# Player (CharacterBody2D)
|
||||
# ├── Sprite2D
|
||||
# ├── CollisionShape2D
|
||||
# ├── PlayerHealth (Node)
|
||||
# ├── PlayerMovement (Node)
|
||||
# └── PlayerInput (Node)
|
||||
|
||||
# PlayerHealth.gd - Single responsibility component
|
||||
extends Node
|
||||
class_name PlayerHealth
|
||||
|
||||
signal health_changed(new_health: int)
|
||||
signal died
|
||||
|
||||
@export var max_health: int = 100
|
||||
var current_health: int
|
||||
|
||||
func _ready() -> void:
|
||||
current_health = max_health
|
||||
|
||||
func take_damage(amount: int) -> void:
|
||||
current_health = max(0, current_health - amount)
|
||||
health_changed.emit(current_health)
|
||||
if current_health == 0:
|
||||
died.emit()
|
||||
```
|
||||
|
||||
### Signal-Based Communication
|
||||
|
||||
**Decouple Systems with Signals:**
|
||||
|
||||
```gdscript
|
||||
# GameManager.gd - Singleton/Autoload
|
||||
extends Node
|
||||
|
||||
signal game_started
|
||||
signal game_over
|
||||
signal level_completed
|
||||
|
||||
var score: int = 0
|
||||
var current_level: int = 1
|
||||
|
||||
func start_game() -> void:
|
||||
score = 0
|
||||
current_level = 1
|
||||
game_started.emit()
|
||||
get_tree().change_scene_to_file("res://scenes/levels/level_1.tscn")
|
||||
|
||||
# Player.gd - Connects to signals
|
||||
extends CharacterBody2D
|
||||
|
||||
func _ready() -> void:
|
||||
GameManager.game_over.connect(_on_game_over)
|
||||
|
||||
func _on_game_over() -> void:
|
||||
set_physics_process(false) # Stop player movement
|
||||
$AnimationPlayer.play("death")
|
||||
```
|
||||
|
||||
### Resource-Based Data Management
|
||||
|
||||
**Use Custom Resources for Game Data:**
|
||||
|
||||
```gdscript
|
||||
# WeaponData.gd - Custom Resource
|
||||
extends Resource
|
||||
class_name WeaponData
|
||||
|
||||
@export var weapon_name: String = "Sword"
|
||||
@export var damage: int = 10
|
||||
@export var attack_speed: float = 1.0
|
||||
@export var sprite: Texture2D
|
||||
|
||||
# Weapon.gd - Uses the resource
|
||||
extends Node2D
|
||||
class_name Weapon
|
||||
|
||||
@export var weapon_data: WeaponData
|
||||
|
||||
func _ready() -> void:
|
||||
if weapon_data:
|
||||
$Sprite2D.texture = weapon_data.sprite
|
||||
|
||||
func attack() -> int:
|
||||
return weapon_data.damage if weapon_data else 0
|
||||
```
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
### Object Pooling (MANDATORY for Spawned Objects)
|
||||
|
||||
```gdscript
|
||||
# ObjectPool.gd - Generic pooling system
|
||||
extends Node
|
||||
class_name ObjectPool
|
||||
|
||||
@export var pool_scene: PackedScene
|
||||
@export var initial_size: int = 20
|
||||
|
||||
var _pool: Array[Node] = []
|
||||
|
||||
func _ready() -> void:
|
||||
for i in initial_size:
|
||||
var instance := pool_scene.instantiate()
|
||||
instance.set_process(false)
|
||||
instance.set_physics_process(false)
|
||||
instance.visible = false
|
||||
add_child(instance)
|
||||
_pool.append(instance)
|
||||
|
||||
func get_object() -> Node:
|
||||
for obj in _pool:
|
||||
if not obj.visible:
|
||||
obj.visible = true
|
||||
obj.set_process(true)
|
||||
obj.set_physics_process(true)
|
||||
return obj
|
||||
|
||||
# Expand pool if needed
|
||||
var new_obj := pool_scene.instantiate()
|
||||
add_child(new_obj)
|
||||
_pool.append(new_obj)
|
||||
return new_obj
|
||||
|
||||
func return_object(obj: Node) -> void:
|
||||
obj.set_process(false)
|
||||
obj.set_physics_process(false)
|
||||
obj.visible = false
|
||||
obj.position = Vector2.ZERO
|
||||
```
|
||||
|
||||
### Process Optimization
|
||||
|
||||
**Use Appropriate Process Methods:**
|
||||
|
||||
```gdscript
|
||||
extends Node2D
|
||||
|
||||
# For physics calculations (fixed timestep)
|
||||
func _physics_process(delta: float) -> void:
|
||||
# Movement, collision detection
|
||||
pass
|
||||
|
||||
# For visual updates and input
|
||||
func _process(delta: float) -> void:
|
||||
# Animations, UI updates
|
||||
pass
|
||||
|
||||
# Use timers or signals instead of checking every frame
|
||||
func _ready() -> void:
|
||||
var timer := Timer.new()
|
||||
timer.wait_time = 1.0
|
||||
timer.timeout.connect(_check_condition)
|
||||
add_child(timer)
|
||||
timer.start()
|
||||
|
||||
func _check_condition() -> void:
|
||||
# Check something once per second instead of 60 times
|
||||
pass
|
||||
```
|
||||
|
||||
### Memory Management
|
||||
|
||||
**Prevent Memory Leaks:**
|
||||
|
||||
```gdscript
|
||||
extends Node
|
||||
|
||||
var _connections: Array[Callable] = []
|
||||
|
||||
func _ready() -> void:
|
||||
# Store connections for cleanup
|
||||
var callable := GameManager.score_changed.connect(_on_score_changed)
|
||||
_connections.append(callable)
|
||||
|
||||
func _exit_tree() -> void:
|
||||
# Clean up connections
|
||||
for connection in _connections:
|
||||
if connection.is_valid():
|
||||
connection.disconnect()
|
||||
_connections.clear()
|
||||
|
||||
# Use queue_free() not free() for nodes
|
||||
func remove_enemy(enemy: Node) -> void:
|
||||
enemy.queue_free() # Safe deletion
|
||||
```
|
||||
|
||||
## Test-Driven Development (MANDATORY)
|
||||
|
||||
### GUT (Godot Unit Test) for GDScript
|
||||
|
||||
**Write Tests FIRST:**
|
||||
|
||||
```gdscript
|
||||
# test/unit/test_player_health.gd
|
||||
extends GutTest
|
||||
|
||||
var player_health: PlayerHealth
|
||||
|
||||
func before_each() -> void:
|
||||
player_health = PlayerHealth.new()
|
||||
player_health.max_health = 100
|
||||
|
||||
func test_take_damage_reduces_health() -> void:
|
||||
# Arrange
|
||||
player_health.current_health = 100
|
||||
|
||||
# Act
|
||||
player_health.take_damage(30)
|
||||
|
||||
# Assert
|
||||
assert_eq(player_health.current_health, 70, "Health should be reduced by damage amount")
|
||||
|
||||
func test_health_cannot_go_negative() -> void:
|
||||
# Arrange
|
||||
player_health.current_health = 10
|
||||
|
||||
# Act
|
||||
player_health.take_damage(20)
|
||||
|
||||
# Assert
|
||||
assert_eq(player_health.current_health, 0, "Health should not go below 0")
|
||||
|
||||
func test_died_signal_emitted_at_zero_health() -> void:
|
||||
# Arrange
|
||||
player_health.current_health = 10
|
||||
watch_signals(player_health)
|
||||
|
||||
# Act
|
||||
player_health.take_damage(10)
|
||||
|
||||
# Assert
|
||||
assert_signal_emitted(player_health, "died")
|
||||
```
|
||||
|
||||
### GoDotTest for C#
|
||||
|
||||
```csharp
|
||||
using Godot;
|
||||
using GoDotTest;
|
||||
|
||||
[TestClass]
|
||||
public class PlayerControllerTests : TestClass
|
||||
{
|
||||
private PlayerController _player;
|
||||
|
||||
[TestInitialize]
|
||||
public void Setup()
|
||||
{
|
||||
_player = new PlayerController();
|
||||
_player.MaxHealth = 100;
|
||||
}
|
||||
|
||||
[Test]
|
||||
public void TakeDamage_ReducesHealth()
|
||||
{
|
||||
// Arrange
|
||||
_player.CurrentHealth = 100;
|
||||
|
||||
// Act
|
||||
_player.TakeDamage(30);
|
||||
|
||||
// Assert
|
||||
AssertThat(_player.CurrentHealth).IsEqualTo(70);
|
||||
}
|
||||
|
||||
[Test]
|
||||
public void TakeDamage_EmitsDiedSignal_WhenHealthReachesZero()
|
||||
{
|
||||
// Arrange
|
||||
_player.CurrentHealth = 10;
|
||||
var signalEmitted = false;
|
||||
_player.Died += () => signalEmitted = true;
|
||||
|
||||
// Act
|
||||
_player.TakeDamage(10);
|
||||
|
||||
// Assert
|
||||
AssertThat(signalEmitted).IsTrue();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Input Handling
|
||||
|
||||
### Godot Input System
|
||||
|
||||
**Input Map Configuration:**
|
||||
|
||||
```gdscript
|
||||
# Configure in Project Settings -> Input Map
|
||||
# Actions: "move_left", "move_right", "jump", "attack"
|
||||
|
||||
extends CharacterBody2D
|
||||
|
||||
@export var speed: float = 300.0
|
||||
@export var jump_velocity: float = -400.0
|
||||
|
||||
func _physics_process(delta: float) -> void:
|
||||
# Add gravity
|
||||
if not is_on_floor():
|
||||
velocity.y += ProjectSettings.get_setting("physics/2d/default_gravity") * delta
|
||||
|
||||
# Handle jump
|
||||
if Input.is_action_just_pressed("jump") and is_on_floor():
|
||||
velocity.y = jump_velocity
|
||||
|
||||
# Handle movement
|
||||
var direction := Input.get_axis("move_left", "move_right")
|
||||
velocity.x = direction * speed
|
||||
|
||||
move_and_slide()
|
||||
|
||||
# For responsive input (use _unhandled_input for UI priority)
|
||||
func _unhandled_input(event: InputEvent) -> void:
|
||||
if event.is_action_pressed("attack"):
|
||||
_perform_attack()
|
||||
```
|
||||
|
||||
## Scene Management
|
||||
|
||||
### Scene Loading and Transitions
|
||||
|
||||
```gdscript
|
||||
# SceneManager.gd - Autoload singleton
|
||||
extends Node
|
||||
|
||||
var current_scene: Node = null
|
||||
|
||||
func _ready() -> void:
|
||||
var root := get_tree().root
|
||||
current_scene = root.get_child(root.get_child_count() - 1)
|
||||
|
||||
func change_scene(path: String) -> void:
|
||||
call_deferred("_deferred_change_scene", path)
|
||||
|
||||
func _deferred_change_scene(path: String) -> void:
|
||||
# Free current scene
|
||||
current_scene.queue_free()
|
||||
|
||||
# Load new scene
|
||||
var new_scene := ResourceLoader.load(path) as PackedScene
|
||||
current_scene = new_scene.instantiate()
|
||||
get_tree().root.add_child(current_scene)
|
||||
get_tree().current_scene = current_scene
|
||||
|
||||
# With loading screen
|
||||
func change_scene_with_loading(path: String) -> void:
|
||||
# Show loading screen
|
||||
var loading_screen := preload("res://scenes/ui/loading_screen.tscn").instantiate()
|
||||
get_tree().root.add_child(loading_screen)
|
||||
|
||||
# Load in background
|
||||
ResourceLoader.load_threaded_request(path)
|
||||
|
||||
# Wait for completion
|
||||
while ResourceLoader.load_threaded_get_status(path) != ResourceLoader.THREAD_LOAD_LOADED:
|
||||
await get_tree().process_frame
|
||||
|
||||
# Switch scenes
|
||||
loading_screen.queue_free()
|
||||
change_scene(path)
|
||||
```
|
||||
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
res://
|
||||
├── scenes/
|
||||
│ ├── main/
|
||||
│ │ ├── main_menu.tscn
|
||||
│ │ └── game.tscn
|
||||
│ ├── levels/
|
||||
│ │ ├── level_1.tscn
|
||||
│ │ └── level_2.tscn
|
||||
│ ├── player/
|
||||
│ │ └── player.tscn
|
||||
│ └── ui/
|
||||
│ ├── hud.tscn
|
||||
│ └── pause_menu.tscn
|
||||
├── scripts/
|
||||
│ ├── player/
|
||||
│ │ ├── player_controller.gd
|
||||
│ │ └── player_health.gd
|
||||
│ ├── enemies/
|
||||
│ │ └── enemy_base.gd
|
||||
│ ├── systems/
|
||||
│ │ ├── game_manager.gd
|
||||
│ │ └── scene_manager.gd
|
||||
│ └── ui/
|
||||
│ └── hud_controller.gd
|
||||
├── resources/
|
||||
│ ├── weapons/
|
||||
│ │ └── sword_data.tres
|
||||
│ └── enemies/
|
||||
│ └── slime_data.tres
|
||||
├── assets/
|
||||
│ ├── sprites/
|
||||
│ ├── audio/
|
||||
│ └── fonts/
|
||||
├── tests/
|
||||
│ ├── unit/
|
||||
│ │ └── test_player_health.gd
|
||||
│ └── integration/
|
||||
│ └── test_level_loading.gd
|
||||
└── project.godot
|
||||
```
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### TDD Story Implementation Process
|
||||
|
||||
1. **Read Story Requirements:**
|
||||
- Understand acceptance criteria
|
||||
- Identify performance requirements (60+ FPS)
|
||||
- Determine GDScript vs C# needs
|
||||
|
||||
2. **Write Tests FIRST (Red Phase):**
|
||||
- Write failing unit tests in GUT/GoDotTest
|
||||
- Define expected behavior
|
||||
- Run tests to confirm they fail
|
||||
|
||||
3. **Implement Feature (Green Phase):**
|
||||
- Write minimal code to pass tests
|
||||
- Follow Godot patterns and conventions
|
||||
- Use static typing in GDScript
|
||||
- Choose appropriate language (GDScript/C#)
|
||||
|
||||
4. **Refactor (Refactor Phase):**
|
||||
- Optimize for performance
|
||||
- Clean up code structure
|
||||
- Ensure 60+ FPS maintained
|
||||
- Run profiler to validate
|
||||
|
||||
5. **Integration Testing:**
|
||||
- Test scene interactions
|
||||
- Validate performance targets
|
||||
- Test on all platforms
|
||||
|
||||
6. **Update Documentation:**
|
||||
- Mark story checkboxes complete
|
||||
- Document performance metrics
|
||||
- Update File List
|
||||
|
||||
### Performance Checklist
|
||||
|
||||
- [ ] Stable 60+ FPS achieved
|
||||
- [ ] Static typing used in all GDScript
|
||||
- [ ] Object pooling for spawned entities
|
||||
- [ ] No memory leaks detected
|
||||
- [ ] Draw calls optimized
|
||||
- [ ] Appropriate process methods used
|
||||
- [ ] Signals properly connected/disconnected
|
||||
- [ ] Tests written FIRST (TDD)
|
||||
- [ ] 80%+ test coverage
|
||||
|
||||
## Performance Targets
|
||||
|
||||
### Frame Rate Requirements
|
||||
|
||||
- **Desktop**: 60+ FPS minimum (144 FPS for high-refresh)
|
||||
- **Mobile**: 60 FPS on mid-range devices
|
||||
- **Web**: 60 FPS with appropriate export settings
|
||||
- **Frame Time**: <16.67ms consistently
|
||||
|
||||
### Memory Management
|
||||
|
||||
- **Scene Memory**: Keep under platform limits
|
||||
- **Texture Memory**: Optimize imports, use compression
|
||||
- **Object Pooling**: Required for bullets, particles, enemies
|
||||
- **Reference Cleanup**: Prevent memory leaks
|
||||
|
||||
### Optimization Priorities
|
||||
|
||||
1. **Profile First**: Use Godot profiler to identify bottlenecks
|
||||
2. **Optimize Algorithms**: Better algorithms beat micro-optimizations
|
||||
3. **Reduce Draw Calls**: Batch rendering, use atlases
|
||||
4. **Static Typing**: 10-20% performance gain in GDScript
|
||||
5. **Language Choice**: Use C# for compute-heavy operations
|
||||
|
||||
## General Optimization
|
||||
|
||||
### Anti-Patterns
|
||||
|
||||
1. **Security Holes**
|
||||
- Buffer overflows
|
||||
- SQL injection vectors
|
||||
- Unvalidated user input
|
||||
- Timing attacks
|
||||
- Memory disclosure
|
||||
- Race conditions with security impact
|
||||
|
||||
2. **Platform Sabotage**
|
||||
- Fighting Godot's scene system
|
||||
- Reimplementing platform features
|
||||
- Ignoring hardware capabilities
|
||||
|
||||
## GDScript Optimization
|
||||
|
||||
### Performance Destroyers
|
||||
|
||||
1. **Type System Crimes**
|
||||
- Dynamic typing anywhere (10-20% performance loss)
|
||||
- Variant usage in hot paths
|
||||
- Dictionary/Array without typed variants
|
||||
- Missing return type hints
|
||||
- Untyped function parameters
|
||||
|
||||
2. **Allocation Disasters**
|
||||
- Creating Arrays/Dictionaries in loops
|
||||
- String concatenation with +
|
||||
- Unnecessary Node instantiation
|
||||
- Resource loading in game loop
|
||||
- Signal connections without caching
|
||||
|
||||
3. **Process Method Abuse**
|
||||
- \_process() when \_physics_process() suffices
|
||||
- Frame-by-frame checks for rare events
|
||||
- get_node() calls every frame
|
||||
- Node path resolution in loops
|
||||
- Unnecessary process enabling
|
||||
|
||||
### GDScript Death Sentences
|
||||
|
||||
```gdscript
|
||||
# CRIME: Dynamic typing
|
||||
var health = 100 # Dies. var health: int = 100
|
||||
|
||||
# CRIME: String concatenation in loop
|
||||
for i in range(1000):
|
||||
text += str(i) # Dies. Use StringBuffer or Array.join()
|
||||
|
||||
# CRIME: get_node every frame
|
||||
func _process(delta):
|
||||
$UI/Score.text = str(score) # Dies. Cache the node reference
|
||||
|
||||
# CRIME: Creating objects in loop
|
||||
for enemy in enemies:
|
||||
var bullet = Bullet.new() # Dies. Object pool
|
||||
|
||||
# CRIME: Untyped arrays
|
||||
var enemies = [] # Dies. var enemies: Array[Enemy] = []
|
||||
|
||||
# CRIME: Path finding every frame
|
||||
func _process(delta):
|
||||
find_node("Player") # Dies. Store reference in _ready()
|
||||
|
||||
# CRIME: Signal spam
|
||||
for i in range(100):
|
||||
emit_signal("updated", i) # Dies. Batch updates
|
||||
|
||||
# CRIME: Resource loading in game
|
||||
func shoot():
|
||||
var bullet_scene = load("res://bullet.tscn") # Dies. Preload
|
||||
|
||||
# CRIME: Checking rare conditions every frame
|
||||
func _process(delta):
|
||||
if player_died: # Dies. Use signals
|
||||
game_over()
|
||||
|
||||
# CRIME: Node creation without pooling
|
||||
func spawn_particle():
|
||||
var p = Particle.new() # Dies. Pool everything spawned
|
||||
add_child(p)
|
||||
```
|
||||
|
||||
### The Only Acceptable GDScript Patterns
|
||||
|
||||
```gdscript
|
||||
# GOOD: Static typing everywhere
|
||||
var health: int = 100
|
||||
var speed: float = 300.0
|
||||
var enemies: Array[Enemy] = []
|
||||
|
||||
# GOOD: Cached node references
|
||||
@onready var score_label: Label = $UI/Score
|
||||
@onready var health_bar: ProgressBar = $UI/HealthBar
|
||||
|
||||
# GOOD: Preloaded resources
|
||||
const BULLET_SCENE: PackedScene = preload("res://bullet.tscn")
|
||||
const EXPLOSION_SOUND: AudioStream = preload("res://explosion.ogg")
|
||||
|
||||
# GOOD: Object pooling
|
||||
var bullet_pool: Array[Bullet] = []
|
||||
func _ready() -> void:
|
||||
for i in 50:
|
||||
var bullet := BULLET_SCENE.instantiate() as Bullet
|
||||
bullet.visible = false
|
||||
bullet_pool.append(bullet)
|
||||
|
||||
# GOOD: Typed dictionaries
|
||||
var player_stats: Dictionary = {
|
||||
"health": 100,
|
||||
"armor": 50,
|
||||
"speed": 300.0
|
||||
}
|
||||
|
||||
# GOOD: Efficient string building
|
||||
func build_text(count: int) -> String:
|
||||
var parts: PackedStringArray = []
|
||||
for i in count:
|
||||
parts.append(str(i))
|
||||
return "".join(parts)
|
||||
|
||||
# GOOD: Timer-based checks
|
||||
func _ready() -> void:
|
||||
var timer := Timer.new()
|
||||
timer.wait_time = 1.0
|
||||
timer.timeout.connect(_check_rare_condition)
|
||||
add_child(timer)
|
||||
timer.start()
|
||||
|
||||
# GOOD: Batch operations
|
||||
var updates_pending: Array[int] = []
|
||||
func queue_update(value: int) -> void:
|
||||
updates_pending.append(value)
|
||||
if updates_pending.size() == 1:
|
||||
call_deferred("_process_updates")
|
||||
|
||||
func _process_updates() -> void:
|
||||
# Process all updates at once
|
||||
for value in updates_pending:
|
||||
# Do work
|
||||
pass
|
||||
updates_pending.clear()
|
||||
|
||||
# GOOD: Const for compile-time optimization
|
||||
const MAX_ENEMIES: int = 100
|
||||
const GRAVITY: float = 980.0
|
||||
const DEBUG_MODE: bool = false
|
||||
```
|
||||
|
||||
### GDScript-Specific Optimization Rules
|
||||
|
||||
1. **ALWAYS use static typing** - Non-negotiable 10-20% free performance
|
||||
2. **NEVER use get_node() in loops** - Cache everything in @onready
|
||||
3. **NEVER load() in gameplay** - preload() or ResourceLoader
|
||||
4. **NEVER create nodes without pooling** - Pool or die
|
||||
5. **NEVER concatenate strings in loops** - PackedStringArray.join()
|
||||
6. **ALWAYS use const for constants** - Compile-time optimization
|
||||
7. **ALWAYS specify Array types** - Array[Type] not Array
|
||||
8. **NEVER check conditions every frame** - Use signals and timers
|
||||
9. **ALWAYS batch similar operations** - One update, not many
|
||||
10. **NEVER trust the profiler isn't watching** - It always is
|
||||
|
||||
## Godot C# Optimization
|
||||
|
||||
### Anti-Patterns
|
||||
|
||||
1. **Performance Destroyers**
|
||||
- ANY allocation in render/game loop
|
||||
- String operations in hot paths
|
||||
- LINQ anywhere (it allocates, period)
|
||||
- Boxing/unboxing in performance code
|
||||
- Virtual calls when direct calls possible
|
||||
- Cache-hostile data layouts
|
||||
- Synchronous I/O blocking computation
|
||||
2. **Algorithmic Incompetence**
|
||||
- O(n²) when O(n log n) exists
|
||||
- O(n³) = fired
|
||||
- Linear search in sorted data
|
||||
- Recalculating invariants
|
||||
- Branches in SIMD loops
|
||||
- Random memory access patterns
|
||||
|
||||
3. **Architectural Cancer**
|
||||
- Abstractions that don't eliminate code
|
||||
- Single-implementation interfaces
|
||||
- Factory factories
|
||||
- 3+ levels of indirection
|
||||
- Reflection in performance paths
|
||||
- Manager classes (lazy design)
|
||||
- Event systems for direct calls
|
||||
- Not using SIMD where available
|
||||
- Thread-unsafe code in parallel contexts
|
||||
|
||||
## C#/GODOT SPECIFIC DEATH SENTENCES
|
||||
|
||||
### Instant Rejection Patterns
|
||||
|
||||
```csharp
|
||||
// CRIME: LINQ in game code
|
||||
units.Where(u => u.IsAlive).ToList() // Dies. Pre-filtered array.
|
||||
|
||||
// CRIME: String operations
|
||||
$"Player {name} scored {score}" // Dies. StringBuilder or byte buffer.
|
||||
|
||||
// CRIME: Boxing
|
||||
object value = 42; // Dies. Generic or specific type.
|
||||
|
||||
// CRIME: Foreach on List<T>
|
||||
foreach(var item in list) // Dies. for(int i = 0; i < list.Count; i++)
|
||||
|
||||
// CRIME: Properties doing work
|
||||
public int Count => CalculateCount(); // Dies. Cache or field.
|
||||
|
||||
// CRIME: Virtual by default
|
||||
public virtual void Update() // Dies. Sealed unless NEEDED.
|
||||
|
||||
// CRIME: Events for direct calls
|
||||
public event Action OnUpdate; // Dies. Direct method call.
|
||||
|
||||
// CRIME: Reflection
|
||||
typeof(T).GetMethod("Update") // Dies. Direct call or delegates.
|
||||
|
||||
// CRIME: Async in game loop
|
||||
await LoadDataAsync(); // Dies. Preload or synchronous.
|
||||
|
||||
// CRIME: GD.Print in production
|
||||
GD.Print($"Debug: {value}"); // Dies. Conditional compilation.
|
||||
```
|
||||
|
||||
### Godot-Specific Crimes
|
||||
|
||||
```csharp
|
||||
// CRIME: GetNode every frame
|
||||
GetNode<Label>("UI/Score") // Dies. Cache in _Ready().
|
||||
|
||||
// CRIME: Creating Nodes dynamically
|
||||
var bullet = bulletScene.Instantiate(); // Dies. Object pool.
|
||||
|
||||
// CRIME: Signal connections in loops
|
||||
unit.HealthChanged += OnHealthChanged; // Dies. Batch updates.
|
||||
|
||||
// CRIME: _Process without need
|
||||
public override void _Process(double delta) // Dies. Use _PhysicsProcess or events.
|
||||
|
||||
// CRIME: Autoload abuse
|
||||
GetNode<GameManager>("/root/GameManager") // Dies. Direct reference.
|
||||
```
|
||||
|
||||
### The Only Acceptable Patterns
|
||||
|
||||
```csharp
|
||||
// GOOD: Pre-allocated buffers
|
||||
private readonly Unit[] _units = new Unit[MAX_UNITS];
|
||||
private readonly int[] _indices = new int[MAX_UNITS];
|
||||
|
||||
// GOOD: Struct over class
|
||||
public struct UnitData { public int Health; public Vector2I Position; }
|
||||
|
||||
// GOOD: Data-oriented design
|
||||
public struct Units {
|
||||
public int[] Health;
|
||||
public Vector2I[] Positions;
|
||||
public bool[] IsAlive;
|
||||
}
|
||||
|
||||
// GOOD: Zero-allocation update
|
||||
public void Update() {
|
||||
int count = _activeCount;
|
||||
for (int i = 0; i < count; i++) {
|
||||
ref Unit unit = ref _units[i];
|
||||
unit.Position += unit.Velocity;
|
||||
}
|
||||
}
|
||||
|
||||
// GOOD: Compile-time elimination
|
||||
#if DEBUG
|
||||
GD.Print("Debug info");
|
||||
#endif
|
||||
```
|
||||
|
||||
These guidelines ensure consistent, high-quality Godot game development that meets performance targets, maintains code quality, and follows TDD practices across all implementation stories.
|
||||
156
expansion-packs/bmad-godot-game-dev/data/elicitation-methods.md
Normal file
156
expansion-packs/bmad-godot-game-dev/data/elicitation-methods.md
Normal file
@@ -0,0 +1,156 @@
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Elicitation Methods Data
|
||||
|
||||
## Core Reflective Methods
|
||||
|
||||
**Expand or Contract for Audience**
|
||||
|
||||
- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
|
||||
- Identify specific target audience if relevant
|
||||
- Tailor content complexity and depth accordingly
|
||||
|
||||
**Explain Reasoning (CoT Step-by-Step)**
|
||||
|
||||
- Walk through the step-by-step thinking process
|
||||
- Reveal underlying assumptions and decision points
|
||||
- Show how conclusions were reached from current role's perspective
|
||||
|
||||
**Critique and Refine**
|
||||
|
||||
- Review output for flaws, inconsistencies, or improvement areas
|
||||
- Identify specific weaknesses from role's expertise
|
||||
- Suggest refined version reflecting domain knowledge
|
||||
|
||||
## Structural Analysis Methods
|
||||
|
||||
**Analyze Logical Flow and Dependencies**
|
||||
|
||||
- Examine content structure for logical progression
|
||||
- Check internal consistency and coherence
|
||||
- Identify and validate dependencies between elements
|
||||
- Confirm effective ordering and sequencing
|
||||
|
||||
**Assess Alignment with Overall Goals**
|
||||
|
||||
- Evaluate content contribution to stated objectives
|
||||
- Identify any misalignments or gaps
|
||||
- Interpret alignment from specific role's perspective
|
||||
- Suggest adjustments to better serve goals
|
||||
|
||||
## Risk and Challenge Methods
|
||||
|
||||
**Identify Potential Risks and Unforeseen Issues**
|
||||
|
||||
- Brainstorm potential risks from role's expertise
|
||||
- Identify overlooked edge cases or scenarios
|
||||
- Anticipate unintended consequences
|
||||
- Highlight implementation challenges
|
||||
|
||||
**Challenge from Critical Perspective**
|
||||
|
||||
- Adopt critical stance on current content
|
||||
- Play devil's advocate from specified viewpoint
|
||||
- Argue against proposal highlighting weaknesses
|
||||
- Apply YAGNI principles when appropriate (scope trimming)
|
||||
|
||||
## Creative Exploration Methods
|
||||
|
||||
**Tree of Thoughts Deep Dive**
|
||||
|
||||
- Break problem into discrete "thoughts" or intermediate steps
|
||||
- Explore multiple reasoning paths simultaneously
|
||||
- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
|
||||
- Apply search algorithms (BFS/DFS) to find optimal solution paths
|
||||
|
||||
**Hindsight is 20/20: The 'If Only...' Reflection**
|
||||
|
||||
- Imagine retrospective scenario based on current content
|
||||
- Identify the one "if only we had known/done X..." insight
|
||||
- Describe imagined consequences humorously or dramatically
|
||||
- Extract actionable learnings for current context
|
||||
|
||||
## Multi-Persona Collaboration Methods
|
||||
|
||||
**Agile Team Perspective Shift**
|
||||
|
||||
- Rotate through different Scrum team member viewpoints
|
||||
- Product Owner: Focus on user value and business impact
|
||||
- Scrum Master: Examine process flow and team dynamics
|
||||
- Developer: Assess technical implementation and complexity
|
||||
- QA: Identify testing scenarios and quality concerns
|
||||
|
||||
**Stakeholder Round Table**
|
||||
|
||||
- Convene virtual meeting with multiple personas
|
||||
- Each persona contributes unique perspective on content
|
||||
- Identify conflicts and synergies between viewpoints
|
||||
- Synthesize insights into actionable recommendations
|
||||
|
||||
**Meta-Prompting Analysis**
|
||||
|
||||
- Step back to analyze the structure and logic of current approach
|
||||
- Question the format and methodology being used
|
||||
- Suggest alternative frameworks or mental models
|
||||
- Optimize the elicitation process itself
|
||||
|
||||
## Advanced 2025 Techniques
|
||||
|
||||
**Self-Consistency Validation**
|
||||
|
||||
- Generate multiple reasoning paths for same problem
|
||||
- Compare consistency across different approaches
|
||||
- Identify most reliable and robust solution
|
||||
- Highlight areas where approaches diverge and why
|
||||
|
||||
**ReWOO (Reasoning Without Observation)**
|
||||
|
||||
- Separate parametric reasoning from tool-based actions
|
||||
- Create reasoning plan without external dependencies
|
||||
- Identify what can be solved through pure reasoning
|
||||
- Optimize for efficiency and reduced token usage
|
||||
|
||||
**Persona-Pattern Hybrid**
|
||||
|
||||
- Combine specific role expertise with elicitation pattern
|
||||
- Architect + Risk Analysis: Deep technical risk assessment
|
||||
- UX Expert + User Journey: End-to-end experience critique
|
||||
- PM + Stakeholder Analysis: Multi-perspective impact review
|
||||
|
||||
**Emergent Collaboration Discovery**
|
||||
|
||||
- Allow multiple perspectives to naturally emerge
|
||||
- Identify unexpected insights from persona interactions
|
||||
- Explore novel combinations of viewpoints
|
||||
- Capture serendipitous discoveries from multi-agent thinking
|
||||
|
||||
## Game-Based Elicitation Methods
|
||||
|
||||
**Red Team vs Blue Team**
|
||||
|
||||
- Red Team: Attack the proposal, find vulnerabilities
|
||||
- Blue Team: Defend and strengthen the approach
|
||||
- Competitive analysis reveals blind spots
|
||||
- Results in more robust, battle-tested solutions
|
||||
|
||||
**Innovation Tournament**
|
||||
|
||||
- Pit multiple alternative approaches against each other
|
||||
- Score each approach across different criteria
|
||||
- Crowd-source evaluation from different personas
|
||||
- Identify winning combination of features
|
||||
|
||||
**Escape Room Challenge**
|
||||
|
||||
- Present content as constraints to work within
|
||||
- Find creative solutions within tight limitations
|
||||
- Identify minimum viable approach
|
||||
- Discover innovative workarounds and optimizations
|
||||
|
||||
## Process Control
|
||||
|
||||
**Proceed / No Further Actions**
|
||||
|
||||
- Acknowledge choice to finalize current work
|
||||
- Accept output as-is or move to next step
|
||||
- Prepare to continue without additional elicitation
|
||||
@@ -0,0 +1,3 @@
|
||||
# User-Defined Preferred Patterns and Preferences
|
||||
|
||||
None Listed
|
||||
Reference in New Issue
Block a user