An Example of a Game Design Document: One-Pager to Pro
A good example of a game design document depends on the stage you're at: a one-page concept doc to pitch the idea, a jam-scale GDD covering core loop and scope, and a full professional document with annotated sections once you're in production. This walkthrough shows the same section rewritten at all three fidelity levels.
What is a game design document and what does it actually contain?
A game design document (GDD) is the single written source of truth for what your game is, how each system works, and what "done" means. It sits next to your task board: the board tracks who's building what this sprint, the GDD explains why the thing works the way it does. If you're juggling Trello, Discord, and Google Docs, the GDD is the doc that stops the other two from contradicting each other.
The seven sections every GDD needs
- Concept (one paragraph, the elevator pitch)
- Core gameplay loop
- Mechanics and systems
- Story and world
- Level or content structure
- Art and audio direction
- Milestone and scope plan
Real professional docs follow this shape. The famous Doom design document covers concept, mechanics, monsters, levels, and storyline in exactly this layered way, just at far greater depth than a tiny crew needs.
Why the 'living document' cliché is true for a tiny crew
On a 2-8 person team, nobody reads a stale 80-page doc, so the GDD has to live where work happens. When your design notes sit beside your kanban board, a changed mechanic updates the same place the backlog updates. That's the argument we make in our Inferno vs Codecks comparison: docs and tasks drift apart when they live in different tools, and drift is where scope creep starts.
What does a game design concept document example look like before full production?
Before a vertical slice or a jam, your GDD is one page. Not one page that grew into twelve: one page that forces decisions. Here's the shape that works for a tiny crew, with annotations.
Annotated one-pager: the elevator pitch section
Write two sentences, no more. "A roguelike where you play the dungeon, rearranging rooms each turn to kill the hero" beats three paragraphs of lore. The annotation rule: if a teammate reads only these two sentences, they should know the genre, the hook, and who the player is. If they can't, the concept isn't ready to build, no matter how good the rest of the doc is. Put the pitch at the top so it's the first thing anyone sees in the shared workspace, and rewrite it every time scope creep changes the answer.
Annotated one-pager: core loop in three sentences
The core loop section gets exactly three sentences, one per beat: what the player does, what happens next, and why they do it again. "You place rooms. Placed rooms generate resources and threats. Better placement means the hero dies faster, which unlocks new rooms." That's the whole game, testable in a prototype within a week.
The reason the constraint matters: a one-pager is a promise you can hold the build against. When Friday's milestone slips, you check the loop sentences, not a 40-page doc nobody updated since the pitch. Keep the one-pager next to your backlog rather than in a separate folder, so the doc and the tasks drift together instead of apart, which means the loop text gets edited the same day the sprint changes. If a feature can't be traced back to one of those three sentences, it waits. That traceability test also doubles as your scope guard during reviews: when someone proposes a crafting system or a hub world, you ask which loop sentence it serves, and if the answer is silence, the idea goes to a parking list instead of the sprint backlog, where it would have sat as a card nobody could justify.
How does a section change between a one-pager and a professional game design document?
The clearest example of a game design document is the same section rewritten at three fidelity levels. Here is a combat section for a 2D roguelike, evolving from one page to full production spec.
Level 1: one-pager combat blurb
Combat: Real-time, top-down. Player dodges with a dash, enemies telegraph attacks. Aim is fast, readable encounters, not depth. Tune later.
That is enough for a jam. Ludum Dare veterans consistently recommend keeping pre-jam design to a single page so scope stays honest (see Ludum Dare's site for jam culture and guidance).
Level 2: jam-scale GDD combat section
Combat: Player has attack (3-hit combo, 0.3s between hits) and dash (0.5s cooldown, 8px i-frames). Three enemy types: melee chaser, ranged turret, charger. Each has one telegraph animation. Damage numbers: player 1 HP, enemies 2-4 HP. No weapon variety; one melee weapon ships.
Now it has numbers a programmer can build against and a scope ceiling the whole crew accepts.
Level 3: professional GDD combat spec
Combat systems: Full input buffering spec, hit-stop tables per weapon class, damage formula (base × crit multiplier × armor curve), enemy archetype matrix with telegraph timings per animation frame, difficulty curve targets per biome, and edge cases: what happens when dash i-frames overlap a grab attack.
What each level is for
| Level | Audience | Question it answers | Failure mode if skipped |
|---|---|---|---|
| One-pager | The whole crew, pre-production | Is this worth building? | Scope creep before a line of code |
| Jam-scale GDD | Your 2-8 person team during a sprint or vertical slice | What exactly do we build this milestone? | "Fixed stuff" commits nobody can trace |
| Professional spec | Future you, plus any collaborator joining mid-pipeline | Why is it built this way? | Monday-morning archaeology through Discord and old docs |
The rule: each level adds numbers, edge cases, and rationale, not adjectives. If your tool separates docs from the board, that rationale rots; we built Inferno so design notes live beside the backlog for exactly this reason.
How to create a game design document step by step?
Step 1: write the one-pager first
Start with the concept doc from earlier in this article: core loop, pillars, target player, scope in one sentence. If your tiny crew cannot agree on one page, more pages will not fix it. Ship this page before anyone opens a task board.
Step 2: expand only sections your next milestone needs
Look at your next milestone, usually a vertical slice, and expand only the GDD sections that slice touches: mechanics, one level, the art pipeline for its assets. Everything else stays as a stub heading. A professional game design document grows from the backlog outward, not from a template downward.
Step 3: link GDD sections to tasks
Every expanded section gets linked to the tasks implementing it, the way Codecks users keep design docs beside task management. In Inferno, the GDD lives in the same workspace as the board, so a designer updating a mechanic sees the tasks it breaks. We compare how that setup stacks up against HacknPlan in our Inferno vs HacknPlan comparison.
Steps 4-5: review cadence and versioning
Review the GDD at every milestone, not every sprint; mid-sprint edits cause scope creep. Version it with your build so a "fixed stuff" commit traces back to the section that asked for it.
What should you leave out of a design document game teams actually use?
Cut anything the task board already owns
Sprint assignments, build statuses, and bug lists rot the moment they're pasted into a GDD. Your board is the live version; the doc is a snapshot that's wrong by Friday. Keep the GDD for durable design intent, and let the task board own anything with a checkbox. A milestone and backlog view already tracks scope creep better than a paragraph ever will.
Cut anything no one reads at standup
Lore dumps, pixel-level art specs, and 40-page system breakdowns don't get read on a tiny crew. If a section wouldn't survive being skimmed aloud at standup, cut it or move it to an appendix. Also skip elaborate formatting: heading-based structure in Google Docs generates an automatic table of contents, which is all the polish a working GDD needs (Google Docs Help).
How do you set up a game design document template in Google Docs?
Build the skeleton once, then duplicate it per project. Use Title for the doc name, Heading 1 for major sections (Overview, Core Loop, Systems, Art, Audio, Milestones), and Heading 2 for subsections. Google's heading styles let you insert an automatic table of contents that updates as your GDD grows (Google Docs Help).
Heading hierarchy that auto-builds your TOC
Resist manual bold text. If a section title isn't a heading style, it won't appear in the TOC or the document outline in the left sidebar, which is how teammates skim a 20-page doc. Keep it to three levels deep so the outline stays scannable during a sprint review.
Using comments and suggestions for design review
Assign comments to a specific teammate with @mentions so a design question doesn't die in Discord. Use Suggesting mode for rewrites of systems text, and resolve threads only when the change lands in the backlog. This keeps review history attached to the exact paragraph, not scattered across channels.
When is a lightweight GDD better than a full one for small teams?
Match the doc to the stage: a jam page in a jam, a slice doc for the vertical slice, and a split doc only once a tiny crew becomes a real pipeline.
Jam: one page, no more
One page. Loop, controls, win condition, scope cut line. Anything longer doesn't get read during a jam.
Vertical slice: 5-10 pages
Core loop, one level or encounter, art direction with reference images, and a build checklist. Keep it next to your board so every card traces back to a section.
Full production: when to split the doc
Split when two disciplines can't work from the same file without blocking each other: systems doc, content doc, and a milestone plan. That's also where docs-plus-board breaks down and dedicated tools earn their keep. HacknPlan ties design docs to tasks; Codecks merges them (its users cite docs living alongside task management on Codecks). Honest limit for us: Inferno handles the planning side well, but deep design prose still belongs in a doc you link, not replace.
FAQ
What does a game design document look like in practice?
It depends on stage. A one-pager holds a two-sentence pitch and a three-sentence core loop. A jam-scale version adds numbers like cooldowns and HP values. A professional spec adds edge cases, damage formulas, and rationale for why each system works. Each level adds specifics, not adjectives.
How long should a game design document be for an indie team?
Match it to the milestone. A vertical slice needs 5-10 pages: core loop, one level, art direction with references, and a build checklist. Only split into multiple docs when two disciplines block each other working from the same file. Anything longer than the team reads at standup rots.
Do I need a GDD for a game jam?
Yes, but only one page. Include the loop, controls, win condition, and a scope cut line. Ludum Dare veterans recommend keeping pre-jam design to a single page so scope stays honest. A jam doc is a promise you hold the build against when the milestone slips on Saturday night.
Is there a free game design document template for Google Docs?
Build your own skeleton once and duplicate it per project; it takes ten minutes. Use Heading 1 for major sections like Overview and Core Loop, and Heading 2 for subsections. Google's heading styles generate an automatic table of contents that updates as the doc grows. Keep it three levels deep.
What is the difference between a concept document and a GDD?
A concept document is the one-page pitch: elevator pitch, core loop, target player, and scope in one sentence. It answers whether the game is worth building. A GDD answers how each system works and what done means, with numbers a programmer can build against. Write the concept first.