Workshop 3 — Rapid Prototyping on Paper

Morning found the core. The afternoon made it communicable. Tonight we find out whether we were right. The deliverable is a paper prototype that other people have actually played.

This workshop’s worksheets — a three-sheet pack

This workshop runs on three sheets, each used at a different point in the hour. Print all three before you start.

Sheet	Name	Used when	How many
A	Prototype Brief	Before you build anything — the twenty-minute clock starts after this sheet	1 per game
B	Playtest Observation	While a tester plays	one per tester
C	Change One Thing	After both playtest rounds	1 per revision round

📄 Download the Workshop 3 instrument pack — all three sheets with worked examples (PDF, 6 pages)

Odd pages are blank templates; even pages are the demo game’s filled-in versions.

Sheet A — Prototype Brief has six boxes: (1) the one question you want answered tonight, (2) what you are cutting for tonight, (3) win / lose condition, (4) systems in my game → objects on the table, (5) the rules, short enough to read aloud in sixty seconds, (6) where you are the computer — rulings you will have to make live.

Sheet B — Playtest Observation has the four behaviour columns, plus a box for live rulings and one for the closing question’s answer.

Sheet C — Change One Thing has six boxes: the repeated failure · the rule as it stands → the one rule you are changing it to · what you expect to happen next round (written before you test again — a prediction you can be wrong about is what makes this an experiment) · which box on the one-pager moves from undecided to known · the question for the next round.

The cost of finding out late

The question is not how to build faster. It is how to discover you were wrong as early as possible.

Problem found…	Relative cost
On paper	1
In an engine prototype	6
During production	22
Near release	70
After launch	160

The numbers vary by project. The shape never does. And the real cost is emotional — after three months you will not want to throw it away, even knowing it fails. Paper has no such gravity.

A prototype is an experiment, not a small version of the game. It is a device that answers one question. Answer it and the prototype worked.

The design loop mirrors the core loop

Same four steps as workshop 1. The only real skill is how many times you can go round.

Build — make the smallest thing that can answer your question. Twenty minutes, not twenty hours.
Test — put it in front of someone who is not you and did not help design it.
Learn — watch what they do rather than listening to what they recommend. Record behaviour.
Change — alter one rule, so the next round tells you whether that rule was the problem.

Click walls into the grid above and watch the route change — your paper prototype tonight runs on the same principle: a small grid that answers fast.

What paper can and cannot test

Match the tool to your question. If your question sits on the right, do not spend the evening on cardboard.

Tests well	Tests badly
Rules and systems — clear enough for a stranger to play?	Feel of control — the weight of a jump
Decisions — is the choice worth thinking about?	Real-time timing measured in fractions of a second
Economy and number balance	Atmosphere and dread carried by image and sound
Goal clarity — do they know what they are trying to do?	Visual quality and craft
Teaching order — do they learn fast enough?	Technical performance

If your question is on the right, build a tiny engine prototype instead — but first check whether the left-hand questions are actually answered.

Four hard rules for tonight

One question, written before you build. Keep it visible in the middle of the table. For the demo game: will a player risk moving forward when they do not know where the threat is? Answer that and the evening succeeded.
It is not allowed to look good. No illustrations, no more than two colours, no neat cutting. The prettier it gets, the more it costs you emotionally to throw away — and throwing away is the whole point.
Twenty minutes is all of it. Finishing early is an advantage, because testing is what produces answers, not building. If you finish early, play it yourself once and fix what jams.
You are the computer. You do not need rules for every case. Adjudicate live — but write down every ruling you make, because each one marks a rule that is not yet clear.

Turning systems into objects on a table

Use this while you build — find the row that matches your system and grab the object.

System in the game	Object on the table	How to actually use it
Health or resources	Counters, caps, beans	Keep the pile in front of the player and remove one at a time, so loss is visible
Randomness	Dice or a face-down deck	Dice feel riskier; a deck lets you control the actual probabilities much more precisely
Hidden information	Face-down cards on the board	Flip when the player reaches that tile — an excellent stand-in for fog of war
Cooldowns	A card turned face down	Turn it back up after the agreed number of turns have passed
Inventory limits	A grid drawn on paper	Cap the number of slots so you can watch what the player chooses to drop
Levels and maps	Grid paper and tokens	Start at six by six — small enough to finish a round in five minutes
Enemy AI	Three lines of written rules	Write conditions: if the enemy can see the player, advance two tiles; otherwise roll for direction

The demo game’s prototype

A 6×6 grid drawn in pen on one sheet of A4.

The player token — one bottle cap. Moves one tile per turn, or stays put to listen.
The hidden threat — the designer moves it. Roll each turn: 1–4 moves one tile toward the player, 5–6 moves randomly.
The goal tile — reach the opposite corner and you win. Share a tile with the threat and you lose.
Cards, dice, counters — face-down cards are information you do not have. Counters are lantern fuel, one spent every turn.

Hands-on — build your paper prototype (20 minutes)

Fill in Sheet A first — the clock starts after that.

Write your one question (box 01) and put it in the middle of the table where you can see it. It must be answerable by watching: not “is it fun”, but “will they do X when Y”.
Cut the game down to only the part that answers that question (box 02) — the rest waits.
Write the win and lose conditions (box 03), then convert your systems into objects using the table above (box 04).
Write the rules into box 05, short enough to read aloud in sixty seconds — if you cannot, the game is too big for tonight.
Play it yourself once before the clock stops and fix whatever jams. Log every live ruling in box 06.

The one rule you cannot break

Players report problems accurately and propose solutions badly

When a tester says “you should add a map”, what they are actually reporting is that they got lost and felt stupid. Sylvester’s guidance is to weigh observed behaviour far above stated opinion: watch where they hesitate, where they misread, where they disengage. The designer’s job is to hear the symptom and then diagnose it themselves.

Playtest rules — two sides, two jobs

If it is your game	If you are the tester
Explain the rules in sixty seconds, then stop talking	Think out loud continuously — “right now I am confused about…”
Never defend, never say “actually it will have…” — in the real game you are not sitting beside them	Report what you felt, not what you think should be fixed
Only take notes, especially where they pause abnormally long	Do not be polite; your politeness costs your friend months
Answer questions about rules, never about strategy	If you break a rule, do not apologise — that is the most valuable data of the night

Record these four things while someone plays (Sheet B)

Do not record opinions. Record behaviour — these four columns capture almost everything you need. Use one copy of Sheet B per tester, not one sheet for everyone, because the next step depends on finding what more than one tester hit.

#	What you record	What it means
1	Where they got confused	Any question asked or rule broken marks a rule that is not clear enough
2	Where they paused long	A long pause ending in a smile is a good decision. One ending in a sigh means missing information.
3	Where they smiled or laughed	This is the part that already works. Do not accidentally delete it in the next revision.
4	Where they disengaged	The moment they glance around the room or reach for a phone is where your loop broke

Close with one question: “If you played again, what would you do differently?” The answer tells you what the game managed to teach.

Cross-table playtest (15 minutes)

Two rounds of seven minutes. Rotate clockwise on the signal.

One designer stays at the table; everyone else moves to the next table.
Sixty seconds of rules, then the designer goes quiet and lets them play.
Four minutes of real play — designer records the four columns, gives no help, offers no defence.
Two minutes of closing questions, ending with “what would you do differently?”
On the signal, move immediately — do not tidy up.

Change one thing, then record it (Sheet C)

The last seven minutes of building. The goal is one change, not a rebuild.

Find the repeated failure — lay both copies of Sheet B side by side and look for what both testers hit. A problem that appeared once may just be that one person.
Change exactly one rule — the old rule in box 02, the new one in box 03. Change three at once and you will never know which one worked. Write the new rule over the old rules sheet; do not start a clean copy.
Write the prediction before you retest — box 04 is the heart of this sheet. State what you expect to happen next round before it happens. A prediction you can be wrong about is what separates an experiment from a guess.
Push it back into the document — box 05: open this afternoon’s one-pager and turn a box you marked undecided into something you now know. Then write the next round’s question in box 06 — the loop never closes.

The demo game’s worked example

Box	Content
The repeated failure	Both testers listened so often in the first half that they had no fuel left to move in the second. Waiting is currently free, so waiting is always correct.
The rule as it stands	Listening costs one lantern counter — the same as moving.
The one rule I am changing it to	Listening costs one counter and lets the threat move two tiles instead of one.
What I expect next round	Players will listen roughly half as often, and the second half will still have fuel in it. If they keep stalling anyway, the problem is missing information, not price.
What this changes in the one-pager	Box 03, core loop — the decision now costs something on both sides. Box 05, key features — “a lantern that loses fuel every turn” moves from untested to tested.
The question for the next round	Now that waiting is expensive, does the player have enough information to move with confidence, or are they just guessing?

Removing the designer’s blinders

After tonight you go back to building your own game, and you will hit the problem every team hits: you will lose perspective on your own game. Play the same level a thousand times and everything starts to look normal, including the broken parts.

Rely on outside eyes — fresh players and their 10,000-foot view tell you what is truly fun in a way you no longer can.
Trim the fat — if a level feels too long, too hard or boring after you have played it a thousand times, cut it. Consolidate down to only the most exciting moments.
Kill your darlings — if a system is breaking the game late in production, throw it out. Save the best discarded ideas for the sequel.
The pitching hierarchy — a playable demo beats a full GDD, which beats a pitch presentation, which beats a pitch outline. That is why tonight is worth more than it looks.

Workshop 3 wrap, and the end of the course

Find the core, write it down, test it, then go back and change the core — round and round.
Everything written stays a hypothesis until someone who is not you has played it.
A playable prototype beats the prettiest document, every time.
Skill in design is measured by how fast you discover you were wrong.