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.