The Complete Game Design Document Template (with the actual template, in full)

Most GDD templates on the internet are one of two kinds.

The first is a single-page Word document that lists “GAMEPLAY, STORY, ART” as bold headings and calls itself complete. You download it, you stare at it, you realise it doesn’t actually tell you anything you couldn’t have written on a napkin, and you close the tab.

The second is a 70-page corporate behemoth pulled from a 2008 EA postmortem. It has 47 sections, half of which apply to AAA console pipelines that don’t exist anymore. Nobody on a real indie team has the patience to fill it in, and the people who try produce a document that sits unopened in a Dropbox folder for the rest of the project.

This post is the middle path.

It’s the template I’ve used on every project for the last four years. Six top-level sections, each with subsections, each with a prompt that tells you what question the section is trying to answer. Fill in what you know. Leave what you don’t. Come back next week and fill in more. The thing is supposed to grow with the project, not be perfect on day one.

The full template is below in copy-pasteable form. There’s a worked example at the end, filled in for a fake vertical slice called The Cinder Crown, so you have a concrete reference for what “good first-draft” looks like.

The principle that makes a GDD actually useful

Bad GDDs all share a single failure mode: they conflate what the game is with how the game works. (This is a more specific symptom of the broader problem I wrote up in why generic tools break for game design. The TLDR: tools that don’t know what a game IS will always force you to invent structure on top of them.) You end up reading three pages about “the protagonist’s emotional journey” before you find out whether the game is third-person or first-person.

Whoever wrote it knew the answer; whoever needs to actually build the game does not.

The fix is to front-load the unambiguous, decision-critical answers and back-load the texture and elaboration. A new team member reading the doc cold should be able to stop after section 2 and already know what game they’re working on. Sections 3 onward exist to deepen that understanding, not to establish it.

This principle is why the template below puts “core gameplay” before “world and narrative”. Even though narrative is what most designers want to write about first. The world matters; it just matters after the player knows what they’re doing in it.

The template

Six sections. Each has a question it answers, subsections with their own questions, and a note about what most teams get wrong in this section.

Section 1. The Pitch

Question this section answers: In one paragraph, what is this game?

If you can’t fill this in honestly and concretely, the rest of the GDD won’t save you. Most projects that quietly die in pre-production die because the pitch was never sharp.

1.1 One-line pitch The fifteen-words-or-fewer version. “Stardew Valley but the farm is haunted.” “Hades but it’s a heist crew planning a museum job.” Reference-based pitches are fine and often clearer than original prose.

1.2 Genre and references What category does this fall in, and what are the three closest reference games? Be specific. “Roguelite deckbuilder” is fine; “indie game” is not. The references aren’t competitors. They’re shared vocabulary for the team. When someone says “make this feel more like Hades,” everyone should know what that means.

1.3 Target platform + audience PC + Steam? Console? Mobile? Who is this for? “Anyone who liked Hades” is a fine answer; “everyone who likes games” is not. The audience question is what tells you whether to put a tutorial in or trust the player.

1.4 Hook What’s the first 30 seconds of seeing this game? Not the theme. Not the unique mechanic. The thing that makes someone wishlist on Steam, click on a Twitter post, or DM a friend. If you can’t describe the hook, you don’t have one yet. Most prototypes find their hook in week 4 of playtesting, not week 1 of design. So it’s OK to write “TBD, candidates are X, Y, Z” here.

Most-skipped mistake in this section: writing the hook as the theme instead of as a moment. “It’s about loss” is a theme. “The protagonist’s house burns down in the opening cutscene and the rest of the game is them rebuilding it” is a hook.

Section 2. Core Gameplay

Question this section answers: What does the player do, second to second?

This is the section publishers, contractors, and new team members read first to know whether they want to work on the project. Write it like the reader will stop after one paragraph and you need them to get it.

2.1 Verbs The 5-7 core verbs the player performs. “Move, jump, attack, talk, trade, craft, sleep.” This is the atomic vocabulary of your game. Every feature has to either compose from these verbs or introduce a new one cleanly. If you have 14 verbs you have scope creep, not design.

2.2 Core loop What the player does in a single minute. Then in a single session. Then across sessions. Diagram it. Even a rough flowchart is worth a paragraph of prose. The diagram is the thing. The prose is supporting.

2.3 Win/loss conditions How does a play session end? How does the game end? What happens when the player fails. Restart, retry from checkpoint, soft loss with consequences? Permadeath should be an explicit decision, not an implicit one.

2.4 Pacing Roughly how long is a session? How long is a complete run of the game? Does difficulty curve over time, or stay flat, or have peaks and valleys? Pacing is the thing most likely to feel wrong on first playtest; designing it intentionally up front saves three months of post-vertical-slice flailing.

Most-skipped mistake in this section: listing 12 verbs because they all feel core. Pick five. The other seven are content, not verbs.

Section 3. Systems

Question this section answers: What machinery makes the game work?

Most teams under-fill this section in v1 because the systems aren’t decided yet. That is correct. Use the section as a placeholder for the decisions you’ll make later, not as a place to invent systems to fill the page. An honest “TBD. Leaning toward X” is more useful than a confident-sounding paragraph about a system that will get cut.

3.1 Progression How does the player become more capable over time? Levels? Gear? Unlocks? Skill trees? Don’t pick “all of the above” by default. Most games need one or two, and the games that ship with all four are 90% AAA studios with the headcount to build all four properly.

3.2 Economy What resources exist? Where do they come from? Where do they go? Most game economies break because a designer added a source without adding a corresponding sink. Make the table. It’s a 5-minute exercise that catches the issue before it ships:

3.3 Combat / interaction model Whatever the primary moment-to-moment activity is, describe it. If it’s combat: weapons, classes, defense model, status effects. If it’s dialogue: branching style, voice direction, choice consequences. If it’s puzzles: rule discovery vs. memorisation, hint system, fail state.

3.4 Difficulty scaling What gets harder as the player progresses? What stays the same? Don’t say “everything scales.” That’s how you accidentally make a flat experience that feels the same at hour 1 and hour 30. Pick what scales (enemy stats, encounter complexity) and what doesn’t (player verbs, UI complexity).

Most-skipped mistake in this section: describing the economy without naming the sinks. Look at the table above. The Sink column is the one that determines whether your economy is healthy.

Section 4. World and Narrative

Question this section answers: What is the world, and what story is being told inside it?

4.1 Premise The two-paragraph version of the setting and the situation that kicks off the game. Where, when, why is the player here. Don’t write the whole prologue.

4.2 Tone Three adjectives. “Melancholic, hopeful, weird.” “Funny, brutal, intimate.” “Tense, slow, paranoid.” You’ll use these adjectives a thousand times during art and audio reviews (“this feels too cheerful; we said melancholic”). Pick them deliberately now.

4.3 Major characters A list, with one line per character describing their role in the player’s experience. Not their backstory. Their role. “Mentor. Dies in Act 2. The first character the player loves.” “Antagonist. The protagonist’s mirror. Revealed as right about everything in the final hour.”

Full bios live in their own per-character pages, not here. A short field-structure I use for those: one-line pitch, role, voice sample, visual silhouette, mechanical hook, backstory in three beats, relationships, arc in this game, and what they will NOT do.

4.4 Locations A list, with one line per location describing its role. Same principle as characters. Details live in their own pages. “Capital city. Where the player first feels safe and then learns they shouldn’t have.” “Final dungeon. A descent. The light gets dimmer the deeper you go.”

4.5 Story beats The five-to-ten major plot beats, in order. Not the full plot. Just the shape. A reader should know after this list whether the game is a redemption arc, a tragedy, a journey-and-return, or something else. The beats are the skeleton; the prose is the skin.

Most-skipped mistake in this section: writing character bios in the list of characters. Resist. Keep the list scannable. The bios go on their own pages with their own structure.

Section 5. Art and Audio

Question this section answers: What does the game look and sound like?

5.1 Visual style Three reference images (linked, not embedded. Keep the doc light). One paragraph on what makes the style: palette, line weight, lighting model, character proportions. Reference images do 90% of this section’s work; treat the prose as supplementary.

5.2 Color palette The actual hex values for your primary, secondary, accent, and neutral colours. Surprisingly many GDDs skip this and then live in colour drift hell for two years. A 5-minute upfront decision saves dozens of “should this UI element be the gold or the brown?” arguments.

5.3 Audio direction Three reference tracks (Spotify or YouTube links). One paragraph on the music’s role: ambient bed? Reactive? Diegetic vs. non-diegetic? Vocal? Instrument palette? Sound design philosophy (hyper-realistic vs. stylised vs. retro).

5.4 UI / UX direction Diegetic vs. non-diegetic UI lives here. So does the font choice. So does whether you’ll use mouse + KB, controller, both, or touch-only. The accessibility decisions also live here (colour-blind modes, subtitle minimums, remap-everything as default).

Most-skipped mistake in this section: skipping the colour palette. It feels precious to commit to hex codes early. It saves so much time downstream.

Section 6. Scope and Schedule

Question this section answers: Is this actually buildable?

This is the most-uncomfortable section to fill in and the one that catches the most fatal mistakes. Most cancelled indie projects die because of scope, not vision.

6.1 Scope A bulleted list of what’s in the game. Not features in the abstract. Concrete content. “Three biomes, twelve enemies per biome, eighteen weapons across four damage types, six bosses, twenty-four side quests.” Be specific or be wrong.

6.2 What’s NOT in scope The most-skipped section of any GDD and the one that prevents the most arguments down the line. List the things people will ask for and you won’t ship:

• No multiplayer.
• No mod support at launch.
• No localisation beyond English at v1; community translations welcome post-launch.
• No console release in year one.
• No daily challenges or seasonal content.

When someone six months from now says “wouldn’t it be cool if we added X,” you can point at this section instead of having the conversation from scratch.

6.3 Major milestones A rough timeline with three to five anchor dates. Not a Gantt chart. Just:

• Prototype playable: end of month 2
• Vertical slice complete: end of month 6
• Content-complete alpha: end of month 14
• Beta: end of month 16
• Launch: end of month 18

Each anchor should be ambitious-but-defensible. If you can’t defend the dates, the schedule is fantasy and you’ll be embarrassed about it in retrospect.

6.4 Known risks Three to five things that could go wrong, ranked by likelihood × impact. Write the mitigations down too. If you can’t name three risks, you’re not thinking hard enough about the project. Common risks for indie projects:

• Risk: Lead artist quits. Mitigation: Document style early; identify two backup artists in the network.
• Risk: Combat fails to gel and needs to be reworked at month 10. Mitigation: Lock the combat feel by end of month 4 with a 2-week dedicated prototype.
• Risk: Runway runs out before launch. Mitigation: Vertical slice at month 6 enables a soft Steam wishlist push; revisit funding strategy if wishlist below X.

Most-skipped mistake in this section: treating “What’s NOT in scope” as optional. It’s the most important section in the entire GDD, because it’s the only one that protects you from yourself.

A worked example. The Cinder Crown

To make all the above concrete, here’s the template filled in for a fake action-RPG vertical slice. The depth here is roughly what I’d expect at the end of week 2 of pre-production.

1. Pitch

1.1 One-line: A princess inherits a forbidden artifact, and the court conspires against her. Dragon Age but the conspiracy is the gameplay, not the backdrop.

1.2 Genre: Action-RPG with diplomatic dialogue trees and tactical pause-and-play combat. References: Pillars of Eternity 2 (faction politics), Hades (combat feel), Disco Elysium (dialogue as gameplay).

1.3 Platform / audience: PC (Steam) primary, console post-launch. Audience: CRPG players who liked Larian but want shorter sessions and tighter writing.

1.4 Hook: The crown speaks. The first thing the player hears, before any UI, is the crown’s voice in the protagonist’s head. The crown is wrong about things in a way that makes you uncertain whether to trust it. The whole game is “do you take the crown’s advice.”

2. Core Gameplay

2.1 Verbs: Move, talk, attack, defend, persuade, accuse, ally.

2.2 Core loop:

• One minute: Read dialogue, choose a response shaped by current Crown / Court influence.
• One session: Investigate one conspiracy thread; resolve through combat OR diplomacy.
• Across sessions: Court reputation shifts; new factions become viable allies / enemies; ending unlocks reflect choices.

2.3 Win/loss: Game ends when the player chooses to crown or destroy the crown in the final act. No fail state; bad choices lead to bad endings, not retries.

2.4 Pacing: 30-minute sessions feel complete. Full game ~20 hours main path, ~35 with all faction routes.

3. Systems

3.1 Progression: Two stats. Crown (occult/intimidation) and Court (charm/strategy). That grow based on choices, not XP. No levels.

3.2 Economy: Currency = Favors. Sources: completing faction quests, eavesdropping discoveries. Sinks: bribing guards, commissioning artifacts, paying off debts. Cap: 100 favors. No inflation late-game (intentional. Late-game economy is in influence, not coin).

3.3 Combat: Tactical pause-and-play. Three party members at any time. Combat feels like Pillars but turn-based encounters resolve in 45 seconds, not 5 minutes.

3.4 Difficulty scaling: Enemy intelligence (positioning, target prioritisation) scales with player progression; enemy stats do not. Player can always brute-force-tactically; scaling is in their thinking, not their clicking.

4. World and Narrative

4.1 Premise: The kingdom of Vallindor. A 200-year peace under the Cinder Crown is fracturing. The previous monarch died “of natural causes” three months before the game opens. The player is the youngest heir.

4.2 Tone: Melancholic, intimate, paranoid.

4.3 Major characters (excerpt):

• Lyra. Protagonist. The crown’s chosen, doesn’t want to be.
• Vesper. High Priest. Mentor. Has his own agenda; revealed in Act 2.
• Cassio. General. Loyal to the throne, not the person on it.
• The Crown. Character with internal voice line. Wrong about things in a calibrated way.

4.4 Locations (excerpt):

• The Spire. Capital. Where the player feels safe; learns not to.
• The Marches. Wild border province. Sanctuary if exile becomes necessary.

4.5 Story beats (skeleton):

1. Inheritance & first crown-voice
2. First conspiracy discovered (faction routes diverge here)
3. Vesper’s betrayal revealed
4. Exile to the Marches (or coronation, depending on path)
5. Return; final choice (crown / destroy / share)

5. Art and Audio

5.1 Visual style: Hand-painted 2.5D, Pillars of Eternity lineage. Three references: PoE2, Hades, Tyranny.

5.2 Color palette: Primary #d4a847 (Crown gold). Secondary #4dd4e0 (Court teal). Accent #b03c3c (Conspiracy red). Neutral #0e1322 (deep navy).

5.3 Audio: Strings + sparse vocal motifs. Reference: Pillars OST. Reactive music tied to Crown/Court score.

5.4 UI: Diegetic where possible (dialogue choices appear as scrolls being unrolled). Controller-first; KB+M supported.

6. Scope and Schedule

6.1 Scope: Three acts. 24 named characters. 6 factions. ~40 side quests. ~12 distinct combat encounters per act. Vertical slice = Act 1.

6.2 NOT in scope: No multiplayer. No mod support v1. English only at launch. No DLC planned year 1.

6.3 Milestones: Prototype M2. Vertical slice M6. Alpha M14. Beta M16. Launch M18.

6.4 Risks: (1) Combat-system feel undefined. Mitigation: 2-week dedicated combat prototype in M3. (2) Faction-route writing is 4x the prose of linear plot. Mitigation: limit to 3 faction routes from day one. (3) Lead artist is a contractor. Mitigation: style guide locked by M2; backup artist on retainer.

Three rules for actually using this template

1. Fill in what you know in one sitting, even if you have to guess. Bad answers in italics are infinitely better than empty headings. They trigger feedback. Empty headings get scrolled past. The doc you finish in 90 minutes today is the doc that will get improved over the next 90 days.

2. Re-read the whole thing every two weeks for the first three months. Most of the value of a GDD is the re-reading, not the writing. Decisions you made in week 1 won’t make sense by week 6, and the GDD is where you find that out before the build does.

3. Link out, don’t write down. When a section references a character, link to their character page; don’t paste their bio. When it references a system, link to the system page. The GDD is a map. The details live in the pages it points at.

How to actually use this in a tool

You can put this template in any tool you like. Word, Google Docs, Notion, Obsidian. The format matters less than the discipline of keeping it current. (If you’re trying to pick a tool, I wrote a comparison of the 7 best ones and a dedicated honest review of Notion specifically.)

The one thing the template assumes is that the characters, items, quests, and mechanics it references live somewhere structured. Not as more sub-pages of the same doc, but as their own typed records you can search, filter, and cross-reference. If your tool can’t do that, every reference in the GDD (“see character Lyra,” “see mechanic Crown Voice”) becomes a manual link that rots when the linked thing renames.

This is the gap that drove me to build Ludessy. Character / item / quest / mechanic editors with their own forms, and a GDD editor that can embed any of them as live cards. (For the full story of why I built it, here’s the launch post.) Whichever tool you pick, the template here works inside it; just be aware of which problem that tool will solve for you, and which it will quietly leave to you.

The downloadable version

I’ll wire a real download link here as soon as the asset pipeline is ready (likely next week). In the meantime, the version above is the full template. Copy-paste it into your tool of choice and you have a working starting point.

Next step

Pick a project. Yours, or a paper-design exercise. And fill in sections 1 and 2 right now. Twenty minutes. The hardest part of any GDD is the first hour; after that, it writes itself in passes.

If the structure helps, tell me what’s missing and I’ll iterate the template based on what you actually use it for.