Game Design Document Template 2026
A blank one-page game design document you can fill in for your own project in an evening and keep open while you build.
A game design document does not need to be a hundred pages. For a solo developer, a long document is usually a way to avoid building. A single page does the real job: it forces decisions, keeps your scope honest, and tells you what to cut when things slip.
This post gives you a blank one-page template and explains how to fill it in. There is no sample game here. The fields are yours.
Why one page works
One page is short enough to reread every time you sit down to work. That is the point. A design document helps only if you look at it.
It also limits you. If your pitch needs three paragraphs, the idea is not clear yet. If your content list runs off the page, your scope is too big for one person.
Treat the page as a contract with yourself. When you want to add a feature, check the page. If the feature is not on it, either it waits or something else comes off.
How to fill it in
Work through the fields in order. Each one builds on the one before.
Write fast, then cut. Your first pass should take under an hour. Do not polish. Get a rough answer in every field, even a bad one.
Use plain words. Write as if explaining the game to a friend who does not make games. If a field needs jargon, you probably have not decided yet.
Be specific. “Fun combat” is not an answer. “Dodge, then counter-hit during the enemy’s recovery” is.
Leave blanks visible. If you cannot answer a field, leave the brackets in place. An empty field is a question you need to solve, and seeing it is useful.
Keep the out-of-scope list growing. Every time you cut an idea, write it there. It stops the idea from creeping back.
Field-by-field notes
Pitch. One or two sentences. What the player does and why it is interesting. If you cannot say it in two sentences, keep cutting until you can.
Player. Who is this for? Name the kind of player and the games they already enjoy. This helps you make choices about difficulty and pacing.
Core verb. The main action the player repeats. Jump, shoot, place, talk, match. Most good small games have one strong verb. Write it down and protect it.
Camera. Where the camera sits and how it moves. This decision shapes your art, controls, and level design. Decide it early.
Win and lose. How a session ends. What counts as success, and what counts as failure. If there is no failure, say so and say what replaces it.
Scope fence. The hard limits: number of levels, play length, platforms, and the date you want to stop. This is the most important field. Be strict.
Controls. Every input and what it does. If the list is long, the game may be too complex for its size.
Content list. Everything you need to build: levels, characters, enemies, items, sounds, music, screens. Count each one. Small numbers are good.
Risks. What could stop you from finishing. A system you have never built, an art style you have not tested, a feature that depends on a tool you do not know.
Out of scope. Ideas you like but will not build for this version. This field protects your scope fence.
The template
Copy everything below into a document or a plain text file. Replace the brackets with your answers.
Working title
[Placeholder name. You can change it later.]
Pitch
[One or two sentences: what the player does and why it is interesting.]
Player
[Who this is for.]
[Two or three games they already play.]
Core verb
[The main action the player repeats.]
[What makes that action feel good.]
Camera
[View: side, top-down, first person, third person, fixed, other.]
[How it moves and what it follows.]
Win and lose
[How the player wins a session or the whole game.]
[How the player fails, or what replaces failure.]
[What happens after failure.]
Core loop
[Step 1:]
[Step 2:]
[Step 3:]
[Back to step 1 because:]
Scope fence
[Number of levels or areas:]
[Target play length for one full run:]
[Platforms:]
[Stop date:]
Controls
| Input | Action |
|---|---|
| [ ] | [ ] |
| [ ] | [ ] |
| [ ] | [ ] |
| [ ] | [ ] |
Content list
[Levels or areas, with count:]
[Characters, with count:]
[Enemies or obstacles, with count:]
[Items or pickups, with count:]
[Sound effects, rough count:]
[Music tracks, with count:]
[Screens or menus:]
Art and audio direction
[Three words for the look:]
[Three words for the sound:]
[One existing game or artwork that captures the mood:]
Risks
[Risk 1, and how you will test it early:]
[Risk 2, and how you will test it early:]
[Risk 3, and how you will test it early:]
Out of scope
[Idea cut, and why:]
[Idea cut, and why:]
[Idea cut, and why:]
Open questions
[Something you have not decided yet:]
[Something you have not decided yet:]
Keep it alive
Put the page somewhere you see it. Print it, pin it, or keep it in a tab next to your engine.
Reread it at the start of each work session. Ask one question: does what I plan to build today serve this page?
Update it when you learn something. If a playtest shows the core verb needs to change, change the page first, then the game. Date each major revision at the bottom so you can see how the design moved.
When the page and the game disagree, one of them is wrong. Decide which, and fix it.
Common mistakes
Writing the story first. Story matters, but on a one-page document it can push out the decisions that make the game playable. Keep story to a line in the pitch until the core verb works.
Skipping the scope fence. Without limits, the content list grows forever. Fill in the fence before the content list.
Treating it as finished. The first version will be wrong somewhere. That is fine. A design document is a working tool, not a pitch deck.
Adding pages. If you need more detail, keep it in separate notes for specific systems. The one page stays one page.
Fill in the template tonight. Leave blanks where you must. Then open your engine and build the core verb first.
