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
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.
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 |
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.
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.
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."
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).
1---2name: game-design-doc3description: 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.4---56# Game Design Doc78*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.*910## Overview11A 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.1213## When to use14- A project has a concept but no GDD yet (e.g. 2P_Fire: "2-player co-op volcanic obby, Teamwork-Puzzles style").15- A new mechanic needs a written spec before an engineer builds it.16- An existing game needs its systems documented after the fact.1718## Process: concept sentence to GDD19201. **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*.212. **Core loop**, at three timescales — fill in all three, don't stop at the first:2223 | Layer | Timescale | What to fill in |24 |---|---|---|25 | Moment-to-moment | 0-30s | action, immediate feedback, small reward |26 | Session | 5-30 min | the goal, the source of tension, the win/fail resolution |27 | Long-term | hours-weeks | what changes across sessions — unlocks, cosmetics, new stages |283. **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.294. **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.305. **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."316. **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.3233## Economy and monetization34Add 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.3536## Document skeleton37```38# GDD: [Name]39## Pillars40## Core Loop (moment / session / long-term)41## Mechanics (one spec block per mechanic)42## Onboarding Flow43## Progression44## Economy — not applicable / [full section if applicable]45## Changelog46```47Version every meaningful revision in the changelog — a GDD is a living document, not a one-time deliverable.4849Related: `game-level-designer` (spatial execution of the mechanics this GDD defines).
PresidenteOG