Game design document template

Game design document template

A game design document (GDD) has one job: get the idea out of your head so you, and anyone who joins you, can check decisions against it. It is not a contract and it is not a novel. Most GDDs that fail are too long to keep up to date, so the template below is short on purpose.

Working alone? You still need this. Future you, three months from now, is a stranger who has forgotten why a decision was made.

Game design document template: part 1

• Start with the pitch and the pillars. If you can’t say what the game is in two sentences, nothing else in the document will fix that.
• Fill in the core loop before anything else. It is the thing a player does every minute. Every other section exists to support it.
• Write the scope section honestly. List what is in the first playable version and what is not. “Not yet” is a perfectly good answer.
• Leave sections empty rather than inventing detail. Open questions are more useful than guesses. Move them to “Open questions” and come back.
• Review it at every milestone. A GDD that stops matching the game is worse than none, because people trust it.

Game design document template: part 2

• # [Game title]
• ## Pitch
• [Two sentences. What is the game, who is it for, and what makes it worth playing?]
• ## Design pillars
• Three or four things the game must always be. When two good ideas conflict, the pillars decide.
• 1. [Pillar] — [what it means in practice]
• 2. [Pillar] — [what it means in practice]
• 3. [Pillar] — [what it means in practice]
• ## Core loop
• [What does the player do, over and over, in a minute? In a session?]
• - Moment to moment:
• - Session:
• - Long term:
• ## Player experience
• [How should it feel to play? Name two or three feelings, and what in the design creates them.]
• ## Mechanics
• | Mechanic | What the player can do | Why it is fun | Status |
• | [Name] | [Action] | [Reason] | Idea / Prototype / Done |
• ## Progression and difficulty
• [What changes as the player plays? How do you teach, and how do you ramp?]
• ## World and story
• [Setting, tone and the story in a paragraph. Link to a longer world document if you have one.]
• ## Characters
• | Name | Role | One line |
• | [Name] | [Role] | [Who they are] |
• ## Art direction
• [Style in a sentence, references, colour and camera notes.]
• ## Audio direction
• [Music and sound style, references, anything the player must be able to hear.]
• ## Technical notes
• - Engine and version:
• - Target platforms:
• - Known constraints:
• ## Scope
• **In the first playable version:**
• -
• **Not yet:**
• -
• **Stretch goals:**
• -
• ## Risks
• | Risk | How likely | What we do about it |
• | [Risk] | Low / Medium / High | [Plan] |
• ## Milestones
• | Milestone | What is true when it is done | Target date |
• | Prototype | [Core loop is playable] | |
• | Vertical slice | [One level at final quality] | |
• | Alpha | [All features in, rough] | |
• | Release | [Shipped] | |
• ## Open questions
• -

Game design document template: part 3

• Writing the whole game before building any of it. Detail you haven’t tested is a guess. Write a page, build a prototype, then write more.
• Describing features instead of feelings. “A crafting system” says nothing. “Players feel clever for combining things in a way the game never told them” is something you can design toward.
• Keeping it somewhere nobody looks. The document has to be where the work happens, or it will be out of date within a month.