Game Design Document: A One-Page GDD Template

A game design document, usually shortened to GDD, is the working description of the game you intend to build. For a solo developer or small team, it should fit on one page and answer four things immediately: what the player does, how the game pushes back, what is outside the scope, and what the next playable build must prove.

That is enough to begin. A fifty-page encyclopedia full of lore, future modes, and theoretical upgrade trees may feel serious, but it can hide the one decision the build needs today. I would rather keep a short GDD open beside the editor and update it whenever the playable game disagrees with the plan.

This guide includes a copyable one-page game design document template, a fictional filled example, and a rule for deciding what belongs in the document at all.

What Is a Game Design Document?

A game design document records the current design of a game so the people building it can make consistent decisions. It can describe the player, rules, controls, levels, art, audio, interface, production scope, and release plan. The useful part is not the file format. It is the shared answer to “What game are we making now?”

GDD stands for game design document. Studios can maintain large collections of design pages because different disciplines need detailed specifications. A solo developer usually has a different problem: the document becomes easier to expand than the game.

For a small project, I would treat the GDD as a control surface rather than a novel. Every line should change one of these:

• what enters the next playable build;
• what deliberately stays out;
• how a mechanic is judged;
• what another contributor needs to produce;
• what evidence would make the design change.

If a paragraph changes none of those, it may belong in a private idea notebook, a story outline, an art reference board, or nowhere yet.

The One-Page Game Design Document Template

Copy this into a Markdown file, document, issue, or project note. Keep each answer short enough that you can scan the whole design without searching.

# [Working Game Title]

## One-Sentence Promise
[Player fantasy + core action + pressure]

## Player Action
The player repeatedly:
1. [Action]
2. [Immediate response]
3. [Decision or escalation]

## Win, Loss, and Reset
Win or progress condition: [observable condition]
Loss or failure condition: [observable condition]
What resets: [run, room, score, world state]

## Core Loop
[Start state] -> [player action] -> [game response] -> [new decision]

## Controls and Camera
[Input device, essential inputs, camera behavior]

## Content Multiplier
[One system that creates variation without a new mechanic]

## Scope Boundary
Must ship: [small list]
Explicitly cut: [small list]
Revisit only if: [evidence threshold]

## Visual and Audio Rule
[One useful art constraint]
[One useful audio constraint]

## Next Playable Build
Question: [one uncertainty]
Build contains: [minimum implementation]
Pass signal: [observable result]
Fail signal: [observable result]

## Change Log
[Date] [decision] [evidence or reason]

The template is intentionally uncomfortable if the design is vague. “The player explores a rich world” does not identify an action, response, or loss condition. “The player crosses one dangerous room by moving between pools of light before a timer empties” gives the next build something to implement.

Fill the Promise With a Verb and Pressure

The one-sentence promise is not store copy. It is the shortest useful boundary around the game.

Use this shape:

The player does a concrete verb to reach an observable goal while a system creates pressure.

“A cozy adventure about memories” may be a tone, but it does not yet tell the programmer, level designer, or player what happens. “The player repairs abandoned rooms by placing recovered objects before each memory fades” contains a verb, a goal, and pressure.

I would reject any promise that needs three sentences of exceptions before it can describe the first playable minute. That usually means several possible games are sharing one title.

The promise can change. Its job is to make the current design legible, not trap the project inside an early sentence forever.

Write the Player Action Before the Feature List

A feature list says the game has crafting, dialogue, combat, weather, and procedural levels. It does not say what the player does from moment to moment.

Write the repeated action as a sequence:

1. The player reads a situation.
2. The player chooses an input or resource.
3. The game responds.
4. The response creates the next decision.

Godot's official first 2D game tutorial is useful because it stays concrete. The small project has a moving player, spawning enemies, avoidance, and a score. Scenes, nodes, input, and signals support a complete playable loop rather than a commercial-scale feature catalog.

Your GDD does not need to use Godot. The lesson is the size of the loop. If the first version needs an inventory, branching dialogue, crafting, online accounts, and ten enemy families before the central action can be judged, the design has hidden its riskiest question under production work.

For a smaller start, the guides to making your first game in Godot and building a 2D game turn this planning step into an actual project structure.

Give Failure a Visible Shape

A surprising number of early game ideas describe how the player succeeds but not how the game says no. Without resistance, the core verb is difficult to judge.

The loss condition does not have to mean death. It can be:

• time expires;
• a resource reaches zero;
• an object escapes;
• a route closes;
• the player creates an invalid arrangement;
• an opponent completes its goal;
• the player chooses to end the run and bank a result.

Write what the player sees when the condition occurs and what resets afterward. “You lose when overwhelmed” is an emotion. “The third unblocked enemy reaches the gate; the room resets but collected story fragments remain” is implementable.

I also want the GDD to name what persists. A restart that preserves currency creates a different game from one that erases the run. That decision affects balance, interface, save data, and how failure feels, so it earns a line on the page.

Use One Content Multiplier

A content multiplier creates more situations from a rule you already built. It is not another major system wearing a smaller name.

Examples include:

• one enemy whose speed and route combine with different room layouts;
• one card rule applied to a changing hand;
• one movement ability interacting with several obstacle arrangements;
• one dialogue choice changing who provides the next clue;
• one weather state altering visibility across existing spaces.

The multiplier belongs in the GDD because it explains where replay or variation comes from. It also gives you a scope test. If every new level needs a new mechanic, new art family, new interface, and special-case code, the project is multiplying production rather than content.

I would choose one multiplier until a playable build proves it runs out of interesting combinations. “It might get repetitive” is not yet evidence that three more systems are necessary.

Make the Cut List as Real as the Must-Ship List

The scope boundary is the most valuable part of the one-page GDD. A must-ship list without a cut list simply gives new ideas somewhere to land.

Use three columns:

The third column prevents a cut from becoming a disguised promise. “Maybe later” is weak because enthusiasm alone can reopen it. “Revisit only if five observed sessions fail for the same reason” creates an evidence threshold.

Do not use arbitrary thresholds when no measurement makes sense. A technical requirement, platform rule, accessibility need, or repeated observed failure can also justify reopening scope. The point is to name the trigger before the feature becomes emotionally expensive to cut.

End Every Version With the Next Playable Question

A GDD becomes stale when it describes an imagined final game while production works on something else. The Next Playable Build section keeps the document connected to the executable project.

Write one question, not a sprint backlog:

• Is moving between cover points readable without a tutorial?
• Does choosing a heavier tool create a meaningful timing tradeoff?
• Can two players tell which one has authority over the shared object?
• Does the menu remain navigable with only a controller?
• Is the loss condition visible before it feels arbitrary?

Then describe the minimum build that can answer it. Grey boxes are acceptable. Placeholder audio is acceptable. A second level, settings screen, progression tree, and polished trailer are not required unless the question depends on them.

Define a pass and fail signal before running the build. “Feels good” can be part of a designer's judgment, but an observable signal is easier to discuss. For example: “A fresh player reaches the first cover point without being told where it is” is clearer than “movement is intuitive.”

The next build should kill uncertainty. It does not need to preserve every line of code.

A Filled Fictional GDD Example

This example describes an invented small game called Last Lantern. It is a demonstration, not a shipped project or a claimed playtest.

One-Sentence Promise

The player carries a fading lantern through one flooded ruin, choosing which safe platforms to illuminate before darkness closes the route home.

Player Action

The player aims the lantern at a platform, spends light to reveal its route, then commits to a jump while the remaining darkness changes which return paths are possible.

Win, Loss, and Reset

The run succeeds when the player retrieves one relic and returns to the entrance. The run fails when the lantern empties while the player stands outside a lit platform. The room resets; the best completed route time remains locally.

Core Loop

Read the dark room, illuminate one platform, move, collect a small light refill, then decide whether to press toward the relic or preserve a return route.

Controls and Camera

Left stick or movement keys move. Right stick or mouse aims the lantern. One action commits the jump. A fixed angled camera keeps the entrance and next two platform choices visible.

Content Multiplier

The same platform rule combines with different distances, refill positions, and one-way current directions.

Scope Boundary

Must ship: one ruin, one relic, one complete return trip, keyboard and controller input, restart, and local best time.

Explicitly cut: combat, inventory, character upgrades, procedural generation, online leaderboard, voice acting, and a second biome.

Revisit only if: the lantern route becomes legible and satisfying but repeated layouts cannot create a harder decision.

Next Playable Build

Question: can a player understand that illuminating a platform spends the same resource needed to return?

Build contains: five grey platforms, one lantern meter, one refill, one relic, one loss state, and restart.

Pass signal: the player hesitates before spending the final safe unit of light and can explain why.

Fail signal: the player treats light as a cosmetic aiming beam or loses without connecting the loss to the earlier spend.

The example is small enough to argue with. That is a feature. If the first build shows the resource is confusing, the GDD can change before anyone produces finished ruins, dialogue, or a progression system.

When to Update the GDD

Do not schedule a ceremonial rewrite every Friday. Update the document when the game's current truth changes.

Good triggers include:

• a playable build disproves the stated loop;
• a platform requirement adds a real constraint;
• a cut feature becomes necessary for a documented reason;
• a core control changes;
• the win, loss, or persistence rule changes;
• production capacity forces a scope decision;
• a contributor cannot make a decision from the current page.

Add a one-line change log with the date, decision, and evidence. Do not silently rewrite history. “Removed free camera after the room test lost the next route off-screen” preserves why the fixed camera exists. Six weeks later, that note prevents the team from reopening the same debate as if it were new.

Version numbers are optional. Reasons are not.

What Belongs Outside the One-Page GDD?

The one-page document should link outward when a specialist needs detail that would make the core design unreadable.

Useful companion artifacts can include:

• a control map;
• a level-flow diagram;
• an art reference board;
• a narrative beat sheet;
• an accessibility checklist;
• an audio cue list;
• a technical architecture note;
• a release checklist;
• a task board.

Keep one owner for each fact. If the one-page GDD says the jump uses one button while a control sheet says two, the team now has two sources of truth. The GDD can summarize the decision and link to the detailed artifact.

Godot itself is released under the MIT license and can be used for commercial games. The engine's official license page also explains that your game content remains under the terms you choose, while a distributed Godot binary still requires the engine's copyright and license notice. That licensing note belongs in a release or technical artifact unless it changes the design being discussed.

My Five-Minute GDD Review

I would review the page before opening a long new branch of work, not after the branch is already expensive. Five minutes is enough to expose a surprising amount of design drift when the questions are concrete.

First, I cover the working title and read only the one-sentence promise, player action, and win or loss rules. I ask whether those three sections describe the same game. If the promise sells careful exploration, the action describes rapid combat, and the loss rule rewards hoarding, I do not solve that contradiction by adding lore. I choose which behavior the build should test and rewrite the other lines around it.

Second, I compare the must-ship and cut lists against the actual task board. Any active task that appears on neither side is ungoverned scope. I either move it under must ship with a reason, place it behind a revisit condition, or remove it from the current work. I would pay special attention to tasks labeled foundation, framework, future-proofing, or polish because those names can make optional systems sound unavoidable without saying what playable question they answer.

Third, I read the next-build question and imagine deleting each planned element. If the question can still be answered without a settings menu, second enemy, final art pass, save system, or elaborate level, I cut that element from this build. The prototype may eventually need it. This test asks whether it needs it now.

Fourth, I look for a pass signal that the builder can observe and a fail signal that permits a design change. I distrust a test where every outcome can be narrated as promising. If nobody can describe what would make us abandon the mechanic, the build is demonstrating commitment rather than reducing uncertainty.

Finally, I add one change-log line when the review alters a decision. I do not write meeting minutes. I record the choice and the evidence that could matter when the same idea returns later.

That is the whole review. Read for contradiction, expose ungoverned work, delete anything the next question does not need, make failure informative, and preserve the reason for a change.

Questions a GDD Should Answer

Before calling the page usable, hand it to someone who has not heard the pitch and ask whether they can answer:

1. What does the player do in the first minute?
2. What creates the next decision?
3. How does a run or level end?
4. What changes after failure?
5. What creates variation without a new major system?
6. Which tempting features are currently cut?
7. What single question does the next build answer?
8. What result would change the design?

If the answers require a live explanation from the designer, write down the missing decision. If they require thirty more pages, the game may still contain several competing scopes.

There is no mandatory seven-stage structure that every game design document must follow. Different teams separate concept, preproduction, production, testing, release, and live work in different ways. A GDD should match the decisions its builders need, not a ceremonial stage count copied from a course outline.

Age does not change the template either. Starting game development at 30, 40, or any other age does not require a different core loop. Available time, responsibilities, skills, and project size affect scope; the birth year does not belong in the design document.

Keep the Document Close to the Build

Name the file plainly. Put it where the project team already looks. Link the current playable build or task from it. Review the next-build question before starting a large asset or system.

I would archive abandoned ideas outside the page rather than letting them crowd the active scope. Deleting a line from the current GDD does not mean the idea was worthless. It means the idea is not allowed to spend this project's time without earning its way back through evidence.

A useful game design document does not predict the finished game perfectly. It makes today's build coherent, exposes the riskiest assumption, and records why the team changed course.

Start with one page. Write the player action, resistance, loss, scope boundary, and next playable question. Then open the engine and make the document answer to the game.