mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 04:51:46 +00:00
* Add /vertical-slice skill, prototype overhaul, and workflow integration - Add /vertical-slice skill for pre-production validation (Phase 4 gate) - Overhaul /prototype skill with two-mode design: concept prototype (Phase 1) vs vertical slice (Phase 4), with clearer differentiation and higher standards for VS - Update prototyper agent to own both prototype and vertical-slice workflows - Add prototype-report.md and vertical-slice-report.md output templates - Update WORKFLOW-GUIDE, quick-start, skills-reference, agent-coordination-map, and skill-flow-diagrams to fully integrate both skills into the 7-phase pipeline - Remove orphaned empty quick-prototype/ directory Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * sync v1 counts + polish Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add entity inventory flow, relax vertical-slice gate, improve UX authoring prompts - /asset-spec: new Phase 0b entity & screen inventory when no argument and no existing inventory — reads GDDs/art-bible, proposes categorized list, writes design/assets/entity-inventory.md collaboratively - /asset-spec: entity/character target falls back to inline user description when no source doc exists, rather than failing - /gate-check: vertical slice changed from blocking to CONCERNS-only when absent; built-but-broken slice still fails; adds entity inventory as gate artifact - /ux-design: convert inline approval prompts to AskUserQuestion for structured option capture at key authoring decision points - workflow-catalog.yaml: entity-inventory step added to pre-production; UX spec min_count raised to 3; vertical-slice and prototype marked required: false with updated descriptions - .gitignore: exclude marrow/ eval tooling directory Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Add missing AskUserQuestion widgets to 7 skills Audit found 11 decision points across 7 skills where structured option prompts were missing — using plain text, auto-selection, or no gate at all. Skills patched: - create-epics: per-epic approval + producer CONCERNS verdict - sprint-plan: producer CONCERNS verdict with scope/timeline options - milestone-review: AT RISK / OFF TRACK producer verdicts require acknowledgement - retrospective: existing-retro handling converted from plain text [A]/[B] - quick-design: classification confirmation + draft approve/revise/redirect - tech-debt add mode: category (6 options) + effort (S/M/L/XL) structured capture - regression-suite: no-arg mode selection instead of silent auto-detect - hotfix: severity confirmation gate before workflow begins Also added AskUserQuestion to allowed-tools headers for retrospective, quick-design, tech-debt, regression-suite, and hotfix. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Prep v1 stable: fix WORKFLOW-GUIDE counts, stale agent names, and skill model fields - WORKFLOW-GUIDE.md: correct agent count (48→49), skill count (66/68→73), add 6 missing skills to Appendix B, fix Creative category count (2→4), replace 3 non-existent agent names with correct ue-*/unity-* specialists, add missing godot-csharp/gdextension specialists to hierarchy, fix production/stories/ paths → production/epics/ - coordination-rules.md: replace "not yet used" with opt-in env var note - quick-start.md: rename duplicate "Validate the concept" label → "Prototype the mechanic" - skill-flow-diagrams.md: remove duplicate legacy UX pipeline section - All 62 skills missing model: field now have explicit model: sonnet Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: comprehensive skill audit — consistency, UX, and flow gaps Two-pass audit fixing ~35 bugs across 41 files. Pre-production flow: - Brainstorm next-steps split into Path A (design-first) and Path B (prototype-first) — eliminates "prototype after architecture" confusion - /architecture-review added to pre-production flow in brainstorm and create-architecture handoffs - gate-check traceability check corrected to requirements-traceability.md - dev-story TR registry error now points to /architecture-review (not /create-epics) - start now writes production/stage.txt on first onboarding AskUserQuestion gaps filled: - balance-check, code-review, hotfix, day-one-patch, consistency-check all gain closing widgets and/or missing allowed-tools declarations - hotfix git branch creation now requires user confirmation - sprint-plan review-mode setup moved to Phase 0 (before gates run) - team-combat gains architecture→implementation approval gate - design-review APPROVED path consolidated from 3 widgets to 1 multiSelect All 9 team-* skills: - Phase 0 review-mode resolution added (solo/lean/full now respected) - team-audio output path fixed (design/gdd/ → design/audio/) - team-level final doc compilation delegated to level-designer subagent - team-narrative localization-lead added to composition list - team-qa sprint path fixed (flat files, not directories) - team-release NO-GO override captures written justification - team-live-ops Cancel verdict now explicitly BLOCKED Other fixes: - Art bible path standardized to design/art/art-bible.md (3 wrong refs) - AD-PHASE-GATE added to lean-mode skip list in director-gates.md - design-system duplicate 5d heading fixed; skeleton decline path added; mandatory agent spawns now respect review mode - story-readiness acceptance criteria thresholds now type-aware - create-stories gains multi-ADR and no-ADR handling guidance - consistency-check creates docs/consistency-failures.md on first run - retrospective frontmatter bash injection replaced with explicit Bash call - smoke-check ls -t gains PowerShell fallback - Conventional Commits format documented in coding-standards.md - gate-check: ADR acceptance gate, QA plan check, chain-of-verification tool-action requirement all added Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: expose --review flag in argument-hints for all team-* skills All 9 team-* skills already implement Phase 0 review-mode resolution internally (full/lean/solo), but none advertised [--review full|lean|solo] in their argument-hint. Users had no way to discover the per-run override. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add SECURITY.md with coordinated disclosure policy Defines scope, reporting process (GitHub private vulnerability reporting), contributor security guidelines for hooks/skills/agents, and 90-day coordinated disclosure timeline. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add CONTRIBUTING.md with framework contribution guidelines Covers what PRs are welcome, skill/hook/agent technical requirements, the collaborative principle, testing expectations, commit format, and platform compatibility requirements. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add v1.0.0-beta → v1.0 upgrade section to UPGRADING.md Documents the 17 commits since the beta tag: new /vertical-slice gate, entity inventory flow in /map-systems, AskUserQuestion widgets across 7 skills, --review flag exposure on team-* skills, bug fixes (#21, #36, #42, #43, #45), and the new CONTRIBUTING.md and SECURITY.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
318 lines
12 KiB
Markdown
318 lines
12 KiB
Markdown
# Game Concept: [Working Title]
|
|
|
|
*Created: [Date]*
|
|
*Status: [Draft / Under Review / Approved]*
|
|
|
|
---
|
|
|
|
## Elevator Pitch
|
|
|
|
> [1-2 sentences that capture the entire game. Should be compelling enough to
|
|
> make someone want to hear more. Format: "It's a [genre] where you [core
|
|
> action] in a [setting] to [goal]."
|
|
>
|
|
> Test: Can someone who has never heard of this game understand what they'd
|
|
> be doing in 10 seconds? If not, simplify.]
|
|
|
|
---
|
|
|
|
## Core Identity
|
|
|
|
| Aspect | Detail |
|
|
| ---- | ---- |
|
|
| **Genre** | [Primary genre + subgenre(s)] |
|
|
| **Platform** | [PC / Console / Mobile / Cross-platform] |
|
|
| **Target Audience** | [See Player Profile section below] |
|
|
| **Player Count** | [Single-player / Co-op / Multiplayer / MMO] |
|
|
| **Session Length** | [Typical play session: 10 min / 30 min / 1 hr / 2+ hr] |
|
|
| **Monetization** | [Premium / F2P / Subscription / none yet] |
|
|
| **Estimated Scope** | [Small (1-3 months) / Medium (3-9 months) / Large (9+ months)] |
|
|
| **Comparable Titles** | [2-3 existing games in the same space] |
|
|
|
|
---
|
|
|
|
## Core Fantasy
|
|
|
|
[What power, experience, or feeling does the player get from this game?
|
|
What can they do here that they can't do anywhere else?
|
|
|
|
The core fantasy is the emotional promise. It's not a feature list — it's the
|
|
answer to "why would someone choose THIS game over anything else they could
|
|
be doing?"
|
|
|
|
Examples of strong core fantasies:
|
|
- "You are a lone survivor building a new life in a hostile wilderness" (survival)
|
|
- "You command a civilization across millennia" (strategy)
|
|
- "You explore a vast, beautiful world at your own pace" (open world)
|
|
- "You master intricate combat and overcome impossible odds" (soulslike)]
|
|
|
|
---
|
|
|
|
## Unique Hook
|
|
|
|
[What makes this game different from everything else in its genre? This is
|
|
the single most important differentiator.
|
|
|
|
A strong hook passes the "and also" test: "It's like [comparable game],
|
|
AND ALSO [unique thing]." If the "and also" doesn't spark curiosity, the
|
|
hook needs work.
|
|
|
|
The hook should be:
|
|
- Explainable in one sentence
|
|
- Genuinely novel (not just a combination of existing features)
|
|
- Connected to the core fantasy (not a gimmick bolted on)
|
|
- Something that affects gameplay, not just aesthetics]
|
|
|
|
---
|
|
|
|
## Player Experience Analysis (MDA Framework)
|
|
|
|
The MDA (Mechanics-Dynamics-Aesthetics) framework ensures we design from the
|
|
player's emotional experience backward to the systems that create it.
|
|
|
|
### Target Aesthetics (What the player FEELS)
|
|
Rank the following aesthetic goals for this game (1 = primary, mark N/A if not
|
|
relevant). These come from the MDA framework's 8 aesthetic categories:
|
|
|
|
| Aesthetic | Priority | How We Deliver It |
|
|
| ---- | ---- | ---- |
|
|
| **Sensation** (sensory pleasure) | [1-8 or N/A] | [Visual beauty, audio design, haptics] |
|
|
| **Fantasy** (make-believe, role-playing) | [Priority] | [World, characters, player identity] |
|
|
| **Narrative** (drama, story arc) | [Priority] | [Plot structure, player-driven stories] |
|
|
| **Challenge** (obstacle course, mastery) | [Priority] | [Difficulty curve, skill ceiling] |
|
|
| **Fellowship** (social connection) | [Priority] | [Co-op, guilds, shared experiences] |
|
|
| **Discovery** (exploration, secrets) | [Priority] | [Hidden areas, emergent systems, lore] |
|
|
| **Expression** (self-expression, creativity) | [Priority] | [Build variety, cosmetics, creation tools] |
|
|
| **Submission** (relaxation, comfort zone) | [Priority] | [Low-stress loops, ambient gameplay] |
|
|
|
|
### Key Dynamics (Emergent player behaviors)
|
|
[What behaviors do we WANT to emerge from our mechanics? What should players
|
|
naturally start doing without being told?
|
|
|
|
Example: "Players will experiment with ability combinations to find synergies"
|
|
Example: "Players will share discoveries with the community"]
|
|
|
|
### Core Mechanics (Systems we build)
|
|
[What are the 3-5 mechanical systems that generate the dynamics and aesthetics
|
|
above? These are the rules, verbs, and systems we actually implement.]
|
|
|
|
1. [Mechanic 1 — e.g., "Real-time combat with stamina management"]
|
|
2. [Mechanic 2 — e.g., "Procedurally generated dungeons with hand-crafted rooms"]
|
|
3. [Mechanic 3 — e.g., "Crafting system with discoverable recipes"]
|
|
|
|
---
|
|
|
|
## Player Motivation Profile
|
|
|
|
Understanding WHY players play helps us make every design decision. Based on
|
|
Self-Determination Theory (SDT) and the Player Experience of Need Satisfaction
|
|
(PENS) model.
|
|
|
|
### Primary Psychological Needs Served
|
|
|
|
| Need | How This Game Satisfies It | Strength |
|
|
| ---- | ---- | ---- |
|
|
| **Autonomy** (freedom, meaningful choice) | [How does the player feel in control?] | [Core / Supporting / Minimal] |
|
|
| **Competence** (mastery, skill growth) | [How does the player feel skilled?] | [Core / Supporting / Minimal] |
|
|
| **Relatedness** (connection, belonging) | [How does the player feel connected?] | [Core / Supporting / Minimal] |
|
|
|
|
### Player Type Appeal (Bartle Taxonomy)
|
|
|
|
Which player types does this game primarily serve?
|
|
|
|
- [ ] **Achievers** (goal completion, collection, progression) — How: [...]
|
|
- [ ] **Explorers** (discovery, understanding systems, finding secrets) — How: [...]
|
|
- [ ] **Socializers** (relationships, cooperation, community) — How: [...]
|
|
- [ ] **Killers/Competitors** (domination, PvP, leaderboards) — How: [...]
|
|
|
|
### Flow State Design
|
|
|
|
Flow occurs when challenge matches skill. How does this game maintain flow?
|
|
|
|
- **Onboarding curve**: [How do the first 10 minutes teach the player?]
|
|
- **Difficulty scaling**: [How does challenge grow with player skill?]
|
|
- **Feedback clarity**: [How does the player know they're improving?]
|
|
- **Recovery from failure**: [How quickly can they try again? Is failure punishing or educational?]
|
|
|
|
---
|
|
|
|
## Core Loop
|
|
|
|
### Moment-to-Moment (30 seconds)
|
|
[What is the player physically doing most of the time? The most basic, repeated
|
|
action. This MUST be intrinsically satisfying — if the 30-second loop isn't
|
|
fun in isolation, no amount of progression will save the game.]
|
|
|
|
### Short-Term (5-15 minutes)
|
|
[What objective or cycle structures the moment-to-moment play? Encounters,
|
|
puzzles, rounds, quests. This is where "one more turn" or "one more run"
|
|
psychology lives.]
|
|
|
|
### Session-Level (30-120 minutes)
|
|
[What does a full play session look like? What does the player accomplish?
|
|
This should end with a natural stopping point AND a reason to come back.]
|
|
|
|
### Long-Term Progression
|
|
[How does the player grow over days/weeks? Character progression, unlocks,
|
|
story advancement, mastery. What is the player working toward?]
|
|
|
|
### Retention Hooks
|
|
[What specifically brings the player back for their next session?]
|
|
- **Curiosity**: [Unanswered questions, unexplored areas, locked content]
|
|
- **Investment**: [Progress they don't want to lose, characters they care about]
|
|
- **Social**: [Friends playing, guild obligations, shared goals]
|
|
- **Mastery**: [Skills to improve, challenges to overcome, rankings to climb]
|
|
|
|
---
|
|
|
|
## Game Pillars
|
|
|
|
Design pillars are non-negotiable principles that guide EVERY decision. When
|
|
two design choices conflict, pillars break the tie. Keep to 3-5 pillars.
|
|
|
|
Real AAA examples:
|
|
- God of War: "Intense combat", "Father-son story", "World exploration"
|
|
- Hades: "Fast fluid combat", "Narrative depth through repeated runs"
|
|
- The Last of Us: "Story as essential", "AI partners build relationships", "Stealth encouraged"
|
|
|
|
### Pillar 1: [Name]
|
|
[One sentence defining this non-negotiable design principle.]
|
|
|
|
*Design test*: [A concrete decision this pillar would resolve. "If we're
|
|
debating between X and Y, this pillar says we choose __."]
|
|
|
|
### Pillar 2: [Name]
|
|
[Definition]
|
|
|
|
*Design test*: [Decision it resolves]
|
|
|
|
### Pillar 3: [Name]
|
|
[Definition]
|
|
|
|
*Design test*: [Decision it resolves]
|
|
|
|
### Anti-Pillars (What This Game Is NOT)
|
|
|
|
Anti-pillars are equally important — they prevent scope creep and keep the
|
|
vision focused. Every "no" protects the "yes."
|
|
|
|
- **NOT [thing]**: [Why this is explicitly excluded and what it would compromise]
|
|
- **NOT [thing]**: [Why]
|
|
- **NOT [thing]**: [Why]
|
|
|
|
---
|
|
|
|
## Inspiration and References
|
|
|
|
| Reference | What We Take From It | What We Do Differently | Why It Matters |
|
|
| ---- | ---- | ---- | ---- |
|
|
| [Game 1] | [Specific mechanic, feeling, or approach] | [Our twist] | [What it validates about our concept] |
|
|
| [Game 2] | [What we learn] | [Our twist] | [Validation] |
|
|
| [Game 3] | [What we learn] | [Our twist] | [Validation] |
|
|
|
|
**Non-game inspirations**: [Films, books, music, art, real-world experiences
|
|
that influence the tone, world, or feel. Great games often pull from outside
|
|
the medium.]
|
|
|
|
---
|
|
|
|
## Target Player Profile
|
|
|
|
[Be specific. "Gamers" is not a target audience.]
|
|
|
|
| Attribute | Detail |
|
|
| ---- | ---- |
|
|
| **Age range** | [e.g., 18-35] |
|
|
| **Gaming experience** | [Casual / Mid-core / Hardcore] |
|
|
| **Time availability** | [e.g., "30-minute sessions on weeknights, longer on weekends"] |
|
|
| **Platform preference** | [Where they play most] |
|
|
| **Current games they play** | [2-3 specific titles] |
|
|
| **What they're looking for** | [The unmet need this game fills] |
|
|
| **What would turn them away** | [Dealbreakers for this audience] |
|
|
|
|
---
|
|
|
|
## Technical Considerations
|
|
|
|
| Consideration | Assessment |
|
|
| ---- | ---- |
|
|
| **Recommended Engine** | [Godot / Unity / Unreal and why — consider scope, team expertise, platform targets] |
|
|
| **Key Technical Challenges** | [What's technically hard about this game?] |
|
|
| **Art Style** | [Pixel / 2D / 2.5D / 3D stylized / 3D realistic] |
|
|
| **Art Pipeline Complexity** | [Low (asset store + modifications) / Medium (custom 2D) / High (custom 3D)] |
|
|
| **Audio Needs** | [Minimal / Moderate / Music-heavy / Adaptive] |
|
|
| **Networking** | [None / P2P / Client-Server / Dedicated Servers] |
|
|
| **Content Volume** | [Estimate: X levels, Y items, Z hours of gameplay] |
|
|
| **Procedural Systems** | [Any procedural generation? What scope?] |
|
|
|
|
---
|
|
|
|
## Risks and Open Questions
|
|
|
|
### Design Risks
|
|
[Things that could make the game unfun or uncompelling]
|
|
- [Risk 1 — e.g., "Core loop may not sustain sessions > 30 minutes"]
|
|
- [Risk 2 — e.g., "Player motivation unclear after main story ends"]
|
|
|
|
### Technical Risks
|
|
[Things that could be hard or impossible to build]
|
|
- [Risk 1 — e.g., "Procedural generation quality is unproven"]
|
|
- [Risk 2 — e.g., "Networking for 100+ players may require dedicated infrastructure"]
|
|
|
|
### Market Risks
|
|
[Things that could prevent commercial success]
|
|
- [Risk 1 — e.g., "Genre is saturated with established competitors"]
|
|
- [Risk 2 — e.g., "Target audience may be too niche for financial sustainability"]
|
|
|
|
### Scope Risks
|
|
[Things that could blow the timeline]
|
|
- [Risk 1 — e.g., "Content volume exceeds team capacity"]
|
|
- [Risk 2 — e.g., "Feature X depends on technology we haven't prototyped"]
|
|
|
|
### Open Questions
|
|
[Things that need prototyping or research before we can answer]
|
|
- [Question 1 — and how we plan to answer it]
|
|
- [Question 2 — and what prototype would resolve it]
|
|
|
|
---
|
|
|
|
## MVP Definition
|
|
|
|
[The absolute minimum version that validates the core hypothesis. The MVP
|
|
answers ONE question: "Is the core loop fun?"]
|
|
|
|
**Core hypothesis**: [The single statement the MVP tests, e.g., "Players find
|
|
the combat-crafting loop engaging for 30+ minute sessions"]
|
|
|
|
**Required for MVP**:
|
|
1. [Essential feature 1 — directly tests the hypothesis]
|
|
2. [Essential feature 2]
|
|
3. [Essential feature 3]
|
|
|
|
**Explicitly NOT in MVP** (defer to later):
|
|
- [Feature that's nice but doesn't test the hypothesis]
|
|
- [Feature that adds scope without validating the core]
|
|
|
|
### Scope Tiers (if budget/time shrinks)
|
|
|
|
| Tier | Content | Features | Timeline |
|
|
| ---- | ---- | ---- | ---- |
|
|
| **MVP** | [Minimal] | [Core loop only] | [X weeks] |
|
|
| **Vertical Slice** | [One complete area] | [Core + progression] | [X weeks] |
|
|
| **Alpha** | [All areas, placeholder] | [All features, rough] | [X weeks] |
|
|
| **Full Vision** | [Complete content] | [All features, polished] | [X weeks] |
|
|
|
|
---
|
|
|
|
## Next Steps
|
|
|
|
- [ ] Get concept approval from creative-director
|
|
- [ ] Fill in CLAUDE.md technology stack based on engine choice (`/setup-engine`)
|
|
- [ ] Create game pillars document (`/design-review` to validate)
|
|
- [ ] **Prototype core idea** (`/prototype [core-mechanic]`) — before writing GDDs, validate the concept is worth designing
|
|
- [ ] If prototype PROCEEDS: Decompose concept into systems (`/map-systems`)
|
|
- [ ] Design each system (`/design-system [system-name]`) — use prototype learnings in Tuning Knobs and Formulas sections
|
|
- [ ] Build vertical slice in Pre-Production (`/vertical-slice`) — validate full game loop before committing to Production
|
|
- [ ] Validate core loop with playtest (`/playtest-report`)
|
|
- [ ] Plan first milestone (`/sprint-plan new`)
|