mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 04:51:46 +00:00
48 coordinated Claude Code subagents for indie game development: - 3 leadership agents (creative-director, technical-director, producer) - 10 department leads (game-designer, lead-programmer, art-director, etc.) - 23 specialist agents (gameplay, engine, AI, networking, UI, tools, etc.) - 12 engine-specific agents (Godot, Unity, Unreal with sub-specialists) Infrastructure: - 34 skills (slash commands) for workflows, reviews, and team orchestration - 8 hooks for commit validation, asset checks, session management - 11 path-scoped rules enforcing domain-specific standards - 28 templates for design docs, reports, and collaborative protocols Key features: - User-driven collaboration protocol (Question → Options → Decision → Draft → Approval) - Engine version awareness with knowledge-gap detection (Godot 4.6 pinned) - Phase gate system for development milestone validation - CLAUDE.md kept under 80 lines with extracted doc imports Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1.9 KiB
1.9 KiB
Technical Design: [System Name]
Document Status
- Version: 1.0
- Last Updated: [Date]
- Author: [Agent/Person]
- Reviewer: lead-programmer
- Related ADR: [ADR-XXXX if applicable]
- Related Design Doc: [Link to game design doc this implements]
Overview
[2-3 sentence summary of what this system does and why it exists]
Requirements
Functional Requirements
Non-Functional Requirements
- Performance: [Budget — e.g., "< 1ms per frame"]
- Memory: [Budget — e.g., "< 50MB at peak"]
- Scalability: [Limits — e.g., "Support up to 1000 entities"]
- Thread Safety: [Requirements]
Architecture
System Diagram
[ASCII diagram showing components and data flow]
Component Breakdown
| Component | Responsibility | Owns |
|---|---|---|
| [Name] | [What it does] | [What data it owns] |
Public API
[Interface/API definition in pseudocode or target language]
Data Structures
[Key data structures with field descriptions]
Data Flow
[Step by step: how data moves through the system during a typical frame]
Implementation Plan
Phase 1: [Core Functionality]
- [Task 1]
- [Task 2]
Phase 2: [Extended Features]
- [Task 3]
- [Task 4]
Phase 3: [Optimization/Polish]
- [Task 5]
Dependencies
| Depends On | For What |
|---|---|
| [System] | [Reason] |
| Depended On By | For What |
|---|---|
| [System] | [Reason] |
Testing Strategy
- Unit Tests: [What to test at unit level]
- Integration Tests: [Cross-system tests needed]
- Performance Tests: [Benchmarks to create]
- Edge Cases: [Specific scenarios to test]
Known Limitations
[What this design intentionally does NOT support and why]
Future Considerations
[What might need to change if requirements evolve — but do NOT build for this now]