This course teaches the craft behind games before any engine is involved. The first module gives you a vocabulary for analysing games: the MDA framework (mechanics, dynamics, aesthetics), core loops and goals, and what motivates different players. The second module is hands-on paper prototyping: you build a playable prototype from paper and dice, write rules a stranger can follow, and run a playtest that produces useful notes instead of polite compliments. The third module covers systems and content: tuning a small resource economy in code, designing a level with a deliberate difficulty curve, and writing a one-page narrative brief. The last module is about communicating design: a one-page game design document, an honest map of studio roles and entry routes into the games industry, and a two-minute pitch. Every activity can be done at home with paper, a pen, a few dice and a browser. Game design has no licence; studios hire on a portfolio of prototypes and finished small games, and many designers also hold a game design or computer science degree.

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

## Why it matters

Everyone can say whether they liked a game. A designer has to say **why**, and then change the right thing. "The combat feels boring" is not something you can fix directly; "enemies always attack one at a time, so players never have to choose a target" is. A shared framework turns vague feelings into causes you can work on.

The most widely taught framework is **MDA**, from a 2004 paper by Robin Hunicke, Marc LeBlanc and Robert Zubek. It splits a game into three layers.

## The three layers

| Layer | What it is | Who controls it | Example (chess) |
|---|---|---|---|
| **Mechanics** | the rules, data and actions: what you can do and what happens | the designer, directly | pieces move in fixed patterns; capture by landing on a piece |
| **Dynamics** | the behaviour that emerges when players use the mechanics over time | nobody directly; it emerges | controlling the centre, forks, trading pieces, endgame technique |
| **Aesthetics** | the emotional responses players have | nobody directly; it is felt | challenge, tension, the satisfaction of a plan coming together |

The key insight is the **direction** of each view:

- The **designer** builds mechanics, hoping they create certain dynamics, which create the aesthetics they want.
- The **player** experiences the aesthetics first, notices some dynamics, and may never think about the mechanics at all.

So you design from the aesthetic you want back down to the mechanics that might produce it, then test whether it actually happens.

## Naming aesthetics precisely

"Fun" is too vague to design for. The MDA paper lists eight kinds of fun, which give you better words:

- **Sensation**: the game as sense-pleasure (sound, visuals, game feel)
- **Fantasy**: make-believe, being someone else
- **Narrative**: the game as drama
- **Challenge**: an obstacle course to master
- **Fellowship**: a social framework, playing together
- **Discovery**: uncharted territory to explore
- **Expression**: self-discovery and creativity
- **Submission**: a relaxing pastime

Most games target two or three of these. A cosy farming game leans on submission, expression and fantasy; a competitive fighting game leans on challenge and fellowship.

## Worked example: why does tag work?

Analyse playground tag with MDA.

- **Mechanics:** one player is "it"; touching another player makes them "it"; there is a play area.
- **Dynamics:** players keep their distance from "it", taunt from just out of reach, and team up loosely to distract "it". "It" picks the slowest or nearest target and tries to corner people.
- **Aesthetics:** challenge (escaping), fellowship (laughing together), sensation (running).

Now change one mechanic: **"it" must hop on one foot.** The dynamics shift (players get bolder, taunting increases) and the aesthetics shift too (less tension, more comedy). One small rule changed the whole experience. That is the MDA loop in action.

## Worked example: a design problem

A team's dungeon game is meant to feel **tense** (challenge), but playtesters say it feels like a chore. Work backwards:

1. **Aesthetic missing:** tension.
2. **Dynamic observed:** players fully clear every room, heal to full and move on. There is never a risky decision.
3. **Mechanic causing it:** healing potions are plentiful and resting is free.
4. **Change to try:** make resting cost a resource or advance a danger timer.

The fix is in the mechanics, but you found it by starting from the aesthetic.

## Common mistakes

- **Describing only mechanics.** A feature list is not a design. Always ask what dynamic each rule creates and what players feel as a result.
- **Assuming dynamics.** You cannot be sure what players will do until you watch them. MDA is a way to form hypotheses that playtests confirm or reject.
- **Targeting every aesthetic.** A game that tries to be relaxing, punishing and story-heavy at once usually does none of them well. Choose.
- **Treating MDA as the only lens.** It is a starting vocabulary. Later frameworks add story, technology and context, but the core idea of rules -> behaviour -> feeling stays useful.

## Quick recap

- Mechanics are rules you write, dynamics are behaviour that emerges, aesthetics are feelings players have.
- Designers work from aesthetics back to mechanics; players experience them the other way round.
- Name aesthetics precisely (challenge, discovery, fellowship...) instead of "fun".
- Small mechanical changes can change dynamics and aesthetics completely, so test every change.


Use the MDA framework to explain how a game's rules turn into the experience players feel.

Mechanics, dynamics, aesthetics

How To Think Like A Game Designer

MDA - Mechanics, Dynamics, Aesthetics. Core elements of game design.

Write the game's name and, in one sentence, what the player does most often from minute to minute.

Draw the core loop as 3-5 boxes connected by arrows in a circle, using verbs (for example: explore -> fight -> loot -> upgrade -> explore).

Under each arrow, write what the player gets or spends at that step (time, health, coins, items, information).

Next to the loop, list one short-term goal (seconds to minutes), one medium-term goal (a session) and one long-term goal (days or weeks).

Mark the moment in the loop where a player is most likely to quit. Write why (boredom, frustration, nothing new to aim for).

Propose one change to the loop or a goal that would keep a player going past that moment. Keep it to a single rule.

Explain your map to a friend in under a minute and ask whether it matches how they play.

## Why it matters

Players spend most of their time repeating a small set of actions. If that repetition is satisfying, they will forgive a lot; if it is not, no amount of story or art will save the game. Designers call that repeated cycle the **core loop**, and mapping it is one of the first things you do when analysing or planning a game.

## The core idea

A **core loop** is the shortest cycle of actions a player repeats, where the result of one cycle feeds the next. It is usually written as verbs:

```text
explore -> fight -> collect loot -> upgrade gear -> explore (harder area)
```

A good loop has three qualities:

1. **Clear action:** the player knows what to do next.
2. **Feedback:** each step gives a visible result (a number goes up, a door opens, a sound plays).
3. **Progression:** the output of the loop changes the next pass, so it is not identical every time.

## Loops inside loops

Most games nest loops of different lengths, and each layer has its own goal:

| Layer | Time scale | Example (a farming game) |
|---|---|---|
| **Moment-to-moment** | seconds | water a crop, hear the sound, see it sparkle |
| **Core loop** | minutes to a day in game | plant -> water -> harvest -> sell -> buy seeds |
| **Meta loop** | sessions to weeks | expand the farm, unlock a new area, finish a festival |

Short-term goals keep hands busy; medium-term goals give a reason to finish the session; long-term goals give a reason to come back tomorrow. When a game feels aimless, one of these layers is usually missing.

## Worked example: mapping a puzzle game

Take a match-three puzzle game.

- **Moment-to-moment:** swap two tiles -> match three -> tiles clear with a satisfying effect.
- **Core loop:** start level -> make matches to meet the goal within limited moves -> win or lose -> earn stars -> next level.
- **Meta loop:** collect stars to unlock new worlds; complete a themed event.
- **Resources:** moves (spent per swap), stars (earned per level), lives (spent on failure).

Now look for the quit point. A player who fails the same level five times has no new information and no progress: the loop has stalled. A designer might add a small reward for near-misses, a hint after repeated failure, or an alternate level path.

## Goals: make them visible

Players chase goals they can see. Useful goal design follows a few rules:

- **Show the next goal before the current one ends.** A visible "next upgrade costs 50 coins" gives the next loop a purpose.
- **Mix certain and uncertain rewards.** Fixed rewards build trust; occasional surprises add excitement.
- **Let players choose some goals.** Optional challenges and side quests support different motivations (more on that in the next lesson).

## Common mistakes

- **A loop with no output.** If finishing a cycle changes nothing, players feel they are running in place.
- **Too many resources in the core loop.** Five currencies in the first ten minutes overloads a new player. Introduce them one at a time.
- **Only long-term goals.** "Reach level 50" is meaningless at level 1 without smaller steps along the way.
- **Confusing the loop with the plot.** Story beats are not the core loop. The loop is what players *do* repeatedly.
- **Loops that reward the wrong thing.** If the fastest way to progress is a boring exploit, players will do it and then blame the game for being boring. Reward the behaviour you want.

## Quick recap

- The core loop is the shortest repeated cycle of player actions, written as verbs.
- Good loops have clear actions, feedback and progression.
- Games nest moment-to-moment, core and meta loops with short, medium and long-term goals.
- Find the quit point in a loop and change one rule to fix it.

## Try it

Open the Do tab and map the core loop and goals of a game you know well.


Map a game's core loop and the short, medium and long-term goals that keep players playing.

Core loops and goals

What is a “Core Gameplay Loop”?

How To Design a Gameplay Loop

## Why it matters

Two people can play the same game for completely different reasons. One wants to top the leaderboard, another wants to explore every corner, a third mostly enjoys chatting with friends. If you design only for yourself, you design for one of them. Motivation models help you see who you are leaving out, and decide on purpose whether that is fine.

## Bartle's player types

In 1996 Richard Bartle studied players of early online text games (MUDs) and described four types along two axes: whether players prefer **acting on** or **interacting with**, and whether they focus on **players** or the **world**.

| Type | Enjoys | Acts on / interacts with | Typical features they seek |
|---|---|---|---|
| **Achievers** | points, levels, completion | acting on the world | achievements, rankings, rare items |
| **Explorers** | discovering how things work | interacting with the world | hidden areas, lore, secrets, system depth |
| **Socialisers** | relationships and conversation | interacting with players | chat, guilds, co-op, emotes |
| **Killers** | competing with and dominating others | acting on players | PvP, rankings against people |

Bartle himself warns that the model was built for multiplayer worlds and that real people mix types and change over time. Use it as a checklist, not as a personality test.

## A broader lens: self-determination theory

Psychologists Edward Deci and Richard Ryan describe three basic needs that make activities intrinsically motivating. Game researchers have applied this widely:

- **Competence:** feeling effective and improving. Supported by clear feedback, fair challenge and visible mastery.
- **Autonomy:** feeling in control of your choices. Supported by meaningful options, multiple ways to solve problems and optional goals.
- **Relatedness:** feeling connected to others. Supported by co-op, communities and characters players care about.

This model works for single-player games too, and it explains why rewards alone do not create motivation: a reward that feels controlling can actually reduce autonomy.

## Intrinsic and extrinsic rewards

- **Intrinsic:** the activity is rewarding in itself (solving a puzzle, a well-timed jump).
- **Extrinsic:** a reward outside the activity (badges, currency, daily login bonuses).

Extrinsic rewards can guide attention, but if they become the only reason to play, players quit when they stop. Strong designs make the core activity satisfying first and add extrinsic rewards as signposts.

## Worked example: one level, four motivations

You are designing a single cave level in an adventure game. A quick pass with Bartle's types:

- **Achievers:** a time-trial medal and a counter for collectibles found (3/5).
- **Explorers:** a breakable wall leading to a hidden chamber with lore about the cave's history.
- **Socialisers:** an optional NPC who reacts to what the player has done; in a multiplayer version, a two-player door.
- **Killers / competitors:** a leaderboard for the time trial.

Then check self-determination theory: are there two routes through the cave (autonomy)? Does difficulty rise gradually with clear feedback (competence)? Does the NPC make the player care (relatedness)?

You may decide not to serve every type, and that is a valid design choice. The point is to decide deliberately.

## Ethics: motivation is not manipulation

Some monetised games use motivation research to push spending: limited-time pressure, loss aversion ("your streak will be lost"), and randomised paid rewards (loot boxes). Several countries regulate loot boxes, and app stores require odds disclosure. A professional designer should know these techniques, recognise when they exploit players (especially children), and push for honest design.

## Common mistakes

- **Treating player types as fixed boxes.** Players mix motivations and shift over time and between games.
- **Designing only for yourself.** Your own preference is one data point. Watch real players.
- **Adding rewards to fix a boring activity.** If the core action is not satisfying, a badge will not fix it.
- **Ignoring the audience.** A game for young children, a competitive esport and a relaxing puzzle app need very different motivational designs.

## Quick recap

- Bartle's four types (achievers, explorers, socialisers, killers) are a useful checklist from multiplayer games.
- Self-determination theory explains motivation through competence, autonomy and relatedness.
- Make the core activity intrinsically satisfying; use extrinsic rewards as signposts.
- Decide deliberately which motivations you serve, and do not exploit them.


Design for different player motivations using Bartle's types, self-determination theory and player research.

Player motivation

Bartle's Taxonomy - What Type of Player are You? - Extra Credits

Analyse games with the MDA framework, map core loops and goals, and design for what different players want.

What Makes Games Work

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.

Paper Prototyping

## Why it matters

Almost every game has an **economy**: something players earn, spend and want more of. It might be gold, health, ammunition, time, cards in hand or experience points. If resources flow in too fast, choices stop mattering and players get bored. Too slow, and they feel stuck. **Balance** is the work of tuning those flows (and the strength of options) so that choices stay interesting.

## The core idea: sources, sinks and stocks

Think of each resource as water in a tank.

- **Sources (faucets)** add to it: quest rewards, income per turn, enemies dropping coins.
- **Sinks (drains)** remove it: buying items, upkeep, repair costs, death penalties.
- **The stock** is how much the player has right now.

The **net flow** per turn is sources minus sinks. If the net flow is always positive, the stock grows without limit and prices become meaningless (inflation). If it is always negative, players run dry. Designers aim for a net flow that lets players afford meaningful things at a pace that matches the game's length.

```text
gold_next_turn = gold_now + income - upkeep
```

## Worked example: how long until the castle?

A player starts with 20 gold, earns 12 per turn and pays 4 upkeep. A castle costs 100.

- Net flow = 12 - 4 = 8 gold per turn.
- Gold needed = 100 - 20 = 80.
- Turns = 80 / 8 = **10 turns**.

If playtests show 10 turns is too long, you can raise income, cut upkeep, lower the price, or add a one-off source (a quest reward). Each lever has side effects: raising income also speeds up every other purchase. That is why designers prefer to change **one number at a time** and re-check.

## Types of balance

- **Economic balance:** the flow of resources over time (the example above).
- **Option balance:** no single strategy, weapon or character is the obvious best choice. Rock-paper-scissors is perfectly balanced because each option beats one and loses to one.
- **Difficulty balance:** challenge matches player skill (covered in the next lesson).
- **Fairness between players:** for example, first-player advantage in turn-based games.

Perfect balance is not always the goal. Some imbalance creates interest: a strong but risky option, or a character that is great on one map. What matters is that every option has a **reason to be chosen**.

## Using spreadsheets and simulations

Designers model economies in spreadsheets or small scripts before touching the game. A simple simulation answers questions like "after 30 turns, how much gold does a careful player have?" or "can a player ever get stuck with zero gold and no way to earn more?". That last one, a **dead state**, is one of the worst balance bugs, and simulation catches it early.

Pure functions (same inputs, same outputs, no side effects) are ideal for this: you can call them with hundreds of combinations and compare the results.

## Common mistakes

- **Tuning by feel only.** Write down the numbers and model them; intuition about growth curves is often wrong.
- **Forgetting sinks.** Many games add more and more rewards and end with players hoarding resources that have nothing to buy.
- **Changing many numbers at once.** You lose track of what caused the change.
- **Dead states.** Make sure a player at zero can always earn their way back.
- **Balancing only for experts or only for beginners.** Test both a careless and a careful strategy.

## Quick recap

- Economies are sources, sinks and stocks; the net flow sets the pace.
- Turns to afford something = (price - current) / net flow, rounded up.
- Balance covers economies, options, difficulty and fairness; some imbalance is healthy.
- Model with small pure functions or spreadsheets, change one number at a time, and watch for dead states.

## Try it

Open the Do tab and write the two economy functions a designer would use to tune the castle example.


Model a game's resource economy with sources and sinks, and tune it with a small simulation.

Balance and economies

How Video Game Economies are Designed

Perfect Imbalance - Why Unbalanced Design Creates Balanced Play - Extra Credits

Choose one mechanic for the level to teach, such as a double jump, a moving platform or a key that opens a door.

Draw the level as a side or top view on graph paper, divided into four sections: introduce, practise, twist, test.

In the introduce section, present the mechanic where failure is safe (a short fall, an instant retry).

In the practise and twist sections, raise difficulty one step at a time and add one new combination or complication.

In the test section, combine everything once with real stakes. Add a rest moment just before it.

Sketch the difficulty curve under the map: x is position in the level, y is difficulty from 1 to 5. Check that it rises with small dips for rest.

Play it on paper with a coin as the player and count the steps per section. Ask a friend to 'play' it by tracing with a finger and say where they think they would die.

## Why it matters

A level is where mechanics meet the player. The same jump can feel trivial, thrilling or unfair depending on where it is placed, what comes before it and what happens if you miss. **Level design** is the craft of arranging space, challenges and information so players learn, feel challenged and keep moving forward.

## The core idea: teach, then test

Many great levels follow a pattern often described as **introduce, develop, twist, conclude**:

1. **Introduce** the mechanic where failure is safe. The first gap is over solid ground, not a pit.
2. **Develop:** use it a few times with rising difficulty so the player builds confidence.
3. **Twist:** combine it with something else or change the context (a moving platform, a timer).
4. **Conclude:** a final test that uses everything, followed by a reward.

This is how many games teach without text: the level design itself is the tutorial.

## Difficulty curves

A **difficulty curve** plots challenge against time or position in a level or game. A straight line upward exhausts players; a flat line bores them. Good curves rise overall with **rhythm**: tension, then release.

```text
difficulty
 5 |                         /\
 4 |              /\        /  \
 3 |       /\    /  \  /\  /
 2 |  /\  /  \  /    \/  \/
 1 | /  \/    \/
   +--------------------------------> position
     intro   practise   twist   test
```

Rest moments (a safe room, a cutscene, an easy collectable) let tension drop so the next peak feels big. Psychologist Mihaly Csikszentmihalyi's idea of **flow** describes the goal: challenge just above the player's current skill, rising as their skill rises.

## Guiding the player

Levels also communicate where to go:

- **Landmarks:** a tall tower or bright light visible from far away gives a goal.
- **Lighting and colour:** players move toward light and toward contrasting colours.
- **Leading lines:** paths, rails, cables and edges point the way.
- **Gating:** a locked door seen early creates a goal; the key found later gives satisfaction.
- **Breadcrumbs:** collectables placed along the intended route.

## Worked example: a double-jump level

Mechanic to teach: the double jump.

| Section | Design | Difficulty |
|---|---|---|
| Introduce | a ledge too high for one jump; falling just lands you back at the start | 1 |
| Practise | three gaps, each slightly wider; the last needs good timing | 2-3 |
| Rest | a safe platform with a few coins | 1 |
| Twist | double jump onto a moving platform; missing drops you one screen back | 4 |
| Test | a sequence of all of the above over a pit, with a checkpoint just before it | 5 |
| Reward | an exit with a view of the next area | - |

Notice that the **cost of failure** rises with skill: early mistakes are free, the final test has stakes but a nearby checkpoint keeps it fair.

## Blockouts

Professional level designers build **blockouts** (also called greyboxes): the level made from plain shapes with no art. Paper sketches and grey boxes let you test layout, pacing and sightlines cheaply, just like a paper prototype tests rules.

## Common mistakes

- **Teaching and testing at the same time.** If the first use of a mechanic can kill the player, they learn to fear it, not use it.
- **Unfair failures.** Hazards the player could not see coming feel cheap. Show danger before it matters.
- **No rest.** Constant peak difficulty is exhausting and flattens the curve.
- **Designing for your own skill.** You have played the level a hundred times. New players have not; playtest it.
- **Long walks back after failure.** Place checkpoints so retries are fast.

## Quick recap

- Introduce a mechanic safely, develop it, twist it, then test it.
- Difficulty curves rise overall with rhythm: peaks and rests.
- Guide players with landmarks, light, lines, gates and breadcrumbs.
- Block out levels cheaply first and playtest with fresh players.

## Try it

Open the Do tab and design a level on graph paper with its difficulty curve.


Design a level that teaches a mechanic and raises difficulty along a deliberate curve.

Level design

5 Tips for Great Level Design

Difficulty Curves

Write a logline: one sentence with a character, a goal, an obstacle and the stakes.

Describe the world in three sentences: where, when, and the one rule that makes it different from ours.

Write a short profile of the player character: what they want, what they fear, and why the player should care.

List the three main story beats (beginning, turning point, ending), one or two lines each.

Connect story to mechanics: for each core mechanic, write one sentence on how it fits the world (for example, 'light is health because the cave spirits feed on darkness').

Note two places where the environment tells story without text (a ruined camp, a child's drawing on a wall).

Read the brief aloud in under two minutes. Cut anything that does not affect what the player does or feels.

## Why it matters

Story and world give players reasons to care: about a character, a place, a choice. But games are not films. Players act, and the story has to survive their choices, their skipping of dialogue and their wandering off to collect mushrooms. **Narrative design** is the craft of telling stories through play, and **worldbuilding** is creating a setting consistent enough that players can believe in it and act within it.

## Narrative designer vs writer

In studios these roles often overlap but are different:

- A **writer** writes the words: dialogue, item descriptions, barks.
- A **narrative designer** decides how story is delivered through systems, levels and choices, and makes sure story and mechanics support each other.

Small teams often combine both, and game designers on any team benefit from narrative thinking.

## The core idea: story through play

Games tell stories in several layers:

| Layer | What it is | Example |
|---|---|---|
| **Embedded narrative** | authored story the designer wrote | cutscenes, dialogue, quests |
| **Environmental storytelling** | story told by the space itself | a barricaded door and claw marks tell you something happened |
| **Emergent narrative** | stories that arise from systems and player actions | the time your last unit survived against the odds in a strategy game |
| **Lore** | background history, often optional | books, item descriptions, codex entries |

Strong games use several layers, so players who skip dialogue still understand the world through what they see and do.

## Ludonarrative harmony

When mechanics and story agree, they reinforce each other. When they clash, players feel it. A character described as gentle who mows down hundreds of enemies is a classic example of **ludonarrative dissonance**. You do not have to solve this perfectly, but asking "what does this mechanic say about the character and world?" makes designs more coherent.

## Worldbuilding that serves play

A believable world is consistent, not exhaustive. Focus on:

- **The core difference:** the one thing that makes this world unlike ours (magic is fuelled by memory; the sun never sets).
- **Rules and consequences:** if magic costs memories, characters who use it a lot should forget things.
- **Factions and conflict:** groups that want different things create quests and choices.
- **Visible history:** ruins, signs and changes in architecture show the past without a lecture.

Every element should eventually touch play: a place to explore, a choice to make, a mechanic it explains.

## Worked example: a narrative brief

For the dungeon game from the paper prototype lesson:

- **Logline:** A lamplighter's apprentice must descend into the flooded mines to relight the beacon before the village's last oil runs out.
- **World:** a mining village where the darkness below is alive and drinks light; oil is the most valuable thing anyone owns.
- **Character:** Mara, 15, wants to prove she is not a child; fears the dark that took her mentor.
- **Beats:** she enters the mines; she finds her mentor's lamp still burning deep below (turning point); she must choose to carry it home or use its oil to relight the beacon.
- **Mechanics fit:** light is health because the darkness drinks it; treasure is needed for the exit because the miners' tokens open the lift.
- **Environmental story:** abandoned lamps placed further and further apart; scratched tally marks on walls.

That one page gives artists, writers and level designers a shared direction.

## Common mistakes

- **Lore dumps.** Long text at the start before players care. Reveal the world as they explore it.
- **Story that ignores play.** If cutscenes say one thing and mechanics another, players believe the mechanics.
- **Too much worldbuilding, too little game.** A 50-page history no one sees does not help the player.
- **Forcing a single path in a game about freedom.** Match narrative structure (linear, branching, emergent) to the game.

## Quick recap

- Narrative design tells story through play; worldbuilding creates a consistent setting to act in.
- Use embedded, environmental, emergent and lore layers together.
- Aim for mechanics and story that agree (ludonarrative harmony).
- A one-page narrative brief aligns the team: logline, world, character, beats and how mechanics fit.

## Try it

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


Write a one-page narrative brief that ties story, world and mechanics together.

Narrative and worldbuilding

The Three Pillars of Game Writing - Plot, Character, Lore - Extra Credits

How Level Design Can Tell a Story

Tune a resource economy, design a level with a difficulty curve, and write a one-page narrative brief.

Systems and Balance

Write the title, a one-sentence high concept and the target platform and audience at the top.

List the design pillars: two or three short phrases describing the experience every decision must support.

Draw or describe the core loop in one line of verbs with arrows.

List the main mechanics with one line each, and the controls or inputs if it is a digital game.

Describe the scope: number of levels or areas, play time, and what is explicitly out of scope.

Add a small sketch or diagram (a map, a screen layout or the loop) taking no more than a quarter of the page.

List the top three risks or open questions you would test first.

Give the page to someone and ask them to explain your game back to you. Fix anything they got wrong.

## 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.


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

Game design documents

How to write a Game Design Document

One-Page Designs

## Why it matters

"Game designer" is one of the most wanted job titles in games and one of the hardest to get as a first job. Understanding how studios are organised, what each role does and how people actually get hired helps you plan a realistic route and build the right portfolio, instead of waiting for a dream job posting.

## Who makes a game

Team size ranges from one person to more than a thousand, but the same disciplines appear everywhere:

| Discipline | What they do | Example titles |
|---|---|---|
| **Design** | rules, systems, levels, balance, narrative, user experience | game designer, systems designer, level designer, narrative designer, UX designer |
| **Programming** | engine, gameplay, tools, networking, AI | gameplay programmer, tools engineer, engine programmer |
| **Art** | concept, characters, environments, animation, VFX, UI art | concept artist, 3D artist, animator, technical artist |
| **Audio** | music, sound effects, voice | sound designer, composer |
| **Production** | schedules, scope, coordination | producer, project manager |
| **QA** | finding and reporting bugs, test plans | QA tester, QA analyst |
| **Other** | community, marketing, user research, live operations, data analysis | community manager, user researcher, live-ops designer |

Design itself has specialisms. In a large studio you might be a **combat designer** or **economy designer**; in a small studio one designer covers everything.

## Studio types

- **AAA studios:** large budgets and teams, specialised roles, long projects (often several years).
- **Indie studios:** small teams (1-30), broad roles, many shipped smaller games, more risk.
- **Mobile and live-service:** ongoing updates, data-driven design, monetisation and economy roles.
- **Work-for-hire and outsourcing:** build parts of other companies' games (art, ports, QA).
- **Serious and educational games:** games for training, health or schools; overlaps with instructional design.

## What a junior designer actually does

Early-career design work is less "invent the game" and more:

- implementing content in an editor or scripting language (placing enemies, wiring quests)
- tuning values in spreadsheets
- writing specs for a feature someone else designed at a high level
- running and analysing playtests
- fixing design bugs reported by QA

Being reliable at these tasks is how designers earn ownership of bigger features.

## Entry routes

There is no licence for game design. Studios hire on evidence that you can design and ship. Common routes:

1. **Portfolio of small finished games.** Jam games (48-72 hour game jams such as Global Game Jam or itch.io jams), mods and small releases on itch.io show you can finish things. Two or three polished small games beat one unfinished epic.
2. **Degrees.** Game design, computer science, or related programmes give structure, team projects and industry contacts. Many designers have one; it is common but not strictly required.
3. **Adjacent roles.** QA, community, level scripting or programming roles are frequent stepping stones into design.
4. **Modding and level creation** in games with editors.
5. **Indie or self-published projects**, sometimes with a small team.

A strong design portfolio shows **your process**, not just screenshots: the problem, prototypes, playtest findings, what you changed and why, and the result.

## Realities to plan for

- Competition for design roles is high; the industry has had waves of layoffs, so many experienced people are also job hunting.
- Crunch (long overtime) still happens at some studios; ask about it in interviews and look for reviews.
- Many designers build skills in scripting (for example C# in Unity, Blueprints in Unreal, GDScript in Godot) because technical designers are in demand.
- Networking matters: jams, local meetups, Discord communities and conferences lead to many jobs.

## Common mistakes

- **Only applying for "game designer" titles.** Look at QA, level scripter, technical designer and indie roles too.
- **A portfolio of ideas instead of games.** Studios want playable evidence.
- **Unfinished projects.** Finishing is a skill; show it.
- **Ignoring other disciplines.** Designers who can talk to programmers and artists in their terms are easier to hire.

## Quick recap

- Games are made by design, programming, art, audio, production, QA and support roles.
- Studios range from AAA to indie, mobile, outsourcing and serious games.
- Junior designers implement, tune, document and test before owning big features.
- Entry is through a portfolio of small finished games, often with a degree or an adjacent role.


Map the main studio roles, how teams are structured, and realistic entry routes into game design.

The games industry

How to Get a Job as a Game Designer

Write a hook: one sentence that makes the game sound different, for example 'X meets Y, but Z'.

Write who it is for and why they will want it (the audience and the feeling it gives them).

Describe the core loop in one or two sentences using verbs.

Add a reason to believe: your prototype, a playtest finding, or a GIF or sketch that shows the game.

State the scope and the ask: team size, time, platform, and what you want from the listener (feedback, a teammate, funding).

Rehearse with a timer until the pitch fits in two minutes without rushing.

Deliver it and ask the listener to repeat the game back in one sentence. Note what they remembered and what they missed.

## Why it matters

Designers pitch all the time: to teammates in a meeting, to a lead when proposing a feature, to a publisher or funding body, to a game jam team at 9 pm on Friday. A clear pitch gets an idea a fair hearing; a rambling one gets it forgotten, however good the idea. Pitching is also a test of your design: if you cannot explain the game in two minutes, it may not be clear yet.

## The core idea: what the listener needs

Every listener is silently asking four questions:

1. **What is it?** (the hook and genre)
2. **Who is it for?** (audience and platform)
3. **Why will it work?** (core loop, unique angle, evidence)
4. **What do you need from me?** (the ask)

A good short pitch answers all four, in roughly that order.

## A two-minute structure

| Time | Part | Example (folding puzzle game) |
|---|---|---|
| 0:00-0:15 | **Hook** | "Fold Lands is a calm puzzle game where you fold paper maps to bring villages together." |
| 0:15-0:35 | **Audience and feeling** | "It's for players who love relaxing puzzle games and the feel of craft; every fold should feel physical." |
| 0:35-1:05 | **Core loop** | "You study a map, fold it along creases to line up roads, connect every village and unlock the next region." |
| 1:05-1:30 | **Reason to believe** | "Our paper prototype tested with eight players; all finished the first set and asked for more. Here's a 10-second clip." |
| 1:30-1:50 | **Scope** | "Two people, nine months, PC and Switch, 40 puzzles." |
| 1:50-2:00 | **Ask** | "We're looking for an artist to join the team." |

## Hooks and comparisons

A common hook format is **"X meets Y"** or **"X, but Y"**: "a farming game, but your farm is on a whale's back". Comparisons are useful because they borrow the listener's knowledge, but they also set expectations, so pick comparisons that are honest and widely known. Then add what makes yours **different**; a pitch that is only "like X" invites the question "why not just play X?".

## Show, do not just tell

Evidence persuades more than adjectives:

- a short gameplay clip or animated GIF
- a photo of the paper prototype in use
- one playtest result ("seven of eight players replayed the first level")
- a single striking piece of concept art

Avoid claims you cannot support, such as "it will be the next big hit".

## Pitching to different audiences

- **Teammates:** focus on the experience and what each discipline will get to build.
- **Leads or producers:** focus on scope, risks and how it supports the project's pillars.
- **Publishers or funds:** add market, budget, timeline, team track record and a playable build. Many publishers list what they want in a pitch deck on their websites; follow their format.

## Handling questions

Questions are good: they mean someone is engaged. Listen fully, answer briefly, and if you do not know, say so and say how you would find out ("We haven't tested that yet; it's our next playtest goal"). Do not argue with feedback in the room. Write it down.

## Common mistakes

- **Starting with lore.** "In the year 3045, the kingdom of..." loses listeners before they know what they do in the game.
- **Feature lists.** Ten features in a row are hard to remember. One hook and one loop are not.
- **No ask.** Listeners do not know what you want from them.
- **Running over time.** Respect the limit; it shows you can scope.
- **Reading slides word for word.** Rehearse until you can speak naturally.

## Quick recap

- Answer four questions: what is it, who is it for, why will it work, what do you need.
- Use a two-minute structure: hook, audience, loop, evidence, scope, ask.
- Show evidence (clips, prototype photos, playtest results) instead of hype.
- Adapt to the audience, welcome questions and stay within time.

## Try it

Open the Do tab, prepare a two-minute pitch and deliver it to someone.


Pitch a game concept clearly in two minutes, with a hook, a core loop and a reason to believe.

Pitching a game

How To Pitch Your Indie Game

Game Pitches

Write a one-page game design document, map studio roles and entry routes, and pitch a concept in two minutes.

Game Design Fundamentals

About this course

Course content

What Makes Games Work

Paper Prototyping

Systems and Balance

Communicating Design

Where this course leads

Next course on the path

Careers that use it