game-design-doc

Game Design Document

When to Use

When starting a new game project, aligning team members on what to build, or documenting mechanics for implementation.

Core Jobs

1. Core Concept (1 page)

• Logline: one sentence that captures the essence. "A roguelite deck-builder where your deck evolves based on how you play, not what you pick."
• Genre(s): be specific (roguelite, not "action")
• Target player: who plays this? ("people who played Hades and want more narrative depth")
• Core emotion: what feeling does the player chase? (power fantasy, tension, exploration)
• Platform and estimated scope

2. Core Loop (the fun part)

The 3 layers:

• Micro loop (seconds): what does the player do moment-to-moment?
• Macro loop (minutes): what is the session goal?
• Meta loop (hours/days): what keeps them coming back?

Write it as actions, not features: "Player fights → defeats enemy → gains resources → upgrades → faces harder enemy → (repeat)" is good. "Combat system with progression mechanics" is bad.

3. Mechanics Documentation

Per mechanic:

• Name and description
• Player interaction (what does the player do?)
• Rules (exact behavior, edge cases)
• Feel goal (what should it feel like?)
• Implementation notes (for engineers)

4. Scope Management

MoSCoW for game design:

• Must have (launch): core loop, win/lose conditions, 1 environment, tutorial
• Should have (launch): 3 environments, variety, polish
• Could have (post-launch): extra modes, community features
• Won't have (this version): anything that doesn't serve the core loop

Key Outputs

• Game concept and logline
• Core loop diagram (3 layers)
• Mechanics documentation
• MoSCoW feature list

Anti-Patterns

• GDD with no core loop — features without a framework
• Designing features before validating the core loop is fun
• Scope that exceeds team capacity by 3x
• Not playtesting before full implementation