wxm/codex-game-studios
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Align brainstorm workflow with Codex input schema

Browse Source
This commit is contained in:
wxm
2026-05-18 19:42:51 -07:00
parent 0c4227cba6
commit 445d86c300
11 changed files with 1192 additions and 349 deletions
Download Patch File Download Diff File Expand all files Collapse all files

86
references/studio-docs/director-gates.md
View File

@@ -4,9 +4,8 @@ This document defines the standard gate prompts for all director and lead review
across every workflow stage. Skills reference gate IDs from this document instead
of embedding full prompts inline — eliminating drift when prompts need updating.
**Scope**: All 7 production stages (Concept → Release), all shared director
custom agents, and all key Tier 2 leads. Any skill, team orchestrator, or
workflow may invoke these gates.
**Scope**: All 7 production stages (Concept → Release), all 3 Tier 1 directors,
all key Tier 2 leads. Any skill, team orchestrator, or workflow may invoke these gates.
---
@@ -19,31 +18,15 @@ Spawn `creative-director` via Codex custom-agent delegation using gate
**CD-PILLARS** from `references/studio-docs/director-gates.md`.
```
The matching custom agent must already be installed in the target project at
`.codex/agents/<agent-name>.toml`. The target project should also have a root
`AGENTS.md` installed from `project-template/AGENTS.md`; this is the shared
project guide used by Codex and bundled custom agents. The plugin source copies
for agents live in `runtime/agents/`; run
`python3 scripts/install_codex_runtime.py <target-project>` from the plugin root
if the target project is missing the agents or root guide. Pass the context
listed under that gate's **Context to pass** field, then handle the verdict
using the **Verdict handling** rules below.
Director names are Codex custom agent names. Do not recreate them by pasting
profile text into a generic default agent.
Pass the context listed under that gate's **Context to pass** field, then handle
the verdict using the **Verdict handling** rules below.
---
## Review Modes
Review intensity controls whether director and lead **review gates** run. It is
not a global switch for all custom-agent or subagent usage: a future team
workflow may still call specialist agents as part of its core work. Apply
review mode only to gate invocations such as `CD-PILLARS`, `TD-FEASIBILITY`,
`PR-SCOPE`, and the `*-PHASE-GATE` checks.
Review intensity can be set globally (persists across sessions) or overridden
per skill run.
Review intensity controls whether director gates run. It can be set globally
(persists across sessions) or overridden per skill run.
**Global config**: `production/review-mode.txt` — one word: `full`, `lean`, or `solo`.
Set once during `/start`. Edit the file directly to change it at any time.
@@ -55,14 +38,14 @@ Examples:
```
/brainstorm space horror → uses global mode
/brainstorm space horror --review full → forces full mode this run
/architecture-decision --review solo → skips review gates this run
/architecture-decision --review solo → skips all gates this run
```
| Mode | What runs | Best for |
|------|-----------|----------|
| `full` | All key director / lead review gates call their custom agents | Teams, learning users, or when you want thorough director feedback at every step |
| `lean` | Only PHASE-GATE review gates such as `/gate-check` call directors; ordinary per-skill review gates are skipped | **Default** — solo devs and small teams; directors review at milestones only |
| `solo` | All director review gates are skipped | Game jams, prototypes, maximum speed |
| `full` | All gates active — every workflow step reviewed | Teams, learning users, or when you want thorough director feedback at every step |
| `lean` | PHASE-GATEs only (`/gate-check`) — per-skill gates skipped | **Default** — solo devs and small teams; directors review at milestones only |
| `solo` | No director gates anywhere | Game jams, prototypes, maximum speed |
**Check pattern — apply before every gate spawn:**
@@ -73,9 +56,8 @@ Before spawning gate [GATE-ID]:
3. Else default to lean
Apply the resolved mode:
- solo → skip all director / lead review gates. Note: "[GATE-ID] skipped — Solo mode"
- lean → skip ordinary per-skill review gates; only run PHASE-GATE checks
(CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
- solo → skip all gates. Note: "[GATE-ID] skipped — Solo mode"
- lean → skip unless this is a PHASE-GATE (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
Note: "[GATE-ID] skipped — Lean mode"
- full → spawn as normal
```
@@ -90,20 +72,15 @@ Apply the resolved mode:
3. Else default to `lean`
Apply the resolved mode:
- `full` → **spawn all key director / lead review gates** as described by the skill.
- `lean` → **spawn only PHASE-GATE review gates** such as `/gate-check`
(CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE). Skip ordinary
per-skill review gates and note: `[GATE-ID] skipped — Lean mode`
- `solo` → **skip all director review gates**. Note in output:
`[GATE-ID] skipped — Solo mode`
- `solo` → **skip all gates**. Note in output: `[GATE-ID] skipped — Solo mode`
- `lean` → **skip unless this is a PHASE-GATE** (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE). Note: `[GATE-ID] skipped — Lean mode`
- `full` → spawn as normal
```
# Apply mode check, then:
Spawn `[agent-name]` via Codex custom-agent delegation:
- Gate: [GATE-ID] (see references/studio-docs/director-gates.md)
- Custom agent file: .codex/agents/[agent-name].toml in the target project
- Context: [fields listed under that gate]
- Codex fork_context: false unless full thread context is required
- Await the verdict before proceeding.
```
@@ -111,9 +88,8 @@ For parallel spawning (multiple directors at the same gate point):
```
# Apply mode check for each gate first, then spawn all that survive:
Spawn all [N] custom agents simultaneously via Codex subagent delegation. Issue
all subagent requests before waiting for any result. Collect all verdicts before
proceeding.
Spawn all [N] agents simultaneously via Codex custom-agent delegation — issue all custom-agent requests before
waiting for any result. Collect all verdicts before proceeding.
```
---
@@ -125,7 +101,7 @@ All gates return one of three verdicts. Skills must handle all three:
| Verdict | Meaning | Default action |
|---------|---------|----------------|
| **APPROVE / READY** | No issues. Proceed. | Continue the workflow |
| **CONCERNS [list]** | Issues present but not blocking. | Surface to user via a structured prompt when available, or ask directly in chat: `Revise flagged items` / `Accept and proceed` / `Discuss further` |
| **CONCERNS [list]** | Issues present but not blocking. | Surface to user via Codex `request_user_input` — options: `Revise flagged` / `Accept` / `Discuss` |
| **REJECT / NOT READY [blockers]** | Blocking issues. Do not proceed. | Surface blockers to user. Do not write files or advance stage until resolved. |
**Escalation rule**: When multiple directors are spawned in parallel, apply the
@@ -160,15 +136,8 @@ or any time pillars are revised)
**Context to pass**:
- Full pillar set with names, definitions, and design tests
- Anti-pillars list
- Pillar conflict priority
- Core fantasy statement
- Unique hook ("Like X, AND ALSO Y")
- Required output document path for `/brainstorm`: `design/gdd/game-pillars.md`
- Template to use when the document is created or updated:
`references/studio-docs/templates/game-pillars.md`
- Existing `design/gdd/game-pillars.md` contents, if the file already exists
- Orchestrator assessment: missing / present and current / present but stale /
present but incomplete
**Prompt**:
> "Review these game pillars. Are they falsifiable — could a real design decision
@@ -176,18 +145,7 @@ or any time pillars are revised)
> they differentiate this game from its closest comparables? Would they help resolve
> a design disagreement in practice, or are they too vague to be useful? Return
> specific feedback for each pillar and an overall verdict: APPROVE (strong), CONCERNS
> [list] (needs sharpening), or REJECT (weak — pillars do not carry weight).
> When this gate is invoked from `/brainstorm` after the user has locked pillars,
> ensure `design/gdd/game-pillars.md` exists as the brainstorm-stage pillar
> source of truth. If it already exists and matches the locked pillars, review it
> in place and avoid rewriting for churn. If it is missing, stale, or incomplete,
> create or update it with `references/studio-docs/templates/game-pillars.md` as
> the structure. The initial brainstorm version must capture core fantasy, unique
> hook, target MDA aesthetics, 3-5 pillars, design tests, anti-pillars, conflict
> priority, and validation status; deeper cross-department implications can be
> marked TBD for later refinement. Begin the response with the required verdict
> token, then state whether the pillar document is current, created, updated, or
> blocked."
> [list] (needs sharpening), or REJECT (weak — pillars do not carry weight)."
**Verdicts**: APPROVE / CONCERNS / REJECT
@@ -661,9 +619,7 @@ Agent: `art-director` | Target custom agent file: `.codex/agents/art-director.to
## Tier 2 — Lead Gates
These gates are invoked by orchestration skills and senior skills when a domain
specialist's feasibility sign-off is needed. If a Tier 2 lead custom agent is
added later, invoke it with the same Codex custom-agent delegation pattern used
for Tier 1 agents.
specialist's feasibility sign-off is needed. Tier 2 leads use Sonnet (default).
---
@@ -810,7 +766,7 @@ When a workflow requires multiple directors at the same checkpoint (most common
at `/gate-check`), spawn all agents simultaneously:
```
Spawn in parallel (issue all subagent requests before waiting for any result):
Spawn in parallel (issue all custom-agent requests before waiting for any result):
1. creative-director → gate CD-PHASE-GATE
2. technical-director → gate TD-PHASE-GATE
3. producer → gate PR-PHASE-GATE

338
references/studio-docs/templates/game-pillars.md
View File

@@ -1,247 +1,313 @@
# Game Pillars: [Game Title]
## Document Status
- **Version**: 1.0
- **Last Updated**: [Date]
- **Owner**: creative-director
- **Status**: Draft / Under Review / Approved
> **Creative Director Review (CD-PILLARS)**: [APPROVED date / CONCERNS accepted date / REVISED date]
- **Approved By**: creative-director
- **Status**: [Draft / Under Review / Approved]
---
## Purpose
## What Are Game Pillars?
This document is the source of truth for the game's creative pillars. It is
created during `/brainstorm` once the user locks the pillars. The first version
can be lightweight; later workflows may deepen the cross-department implications
and validation details as the project matures.
Pillars are the 3-5 non-negotiable principles that define this game's identity.
Every design, art, audio, narrative, and technical decision must serve at least
one pillar. If a feature doesn't serve a pillar, it doesn't belong in the game.
Pillars are the 3-5 non-negotiable principles that define the game's identity.
Every design, art, audio, narrative, production, and technical decision should
serve at least one pillar. If a feature does not serve a pillar, it probably
does not belong in the game.
**Why pillars matter**: In a typical development cycle, the team makes thousands
of small creative decisions. Pillars ensure all those decisions push in the same
direction, creating a coherent player experience rather than a collection of
disconnected features.
### What Makes a Good Pillar
A good pillar is:
- **Falsifiable**: "Fun gameplay" is not a pillar. "Combat rewards patience over
aggression" is — it makes a testable claim about design choices.
- **Constraining**: If a pillar never forces you to say no to something, it's
too vague. Good pillars eliminate options.
- **Cross-departmental**: A pillar that only constrains game design but says
nothing about art, audio, or narrative is incomplete. Real pillars shape
every discipline.
- **Memorable**: The team should be able to recite the pillars from memory.
If they can't, the pillars are too numerous or too complex.
### Real AAA Examples
These studios publicly shared their game pillars, showing how concrete and
specific effective pillars can be:
| Game | Pillars | Why They Work |
| ---- | ---- | ---- |
| **God of War (2018)** | Visceral combat; Father-son emotional journey; Continuous camera (no cuts); Norse mythology reimagined | "Continuous camera" is radical — it cut a standard cinematic tool. "Father-son journey" constrains narrative, level design, AND combat (Atreus as companion). |
| **Hades** | Fast fluid combat; Story depth through repetition; Every run teaches something new | "Story through repetition" justified the roguelike structure narratively — death IS the story. "Every run teaches" constrains level and encounter design. |
| **The Last of Us** | Story is essential, not optional; AI partners build relationships; Stealth is always an option | "AI partners build relationships" drove massive investment in companion AI — not just pathfinding, but emotional presence. |
| **Celeste** | Tough but fair; Accessibility without compromise; Story and mechanics are the same thing | "Story and mechanics are the same thing" — climbing IS the struggle, the dash IS the anxiety. Pillar prevented mechanics from being "just gameplay." |
| **Hollow Knight** | Atmosphere over explanation; Earned mastery; World tells its own story | "Atmosphere over explanation" — no tutorials, no hand-holding, the world teaches through environmental design. |
| **Dead Cells** | Every weapon is viable; Combat is a dance; Permanent death creates meaning | "Every weapon is viable" is extremely constraining — it demands constant balance work across hundreds of items. |
---
## Core Fantasy
[What power, experience, or feeling does the player get from this game? This is
the emotional promise, not a feature list.]
---
## Unique Hook
[Like X, and also Y. The hook should make the game distinguishable from its
closest comparables in one sentence.]
> [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 — the answer to "why would someone choose THIS game?"
>
> Strong core fantasies are visceral and immediate:
> - "You are a lone survivor building a new life in a hostile wilderness"
> - "You command a civilization across millennia"
> - "You explore a vast, beautiful world at your own pace"
> - "You master intricate combat and overcome impossible odds"]
---
## Target MDA Aesthetics
Rank the aesthetics this game is intentionally trying to deliver.
[Rank the aesthetic goals this game serves, from the MDA Framework. This ranking
guides every pillar — your pillars should collectively deliver your top 2-3
aesthetics.]
| Rank | Aesthetic | How This Game Delivers It |
| Rank | Aesthetic | How Our Game Delivers It |
| ---- | ---- | ---- |
| 1 | [Challenge / Discovery / Fantasy / etc.] | [Specific delivery mechanism] |
| 2 | [Aesthetic] | [Specific delivery mechanism] |
| 3 | [Aesthetic] | [Specific delivery mechanism] |
| Not targeted | [Aesthetic] | [Why this is not a priority] |
| 1 | [e.g., Challenge] | [Specific delivery mechanism] |
| 2 | [e.g., Discovery] | [Specific delivery mechanism] |
| 3 | [e.g., Fantasy] | [Specific delivery mechanism] |
| 4 | [e.g., Narrative] | [Specific delivery mechanism] |
| N/A | [Aesthetics not targeted] | [Why this isn't a priority] |
Reference aesthetics: Sensation, Fantasy, Narrative, Challenge, Fellowship,
Discovery, Expression, Submission.
**Aesthetics reference** (Hunicke, LeBlanc, Zubek):
- **Sensation**: Sensory pleasure (visual beauty, satisfying audio, haptic feedback)
- **Fantasy**: Make-believe, inhabiting a role or world
- **Narrative**: Drama, story arcs, emotional plot progression
- **Challenge**: Obstacle course, skill mastery, overcoming difficulty
- **Fellowship**: Social connection, cooperation, shared experience
- **Discovery**: Exploration, uncovering secrets, understanding hidden systems
- **Expression**: Self-expression, creativity, personal identity
- **Submission**: Relaxation, comfort, meditative play
---
## Pillar Summary
## The Pillars
| Pillar | One-Sentence Definition | Primary Design Test |
| ---- | ---- | ---- |
| [Pillar 1] | [Falsifiable definition] | [If debating X vs Y, choose __] |
| [Pillar 2] | [Falsifiable definition] | [If debating X vs Y, choose __] |
| [Pillar 3] | [Falsifiable definition] | [If debating X vs Y, choose __] |
---
## Pillar 1: [Name]
### Pillar 1: [Name]
**One-Sentence Definition**: [A clear, falsifiable statement of what this pillar
means.]
means. Must be specific enough that two people would reach the same conclusion
when applying it to a design question.]
**Target Aesthetics Served**: [Which MDA aesthetics this pillar supports.]
**Target Aesthetics Served**: [Which MDA aesthetics from the ranking above does
this pillar primarily deliver?]
**Design Test**: [A concrete decision this pillar resolves.]
**Design Test**: [A concrete decision this pillar resolves. "If we're debating
between X and Y, this pillar says we choose __."]
### Cross-Department Implications
#### What This Means for Each Department
| Department | This Pillar Says | Example |
| Department | This Pillar Says... | Example |
| ---- | ---- | ---- |
| Design | [How it constrains mechanics and rules] | [Concrete example] |
| Art | [How it constrains visuals] | [Concrete example] |
| Audio | [How it constrains sound/music] | [Concrete example] |
| Narrative | [How it constrains story/writing] | [Concrete example] |
| Engineering | [Technical priorities or constraints] | [Concrete example] |
| Production | [Scope and scheduling implications] | [Concrete example] |
| **Game Design** | [How this constrains and inspires mechanics] | [Concrete example] |
| **Art** | [How this constrains and inspires visuals] | [Concrete example] |
| **Audio** | [How this constrains and inspires sound/music] | [Concrete example] |
| **Narrative** | [How this constrains and inspires story/writing] | [Concrete example] |
| **Engineering** | [Technical implications and priorities] | [Concrete example] |
### Serving This Pillar
- [Concrete feature or decision that embodies this pillar]
#### Serving This Pillar
- [Concrete example of a feature/decision that embodies this pillar]
- [Another example]
### Violating This Pillar
- [Plausible feature or decision that would betray the pillar]
#### Violating This Pillar
- [Concrete example of what would betray this pillar — things we must never do]
- [Another example]
---
## Pillar 2: [Name]
### Pillar 2: [Name]
**One-Sentence Definition**: [A clear, falsifiable statement.]
**One-Sentence Definition**: [Specific, falsifiable statement]
**Target Aesthetics Served**: [MDA aesthetics.]
**Target Aesthetics Served**: [MDA aesthetics]
**Design Test**: [A concrete decision this pillar resolves.]
**Design Test**: [Concrete decision it resolves]
### Cross-Department Implications
#### What This Means for Each Department
| Department | This Pillar Says | Example |
| Department | This Pillar Says... | Example |
| ---- | ---- | ---- |
| Design | [Constraint or inspiration] | [Example] |
| Art | [Constraint or inspiration] | [Example] |
| Audio | [Constraint or inspiration] | [Example] |
| Narrative | [Constraint or inspiration] | [Example] |
| Engineering | [Constraint or inspiration] | [Example] |
| Production | [Constraint or inspiration] | [Example] |
### Serving This Pillar
| **Game Design** | [Constraint/inspiration] | [Example] |
| **Art** | [Constraint/inspiration] | [Example] |
| **Audio** | [Constraint/inspiration] | [Example] |
| **Narrative** | [Constraint/inspiration] | [Example] |
| **Engineering** | [Constraint/inspiration] | [Example] |
#### Serving This Pillar
- [Example]
- [Example]
### Violating This Pillar
#### Violating This Pillar
- [Example]
- [Example]
---
## Pillar 3: [Name]
### Pillar 3: [Name]
**One-Sentence Definition**: [A clear, falsifiable statement.]
**One-Sentence Definition**: [Specific, falsifiable statement]
**Target Aesthetics Served**: [MDA aesthetics.]
**Target Aesthetics Served**: [MDA aesthetics]
**Design Test**: [A concrete decision this pillar resolves.]
**Design Test**: [Concrete decision it resolves]
### Cross-Department Implications
#### What This Means for Each Department
| Department | This Pillar Says | Example |
| Department | This Pillar Says... | Example |
| ---- | ---- | ---- |
| Design | [Constraint or inspiration] | [Example] |
| Art | [Constraint or inspiration] | [Example] |
| Audio | [Constraint or inspiration] | [Example] |
| Narrative | [Constraint or inspiration] | [Example] |
| Engineering | [Constraint or inspiration] | [Example] |
| Production | [Constraint or inspiration] | [Example] |
### Serving This Pillar
| **Game Design** | [Constraint/inspiration] | [Example] |
| **Art** | [Constraint/inspiration] | [Example] |
| **Audio** | [Constraint/inspiration] | [Example] |
| **Narrative** | [Constraint/inspiration] | [Example] |
| **Engineering** | [Constraint/inspiration] | [Example] |
#### Serving This Pillar
- [Example]
- [Example]
### Violating This Pillar
#### Violating This Pillar
- [Example]
- [Example]
---
## Optional Additional Pillars
### Pillar 4: [Name] (Optional)
Use this section only if the game needs a fourth or fifth pillar. Keep the total
pillar count between 3 and 5.
[Same structure as Pillars 1-3]
### Pillar 5: [Name] (Optional)
[Same structure as Pillars 1-3]
---
## Anti-Pillars
## Anti-Pillars (What This Game Is NOT)
Anti-pillars define what this game is not. Good anti-pillars block tempting
ideas that would dilute the core fantasy.
Anti-pillars are equally important as pillars — they prevent scope creep and
keep the vision focused. Every "no" protects the "yes."
- **NOT [thing]**: [Why this is excluded, what pillar it would compromise, and
what it would cost.]
- **NOT [thing]**: [Why excluded.]
- **NOT [thing]**: [Why excluded.]
Great anti-pillars are things the team might actually want to do. "NOT a racing
game" is obvious and useless. "NOT an open-world game" is useful if the genre
could plausibly support it.
- **NOT [thing]**: [Why this is explicitly excluded, what pillar it would
compromise, and what it would cost in development focus]
- **NOT [thing]**: [Why excluded]
- **NOT [thing]**: [Why excluded]
---
## Pillar Conflict Priority
## Pillar Conflict Resolution
When two pillars conflict, resolve the conflict in this order.
When two pillars conflict (and they will), use this priority order. The ranking
reflects which aspects of the experience are most essential to the core fantasy.
| Priority | Pillar | Why It Wins |
| Priority | Pillar | Rationale |
| ---- | ---- | ---- |
| 1 | [Highest priority pillar] | [Rationale] |
| 2 | [Second priority pillar] | [Rationale] |
| 3 | [Third priority pillar] | [Rationale] |
| 1 | [Highest priority pillar] | [Why this wins when it conflicts with others] |
| 2 | [Second priority] | [Why] |
| 3 | [Third priority] | [Why] |
**Resolution process**:
1. Identify which pillars are in tension.
2. Check the priority table.
3. Preserve the lower-priority pillar only where it does not weaken the higher-priority one.
4. If the conflict is fundamental, escalate to `creative-director` for pillar revision.
**Resolution Process**:
1. Identify which pillars are in tension
2. Consult the priority ranking above
3. If the lower-priority pillar can be served partially without compromising the
higher-priority one, do so
4. If not, the higher-priority pillar wins
5. Document the decision and rationale in the relevant design document
6. If the conflict is fundamental (two pillars are irreconcilable), escalate to
the creative-director to consider revising the pillars themselves
---
## Player Motivation Alignment
Use Self-Determination Theory as a sanity check.
[Verify that the pillars collectively serve the target player's psychological needs.
Based on Self-Determination Theory (Deci & Ryan) and the Player Experience of
Need Satisfaction model.]
| Need | Which Pillar Serves It | How |
| ---- | ---- | ---- |
| Autonomy | [Pillar name] | [Meaningful choices or agency] |
| Competence | [Pillar name] | [Mastery, feedback, skill growth] |
| Relatedness | [Pillar name] | [Connection, belonging, emotional bond] |
| **Autonomy** (meaningful choice, player agency) | [Pillar name] | [How this pillar creates autonomy] |
| **Competence** (mastery, skill growth, clear feedback) | [Pillar name] | [How this pillar creates competence] |
| **Relatedness** (connection, belonging, emotional bond) | [Pillar name] | [How this pillar creates relatedness] |
**Gap check**: If any of the three needs is not served by at least one pillar,
consider whether the pillar set is complete. A game that satisfies all three
SDT needs has the strongest foundation for sustained engagement.
---
## Reference Games and Inspirations
## Emotional Arc
[Map the intended emotional journey of a play session. This should be a
deliberate design, not an accident.]
### Session Emotional Arc
| Phase | Duration | Target Emotion | Pillar(s) Driving It | Mechanics Delivering It |
| ---- | ---- | ---- | ---- | ---- |
| Opening | [e.g., 0-5 min] | [e.g., Curiosity, anticipation] | [Which pillar] | [What the player does] |
| Rising | [e.g., 5-20 min] | [e.g., Tension, focus, flow] | [Which pillar] | [What the player does] |
| Climax | [e.g., 20-30 min] | [e.g., Triumph, relief, awe] | [Which pillar] | [What the player does] |
| Resolution | [e.g., 30-40 min] | [e.g., Satisfaction, reflection] | [Which pillar] | [What the player does] |
| Hook | [End of session] | [e.g., Curiosity, unfinished business] | [Which pillar] | [What makes them return] |
### Long-Term Emotional Progression
[How does the emotional experience evolve across the full game? Early game vs
mid game vs late game vs endgame should each feel distinct.]
---
## Reference Games
| Reference | What We Take From It | What We Do Differently | Which Pillar It Validates |
| ---- | ---- | ---- | ---- |
| [Game 1] | [Specific mechanic, feeling, or approach] | [Our twist] | [Pillar] |
| [Game 2] | [Specific learning] | [Our twist] | [Pillar] |
| [Game 3] | [Specific learning] | [Our twist] | [Pillar] |
| [Game 1] | [Specific mechanic, feeling, or approach] | [Our twist] | [Pillar name] |
| [Game 2] | [What we learn] | [Our twist] | [Pillar name] |
| [Game 3] | [What we learn] | [Our twist] | [Pillar name] |
**Non-game inspirations**: [Films, books, music, art, real-world experiences.]
**Non-game inspirations**: [Films, books, music, art, real-world experiences
that inform the tone, world, or feel. Great games pull from outside the medium.]
---
## Validation Checklist
## Pillar Validation Checklist
- [ ] 3-5 pillars total
- [ ] Each pillar is falsifiable
- [ ] Each pillar constrains real design choices
- [ ] Each pillar has a design test
- [ ] Each pillar has cross-department implications
- [ ] At least 3 anti-pillars are defined
- [ ] Pillar conflict priority is explicit
- [ ] Top MDA aesthetics are covered
- [ ] Autonomy, competence, and relatedness have been considered
- [ ] Every pillar traces back to the core fantasy
Before finalizing the pillars, verify:
- [ ] **Count**: 3-5 pillars (no more, no fewer)
- [ ] **Falsifiable**: Each pillar makes a claim that could be wrong
- [ ] **Constraining**: Each pillar forces saying "no" to some plausible ideas
- [ ] **Cross-departmental**: Each pillar has implications for design, art, audio, narrative, AND engineering
- [ ] **Design-tested**: Each pillar has a concrete design test that resolves a real decision
- [ ] **Anti-pillars defined**: At least 3 explicit "this game is NOT" statements
- [ ] **Priority-ranked**: Clear order for resolving conflicts between pillars
- [ ] **MDA-aligned**: Pillars collectively deliver the top-ranked target aesthetics
- [ ] **SDT coverage**: At least one pillar serves Autonomy, one Competence, one Relatedness
- [ ] **Memorable**: The team can recite all pillars from memory
- [ ] **Core fantasy served**: Every pillar traces back to the core fantasy promise
---
## Next Steps
- [ ] Keep this document linked from `design/gdd/game-concept.md`
- [ ] Use these pillars when writing system GDDs
- [ ] Revisit after major prototype learnings or milestone pivots
- [ ] Get pillar approval from creative-director
- [ ] Distribute to all department leads for sign-off
- [ ] Create design tests for each pillar using real upcoming decisions
- [ ] Schedule first pillar review (after 2 weeks of development)
- [ ] Add pillars to the game-concept document and pitch document
---
This document lives at `design/gdd/game-pillars.md`.
*This document is the creative north star. It lives in `design/gdd/game-pillars.md`
and is referenced by every design, art, audio, and narrative document in the project.
Review quarterly or after major milestone pivots.*