Game Design Document Template: Start With One Page

You need a game design document template that fits on one page, then grows only when the game earns it. Start with seven blocks: pitch, core loop, player verbs, world, systems, scope, and open questions. Fill them in an evening. Cut anything you cannot test in a prototype this month. The rest of this post is the template itself, plus the parts most guides skip.

Why most game design documents die in week two

Picture the 40-page GDD. Beautiful cover, a table of contents, a lore chapter nobody asked for. By week two the prototype has drifted and the document is a fossil.

That is the real failure. Not missing sections, but a file that stops being true. A GDD is a working tool, closer to a changelog than a bible. If the doc and the build disagree, the doc loses, and people stop opening it.

So the question is not "what should a game design document contain?" It is "what is the smallest document I will actually keep honest?"

The one-page game design document template

Copy this outline. Each block gets two to five lines, never more on the first pass.

1. Pitch. One sentence a stranger could repeat. "A co-op harbor town where the tide rewrites the map every night."

2. Core loop. What the player does, over and over, in under a minute. Draw it as a circle of verbs.

3. Player verbs. Five to eight actions. Not features. Verbs: climb, trade, hide, fork, repair.

4. World. Place, mood, three rules that are always true. Weather counts as a rule.

5. Systems. The two or three mechanisms that make the verbs interesting. Economy, stealth, crafting, whatever carries the loop.

6. Scope. What ships, what is cut, what is a stretch. Put a date next to each.

7. Open questions. The honest list of things you do not know yet. This block is the most valuable one on the page.

Notice what is missing: monetization, marketing plan, a character backstory chapter. They belong in separate files, written when the prototype proves the loop. Most published templates start with them, which is exactly why those documents never get finished.

If you want a longer structure for a team that needs sign-off, the GitBook guide to writing a game design document lays out the classic chapter list, and its advice to start from a one-page version and add detail as prototypes prove out is the right instinct.

What a core loop section should actually say

Skip adjectives. Write the loop as a sentence with a timer.

Scavenge for 40 seconds -> carry salvage to the pier -> trade for one upgrade -> tide shifts, map changes -> repeat

Now read it out loud. If one step feels dead, you found your first prototype task. If every step sounds fine but you cannot say why the player returns, the loop is missing a reason. Add it as an open question instead of burying it under prose.

One test I like: the loop sentence must fit in a single line of text. If it needs a paragraph, it is two loops, and you are designing two games.

Which sections can you cut without regret?

Be ruthless. A solo or two-person project can usually drop these on day one:

• Full character bios. Keep a name, a want, a flaw. Write more when the character appears in a build.

• Detailed level descriptions. Describe level rules, not rooms.

• Platform and monetization chapters. Park them until the loop works.

• Art bible. Three reference images and a palette. That is it.

Skip if you are shipping a jam game in 72 hours: the pitch, loop, and verbs are your entire document. Worth keeping the full list if you have a publisher, a console certification path, or contractors who cannot ask you questions at midnight.

The Unity game design document template PDF is a decent reference for how mechanics and object behavior get written down once a team is involved. Read it as a catalogue, not a checklist.

Where should you keep the document?

Wherever you will edit it daily. That sounds obvious until you see how many GDDs live in a PDF nobody can diff.

Pick a tool that gives you headings, a database for tasks, and version history. A database-backed notes app works well, because your open questions and scope list can become tracked items instead of bullet points that rot.

Plain Markdown in the repo is the other good answer. It lives next to the code, it diffs cleanly, and nobody forgets to update it during a pull request. The cost is that non-technical teammates will not touch it.

Whichever you choose, put the one-pager at the top and link out to deeper files. The page is the map. The files are territory.

Does your engine change what you write down?

A little, yes. The engine decides which verbs are cheap and which are expensive, so your systems and scope blocks should say it plainly.

If you are in a full 3D engine with a large asset pipeline, scope needs a line for every asset category, because content is where schedules go to die.

If you want an open-source engine with no royalty math to track, your scope block gets simpler: no licensing line, but a real note on which features you will build yourself.

And if the game is 2D with tight mechanics, the loop section carries almost everything. Small, readable documents suit small, readable games.

The point is not to pick a winner here. The point is that "Engine and tools" is not a throwaway line. It should list what the engine makes easy, what it makes painful, and what you will refuse to build.

How do you write a GDD for a world that generates itself?

This is the gap in nearly every template. They assume you place every tree by hand.

When a world is generated from a prompt, the design document changes shape. You are no longer specifying rooms. You are specifying constraints: what must be true in every world the engine can produce, and what is allowed to vary.

Add two blocks to the one-pager:

• World constraints. The rules that cannot break. "Every settlement has water within two minutes of walking." "No dead-end quest locations."

• Prompt seeds. The exact prompts you used, saved as part of the document.

Here is what a seed looks like in practice:

a foggy harbor town at low tide, one lighthouse, narrow stairs, rope bridges between rooftops, nobody in sight yet

Save the prompt, save what came back, and note what you would fork. The prompt is your spec and your changelog at the same time. Fork it, change one thing, see what happens, then write the delta in the doc. That habit turns a generated world into something you can reason about, and it gives teammates something concrete to critique instead of a vibe.

A caution: generation quality varies a lot between tools, and some features are still in beta across the industry. Write down the version and date next to every seed, so you know whether a result is repeatable or a lucky roll.

A fast way to test the loop before you write more

Here is the evening workflow I would run on a fresh idea.

1. Write the one-pager in 30 minutes. Do not edit it.

2. Turn the pitch and three world rules into a prompt, and generate a first pass of the space.

3. Walk through the core loop in that space, by hand or in a rough prototype.

4. Mark every step that felt dead. Those go into open questions.

5. Cut one verb. Always cut one.

The cut is the part people skip. A design doc that only ever grows is a wish list. Removing a verb forces the remaining ones to carry more weight, and it usually exposes which system was doing real work.

How do you keep the document alive after week two?

Three habits, none of them heroic.

Date every open question. If a question is older than three weeks and still open, either answer it or admit you are avoiding it.

Update the doc in the same sitting as the build. Not later. Later is how the fossil forms. A two-line edit at the end of a session costs a minute.

Keep a "killed ideas" list at the bottom. It saves you from re-debating the same mechanic every month, and it is oddly motivating to see how much you shipped by saying no.

When someone new joins the project, hand them the one-page version first and watch where they get confused. Every confused question is a missing line in the doc.

What would we actually use?

If you are alone or in a pair, the seven-block one-pager plus a prompt-seed list is enough for the first month. If you have a team, keep the one-pager as the front door and add separate files for systems and content as the prototype justifies them. If you have a publisher, give them the long version, but keep your one-pager as the version you trust.

Open a blank page tonight and write the pitch. One sentence. Then the loop, with a timer on it. If you cannot finish that in half an hour, the idea is still a dream, and that is useful to know before you spend a month on it.