← Module 9/Level design
RU
Module 9 · Game design theory

Level design: teaching without tutorials

The best tutorial is the absence of one. A good level teaches a mechanic through structure rather than text: it introduces it in a safe context, develops it, throws in a twist, and pulls everything together at the end. And you verify that not by arguing about "clarity" but by watching live players.
~16 min🎲 design + empirics
The gist in 30 seconds
A level is a silent teacher. It teaches a mechanic through structure rather than through pop-up text. Kishōtenketsu (起承転結, the Japanese four-act conflict-free structure): ki — introduce the mechanic somewhere safe → shō — make it harder → ten — a twist (a new constraint or combination) → ketsu — a finale that needs all of it at once. SMB 1-1 and Celeste ch.1 are canonical: first the jump, then pits, then the twist, then a combined exam — never told, always shown. Levels communicate through telegraphing and affordances (a pit says "jump", a glowing ledge says "climb"), and this is verified by Valve-style playtesting: let people play with no hints, watch where they stall or miss, and fix it with telegraphing (Half-Life 2: "over here!"). And the space itself tells a story — environmental storytelling (Dark Souls: a corpse with loot = someone already tried this). Design means teaching and narrating without words, confirmed empirically.

The mechanism: introduce, develop, twist, combine

Kishōtenketsu

Unlike the Western three-act structure, this four-act one requires no conflict — it introduces an idea and explores it, then recombines at the end. Ideal for teaching:

Kiintroduce:teach the jump(safely) Shōdevelop:pits wider,higher Tentwist:+dash or amoving platform Ketsufinale:all at once —jump+dash each act is one tooth of the difficulty sawtooth: introduce → let it settle → complicate by combination → test

Celeste ch.1: ki — jumping plus wall climbing; shō — practice in a safe area; ten — the dash is introduced; ketsu — the level demands jumping plus climbing plus dashing together. Each act is a tooth of the difficulty sawtooth: introducing a mechanic lowers perceived difficulty (you are a novice again), then the ramp.

Teaching without words: affordances and "the only way through"

Miyamoto's SMB 1-1 is the benchmark silent tutorial. The first screen teaches running, jumping, that a Goomba kills you, and that a "?" block gives a mushroom — without a single line of text. The technique: introduce a mechanic where it is the only safe way out (the first Goomba forces you to learn the jump), while the environment telegraphs the action through affordances — a pit reads as "jump", a lit ledge as "climb", a narrow passage as "go this way". The player discovers the rule instead of reading it — and therefore remembers it.

Valve-style playtesting: watch, don't argue

Clarity cannot be deduced in your head — it is measured. The Valve method: let a player go through with no hints, record video plus voice, mark where they stalled or missed the goal, fix the level, repeat — until ~90% get through without instruction. The classic Half-Life 2 finding: the designer wants the player to follow an NPC; the playtest shows players getting stuck at a fork; the fix is the NPC saying "over here!" or blocking the wrong route, making the right one obvious. Telegraphing means lighting, framing, color, leading lines and blocking off the wrong path.

Why you cannot skip this: the designer suffers from the curse of knowledge — they already know the solution and cannot un-know it, so they overestimate their own clarity. Only a fresh player shows you the truth. If you break the route into N "gates" (each requiring the telegraph to be read with probability pi), the share of players who get through without stalling is the product:

P(got through)= ∏i=1Npi

10 gates at 95% telegraph each → 0.9510≈0.60; a single gate at 50% telegraph halves the whole funnel. One badly telegraphed spot ruins a level — the same leaky-bucket logic as in retention.

Environmental storytelling

Narrative through space rather than dialogue. Dark Souls: you enter a boss room and see the corpse of a previous seeker (with a weapon you can pick up), broken scenery, the architecture — and you understand that people tried before you, that someone fell here. The principle of "every object means something": significance (armour on the ground = a knight fell here / loot / both) against clutter (decorative barrels with no meaning are fine in moderation but break immersion in excess). Show, don't tell.

🕹 What to play — and what to notice

Super Mario Bros. 1-1 the silent tutorial

Miyamoto's first screen teaches everything without words: go right, jump, that the Goomba is dangerous, that "?" gives a mushroom, that the mushroom makes you big. All through object placement and "the only safe route".

🎮 Do: play only the first screen of SMB 1-1 and write out everything it taught you without a single line of text (at least 5 items). Notice how the first Goomba is placed so that jumping is the obvious way out, and the "?" block sits right in the path of that jump.

Portal one idea per chamber

Every test chamber introduces exactly one concept (a portal on a wall → on the floor → momentum conservation → the flung jump), lets you get comfortable, then combines them. The teaching is built into the structure, with almost no text.

🎮 Notice: in the early Portal chambers, note that each teaches one new thing before combining. That is kishōtenketsu in its pure form: an introduction chamber → development → twist → assembly.

Half-Life 2 / Dark Souls telegraphing and space-as-story

HL2 leads your eye (lighting, NPCs, framing) rather than your reading — the result of hundreds of playtests. Dark Souls tells its story through the placement of corpses, ruins and architecture — no cutscenes, no exposition.

🎮 Notice: in HL2, track what is leading you through the level (a light source at the end of a corridor, an NPC's movement, the one open door). In Souls, read the "story" of a room from its objects before you meet the enemy. Catch the moment you get lost yourself — that is a telegraphing failure.

Deep end · the telegraph funnel and the curse of knowledgeskippable

Clarity is a measurable quantity, not an opinion

A route through a level is a funnel: at every "telegraph gate" the player either reads the intent or stalls. End-to-end throughput P=∏pi is multiplicative, so the weakest gate dominates (as with Amdahl's law and the leaky bucket of retention). Hence the practice: don't argue "clear/unclear", measure p^i on playtesters and fix the lowest gate — this is funnel/conversion analysis, only at level scale.

The curse of knowledge

A designer cannot un-see the solution: knowing the answer, they systematically overestimate how obvious their hints are (a documented cognitive bug — the "curse of knowledge"). So internal assessment of clarity is useless: you need a fresh player, preferably from the target audience, and a silent observer (give a hint and you have spoiled the measurement). Recording plus logging stall points plus a threshold criterion (≈90% without instruction) turns clarity from a matter of taste into a metric.

Deep end · design: affordances, telegraphing, kishōtenketsu vs 3 actsskippable

Affordances and signifiers (Norman)

An affordance is what an object allows you to do; a signifier is the cue about what exactly and how. A ledge affords "climb", but the player will only realize it if there is a signifier (contrast, light, color, wear). A good level places signifiers densely wherever an action is needed and removes false ones (a pit you cannot jump should not look jumpable).

Telegraphing techniques

Light (the eye goes to the bright spot), framing and leading lines (the architecture points), color (yellow paint = "you can go here" in Uncharted/The Last of Us), contrast and movement (the eye catches animation), blocking (physically closing off the wrong route). They are layered — so that if one channel fails another still fires (redundancy against a weak gate).

Kishōtenketsu vs the Western 3 acts

The three-act structure is built on conflict (setup→confrontation→resolution). Kishōtenketsu is built on juxtaposition: it introduces, develops, delivers an unexpected fourth element and reconciles — with no conflict required. For teaching that is more accurate: a mechanic needs to be introduced and explored, not "put in conflict". Nintendo builds whole games this way.

Analogy
A good level is like a chapter of a good textbook. It does not lecture: it introduces one idea in a safe worked example, gives you a practice exercise, then a twist where the idea combines with an earlier one, and a final exercise on everything at once. And the author tests the chapter on live students (playtesting), watches where they got stuck, and rewrites the murky paragraph (re-telegraphs it) — without blaming the student. And the curse of knowledge (the author cannot un-see the solution) is exactly why you have to watch fresh readers instead of relying on "well, it's clear to me".
Why it matters
Teaching through design is one of the deepest skills in the craft: "show, don't tell", affordances and empirical iteration all meet here. It is not about "writing a tutorial" but about making the structure itself teach. And the pattern — introduce/develop/twist/combine; make the interface teach itself; verify on real people rather than on intuition — transfers one-to-one to documentation, onboarding, UX and API design.
🔁 Beyond games — where this transfers
The lesson is about teaching through structure and about clarity being measured on live people rather than deduced in your head.

ML / AI (your domain): silent teaching through a level ⇄ curriculum and learning from demonstrations: an agent learns from graded examples with no explicit instruction, and kishōtenketsu (introduce→develop→twist→recombine) ⇄ curriculum ordering plus tests of compositional generalization (can the model combine primitives it learned separately?). Valve-style playtesting ("you are not your player; don't reason about clarity, watch real users") ⇄ eval-driven development and human eval: you cannot tell by introspection whether your prompt or interface is clear to a model — you have to run it on held-out inputs and see where it breaks. The curse of knowledge ⇄ why you cannot evaluate a model on its training set and why authors overestimate their own clarity (you already know the answer). The telegraph funnel ∏pi ⇄ the reliability of a multi-step pipeline or agent chain: one weak step wrecks end-to-end performance (the weakest link). Environmental storytelling (meaning in the artifact rather than in a label) ⇄ learning from context rather than from explicit labels. And "affordances teach the interface" ⇄ designing tools and APIs for an agent: the interface should make the right action obvious (self-documenting tools, typed schemas) so that no separate tutorial is needed.

Onboarding/UX/docs: progressive disclosure, empty states that teach, "empty state as tutorial"; verified by usability testing rather than team arguments.

Engineering: a self-documenting API, the "pit of success" (the default is the correct thing), error messages that telegraph the next step.

Principle: teach through structure, not text; make the right action obvious; don't deduce clarity — measure it on fresh users and fix the weakest gate.

🔧 Take it apart, then design
🎮 Taking a silent tutorial apart ~25 min
Play SMB 1-1 (or the first Portal chambers) and build a kishōtenketsu map: what is introduced, where the development is, where the twist is, where the assembly is. Separately, write out every telegraph (what is cued and by what). Find at least one affordance without a signifier — a place where it is easy to get stuck.
🧪 Design a teaching level ~25 min, paper
Take one mechanic from your own Novgorod and lay out a kishōtenketsu level for it (4 acts) plus a telegraphing plan (how you will show it without text). Then "playtest on one person": have a friend follow your layout with no explanations and note where they got confused — that is your weakest gate.
Checklist: marked the 4 acts on a real game; listed the telegraphs and found the weak one; designed a teaching level for your own mechanic; tested it on a live person (the curse of knowledge); connected it to eval/onboarding.
Connections
foundation
Flow and difficulty — a kishōtenketsu act = a tooth of the sawtooth: introducing a mechanic doses the difficulty.
foundation
MDA and the core loop — a level is mechanics arranged so that the dynamic of learning emerges.
adjacent
Game feel — telegraphing rests on feedback: highlighting, response, movement.
adjacent
Telemetry — a playtest is a funnel: where players get stuck is where the gate is weak.
Questions worth asking
Why is a text-free tutorial better than a text one?
Because knowledge that is discovered sticks better than knowledge that is read, and because text pulls you out of flow. When a player finds the rule themselves (the first Goomba → "ah, I have to jump"), active learning kicks in: they built the model rather than taking it on faith — which encodes more deeply and transfers to new situations. A text tutorial ("press A to jump") requires reading, holding it in memory and applying it — three steps, each losing some players, and all of it breaks immersion (you are no longer in the world, you are reading instructions). Text also does not scale: players skip it. Silent design teaches while you play, through the same action you play with. A caveat: no hints at all is also bad — complex systemic games (Dwarf Fortress, Paradox) genuinely need text and a wiki; the principle is not "never write" but "try teaching through structure first, text is the last-resort crutch".
What is the "curse of knowledge" and why can't you skip playtesting?
The curse of knowledge is a documented cognitive bug: once you know something you cannot reliably imagine the state of someone who does not. A designer who knows the solution to a puzzle is physically unable to judge objectively how obvious it is to a newcomer — they systematically overestimate the clarity of their cues. So internal runs ("it's clear to me, therefore it's clear") are useless as a measurement. The only source of truth is a fresh player, preferably from the target audience, observed in silence (any hint spoils the measurement, like a test-set leak). Hence the whole Valve ritual: recording, logging stall points, a threshold criterion (~90% without instruction), iteration. It is literally the same reason you cannot evaluate a model on its training data: in both cases the evaluator "already knows the answer".
How does kishōtenketsu differ from the Western three-act structure?
The Western three-act structure is built on conflict: setup → confrontation (escalating conflict) → resolution. The drama is driven by collision. Kishōtenketsu (起承転結) is built on juxtaposition without required conflict: ki (introduction) → shō (development) → ten (the twist — something unexpected is introduced, often not directly connected) → ketsu (reconciliation — the twist and what came before converge into a new meaning). For teaching a mechanic the second is more accurate: you do not need to be in conflict with the player, you need to introduce an idea, let them get comfortable with it, show an unexpected facet (a combination) and pull it into a single understanding. Nintendo builds not just levels but whole games this way (world 1 introduces, worlds 2–3 develop, a later world twists, the finale combines). It is not "better/worse" but a different tool — for exploration and teaching rather than for dramatic tension.
How exactly do you telegraph a route without saying "go here"?
In layers of visual signifiers. Light: the eye goes to the bright spot — a light source at the end of a corridor pulls you forward (Half-Life, The Last of Us). Color: a consistent "language" — yellow paint = "you can climb/grab here" (Uncharted, TLOU), a red barrel = "this will explode". Framing and leading lines: architecture, railings, pipes and shadows point the way; art composition puts the goal at the vanishing point. Movement: the eye catches animation — a flapping flag, a bird in flight, an NPC walking ahead. Contrast: interactive things stand out from the background (slightly brighter or more detailed). Blocking: the wrong path is physically closed off or leads to an obvious dead end. The key is redundancy: put 2–3 cues on an important action so that if one channel fails (the player did not notice the light) another fires (color). And remove false signifiers — the most common cause of getting stuck is not "too few cues" but contradictory ones (something looks traversable and is not).
Further reading