# Game Design Doc

> Use when writing a Game Design Document (GDD), defining core mechanics, or planning player loops

- Skill: `kienbui1995/game-design-doc` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kienbui1995/game-design-doc`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kienbui1995/game-design-doc/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kienbui1995 (https://skillmd.com/u/kienbui1995)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kienbui1995/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