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

Evaluate through the lens of Self-Determination Theory and Flow Theory.

SDT Check -- Does the design support the three basic psychological needs?

SDT ASSESSMENT
-------------------------------------------------
Need         | Evidence in Design       | Threats in Design     | Rating
-------------------------------------------------
Autonomy     | [choices described]      | [forced linearity]    | [A/B/C/F]
Competence   | [skill expression]       | [unfair difficulty]   | [A/B/C/F]
Relatedness  | [social features]        | [isolation by design] | [A/B/C/F]
-------------------------------------------------

Flow Check -- Can the player maintain a flow state?

FLOW ASSESSMENT
-------------------------------------------------
Flow Element  | Present? | Notes
-------------------------------------------------
Clear goals   | Y/N      | [does the player always know what to do next?]
Immediate feedback | Y/N | [does every action produce visible response?]
Challenge/skill balance | Y/N | [does difficulty scale with player growth?]
Sense of control | Y/N   | [does the player feel agency?]
Loss of self-consciousness | Y/N | [can they forget they are playing?]
Time distortion | Y/N    | [does the design support losing track of time?]
-------------------------------------------------

Step 5: Internal Consistency Review

Look for contradictions between different sections of the document.

CONSISTENCY CROSS-CHECK
-------------------------------------------------
Check                        | Status | Finding
-------------------------------------------------