Analyse why games work, build and playtest paper prototypes, balance systems and levels, and communicate a design with a one-page GDD and a pitch.

Game Design Fundamentals

Write the one question this prototype must answer, for example: 'Is it tense to decide when to spend light?'

List the minimum components: board or cards, tokens, dice. Cross out anything that does not help answer your question.

Draw the board or cards quickly. Use words and simple symbols, not art.

Write the turn sequence on one index card or a scrap of paper (for example: move, draw, resolve, spend).

Play three full turns alone, moving for every player. Fix anything that stops play (missing rule, impossible state).

Play one full game alone and note how long it takes and where you were bored or confused.

Change one rule based on that solo game and play again. Note what changed.

Photograph the prototype and your notes so you can bring them to the playtest lesson.

## Why it matters

Building a digital game takes weeks before you can tell whether the idea is any good. A paper prototype can answer many of the same questions in an afternoon, for the price of some index cards. Studios use paper prototypes for board games, card systems, combat rules, economies, level layouts and even user-interface flows, because changing a rule with a pencil is far cheaper than changing code.

## The core idea: prototype a question, not a game

A prototype is an experiment. Before you cut a single card, write down the **one question** it must answer:

- "Is choosing between attacking and defending interesting every turn?"
- "Does a shared resource make players negotiate?"
- "Can a player understand the map layout without explanation?"

Everything that does not help answer that question can be left out, faked or simplified. Art, story, menus and balancing details usually come later.

## What you need

- **Index cards or paper** for cards, tiles and reference sheets
- **Dice** for randomness (a d6 gives 1-6; two d6 give a bell curve from 2 to 12)
- **Tokens** such as coins, buttons or beans for health, money or resources
- **A pencil**, so rules can change mid-game
- **A timer or phone clock** to measure turn length

## Worked example: testing a light mechanic

Idea: a dungeon game where your torch is also your health. Question: *is it tense to decide when to spend light?*

1. **Board:** a 6 x 6 grid drawn on paper. Face-down cards in some squares are rooms.
2. **Torch:** each player starts with 10 coins (light).
3. **Turn:** move one square (costs 1 light). Flip a room card if you enter it.
4. **Room cards:** "+3 light (oil)", "monster: roll a d6, lose that much light", "treasure: 1 point", "dark room: lose 2 light".
5. **End:** when a player escapes from the exit square or runs out of light.

The first solo playthrough reveals that players can just walk straight to the exit and ignore treasure. The question is not answered yet: there is no tension because there is no temptation. One rule change: **treasure is needed to unlock the exit.** Now every step is a choice between safety and greed, and the second solo game feels very different.

That loop of *build, play, notice, change one thing* is the whole method.

## Simulating digital games on paper

Paper works for digital ideas too:

- **Real-time action:** play in turns, where each turn is one second. You will learn about decision density, not reflexes.
- **Hidden information:** a friend acts as the "computer", hiding cards and applying rules.
- **Level layouts:** draw the level on graph paper and move a coin through it, counting steps and noting what the player can see.
- **Interfaces:** sketch each screen on a card and swap cards when a "button" is tapped.

## Low fidelity on purpose

Rough materials send a useful message to testers: *this can still change*. Polished art makes people hesitant to criticise and makes you reluctant to throw things away. Keep it ugly until the rules work.

## Common mistakes

- **Prototyping everything at once.** Too many systems means you cannot tell which one causes a problem.
- **Spending hours on art.** Words and arrows are enough.
- **Never playing it yourself first.** Solo play catches broken rules before you waste a tester's time.
- **Changing many rules between tests.** Change one or two things so you know what made the difference.
- **Treating the prototype as the product.** It exists to answer a question; once answered, it can be thrown away.

## Quick recap

- A paper prototype is a cheap experiment that answers one design question.
- Use cards, dice, tokens and a pencil; leave out everything else.
- Build, play, notice, change one thing, and repeat.
- Digital ideas can be simulated on paper by turning time into turns and using a human "computer".

## Try it

Open the Do tab and build a paper prototype around a single question.


Build a playable paper prototype that tests one core question about a game idea in an afternoon.

Paper prototypes

How to Paper Prototype Your Video Game: Game Design Secrets!

Write the goal of the game in one sentence at the top of the page.

List the components with quantities (for example: 20 cards, 2 dice, 30 tokens).

Write setup as numbered steps that end with 'the first player is...'.

Write the turn as numbered steps in the order they happen. Use one rule per sentence and the same word for the same thing every time.

Write how the game ends and how a winner is decided, including ties.

Add one worked example of a full turn, and a short reference summary at the bottom.

Give the sheet and the components to someone who has never seen the game. Stay silent and watch them set up and play two turns.

Mark every place they hesitated, asked a question or played a rule wrongly. Rewrite those sentences.

## Why it matters

A game that only works when its designer explains it is not finished. Playtesters, publishers, teammates and eventually players all need rules they can follow without you. Writing rules also exposes holes in the design: if you cannot write down what happens when two effects happen at once, the game does not actually know either. In video games the same skill appears as tutorial text, ability descriptions and design specs that programmers implement.

## The core idea: order and consistency

Good rules answer questions in the order a new player asks them:

1. **What is this game about and how do I win?** (one or two sentences)
2. **What is in the box?** (components with quantities)
3. **How do I set up?** (numbered steps)
4. **What do I do on my turn?** (numbered steps, in order)
5. **How does it end?** (end condition, scoring, ties)
6. **What about special cases?** (clarifications, FAQ)
7. **Can I check quickly?** (a reference summary)

Inside that structure, consistency matters most: **one term for one thing.** If you call something a "token" in setup and a "coin" later, readers assume they are different.

## Writing style that works

- **One rule per sentence.** Long sentences hide conditions.
- **Imperative mood.** "Draw two cards." not "Players will generally want to draw some cards."
- **Bold key terms** the first time they appear and define them.
- **Numbers as numerals** ("draw 2 cards"), which are easier to scan.
- **Say what happens, not what you hope.** "If the deck is empty, shuffle the discard pile to form a new deck."
- **Examples beat explanations.** One concrete example of a turn clears up more than a paragraph of abstract rules.

## Worked example: rewriting a confusing rule

First draft:

> On your turn you can move and attack if you want, but if you attacked last turn you might not be able to move as far unless you have the boots, and monsters attack back.

Problems: order is unclear, "might" is vague, the boots condition is buried, and "attack back" has no timing.

Rewrite:

> **Your turn** has three steps, in this order:
> 1. **Move** up to 3 squares. If you attacked on your previous turn, move up to 2 squares instead (**Boots** ignore this limit).
> 2. **Attack** (optional): choose one monster next to you and roll a die. On 4 or more, it loses 1 health.
> 3. **Monster response:** every monster next to you deals 1 damage to you.

Each step is ordered, every condition is explicit and the timing of the monster's attack is clear.

## Edge cases and the "what if" pass

After drafting, read every rule and ask "what if...?":

- What if two players reach the goal on the same turn?
- What if a card tells you to draw and the deck is empty?
- What if a number would go below zero?
- What if two effects trigger at the same moment: which goes first?

Every unanswered "what if" becomes an argument at the table, or a bug in code.

## The blind test

The only real test of rules is a **blind playtest**: give the rules to someone new and stay silent while they learn. Note every hesitation and question. Those are not their mistakes; they are places your writing failed. Rewrite and test again with someone else.

## Common mistakes

- **Writing from memory, not the prototype.** Rules drift from what you actually play. Write with the components in front of you.
- **Front-loading exceptions.** Teach the normal turn first and special cases later.
- **Synonyms.** "Card", "tile" and "piece" for the same object will confuse readers.
- **Missing end and tie rules.** Players always ask, usually at the most heated moment.
- **Explaining during a blind test.** As soon as you speak, the test stops measuring your rules.

## Quick recap

- Order rules as players need them: goal, components, setup, turn, end, special cases, reference.
- One term per thing, one rule per sentence, imperative mood, concrete examples.
- Run a "what if" pass for edge cases and simultaneous effects.
- Test with a silent, blind playtest and rewrite where people hesitate.

## Try it

Open the Do tab, write a one-page rules sheet and run a blind test with someone new.


Write rules that a stranger can learn and play from without you in the room.

Writing rules

How to Write an Excellent Rulebook

6 Tips on Writing Board Game Rules - Board Game Design Time

Write down two or three questions this playtest should answer (for example: 'Do players understand how to win?', 'Is the middle of the game too slow?').

Prepare a notes sheet with columns: time, what happened, what the player said, my interpretation.

Brief the testers: say you are testing the game, not them, ask them to think aloud, and tell them you will mostly stay quiet.

Let them play. Record what they do and say, especially hesitations, rule mistakes, laughter, sighs and moments they look at their phone.

Afterwards, ask open, neutral questions: 'What was going through your mind when...?', 'What would you change?', 'When were you most engaged?'

Thank them. Then, alone, sort your notes into problems and positives, and rate each problem by how often it happened and how badly it hurt play.

Pick the top one or two problems and write the single rule change you will try for each in the next version.

## Why it matters

Designers are the worst judges of their own games. You know the rules, the intended strategies and what each card is "for", so you cannot experience the game fresh. **Playtesting** is how you find out what the game actually does to people, as opposed to what you hoped it would do. Professional studios playtest constantly, from paper prototypes to finished builds.

## The core idea: observe behaviour, then ask

The most reliable data in a playtest is **what people do**: where they hesitate, what they misunderstand, when they lean in and when they check their phone. What people **say** is useful too, but less reliable: testers are polite, guess at causes, and suggest fixes that may not be the right ones.

A useful rule from many designers: *players are usually right about where the problem is and often wrong about how to fix it.* Listen to the "where"; design the "how" yourself.

## Plan the test

Before anyone plays, decide:

- **Goals:** two or three questions the test should answer. "Is it fun?" is too broad; "Do players understand trading by turn 3?" is testable.
- **Testers:** at least one person who has never seen the game. Friends and family are fine early, but they are kinder than strangers.
- **Setup:** materials ready, rules sheet printed, a notes sheet with columns for time, behaviour, quotes and interpretation.
- **Your role:** host and observer, not teacher or salesperson.

## Run the test

1. **Brief:** "I'm testing the game, not you. Please think aloud. I'll mostly stay quiet."
2. **Watch:** let them struggle a little. Write down exact quotes and timestamps.
3. **Intervene only to unblock:** if they are completely stuck for minutes, give the minimum help and note that you had to.
4. **Debrief with open, neutral questions:**
   - "Talk me through what you were thinking when you chose to trade."
   - "When were you most and least engaged?"
   - "If you could change one thing, what would it be?"

Avoid **leading questions** such as "Did you like the trading system?" They invite polite yes answers.

## Worked example: from notes to changes

Raw notes from a test of the dungeon prototype:

| Time | Behaviour | Quote | Interpretation |
|---|---|---|---|
| 4:10 | Both testers re-read the light rule | "Wait, does moving cost light?" | turn summary unclear |
| 12:30 | Player B stops flipping rooms | "Not worth the risk." | risk too high mid-game |
| 18:00 | Player A laughs on monster card | "Of course!" | monster tension works |
| 22:00 | Both check phones | (silent) | ending drags |

Prioritise by **frequency** and **severity**:

1. Ending drags (both testers, big impact) -> try: the exit opens once 3 treasures exist in total.
2. Mid-game risk too high (one tester, medium) -> try: oil cards more common in rooms far from the start.
3. Light rule unclear (both, small but easy) -> fix the rules sheet.
4. Keep: the monster card moment.

Change one or two big things for the next test, so you can tell what worked.

## Types of playtests

- **Internal tests:** the team plays; good for broken rules, bad for "is it understandable".
- **Friends and family:** quick and easy; kind feedback.
- **Blind tests:** new players learn from the rules alone; best for clarity.
- **Targeted tests:** players from your intended audience; best for appeal and difficulty.

## Common mistakes

- **Explaining and defending.** If you argue with feedback, testers stop giving it.
- **Leading questions.** "Wasn't that cool?" tells you nothing.
- **Testing without goals.** You come away with a pile of opinions and no decisions.
- **Taking every suggestion.** Look for patterns across testers; one person's idea is a data point.
- **Waiting until the game is "ready".** Test the ugly prototype; big problems are cheapest to fix early.

## Quick recap

- Playtesting shows what the game actually does to people.
- Observe behaviour first, ask open and neutral questions second.
- Plan goals, take timestamped notes, and stay quiet unless a tester is completely stuck.
- Prioritise problems by frequency and severity, and change one or two things per round.

## Try it

Open the Do tab and run a short playtest of your prototype.


Run a playtest with clear goals, observe without leading, and turn notes into prioritised changes.

Playtesting

Playtesting - How to Get Good Feedback on Your Game - Extra Credits

HOW TO PLAYTEST!

Build a playable paper prototype, write rules others can play from, and run a playtest that produces useful notes.