Coyote Time and Jump Buffering Explained

Two small mechanics appear in every jumping game on this site, neither of which a player consciously notices. They exist to remove a specific category of failure - the one where you pressed the right button at approximately the right time and the game said no - and without them a fast runner does not feel hard, it feels broken.

Coyote time

After walking off a ledge, the game continues to accept a jump input for a short period - a tenth of a second here - as though you were still standing on the ground.

The name comes from cartoon physics, where a character runs off a cliff and hangs in the air until they notice. The mechanic is a similar grace: you have already left the ledge but the game has not committed to that fact yet.

A tenth of a second sounds trivial. At a run speed of 500 pixels per second it covers 50 pixels of travel, which is a substantial fraction of a jump's launch window, and it converts a large number of frustrating deaths into successful jumps.

Jump buffering

The mirror image. A jump pressed shortly before landing - within about 120 milliseconds here - is remembered and fires the instant the ground becomes available.

This covers the opposite error. A player who presses jump slightly too early, while still falling, would otherwise have their input silently discarded and would land and stand still at exactly the moment they needed to leave.

Together the two mechanics create a window of roughly 220 milliseconds around the actual landing frame during which a jump input works. That is wide enough to absorb ordinary human imprecision and narrow enough that timing still matters.

Why they are invisible

Because they only ever produce the outcome the player intended. A player who presses jump 60 milliseconds late does not experience coyote time - they experience having jumped.

That is the point. A good assist is one that removes failures the player would have described as unfair, without ever producing a success they would describe as unearned.

The test is whether removing them would change how the game feels rather than how hard it is. Turning both off makes the runners here noticeably worse without making them noticeably harder - deaths would go up, and every additional death would feel like the game's fault.

The related mechanics

Several other assists follow the same principle across the library.

• Mid-air slide converts into a fast drop rather than doing nothing, so the input always produces something.
• A short drag in Sword Breaker - under 40 pixels - is ignored entirely, so a stray click never costs a heart.
• The swing arc widens by the angle an enemy's radius subtends, so a wide enemy at close range is hit if it looks hit.
• Post-hit invulnerability of around a second prevents a single positioning error becoming four hits in one frame.

All four share the same design intent: the game should never punish you for something you were right about but slightly imprecise on.

How much forgiveness is too much

Both windows sit around a tenth of a second, and the size is a real design decision rather than a default.

Too small and they do nothing: the near-misses they exist to catch fall outside the window and the player still experiences the input being ignored. Too large and they begin catching inputs that were genuinely wrong, which is worse than it sounds. A jump that fires a quarter of a second after you walked off an edge reads as the game acting on its own, and a buffered input that survives too long produces a jump you no longer wanted.

The tuning target is that the player never notices either mechanic. If you can feel coyote time, it is too long; if you regularly experience an input doing nothing, it is too short. Invisibility in both directions is the whole specification.

Whether this counts as cheating

There is a reasonable objection to forgiveness mechanics: if the game is quietly correcting your input, is the skill still yours?

The answer turns on what they remove. They do not make the jump easier - the height, the arc and the inability to change direction mid-air are unchanged, and no jump becomes possible that was not possible before. What they remove is a category of failure where you made the right decision and expressed it a few hundredths of a second outside a boundary you had no way to perceive.

That boundary was never part of the challenge. It was an artefact of the simulation having discrete frames and a hard edge, and removing it makes the game measure the thing it was trying to measure - which is the opposite of cheating.

Where they are deliberately absent

Dodge inputs are not buffered. Pressing dodge during its cooldown does nothing and is not remembered, because a buffered dodge would fire at an arbitrary later moment and produce movement the player did not intend at that instant.

Attack inputs during recovery are dropped rather than queued, for the same reason. In Blade Master, mashing during recovery does nothing at all, and the recovery bar is drawn so the player can see why.

The distinction is that buffering is safe when the intended outcome is unambiguous - a jump means jump - and unsafe when the correct action depends on circumstances that may have changed by the time the buffer fires.

Frequently asked questions