Teach the game without a wall of instructions
A first level is a conversation with someone who has never seen your game. Give them room to notice, try, misunderstand, recover, and gradually become more capable.

In this guide
Set aside 45–60 minutes for the reading, experiments, and notebook work. You can pause between sections and return to the same project.
By the end of this lesson
- Separate learning a control from applying it under pressure.
- Create a sequence that introduces, varies, and combines a mechanic.
- Diagnose whether a failure comes from understanding, execution, or unreadable feedback.
You know far more than your first player
You open Night Mail for the hundredth time. Of course the courier can jump. Of course the striped stone is slippery. Of course a blinking lantern means the gate is open. You designed those things, so the screen looks full of information.
A new player sees a small person, some shapes, and a few decorative lights. They may not know which parts respond to input, whether the camera moves, or whether falling is reversible. They do not share your memory of yesterday’s prototype.
The first level needs to bridge that gap. Think of it as a sequence of opportunities to form and check an understanding. A written instruction can help, but it is only one part of the sequence. “Hold to jump higher” has not been learned until the player can use it and recognize what happened.
Your job is not to prevent every misunderstanding. Trying and revising an idea can be enjoyable. Your job is to make useful experimentation possible, and to keep a small misunderstanding from becoming an expensive dead end.
Compare two first levels
Both versions below teach jumping and moving ground. Their order, cues, and recovery costs differ. Choose a sequence, step through it, and predict what a first-time player needs to know at each moment.
There is no universal best order for every audience. The explanation assumes a player who has never used Night Mail’s variable-height jump. A player already fluent in that control may need less practice. State the audience before you judge the lesson.
A first level in four encounters
A low step, safe ground below
New idea: pressing makes the courier jump.
A miss lands nearby. The player can compare another attempt without a long reset.
Before reading the next encounter, predict what the player already knows. If your audience already uses these controls, which practice could you shorten?
Introduce one relationship clearly
A useful first jump can be almost embarrassingly small. A low step blocks walking, the destination is visible, and falling leaves the courier on safe ground. The player can discover that a press makes them rise and that the character lands somewhere predictable.
The important unit is the relationship between input and result. If the first jump also includes moving ground, wind, oil consumption, and a camera turn, a failure has too many possible explanations. The player may learn something, but you have made it harder to know what.
You can guide attention through contrast and placement. Put the relevant obstacle near the route, keep its silhouette clear, and avoid a competing animation directly beside it. A sign can name the input. A short demonstration can show the result. Use the fewest cues that make the situation understandable for the intended audience.
Do not hide basic controls just to make the player feel clever. Discovering an interesting strategy is different from guessing which keyboard key you chose. If the design depends on a control, offer an accessible way to learn it. Mystery belongs where it creates a worthwhile question.
Then vary what the player just learned
Once a short press clears the low step, a slightly higher ledge can invite a longer press. The scene changes one relevant property: the height needed. The player can carry forward the idea that pressing causes a jump while investigating how the duration changes it.
Next, a wider gap asks for timing and movement together. Later, a moving raft introduces a destination that changes position. The sequence builds on previous understanding instead of discarding it. This is transfer: a learned relationship becomes useful in a new situation.
Varying one property at a time is a useful early teaching technique, not a law for every level. Once players have a stable grasp of the pieces, combinations can be the interesting part. A moving raft beneath a low branch asks them to choose both when and how high to jump.
Watch for accidental changes that muddy the lesson. If the higher ledge also uses a new surface texture and a different camera angle, the player may blame the texture when a short jump fails. You intended to teach jump duration; they may learn a superstition about blue stones.
In your sketch, label what each encounter assumes and what it adds. If an encounter adds three unfamiliar ideas, decide which one deserves the player’s attention. Move the others later or make their role obvious enough that they do not become separate puzzles.
Play it: decide how much to show
Deliver the parcel to the tray using angle and power. Try a few throws without the flight guide. Then reveal it. The guide shows the predicted path for these exact rules, including rebounds. It gives away information rather than changing the throw.
Compare learning the relationship with following the preview. Both can suit a game, but they are different activities. A planning puzzle might deliberately show the whole path. A game about judging distance might offer a shorter hint, a practice area, or the trace of your last attempt instead.
Special delivery
Land a parcel in the tray. Set the angle and power, then launch. First try without the flight guide. Turn it on and notice which part of the task becomes easier.
Ready. Predict the result, then launch.
What this little world does
The ball follows gravity, rebounds from walls, and loses some speed at each impact. The tray catches a descending ball that fits inside it. Each attempt stops after eight seconds. Numbers use this scene’s own units; these settings are for comparing behavior, not real-world measurements.
The guide shows this scene’s exact predicted path. Does it help you learn the relationship between angle and distance, or let you avoid learning it? Try turning it off again.
- Try one successful throw with the guide, hide it, then change the angle. Can you predict how the landing moves?
- Keep your last trace and change only power. Use the two paths to explain the error instead of calling the controls “weird.”
- Design a first encounter with less help than the complete guide but more help than a blank scene. What should the player notice? What evidence would show that they learned it?
Make the result explain the attempt
After a failed jump, what information remains? If the screen instantly cuts to a restart, the player may never see whether they hit the branch, fell short, or slid off the landing. A brief readable result can teach more than a loud failure sound.
Useful feedback distinguishes causes. A soft bump against the branch suggests excessive height. A short landing splash shows the missing distance. A slippery-foot animation suggests the surface. These cues should support the actual rules; they should not merely decorate the same generic failure.
Success also needs explanation. A gate opening in the distance may go unnoticed if the camera is focused on the courier. A change in the lantern, a short sound, or a visible connection between the switch and gate can help the player understand what their action accomplished.
Avoid depending on one sensory channel. Pair color with shape or text. Provide an alternative to an important sound. Let essential information remain visible long enough to be read. A cue that exists for three frames is technically present and practically absent for many players.
When you test, ask the player what they think happened after an attempt. If they give the wrong explanation confidently, your feedback may be teaching the wrong rule. That is different from a player who understands the mistake but needs practice executing the correction.
The retry is part of the lesson
Imagine failing a ten-second jump and then spending ninety seconds walking back. The game has made the cost of practice much larger than the action being practiced. A player may become cautious, bored, or unwilling to try a variation.
A nearby recovery point creates a different rhythm: attempt, read the result, adjust, try again. The player can compare attempts while the previous one is still easy to remember. That rhythm is especially useful when you are teaching a new control.
Not every game needs frequent checkpoints. A long expedition may deliberately make preparation and risk matter. But consider whether the recovery cost belongs to the intended skill. If the player is learning a basic input, a long penalty often teaches avoidance more effectively than competence.
Also inspect the physical path back. Does restart put the player facing the obstacle? Are moving objects in a predictable state? Is there enough time to orient before danger returns? A checkpoint that respawns the courier into immediate failure can make the recovery system part of the problem.
For Night Mail’s first raft, place safe ground below it and let the courier climb back quickly. Later, once the mechanic is understood, you can use a more consequential crossing. The same action can carry different stakes at different points in the learning journey.
Difficulty has several ingredients
A level can become harder because the player has less time, less information, more things to track, more precise inputs, or a greater cost of failure. These changes do not feel the same. Treating them as one difficulty slider hides useful design choices.
If the player understands the route but cannot land the jump, you may be looking at execution difficulty. If they can perform every movement but cannot identify a route, you may be looking at planning or perception. If they succeed when alone but fail while reading several counters, attention may be the bottleneck.
Choose which demand belongs in the moment. Night Mail might ask for calm route planning, so pausing at a junction should be safe. If oil drains while the player reads route signs, you have added time pressure to a reading task. That may work for an urgent delivery game, but it changes the experience.
Difficulty options can target these ingredients separately. A longer input window preserves route planning. A route hint preserves movement practice. A checkpoint reduces the cost of failure. An option does not need to flatten every dimension to help a player.
Do not label players as simply skilled or unskilled after one observation. Someone can be experienced with strategy games and unfamiliar with touch controls. Someone can understand your rules but have difficulty distinguishing the current palette. Design and test for the task in front of you, not a single imagined average player.
Give understanding time to settle
A sequence of demanding encounters without a pause can exhaust the player before they have time to appreciate their progress. A quiet stretch lets them use a learned skill with less pressure, notice the world, and anticipate what comes next.
A rest is not necessarily empty walking. The courier might pass a familiar landmark from a new angle, deliver a letter without a hazard, or choose an optional scenic path. These moments can reinforce competence and meaning without introducing another rule.
Likewise, a surprise is not necessarily a difficulty spike. A known bridge appearing in a changed context can renew attention. A friendly character using a mechanic the player learned can make the world feel coherent. Pacing is about the sequence of demands and responses, not only enemy density.
Sketch the player’s likely questions along your level. “What can I do?” “Can I do that again?” “Does it work here too?” “What happens if I combine these?” “Can I take a breath?” If every moment asks the same question at a higher speed, consider whether you are building a curve or simply turning a dial.
Difficulty is also the price of another attempt
Jesper Juul’s The Art of Failure examines a familiar puzzle: we seek out games even though failing at them can feel bad. That tension is worth keeping in view. “Players should never fail” and “frustration proves the game is good” are both poor design shortcuts.
For Night Mail, keep one tricky jump exactly the same and move its checkpoint. A nearby checkpoint makes the next attempt cheap. A distant one makes the player repeat a solved route first. The physical challenge has not changed, but the cost of learning it has.
Use the calculator below to compare those costs. It holds success chance constant to isolate the retry overhead. Real players learn, get tired, and change strategy, so its result is a deliberately limited estimate. Ask what each attempt teaches before deciding which number is desirable.
Same jump. Different walk back.
Each attempt takes ten seconds. Change the fixed success chance and the return journey after a miss. Predict which change saves more practice time before moving a slider.
Expected time to one success: 220 seconds
4.0 attempts on average, including 3.0 failed attempts. About 180 seconds go to the return journey. With an immediate retry, the estimate is 40 seconds.
What this calculation assumes
Attempts are independent with a fixed probability of success. Expected attempts = 1 ÷ success probability. Return time is paid only after failures. The estimate includes the successful attempt. It does not model learning, fatigue, loading screens, or a player stopping.
Keep the chance fixed and remove the walk back. The jump is still as demanding in this model. What changed was the cost of practicing it. When would a return journey contain a worthwhile new decision?
Give a failed attempt something useful to say
A player misses a ledge. “You failed” is accurate but unhelpful. Did they jump too late, release too soon, misunderstand the control, or aim at scenery that looked solid? Design the feedback around the distinction the player needs to make.
For a variable-height jump, you could make the jump arc visibly respond while the button is held. Place a low ledge before a high one so the player can compare short and long holds. If they hit a ceiling, a brief contact response helps distinguish “I jumped too high” from “the button did nothing.” Avoid relying on color or sound alone to carry the explanation.
Next inspect the reset. Does the camera return to a useful view? Is the character immediately controllable? Is there an accidental input carried over from the previous attempt? A fair obstacle can feel erratic when its restart state changes under the player’s hands.
Longer setbacks can still support an intended experience. A journey may depend on preparing carefully because returning home matters. In that case, test whether a setback creates a new plan or merely a long walk through solved material. Keep the consequence that supports the game’s purpose; question the repetition that does not.
Try a paper critique with three versions of your obstacle. Version A retries immediately with no explanation. Version B retries immediately with clear cause feedback. Version C adds a long return journey. Write what the player could learn from the first three failures in each version. If the answers are identical, explain what the added time is for.
Finally, give someone a way to practice the demanding action without its largest penalty. This may be a safe ledge, an optional practice route, or a setting that reduces the setback. You can preserve a demanding challenge while offering more than one way to learn it.
Sketch a five-encounter teaching sequence
For each encounter, write what you expect the player to understand afterward. Then write one wrong explanation they might form. This second line is often the more useful one. It makes you look for ambiguous textures, hidden rules, and feedback that arrives too late.
You can test the sequence on paper by asking someone to explain what they would try. That tests interpretation and planning. It does not test jump timing or touch comfort. Use a small playable version when the lesson depends on those things. Match the prototype to the question.
- Choose one mechanic and one audience assumption. For example: a player new to holding a button for a longer jump.
- Create a safe encounter that reveals the basic input-result relationship.
- Create a second encounter that changes one relevant property.
- Create a third that applies the skill in a new context.
- Create a fourth that combines it with one previously understood idea.
- Finish with a lower-pressure encounter that lets the player use what they learned.
- Mark the recovery path and feedback for every possible failure.
A worked diagnosis: the player keeps tapping
Our tester clears the low step, then fails the taller ledge six times. We assume the jump is too difficult. On closer observation, every attempt is a short tap. The player says, “I think I need to stand closer.” They never learned that holding changes height.
We add a safe practice space with two visible jump arcs and a short “hold for a higher jump” cue. The tester now changes the hold duration. Some attempts still fail, but the adjustments are relevant. We have moved from a misunderstanding to practice.
In a second test, a player holds correctly but releases after a delayed visual response. That suggests a control or feedback issue, not a need for more tutorial text. The same failed ledge can reveal different problems.
Your sequence is ready to prototype when you can explain what each encounter teaches, how a failed attempt informs the next, and how the player recovers. The next lesson turns that plan into the smallest useful experiment, without accidentally signing up to build the whole garden.
Put your idea to work with the Dashpop Game Engine. Describe a game, play it quickly, and shape it yourself. Start with one change you can test.