Celeste: hard jumps, generous controls

The design bet: protect the action the player meant to take

Celeste’s basic actions include jumping, air-dashing, and climbing. Its official description pairs that compact vocabulary with demanding, expressive play. Maddy Thorson’s account of forgiveness explains techniques that widen small timing or positioning windows in the player’s favor.

Our reading is that difficulty and literal input acceptance are separate design choices. A game can demand a difficult sequence while allowing a small margin around the moment an input becomes valid. You can preserve the route problem without making every boundary an argument between the player and the collision system.

This distinction is especially useful when someone describes controls as “floaty,” “unresponsive,” or “unfair.” Those words report a real experience, but they do not identify the cause. Before changing gravity, find the input, state, and expectation involved.

A late jump and an early jump are different problems

Coyote time allows a jump briefly after leaving a ledge. Jump buffering remembers an input made shortly before landing, then applies it when the jump becomes possible. Thorson documents both in Celeste. They address opposite sides of a timing boundary.

In the first case, the player has just lost eligibility. In the second, they have not gained it yet. Calling both “make jump easier” hides the distinction and makes tuning harder. You need to know whether the input should be accepted after a state ends or remembered before a state begins.

Imagine a parcel courier stepping off a roof. The person at the keyboard sees a foot near the edge and presses jump. A strict collision check might already consider the courier airborne. A short grace window can align the result with the player’s reasonable reading of the picture.

Now imagine landing and jumping again in one continuous rhythm. A very slightly early input can disappear in a strict system. Remembering it briefly can preserve the intended sequence. The designer is not choosing the route for the player; the designer is deciding how to interpret an input near a boundary.

Play it: move the input across the boundary

Set an input just before or just after the event in this original timing diagram. Toggle the grace window and switch between leaving a ledge and landing. Read which event actually accepts the jump.

These values are deliberately visible and adjustable. They do not report Celeste’s tuning. The point is to understand the relationship well enough to investigate your own controller.

Name the skill before choosing the tolerance

Suppose a room asks the player to choose the right route and execute two direction changes. A tiny missed jump input may prevent them from even attempting the second decision. In that room, absorbing a small timing mismatch can give the intended challenge more room to work.

Now suppose the entire game is about hitting an exact musical beat. A wide acceptance window could erase the skill you meant to test. The same implementation feature can help one experience and flatten another. Start with the desired activity, not a list of control tricks to install.

Write a failure budget for one obstacle. Which mistakes should cause a miss: choosing the wrong route, jumping too early by a large amount, releasing too soon, or touching a hazard? Which tiny discrepancies should the controller absorb? This is not a numerical standard. It is a way to make your intention reviewable.

Then test the boundary cases. Try an input just inside the intended tolerance and one just outside it. If both succeed, your margin may be wider than you meant. If neither succeeds, the feature may not be connected to the state you thought it was.

Forgiveness cannot rescue a misleading picture

A grace window is not a substitute for clear geometry. If a ledge looks much wider than its collision surface, an input can feel late even when it is visually sensible. Enlarging the timing window may compensate for one approach speed while failing at another.

Check the visual and physical boundaries first. Show the character’s contact shape and the ledge’s collision edge while testing. Compare slow and fast approaches. Only then decide which small margin serves the intended motion.

Also separate a button event from a held input. Should holding jump before landing produce an automatic jump? Should a tap be remembered for a short interval? Should an input be consumed once or reused? These are product decisions about control, even when they appear as a few lines of code.

In a prototype, give yourself a temporary readout of input time, grounded state, and acceptance reason. It is much easier to repair “the buffer expired one frame before landing” than “the controller sometimes hates me.” Keep the readout out of the finished player interface unless it is part of the game’s purpose.

The next attempt starts before the next jump

An obstacle includes its recovery path. After a miss, the player has to understand the failure, return to a useful starting state, and decide what to change. If returning consumes most of the session, the game may be testing patience alongside the intended skill.

For your own room, compare the time spent on the unsolved action with the time spent repeating solved material. A long return can support tension or preparation, but it should have a reason. If it adds no new decision, try a nearer checkpoint and see whether players experiment more thoughtfully.

Keep the reset consistent. Camera position, movement state, and held inputs can change the first action after a restart. If each retry begins with a different accidental condition, a player cannot compare attempts cleanly.

A useful playtest question is “What will you try differently?” If the player can answer and immediately test the idea, you have a functioning learning loop. If they cannot identify the cause, focus on feedback. If they know the cause but dread repeating the approach, focus on recovery.

Help should preserve a meaningful way to play

Avoid treating assistance as one master switch between the real game and a lesser version. Different changes address different barriers: slower motion provides more reaction time, a clearer cue improves information, and a shorter setback reduces repetition. A player may need one while wanting the others unchanged.

This is our design recommendation, not a claim about a universal setting menu. For a small project, identify the barrier that appears in testing and offer the narrowest useful adjustment. Explain its effect in ordinary language.

You can also separate optional challenges from the route needed to continue. An expressive movement system can reward mastery without making every player perform its most demanding sequence. The important question is whether the available paths still carry the experience you promised.

For a game about practicing precision, assistance should help someone participate in that practice. It need not erase the need to read the room, make a plan, and act.

A room is a sentence. The sequence is the lesson.

A well-tuned jump is only part of a platformer. The room decides when to use it, and the next room decides whether the player can apply what they learned. Forgiving input cannot repair a sequence that asks for an unknown technique and punishes experimentation before explaining the task.

Consider an original three-room courier route. Room one asks for a short jump over a shallow gap with safe recovery. Room two uses the same gap beside a wall, introducing a need to control the landing. Room three combines a known landing with a visible moving platform. The point is not this exact order. It is that each room preserves enough of the previous problem for the new demand to be identifiable.

Write what the player should already know at the entrance and what new relationship they can learn inside. If a room introduces timing, a new surface, a new camera behavior, and a new penalty together, a failure becomes difficult to interpret. Split the question or provide a safer place to discover one part.

Change the controls and the room separately

Use the forgiveness experiment above to distinguish an input that arrived slightly late from one that arrived slightly early. Then sketch the same jump in two rooms: one with plenty of landing space, one with a narrow ledge. Input forgiveness changes whether the jump begins. Landing space changes what happens afterward. These are different design levers.

Try the jump workshop below for a broader feel comparison. Keep a note of the version you tried and the movement relationship you changed. This is an original teaching game, not Celeste's controller. The useful connection is that a control adjustment should be evaluated in a room that exposes its consequences.

Decide what a retry asks the player to repeat

A retry can repeat the useful question or repeat the journey to it. Suppose the difficult move is the final landing, but every attempt includes twenty seconds of already-mastered walking. The player practices patience more often than the landing. Move the restart closer in your prototype and see whether attempts become more informative.

That does not mean checkpoints should sit before every action. A sequence can deliberately ask for sustained execution. The question is whether repeating the earlier actions contributes to the challenge you intended. Name that challenge before deciding how much repetition belongs in it.

After a miss, ask the player which action they would change. If they name the final correction, the failure may be readable. If they cannot tell whether they pressed too early, too late, or toward the wrong target, inspect the visual and audio feedback before increasing the grace window. More tolerance can hide an unclear explanation without teaching the move.

Preserve a reason to learn when changing the demand

For our courier prototype, an assistance option could slow the moving platform while retaining the route and landing decision. Another could remove the fall penalty while keeping the movement challenge. These options change different demands. Ask which part a player wants to engage with and which part is preventing that engagement.

Do not assume one setting serves every difficulty. Reading the destination, timing a press, holding a direction, and repeating a long sequence are distinct demands. You can improve access by making information clearer even when the numerical difficulty stays the same.

The larger lesson of this study is that generosity and precision can support each other. Be precise about the challenge you want, then remove accidental demands around it. That requires observing complete rooms and retries, not just choosing a popular controller parameter.

Build one ledge and make the boundary inspectable

The lesson to take from Celeste is not “add every forgiving feature.” It is to decide which precision belongs to the player and which precision is bookkeeping the game should handle.

1. Make an original room with a ledge, a landing, and a restart. Keep the artwork simple enough to compare with collision shapes.
2. Record the input event and the moment the character leaves or reaches the floor.
3. Compare strict input acceptance with a small grace or buffer window. Test them separately before combining them.
4. Ask a player where they believed the character was when they pressed jump. Compare that belief with the visible and physical states.
5. Keep the intended route challenge fixed while revising acceptance. Then test a clearly early or late input to confirm that the challenge still exists.

Sources & further reading

Official material and creator accounts behind this analysis. The interpretations, examples, and interactive models are Dashpop’s own.

• Celeste: Maddy Makes Games’ official itch.io page
• Maddy Thorson: Celeste & Forgiveness