game-design-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# AlterLab GameForge -- Design Document Review Workflow

A game design document is a living contract between your ambitions and your execution capacity. A bad GDD is not poorly formatted -- it is one that lets the team build confidently in the wrong direction for weeks before anyone notices. Hollow Knight's design doc worked because Team Cherry kept it tight, falsifiable, and obsessively focused on three pillars. Most GDDs fail because they describe a game without constraining it -- anything goes, so nothing works.

This is not a checklist review. A checklist confirms sections exist. This review confirms sections are good -- internally consistent, psychologically grounded, scope-honest, and specific enough to guide implementation decisions. Disco Elysium's systems-narrative integration did not happen by accident -- it happened because the design document specified exactly how every skill check connected to every dialogue branch. That level of specificity is what this review demands.

### Purpose & Triggers

Use this workflow when:
- A designer says "review my GDD" or "give feedback on my design document"
- Before starting implementation, to catch problems while they are cheap to fix
- After significant design changes, to re-validate internal consistency
- When a playtest reveals problems and you suspect the root cause is in the design
- When team members disagree about what the game is supposed to be

Problems this solves:
- Mechanics that do not serve any design pillar (orphan features)
- Target aesthetics that contradict the actual mechanics (MDA misalignment)
- Scope estimates that ignore reality (optimism masquerading as planning)
- Design documents that describe a game but do not constrain it (anything goes = nothing works)
- Systems that interact in unintended ways (emergent conflict)
- Missing sections that will cause confusion during implementation

### Critical Rules

1. **Read the whole document before commenting.** Context matters. A mechanic that seems
   orphaned in Section 3 might be justified by the progression system in Section 7. Read
   everything first, then analyze.

2. **Severity matters.** Not all findings are equal. A missing core loop definition is
   Critical. A vague art style reference is Minor. Assign severity explicitly so the
   designer knows where to spend time.

3. **Be specific, not vague.** "The combat system could be better" is useless feedback. "The combat system describes player attacks but never specifies enemy behavior patterns, making it impossible to tune difficulty" is actionable. Name the problem, cite the section, propose the fix.

4. **Propose, do not prescribe.** Offer alternative approaches with reasoning, not mandates. The designer owns the vision. Your job is to identify problems and suggest directions -- "Disco Elysium solved this by tying skill checks to dialogue, not combat" is a reference that opens thinking. "Just copy Disco Elysium" is lazy.

5. **Reference the theory.** When flagging an issue, connect it to established design
   principles from `docs/game-design-theory.md`. "This violates Flow Theory because the
   difficulty spike at Stage 3 has no skill-building ramp" is stronger than "Stage 3 is
   too hard."

6. **Check alignment across the document.** The biggest GDD failures are not missing
   sections but contradictions between sections. A pillar that says "player freedom" and
   a level design section that describes linear corridors is a critical contradiction.

### Workflow

**Step 1: Document Intake**

Read the complete design document. Note the structure, length, and overall organization.
Identify which of the 8 required GDD sections are present:

```
REQUIRED GDD SECTIONS
-------------------------------------------------
1. Game Overview (concept, genre, platform, audience)
2. Core Mechanics (player actions, systems, interactions)
3. Game Flow / Core Loop (30-sec to full-game timescales)
4. Level / World Design (spaces, progression through space)
5. Art Direction (visual style, references, asset requirements)
6. Audio Design (music, SFX, adaptive audio approach)
7. UI / UX Design (menus, HUD, accessibility considerations)
8. Technical Requirements (engine, platforms, performance targets)

OPTIONAL BUT VALUABLE
- Narrative Design (story, characters, dialogue systems)
- Monetization Model (if applicable)
- Multiplayer Design (if applicable)
- Accessibility Plan
- Competitive Analysis
-------------------------------------------------
```

**Step 2: Pillar Alignment Review**

This is the most important dimension. If the game has defined design pillars, every
mechanic and system must trace back to at least one pillar. If no pillars are defined,
flag this as a Critical finding.

```
PILLAR ALIGNMENT MATRIX
-------------------------------------------------
Mechanic/System        | Pillar 1 | Pillar 2 | Pillar 3 | Orphan?
-------------------------------------------------
[combat system]        | Yes      | --       | Yes      | No
[crafting system]      | --       | --       | --       | YES - flag
[dialogue choices]     | Yes      | Yes      | --       | No
[inventory management] | --       | --       | --       | YES - flag
-------------------------------------------------

Orphan mechanics are red flags. They either:
a) Should be cut (they serve no pillar, so they dilute focus)
b) Reveal a missing pillar (add a pillar that justifies them)
c) Are described poorly (clarify how they connect to pillars)
```

**Step 3: MDA Consistency Review**

Check whether the described mechanics actually deliver the target aesthetics. This
requires understanding the MDA Framework as documented in `docs/game-design-theory.md`.

```
MDA CONSISTENCY CHECK
-------------------------------------------------
Target Aesthetic | Required Dynamics        | Mechanics That Deliver | Gap?
-------------------------------------------------
Discovery        | Exploration, revelation  | Fog of war, hidden areas | OK
Challenge        | Skill testing, escalation| [none described]         | GAP
-------------------------------------------------

Common MDA misalignments:
- Target "Discovery" but linear level progression (no exploration mechanics)
- Target "Challenge" but no difficulty scaling or mastery curve
- Target "Expression" but no player-facing creative tools
- Target "Fellowship" but single-player-only design
```

**Step 4: Player Psychology Review**

From AlterLab-IEU/AlterLab_GameForge, MIT.

More from AlterLab-IEU/AlterLab_GameForge