# Game design document template

Nine linked documents that cover a game from its pitch to its decision log, each with guidance on what to write and a short example. Download them as Markdown files: they open in any editor, show their diagrams on GitHub and in Obsidian, and import into Nodary as a map.

Free, no account, no email. Use it, change it, share it.

[Download the template (.zip)](https://nodary.ai/downloads/game-design-document-template.zip)

## Read every page before you download

The overview fits on one screen and links to eight parts, one per discipline, so each part has an owner and a change stays small. Italic lines say what to write; the examples come from Saltmarrow, the sample game this site uses everywhere.

- Game design document: The page everyone reads first: pitch, pillars, audience, scope, and a link to every part.
- Gameplay: What the player does from one minute to the next, and why they keep doing it.
- Systems and economy: Every system, the rules it follows, the resources it moves and the numbers behind it.
- World, story and characters: The setting and its rules, the story the player lives through, and the people in it.
- Levels and content: Every place the player goes, the first hour, and how much content the release needs.
- Art and audio direction: How the game looks and sounds, precisely enough that two artists working apart still match.
- Interface and accessibility: Screens, HUD and input, and how the game adapts to every player.
- Technical design: Engine, targets, architecture and pipeline, and the limits they set on the design.
- Production plan: Milestones, team, risks, and the log of every decision that changed the design.

### Game design document

_How to use this template: italic lines are guidance. Replace them with your own words, then delete them. Values in square brackets are yours to fill in. Keep this page to about one screen: it is the page everyone reads first, and every other part of the design is one link away._

#### At a glance

| Field | Your game |
| --- | --- |
| Working title | [Title] |
| Logline | [One sentence a stranger could repeat] |
| Genre | [Genre and subgenre] |
| Players | [Single player, co-op for 2 to 4, competitive] |
| Platforms | [PC, consoles, mobile] |
| Session length | [A typical session, in minutes] |
| Engine | [Engine and version] |
| Team | [Size today and at its largest] |
| Business model | [Price, free to play, subscription] |
| Next milestone | [Name and date] |

#### Pitch

_Two or three sentences: who the player is, what they do, and what makes the game different. Write it so it would still work on a store page._

_Example (Saltmarrow, a sample game): Rake salt, dive for memories, beat the tide home. A co-op exploration and crafting game for up to four players, set on tidal salt flats where a drowned archive city surfaces twice a day._

[Your pitch]

#### Design pillars

_Three to five rules every feature must serve. A pillar that could describe any game, such as “fun combat”, is not a pillar. A feature that serves no pillar is cut; a feature that breaks one is redesigned._

1. **[Pillar one]**: [what it means, in one sentence]
2. **[Pillar two]**: [what it means, in one sentence]
3. **[Pillar three]**: [what it means, in one sentence]

_Example (Saltmarrow, a sample game): The tide is the clock. Time is the only resource that never grows: every system reads the tide, and nothing pauses it._

#### Audience

_Who the game is for, what they play today and when they stop playing. Name real games and real habits, not only an age bracket._

- Primary players: [who they are and how they play]
- What they play today: [three or four games]
- They stop playing when: [...]
- Secondary players: [...]

#### Comparable games

_Three or four games your team and your players already know. Say what you take from each and, just as useful, what you leave._

| Game | What we take | What we leave |
| --- | --- | --- |
| [Game] | [...] | [...] |
| [Game] | [...] | [...] |
| [Game] | [...] | [...] |

#### Scope

_What the first release contains, and what it explicitly does not. The second list is the one that keeps scope from growing quietly._

- In the first release: [...]
- Not in the first release: [...]
- To be decided later: [...]

#### The rest of the design

_Each part is its own document. Link to it rather than copy from it, so every fact lives in one place and changes in one place._

- [Gameplay](https://nodary.ai/templates/game-design-document#gdd-gameplay): the core loop, mechanics, controls and progression
- [Systems and economy](https://nodary.ai/templates/game-design-document#gdd-systems): every system, its rules and its numbers
- [World, story and characters](https://nodary.ai/templates/game-design-document#gdd-world): the setting, the story and the people in it
- [Levels and content](https://nodary.ai/templates/game-design-document#gdd-levels): every place, the first hour and the content budget
- [Art and audio direction](https://nodary.ai/templates/game-design-document#gdd-art): how the game looks and sounds
- [Interface and accessibility](https://nodary.ai/templates/game-design-document#gdd-interface): screens, HUD, input and accessibility
- [Technical design](https://nodary.ai/templates/game-design-document#gdd-technical): engine, targets, architecture and pipeline
- [Production plan](https://nodary.ai/templates/game-design-document#gdd-production): milestones, team, risks and the decision log

_This template is free to use, change and share. It comes from_ [Nodary](https://nodary.ai)_, where these files import as a map of linked documents._

### Gameplay

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_What the player does from one minute to the next, and why they keep doing it. Start with the loop: everything else in this document hangs from it._

#### Core loop

_The loop the player repeats most, in four to six verbs. If the team cannot draw it, it is not settled yet._

```mermaid
flowchart LR
  n0["Plan"]
  n1["Explore"]
  n2["Collect"]
  n3["Craft"]
  n4["Upgrade"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n3 --> n4
  n4 --> n0
```
_The core loop, about [n] minutes per cycle_

| Beat | Typical time | The player’s question |
| --- | --- | --- |
| [Plan] | [2 min] | [Which goal this time, and what do I bring?] |
| [Explore] | [...] | [...] |
| [Collect] | [...] | [...] |

_Example (Saltmarrow, a sample game): Harvest or dive, 8 to 14 minutes: rake safe salt, or dive for crystals that might be worth more? Every beat should ask the player a question. A beat without one is a chore._

#### Mechanics

_One row per mechanic. The pillar column keeps each one honest: a mechanic that serves no pillar goes on the cut list._

| Mechanic | What the player does | Pillar it serves | Status |
| --- | --- | --- | --- |
| [Mechanic] | [...] | [...] | [idea, prototyped, locked] |
| [Mechanic] | [...] | [...] | [...] |

#### Controls

_The player’s verbs and how each one should feel. The button mapping for each device lives in_ [Interface and accessibility](https://nodary.ai/templates/game-design-document#gdd-interface).

- [Verb]: [how it is performed, and how it should feel]
- [Verb]: [...]

#### Progression

_What grows during a session and across the whole game, and how the player sees it grow. Name the long-term goal._

- Within a session: [...]
- Across sessions: [...]
- Long-term goal: [...]

#### Challenge and failure

_How difficulty rises, what failing costs and how the player gets back in. A failure that only costs time teaches less than one that costs a choice._

- Difficulty rises through: [...]
- Failing costs: [...]
- Getting back in: [...]

_Example (Saltmarrow, a sample game): A diver still in the archive when the horn sounds loses the crystals in their satchel and surfaces at the nearest tower, keeping their salt._

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [Game design document](https://nodary.ai/templates/game-design-document#gdd-overview) · [Systems and economy](https://nodary.ai/templates/game-design-document#gdd-systems) · [Levels and content](https://nodary.ai/templates/game-design-document#gdd-levels)

### Systems and economy

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_Every system in the game, the rules it follows and the numbers behind it. Numbers change every week: keep them in tables or spreadsheets, and keep the reasoning here._

#### Systems

_One row per system. A system that feeds nothing is decoration. A system that everything feeds into is the spine of your game, and deserves a document of its own._

| System | What it does | Reads from | Feeds into | Owner |
| --- | --- | --- | --- | --- |
| [Crafting] | [...] | [Inventory] | [Upgrades] | [name] |
| [System] | [...] | [...] | [...] | [...] |

_Example (Saltmarrow, a sample game): Every system reads the tide: harvest yields, storm odds, prices in the village, even how long a character is willing to talk._

#### Resources and currencies

_For each resource, where it comes from (sources) and where it goes (sinks). An economy with more sources than sinks inflates: fill in both columns before tuning anything._

| Resource | Sources | Sinks | Cap |
| --- | --- | --- | --- |
| [Gold] | [...] | [...] | [none, or a number] |
| [Resource] | [...] | [...] | [...] |

#### Rewards and drop rates

_Loot tables, reward chances and any pity rule. Say what a player should expect: how many tries until half of players have an item, and until nine in ten do. The free_ [drop rate calculator](https://nodary.ai/tools/drop-rate-calculator) _works this out from a table of weights._

| Reward | Weight | Chance per try | Guaranteed by |
| --- | --- | --- | --- |
| [Item] | [...] | [...] | [none, or try n] |
| [Item] | [...] | [...] | [...] |

#### Tuning knobs

_The few values a designer changes to make the game easier, faster or more generous, with the current value and the range already tested. When one changes, note why in the decision log of the_ [production plan](https://nodary.ai/templates/game-design-document#gdd-production).

| Knob | Current value | Range tested | Affects |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [Gameplay](https://nodary.ai/templates/game-design-document#gdd-gameplay) · [Levels and content](https://nodary.ai/templates/game-design-document#gdd-levels) · [Production plan](https://nodary.ai/templates/game-design-document#gdd-production)

### World, story and characters

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_The world’s rules, the story the player lives through, and the people in it. Lore that never reaches the player belongs in documents of its own, linked from here._

#### Setting

_Where and when, in three sentences, and the one rule of this world that the player feels in play._

_Example (Saltmarrow, a sample game): A library city that tried to outlast the sea by growing salt. It worked: the salt kept the books and drowned the readers. Twice a day, the tide uncovers it._

[Your setting]

#### Tone

_Three words, each with a game, film or book that sets the bar. Then what the tone is not: it settles more arguments than what it is._

- Tone: [...]
- References: [...]
- Never: [...]

#### Story outline

_The story as the player experiences it, beat by beat, rather than the backstory. Note how each beat reaches the player: a cutscene, a line of dialogue, an object found, the level itself._

| Beat | What happens | How the player learns it |
| --- | --- | --- |
| [Opening] | [...] | [...] |
| [Turning point] | [...] | [...] |
| [Ending] | [...] | [...] |

#### Characters

| Character | Role in play | What they want | Their voice in one line |
| --- | --- | --- | --- |
| [Name] | [guide, merchant, rival] | [...] | [...] |
| [Name] | [...] | [...] | [...] |

_Once a character has more than a few lines, give them a document of their own (a profile, references, sample dialogue) and link it from this table._

#### Writing rules

_The conventions every writer follows: names and spellings, words this world never uses, the longest line that fits on screen. Written early, they save the localisation team weeks._

- [Rule]
- [Rule]

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [Game design document](https://nodary.ai/templates/game-design-document#gdd-overview) · [Levels and content](https://nodary.ai/templates/game-design-document#gdd-levels) · [Art and audio direction](https://nodary.ai/templates/game-design-document#gdd-art)

### Levels and content

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_Every place the player goes and every piece of content the game needs, with how much of each. This list becomes the production backlog, so keep the counts honest._

#### Places and levels

| Place or level | Purpose in the game | Main mechanics | Length | Status |
| --- | --- | --- | --- | --- |
| [Tutorial area] | [teach movement and the core loop] | [...] | [10 min] | [blockout, art pass, final] |
| [Place] | [...] | [...] | [...] | [...] |

#### Level design rules

_Rules that hold in every level: how the player is guided, how far apart checkpoints are, how secrets are signalled. Write them once here rather than in each level._

- [Rule]
- [Rule]

#### The first hour

_The player’s first hour, step by step: what they do, what they learn, and the first moment they would tell a friend about. Most players who quit, quit here._

| Minutes | What the player does | What they learn |
| --- | --- | --- |
| 0 to 5 | [...] | [...] |
| 5 to 15 | [...] | [...] |
| 15 to 60 | [...] | [...] |

#### Content budget

_How many of each kind of content the first release needs, and who makes it. Check it against the_ [production plan](https://nodary.ai/templates/game-design-document#gdd-production) _before anyone starts building._

| Content | Count | Made by | Notes |
| --- | --- | --- | --- |
| [Levels or areas] | [...] | [...] | [...] |
| [Characters and creatures] | [...] | [...] | [...] |
| [Items] | [...] | [...] | [...] |
| [Lines of dialogue] | [...] | [...] | [...] |
| [Music tracks] | [...] | [...] | [...] |

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [Gameplay](https://nodary.ai/templates/game-design-document#gdd-gameplay) · [World, story and characters](https://nodary.ai/templates/game-design-document#gdd-world) · [Production plan](https://nodary.ai/templates/game-design-document#gdd-production)

### Art and audio direction

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_How the game looks and sounds, precisely enough that two artists working apart produce work that fits together._

#### Visual rules

_Three to five rules about shape, colour, light and detail. “Stylised” is not a rule; “every silhouette reads at thirty metres” is._

- [Rule]
- [Rule]
- [Rule]

#### References

_Add reference images under each rule, and say what to take from each one: the palette, the light, the shapes. Never “everything”._

| Reference | What we take | What we avoid |
| --- | --- | --- |
| [Image or game] | [...] | [...] |
| [Image or game] | [...] | [...] |

#### Palette

| Use | Colour | Notes |
| --- | --- | --- |
| [Background] | [#hex] | [...] |
| [Danger] | [#hex] | [never the only way danger is shown] |

#### Asset families

_What each family of assets has in common, its budget (polygons, texture size, frames) and who approves it._

| Family | Style notes | Budget | Approved by |
| --- | --- | --- | --- |
| [Characters] | [...] | [...] | [...] |
| [Environments] | [...] | [...] | [...] |
| [Props] | [...] | [...] | [...] |
| [Effects] | [...] | [...] | [...] |

#### Audio

_The mood of the music, the sound effects and the voices, and the game information that sound carries: warnings, rewards, the passing of time._

- Music: [...]
- Sound effects: [...]
- Voice: [languages and number of lines, or none]
- Information carried by sound: [...]

_Example (Saltmarrow, a sample game): Two minutes before the tide turns, a horn sounds across the flats. The tide is shown on screen, heard in the mix and felt through the controller._

#### Reviews

_Who approves art and audio, and when. Keep feedback on the picture itself, pinned to the spot it is about: it saves a round of “which one, on the left?”_

- Art is approved by: [...]
- Audio is approved by: [...]

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [World, story and characters](https://nodary.ai/templates/game-design-document#gdd-world) · [Interface and accessibility](https://nodary.ai/templates/game-design-document#gdd-interface)

### Interface and accessibility

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_Everything the player reads, presses and navigates, and how the game adapts to players who see, hear or move differently._

#### Screens and flow

_Every screen, and how the player moves between them from launch to quitting. A diagram finds the dead ends before they are built._

```mermaid
flowchart LR
  n0["Title screen"]
  n1["Main menu"]
  n2["Play"]
  n3["Settings"]
  n4["Pause"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n2 --> n4
  n4 --> n2
  n4 --> n1
```
_Screen flow_

#### HUD

_What stays on screen during play, and why each element earns its place. Anything the player checks less than once a minute can live in a menu._

| Element | Shows | When it is visible | Priority |
| --- | --- | --- | --- |
| [Health] | [...] | [always, in combat, on request] | [high, medium, low] |
| [Element] | [...] | [...] | [...] |

#### Input

| Action | Keyboard and mouse | Controller | Touch |
| --- | --- | --- | --- |
| [Move] | [WASD] | [Left stick] | [...] |
| [Interact] | [E] | [A / Cross] | [...] |
| [Pause] | [Esc] | [Start / Options] | [...] |

#### Accessibility

_Tick each item, or write why it does not apply. Decided early, most of them cost little; added late, they cost a lot._

- [ ] Every input can be remapped
- [ ] Hold actions can be switched to toggles
- [ ] Subtitles show who is speaking, and their size can be changed
- [ ] Important sounds also have a visual cue
- [ ] No information is carried by colour alone
- [ ] Text can be made larger
- [ ] Timers can be slowed down or turned off
- [ ] Camera shake and flashing can be reduced

#### Text and languages

_The languages at launch, and the rules that keep translation possible: no text baked into images, room for text up to a third longer than English, fonts that cover every script you ship._

- Languages at launch: [...]
- Languages later: [...]
- Fonts: [...]

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [Gameplay](https://nodary.ai/templates/game-design-document#gdd-gameplay) · [Art and audio direction](https://nodary.ai/templates/game-design-document#gdd-art) · [Technical design](https://nodary.ai/templates/game-design-document#gdd-technical)

### Technical design

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_The technical choices that shape the design, and the limits the design must respect. Detailed architecture can live in engineering documents linked from here._

#### Engine and tools

| Choice | Decision | Why |
| --- | --- | --- |
| Engine | [Engine and version] | [...] |
| Programming languages | [...] | [...] |
| Version control | [...] | [...] |
| Builds and distribution | [...] | [...] |

#### Targets and budgets

_The numbers every department builds against. Without them, performance problems are discovered at the end._

| Platform | Frame rate | Resolution | Memory | Loading time | Install size |
| --- | --- | --- | --- | --- | --- |
| [PC, minimum specification] | [...] | [...] | [...] | [...] | [...] |
| [Console] | [...] | [...] | [...] | [...] | [...] |

#### Architecture

_The main parts of the game’s code and how they talk to each other. A diagram of five boxes beats five pages of prose._

```mermaid
flowchart TD
  n0["Input"]
  n1["Game state"]
  n2["Rendering"]
  n3["Audio"]
  n4["Saves"]
  n0 --> n1
  n1 --> n2
  n1 --> n3
  n1 --> n4
```
_Main systems_

#### Saves and online

- Saves: [what is saved, when, and where]
- Online: [none, peer to peer, dedicated servers]
- Player data: [what is collected, and where it is kept]

#### Pipeline

_How an asset or a line of text goes from its author to a playable build, and how long that takes. A slow pipeline quietly cuts the number of iterations a team gets._

[Your pipeline]

#### Technical risks

| Risk | Impact | What we do about it | Owner |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [Interface and accessibility](https://nodary.ai/templates/game-design-document#gdd-interface) · [Production plan](https://nodary.ai/templates/game-design-document#gdd-production)

### Production plan

**Owner:** [name] · **Status:** draft · **Last reviewed:** [date]

_When the game ships, who makes it, what could stop it, and every decision taken along the way._

#### Milestones

| Milestone | Date | Goal | Done when |
| --- | --- | --- | --- |
| [Prototype] | [...] | [the core loop is fun] | [...] |
| [Vertical slice] | [...] | [one level at final quality] | [...] |
| [Alpha] | [...] | [every feature in, roughly] | [...] |
| [Beta] | [...] | [all content in, fixing only] | [...] |
| [Release] | [...] | [...] | [...] |

_“Done when” is the column people skip. Without it, a milestone is only a date._

#### Team

| Role | Person | Owns these documents |
| --- | --- | --- |
| [Creative director] | [name] | [Game design document, Gameplay] |
| [Role] | [name] | [...] |

#### Risks

| Risk | Likelihood | Impact | What we do about it | Owner |
| --- | --- | --- | --- | --- |
| [...] | [low, medium, high] | [low, medium, high] | [...] | [...] |

#### Decision log

_Every decision that changes the design: what was decided, by whom, why, and which document changed. Six months later, when someone asks why it works this way, this table answers._

| Date | Decision | Decided by | Why | Document changed |
| --- | --- | --- | --- | --- |
| [date] | [...] | [...] | [...] | [...] |

_Example (Saltmarrow, a sample game): 12 September: no combat, the threat comes from the tide and storms only. Decided by the creative director and the systems designer, to keep the game calm and its deadline sharp. Document changed: the design pillars._

#### Open questions

- [ ] [Question], [who answers it], [by when]

Related: [Game design document](https://nodary.ai/templates/game-design-document#gdd-overview) · [Levels and content](https://nodary.ai/templates/game-design-document#gdd-levels) · [Technical design](https://nodary.ai/templates/game-design-document#gdd-technical)

## How to use it

### Write the overview in one sitting

Fill in the table, the pitch and the pillars first, in about an hour, with the people who will build the game. Every other page is judged against them.

### Fill the parts as decisions are made

Leave a section empty rather than invent it. An empty section is an honest open question; an invented one gets built.

### Log every decision

When a decision changes the design, add a line to the decision log in the production plan and update the page it affects. The log says why; the page says what is true now.

### Give every page an owner

Each part names its owner and the date it was last reviewed. A page that nobody owns is the first to go stale.

## Import it into Nodary as a map

Nodary is a workspace for game teams where documents are linked like stars on a map. Import the .zip and the overview arrives with its eight parts filed under it, the links between pages kept and the diagrams drawn. Your team then comments on passages, asks for reviews and sees what changed since their last visit, and AI agents connected over MCP read the design before they write in it.

1. Open a project’s map and choose Import.
2. Choose the Folder or ZIP tab, then Choose a ZIP.
3. Pick the downloaded file, check the tree, and import.

The free plan holds ten documents per workspace, the project’s own page included: the template’s nine fit in a new workspace and fill it. Paid plans have room for more.

## Writing a GDD people actually read

A game design document fails in one of two ways: nobody reads it, or everyone reads an old version. These habits prevent both.

### One page per part

A sixty-page file is read once, at the start. Short linked pages are read when they matter, and a change touches one page instead of five.

### Write decisions, not wishes

“Combat should feel good” decides nothing. “A hit lands within 100 milliseconds of the button press” can be built and tested.

### Say what is still open

Mark unanswered questions as open, with who answers them and by when. A guess written as a fact is how two departments end up building two different games.

### Link, never copy

When the economy page needs the tide timings, link to them. A fact written in two places soon says two different things.

### Keep the why

The decision log records why things are the way they are, so a new teammate does not undo a choice the team has already paid for.

### Cut what nobody reads

If a section has not been opened since it was written, merge it or delete it. A short document that is true beats a long one that was.

## Questions about game design documents

### What is a game design document?

A game design document, or GDD, describes the game a team is making: its pitch, pillars, mechanics, systems, world, levels, look and sound, and the plan to build it. Designers, artists, programmers, producers and, more and more, AI agents read it, so it has to stay current while the game changes.

### What should a game design document include?

At least a one-page overview with the pitch, pillars, audience and scope; the gameplay and core loop; the systems and their numbers; the world and story; levels and content; art and audio direction; interface and accessibility; the technical constraints; and a production plan with a decision log. This template has one document for each.

### How long should a GDD be?

As short as it can be while still answering the team’s questions. The overview should fit on one screen. Each part grows with the decisions taken, not with the hopes: a page of settled rules beats ten pages of possibilities.

### Do indie and agile teams still need a GDD?

They need the decisions written down, not a bible written up front. Teams that iterate quickly use the GDD as the record of what the game is today: short pages, updated when a playtest changes something, with the reasons kept in the decision log.

### Which format is the template in?

Markdown: plain text files that any editor opens. Links between documents are relative links, tables are Markdown tables, and diagrams are Mermaid, which GitHub, Obsidian and Nodary draw. Nothing depends on one particular tool.

### Can I use it in Obsidian, on GitHub or in another editor?

Yes. Obsidian opens the unzipped folder as a vault with every link working, and GitHub shows the files with their links and diagrams. Tools that import Markdown one file at a time keep the text and the tables; check how they handle links between files.

### How do I import the template into Nodary?

Open a project’s map, choose Import, then the Folder or ZIP tab, and choose the downloaded .zip. Nodary shows the tree first, then creates the nine documents with the overview as their parent, keeps the links between them and draws the diagrams. Any folder or .zip of up to 200 Markdown files imports the same way.

### Can I use the template for a commercial game?

Yes. Use it, change it and share it for any game, commercial or not, with or without a Nodary account. A mention is welcome, never required.

The page: https://nodary.ai/templates/game-design-document