Workshop 2 — Structuring a Game Design Document

The morning gave you the core. This hour makes it communicable. The deliverable is a one-page GDD.

Caution

Nothing you write this afternoon is a fact. It is a hypothesis waiting for workshop 3’s table.

Why this is hard

You cannot write an experience. You can only write the rules that produce one

Salen and Zimmerman call this the second-order design problem: a designer builds a system, and the play that emerges from it belongs to the player. Sylvester makes the same point from the production side — you author mechanics, the mechanics generate events, and only those events carry feeling.

Your document therefore has to be precise about rules and honest about the fact that the experience is a prediction.

Who is this document for?

Write without knowing your reader and you will write too much while still failing to answer their question.

Reader	What they want	What you owe them
Your team	To know what to build tomorrow	Rules precise enough to implement without guessing, and a clear line between what is decided and what is still open
You in three months	To know what you were thinking	The reason for a decision, not just the decision
Outsiders	Why this game and not another	About two minutes of attention — which is why the one-page version exists

Schell describes design documents as serving two purposes: jogging your own memory and communicating with others. The most forgotten reader is future you, and the most grateful one too.

Three artefacts, not one document

Rogers calls this a tiered document set — each tier has a different reader and a different length.

Artefact	Name in the literature	When it is written	What it holds
The one-pager	The One-Sheet	Written first, read first	Eight boxes · target audience · rating · unique selling proposition
The ten-pager	The Ten-Pager	When you pitch, or when production planning starts	Macro-level logic · the rule of threes · the beat chart
The full design document	The GDD	Grown section by section, only when a decision needs it	Moment-to-moment gameplay · heavily illustrated · flowcharts and animatics

The Rogers rule on documents

Nobody on your team wants to read your design document. Your job is to find the most engaging, visual way to communicate the ideas so they are grokked instantly — a stick figure conveying a mechanic beats a dense paragraph every time.

Three supporting habits that apply at every tier:

• The rule of threes — humans process information best in threes. Group features, mechanics and sections in threes wherever you can.
• Visual communication — draw it, don’t describe it.
• The beat chart — a single-page spreadsheet running the entire span of the game (level · new enemy · new mechanic · mood · reward), so you can compare pacing and flow on one sheet and catch the flat stretch before you build it.

The one-page document — eight boxes

Fit these on one page and you understand your own game well enough to start building it.

#	Box	The bar
1	High concept	One or two sentences, with no story summary
2	Genre, platform, audience	Lets the reader compare it to something they know
3	Core loop	Lift it straight from this morning’s canvas
4	Three pillars	The box that says what you won’t do
5	Key features (3–5)	Only what the game cannot exist without
6	Art and audio direction	In words, not images. Real references encouraged.
7	The hook	Why this one, when ten similar games exist?
8	Scope and schedule	Length, team size, deadline

Tip

Box eight is what separates a student document from one written by someone who has shipped. It gets skipped often, and read first.

A worked example — the demo game’s one-pager

Note that no box runs longer than two lines, and one box openly says it is undecided.

Box	Content
High concept	A first-person escape game where the player uses hearing instead of sight to decide when to move
Genre · platform · audience	Survival horror · PC on Steam · players 18–30 who watch streamers play Asian horror
Core loop	Listen, choose a route, move quietly, the threat closes in — roughly 20–30 seconds per cycle
Pillars	Silence is the weapon · you lose by hurrying · fear comes from what is never shown
Key features	Directional audio · a lantern that burns down every turn · a threat that remembers your routes
The hook	A horror game that delivers information through the ears, built on Isan folk belief
Art and audio direction	Degraded videotape image, light limited to the lantern, field recordings from a real village
Scope and schedule	45 minutes to finish · team of 3 · prototype in 8 weeks · number of levels undecided

Writing the high concept

The formula: the player is X, must VERB, in order to Y, under constraint Z

Works	Doesn’t work
Names what the player does before what the player sees	Opens with the setting, the lore or the protagonist’s childhood
Contains the core verb from this morning, word for word	Leans on adjectives — atmospheric, immersive, gripping
States a constraint, because constraint is where tension lives	Describes the feeling you hope for instead of the system that causes it
Readable aloud in a single breath	Would fit any other project in this room without alteration

Test: read your high concept to someone and ask them to describe what the player does. If they cannot, rewrite it.

The meat and the salt — why the high concept carries no story

The most re-argued question in any design classroom: which matters more, story or gameplay? Rogers settles it with one image.

Gameplay is the meat — the core sustenance, the interactive engine that keeps the player engaged. Story is the salt — it adds vital flavour, context and emotional resonance. Applied too heavily, it ruins the meal completely.

Structure the mechanics first and let the narrative season the experience. That is why the high concept box carries no story summary, and why world and backstory are capped at two lines on the one-pager.

The real narrative belongs to the player

The classical arc — hero has a desire, an event causes disarray, reversals escalate the risk, resolution delivers the object of desire — is the structure Hollywood uses. Games have a fundamentally different geometry.

The player’s actions are the story. Every time the game is played, an infinite number of narratives can be generated. The designer’s job is therefore not to write one good story but to look at the infinite permutations and ensure all of them are fun.

A systems example: Left 4 Dead runs an AI “Director” that calculates player stress from health, skill and location, and dynamically adjusts enemy spawns, ammo drops and pacing. Systems choreograph experiences, and experiences generate emotions — not a pre-written script.

In your document this means: describe how the system responds, not which cutscene will move the player.

Growing into the full document

Write a section at the moment it is needed to make a decision — not before.

Section	When to write it	The question it settles
1. Overview and pillars	Day one	What are we making, and what will we refuse?
2. Rules and systems	Before that system is coded	What exactly are the numbers, states and win conditions?
3. Economy and progression	After the prototype survives a test	What does the player gain and lose, and when?
4. World, story, characters	Once the mechanics stop moving	What context makes those mechanics mean something?
5. Levels and teaching	Before real level building starts	In what order does the player learn the rules?
6. Interface and UX	Before final art	What does the player see, and at what moment?
7. Art and audio	When you start briefing or hiring	What exactly must someone deliver?
8. Tech, scope, schedule	Day one, revised monthly	Can this team finish this in this time?

Four habits that keep a document alive

• Date and version it — the top line shows when it last changed, so a reader knows whether they are looking at current thinking.
• Mark what is untested — tag every claim as tested, untested or undecided. Belief and evidence must not read in the same voice.
• Cut what you dropped — move cancelled features to a graveyard page with the reason. It stops new team members re-proposing them.
• Keep one copy — one link everybody opens. No final_v3_actual_latest circulating in a chat thread.

Hands-on — write the one-pager for your game (14 minutes)

1. Start with the boxes you already have — the core loop and the three pillars.
2. Write the high concept with the formula: player is X, must VERB, to Y, under constraint Z.
3. Pick at most five key features, then cross out any the game could survive without.
4. Write the hook by comparison to existing games, not by claiming novelty.
5. Finish with scope and schedule — length, team size, deadline.

Ground rules

• One page. If it overruns, cut content — do not shrink the font
• No more than two lines of world or backstory on the one-pager
• Circle every box you are unsure about. That circle is workshop 3’s test list.

This workshop’s worksheet

📄 One-Page GDD — blank template + worked example (PDF, 2 pages)

Page 1 is the eight boxes you fill in during this hour. Page 2 is the demo game’s one-pager. Keep your Loop Canvas from workshop 1 beside you while you write.

If you finish early — design the box first

Rogers’ extra exercise, and a good check on whether your one-pager is sharp: draw your game box.

• The slogan on the front — can you summarise the game’s objective as simply as a 1950s board game?
• Three features on the back — limit yourself to three core mechanics. If it does not fit on the box, it might not belong in the game.
• Rating and audience — who exactly is the player? Casual or hardcore?

Designer’s note: kids always want to play games designed for an audience slightly older than they are. Never talk down to your player.

The read-back test

The cheapest and most brutal test a document can face. Eight minutes, and it never flatters you.

1. Read in silence, three minutes — swap documents with a partner. The reader asks nothing. The author explains nothing, however badly they want to.
2. Play it back, two minutes — the reader says what they think the game is, what the player does, and what the hook is. The author listens and writes.
3. Circle only the misses — if the reader got it wrong, the document is wrong, not the reader. Circle the line that misled them and fix that line alone.

Workshop 2 wrap

1. A document nobody reads does not exist; write for a named reader, and write visually.
2. The one-pager is the hard version, because one page forces decisions.
3. Gameplay is the meat, story is the salt — write the rules first, then season.
4. Everything in it is a hypothesis until someone who is not you has played it.

Next: bring the boxes you marked undecided. They go on a table, and real people play them inside one hour → Workshop 3