Game Design Document Template: One Page That Stays Alive
Summary
A game design document template works best as one page: pitch, design pillars, core loop, systems list and open questions. Add lore, numbers and production notes only after playtests prove a mechanic. This guide covers pillars that can veto features, where lore belongs, which tool to use, and how AI can check consistency without writing your decisions.
A game design document template should fit on one page first and grow only when the game earns it. Start with five blocks: pitch, design pillars, core loop, systems list and open questions. Everything else, from lore to level notes, gets added when a playtest proves the mechanic is real. Below is the template we use for tabletop and indie video game projects, plus where each section tends to rot.
Why do most game design documents die by week three?
The usual failure is ambition. Someone opens a blank file, pastes a 20-section outline from a forum, and spends a weekend filling in boxes for mechanics nobody has tested. By week three the game has moved and the document has not. Nobody opens it, and nobody admits it.
Game Dev Beginner's guide to GDDs names the problem plainly: large, overly detailed documents take heavy upfront work, are almost always out of date, and get restrictive when the design is still shifting. Its fix is staging. Write a one-page document first, a ten-page one when the game takes shape, and the full version only when content is being produced.
That staging matters more for tabletop designers than for video game teams. A TTRPG designer is often the writer, the systems lead and the playtester at once. There is no engineer waiting on a spec. The document has exactly one job: stop you from contradicting yourself between session four and session forty.
Skip the 40-page template if you are working alone. You will not maintain it. Even the standard definition calls a GDD a living document, which means nobody expects it to be finished on day one.
What goes into a game design document template that people actually open?
Five blocks cover the first month of almost any project. Keep each one short enough that you can read the whole page in two minutes.
Pitch. Two sentences. Who plays it, what they do, and what makes it different from the nearest game they already own.
Design pillars. Three or four statements that every later decision gets tested against. "Every combat costs something permanent" is a pillar. "Fun and engaging" is not.
Core loop. The thing a player repeats. In a dungeon crawl it might be explore, choose, risk, spend. In a political campaign it might be intrigue, leverage, consequence, fallout.
Systems list. Names only, with one line each. Do not specify numbers yet.
Open questions. The most useful section on the page, and the one templates leave out. Write down what you do not know, and date it.
Add a change log at the bottom, even if it is only a line per week. When a playtest kills an idea, record the kill and the reason. Future you will otherwise try the same idea again.
How should you write design pillars so they can lose an argument?
A pillar earns its place by vetoing something. If you cannot name a feature that the pillar would reject, it is decoration.
Test each pillar with a cut list. Take the three features you are most attached to and ask which pillar each one serves. A feature that serves none goes on the "maybe later" shelf, and the shelf is allowed to be long. This is the hardest hour of the whole process, and it is worth more than any template section.
Here is a worked example from a campaign setting with a plague at its centre. Pillar one: scarcity is visible, so every healing resource is tracked on the table. Pillar two: factions want different cures, so no single treatment solves everything. Pillar three: the map shrinks, so travel gets more expensive as the story advances. Now a proposal arrives for a resurrection spell. Pillar one rejects it. The decision takes ten seconds instead of a forty-minute debate.
Worth knowing: pillars are not a marketing tagline. They are internal and blunt, and they can sound slightly unflattering. That is fine.
Where does lore belong in a GDD, and where does it get in the way?
Lore is the section that grows fastest and gets read least. Most documents either bury it in a "Story" heading at the bottom or let it swallow the whole file. Neither works.
Split the material by what it does. Lore that changes play, such as a faction's grudge that unlocks a quest or a curse that shapes a class, lives inside the systems it affects. Lore that only sets mood lives in a separate Codex page that nobody needs to open to make a design decision. The test is simple: if deleting the paragraph would not change a mechanic, a roll, or a player choice, it belongs in the Codex.
That split also protects canon. When a fact lives in two places, they drift. Pick one home for each fact and link to it from everywhere else. Canon is a promise, and every inconsistency breaks it.
Designers working on narrative-heavy games often add a short timeline page and a "who knows what" table. Both are cheap. Both save entire sessions of rework when a late revelation has to land correctly.
Which tool should hold your template: Notion, Obsidian or a plain doc?
The tool matters less than whether the document stays in the place you already work. A doc that lives in a tab you never open is a dead doc.
Notion is the default for small teams because pages link to each other, databases hold items and factions, and collaborators need no setup. Ready-made options exist, including a Notion GDD template with sections for controls, game loop, level design and rules. The catch is lock-in and the temptation to build databases for things that do not need them.
Obsidian suits the solo designer who wants plain Markdown files on disk. Backlinks do real work here: link a faction to every scene it appears in and you get a consistency check for free. It survives the vendor disappearing, which matters if the project runs for years.
GitBook works when the document needs to be public or semi-public, for a playtest group or a crowdfunding backer page. A plain Google Doc is fine for a game jam. Skip anything with a heavy permissions model unless a publisher is asking for it.
Whatever you pick, set one rule: the document is updated at the end of every playtest, before anyone goes home. Ten minutes, no exceptions.
What do you add once the prototype survives playtesting?
After three or four sessions with real players, the one-pager earns its next layer. Add sections in this order, and only when the pain shows up.
Systems detail. Numbers, tables, edge cases. Write these as you lock a system, not before. For a TTRPG this is where action economy, damage ranges and resource costs go, along with the rule text as written. For a video game, add the data tables engineers will read.
Content lists. Items, enemies, factions, locations. Use a table with one row per entry and a column for the pillar each one serves. Rows that serve nothing are candidates for cutting.
Interface and flow. Character sheet layout for tabletop, screen flow for digital. Sketch it by hand before you describe it in text.
Production notes. Milestones, scope, risks, what is in the first release and what is not. If you plan to sell the result on DriveThruRPG or Itch.io, this is also where your page copy and price assumptions start.
A pitch or marketing section is a separate document for a separate reader. Publishers and backers want market context and unique selling points. Your playtesters want rules. Mixing them produces a file that serves neither.
Can AI help you write a game design document, and where does it fall short?
It helps with drafts of the boring parts and fails at the parts that matter. Ask a model to expand a systems list into a table of edge cases and you will get a decent first pass in a minute. Ask it to choose your pillars and you will get pillars that sound like every other game. It generates fast. The decisions still need a human pass.
The practical use is consistency checking. Feed it the Codex and the systems list, then ask where two pages contradict each other. Tools built around a long-form story bible, such as Novelcrafter, are designed for this kind of cross-reference. Treat the output as a list of suspects, not a verdict, and check each flag against your own pages.
One firm rule: the model never writes the open questions section. That page is your honest list of what you do not know, and handing it off defeats the point.
What should you skip, and what should you keep?
Skip the full-length template until a mechanic has survived at least three real sessions. Skip the "target audience" essay if you cannot name five actual people who would play. Skip detailed monetization sections for a game that has not found its loop. Skip any section you cannot imagine reading aloud to a collaborator.
Keep the pillars, the open questions and the change log. Those three do most of the work. A document with only them, updated weekly, beats a polished 30-page file nobody has opened since March.
The template is a promise to your future self about what you decided and why. Keep it short enough that you can keep the promise.