Coyote Time and Input Buffering: The Invisible Help in Good Controls

A knight in Trap Castle can still jump for a tenth of a second after running off a ledge. Nothing on screen says so, and nobody who plays it notices. They only notice games that don't do it, which feel sticky and unfair for reasons that are hard to name.

That window is called coyote time, after the cartoon coyote who runs off a cliff and hangs in the air before he falls. It has a partner, the input buffer, and between them they fix the two ways a human press misses a game's exact frame: a fraction too late, and a fraction too early.

Late presses and early presses

Coyote time covers the late press. When a player runs at an edge and presses jump "right at the edge", the press often lands a few hundredths of a second after the feet have left the ground. A strict game refuses the jump. A game with coyote time still treats the character as standing for a short moment.

The input buffer covers the early press. Falling toward a platform, a player presses jump just before landing, meaning to jump the instant the feet touch. A strict game drops the press because the character was still in the air. A game with a buffer remembers it for a short moment and carries it out on landing.

A useful way to compare the two is in frames. At 60 frames a second, one frame lasts about 16.7 ms.

The numbers in SalutGames

Trap Castle's coyote time is six frames, and both platformers keep a buffered press for about eight. The buffers are the longer of the two in both games, which makes sense once it's clear what each one would look like if it were too generous. A long coyote window shows: the knight would visibly jump off thin air. A long buffer is invisible, because it only means a slightly early press still counts.

In the Gravibot code, the whole system is two settings and one rule. A flip happens if the buffer is still running and the robot is standing on something, still inside its coyote time, or carrying a flip orb from the later sectors:

coyote: 0.085,
flipBuffer: 0.13,

Lost Corridors needs a much longer window because its input means something different. A swipe made while Lumi is gliding down a corridor is a request for the next junction, not for this frame, so the game holds it for 0.8 seconds and takes the turn when the junction arrives. Anything older is discarded as a stale swipe, so an old swipe can't suddenly fire three corridors later.

Forgiveness that isn't about time

Timing windows are only one kind of help. Gravibot's spikes are drawn 24 pixels tall, but the top 9 pixels, the points, don't hurt. Spike strips on the floor and ceiling also forgive their last 4 pixels at each end. Strips mounted on platforms deliberately don't, so a spiked platform can't be stood on by its corner.

Rondo's version is about consequences rather than windows. A tap that misses every timing band locks input for 400 ms, but it never ends the run.

None of this is new. Maddy Thorson, who made Celeste, published a list of the forgiveness built into that game. Besides coyote time and jump buffering, it includes half gravity at the top of a held jump, nudging the player around a corner they clip with their head, and a wall jump that works from 2 pixels away from the wall. In a game drawn at 320 by 180, that is a quarter of a tile.

Why players never see it

Every one of these systems trades a little strictness for a lot of fairness, and each is small enough to sit below what a player can perceive. Six frames of coyote time doesn't look like cheating. It looks like the jump that was pressed in time going off in time. That's the whole point: the controls do what the player meant, not exactly what the hardware recorded.

Trap Castle below runs on the 100 ms coyote time and the 130 ms buffer described above.

Sources

• Maddy Thorson, Celeste & Forgiveness
• SalutGames: game source code for Trap Castle, Gravibot, Lost Corridors and Rondo