mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +00:00
ad540fe75d
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>
26 lines
1.3 KiB
Markdown
26 lines
1.3 KiB
Markdown
# Coding Standards
|
|
|
|
- All game code must include doc comments on public APIs
|
|
- Every system must have a corresponding architecture decision record in `docs/architecture/`
|
|
- Gameplay values must be data-driven (external config), never hardcoded
|
|
- All public methods must be unit-testable (dependency injection over singletons)
|
|
- Commits must reference the relevant design document or task ID
|
|
- **Verification-driven development**: Write tests first when adding gameplay systems.
|
|
For UI changes, verify with screenshots. Compare expected output to actual output
|
|
before marking work complete. Every implementation should have a way to prove it works.
|
|
|
|
# Design Document Standards
|
|
|
|
- All design docs use Markdown
|
|
- Each mechanic has a dedicated document in `design/gdd/`
|
|
- Documents must include these 8 required sections:
|
|
1. **Overview** -- one-paragraph summary
|
|
2. **Player Fantasy** -- intended feeling and experience
|
|
3. **Detailed Rules** -- unambiguous mechanics
|
|
4. **Formulas** -- all math defined with variables
|
|
5. **Edge Cases** -- unusual situations handled
|
|
6. **Dependencies** -- other systems listed
|
|
7. **Tuning Knobs** -- configurable values identified
|
|
8. **Acceptance Criteria** -- testable success conditions
|
|
- Balance values must link to their source formula or rationale
|