Coyote Time, Input Buffering, and the Art of Forgiving Controls

Coyote time and input buffering are the two most impactful forgiveness mechanics in platformer design. Neither is visible to the player. Both are immediately felt. Games that implement them feel fair and responsive. Games that don't feel like they cheat the player, even when they technically don't. The difference between a platformer players love and one they abandon often comes down to these two systems.

Coyote Time

Coyote time is a grace period after a player character runs off a platform edge, during which the jump command is still accepted. The name comes from Wile E. Coyote, who could run off cliffs without falling until he looked down. The mechanic solves a real perceptual problem: the human eye processes visual information approximately 13 milliseconds behind reality.

By the time a player sees their character leave the platform edge, it has already been airborne for several frames. The player's input - which they subjectively feel was 'on the platform' - is rejected as 'in the air.' This feels like the game cheated them. The physics didn't. The perception did. Coyote time bridges this gap by honouring the jump even after the physics says the character is airborne, for a brief window that matches the perceptual delay.

The player never notices coyote time exists. They just feel that the controls are fair. Celeste uses a 5-frame coyote window. Super Meat Boy uses a similar duration. Both are widely cited as having the best-feeling platformer controls ever made, and neither player community talks about coyote time as a feature - they talk about the controls feeling 'tight' and 'responsive.' That's the effect of invisible forgiveness done right.

Input Buffering

Input buffering is the inverse problem. Coyote time forgives late jumps (pressed after leaving the edge). Input buffering forgives early jumps (pressed before landing on a surface). A player approaching a platform sees the landing coming, anticipates it, and presses jump a fraction of a second before they touch down. Without buffering: the jump fires while still airborne, where it's invalid, and is ignored. The character lands and walks off the other side.

With buffering: the jump command is stored for a short window. The moment the character touches ground, the buffered command fires immediately. To the player, they pressed jump and jumped. Their input was honoured. They feel skilled rather than frustrated. The entire interaction is invisible - no UI, no indicator, no acknowledgement - but its absence is felt on every missed landing.

Buffering applies to more than jumps. Attack buffering during combo animations allows smooth chaining - press the next attack during the current one's recovery frames and the chain executes without gaps. Dodge buffering during recovery states lets rhythm-based action games feel fluid. Menu input buffering ensures rapid button presses in UI navigation all register rather than dropping inputs when the system is busy processing the previous one.

Implementation

Both systems use the same timer pattern. Coyote time: start a countdown when the character leaves the ground without jumping. While the timer is above zero, treat the character as if they can still jump. Reset the timer to zero when the jump executes, preventing double-jumps from the grace period.

Input buffering: when a jump input is received, start a buffer timer. Each frame, check if jumping is now valid. If valid and the buffer timer is above zero, execute the jump and clear the timer. The buffer window should be 100 to 150 milliseconds for jump - about 6 to 9 frames at 60fps. This covers the typical reaction-time gap between seeing a landing and pressing the button.

The two systems can and should coexist. A player who runs off an edge (triggering coyote time) and then presses jump slightly before they would have landed on the next platform (triggering input buffer) has both systems active simultaneously. The coyote time window should be shorter - 5 to 8 frames. The buffer window can be slightly longer - 6 to 9 frames. Combined, they create a control system that feels genuinely forgiving without ever feeling like it's doing the work for the player.

Tuning for Your Game

The right window sizes depend on your game's pace and target audience. A fast, precise platformer aimed at experienced players (Super Meat Boy) can use shorter windows - players have better reaction times and the challenge level expects precision. A casual or broad-audience platformer can use longer windows without the game feeling 'easy' - the forgiveness is invisible and players simply experience the controls as responsive.

Start with 5 frames for coyote time and 7 frames for jump buffer at 60fps. Playtest with players who are not experienced with your game - first-time players expose the moments where the controls feel unfair far more reliably than developers who know the level layout. If players repeatedly complain about 'missing' jumps they felt they should have made, increase the coyote window. If they complain about unintended jumps firing, reduce the buffer window.

Validate that your coyote time implementation clears itself correctly. The most common bug: the coyote timer persists after a wall jump or edge grab, allowing a second jump that shouldn't be available. Always zero the coyote timer when any jump executes, regardless of source. Similarly, clear the jump buffer on landing if you don't want buffered jumps to fire as immediate bounces - this is a design choice either way, but should be intentional.

The Broader Principle

Coyote time and input buffering are expressions of a broader design principle: the game should interpret player intent, not just player input. Players intend to jump at the edge of the platform. They intend to chain their attacks smoothly. The exact frame their finger depresses a button is a noisy signal of that intent, subject to reaction time variance, display lag, and the physical mechanics of pressing a button. Design systems that honour the intent, not just the signal.

Every action game genre has equivalent forgiveness mechanics. Fighting games have input leniency windows for special move commands. Racing games have correction assistance for oversteer. Rhythm games have hit windows. All of them exist for the same reason: players are not frame-perfect input machines, and games that treat them as such feel unfair even when they are technically correct. Build forgiveness in. Players won't notice it exists. They'll just feel like they're good at your game.