bmad-method 4.31.0 → 4.32.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.vscode/settings.json +1 -7
- package/CHANGELOG.md +108 -173
- package/README.md +40 -0
- package/bmad-core/agents/analyst.md +1 -1
- package/bmad-core/agents/architect.md +2 -3
- package/bmad-core/agents/bmad-master.md +0 -1
- package/bmad-core/agents/bmad-orchestrator.md +9 -10
- package/bmad-core/agents/dev.md +1 -2
- package/bmad-core/agents/pm.md +3 -1
- package/bmad-core/agents/po.md +1 -1
- package/bmad-core/agents/qa.md +1 -1
- package/bmad-core/agents/sm.md +1 -1
- package/bmad-core/agents/ux-expert.md +1 -1
- package/bmad-core/bmad-core/user-guide.md +0 -0
- package/bmad-core/data/bmad-kb.md +12 -2
- package/bmad-core/data/elicitation-methods.md +20 -0
- package/bmad-core/enhanced-ide-development-workflow.md +43 -0
- package/bmad-core/tasks/advanced-elicitation.md +2 -0
- package/bmad-core/tasks/create-brownfield-story.md +20 -3
- package/bmad-core/tasks/document-project.md +19 -13
- package/bmad-core/tasks/facilitate-brainstorming-session.md +1 -1
- package/bmad-core/tasks/index-docs.md +0 -1
- package/bmad-core/tasks/kb-mode-interaction.md +3 -3
- package/bmad-core/tasks/review-story.md +18 -1
- package/bmad-core/user-guide.md +7 -6
- package/bmad-core/working-in-the-brownfield.md +39 -36
- package/dist/agents/analyst.txt +6 -6
- package/dist/agents/architect.txt +8 -3
- package/dist/agents/bmad-master.txt +2 -1
- package/dist/agents/pm.txt +9 -2
- package/dist/agents/po.txt +2 -318
- package/dist/agents/qa.txt +0 -1
- package/dist/agents/sm.txt +3 -3
- package/dist/agents/ux-expert.txt +2 -297
- package/dist/expansion-packs/bmad-2d-phaser-game-dev/teams/phaser-2d-nodejs-game-team.txt +6 -6
- package/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-architect.txt +4047 -0
- package/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.txt +1520 -185
- package/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-developer.txt +214 -1229
- package/dist/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.txt +537 -373
- package/dist/expansion-packs/bmad-2d-unity-game-dev/teams/unity-2d-game-team.txt +6917 -2140
- package/dist/teams/team-all.txt +30 -25
- package/dist/teams/team-fullstack.txt +27 -21
- package/dist/teams/team-ide-minimal.txt +5 -322
- package/dist/teams/team-no-ui.txt +25 -16
- package/expansion-packs/bmad-2d-phaser-game-dev/data/development-guidelines.md +3 -1
- package/expansion-packs/bmad-2d-unity-game-dev/agent-teams/unity-2d-game-team.yaml +1 -0
- package/expansion-packs/bmad-2d-unity-game-dev/agents/game-architect.md +80 -0
- package/expansion-packs/bmad-2d-unity-game-dev/agents/game-designer.md +21 -16
- package/expansion-packs/bmad-2d-unity-game-dev/agents/game-developer.md +25 -25
- package/expansion-packs/bmad-2d-unity-game-dev/agents/game-sm.md +15 -14
- package/expansion-packs/bmad-2d-unity-game-dev/checklists/game-architect-checklist.md +396 -0
- package/expansion-packs/bmad-2d-unity-game-dev/checklists/game-change-checklist.md +203 -0
- package/expansion-packs/bmad-2d-unity-game-dev/checklists/game-design-checklist.md +1 -1
- package/expansion-packs/bmad-2d-unity-game-dev/checklists/game-story-dod-checklist.md +93 -121
- package/expansion-packs/bmad-2d-unity-game-dev/config.yaml +1 -1
- package/expansion-packs/bmad-2d-unity-game-dev/data/bmad-kb.md +593 -68
- package/expansion-packs/bmad-2d-unity-game-dev/tasks/correct-course-game.md +151 -0
- package/expansion-packs/bmad-2d-unity-game-dev/tasks/create-game-story.md +165 -198
- package/expansion-packs/bmad-2d-unity-game-dev/tasks/validate-game-story.md +200 -0
- package/expansion-packs/bmad-2d-unity-game-dev/templates/game-architecture-tmpl.yaml +938 -453
- package/expansion-packs/bmad-2d-unity-game-dev/templates/game-brief-tmpl.yaml +3 -3
- package/expansion-packs/bmad-2d-unity-game-dev/templates/game-design-doc-tmpl.yaml +517 -155
- package/expansion-packs/bmad-2d-unity-game-dev/templates/game-story-tmpl.yaml +12 -12
- package/expansion-packs/bmad-2d-unity-game-dev/templates/level-design-doc-tmpl.yaml +11 -11
- package/package.json +79 -76
- package/tools/cli.js +9 -0
- package/tools/flattener/main.js +559 -0
- package/tools/installer/lib/installer.js +1 -1
- package/tools/installer/package.json +1 -1
- package/.husky/pre-commit +0 -2
- package/.prettierignore +0 -21
- package/.prettierrc +0 -23
|
@@ -1,545 +1,1030 @@
|
|
|
1
1
|
template:
|
|
2
|
-
id: game-architecture-template-
|
|
2
|
+
id: game-architecture-template-v3
|
|
3
3
|
name: Game Architecture Document
|
|
4
|
-
version:
|
|
4
|
+
version: 3.0
|
|
5
5
|
output:
|
|
6
6
|
format: markdown
|
|
7
|
-
filename:
|
|
8
|
-
title: "{{
|
|
7
|
+
filename: docs/game-architecture.md
|
|
8
|
+
title: "{{project_name}} Game Architecture Document"
|
|
9
9
|
|
|
10
10
|
workflow:
|
|
11
11
|
mode: interactive
|
|
12
|
+
elicitation: advanced-elicitation
|
|
12
13
|
|
|
13
14
|
sections:
|
|
14
|
-
- id: initial-setup
|
|
15
|
-
instruction: |
|
|
16
|
-
This template creates a comprehensive game architecture document specifically for Unity + C# projects. This should provide the technical foundation for all game development stories and epics.
|
|
17
|
-
|
|
18
|
-
If available, review any provided documents: Game Design Document (GDD), Technical Preferences. This architecture should support all game mechanics defined in the GDD.
|
|
19
|
-
|
|
20
15
|
- id: introduction
|
|
21
16
|
title: Introduction
|
|
22
|
-
instruction:
|
|
23
|
-
|
|
24
|
-
This document outlines the complete technical architecture for {{Game Title}}, a 2D game built with Unity and C#. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems.
|
|
25
|
-
|
|
26
|
-
This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining stable performance and cross-platform compatibility.
|
|
17
|
+
instruction: |
|
|
18
|
+
If available, review any provided relevant documents to gather all relevant context before beginning. At a minimum you should locate and review: Game Design Document (GDD), Technical Preferences. If these are not available, ask the user what docs will provide the basis for the game architecture.
|
|
27
19
|
sections:
|
|
28
|
-
- id:
|
|
20
|
+
- id: intro-content
|
|
21
|
+
content: |
|
|
22
|
+
This document outlines the complete technical architecture for {{project_name}}, a 2D game built with Unity and C#. It serves as the technical foundation for AI-driven game development, ensuring consistency and scalability across all game systems.
|
|
23
|
+
|
|
24
|
+
This architecture is designed to support the gameplay mechanics defined in the Game Design Document while maintaining stable performance and cross-platform compatibility.
|
|
25
|
+
- id: starter-template
|
|
26
|
+
title: Starter Template or Existing Project
|
|
27
|
+
instruction: |
|
|
28
|
+
Before proceeding further with game architecture design, check if the project is based on a Unity template or existing codebase:
|
|
29
|
+
|
|
30
|
+
1. Review the GDD and brainstorming brief for any mentions of:
|
|
31
|
+
- Unity templates (2D Core, 2D Mobile, 2D URP, etc.)
|
|
32
|
+
- Existing Unity projects being used as a foundation
|
|
33
|
+
- Asset Store packages or game development frameworks
|
|
34
|
+
- Previous game projects to be cloned or adapted
|
|
35
|
+
|
|
36
|
+
2. If a starter template or existing project is mentioned:
|
|
37
|
+
- Ask the user to provide access via one of these methods:
|
|
38
|
+
- Link to the Unity template documentation
|
|
39
|
+
- Upload/attach the project files (for small projects)
|
|
40
|
+
- Share a link to the project repository (GitHub, GitLab, etc.)
|
|
41
|
+
- Analyze the starter/existing project to understand:
|
|
42
|
+
- Pre-configured Unity version and render pipeline
|
|
43
|
+
- Project structure and organization patterns
|
|
44
|
+
- Built-in packages and dependencies
|
|
45
|
+
- Existing architectural patterns and conventions
|
|
46
|
+
- Any limitations or constraints imposed by the starter
|
|
47
|
+
- Use this analysis to inform and align your architecture decisions
|
|
48
|
+
|
|
49
|
+
3. If no starter template is mentioned but this is a greenfield project:
|
|
50
|
+
- Suggest appropriate Unity templates based on the target platform
|
|
51
|
+
- Explain the benefits (faster setup, best practices, package integration)
|
|
52
|
+
- Let the user decide whether to use one
|
|
53
|
+
|
|
54
|
+
4. If the user confirms no starter template will be used:
|
|
55
|
+
- Proceed with architecture design from scratch
|
|
56
|
+
- Note that manual setup will be required for all Unity configuration
|
|
57
|
+
|
|
58
|
+
Document the decision here before proceeding with the architecture design. If none, just say N/A
|
|
59
|
+
elicit: true
|
|
60
|
+
- id: changelog
|
|
29
61
|
title: Change Log
|
|
62
|
+
type: table
|
|
63
|
+
columns: [Date, Version, Description, Author]
|
|
30
64
|
instruction: Track document versions and changes
|
|
65
|
+
|
|
66
|
+
- id: high-level-architecture
|
|
67
|
+
title: High Level Architecture
|
|
68
|
+
instruction: |
|
|
69
|
+
This section contains multiple subsections that establish the foundation of the game architecture. Present all subsections together at once.
|
|
70
|
+
elicit: true
|
|
71
|
+
sections:
|
|
72
|
+
- id: technical-summary
|
|
73
|
+
title: Technical Summary
|
|
74
|
+
instruction: |
|
|
75
|
+
Provide a brief paragraph (3-5 sentences) overview of:
|
|
76
|
+
- The game's overall architecture style (component-based Unity architecture)
|
|
77
|
+
- Key game systems and their relationships
|
|
78
|
+
- Primary technology choices (Unity, C#, target platforms)
|
|
79
|
+
- Core architectural patterns being used (MonoBehaviour components, ScriptableObjects, Unity Events)
|
|
80
|
+
- Reference back to the GDD goals and how this architecture supports them
|
|
81
|
+
- id: high-level-overview
|
|
82
|
+
title: High Level Overview
|
|
83
|
+
instruction: |
|
|
84
|
+
Based on the GDD's Technical Assumptions section, describe:
|
|
85
|
+
|
|
86
|
+
1. The main architectural style (component-based Unity architecture with MonoBehaviours)
|
|
87
|
+
2. Repository structure decision from GDD (single Unity project vs multiple projects)
|
|
88
|
+
3. Game system architecture (modular systems, manager singletons, data-driven design)
|
|
89
|
+
4. Primary player interaction flow and core game loop
|
|
90
|
+
5. Key architectural decisions and their rationale (render pipeline, input system, physics)
|
|
91
|
+
- id: project-diagram
|
|
92
|
+
title: High Level Project Diagram
|
|
93
|
+
type: mermaid
|
|
94
|
+
mermaid_type: graph
|
|
95
|
+
instruction: |
|
|
96
|
+
Create a Mermaid diagram that visualizes the high-level game architecture. Consider:
|
|
97
|
+
- Core game systems (Input, Physics, Rendering, Audio, UI)
|
|
98
|
+
- Game managers and their responsibilities
|
|
99
|
+
- Data flow between systems
|
|
100
|
+
- External integrations (platform services, analytics)
|
|
101
|
+
- Player interaction points
|
|
102
|
+
|
|
103
|
+
- id: architectural-patterns
|
|
104
|
+
title: Architectural and Design Patterns
|
|
105
|
+
instruction: |
|
|
106
|
+
List the key high-level patterns that will guide the game architecture. For each pattern:
|
|
107
|
+
|
|
108
|
+
1. Present 2-3 viable options if multiple exist
|
|
109
|
+
2. Provide your recommendation with clear rationale
|
|
110
|
+
3. Get user confirmation before finalizing
|
|
111
|
+
4. These patterns should align with the GDD's technical assumptions and project goals
|
|
112
|
+
|
|
113
|
+
Common Unity patterns to consider:
|
|
114
|
+
- Component patterns (MonoBehaviour composition, ScriptableObject data)
|
|
115
|
+
- Game management patterns (Singleton managers, Event systems, State machines)
|
|
116
|
+
- Data patterns (ScriptableObject configuration, Save/Load systems)
|
|
117
|
+
- Unity-specific patterns (Object pooling, Coroutines, Unity Events)
|
|
118
|
+
template: "- **{{pattern_name}}:** {{pattern_description}} - _Rationale:_ {{rationale}}"
|
|
119
|
+
examples:
|
|
120
|
+
- "**Component-Based Architecture:** Using MonoBehaviour components for game logic - _Rationale:_ Aligns with Unity's design philosophy and enables reusable, testable game systems"
|
|
121
|
+
- "**ScriptableObject Data:** Using ScriptableObjects for game configuration - _Rationale:_ Enables data-driven design and easy balancing without code changes"
|
|
122
|
+
- "**Event-Driven Communication:** Using Unity Events and C# events for system decoupling - _Rationale:_ Supports modular architecture and easier testing"
|
|
123
|
+
|
|
124
|
+
- id: tech-stack
|
|
125
|
+
title: Tech Stack
|
|
126
|
+
instruction: |
|
|
127
|
+
This is the DEFINITIVE technology selection section for the Unity game. Work with the user to make specific choices:
|
|
128
|
+
|
|
129
|
+
1. Review GDD technical assumptions and any preferences from {root}/data/technical-preferences.yaml or an attached technical-preferences
|
|
130
|
+
2. For each category, present 2-3 viable options with pros/cons
|
|
131
|
+
3. Make a clear recommendation based on project needs
|
|
132
|
+
4. Get explicit user approval for each selection
|
|
133
|
+
5. Document exact versions (avoid "latest" - pin specific versions)
|
|
134
|
+
6. This table is the single source of truth - all other docs must reference these choices
|
|
135
|
+
|
|
136
|
+
Key decisions to finalize - before displaying the table, ensure you are aware of or ask the user about:
|
|
137
|
+
|
|
138
|
+
- Unity version and render pipeline
|
|
139
|
+
- Target platforms and their specific requirements
|
|
140
|
+
- Unity Package Manager packages and versions
|
|
141
|
+
- Third-party assets or frameworks
|
|
142
|
+
- Platform SDKs and services
|
|
143
|
+
- Build and deployment tools
|
|
144
|
+
|
|
145
|
+
Upon render of the table, ensure the user is aware of the importance of this sections choices, should also look for gaps or disagreements with anything, ask for any clarifications if something is unclear why its in the list, and also right away elicit feedback.
|
|
146
|
+
elicit: true
|
|
147
|
+
sections:
|
|
148
|
+
- id: platform-infrastructure
|
|
149
|
+
title: Platform Infrastructure
|
|
150
|
+
template: |
|
|
151
|
+
- **Target Platforms:** {{target_platforms}}
|
|
152
|
+
- **Primary Platform:** {{primary_platform}}
|
|
153
|
+
- **Platform Services:** {{platform_services_list}}
|
|
154
|
+
- **Distribution:** {{distribution_channels}}
|
|
155
|
+
- id: technology-stack-table
|
|
156
|
+
title: Technology Stack Table
|
|
31
157
|
type: table
|
|
158
|
+
columns: [Category, Technology, Version, Purpose, Rationale]
|
|
159
|
+
instruction: Populate the technology stack table with all relevant Unity technologies
|
|
160
|
+
examples:
|
|
161
|
+
- "| **Game Engine** | Unity | 2022.3.21f1 | Core game development platform | Latest LTS version, stable 2D tooling, comprehensive package ecosystem |"
|
|
162
|
+
- "| **Language** | C# | 10.0 | Primary scripting language | Unity's native language, strong typing, excellent tooling |"
|
|
163
|
+
- "| **Render Pipeline** | Universal Render Pipeline (URP) | 14.0.10 | 2D/3D rendering | Optimized for mobile, excellent 2D features, future-proof |"
|
|
164
|
+
- "| **Input System** | Unity Input System | 1.7.0 | Cross-platform input handling | Modern input system, supports multiple devices, rebindable controls |"
|
|
165
|
+
- "| **Physics** | Unity 2D Physics | Built-in | 2D collision and physics | Integrated Box2D, optimized for 2D games |"
|
|
166
|
+
- "| **Audio** | Unity Audio | Built-in | Audio playback and mixing | Built-in audio system with mixer support |"
|
|
167
|
+
- "| **Testing** | Unity Test Framework | 1.1.33 | Unit and integration testing | Built-in testing framework based on NUnit |"
|
|
168
|
+
|
|
169
|
+
- id: data-models
|
|
170
|
+
title: Game Data Models
|
|
171
|
+
instruction: |
|
|
172
|
+
Define the core game data models/entities using Unity's ScriptableObject system:
|
|
173
|
+
|
|
174
|
+
1. Review GDD requirements and identify key game entities
|
|
175
|
+
2. For each model, explain its purpose and relationships
|
|
176
|
+
3. Include key attributes and data types appropriate for Unity/C#
|
|
177
|
+
4. Show relationships between models using ScriptableObject references
|
|
178
|
+
5. Discuss design decisions with user
|
|
179
|
+
|
|
180
|
+
Create a clear conceptual model before moving to specific implementations.
|
|
181
|
+
elicit: true
|
|
182
|
+
repeatable: true
|
|
183
|
+
sections:
|
|
184
|
+
- id: model
|
|
185
|
+
title: "{{model_name}}"
|
|
32
186
|
template: |
|
|
33
|
-
|
|
34
|
-
|
|
187
|
+
**Purpose:** {{model_purpose}}
|
|
188
|
+
|
|
189
|
+
**Key Attributes:**
|
|
190
|
+
- {{attribute_1}}: {{type_1}} - {{description_1}}
|
|
191
|
+
- {{attribute_2}}: {{type_2}} - {{description_2}}
|
|
192
|
+
|
|
193
|
+
**Relationships:**
|
|
194
|
+
- {{relationship_1}}
|
|
195
|
+
- {{relationship_2}}
|
|
35
196
|
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
197
|
+
**ScriptableObject Implementation:**
|
|
198
|
+
- Create as `[CreateAssetMenu]` ScriptableObject
|
|
199
|
+
- Store in `Assets/_Project/Data/{{ModelName}}/`
|
|
200
|
+
|
|
201
|
+
- id: components
|
|
202
|
+
title: Game Systems & Components
|
|
203
|
+
instruction: |
|
|
204
|
+
Based on the architectural patterns, tech stack, and data models from above:
|
|
205
|
+
|
|
206
|
+
1. Identify major game systems and their responsibilities
|
|
207
|
+
2. Consider Unity's component-based architecture with MonoBehaviours
|
|
208
|
+
3. Define clear interfaces between systems using Unity Events or C# events
|
|
209
|
+
4. For each system, specify:
|
|
210
|
+
- Primary responsibility and core functionality
|
|
211
|
+
- Key MonoBehaviour components and ScriptableObjects
|
|
212
|
+
- Dependencies on other systems
|
|
213
|
+
- Unity-specific implementation details (lifecycle methods, coroutines, etc.)
|
|
214
|
+
|
|
215
|
+
5. Create system diagrams where helpful using Unity terminology
|
|
216
|
+
elicit: true
|
|
39
217
|
sections:
|
|
40
|
-
- id:
|
|
41
|
-
|
|
218
|
+
- id: system-list
|
|
219
|
+
repeatable: true
|
|
220
|
+
title: "{{system_name}} System"
|
|
221
|
+
template: |
|
|
222
|
+
**Responsibility:** {{system_description}}
|
|
223
|
+
|
|
224
|
+
**Key Components:**
|
|
225
|
+
- {{component_1}} (MonoBehaviour)
|
|
226
|
+
- {{component_2}} (ScriptableObject)
|
|
227
|
+
- {{component_3}} (Manager/Controller)
|
|
228
|
+
|
|
229
|
+
**Unity Implementation Details:**
|
|
230
|
+
- Lifecycle: {{lifecycle_methods}}
|
|
231
|
+
- Events: {{unity_events_used}}
|
|
232
|
+
- Dependencies: {{system_dependencies}}
|
|
233
|
+
|
|
234
|
+
**Files to Create:**
|
|
235
|
+
- `Assets/_Project/Scripts/{{SystemName}}/{{MainScript}}.cs`
|
|
236
|
+
- `Assets/_Project/Prefabs/{{SystemName}}/{{MainPrefab}}.prefab`
|
|
237
|
+
- id: component-diagrams
|
|
238
|
+
title: System Interaction Diagrams
|
|
239
|
+
type: mermaid
|
|
42
240
|
instruction: |
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
-
|
|
46
|
-
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
**Target Performance:** Stable frame rate on {{target_device}}
|
|
58
|
-
- id: technology-stack
|
|
59
|
-
title: Technology Stack
|
|
60
|
-
template: |
|
|
61
|
-
**Core Engine:** Unity 2022 LTS or newer
|
|
62
|
-
**Language:** C# 10+
|
|
63
|
-
**Build Tool:** Unity Build Pipeline
|
|
64
|
-
**Package Manager:** Unity Package Manager
|
|
65
|
-
**Testing:** Unity Test Framework (NUnit)
|
|
66
|
-
**Deployment:** {{deployment_platform}}
|
|
67
|
-
|
|
68
|
-
- id: project-structure
|
|
69
|
-
title: Project Structure
|
|
70
|
-
instruction: Define the complete project organization that developers will follow
|
|
71
|
-
sections:
|
|
72
|
-
- id: repository-organization
|
|
73
|
-
title: Repository Organization
|
|
74
|
-
instruction: Design a clear folder structure for game development
|
|
75
|
-
type: code
|
|
76
|
-
language: text
|
|
241
|
+
Create Mermaid diagrams to visualize game system relationships. Options:
|
|
242
|
+
- System architecture diagram for high-level view
|
|
243
|
+
- Component interaction diagram for detailed relationships
|
|
244
|
+
- Sequence diagrams for complex game loops (Update, FixedUpdate flows)
|
|
245
|
+
Choose the most appropriate for clarity and Unity-specific understanding
|
|
246
|
+
|
|
247
|
+
- id: gameplay-systems
|
|
248
|
+
title: Gameplay Systems Architecture
|
|
249
|
+
instruction: |
|
|
250
|
+
Define the core gameplay systems that drive the player experience. Focus on game-specific logic and mechanics.
|
|
251
|
+
elicit: true
|
|
252
|
+
sections:
|
|
253
|
+
- id: gameplay-overview
|
|
254
|
+
title: Gameplay Systems Overview
|
|
77
255
|
template: |
|
|
78
|
-
{{
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
instruction: Define how TypeScript modules should be organized
|
|
92
|
-
sections:
|
|
93
|
-
- id: scene-structure
|
|
94
|
-
title: Scene Structure
|
|
95
|
-
type: bullet-list
|
|
96
|
-
template: |
|
|
97
|
-
- Each scene in separate file
|
|
98
|
-
- Scene-specific logic contained in scripts within the scene
|
|
99
|
-
- Use a loading scene for asynchronous loading
|
|
100
|
-
- id: game-object-pattern
|
|
101
|
-
title: Game Object Pattern
|
|
102
|
-
type: bullet-list
|
|
103
|
-
template: |
|
|
104
|
-
- Component-based architecture using MonoBehaviours
|
|
105
|
-
- Reusable game objects as prefabs
|
|
106
|
-
- Data-driven design with ScriptableObjects
|
|
107
|
-
- id: system-architecture
|
|
108
|
-
title: System Architecture
|
|
109
|
-
type: bullet-list
|
|
110
|
-
template: |
|
|
111
|
-
- Singleton managers for global systems (e.g., GameManager, AudioManager)
|
|
112
|
-
- Event-driven communication using UnityEvents or C# events
|
|
113
|
-
- Clear separation of concerns between components
|
|
256
|
+
**Core Game Loop:** {{core_game_loop_description}}
|
|
257
|
+
|
|
258
|
+
**Player Actions:** {{primary_player_actions}}
|
|
259
|
+
|
|
260
|
+
**Game State Flow:** {{game_state_transitions}}
|
|
261
|
+
- id: gameplay-components
|
|
262
|
+
title: Gameplay Component Architecture
|
|
263
|
+
template: |
|
|
264
|
+
**Player Controller Components:**
|
|
265
|
+
- {{player_controller_components}}
|
|
266
|
+
|
|
267
|
+
**Game Logic Components:**
|
|
268
|
+
- {{game_logic_components}}
|
|
114
269
|
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
270
|
+
**Interaction Systems:**
|
|
271
|
+
- {{interaction_system_components}}
|
|
272
|
+
|
|
273
|
+
- id: component-architecture
|
|
274
|
+
title: Component Architecture Details
|
|
275
|
+
instruction: |
|
|
276
|
+
Define detailed Unity component architecture patterns and conventions for the game.
|
|
277
|
+
elicit: true
|
|
118
278
|
sections:
|
|
119
|
-
- id:
|
|
120
|
-
title:
|
|
279
|
+
- id: monobehaviour-patterns
|
|
280
|
+
title: MonoBehaviour Patterns
|
|
121
281
|
template: |
|
|
122
|
-
**
|
|
282
|
+
**Component Composition:** {{component_composition_approach}}
|
|
123
283
|
|
|
124
|
-
**
|
|
284
|
+
**Lifecycle Management:** {{lifecycle_management_patterns}}
|
|
125
285
|
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
286
|
+
**Component Communication:** {{component_communication_methods}}
|
|
287
|
+
- id: scriptableobject-usage
|
|
288
|
+
title: ScriptableObject Architecture
|
|
289
|
+
template: |
|
|
290
|
+
**Data Architecture:** {{scriptableobject_data_patterns}}
|
|
129
291
|
|
|
130
|
-
**
|
|
292
|
+
**Configuration Management:** {{config_scriptableobject_usage}}
|
|
131
293
|
|
|
132
|
-
|
|
133
|
-
- A loading scene to handle asynchronous loading
|
|
134
|
-
- A `GameManager` to persist between scenes and hold necessary data
|
|
294
|
+
**Runtime Data:** {{runtime_scriptableobject_patterns}}
|
|
135
295
|
|
|
136
|
-
|
|
296
|
+
- id: physics-config
|
|
297
|
+
title: Physics Configuration
|
|
298
|
+
instruction: |
|
|
299
|
+
Define Unity 2D physics setup and configuration for the game.
|
|
300
|
+
elicit: true
|
|
301
|
+
sections:
|
|
302
|
+
- id: physics-settings
|
|
303
|
+
title: Physics Settings
|
|
304
|
+
template: |
|
|
305
|
+
**Physics 2D Settings:** {{physics_2d_configuration}}
|
|
137
306
|
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
307
|
+
**Collision Layers:** {{collision_layer_matrix}}
|
|
308
|
+
|
|
309
|
+
**Physics Materials:** {{physics_materials_setup}}
|
|
310
|
+
- id: rigidbody-patterns
|
|
311
|
+
title: Rigidbody Patterns
|
|
142
312
|
template: |
|
|
143
|
-
**
|
|
313
|
+
**Player Physics:** {{player_rigidbody_setup}}
|
|
144
314
|
|
|
145
|
-
**
|
|
315
|
+
**Object Physics:** {{object_physics_patterns}}
|
|
146
316
|
|
|
147
|
-
|
|
148
|
-
- Game settings (audio, controls)
|
|
149
|
-
- Session data (current level, score)
|
|
150
|
-
- Persistent data (achievements, statistics)
|
|
317
|
+
**Performance Optimization:** {{physics_optimization_strategies}}
|
|
151
318
|
|
|
152
|
-
|
|
319
|
+
- id: input-system
|
|
320
|
+
title: Input System Architecture
|
|
321
|
+
instruction: |
|
|
322
|
+
Define input handling using Unity's Input System package.
|
|
323
|
+
elicit: true
|
|
324
|
+
sections:
|
|
325
|
+
- id: input-actions
|
|
326
|
+
title: Input Actions Configuration
|
|
327
|
+
template: |
|
|
328
|
+
**Input Action Assets:** {{input_action_asset_structure}}
|
|
153
329
|
|
|
154
|
-
|
|
155
|
-
- Use of `ScriptableObject`s to hold game state data
|
|
156
|
-
- State validation and error recovery
|
|
330
|
+
**Action Maps:** {{input_action_maps}}
|
|
157
331
|
|
|
158
|
-
**
|
|
332
|
+
**Control Schemes:** {{control_schemes_definition}}
|
|
333
|
+
- id: input-handling
|
|
334
|
+
title: Input Handling Patterns
|
|
335
|
+
template: |
|
|
336
|
+
**Player Input:** {{player_input_component_usage}}
|
|
159
337
|
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
338
|
+
**UI Input:** {{ui_input_handling_patterns}}
|
|
339
|
+
|
|
340
|
+
**Input Validation:** {{input_validation_strategies}}
|
|
341
|
+
|
|
342
|
+
- id: state-machines
|
|
343
|
+
title: State Machine Architecture
|
|
344
|
+
instruction: |
|
|
345
|
+
Define state machine patterns for game states, player states, and AI behavior.
|
|
346
|
+
elicit: true
|
|
347
|
+
sections:
|
|
348
|
+
- id: game-state-machine
|
|
349
|
+
title: Game State Machine
|
|
164
350
|
template: |
|
|
165
|
-
**
|
|
351
|
+
**Game States:** {{game_state_definitions}}
|
|
166
352
|
|
|
167
|
-
**
|
|
353
|
+
**State Transitions:** {{game_state_transition_rules}}
|
|
168
354
|
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
355
|
+
**State Management:** {{game_state_manager_implementation}}
|
|
356
|
+
- id: entity-state-machines
|
|
357
|
+
title: Entity State Machines
|
|
358
|
+
template: |
|
|
359
|
+
**Player States:** {{player_state_machine_design}}
|
|
173
360
|
|
|
174
|
-
**
|
|
361
|
+
**AI Behavior States:** {{ai_state_machine_patterns}}
|
|
175
362
|
|
|
176
|
-
|
|
177
|
-
- Asset bundles for platform-specific assets
|
|
178
|
-
- Memory management for large assets
|
|
363
|
+
**Object States:** {{object_state_management}}
|
|
179
364
|
|
|
180
|
-
|
|
365
|
+
- id: ui-architecture
|
|
366
|
+
title: UI Architecture
|
|
367
|
+
instruction: |
|
|
368
|
+
Define Unity UI system architecture using UGUI or UI Toolkit.
|
|
369
|
+
elicit: true
|
|
370
|
+
sections:
|
|
371
|
+
- id: ui-system-choice
|
|
372
|
+
title: UI System Selection
|
|
373
|
+
template: |
|
|
374
|
+
**UI Framework:** {{ui_framework_choice}} (UGUI/UI Toolkit)
|
|
181
375
|
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
376
|
+
**UI Scaling:** {{ui_scaling_strategy}}
|
|
377
|
+
|
|
378
|
+
**Canvas Setup:** {{canvas_configuration}}
|
|
379
|
+
- id: ui-navigation
|
|
380
|
+
title: UI Navigation System
|
|
185
381
|
template: |
|
|
186
|
-
**
|
|
382
|
+
**Screen Management:** {{screen_management_system}}
|
|
187
383
|
|
|
188
|
-
**
|
|
384
|
+
**Navigation Flow:** {{ui_navigation_patterns}}
|
|
189
385
|
|
|
190
|
-
|
|
191
|
-
- Mouse/pointer interaction
|
|
192
|
-
- Touch gestures (mobile)
|
|
193
|
-
- Gamepad support
|
|
386
|
+
**Back Button Handling:** {{back_button_implementation}}
|
|
194
387
|
|
|
195
|
-
|
|
388
|
+
- id: ui-components
|
|
389
|
+
title: UI Component System
|
|
390
|
+
instruction: |
|
|
391
|
+
Define reusable UI components and their implementation patterns.
|
|
392
|
+
elicit: true
|
|
393
|
+
sections:
|
|
394
|
+
- id: ui-component-library
|
|
395
|
+
title: UI Component Library
|
|
396
|
+
template: |
|
|
397
|
+
**Base Components:** {{base_ui_components}}
|
|
196
398
|
|
|
197
|
-
|
|
198
|
-
- Create Action Maps for different input contexts
|
|
199
|
-
- Use the `PlayerInput` component for easy player input handling
|
|
399
|
+
**Custom Components:** {{custom_ui_components}}
|
|
200
400
|
|
|
201
|
-
**
|
|
401
|
+
**Component Prefabs:** {{ui_prefab_organization}}
|
|
402
|
+
- id: ui-data-binding
|
|
403
|
+
title: UI Data Binding
|
|
404
|
+
template: |
|
|
405
|
+
**Data Binding Patterns:** {{ui_data_binding_approach}}
|
|
202
406
|
|
|
203
|
-
|
|
204
|
-
- id: game-mechanics-systems
|
|
205
|
-
title: Game Mechanics Systems
|
|
206
|
-
instruction: For each major mechanic defined in the GDD, create a system specification
|
|
207
|
-
repeatable: true
|
|
208
|
-
sections:
|
|
209
|
-
- id: mechanic-system
|
|
210
|
-
title: "{{mechanic_name}} System"
|
|
211
|
-
template: |
|
|
212
|
-
**Purpose:** {{system_purpose}}
|
|
407
|
+
**UI Events:** {{ui_event_system}}
|
|
213
408
|
|
|
214
|
-
|
|
409
|
+
**View Model Patterns:** {{ui_viewmodel_implementation}}
|
|
215
410
|
|
|
216
|
-
|
|
217
|
-
|
|
218
|
-
|
|
411
|
+
- id: ui-state-management
|
|
412
|
+
title: UI State Management
|
|
413
|
+
instruction: |
|
|
414
|
+
Define how UI state is managed across the game.
|
|
415
|
+
elicit: true
|
|
416
|
+
sections:
|
|
417
|
+
- id: ui-state-patterns
|
|
418
|
+
title: UI State Patterns
|
|
419
|
+
template: |
|
|
420
|
+
**State Persistence:** {{ui_state_persistence}}
|
|
219
421
|
|
|
220
|
-
|
|
422
|
+
**Screen State:** {{screen_state_management}}
|
|
221
423
|
|
|
222
|
-
|
|
424
|
+
**UI Configuration:** {{ui_configuration_management}}
|
|
425
|
+
|
|
426
|
+
- id: scene-management
|
|
427
|
+
title: Scene Management Architecture
|
|
428
|
+
instruction: |
|
|
429
|
+
Define scene loading, unloading, and transition strategies.
|
|
430
|
+
elicit: true
|
|
431
|
+
sections:
|
|
432
|
+
- id: scene-structure
|
|
433
|
+
title: Scene Structure
|
|
434
|
+
template: |
|
|
435
|
+
**Scene Organization:** {{scene_organization_strategy}}
|
|
223
436
|
|
|
224
|
-
|
|
437
|
+
**Scene Hierarchy:** {{scene_hierarchy_patterns}}
|
|
225
438
|
|
|
226
|
-
|
|
227
|
-
|
|
228
|
-
|
|
229
|
-
title: Physics & Collision System
|
|
439
|
+
**Persistent Scenes:** {{persistent_scene_usage}}
|
|
440
|
+
- id: scene-loading
|
|
441
|
+
title: Scene Loading System
|
|
230
442
|
template: |
|
|
231
|
-
**
|
|
443
|
+
**Loading Strategies:** {{scene_loading_patterns}}
|
|
232
444
|
|
|
233
|
-
**
|
|
445
|
+
**Async Loading:** {{async_scene_loading_implementation}}
|
|
234
446
|
|
|
235
|
-
|
|
236
|
-
- Enemy interactions
|
|
237
|
-
- Environmental objects
|
|
238
|
-
- Collectibles and items
|
|
447
|
+
**Loading Screens:** {{loading_screen_management}}
|
|
239
448
|
|
|
240
|
-
|
|
449
|
+
- id: data-persistence
|
|
450
|
+
title: Data Persistence Architecture
|
|
451
|
+
instruction: |
|
|
452
|
+
Define save system and data persistence strategies.
|
|
453
|
+
elicit: true
|
|
454
|
+
sections:
|
|
455
|
+
- id: save-data-structure
|
|
456
|
+
title: Save Data Structure
|
|
457
|
+
template: |
|
|
458
|
+
**Save Data Models:** {{save_data_model_design}}
|
|
241
459
|
|
|
242
|
-
|
|
243
|
-
- Use `Rigidbody2D` for physics-based movement
|
|
244
|
-
- Use `Collider2D` components for collision shapes
|
|
460
|
+
**Serialization Format:** {{serialization_format_choice}}
|
|
245
461
|
|
|
246
|
-
**
|
|
462
|
+
**Data Validation:** {{save_data_validation}}
|
|
463
|
+
- id: persistence-strategy
|
|
464
|
+
title: Persistence Strategy
|
|
465
|
+
template: |
|
|
466
|
+
**Save Triggers:** {{save_trigger_events}}
|
|
467
|
+
|
|
468
|
+
**Auto-Save:** {{auto_save_implementation}}
|
|
247
469
|
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
|
|
470
|
+
**Cloud Save:** {{cloud_save_integration}}
|
|
471
|
+
|
|
472
|
+
- id: save-system
|
|
473
|
+
title: Save System Implementation
|
|
474
|
+
instruction: |
|
|
475
|
+
Define detailed save system implementation patterns.
|
|
476
|
+
elicit: true
|
|
477
|
+
sections:
|
|
478
|
+
- id: save-load-api
|
|
479
|
+
title: Save/Load API
|
|
251
480
|
template: |
|
|
252
|
-
**
|
|
481
|
+
**Save Interface:** {{save_interface_design}}
|
|
253
482
|
|
|
254
|
-
|
|
255
|
-
- Sound effects for actions
|
|
256
|
-
- Audio settings and volume control
|
|
257
|
-
- Mobile audio optimization
|
|
483
|
+
**Load Interface:** {{load_interface_design}}
|
|
258
484
|
|
|
259
|
-
**
|
|
485
|
+
**Error Handling:** {{save_load_error_handling}}
|
|
486
|
+
- id: save-file-management
|
|
487
|
+
title: Save File Management
|
|
488
|
+
template: |
|
|
489
|
+
**File Structure:** {{save_file_structure}}
|
|
260
490
|
|
|
261
|
-
|
|
262
|
-
- Use of `AudioMixer` to control volume levels
|
|
263
|
-
- Object pooling for frequently played sound effects
|
|
491
|
+
**Backup Strategy:** {{save_backup_strategy}}
|
|
264
492
|
|
|
265
|
-
**
|
|
493
|
+
**Migration:** {{save_data_migration_strategy}}
|
|
266
494
|
|
|
267
|
-
|
|
268
|
-
|
|
269
|
-
|
|
495
|
+
- id: analytics-integration
|
|
496
|
+
title: Analytics Integration
|
|
497
|
+
instruction: |
|
|
498
|
+
Define analytics tracking and integration patterns.
|
|
499
|
+
condition: Game requires analytics tracking
|
|
500
|
+
elicit: true
|
|
501
|
+
sections:
|
|
502
|
+
- id: analytics-events
|
|
503
|
+
title: Analytics Event Design
|
|
270
504
|
template: |
|
|
271
|
-
**
|
|
505
|
+
**Event Categories:** {{analytics_event_categories}}
|
|
272
506
|
|
|
273
|
-
|
|
274
|
-
- Menu navigation
|
|
275
|
-
- Modal dialogs
|
|
276
|
-
- Settings screens
|
|
507
|
+
**Custom Events:** {{custom_analytics_events}}
|
|
277
508
|
|
|
278
|
-
**
|
|
509
|
+
**Player Progression:** {{progression_analytics}}
|
|
510
|
+
- id: analytics-implementation
|
|
511
|
+
title: Analytics Implementation
|
|
512
|
+
template: |
|
|
513
|
+
**Analytics SDK:** {{analytics_sdk_choice}}
|
|
279
514
|
|
|
280
|
-
|
|
281
|
-
- Create a `UIManager` to manage UI elements
|
|
282
|
-
- Use events to update UI from game logic
|
|
515
|
+
**Event Tracking:** {{event_tracking_patterns}}
|
|
283
516
|
|
|
284
|
-
**
|
|
517
|
+
**Privacy Compliance:** {{analytics_privacy_considerations}}
|
|
285
518
|
|
|
286
|
-
|
|
287
|
-
|
|
519
|
+
- id: multiplayer-architecture
|
|
520
|
+
title: Multiplayer Architecture
|
|
521
|
+
instruction: |
|
|
522
|
+
Define multiplayer system architecture if applicable.
|
|
523
|
+
condition: Game includes multiplayer features
|
|
524
|
+
elicit: true
|
|
525
|
+
sections:
|
|
526
|
+
- id: networking-approach
|
|
527
|
+
title: Networking Approach
|
|
528
|
+
template: |
|
|
529
|
+
**Networking Solution:** {{networking_solution_choice}}
|
|
530
|
+
|
|
531
|
+
**Architecture Pattern:** {{multiplayer_architecture_pattern}}
|
|
532
|
+
|
|
533
|
+
**Synchronization:** {{state_synchronization_strategy}}
|
|
534
|
+
- id: multiplayer-systems
|
|
535
|
+
title: Multiplayer System Components
|
|
536
|
+
template: |
|
|
537
|
+
**Client Components:** {{multiplayer_client_components}}
|
|
288
538
|
|
|
289
|
-
|
|
290
|
-
|
|
291
|
-
|
|
539
|
+
**Server Components:** {{multiplayer_server_components}}
|
|
540
|
+
|
|
541
|
+
**Network Messages:** {{network_message_design}}
|
|
542
|
+
|
|
543
|
+
- id: rendering-pipeline
|
|
544
|
+
title: Rendering Pipeline Configuration
|
|
545
|
+
instruction: |
|
|
546
|
+
Define Unity rendering pipeline setup and optimization.
|
|
547
|
+
elicit: true
|
|
292
548
|
sections:
|
|
293
|
-
- id:
|
|
294
|
-
title:
|
|
549
|
+
- id: render-pipeline-setup
|
|
550
|
+
title: Render Pipeline Setup
|
|
295
551
|
template: |
|
|
296
|
-
**
|
|
297
|
-
|
|
298
|
-
**
|
|
299
|
-
|
|
300
|
-
|
|
301
|
-
|
|
302
|
-
|
|
303
|
-
|
|
304
|
-
|
|
305
|
-
type: bullet-list
|
|
306
|
-
template: |
|
|
307
|
-
- Bullets and projectiles
|
|
308
|
-
- Particle effects
|
|
309
|
-
- Enemy objects
|
|
310
|
-
- UI elements
|
|
311
|
-
- id: asset-optimization
|
|
312
|
-
title: Asset Optimization
|
|
313
|
-
type: bullet-list
|
|
314
|
-
template: |
|
|
315
|
-
- Sprite atlases
|
|
316
|
-
- Audio compression
|
|
317
|
-
- Mipmaps for textures
|
|
318
|
-
- id: rendering-optimization
|
|
319
|
-
title: Rendering Optimization
|
|
320
|
-
type: bullet-list
|
|
321
|
-
template: |
|
|
322
|
-
- Use the 2D Renderer
|
|
323
|
-
- Batching for sprites
|
|
324
|
-
- Culling off-screen objects
|
|
325
|
-
- id: optimization-files
|
|
326
|
-
title: Files to Create
|
|
327
|
-
type: bullet-list
|
|
328
|
-
template: |
|
|
329
|
-
- `Assets/Scripts/Core/ObjectPool.cs`
|
|
552
|
+
**Pipeline Choice:** {{render_pipeline_choice}} (URP/Built-in)
|
|
553
|
+
|
|
554
|
+
**Pipeline Asset:** {{render_pipeline_asset_config}}
|
|
555
|
+
|
|
556
|
+
**Quality Settings:** {{quality_settings_configuration}}
|
|
557
|
+
- id: rendering-optimization
|
|
558
|
+
title: Rendering Optimization
|
|
559
|
+
template: |
|
|
560
|
+
**Batching Strategies:** {{sprite_batching_optimization}}
|
|
330
561
|
|
|
331
|
-
|
|
332
|
-
|
|
333
|
-
|
|
562
|
+
**Draw Call Optimization:** {{draw_call_reduction_strategies}}
|
|
563
|
+
|
|
564
|
+
**Texture Optimization:** {{texture_optimization_settings}}
|
|
565
|
+
|
|
566
|
+
- id: shader-guidelines
|
|
567
|
+
title: Shader Guidelines
|
|
568
|
+
instruction: |
|
|
569
|
+
Define shader usage and custom shader guidelines.
|
|
570
|
+
elicit: true
|
|
571
|
+
sections:
|
|
572
|
+
- id: shader-usage
|
|
573
|
+
title: Shader Usage Patterns
|
|
574
|
+
template: |
|
|
575
|
+
**Built-in Shaders:** {{builtin_shader_usage}}
|
|
576
|
+
|
|
577
|
+
**Custom Shaders:** {{custom_shader_requirements}}
|
|
578
|
+
|
|
579
|
+
**Shader Variants:** {{shader_variant_management}}
|
|
580
|
+
- id: shader-performance
|
|
581
|
+
title: Shader Performance Guidelines
|
|
582
|
+
template: |
|
|
583
|
+
**Mobile Optimization:** {{mobile_shader_optimization}}
|
|
584
|
+
|
|
585
|
+
**Performance Budgets:** {{shader_performance_budgets}}
|
|
586
|
+
|
|
587
|
+
**Profiling Guidelines:** {{shader_profiling_approach}}
|
|
588
|
+
|
|
589
|
+
- id: sprite-management
|
|
590
|
+
title: Sprite Management
|
|
591
|
+
instruction: |
|
|
592
|
+
Define sprite asset management and optimization strategies.
|
|
593
|
+
elicit: true
|
|
594
|
+
sections:
|
|
595
|
+
- id: sprite-organization
|
|
596
|
+
title: Sprite Organization
|
|
597
|
+
template: |
|
|
598
|
+
**Atlas Strategy:** {{sprite_atlas_organization}}
|
|
599
|
+
|
|
600
|
+
**Sprite Naming:** {{sprite_naming_conventions}}
|
|
601
|
+
|
|
602
|
+
**Import Settings:** {{sprite_import_settings}}
|
|
603
|
+
- id: sprite-optimization
|
|
604
|
+
title: Sprite Optimization
|
|
605
|
+
template: |
|
|
606
|
+
**Compression Settings:** {{sprite_compression_settings}}
|
|
607
|
+
|
|
608
|
+
**Resolution Strategy:** {{sprite_resolution_strategy}}
|
|
609
|
+
|
|
610
|
+
**Memory Optimization:** {{sprite_memory_optimization}}
|
|
611
|
+
|
|
612
|
+
- id: particle-systems
|
|
613
|
+
title: Particle System Architecture
|
|
614
|
+
instruction: |
|
|
615
|
+
Define particle system usage and optimization.
|
|
616
|
+
elicit: true
|
|
617
|
+
sections:
|
|
618
|
+
- id: particle-design
|
|
619
|
+
title: Particle System Design
|
|
620
|
+
template: |
|
|
621
|
+
**Effect Categories:** {{particle_effect_categories}}
|
|
622
|
+
|
|
623
|
+
**Prefab Organization:** {{particle_prefab_organization}}
|
|
624
|
+
|
|
625
|
+
**Pooling Strategy:** {{particle_pooling_implementation}}
|
|
626
|
+
- id: particle-performance
|
|
627
|
+
title: Particle Performance
|
|
628
|
+
template: |
|
|
629
|
+
**Performance Budgets:** {{particle_performance_budgets}}
|
|
630
|
+
|
|
631
|
+
**Mobile Optimization:** {{particle_mobile_optimization}}
|
|
632
|
+
|
|
633
|
+
**LOD Strategy:** {{particle_lod_implementation}}
|
|
634
|
+
|
|
635
|
+
- id: audio-architecture
|
|
636
|
+
title: Audio Architecture
|
|
637
|
+
instruction: |
|
|
638
|
+
Define audio system architecture and implementation.
|
|
639
|
+
elicit: true
|
|
640
|
+
sections:
|
|
641
|
+
- id: audio-system-design
|
|
642
|
+
title: Audio System Design
|
|
643
|
+
template: |
|
|
644
|
+
**Audio Manager:** {{audio_manager_implementation}}
|
|
645
|
+
|
|
646
|
+
**Audio Sources:** {{audio_source_management}}
|
|
647
|
+
|
|
648
|
+
**3D Audio:** {{spatial_audio_implementation}}
|
|
649
|
+
- id: audio-categories
|
|
650
|
+
title: Audio Categories
|
|
651
|
+
template: |
|
|
652
|
+
**Music System:** {{music_system_architecture}}
|
|
653
|
+
|
|
654
|
+
**Sound Effects:** {{sfx_system_design}}
|
|
655
|
+
|
|
656
|
+
**Voice/Dialog:** {{dialog_system_implementation}}
|
|
657
|
+
|
|
658
|
+
- id: audio-mixing
|
|
659
|
+
title: Audio Mixing Configuration
|
|
660
|
+
instruction: |
|
|
661
|
+
Define Unity Audio Mixer setup and configuration.
|
|
662
|
+
elicit: true
|
|
663
|
+
sections:
|
|
664
|
+
- id: mixer-setup
|
|
665
|
+
title: Audio Mixer Setup
|
|
666
|
+
template: |
|
|
667
|
+
**Mixer Groups:** {{audio_mixer_group_structure}}
|
|
668
|
+
|
|
669
|
+
**Effects Chain:** {{audio_effects_configuration}}
|
|
670
|
+
|
|
671
|
+
**Snapshot System:** {{audio_snapshot_usage}}
|
|
672
|
+
- id: dynamic-mixing
|
|
673
|
+
title: Dynamic Audio Mixing
|
|
674
|
+
template: |
|
|
675
|
+
**Volume Control:** {{volume_control_implementation}}
|
|
676
|
+
|
|
677
|
+
**Dynamic Range:** {{dynamic_range_management}}
|
|
678
|
+
|
|
679
|
+
**Platform Optimization:** {{platform_audio_optimization}}
|
|
680
|
+
|
|
681
|
+
- id: sound-banks
|
|
682
|
+
title: Sound Bank Management
|
|
683
|
+
instruction: |
|
|
684
|
+
Define sound asset organization and loading strategies.
|
|
685
|
+
elicit: true
|
|
686
|
+
sections:
|
|
687
|
+
- id: sound-organization
|
|
688
|
+
title: Sound Asset Organization
|
|
689
|
+
template: |
|
|
690
|
+
**Bank Structure:** {{sound_bank_organization}}
|
|
691
|
+
|
|
692
|
+
**Loading Strategy:** {{audio_loading_patterns}}
|
|
693
|
+
|
|
694
|
+
**Memory Management:** {{audio_memory_management}}
|
|
695
|
+
- id: sound-streaming
|
|
696
|
+
title: Audio Streaming
|
|
697
|
+
template: |
|
|
698
|
+
**Streaming Strategy:** {{audio_streaming_implementation}}
|
|
699
|
+
|
|
700
|
+
**Compression Settings:** {{audio_compression_settings}}
|
|
701
|
+
|
|
702
|
+
**Platform Considerations:** {{platform_audio_considerations}}
|
|
703
|
+
|
|
704
|
+
- id: unity-conventions
|
|
705
|
+
title: Unity Development Conventions
|
|
706
|
+
instruction: |
|
|
707
|
+
Define Unity-specific development conventions and best practices.
|
|
708
|
+
elicit: true
|
|
334
709
|
sections:
|
|
335
|
-
- id: game-balance-configuration
|
|
336
|
-
title: Game Balance Configuration
|
|
337
|
-
instruction: Based on GDD, define configurable game parameters using ScriptableObjects
|
|
338
|
-
type: code
|
|
339
|
-
language: c#
|
|
340
|
-
template: |
|
|
341
|
-
// Assets/Scripts/Data/GameBalance.cs
|
|
342
|
-
using UnityEngine;
|
|
343
|
-
|
|
344
|
-
[CreateAssetMenu(fileName = "GameBalance", menuName = "Game/Game Balance")]
|
|
345
|
-
public class GameBalance : ScriptableObject
|
|
346
|
-
{
|
|
347
|
-
public PlayerStats playerStats;
|
|
348
|
-
public EnemyStats enemyStats;
|
|
349
|
-
}
|
|
350
|
-
|
|
351
|
-
[System.Serializable]
|
|
352
|
-
public class PlayerStats
|
|
353
|
-
{
|
|
354
|
-
public float speed;
|
|
355
|
-
public int maxHealth;
|
|
356
|
-
}
|
|
357
|
-
|
|
358
|
-
[System.Serializable]
|
|
359
|
-
public class EnemyStats
|
|
360
|
-
{
|
|
361
|
-
public float speed;
|
|
362
|
-
public int maxHealth;
|
|
363
|
-
public int damage;
|
|
364
|
-
}
|
|
365
|
-
|
|
366
|
-
- id: development-guidelines
|
|
367
|
-
title: Development Guidelines
|
|
368
|
-
instruction: Provide coding standards specific to game development
|
|
369
|
-
sections:
|
|
370
|
-
- id: c#-standards
|
|
371
|
-
title: C# Standards
|
|
372
|
-
sections:
|
|
373
|
-
- id: code-style
|
|
374
|
-
title: Code Style
|
|
375
|
-
type: bullet-list
|
|
376
|
-
template: |
|
|
377
|
-
- Follow .NET coding conventions
|
|
378
|
-
- Use namespaces to organize code
|
|
379
|
-
- Write clean, readable, and maintainable code
|
|
380
710
|
- id: unity-best-practices
|
|
381
711
|
title: Unity Best Practices
|
|
382
|
-
|
|
383
|
-
|
|
384
|
-
title: General Best Practices
|
|
385
|
-
type: bullet-list
|
|
386
|
-
template: |
|
|
387
|
-
- Use the `[SerializeField]` attribute to expose private fields in the Inspector
|
|
388
|
-
- Avoid using `GameObject.Find()` in `Update()`
|
|
389
|
-
- Cache component references in `Awake()` or `Start()`
|
|
390
|
-
- id: component-design
|
|
391
|
-
title: Component Design
|
|
392
|
-
type: bullet-list
|
|
393
|
-
template: |
|
|
394
|
-
- Follow the Single Responsibility Principle
|
|
395
|
-
- Use events for communication between components
|
|
396
|
-
- Use ScriptableObjects for data
|
|
397
|
-
- id: scene-management-practices
|
|
398
|
-
title: Scene Management
|
|
399
|
-
type: bullet-list
|
|
400
|
-
template: |
|
|
401
|
-
- Use a loading scene for asynchronous loading
|
|
402
|
-
- Keep scenes small and focused
|
|
403
|
-
- id: testing-strategy
|
|
404
|
-
title: Testing Strategy
|
|
405
|
-
sections:
|
|
406
|
-
- id: unit-testing
|
|
407
|
-
title: Unit Testing
|
|
408
|
-
type: bullet-list
|
|
409
|
-
template: |
|
|
410
|
-
- Use the Unity Test Framework (Edit Mode tests)
|
|
411
|
-
- Test C# logic in isolation
|
|
412
|
-
- id: integration-testing
|
|
413
|
-
title: Integration Testing
|
|
414
|
-
type: bullet-list
|
|
415
|
-
template: |
|
|
416
|
-
- Use the Unity Test Framework (Play Mode tests)
|
|
417
|
-
- Test the interaction between components and systems
|
|
418
|
-
- id: test-files
|
|
419
|
-
title: Files to Create
|
|
420
|
-
type: bullet-list
|
|
421
|
-
template: |
|
|
422
|
-
- `Assets/Tests/EditMode/`
|
|
423
|
-
- `Assets/Tests/PlayMode/`
|
|
712
|
+
template: |
|
|
713
|
+
**Component Design:** {{unity_component_best_practices}}
|
|
424
714
|
|
|
425
|
-
|
|
426
|
-
|
|
427
|
-
|
|
715
|
+
**Performance Guidelines:** {{unity_performance_guidelines}}
|
|
716
|
+
|
|
717
|
+
**Memory Management:** {{unity_memory_best_practices}}
|
|
718
|
+
- id: unity-workflow
|
|
719
|
+
title: Unity Workflow Conventions
|
|
720
|
+
template: |
|
|
721
|
+
**Scene Workflow:** {{scene_workflow_conventions}}
|
|
722
|
+
|
|
723
|
+
**Prefab Workflow:** {{prefab_workflow_conventions}}
|
|
724
|
+
|
|
725
|
+
**Asset Workflow:** {{asset_workflow_conventions}}
|
|
726
|
+
|
|
727
|
+
- id: external-integrations
|
|
728
|
+
title: External Integrations
|
|
729
|
+
condition: Game requires external service integrations
|
|
730
|
+
instruction: |
|
|
731
|
+
For each external service integration required by the game:
|
|
732
|
+
|
|
733
|
+
1. Identify services needed based on GDD requirements and platform needs
|
|
734
|
+
2. If documentation URLs are unknown, ask user for specifics
|
|
735
|
+
3. Document authentication methods and Unity-specific integration approaches
|
|
736
|
+
4. List specific APIs that will be used
|
|
737
|
+
5. Note any platform-specific SDKs or Unity packages required
|
|
738
|
+
|
|
739
|
+
If no external integrations are needed, state this explicitly and skip to next section.
|
|
740
|
+
elicit: true
|
|
741
|
+
repeatable: true
|
|
428
742
|
sections:
|
|
429
|
-
- id:
|
|
430
|
-
title:
|
|
431
|
-
|
|
432
|
-
-
|
|
433
|
-
|
|
434
|
-
|
|
435
|
-
|
|
436
|
-
|
|
437
|
-
|
|
438
|
-
|
|
439
|
-
|
|
440
|
-
|
|
441
|
-
|
|
442
|
-
|
|
443
|
-
|
|
444
|
-
|
|
743
|
+
- id: integration
|
|
744
|
+
title: "{{service_name}} Integration"
|
|
745
|
+
template: |
|
|
746
|
+
- **Purpose:** {{service_purpose}}
|
|
747
|
+
- **Documentation:** {{service_docs_url}}
|
|
748
|
+
- **Unity Package:** {{unity_package_name}} {{version}}
|
|
749
|
+
- **Platform SDK:** {{platform_sdk_requirements}}
|
|
750
|
+
- **Authentication:** {{auth_method}}
|
|
751
|
+
|
|
752
|
+
**Key Features Used:**
|
|
753
|
+
- {{feature_1}} - {{feature_purpose}}
|
|
754
|
+
- {{feature_2}} - {{feature_purpose}}
|
|
755
|
+
|
|
756
|
+
**Unity Implementation Notes:** {{unity_integration_details}}
|
|
757
|
+
|
|
758
|
+
- id: core-workflows
|
|
759
|
+
title: Core Game Workflows
|
|
760
|
+
type: mermaid
|
|
761
|
+
mermaid_type: sequence
|
|
762
|
+
instruction: |
|
|
763
|
+
Illustrate key game workflows using sequence diagrams:
|
|
764
|
+
|
|
765
|
+
1. Identify critical player journeys from GDD (game loop, level progression, etc.)
|
|
766
|
+
2. Show system interactions including Unity lifecycle methods
|
|
767
|
+
3. Include error handling paths and state transitions
|
|
768
|
+
4. Document async operations (scene loading, asset loading)
|
|
769
|
+
5. Create both high-level game flow and detailed system interaction diagrams
|
|
770
|
+
|
|
771
|
+
Focus on workflows that clarify Unity-specific architecture decisions or complex system interactions.
|
|
772
|
+
elicit: true
|
|
773
|
+
|
|
774
|
+
- id: unity-project-structure
|
|
775
|
+
title: Unity Project Structure
|
|
776
|
+
type: code
|
|
777
|
+
language: plaintext
|
|
778
|
+
instruction: |
|
|
779
|
+
Create a Unity project folder structure that reflects:
|
|
780
|
+
|
|
781
|
+
1. Unity best practices for 2D game organization
|
|
782
|
+
2. The selected render pipeline and packages
|
|
783
|
+
3. Component organization from above systems
|
|
784
|
+
4. Clear separation of concerns for game assets
|
|
785
|
+
5. Testing structure for Unity Test Framework
|
|
786
|
+
6. Platform-specific asset organization
|
|
787
|
+
|
|
788
|
+
Follow Unity naming conventions and folder organization standards.
|
|
789
|
+
elicit: true
|
|
790
|
+
examples:
|
|
791
|
+
- |
|
|
792
|
+
ProjectName/
|
|
793
|
+
├── Assets/
|
|
794
|
+
│ └── _Project/ # Main project folder
|
|
795
|
+
│ ├── Scenes/ # Game scenes
|
|
796
|
+
│ │ ├── Gameplay/ # Level scenes
|
|
797
|
+
│ │ ├── UI/ # UI-only scenes
|
|
798
|
+
│ │ └── Loading/ # Loading scenes
|
|
799
|
+
│ ├── Scripts/ # C# scripts
|
|
800
|
+
│ │ ├── Core/ # Core systems
|
|
801
|
+
│ │ ├── Gameplay/ # Gameplay mechanics
|
|
802
|
+
│ │ ├── UI/ # UI controllers
|
|
803
|
+
│ │ └── Data/ # ScriptableObjects
|
|
804
|
+
│ ├── Prefabs/ # Reusable game objects
|
|
805
|
+
│ │ ├── Characters/ # Player, enemies
|
|
806
|
+
│ │ ├── Environment/ # Level elements
|
|
807
|
+
│ │ └── UI/ # UI prefabs
|
|
808
|
+
│ ├── Art/ # Visual assets
|
|
809
|
+
│ │ ├── Sprites/ # 2D sprites
|
|
810
|
+
│ │ ├── Materials/ # Unity materials
|
|
811
|
+
│ │ └── Shaders/ # Custom shaders
|
|
812
|
+
│ ├── Audio/ # Audio assets
|
|
813
|
+
│ │ ├── Music/ # Background music
|
|
814
|
+
│ │ ├── SFX/ # Sound effects
|
|
815
|
+
│ │ └── Mixers/ # Audio mixers
|
|
816
|
+
│ ├── Data/ # Game data
|
|
817
|
+
│ │ ├── Settings/ # Game settings
|
|
818
|
+
│ │ └── Balance/ # Balance data
|
|
819
|
+
│ └── Tests/ # Unity tests
|
|
820
|
+
│ ├── EditMode/ # Edit mode tests
|
|
821
|
+
│ └── PlayMode/ # Play mode tests
|
|
822
|
+
├── Packages/ # Package Manager
|
|
823
|
+
│ └── manifest.json # Package dependencies
|
|
824
|
+
└── ProjectSettings/ # Unity project settings
|
|
825
|
+
|
|
826
|
+
- id: infrastructure-deployment
|
|
827
|
+
title: Infrastructure and Deployment
|
|
828
|
+
instruction: |
|
|
829
|
+
Define the Unity build and deployment architecture:
|
|
830
|
+
|
|
831
|
+
1. Use Unity's build system and any additional tools
|
|
832
|
+
2. Choose deployment strategy appropriate for target platforms
|
|
833
|
+
3. Define environments (development, staging, production builds)
|
|
834
|
+
4. Establish version control and build pipeline practices
|
|
835
|
+
5. Consider platform-specific requirements and store submissions
|
|
836
|
+
|
|
837
|
+
Get user input on build preferences and CI/CD tool choices for Unity projects.
|
|
838
|
+
elicit: true
|
|
839
|
+
sections:
|
|
840
|
+
- id: unity-build-configuration
|
|
841
|
+
title: Unity Build Configuration
|
|
842
|
+
template: |
|
|
843
|
+
- **Unity Version:** {{unity_version}} LTS
|
|
844
|
+
- **Build Pipeline:** {{build_pipeline_type}}
|
|
845
|
+
- **Addressables:** {{addressables_usage}}
|
|
846
|
+
- **Asset Bundles:** {{asset_bundle_strategy}}
|
|
445
847
|
- id: deployment-strategy
|
|
446
848
|
title: Deployment Strategy
|
|
447
|
-
|
|
448
|
-
-
|
|
449
|
-
|
|
450
|
-
|
|
451
|
-
|
|
452
|
-
|
|
453
|
-
|
|
454
|
-
|
|
849
|
+
template: |
|
|
850
|
+
- **Build Automation:** {{build_automation_tool}}
|
|
851
|
+
- **Version Control:** {{version_control_integration}}
|
|
852
|
+
- **Distribution:** {{distribution_platforms}}
|
|
853
|
+
- id: environments
|
|
854
|
+
title: Build Environments
|
|
855
|
+
repeatable: true
|
|
856
|
+
template: "- **{{env_name}}:** {{env_purpose}} - {{platform_settings}}"
|
|
857
|
+
- id: platform-specific-builds
|
|
858
|
+
title: Platform-Specific Build Settings
|
|
859
|
+
type: code
|
|
860
|
+
language: text
|
|
861
|
+
template: "{{platform_build_configurations}}"
|
|
862
|
+
|
|
863
|
+
- id: coding-standards
|
|
864
|
+
title: Coding Standards
|
|
865
|
+
instruction: |
|
|
866
|
+
These standards are MANDATORY for AI agents working on Unity game development. Work with user to define ONLY the critical rules needed to prevent bad Unity code. Explain that:
|
|
867
|
+
|
|
868
|
+
1. This section directly controls AI developer behavior
|
|
869
|
+
2. Keep it minimal - assume AI knows general C# and Unity best practices
|
|
870
|
+
3. Focus on project-specific Unity conventions and gotchas
|
|
871
|
+
4. Overly detailed standards bloat context and slow development
|
|
872
|
+
5. Standards will be extracted to separate file for dev agent use
|
|
455
873
|
|
|
456
|
-
|
|
457
|
-
|
|
458
|
-
instruction: Break down the architecture implementation into phases that align with the GDD development phases
|
|
874
|
+
For each standard, get explicit user confirmation it's necessary.
|
|
875
|
+
elicit: true
|
|
459
876
|
sections:
|
|
460
|
-
- id:
|
|
461
|
-
title:
|
|
462
|
-
|
|
463
|
-
-
|
|
464
|
-
|
|
465
|
-
|
|
466
|
-
|
|
467
|
-
|
|
468
|
-
|
|
469
|
-
|
|
470
|
-
|
|
471
|
-
|
|
472
|
-
|
|
473
|
-
|
|
474
|
-
|
|
475
|
-
|
|
476
|
-
|
|
477
|
-
|
|
478
|
-
|
|
479
|
-
|
|
877
|
+
- id: core-standards
|
|
878
|
+
title: Core Standards
|
|
879
|
+
template: |
|
|
880
|
+
- **Unity Version:** {{unity_version}} LTS
|
|
881
|
+
- **C# Language Version:** {{csharp_version}}
|
|
882
|
+
- **Code Style:** Microsoft C# conventions + Unity naming
|
|
883
|
+
- **Testing Framework:** Unity Test Framework (NUnit-based)
|
|
884
|
+
- id: unity-naming-conventions
|
|
885
|
+
title: Unity Naming Conventions
|
|
886
|
+
type: table
|
|
887
|
+
columns: [Element, Convention, Example]
|
|
888
|
+
instruction: Only include if deviating from Unity defaults
|
|
889
|
+
examples:
|
|
890
|
+
- "| MonoBehaviour | PascalCase + Component suffix | PlayerController, HealthSystem |"
|
|
891
|
+
- "| ScriptableObject | PascalCase + Data/Config suffix | PlayerData, GameConfig |"
|
|
892
|
+
- "| Prefab | PascalCase descriptive | PlayerCharacter, EnvironmentTile |"
|
|
893
|
+
- id: critical-rules
|
|
894
|
+
title: Critical Unity Rules
|
|
895
|
+
instruction: |
|
|
896
|
+
List ONLY rules that AI might violate or Unity-specific requirements. Examples:
|
|
897
|
+
- "Always cache GetComponent calls in Awake() or Start()"
|
|
898
|
+
- "Use [SerializeField] for private fields that need Inspector access"
|
|
899
|
+
- "Prefer UnityEvents over C# events for Inspector-assignable callbacks"
|
|
900
|
+
- "Never call GameObject.Find() in Update, FixedUpdate, or LateUpdate"
|
|
901
|
+
|
|
902
|
+
Avoid obvious rules like "follow SOLID principles" or "optimize performance"
|
|
903
|
+
repeatable: true
|
|
904
|
+
template: "- **{{rule_name}}:** {{rule_description}}"
|
|
905
|
+
- id: unity-specifics
|
|
906
|
+
title: Unity-Specific Guidelines
|
|
907
|
+
condition: Critical Unity-specific rules needed
|
|
908
|
+
instruction: Add ONLY if critical for preventing AI mistakes with Unity APIs
|
|
480
909
|
sections:
|
|
481
|
-
- id:
|
|
482
|
-
title:
|
|
483
|
-
|
|
484
|
-
template:
|
|
485
|
-
|
|
486
|
-
|
|
487
|
-
|
|
488
|
-
|
|
489
|
-
|
|
490
|
-
|
|
491
|
-
|
|
492
|
-
|
|
493
|
-
|
|
494
|
-
|
|
495
|
-
|
|
496
|
-
|
|
497
|
-
|
|
910
|
+
- id: unity-lifecycle
|
|
911
|
+
title: Unity Lifecycle Rules
|
|
912
|
+
repeatable: true
|
|
913
|
+
template: "- **{{lifecycle_method}}:** {{usage_rule}}"
|
|
914
|
+
|
|
915
|
+
- id: test-strategy
|
|
916
|
+
title: Test Strategy and Standards
|
|
917
|
+
instruction: |
|
|
918
|
+
Work with user to define comprehensive Unity test strategy:
|
|
919
|
+
|
|
920
|
+
1. Use Unity Test Framework for both Edit Mode and Play Mode tests
|
|
921
|
+
2. Decide on test-driven development vs test-after approach
|
|
922
|
+
3. Define test organization and naming for Unity projects
|
|
923
|
+
4. Establish coverage goals for game logic
|
|
924
|
+
5. Determine integration test infrastructure (scene-based testing)
|
|
925
|
+
6. Plan for test data and mock external dependencies
|
|
926
|
+
|
|
927
|
+
Note: Basic info goes in Coding Standards for dev agent. This detailed section is for comprehensive testing strategy.
|
|
928
|
+
elicit: true
|
|
929
|
+
sections:
|
|
930
|
+
- id: testing-philosophy
|
|
931
|
+
title: Testing Philosophy
|
|
932
|
+
template: |
|
|
933
|
+
- **Approach:** {{test_approach}}
|
|
934
|
+
- **Coverage Goals:** {{coverage_targets}}
|
|
935
|
+
- **Test Distribution:** {{edit_mode_vs_play_mode_split}}
|
|
936
|
+
- id: unity-test-types
|
|
937
|
+
title: Unity Test Types and Organization
|
|
498
938
|
sections:
|
|
499
|
-
- id:
|
|
500
|
-
title:
|
|
501
|
-
type: bullet-list
|
|
939
|
+
- id: edit-mode-tests
|
|
940
|
+
title: Edit Mode Tests
|
|
502
941
|
template: |
|
|
503
|
-
-
|
|
504
|
-
-
|
|
505
|
-
-
|
|
506
|
-
-
|
|
507
|
-
|
|
508
|
-
|
|
509
|
-
|
|
942
|
+
- **Framework:** Unity Test Framework (Edit Mode)
|
|
943
|
+
- **File Convention:** {{edit_mode_test_naming}}
|
|
944
|
+
- **Location:** `Assets/_Project/Tests/EditMode/`
|
|
945
|
+
- **Purpose:** C# logic testing without Unity runtime
|
|
946
|
+
- **Coverage Requirement:** {{edit_mode_coverage}}
|
|
947
|
+
|
|
948
|
+
**AI Agent Requirements:**
|
|
949
|
+
- Test ScriptableObject data validation
|
|
950
|
+
- Test utility classes and static methods
|
|
951
|
+
- Test serialization/deserialization logic
|
|
952
|
+
- Mock Unity APIs where necessary
|
|
953
|
+
- id: play-mode-tests
|
|
954
|
+
title: Play Mode Tests
|
|
510
955
|
template: |
|
|
511
|
-
-
|
|
512
|
-
-
|
|
513
|
-
-
|
|
514
|
-
|
|
515
|
-
|
|
516
|
-
|
|
517
|
-
|
|
518
|
-
|
|
519
|
-
|
|
520
|
-
|
|
521
|
-
|
|
522
|
-
|
|
523
|
-
|
|
524
|
-
|
|
525
|
-
|
|
526
|
-
|
|
527
|
-
|
|
528
|
-
|
|
529
|
-
|
|
530
|
-
|
|
531
|
-
|
|
532
|
-
|
|
533
|
-
|
|
534
|
-
|
|
535
|
-
|
|
536
|
-
|
|
537
|
-
|
|
538
|
-
|
|
539
|
-
|
|
540
|
-
|
|
541
|
-
|
|
542
|
-
|
|
543
|
-
|
|
544
|
-
|
|
545
|
-
-
|
|
956
|
+
- **Framework:** Unity Test Framework (Play Mode)
|
|
957
|
+
- **Location:** `Assets/_Project/Tests/PlayMode/`
|
|
958
|
+
- **Purpose:** Integration testing with Unity runtime
|
|
959
|
+
- **Test Scenes:** {{test_scene_requirements}}
|
|
960
|
+
- **Coverage Requirement:** {{play_mode_coverage}}
|
|
961
|
+
|
|
962
|
+
**AI Agent Requirements:**
|
|
963
|
+
- Test MonoBehaviour component interactions
|
|
964
|
+
- Test scene loading and GameObject lifecycle
|
|
965
|
+
- Test physics interactions and collision systems
|
|
966
|
+
- Test UI interactions and event systems
|
|
967
|
+
- id: test-data-management
|
|
968
|
+
title: Test Data Management
|
|
969
|
+
template: |
|
|
970
|
+
- **Strategy:** {{test_data_approach}}
|
|
971
|
+
- **ScriptableObject Fixtures:** {{test_scriptableobject_location}}
|
|
972
|
+
- **Test Scene Templates:** {{test_scene_templates}}
|
|
973
|
+
- **Cleanup Strategy:** {{cleanup_approach}}
|
|
974
|
+
|
|
975
|
+
- id: security
|
|
976
|
+
title: Security Considerations
|
|
977
|
+
instruction: |
|
|
978
|
+
Define security requirements specific to Unity game development:
|
|
979
|
+
|
|
980
|
+
1. Focus on Unity-specific security concerns
|
|
981
|
+
2. Consider platform store requirements
|
|
982
|
+
3. Address save data protection and anti-cheat measures
|
|
983
|
+
4. Define secure communication patterns for multiplayer
|
|
984
|
+
5. These rules directly impact Unity code generation
|
|
985
|
+
elicit: true
|
|
986
|
+
sections:
|
|
987
|
+
- id: save-data-security
|
|
988
|
+
title: Save Data Security
|
|
989
|
+
template: |
|
|
990
|
+
- **Encryption:** {{save_data_encryption_method}}
|
|
991
|
+
- **Validation:** {{save_data_validation_approach}}
|
|
992
|
+
- **Anti-Tampering:** {{anti_tampering_measures}}
|
|
993
|
+
- id: platform-security
|
|
994
|
+
title: Platform Security Requirements
|
|
995
|
+
template: |
|
|
996
|
+
- **Mobile Permissions:** {{mobile_permission_requirements}}
|
|
997
|
+
- **Store Compliance:** {{platform_store_requirements}}
|
|
998
|
+
- **Privacy Policy:** {{privacy_policy_requirements}}
|
|
999
|
+
- id: multiplayer-security
|
|
1000
|
+
title: Multiplayer Security (if applicable)
|
|
1001
|
+
condition: Game includes multiplayer features
|
|
1002
|
+
template: |
|
|
1003
|
+
- **Client Validation:** {{client_validation_rules}}
|
|
1004
|
+
- **Server Authority:** {{server_authority_approach}}
|
|
1005
|
+
- **Anti-Cheat:** {{anti_cheat_measures}}
|
|
1006
|
+
|
|
1007
|
+
- id: checklist-results
|
|
1008
|
+
title: Checklist Results Report
|
|
1009
|
+
instruction: Before running the checklist, offer to output the full game architecture document. Once user confirms, execute the architect-checklist and populate results here.
|
|
1010
|
+
|
|
1011
|
+
- id: next-steps
|
|
1012
|
+
title: Next Steps
|
|
1013
|
+
instruction: |
|
|
1014
|
+
After completing the game architecture:
|
|
1015
|
+
|
|
1016
|
+
1. Review with Game Designer and technical stakeholders
|
|
1017
|
+
2. Begin story implementation with Game Developer agent
|
|
1018
|
+
3. Set up Unity project structure and initial configuration
|
|
1019
|
+
4. Configure version control and build pipeline
|
|
1020
|
+
|
|
1021
|
+
Include specific prompts for next agents if needed.
|
|
1022
|
+
sections:
|
|
1023
|
+
- id: developer-prompt
|
|
1024
|
+
title: Game Developer Prompt
|
|
1025
|
+
instruction: |
|
|
1026
|
+
Create a brief prompt to hand off to Game Developer for story implementation. Include:
|
|
1027
|
+
- Reference to this game architecture document
|
|
1028
|
+
- Key Unity-specific requirements from this architecture
|
|
1029
|
+
- Any Unity package or configuration decisions made here
|
|
1030
|
+
- Request for adherence to established coding standards and patterns
|