# Game Design Doc

> Use when writing or updating a Game Design Document — defining the core gameplay loop, mechanics, onboarding, and progression from a concept, or documenting an existing game's systems for a team. Trigger when a project has no GDD yet, or when a new mechanic needs a formal spec before implementation.

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

---


# Game Design Doc

*Adapted from https://raw.githubusercontent.com/ai-boost/awesome-prompts/main/prompts/game_designer.txt (ai-boost/awesome-prompts, GPL-3.0) — rewritten, not copied.*

## Overview
A GDD exists to close the gap between "what the game should feel like" and "what actually gets built." This skill turns a one-sentence concept — or an already-built game with no documentation — into a GDD: pillars, core loop, mechanic specs, onboarding, and a progression outline, without pulling in economy or monetization design unless the game genuinely has an economy.

## When to use
- A project has a concept but no GDD yet (e.g. 2P_Fire: "2-player co-op volcanic obby, Teamwork-Puzzles style").
- A new mechanic needs a written spec before an engineer builds it.
- An existing game needs its systems documented after the fact.

## Process: concept sentence to GDD

1. **Pillars.** Pull out three to five non-negotiable experiences the concept implies. Every later decision gets checked against these. For 2P_Fire, pillars might read: *always two players present*, *lava punishes hesitation, not precision*, *no obstacle solvable alone*.
2. **Core loop**, at three timescales — fill in all three, don't stop at the first:

   | Layer | Timescale | What to fill in |
   |---|---|---|
   | Moment-to-moment | 0-30s | action, immediate feedback, small reward |
   | Session | 5-30 min | the goal, the source of tension, the win/fail resolution |
   | Long-term | hours-weeks | what changes across sessions — unlocks, cosmetics, new stages |
3. **Mechanic specs**, one block per mechanic, every field filled, none left blank: purpose (why it exists), the player experience it delivers, input, output, success condition, failure state, edge cases (what if two triggers fire at once, or a resource is at its min/max), tuning levers, what else it touches.
4. **Onboarding flow.** The first control input teaches its own mechanic inside 30 seconds. The first attempt at anything cannot fail. Each new mechanic gets one safe, low-stakes rep before it's combined with anything else. The first session ends on a hook, not a summary screen.
5. **Progression.** State plainly what a player can do at minute 30 that they couldn't at minute 0 — a new ability, a new area, a harder stage, a cosmetic unlock. Write it down even if the honest answer is "just the next stage."
6. **Tuning values.** Treat every number (health, cooldown, timer) as a hypothesis, not a fact — mark it `[PLACEHOLDER]` until it has actually been played, and write down what "too easy" and "too hard" would look like so a playtester recognizes them on sight.

## Economy and monetization
Add an economy section only if the game genuinely runs a resource loop with sources and sinks — currency, crafting materials, energy. If it does, list every source and every sink and confirm the loop neither dead-ends (nothing to spend on) nor inflates (nothing that drains it). If the game has no economy — the default for both Toy_Obby and 2P_Fire — write "Not applicable" and move on. Do not add monetization design (spend psychology, retention pressure, purchase triggers) to either project regardless of audience; it's out of scope here, and doubly so aimed at a young Roblox player base.

## Document skeleton
```
# GDD: [Name]
## Pillars
## Core Loop (moment / session / long-term)
## Mechanics (one spec block per mechanic)
## Onboarding Flow
## Progression
## Economy — not applicable / [full section if applicable]
## Changelog
```
Version every meaningful revision in the changelog — a GDD is a living document, not a one-time deliverable.

Related: `game-level-designer` (spatial execution of the mechanics this GDD defines).