How to write a game design document

What the document is actually for

A design document is not a specification, and treating it like one is what kills it. Nobody can specify a game in advance, because the thing you are specifying does not exist yet and will not behave the way you imagined.

What it is for is narrower and more useful: it records decisions so you only have to make them once. When someone asks in month four whether the game has a crafting system, the document either answers in one line or it has failed. Every section below earns its place by that test.

A second, quieter job: it is the artefact you hand a collaborator, a publisher or a contractor so they can be useful without an hour of your time. That audience is why it needs a pitch at the top and a date on it.

What belongs in it

Twelve sections, in the order a reader needs them. The template has all of them with the prompts written out.

1 · The pitch

One paragraph: what the player does, who they are, why anyone would care. If it will not fit, the game is not decided yet — which is worth knowing on page one.

2 · Pillars

Three at most. A pillar is something you would cancel a good feature to protect. "Fun" is not one. "Every fight is survivable without combat" is.

3 · The loop

What the player does for thirty seconds, ten minutes and ten hours. Write all three — most projects have one clear and two missing, and the missing ones are where the game falls apart.

4 · The player

Who this is for and what they already know. Name a game they have played. Vagueness here becomes tutorials nobody needed.

5 · World and tone

Two or three reference works beat a page of adjectives, because the team can go and look at them.

6 · Narrative

Shape, who tells it, what the player changes, and where it lives. More on this below.

7 · Systems

One heading each: purpose, what the player sees, what it needs from other systems. Cut any system you cannot connect to a pillar.

8 · Content inventory

Levels, characters, dialogue lines, items, tracks. This is the number that decides your schedule. Estimate badly and early rather than accurately and late.

9 · Art and audio direction

In terms someone could act on. References, not adjectives.

10 · Technical

Engine, platforms, minimum spec. Note what would be expensive to change later — save format, input model, localisation — because those get decided by accident otherwise.

11 · Out of scope

The most useful section in the document and the one most often missing. Every entry is an argument you only have once.

12 · Risks

Specific enough to be uncomfortable. "Scope" is not a risk. "The narrative branches faster than one writer can fill them" is.

Four habits that keep it alive

• Put a date and an owner at the top. A document with neither is a document nobody trusts, and untrusted documents stop being read before they stop being true.
• Keep it under ten pages. Length is not thoroughness. If a section needs twenty pages it is not a design decision any more, it is a system, and it wants its own document.
• Put it in the repository. Plain text, next to the code, in version control. A design document in a cloud editor has no history anyone will read; one in Git tells you exactly when the crafting system appeared and who was arguing for it.
• Delete from it. The document should get shorter as the game gets more certain. Decisions made become one-liners; options not taken move to "out of scope".

The narrative section is the one that goes stale

Sections 1 to 5 are decisions, and decisions hold still. Section 6 is different: narrative is the part that keeps growing while you write it. A branch becomes three branches, a character acquires a second scene, a quest grows a failure state nobody planned. Within a month, the prose description in your document and the story in the build are two different games.

So the honest advice is to keep section 6 short and point it somewhere real. Write down the shape — linear, branching, hub-and-spoke, systemic — who tells the story, what the player actually changes, and then where the story itself lives. Do not try to hold the story in the document. It will lose.

That last line, "where it lives", is the one that saves you. Narrative that only exists in a document goes stale the week production starts, because the document cannot be played, cannot be tested, and cannot be exported to the engine.

Take the template

Markdown, twelve sections, every prompt written out. It is meant to be cut down rather than filled in — a section you delete with a clear conscience is a decision too.