Game design documents — Game Design Fundamentals

What you'll learn

Write a one-page GDD
List the sections of a one-page game design document
Write specific design pillars and use them as a decision filter
Scope a game with explicit in and out lists

Write a one-page game design document that a small team could build from.

Why it matters

Once more than one person works on a game, the design has to live somewhere other than the designer's head. A game design document (GDD) is that shared reference: what the game is, what it is not, and how its pieces fit. Programmers, artists, producers and testers all use it to make decisions without asking the designer every five minutes.

From bible to one page

Older studios wrote huge GDDs, sometimes hundreds of pages. They were slow to write, rarely read and quickly out of date. Many teams now prefer:

A one-page design or one-sheet for the whole game, popularised in talks by designer Stone Librande.
Short living docs per feature (a page on the inventory, a page on combat), kept in a wiki and updated as the game changes.
Diagrams over paragraphs: maps, flowcharts and annotated mock-ups.

The one-page constraint forces clarity. If you cannot fit the core of your game on a page, you probably do not know what it is yet.

What goes on a one-page GDD

Section	Purpose	Example
Title + high concept	the game in one sentence	"A cosy puzzle game where you fold paper maps to connect villages."
Platform and audience	who and where	mobile and PC, ages 10+, casual puzzle players
Design pillars	2-3 experience goals every feature must serve	"tactile folding", "calm discovery", "no fail states"
Core loop	the repeated cycle	study map -> fold -> connect -> unlock village -> new map
Mechanics	the main rules, one line each	folds snap to creases; each village needs one path
Controls	inputs for digital games	drag to fold, tap to undo
Scope	size and limits	40 puzzles, 3 hours, no multiplayer
Visual	a map, loop diagram or screen mock	a small sketch
Risks	what to test first	"Is folding readable on small screens?"

Design pillars: the decision filter

Pillars are the most useful part of a GDD for day-to-day decisions. When someone proposes a feature, the team asks: "Does this support our pillars?" If the pillars are "calm discovery" and "no fail states", a countdown timer is an easy no, however cool it looks.

Good pillars are short, specific and different from each other. "Fun" and "good graphics" are not pillars; "every fold should feel physical" is.

Worked example: scoping down

First draft of scope for the folding game: "100 puzzles, story mode, level editor, online sharing, 5 art styles."

For a first release by a small team, that is far too much. Revised scope:

In: 40 puzzles in 4 themed sets, undo, hint system.
Out (for now): level editor, online sharing, extra art styles.

Writing an explicit out of scope list is just as important as the in list: it stops scope creep and records decisions so they are not re-argued every week.

Keeping it alive

A GDD is only useful if it matches the game. Practical habits:

Date the document and note what changed.
Link from the one-pager to feature docs rather than growing it.
Review it after each playtest round: does it still describe the game?
Make it easy to find (a pinned wiki page, a shared folder).

Common mistakes

Writing a novel. Long lore and backstory belong in a separate narrative doc.
Vague pillars. "Fun", "epic" and "polished" do not help anyone decide anything.
No out-of-scope list. Every idea stays "maybe" forever.
Writing it once and never updating it. An outdated GDD is worse than none, because people trust it.
Text where a diagram would do. A loop or map sketch is faster to read than three paragraphs.

Quick recap

A GDD is the team's shared reference for what the game is and is not.
Modern teams favour a one-page overview plus short feature docs.
Include high concept, audience, pillars, core loop, mechanics, scope (in and out), a visual and risks.
Pillars are a decision filter; keep the document current.

Try it

Open the Do tab and write a one-page GDD for your game.

Key terms (5)

game design document: The team's shared reference for what a game is, what it is not and how its pieces fit.
high concept: The whole game described in one sentence.
Design pillars: Two or three short, specific experience goals that every feature must serve.
out of scope: An explicit list of features left out for now, which stops scope creep and records decisions.
living docs: Short feature documents kept in a wiki and updated as the game changes.