Appendix C: Game Design Document Template

The Game Design Document is the most misunderstood artifact in game development. Beginners overbuild it, treating it like a novel that will convince an imaginary publisher to fund the dream. Veterans underbuild it, because they have been burned by 80-page documents that nobody on the team ever opened. Somewhere between those two failure modes is a tool that actually helps you ship.

This appendix is that tool. Or rather, it is three versions of that tool, because the right GDD for a one-week game jam is not the right GDD for a three-year studio production. You pick the level of formality that matches the scope, and you update the document as the game changes — because if you are doing it right, the game will change. The first draft of your GDD will be wrong. The second draft will be less wrong. By the time you ship, the document and the game will have converged on whatever the thing actually turned out to be.

Before we get into templates, one foundational point that you should tattoo somewhere visible: the GDD is a living document, not a one-time deliverable. It is not a script. It is not a contract. It is not a pitch deck, although it can sometimes serve as one. It is the current best description of what the team is building and why. Every month that your GDD does not change, either your game has entered maintenance mode or, much more likely, nobody is updating it and the document is now lying about what the game is. Kill the document or update it. Do not leave zombies lying around.

Levels of GDD Formality

Different projects need different documents. Do not write a 200-page production bible for a two-week jam game. Do not try to run a 40-person studio off a one-page pitch.

The progressive-project action-adventure you are building across this book belongs in the concept-document category. You are one person (or a tiny team) making a scoped 2D game in Godot. A 200-page production bible would be absurd. A one-page pitch would leave you with nothing to refer back to when you forget what you decided in month two. Five pages is the right number.

Now the templates themselves. Copy them. Fill them in. Throw out the bits that do not apply. Add bits that are missing for your project. This is scaffolding, not scripture.

The One-Page Pitch

Use this for jams, elevator pitches, internal go/no-go decisions, or the first 20 minutes of thinking about a new idea. If you cannot fill this out, you do not yet have a game — you have a feeling. That is fine; feelings are where games start. But do not mistake the feeling for the design.

=======================================================
ONE-PAGE PITCH
=======================================================

TITLE:
[Your working title. Placeholder is fine.]

ELEVATOR PITCH:
[One sentence. 20 words max. If you cannot fit your game
into 20 words, you do not know what your game is yet.]

GENRE:
[Primary genre + sub-genre. e.g., "2D metroidvania action-
adventure," "turn-based deckbuilder roguelike," "narrative
puzzle."]

PLATFORM:
[PC/Mac/Linux via Steam + itch.io, iOS, Switch, etc. Be
specific about where players will actually get it.]

SCOPE ESTIMATE:
[Expected playtime + development time + team size. Three
numbers. Be honest; nobody is grading this.]

TEAM:
[Who is making it. Roles if there are multiple people.]

DESIGN PILLARS (3–5):
[Each pillar is one sentence describing a commitment you
will defend against all feature requests. Pillars answer:
"If someone wants to add X, and X violates pillar Y, we
say no." If your pillars do not say no to anything, they
are not pillars, they are marketing.]

INSPIRATIONS:
[3–5 specific games. Not genres. Specific games. "It's
like Celeste meets Hades with a touch of Tunic" is
infinitely more useful than "it's a challenging
action-adventure with rewarding progression."]

TARGET AUDIENCE:
[Who plays this? Be specific enough to be useful.
"Gamers" is not an audience. "Players who completed
Hollow Knight and are looking for something similar but
shorter" is an audience.]

UNIQUE HOOK:
[What does your game do that no other game does? This
should be one sentence. If you need three sentences, your
hook is not sharp enough yet.]

=======================================================

Filled Example — The Progressive Project

=======================================================
ONE-PAGE PITCH
=======================================================

TITLE: Ember's Descent (working title)

ELEVATOR PITCH:
A 2D action-adventure about a phoenix child exploring the
ruins of a sky-kingdom, one fall at a time.

GENRE:
2D metroidvania action-adventure with light platforming.

PLATFORM:
PC/Mac/Linux via itch.io. Potential Steam launch post-
feedback. Godot 4.x engine.

SCOPE ESTIMATE:
3–4 hour first playthrough. 12 months development.
Solo developer. ~50MB build size.

TEAM:
Solo (me): design, code, level art, UI, sound.
Contracted: original soundtrack (~8 tracks), key art.

DESIGN PILLARS:
1. Every death teaches something; no death is random.
2. The world is one continuous space — no loading zones
   visible to the player.
3. Movement feels good before anything else does —
   dashing, climbing, and falling are all joyful in
   isolation.
4. Exploration is rewarded with more interesting movement,
   not just bigger numbers.
5. Accessibility is not optional — assist mode from day
   one, not bolted on in patch 1.1.

INSPIRATIONS:
- Celeste (movement feel, accessibility, emotional tone)
- Hollow Knight (interconnected world, no hand-holding)
- Tunic (visual clarity, the feeling of discovery)
- Dead Cells (combat rhythm at smaller scale)
- Journey (mood, wordless narrative)

TARGET AUDIENCE:
Players who finished Celeste or Hollow Knight and wanted
a similar feeling in a slightly shorter, slightly
gentler package. Age 16+. Controller-first but fully
playable on keyboard.

UNIQUE HOOK:
You can choose to fall instead of die — voluntary falls
unlock new platforming routes that survival-focused runs
never reveal. The map has two shapes: one for cautious
players, one for acrobatic ones.

=======================================================

Fifteen minutes, one page. That is your pitch. You can build a 40-hour RPG off a one-pager like that; you can also build a jam game off it. The point is that everything else in your documentation extends this. If the concept document contradicts the one-pager, one of them is wrong and you need to decide which.

The Concept Document (Five Pages)

The concept document is the workhorse of indie game design. It is long enough to capture real decisions, short enough that every collaborator will actually read it. Chapter 2's discussion of the designer's role, Chapter 5's verb list, and Chapter 6's core-loop diagram all end up compressed into this document.

Structure:

=======================================================
CONCEPT DOCUMENT
[Title] — v[X.Y] — [Date]
=======================================================

1. EXECUTIVE SUMMARY (1 paragraph, ~150 words)
   [The one-page pitch's elevator pitch expanded. Paint a
   picture of what the player does and what the game
   feels like. Do not describe mechanics; describe
   experience. A good test: can a stranger read this
   paragraph and picture someone playing the game? If
   not, rewrite.]

2. DESIGN PILLARS (3–5 single-sentence commitments)
   [Copy from the one-pager. These should rarely change.
   If they do change, flag the change explicitly — the
   rest of the document may need to shift with them.]

3. CORE LOOP (1 paragraph + diagram)
   [The 10–30-second cycle the player does over and over.
   Chapter 6 is the reference. State the loop as a
   sequence of verbs, then describe what makes each beat
   satisfying.]

4. MECHANIC LIST (bullet list, 1 sentence per mechanic)
   [Every verb the player has. Mark which is primary,
   which are secondary, which are progression. Keep each
   description to one sentence. If you need more than a
   sentence, the mechanic is probably two mechanics.]

5. NARRATIVE PREMISE (~200 words)
   [Who is the player? Where are they? What do they want?
   What stands in their way? No more than 200 words. If
   your story cannot fit in 200 words at this stage, you
   are overwriting. Details live in a separate narrative
   doc.]

6. VISUAL REFERENCES (mood board, external)
   [Link to PureRef / Milanote / Figma board. Do not
   paste images into the doc. The mood board is a living
   collection; the GDD just points at it.]

7. AUDIO DIRECTION (1 paragraph)
   [What does the game sound like? Reference 2–3 existing
   soundtracks. One sentence on music style, one on SFX
   philosophy, one on voice-over (if any). Chapter 30 is
   the reference.]

8. PLATFORM & TECH (short)
   [Engine, target platforms, minimum specs, input
   methods supported, networking if applicable,
   save-system approach.]

9. TIMELINE ESTIMATE (milestones, not dates)
   [Paper prototype → playable prototype → vertical slice
   → alpha → beta → ship. Rough duration for each. Your
   estimates will be wrong. That is normal. Update
   monthly.]

10. RISK LIST (top 3–5)
    [What could kill this project? Be honest. "The combat
    might not feel good" is a legitimate risk. "I have
    never made AI before" is a legitimate risk. Chapter
    37 on scope management is the reference for
    evaluating these.]

=======================================================

The concept document is the first document your team should read on day one. It is also the document you print out and stare at when you are lost in month seven and cannot remember why you are making this game. The pillars, especially. The pillars are your compass when you are deep in implementation and some tempting feature whispers "add me."

The Full Design Document (20–50 Pages)

The full GDD fleshes out everything the concept document sketches. It is what you send to a publisher for a vertical-slice greenlight, what you hand to a contracted artist, what QA uses to understand scope. Most indie games never need one of these — the concept document plus your code is enough. If you are working with a small team, with outsourced specialists, or with a publisher who requires one, here is the skeleton.

=======================================================
FULL DESIGN DOCUMENT — SKELETON
=======================================================

TABLE OF CONTENTS

1. GAME OVERVIEW
   1.1 Executive summary
   1.2 Genre and subgenre
   1.3 Platforms and technical requirements
   1.4 Target audience (primary, secondary)
   1.5 Design pillars
   1.6 Comparable titles (3–5 with specific analysis)
   1.7 Unique selling points

2. GAMEPLAY
   2.1 Core loop (diagram + narration)
   2.2 Primary mechanic (detail)
   2.3 Secondary mechanics (detail)
   2.4 Controls (input map for every platform)
   2.5 Camera (framing, behaviors, edge cases)
   2.6 Difficulty philosophy + assist/difficulty options
   2.7 Session length + play patterns

3. SYSTEMS
   3.1 Progression system (XP? ability unlocks? keys?)
   3.2 Economy (currencies, sinks, sources)
   3.3 Combat (if applicable: damage model, i-frames,
       stagger, combo rules)
   3.4 AI (enemy archetypes, companion AI if any)
   3.5 Multiplayer (if applicable: modes, netcode,
       matchmaking)
   3.6 Save/load + persistence
   3.7 Accessibility options (Chapter 29 reference)

4. CONTENT
   4.1 Level list + pacing chart
   4.2 Enemy roster (appearance, behavior, threat level)
   4.3 Boss roster (phases, moves, telegraphs)
   4.4 Item / weapon / ability catalog
   4.5 NPCs (name, role, dialogue sample)
   4.6 Collectibles / secrets

5. NARRATIVE
   5.1 Premise + central conflict
   5.2 Characters (one-page profiles for main cast)
   5.3 Plot structure (beat sheet or outline)
   5.4 Dialogue samples (5–10 lines per major character)
   5.5 Environmental storytelling framework (Chapter 22)
   5.6 Narrative delivery methods (cutscenes?
       environmental? dialogue? journal?)

6. ART
   6.1 Visual style (reference board + written
       philosophy)
   6.2 Character design references
   6.3 Environment design references
   6.4 UI visual direction
   6.5 Animation style + key-pose examples
   6.6 Color palette + mood per region

7. AUDIO
   7.1 Music direction (genres, instruments, 2–3
       reference OSTs)
   7.2 SFX direction (realistic? stylized? chiptune?
       foley?)
   7.3 Voice-over (if any: language count, line count
       estimate, casting direction)
   7.4 Dynamic/adaptive audio rules (Chapter 30
       reference)

8. UI / UX
   8.1 Menu flow diagram (title → settings → play →
       pause → etc.)
   8.2 HUD elements + layouts
   8.3 Inventory / progression screens
   8.4 Tutorial plan (diegetic? overlay? text?)
   8.5 Accessibility feature checklist (Appendix I
       reference)

9. TECHNICAL
   9.1 Engine + version + key plugins
   9.2 Key technical challenges + proposed solutions
   9.3 Performance targets (frame rate, resolution, load
       times)
   9.4 Data formats (save files, level files,
       localization)
   9.5 Build pipeline + deployment

10. PRODUCTION
    10.1 Timeline with milestones
    10.2 Team + roles + contractor plan
    10.3 Budget + cash-flow estimate
    10.4 Risk register (with mitigation plans)
    10.5 QA plan + playtesting plan (Appendix D)

11. MARKETING
    11.1 Positioning statement
    11.2 Comparable-titles analysis (same genre, recent
         releases, commercial performance)
    11.3 Key marketing beats (Steam page, wishlisting,
         demo, launch trailer)
    11.4 Press/influencer target list
    11.5 Community plan (Discord? Twitter? mailing
         list?)

12. APPENDICES
    A. Glossary of in-game terms
    B. References (game, film, book, music inspirations)
    C. Version history / changelog
    D. Open questions / TBD list

=======================================================

You do not fill every section on day one. You fill sections as decisions are made, and you mark un-filled sections [TBD] with a deadline. A section marked [TBD] with no deadline is a lie.

What to Keep in the GDD, What to Move

The GDD is not the only document your project needs. In fact, one of the most common mistakes beginners make is cramming everything into a single 200-page Word file, which is then too unwieldy for anyone to search and too painful for anyone to update. The GDD should be a hub that points to other, specialized documents and tools.

Keep in the GDD:

• High-level vision, pillars, and positioning
• System overviews and how they interact
• Scope decisions and tradeoffs
• Summary tables of content (level list, enemy roster, item catalog)
• Links to all the other places where details live

Move out of the GDD:

• Code. Code lives in your repository. The GDD can describe what the combat system does; the actual implementation belongs in CombatSystem.gd with comments. If your GDD has a code block longer than 10 lines, that block should probably be a link to the source file.
• Art references / mood boards. Use Milanote, PureRef, or a Figma board. Images in GDDs bloat the file, go stale the moment you update the mood board, and lose fidelity in print.
• Narrative scripts. Branching dialogue belongs in ink, Yarn Spinner, Twine, or a dedicated tool. Linear cutscene scripts can live in a Google Doc. The GDD references the script; it does not contain the script.
• Wiki-style content. Detailed lore, character bios, item descriptions, regional histories — put these in Notion, Confluence, Obsidian, or a plain wiki folder. The GDD summarizes; the wiki elaborates.
• Task lists, bug reports, feature requests. These go in Trello, Jira, Linear, GitHub Issues, or a spreadsheet. The GDD describes what the game should be; the task tracker describes what work remains to make it so.
• Data tables. Enemy stats, loot drop tables, economy balance numbers. These belong in spreadsheets (Google Sheets, Airtable) so designers can edit them without touching the doc.

The GDD is the map. The other tools are the territory. A map that tries to contain the territory is just a bigger territory.

Living Document Practices

A GDD that is not maintained is not a GDD. It is a historical artifact, possibly useful for a post-mortem, useless for steering development. Here is how to keep it alive.

Version-control it. Put the GDD in your project repo, or in a Google Doc with revision history, or in Notion with version snapshots. Do not email around GDD_final_v3_ACTUAL_FINAL.docx. When the document changes, you need to be able to see when and who and why.

Changelog at the top. The first section after the title should be a changelog.

## Changelog
- 2026-04-12: Removed wall-climb, replaced with dash-up-wall
- 2026-03-28: Third boss scrapped; cut to single phase
- 2026-03-15: Added assist mode to design pillar #5
- 2026-02-01: v1.0 concept doc locked

Changelogs make it trivial to see what has shifted recently. Team members who return after a week away read the changelog first and know what to re-read.

Flag-stale-sections reviews. Every 2–4 weeks, skim the GDD and flag any section that no longer matches the build. Either update the section or delete it. Sections that describe features you have cut are worse than useless — they mislead new readers.

Pillars are anchors. The one part of the GDD that should rarely change is the design pillars. Pillars are the commitments you made when the vision was clearest. If you find yourself changing pillars monthly, either your vision is still forming (which is fine, but label it that way) or you are drifting away from the game you meant to make (which is the time to stop and ask why). Treat pillar changes as major events. Discuss them. Date them. Justify them in the changelog.

Prune ruthlessly. A 40-page GDD that reflects the current build is more useful than a 200-page GDD that includes everything ever considered. Cut content that no longer applies. You can keep an archive document for "ideas we considered and rejected" if your team wants the history.

Common GDD Mistakes

Every beginner makes at least one of these. Most veterans have made all of them at least once.

Writing a novel nobody reads. The GDD is not your chance to demonstrate literary skill. It is a reference document for collaborators. Write plainly. Use headings and bullet lists aggressively. Short sentences. Active voice. If a section reads like a short story, it probably belongs in the narrative document, not the design doc.

Too much too early. You are six weeks into a three-year project and you have 180 pages of GDD. You have not playtested a single mechanic. You do not know if the core loop is fun. You are describing Level 47's boss fight in detail. Stop. The GDD scales with the game. If you are in pre-production, a five-page concept doc is more honest than a 180-page fantasy.

Too little, too late. The opposite failure. You are in month ten, the team has grown to five people, and the GDD is the two-paragraph pitch you wrote on a napkin. Three designers are making three different games because nobody wrote down what the shared vision was. Tooling up the GDD in mid-production is painful but mandatory; waiting until crunch to document decisions guarantees the decisions will be wrong.

Never updating. The GDD describes the game you thought you were making in month one. You are now in month fourteen and the game is something else. The GDD is lying. New team members read the GDD, form a mental model that does not match the build, and their first week of work is wasted. If you cannot commit to updating, delete the GDD and tell the team the source of truth is the build.

Treating it as the answer. The GDD is the current best guess about what the game should be. It is not proof. It is not a specification in the engineering sense. It is a working hypothesis that you will test against playtest reality (Chapter 31) and revise. Designers who argue "but the GDD says" when playtesters tell them the game is not working have lost the plot. The players are the source of truth. The GDD is the map you drew last month.

Writing it alone, then presenting it. If your team sees the GDD for the first time when you announce it, they will resent it. Collaborate on the document as you write it. Share drafts. Accept edits. A GDD written in isolation and handed down is a GDD that the team will read once and never again.

Example — Progressive Project Two-Page Concept Doc

Here is a filled-out two-page concept doc for the progressive-project action-adventure. Use this as the template for your own concept doc, with your own game in the slots.

=======================================================
EMBER'S DESCENT — CONCEPT DOCUMENT
v0.4 — April 2026
=======================================================

## Changelog
- 2026-04: Reworked pillar 4 (exploration rewards now
  include movement abilities, not just cosmetic finds)
- 2026-03: Cut procedural level gen; fixed handcrafted
  world
- 2026-02: Core loop pivoted from "combat focus" to
  "movement focus"

## 1. Executive Summary
Ember's Descent is a 2D metroidvania in which you play a
phoenix child who has fallen from the sky-kingdom and
must explore the ruins below to find a way back. Combat
is present but light; movement is the real pleasure.
Every dash, climb, and wall-jump feels alive. The world
is one interconnected space, and voluntary falls unlock
alternate routes invisible to cautious players. The tone
is contemplative-mournful rather than bombastic — closer
to Journey than to Hollow Knight, though visually
closer to the latter.

## 2. Design Pillars
1. Every death teaches something; no death is random.
2. The world is one continuous space — no loading zones
   visible to the player.
3. Movement feels good before anything else does.
4. Exploration is rewarded with richer movement, not
   just bigger numbers.
5. Accessibility is not optional — assist mode from day
   one.

## 3. Core Loop
Explore → Encounter (small combat or traversal puzzle) →
Find ember (checkpoint + minor power) → Push further →
Die or quit → Return at checkpoint, try variant route.
Full loop is 2–5 minutes depending on player style.

## 4. Mechanic List
Primary: Dash (air, 8 directions, recharges on landing
or grab)
Secondary: Climb, Wall-jump, Glide (via wing-ember),
Attack (light, no combo system)
Progression: Ember abilities (unlocked by finding
embers scattered through the world — glide, double-dash,
bounce, phase-through specific walls)

## 5. Narrative Premise (200 words)
The sky-kingdom of Coralon has been sustained for a
thousand years by the embers of the phoenix-line, who
carry fragments of the Great Fire through their
successive lives. You are the youngest phoenix-child,
and on the night of your first flight, the Great Fire
went out. You fell with it. You wake in the ruins far
below the clouds — an ancient city that your people had
forgotten, buried in the world they left behind.
Something down here stirred when the fire went out.
You must find your scattered embers, re-learn what your
wings can do, and decide whether to return to the
sky-kingdom or remain in the ruins. There is no
external villain. The antagonist is forgetting — both
the kingdom's forgetting of its origins and your own.

## 6. Visual References
[Link: milanote.com/embers-descent-moodboard]
Key refs: Gris (color), Hollow Knight (silhouette),
Journey (robes), Tunic (clarity), Old Japan ruins.

## 7. Audio Direction
Ambient piano + strings + occasional taiko. Long silences
are allowed. Reference OSTs: Gris (Berlinist), Journey
(Austin Wintory), Celeste (Lena Raine). No voice-over.
Sparse sound design — every footstep matters.

## 8. Platform & Tech
Godot 4.x. PC/Mac/Linux. itch.io first, Steam if
reception warrants. Controller + keyboard both supported.
Save system: autosave at embers. No manual save slots
(opinionated).

## 9. Timeline
- Prototype: complete (core movement feels good)
- Vertical slice: August 2026
- Alpha (all systems, rough content): December 2026
- Beta (content complete, balance passes): March 2027
- Ship: Summer 2027

## 10. Risks
1. Scope creep on world size — mitigation: locked
   world-map design in month 2, no additions without
   cutting something
2. Movement not feeling good enough on keyboard —
   mitigation: test weekly, two keyboard-only testers
   minimum per round
3. Solo burnout — mitigation: 4-day dev weeks, no
   crunch, contracted composer means I am not also
   writing music
4. Narrative tone is hard to nail without dialogue —
   mitigation: playtest narrative comprehension
   explicitly in beta

=======================================================

That is two pages, and it is enough to build a year of work off. Print it. Tape it to the wall. Update the changelog every time a pillar shifts or a core decision changes. When you are lost in month eight and cannot remember what this game was supposed to be, you read these two pages again, and the path forward becomes clearer.

The best GDD is the one your team actually reads. All the rest is stationery.