Ask someone why a platformer feels good and they will talk about the jump. Ask them which specific properties of the jump and they usually cannot say, because the things that matter most are designed to be invisible.

The problem they solve

Human input timing is not frame-perfect. A player intending to jump at the edge of a platform will press somewhere in a window of several frames around that moment — sometimes slightly before, sometimes slightly after.

Without any accommodation, both ends of that window produce failures:

Pressing slightly late means you have already left the ground, so nothing happens and you fall.

Pressing slightly early means you are still airborne from a previous jump or not yet landed, so nothing happens and you keep falling.

Neither failure teaches the player anything. They understood the level, they chose the correct action, and a two-frame discrepancy discarded it. That is not difficulty — it is noise, and noise is what these affordances remove.

Coyote time

A short window after leaving the ground during which a jump input still works. Named after the cartoon convention of a character remaining briefly suspended after running off a cliff.

Ours is about 0.12 seconds — roughly seven frames at sixty per second.

The implementation is a timer that is set to the full window whenever you are grounded and counts down when you are not. A jump is permitted while the timer is above zero.

Played without it, a platformer feels subtly unresponsive in a way most players cannot articulate. They press jump, nothing happens, and they blame themselves without being sure why. Played with it, the same inputs simply work.

It is worth being clear that this does not make hard platformers easier in any meaningful sense. Gem Jump Challenge is the expert-tier precision game on this site and it uses the same 0.12 seconds as everything else. The difficulty there comes from narrow ledges and no double jump, not from punishing input timing.

Jump buffering

The mirror image. A jump press made slightly before you land is remembered and fires the moment you touch down.

Same window, same implementation in reverse: a timer set when the button is pressed, counting down, and consumed when you become grounded.

This matters most in sequences of jumps. A player landing and immediately jumping again will frequently press a frame or two early, and without buffering they simply do not jump — which reads as the game dropping an input rather than as a mistake.

Together, coyote time and buffering widen the effective input window from one frame to roughly fourteen. That is the difference between a control scheme that feels precise and one that feels random, and it costs about six lines of code.

Variable jump height

The largest single factor in how a platformer feels, and the one most often missing from amateur implementations.

The rule: releasing the jump button while still rising cuts the remaining upward velocity — to around 42 to 45 per cent in our platformers.

That turns one binary button into an analogue control. A quick tap produces a short hop; a full hold produces the complete arc; anything between produces something between. And because the cut happens on release, you can adjust after committing to the jump.

Without it, a platformer has exactly one jump, and every platform must be positioned for that single arc. Level design becomes rigid, and players describe the feel as floaty regardless of how carefully gravity is tuned.

With it, the same layout supports several approaches, and a player's precision becomes a continuous variable rather than a binary one.

The practical consequence for players: tapping should be your default. The full-height jump overshoots most narrow ledges, and holding the button is the exception rather than the norm.

Hitbox asymmetry

One more invisible affordance, not specific to jumping but part of the same philosophy.

Collection is generous. The pickup test allows a few extra pixels beyond both the player's and the collectible's radii. If it looked like a collection, it was one.

Collision is stingy. Deadly hits are tested against a box inset by a few pixels from the visual. If it looked like a near miss, it was one.

Neither changes anything on screen. Together they remove almost every moment where a platformer feels arbitrary, and they cost nothing in difficulty — you still have to be in the right place, just without a sub-pixel lottery deciding whether you were.

The principle underneath all four affordances is the same, and it is the one worth taking away: remove failures that teach nothing, keep failures that teach something. A player who falls because they misjudged a gap has learned about the gap. A player who falls because they pressed two frames late has learned nothing at all.

Key takeaways

  • Coyote time gives about 0.12 seconds to still jump after leaving a ledge.
  • Jump buffering remembers a press made shortly before landing and fires it on touchdown.
  • Variable jump height turns one button into an analogue control — the single biggest factor in platformer feel.
  • None of these make a game easier; they remove failures that taught the player nothing.

Frequently asked questions

What is coyote time?

A short window after walking off a ledge during which a jump still works. Ours is about 0.12 seconds, because pressing jump on the exact frame you leave a platform is a coin flip rather than a skill.

Does coyote time make platformers easier?

It removes a category of failure that taught nothing. The difficulty — reading the layout and executing the jump — is entirely unchanged.

What is jump buffering?

A press made slightly before you land is remembered and fires the moment you touch down. Without it, pressing a fraction early means not jumping at all, which reads as the game ignoring you.

Why does variable jump height matter so much?

Because it turns a binary button into an analogue control. Releasing early cuts the jump, so a tap gives a hop and a hold gives the full arc — and you can adjust after committing.

Put it into practice

Reading about collection routes only gets you so far. Pick a game and try one idea from this guide on your next run.

Written by Alex Morgan

Browser Games Editor & Interactive Gaming Content Specialist

Alex Morgan has spent more than eight years working with browser gaming content — writing about arcade mechanics, testing HTML5 games across devices, and breaking down why some collection systems feel satisfying while others feel hollow. Alex builds the test plan for every game we publish and writes the guides that explain the scoring underneath them.

Last reviewed on 6 September 2026.

Author profile · Editorial policy · Fact-checking policy