Chapter 2: Designing the Experience

Designing the Experience 🎯

Design the experience; the mechanics will follow

Chapter 1 handed you the machinery. You can now describe a game with the MDA framework, you know that the game loop runs every frame and scales its math by delta time, and you have Godot 4 installed with a project under version control. The machinery answers the question “how does a game run?” This chapter asks the harder question: what should that machine do to a human being for the next twenty minutes, and why would that person choose to come back tomorrow?

That is the job of the game designer. Designers do not start with a jump height or a damage number. They start with an experience they want a player to have, then work backward to the rules that might produce it. A stealth game wants you to feel like a patient predator; a farming game wants you to feel like the day was yours; a competitive shooter wants you to feel that the last round was lost by a decision you could have made differently. The mechanics are chosen to serve those feelings, and if the feelings do not show up in playtests, the mechanics change.

In this chapter you will learn what motivates players, how loops and economies keep a game moving, how difficulty is tuned so that players stay in a state of flow, how games tell stories, and how designers write down, prototype and test their ideas before a single production asset exists. By the end you will be able to plan a game the way a studio plans one.

2.1 — Why People Play 🧠

Ask ten players why they play and you will get ten answers: to relax, to compete, to be with friends, to see what happens next, to become good at something. Designers need something more useful than “because it is fun.” Fun is an outcome. The question is what causes it, and psychology has a well-tested answer.

Autonomy, Competence, Relatedness

Self-determination theory (SDT), developed by psychologists Edward Deci and Richard Ryan, says that people are drawn to activities that satisfy three basic needs. In 2006, Ryan and two colleagues published a study applying SDT to video games and found that the same three needs predicted how much players enjoyed a game and whether they kept playing:

Need	What it feels like	Mechanics that feed it	What starves it
Autonomy	“I chose this”	Open worlds, builds and loadouts, multiple solutions, cosmetic choices	Forced tutorials, one correct path, timers that punish exploring
Competence	“I am getting good at this”	Clear feedback, skills that deepen, readable failure, mastery ceilings	Random outcomes, unclear rules, punishing difficulty with no learning
Relatedness	“I matter to someone”	Co-op, guilds, trading, companions who react, shared progress	Toxic chat, isolation, NPCs who ignore you

Notice that none of these needs is a genre. A puzzle game and a battle royale can both satisfy competence; a life simulator and a city builder can both satisfy autonomy. Genre, as Chapter 1 described, is a bundle of mechanics. Motivation is what those mechanics are for.

Intrinsic and Extrinsic Motivation

intrinsic motivation is the drive to play because the playing is satisfying. Extrinsic motivation is the drive to play for a reward: a login bonus, a badge, a rank, a chest. Both are real, and every game uses both. The design risk is that extrinsic rewards can crowd out intrinsic ones. Psychologists call this the overjustification effect: when you pay someone for something they already enjoyed, they may start to see the activity as work. A game that hands out experience points for breathing trains its players to chase the number instead of the play, and when the number stops climbing, they leave. Chapter 5 returns to this idea when it looks at monetization ethics, because many of the industry’s most criticized practices are extrinsic hooks turned up too high.

Player Types

Not every player wants the same mix of the three needs. In 1996 Richard Bartle, who co-wrote the first multi-user dungeon, published a taxonomy of the players he watched in online text worlds: Achievers who want to win and complete, Explorers who want to find out how the world works, Socializers who play for the people, and Killers who want to impose themselves on others. His four types are still quoted in studios today, though modern research is more fine-grained. Quantic Foundry, a research company that has surveyed more than a million gamers, groups player motivation into twelve factors in six clusters, including action, mastery, achievement, social, immersion and creativity, and it has found that motivation profiles differ by age and by genre.

The MDA framework’s list of aesthetics from Chapter 1 (challenge, fellowship, discovery, expression and the others) is another map of the same territory. All of these models are tools for one habit: naming the experience before you build the mechanic.

Designing for a Need, Not a Demographic

A practical designer picks one primary need and one secondary need and writes them into a single sentence: “The player should feel like a patient predator (competence) who chose the moment to strike (autonomy).” That sentence becomes a filter. A proposed mechanic that makes the player feel rushed fails the filter and is cut, no matter how cool it looked in another game.

2.2 — Core Loops and Systems ⚙️

Once you know what feeling you are chasing, you need a structure that produces it over and over. Designers describe that structure as a set of nested loops, and they describe the resources moving through those loops as an economy.

The Core Loop

The core loop is the shortest cycle a player repeats: take an action, receive a reward, get a new goal, repeat. In Minecraft it is gather, craft, build, explore, which leads back to gather. In Vampire Survivors it is move, survive, level up, choose an upgrade, which makes surviving the next minute possible. A core loop usually takes seconds to minutes. If it is not satisfying on its own, no amount of story or unlocks will save the game, because the player spends nearly all their time inside it.

A good test: write your core loop as one sentence, then ask whether each step makes the next step desirable. If “collect coins” does not make “reach the exit” more desirable, the coins are decoration, not loop.

Loop	Time scale	Example question it answers
Moment-to-moment	Seconds	“Do I dodge or attack right now?”
Core	Minutes	“Which upgrade do I take this level?”
Meta / session	Hours to days	“What do I unlock before my next run?”

Meta Loops and Progression

The meta loop is the larger cycle that gives the core loop long-term purpose. In Hades, a single run through the underworld is the core loop; the permanent upgrades, weapon unlocks and story conversations between runs are the meta loop. The meta loop is why a player who just lost is excited to start again.

Progression, the visible growth inside the meta loop, comes in two flavors. Vertical progression makes the numbers bigger: more health, more damage. Horizontal progression adds options: new abilities, new routes, new ways to play. Vertical progression is easy to build and easy to overdo, because a player who is only “bigger” is not playing differently. The strongest progression systems change how you play, not just how hard you hit.

Economies: Sources, Sinks and Converters

Every resource in a game, whether gold, ammunition, health or time, flows through an economy. Designers Ernest Adams and Joris Dormans gave the parts standard names: a source creates a resource (mining, a paycheck, regenerating health), a sink destroys it (repairs, taxes, damage), a converter turns one resource into another (a forge, a shop), and a trader moves resources between players. When sources outrun sinks, the economy inflates and rewards stop meaning anything. The original Diablo III real-money auction house in 2012 let the best loot flow so freely that playing the game became a worse way to get gear than buying it, and Blizzard shut the auction house down in 2014.

In GDScript, a tiny economy looks like this:

# A tiny economy: one source, one converter, one sink
var ore := 0
var gold := 0

func mine_tick() -> void:          # source: ore enters the game
    ore += 1

func smelt(amount: int) -> void:   # converter: ore becomes gold
    if ore >= amount:
        ore -= amount
        gold += amount * 3

func repair_gear() -> void:        # sink: gold leaves the game
    gold = max(gold - 10, 0)

The design work is not the code. It is deciding how fast mine_tick() runs, what repair_gear() should cost, and whether the player ever feels rich.

Feedback Loops

A feedback loop is a system whose output feeds back into its input. A positive feedback loop amplifies: in Monopoly, owning property earns rent, which buys more property. Positive loops decide games quickly and make leads feel powerful, but they can make the last half hour miserable for whoever is behind. A negative feedback loop corrects: Mario Kart hands its best items to racers at the back. Negative loops keep games close and forgiving, but too much of them makes skill feel pointless. Neither type is good or bad. A designer chooses which one to use, where, and how strong, based on the experience from section 2.1.

2.3 — Difficulty, Balance, and Flow 📈

Loops keep a player moving. Difficulty decides whether they enjoy the trip. Get it wrong in one direction and the player is bored; get it wrong in the other and the player quits in frustration. The target between those two failures has a name.

The Flow Channel

Psychologist Mihaly Csikszentmihalyi spent decades studying the state people describe as being “in the zone,” and he called it flow. Flow appears when the challenge of a task closely matches the skill of the person doing it. Plot skill on one axis and challenge on the other, and flow lives in a diagonal band: above the band is anxiety, below it is boredom. Game designer Jenova Chen built his 2006 master’s thesis around this diagram and then built the games flOw and Journey to prove it could be designed for.

The catch for game designers is that skill is not fixed. Every minute of play makes the player better, so a challenge that sat perfectly in the band at minute one is boring by minute thirty. Difficulty has to rise, and it has to rise at roughly the rate the player’s skill does.

Difficulty Curves

A difficulty curve is a plan for how challenge changes over the length of a game. A straight upward line is rarely right, because players need moments to consolidate what they learned. Most well-tuned games use a sawtooth: teach a new idea in safety, test it under pressure, ease off with a reward, then introduce the next idea one notch higher. Nintendo’s level designers have described the structure of many Super Mario levels as a four-beat pattern borrowed from Japanese storytelling, kishōtenketsu: introduce, develop, twist, conclude.

Curve shape	How it feels	Where it belongs
Flat	Relaxing, then dull	Sandbox and creative modes
Straight rise	Relentless	Short arcade runs, endless modes
Sawtooth	Learn, prove, breathe, repeat	Most campaigns and level-based games
Cliff	Wall, then quitting	Nowhere, but it is the most common bug

Two tools help players find their own band. Selectable difficulty (easy, normal, hard) is a blunt instrument that changes numbers. Assist options are finer: Celeste (2018) shipped an Assist Mode that lets players slow the game speed, add air dashes or become invincible, and its developers were explicit that it was there to widen the flow channel, not to remove the challenge.

Dynamic Difficulty

dynamic difficulty adjustment (DDA) means the game measures how the player is doing and adjusts itself. Resident Evil 4 (2005) tracked the player’s performance and scaled enemy aggression and drops up or down without ever saying so. Left 4 Dead (2008) made its “AI Director” a headline feature, spawning enemies and supplies based on the team’s stress level. A simple version fits in a few lines:

# Rubber band the spawn rate from recent player deaths
var deaths_this_level := 0
var spawn_interval := 2.0   # seconds between enemy spawns

func retune_difficulty() -> void:
    if deaths_this_level >= 3:
        spawn_interval = min(spawn_interval + 0.5, 4.0)  # ease off
    elif deaths_this_level == 0:
        spawn_interval = max(spawn_interval - 0.25, 1.0) # push harder
    deaths_this_level = 0

The rule for DDA is that it must be either invisible or honest. Players who discover that the game secretly went easy on them feel cheated, which attacks the competence need from section 2.1.

Fairness and Balance

Fair is not the same as easy. A hard game feels fair when its rules are readable, its behavior is consistent, and every death can be traced to a decision the player made. Super Meat Boy and Celeste are brutally hard and still beloved because retries are instant and the fault is always yours. A game feels unfair when the rules are hidden, when outcomes are random with no counterplay, or when the player cannot tell what killed them.

Balance is the related work of making sure no single option dominates. If one weapon is always the right choice, the other weapons are not choices, and autonomy dies. Designers balance with spreadsheets, with rock-paper-scissors relationships between options, and, more than anything, with data from real players.

2.4 — Story and World 📖

Games do not need stories. Tetris has none, and it is one of the best-selling games ever made. But when a game does tell a story, the way it tells it is a design decision with a cost, a level of control, and a set of tools no other medium has. Games are the only art form where the audience is also a character.

Four Ways a Game Tells a Story

Method	The player’s role	Control vs. cost	Examples
Linear	Experiences a fixed sequence	Total authorial control; every scene must be built	Uncharted, The Last of Us
Branching	Chooses among authored paths	Player agency, but content grows with each branch	Detroit: Become Human, Baldur’s Gate 3
Emergent	Generates stories from systems	Endless variety, little authorial control	RimWorld, Dwarf Fortress, The Sims
Environmental	Reads the story from the world	Cheap to build, easy to miss	Dark Souls, Gone Home

Linear stories give writers the most control and cost the least per scene, but they can make the player feel like a passenger. Branching stories answer that with choice, and then hit a math problem: if every choice doubles the paths, ten choices means over a thousand endings to write. Real branching games use a fold-back structure, in which branches split for a while and then converge on shared scenes, so the player feels their choices matter without the studio building a thousand games.

Emergent and Environmental Storytelling

Emergent storytelling means the systems produce the story and the player becomes its author. Nobody at Ludeon Studios wrote the tale of your RimWorld colonist who fell in love, lost an arm to a raid, and then betrayed the colony; the mood system, the relationship system and the injury system produced it together, and you filled in the meaning. Emergent stories are the purest expression of the dynamics layer of MDA, because they are exactly what happens when mechanics meet a player.

Environmental storytelling lets the level be the narrator. A skeleton slumped against a locked door with a crowbar just out of reach tells a complete story in one image. Item descriptions, graffiti, the arrangement of furniture, which lights still work: all of it is text a player reads without pausing the game. For a small team this is the most efficient narrative tool there is, because the art you were building anyway now carries the story.

Ludonarrative Dissonance

In 2007, designer Clint Hocking wrote a blog post about BioShock that gave the industry a phrase it still uses. ludonarrative dissonance is the clash between what a game’s story says and what its mechanics have the player do. The classic example is an adventure hero written as a charming everyman whose gameplay involves killing several hundred people before lunch. The story says “likable”; the verbs say “mass killer.”

The fix is not to remove violence or story. It is to make the verbs agree with the theme. Papers, Please is about the moral weight of bureaucracy, so its mechanic is stamping documents while your family goes hungry. Undertale asks whether you have to kill anyone, and then lets every single fight be resolved without it. When you design a game, ask what your core verb says about the world. That verb is the loudest sentence in your story.

Worldbuilding on a Budget

Big studios write world bibles hundreds of pages long. A student team does not have to. Three questions build a world that feels deep: who has power here, what is scarce, and what changed recently? Every answer becomes a source of conflict, a set of environmental details and a reason for the player’s verb to matter. Show only the tip of it; players trust a world more when they sense there is more below the waterline than they are shown.

2.5 — Documents, Prototypes, and Playtests 📝

Everything above is thinking. Studios turn thinking into a game with three tools: a document that pins down the design, prototypes that test it cheaply, and playtests that find out whether the experience you designed is the one players actually have.

The Game Design Document

A game design document (GDD) is the written specification of a game. Twenty years ago it was a printed manual that ran hundreds of pages and was out of date the week it was finished. Today most studios keep a living wiki that the team edits as the game changes, plus a one-page summary anyone can read in five minutes. The one-pager is the part you should write first:

Section	What it answers
Experience statement	The one sentence from section 2.1: what the player feels and why
Design pillars	Three short principles every decision must serve
Core and meta loop	The two sentences from section 2.2
Player verbs	The five to eight things the player can do
Scope	What version 1 contains, and what it explicitly does not
Risks	The two or three things most likely to fail

Three pillars is the practical maximum. A team that has ten pillars has none, because no decision can be checked against all of them.

Paper Prototypes

The cheapest way to test a rule is to play it with index cards, dice and grid paper. You become the CPU, running Chapter 1’s game loop by hand: read the player’s action, update the state on paper, redraw the board. A paper prototype of a card battler or a turn-based tactics game can be built and played in an afternoon, and if the loop is not interesting on paper, it will not be interesting after six weeks of code and art. Real-time games are harder to prototype on paper, so their equivalent is the grey box: a Godot scene made of ColorRect nodes and placeholder sprites where every system works and nothing looks finished. Grey boxes are ugly on purpose. Pretty prototypes get defended; ugly ones get fixed.

The Vertical Slice

A vertical slice is one short piece of the game built to final quality in every discipline: finished art, finished sound, finished code, one real level. Publishers ask for it before they fund full production, because it proves the team can deliver the experience, not just describe it. Its opposite, the horizontal slice, has every system in the game working at a rough level. Most teams build a horizontal grey box first to find the fun, then a vertical slice to prove they can ship it. The trap is polishing the slice before the loop is proven; you end up with a beautiful thirty seconds of a game that is not fun.

Running an Honest Playtest

A playtest is a scientific instrument, and like any instrument it can be pointed at yourself by mistake. The rules of an honest playtest:

Do not help. If the tester gets stuck, the game is what is broken, not the tester. Write down where and why.
Do not explain. Any sentence you say aloud is a sentence the game failed to say.
Watch behavior, not opinions. Ask testers to think aloud while they play, and log what they did. Afterwards ask “what were you trying to do there?” rather than “did you like it?” People are polite; their hands are not.
Test early and small. Usability researcher Jakob Nielsen’s long-standing finding is that about five testers uncover most of the problems in a design, so five short sessions beat one giant one.

Logging makes playtests repeatable. Even a one-line file of events tells you which room killed everyone:

# Record what testers actually did, not what they remember
func _on_player_died(cause: String) -> void:
    var line := "%d,died,%s,%s" % [Time.get_ticks_msec(), cause, level_name]
    log_file.store_line(line)

Chapter 2 Activity: From Pitch to Paper Playtest 🃏

In this activity you will design a small game the way a studio does: motivation first, then loops, then a difficulty plan, then a real test with real people. You will need paper, index cards or sticky notes, a die or two, a browser for a little research, and your Godot project from Chapter 1. The game you design here can become the project you build in the rest of this book, so choose an idea you would be willing to spend a semester with.

Part 1: The Experience Statement

Choose one primary need from section 2.1 (autonomy, competence or relatedness) and one player type from Bartle or Quantic Foundry. Write a single experience statement: “The player should feel ___ because ___.” Then write three design pillars, each under ten words. Use a browser to find two shipped games that serve the same need and note, in one line each, the mechanic that does the work. Finally, write one mechanic you like from another game that fails your pillars, and cross it out. That crossed-out line is your first real design decision.

Part 2: Loops and Economy

On one sheet of paper, draw your core loop as a circle of three to five steps and your meta loop as a larger circle around it, with an arrow showing where they connect. Below the diagram, list every resource in the game and label each part of its economy: at least one source, one sink and one converter. Then identify one feedback loop, decide whether it is positive or negative, and write one sentence about what that choice does to the last five minutes of a session. Check every step of the core loop against the test from section 2.2: does it make the next step desirable?

Part 3: Paper Prototype and Difficulty Curve

Build the smallest playable version of your core loop with index cards, dice and a grid. Play it yourself twice, then sketch a difficulty curve for the first five rounds using the sawtooth pattern from section 2.3: mark where a new idea is introduced, where it is tested, and where the player gets to breathe. Write one fairness rule your game promises to keep (for example, “every hazard is visible for one full second before it can hurt you”). If your prototype is boring, change one rule and play again before moving on. Note what you changed and why.

Part 4: The Playtest and the Grey Box

Run your paper prototype with two people who have never seen it, following the four rules from section 2.5. Say nothing, and log at least ten observations of what they did, including where they hesitated and what they tried that the rules did not allow. Afterwards ask each tester “what were you trying to do?” at their most confused moment. Then open Godot and build a grey box of the first thirty seconds of your game using ColorRect nodes and a Label for one resource. Commit it to Git with a message that names the one rule you will change first.

Key Concepts Checklist

I can explain autonomy, competence and relatedness and name a mechanic that serves each
I can tell intrinsic motivation from extrinsic motivation and explain why too much of the latter is a risk
I can describe a game’s core loop and meta loop in one sentence each
I can identify sources, sinks and converters in a game economy and explain inflation
I can tell a positive feedback loop from a negative one and say what each does to a match
I can draw the flow channel and explain why difficulty must rise as skill rises
I can name the four storytelling methods and give an example of ludonarrative dissonance
I can write a one-page GDD with an experience statement and three pillars
I can run an honest playtest without helping, explaining or leading the tester