game-design-review

AlterLab GameForge -- Design Document Review

A game design document is a contract between ambition and execution capacity. A bad GDD is not badly formatted; it is one that lets the team build confidently in the wrong direction for weeks before anyone notices. Most fail because they describe a game without constraining it: anything goes, so nothing coheres.

This is not a checklist review. A checklist confirms sections exist. This review confirms they are good: internally consistent, psychologically grounded, scope-honest, and specific enough to drive implementation. In 2026 that last test is literal. When a GDD section goes to Claude Code or a similar agent, every vague sentence becomes a guess in code, so this review also asks: could an agent build this, and could a test tell whether it built it right? And because players, stores and regulators now care how a game was made, it checks originality, AI-content disclosure and accessibility while changes are still cheap.

When to Use / When Not To

Use before implementation starts, as a gate before a section is handed to a coding agent, after significant design changes, when a playtest went badly and the cause may be in the design, or when the team disagrees about what the game is.

Critical Rules

1. Read the whole document before commenting. A mechanic that looks orphaned in §5 may be justified in §11. Read everything, including linked pillars and the systems index, then analyze.
2. Severity is explicit. Critical, Major, Minor or Suggestion on every finding, with a reason. A missing core loop is Critical; a vague art reference is Minor.
3. Specific, cited, actionable. "Combat could be better" is useless. "§5.1 specifies player attacks but no enemy behavior, so difficulty cannot be tuned" is a finding. Name the problem, cite the section, propose a fix.
4. Propose, do not prescribe. The designer owns the vision. Offer directions with reasons; do not rewrite their sections. Route rewrites to /gameforge:game-gdd-author.
5. Ground it in theory. Tie findings to ${CLAUDE_PLUGIN_ROOT}/docs/game-design-theory.md: "this spike violates Flow because §11 has no skill-building ramp before Stage 3" beats "Stage 3 is too hard."
6. Contradictions beat omissions. The costliest GDD failures are sections that disagree, not sections that are missing.
7. Separate design quality from document quality. A brilliant design can be badly documented and a polished document can describe a weak game. Say which problem you found.
8. Compliance findings are flags, not legal advice. State the rule and its date, say what it implies for the design, and recommend professional review where real exposure exists.