Game design document generator

What a game design document is, and why one page is enough

A game design document, or GDD, is the written description of a game that everyone working on it shares: what it is, how it plays, how it looks and sounds, and what it leaves out. There is no standard format. Studios have worked from a single sheet and from bibles of nearly 80 pages, and the long ones tended to go out of date before the game shipped.

For a first game, one page beats fifty. At GDC 2010 Stone Librande argued for one-page designs because most readers stop after the first page, and a long document written before anything is playable describes a game nobody has tested. One page forces the decisions that matter: a one-sentence pitch, one loop, one way to win and one way to lose, and a first build small enough to finish.

This generator fills that page for you. Each section is drawn on its own, but from lists written for one genre, so a horror document never gets a farming loop and a racing game never gets a jump button. Pin the sections you like, shuffle the rest, and copy the result as Markdown.

The sections of a one-page GDD, with examples

Every section answers a question someone building the game will ask. Here is what each one is for, filled in for a small platformer.

The copied document ends with two open questions for your first playtest and a short out-of-scope list. Most templates leave both out, yet they are the two parts you will point to most often while building.

• Pitch: one sentence with the genre, what you do, why, and the twist. Example: A platformer where you carry a lantern through a dark forest to light every shrine, but the flame burns down while you run.
• Core loop: the 30-second repeat, written as verbs joined by arrows. If the chain contains no reward, players have no reason to go round again. Example: Run and jump → grab the coins → reach the next checkpoint → repeat.
• Goal and win: when a session ends well, with a number. Example: Reach the goal at the end of each of the three levels.
• Fail state: what goes wrong and what it costs. A fast restart keeps players trying. Example: Falling into a pit sends you back to the last checkpoint.
• Controls: every action for desktop and for touch. A design that needs six buttons will not survive a phone screen. Example: A/D to move and Space to jump; on touch, arrows at the bottom left and a jump button at the bottom right.
• Art direction: the camera, the style and one readability rule. Example: Side view, pixel art on a 16-pixel grid; the hero is the brightest thing on screen.
• Audio mood: the music style and the two or three sounds that give feedback. Example: Upbeat chiptune, a rising blip for every jump and a bright chime for coins.
• First playable: the smallest build that proves the loop. Example: One level of about two minutes with run, jump, one hazard and an exit, plus win and retry screens.

Common mistakes with GDD templates

Most problems with game design documents come from treating them as paperwork rather than as a tool for decisions. These are the ones that show up most often in first games.

• Filling every heading of a 40-page template for a game you could build in a weekend. Delete every section your game does not need.
• Describing fun instead of rules. “Combat feels punchy” cannot be built; “three hits end the run” can.
• Leaving out the out list. Without one, every good idea gets in, and the first playable never arrives.
• Forgetting touch. If the game might run in a phone browser, plan the touch controls on page one, not after the first build.
• Treating the page as finished. The first playtest will change it; date each version and write down what changed and why.

Growing the page after the first playable

Once a playable build proves the core loop is fun, the document can grow to roughly 3 to 10 pages. Add what the prototype taught you: tuning numbers such as move speed and spawn rates, a content list with counts, progression, accessibility options, and where each asset comes from and under which licence.

Grow it only for what survived playtesting. Ideas nobody has played yet belong in the open questions, not in a new chapter.

From document to playable build

A game design document is a list of bets until someone plays the game. The fastest way to settle them is to build the first playable and test it.

The build button under the document sends the whole page to the Oryn composer as a prompt. Oryn asks a few planning questions, turns your answers into a fuller design document for you to approve, then builds a real Godot 4 project you can play in the browser and export. Nothing is built before you approve the plan.

For the background, read the full guide to game design documents: it has a blank template, a full template, a filled-in example and seven real GDDs from Doom to BioShock. If you still need the idea itself, start with the game idea generator; for the people in your world, try the NPC generator. The guide on how to make a video game covers what comes after the first playable.

How to use it

1. Pick a genre

   Choose a genre chip. Every section is drawn from lists written for that genre, so the parts fit together.

2. Shuffle and pin

   Shuffle until a section fits your idea, then pin it. Pinned sections stay when you shuffle the rest.

3. Copy the one-pager

   Copy the Markdown and paste it into Notion, Google Docs or a file in your repository. Change the numbers until they describe your game.

4. Build the first playable

   Send the page to Oryn, answer the planning questions and play the first version in your browser.

Questions