Game Design Document: Free GDD Template and Real Examples

A game design document (GDD) is the shared, written description of your game: what it is, how it plays, how it looks and sounds, and what you're not making. For a small game, write one page before you build anything, then let the document grow only as a playable prototype proves your ideas.

Below you'll find a one-page GDD template to copy, a full template that grows out of it, and a filled-in example. Then come seven real design documents, from Doom to BioShock, and what changed before each game shipped.

What is a game design document?

A game design document is the shared reference for what a game is and how it plays. Wikipedia describes it as a living document: the team keeps changing it as the game changes, sometimes daily, and there is no industry-standard form. It can hold text, images, diagrams, concept art and even prototypes. When a publisher funds a game, the GDD may be attached to the development contract.

For a hobby or indie game the readers are closer to home. There's you in three weeks, when you've forgotten why the double jump was cut, and anyone who joins later. Codecks lists the jobs a GDD still does: it helps you think, guides a team, onboards new people, and backs publisher contracts and grant applications.

GDD vs one-pager, pitch deck, TDD and game bible

These names get mixed up all the time. Here is what each one is for.

The one-page format comes from Stone Librande's GDC 2010 talk, and the short macro design from Mark Cerny, both covered in the next section. Double Coconut points out that a high-level GDD isn't the whole paperwork: a TDD, a creative design document, a schedule and a budget sit beside it. And GitBook notes that "game bible" is used loosely, sometimes for a narrative bible and sometimes for an umbrella document that holds the GDD plus art and brand guides.

Why modern GDDs are short

The famous design documents of the 1990s were long. The Doom Bible runs to 79 pages in a fan-uploaded copy, LucasArts' Grim Fandango puzzle document to 72, and the Planescape: Torment vision statement to 47. The advice since then has moved firmly the other way.

In 2002 Mark Cerny presented his "Method" (the slides survive as a secondary copy on SlideShare). He listed the 100-page design document as a myth. In his view it wastes resources, misleads, and sets direction before anyone has checked the fundamentals. His macro design for pre-production was about five pages, and pre-production ended with a first playable of publishable quality.

In 2010 Librande, then at EA's Maxis, argued for one page. His reasoning was simple: most people stop reading after the first page or screen. He showed one-page designs from Diablo III, The Simpsons and Spore. Game Developer revisited the talk in July 2026 and found it still useful against long design bibles and scattered wikis.

Current advice says the same thing more bluntly. Codecks calls the single big upfront GDD outdated: it goes out of sync almost immediately, gives a false sense of confidence and is too long to read. Its summary is "your game is your GDD". The studio Trick stopped updating its GDD once production started and moved new ideas to a prioritised task board.

So yes, you still need one. You need it short, and you need it to change.

What goes in a game design document

Every guide has its own list, but they agree on a core. GitBook's six steps run from vision through core loop, systems, content, UX and UI to production, and Double Coconut's template has ten sections that overlap with most of them. Here is the core, what each section is for, and how it reads in our example game, Lantern Run, a small 2D platformer.

Two tips from other guides are worth stealing. Game Gen suggests describing the player's first 10 minutes from their point of view, which catches a confusing start early. Trick's GDD lists the skills a player needs, which flags inputs that don't suit your platform or audience. And skip what your game doesn't need: a Tetris-style puzzle game has no story section.

What most templates leave out

• Tuning numbers. A table of "knobs" with a start value and a range to test: move speed, jump height, spawn rate. Game feel lives in those numbers, and keeping them in one place makes them easy to change.
• Controls per device, including touch. Most templates have a controls heading and no touch column. If your game might run in a phone browser, plan touch controls and screen orientation on page one, not after the first build.
• Open questions and a first-playable definition. What the prototype must answer, and the checklist that says it's done. It's Cerny's first playable turned into a section.
• Non-goals. GitBook is one of the few guides that asks for them. The out list is the one you'll point to when a shiny new idea shows up mid-build.
• A change log. GitBook recommends a light changelog so the same debate doesn't happen twice. Add a column that says what playtesting showed.
• Accessibility. Wikipedia's topic list and GitBook's UX step include it; most templates skip it. Remappable controls, subtitles, a colour-blind-safe palette and reduced motion are far easier to plan than to retrofit.
• An asset list with sources and licences. Double Coconut's template has an asset list. Add where each asset comes from and under which licence, so shipping doesn't turn into an audit.

How long should a game design document be?

One page before your first prototype. Roughly 3 to 10 pages once the core loop is proven. More only for content lists, like levels and items, or when a team or publisher needs it.

That rule is ours, and every number in it comes from a source. Tim Ryan's classic 1999 article on the anatomy of a design document starts with a game concept of one or two pages. Cerny's macro design was about five. Game Dev Beginner recommends writing in stages: one page, then about ten, then the full GDD. Trick's guide keeps the project description to a page at most.

3D games run a little longer, because the camera needs rules and there's more content to list and cut. If that's you, read up on scoping a 3D game before you write the content section.

How to write a game design document in 7 steps

Here's the whole process, using Lantern Run as the example.

1. Write the pitch in one sentence

   Use the formula: [genre] where you [main action] to [goal], but [twist]. For example: a 2D platformer where you carry a lantern through a dark forest to light every shrine before the flame burns out. If you can't fill it in, you have a theme, not a game yet.

2. Pick three design pillars

   Pillars settle later arguments, so each one should rule something out. "Readable danger" rules out hazards that kill you off-screen. A horror game would pick very different pillars, built around dread and what the player can't see.

3. Write the core loop as verbs

   Describe the 30-second repeat as a chain of actions, ending in "repeat". If the chain has no reward or choice in it, players have no reason to go round again.

4. Pin down controls and rules with numbers

   List every action for every device you target, including touch. Then put a number on each rule: the flame drains in 45 seconds, a shrine refills it, raising the lantern doubles the drain. It helps to decide mobile or desktop before you build, because it changes the controls and the screen shape.

5. Cut the scope in writing

   Write what's in, with counts, and what's out. GitBook calls the content list the place where scope creep starts, so be strict: Lantern Run's out list is longer than its in list.

6. List your open questions

   Write the two or three things you can only find out by playing. These questions are the prototype's job description.

7. Build the first playable, then update the page

   Build the smallest version that answers the open questions, play it, and write down what changed and why, with a date. Our guide to building your first playable covers that step, and how to make a video game covers everything after it.

Free game design document template

Both templates are plain Markdown and free to copy and change. They share their headings: the one-page GDD is sections 1 to 10 of the full GDD, so you can grow one into the other without restructuring anything.

• Download the one-page GDD template (.md)
• Download the full GDD template (.md)

Markdown is plain text, so it opens in any editor and pastes into Google Docs, Word or Notion. Kept in a Git repo next to your project, every change gets a history.

One-page GDD template

Copy this and fill in the brackets. Delete any line that doesn't apply.

# [Game Title]: One-Page GDD

*Version 0.1 · [Date] · [Your name]*

## 1. Pitch
[Genre] where you [main action] to [goal], but [twist].

## 2. Design pillars
1. [A feeling or rule that wins every argument]
2. [...]
3. [...]

## 3. Player fantasy
The player gets to feel like [...].

## 4. Player and platform
- For: [who, for example "fans of X and Y"]
- Plays on: [desktop / phone / web / console], [landscape / portrait]
- Session: about [X] minutes

## 5. Core loop (30 seconds)
[Action] → [Reward] → [Choice or upgrade] → repeat

## 6. Controls
| Action | Keyboard | Gamepad | Touch |
|---|---|---|---|
| Move | | | |
| [Main verb] | | | |

## 7. Win and lose
- Win: [...]
- Lose: [...]

## 8. Look and sound
- Art: [2D or 3D, palette, 2 or 3 reference games or images]
- Audio: [music mood, key sound effects]

## 9. Scope
- In: [N] levels, [N] enemies, [N] items
- Out (not in v1): [multiplayer, story cutscenes, ...]

## 10. Open questions and first playable
The prototype must answer:
- [ ] Is [main mechanic] fun for 5 minutes?
- [ ] [...]

First playable is done when:
- [ ] One level can be played start to finish
- [ ] Win and lose both work
- [ ] [...]

The full GDD template

The full template has 24 sections in five parts, plus a change log:

• Part 1, Vision (sections 1 to 10): the one-pager, with room for an elevator paragraph, pillars with what each rules out, and the loop at three scales (seconds, minutes, days).
• Part 2, Gameplay detail: mechanics with edge cases, a game feel and tuning table, progression and difficulty, economy, enemies.
• Part 3, Content and world: levels, story and characters (skip for arcade and puzzle games), and an asset list with source and licence columns.
• Part 4, Presentation: art and audio direction, UI and screen flow with a phone layout line, accessibility.
• Part 5, Production: engine and version, build targets, milestones and risks. If you haven't picked an engine yet, Godot vs Unity helps you choose.

Fill in Part 1 now. Add the rest only after a prototype proves the core loop.

Game design document example: Lantern Run

Here is the one-pager filled in for a small fictional game. It's deliberately specific, with numbers, counts and an out list.

# Lantern Run: One-Page GDD

*Version 0.1 · 2026-11-01*

## 1. Pitch
A 2D platformer where you carry a lantern through a dark forest
to light every shrine before the flame burns out.

## 2. Design pillars
1. Light is time: every second costs flame.
2. Readable danger: you always see what killed you.
3. One more try: restart in under 1 second.

## 3. Player fantasy
A small, brave keeper pushing back the dark.

## 4. Player and platform
- For: players who like short, tense platformers
- Plays on: desktop and phone browsers, landscape
- Session: one level takes about 3 minutes

## 5. Core loop
Run and jump → reach a shrine → refill flame → choose the next path → repeat

## 6. Controls
| Action        | Keyboard     | Gamepad    | Touch                |
|---------------|--------------|------------|----------------------|
| Move          | A/D or ←/→   | Left stick | Drag on left half    |
| Jump          | Space        | A          | Tap jump button      |
| Raise lantern | Shift (hold) | RT (hold)  | Hold lantern button  |

## 7. Win and lose
- Win: light all 5 shrines in a level.
- Lose: the flame reaches 0, or you fall.

## 8. Look and sound
- Art: 2D side view, warm orange light on cold blue, soft vignette.
- Audio: quiet piano, a crackling flame that gets louder as it dies.

## 9. Scope
- In: 3 levels, 2 enemy types (moths, shadows), 1 upgrade (bigger flame).
- Out: story, bosses, multiplayer, level editor.

## 10. Open questions and first playable
The prototype must answer:
- [ ] Is the flame timer stressful in a fun way, or just stressful?
- [ ] Does anyone raise the lantern (it reveals platforms but burns faster)?

First playable is done when:
- [ ] Level 1 plays start to finish on desktop and phone
- [ ] Flame timer, refill and death all work
- [ ] Restart takes under 1 second

Look at what it leaves out: no story, no lore, no menu flow. None of that answers whether carrying a dying lantern is fun. If you're making a platformer yourself, how to make a platformer takes it from here to a build.

A one-pager this specific also works as a prompt for an AI game maker (more on that below):

Other free templates worth a look

If you'd rather start from someone else's structure, these are free as of November 2026:

Notion's marketplace also sells longer ones, such as a 40-plus-page guide for $3 and an "Ultimate" template for $10 as of November 2026. A 40-page template for a first game is the 1990s bible again, so cut it hard if you use one.

Which tool to write it in

Use whatever the people reading it already open. Google Docs or Word if you share with people who won't install anything. Notion or a wiki once the document grows into linked pages, but keep the one-pager as one page: Game Dev Beginner warns that splitting information across pages hides how the parts relate. A Markdown file in your Git repo if you code. A whiteboard for the visual version; Game Developer's Danielle Riendeau sketches on whiteboards, then makes concise versions in Miro for her team.

Famous game design documents you can read

Big studios rarely publish their design documents, so the best-known public examples come from the 1990s and early 2000s. We found no official GDD from a modern AAA game, which is why searches for something like a God of War GDD come up empty. These seven are real and readable, and every one of them changed before release.

The Doom Bible (1992)

Tom Hall delivered the Doom Bible at the end of November 1992. According to Wikipedia's history of Doom's development, the team rejected the entire document early in 1993 and decided it didn't need one. Hall was fired in July 1993, and Sandy Petersen replaced him in September, about ten weeks before release. The lesson isn't "never write a GDD". A detailed document that fights the technology and the game the team wants to make gets thrown away, so test those assumptions first.

The Diablo pitch (1994)

Condor, the studio that became Blizzard North, pitched Diablo in eight pages. The pitch describes turn-based play in the style of Dungeons & Dragons and even proposes $5 expansion disks. During development the game switched to real time. Eight pages were enough to sell the game. The decision that shaped how it plays came later, from playing it.

Race'n'Chase, the GTA design document (1995)

DMA Design's Race'n'Chase spec, version 1.05, is dated 22 March 1995. It describes a fast multiplayer racing and crashing game across three cities, with modes including Cannonball Run, Demolition Derby and a bank robbery you play as robber or cop. It planned five platforms, a first play date of 3 January 1996 and the end of the project on 1 July 1996. Wikipedia notes that none of the milestones were met, and networked multiplayer was dropped. It's the best structured spec here, and the clearest proof that dates in a design document are guesses.

The Grim Fandango puzzle document (1996)

Tim Schafer, Peter Tsacle, Eric Ingerson, Bret Mogilefsky and Peter Chan wrote 72 pages of puzzle structures, early art, and background and solutions for more than 80 puzzles. Schafer published it for the game's 10th anniversary. It also shows what got cut, including a Pizza Demon and a five-puzzle action climax, and Schafer said he wished they'd had one or two more years. The useful idea here: a "GDD" can be a set of focused documents. This one covers puzzles and nothing else.

The BioShock pitch (2002)

Irrational Games released a nine-page excerpt of its 2002 pitch in May 2010. It pitches a spiritual successor to System Shock 2 whose hero is a deprogrammer sent to an island cult, and it planned a story-based deathmatch mode. The game that shipped in 2007 dropped the multiplayer and told a different story, about a free-market ideal gone wrong. A pitch's job is to sell a tone and a promise, not to lock the details.

For more, Gamescrye's library lists 57 documents, including Wipeout (1995), Silent Hill 2 (2001) and Metal Gear Solid 2's "Grand Game Plan" (2001). Some entries are student or fan documents, so check the source before you treat one as official.

Common game design document mistakes

• Writing the full bible before anything is playable. Cerny's point stands: it sets direction before the fundamentals are checked. Write one page, then prototype.
• Describing fun instead of rules. "Combat feels punchy" can't be built. Game Gen puts it plainly: features aren't fun on paper. Write the rule and a number.
• No out list. Without one, every good idea gets in. List what's out of v1 as carefully as what's in.
• Ignoring the target device. A design that needs six buttons won't survive a phone screen. Fill in the touch column on day one.
• Writing for nobody in particular. A publisher needs the pitch and the audience; your future self needs numbers and reasons. Decide who reads it first.
• Never updating it. Codecks warns that documents go out of sync almost immediately, and Game Gen sees them abandoned after the first draft. Date every version and keep a change log of what playtesting showed.
• Splitting it into a wiki too early. Keep one document until it hurts, then split it.
• Copying a 40-page template for a jam game. Delete every section your game doesn't need. Empty headings are noise.
• Treating the document as a contract with yourself. The Doom team threw theirs out and shipped anyway. When the prototype disagrees with the page, the prototype wins.

Can AI write a game design document?

Yes, as a first draft, and quickly. Several tools do it as of November 2026:

• Ludo.ai's Game Concept feature, launched in April 2022, fills in GDD sections from templates, answers questions about each section, generates images and can import an existing GDD as a PDF. Its feature page talks about assets for your engine; it doesn't say it builds a playable game.
• Wayline's Blueprint generates a GDD from a text description, covering mechanics, story, level design and monetization, which you can edit and export, according to Wayline.
• Seele AI's GDD generator turns genre, style, platform, scope and constraints into a production brief, a review checklist and a prompt for continuing toward a prototype.
• Any general chatbot will draft one if you ask.

An AI draft is good at structure. It won't forget the lose condition or the touch column, and it turns a vague idea into something you can react to in minutes. What it can't do is know your taste, decide what to cut, or tell you whether the flame timer is fun. The risk is the one Codecks names for any long document, false confidence: a tidy 20-page GDD for a game nobody has played is still a list of guesses. Use AI for the first draft, cut it to a page, and get to a playable fast. For a wider look at tools that go from prompt to game, see our comparison of AI game makers.

How Oryn uses a design document

Oryn, the AI game maker behind this blog, writes a design document before it builds anything. The reason is the one this article keeps making: you can't test a bet you haven't written down.

You describe your game in a prompt, with reference images if you have them. Oryn asks a few planning questions one at a time, each with suggested answers and room for your own. They include which art style to use and a choice between generated gameplay reference images. From your answers it writes the design document in five parts: game idea, gameplay, game progression, look and sound (including game feel), and scope. A short game brief opens it, with the high concept, player promise, genre, perspective and platform. You can edit any chapter, and nothing is built until you approve it.

Then Oryn writes a real Godot 4 project and a web build you play in the browser; the build button estimates about 30 minutes. You say what should change, and every working version is kept so you can restore an earlier one. You can export the full Godot project as a .zip or publish the game to the Oryn games shelf.

The limits are the ones above: AI output varies between runs and needs review and testing. The planning questions are where your taste goes in, so answer them specifically and check the plan before you approve it. A filled-in one-pager makes a good starting prompt, and the guide on writing a brief that produces a coherent game shows what else to include.

On the free plan you can plan up to three games, each with a full design document, reference images, a cover and a logo, and your first game is built free. Changing it afterwards or building another needs Oryn Pro or Max, where planning also costs credits; the paid plans are on the pricing page.

Your next step: download the one-page template, fill in the pitch, pillars, core loop and two open questions, and build the smallest thing that answers the first question. Build it by hand in an engine, or describe it to Oryn and play the first version in your browser.

Frequently asked questions