Input buffering and coyote time: accept near-miss jumps without duplicate actions

Widen the intended timing window

Input buffering remembers a recent press until an action becomes available. Coyote time briefly preserves ground-jump eligibility after leaving a ledge. They address opposite timing errors: pressing shortly before landing and pressing shortly after losing ground contact. Maddy Thorson's explanation of Celeste describes both techniques as part of its forgiving game feel. They adjust input acceptance without requiring a visible change to the level. [1]

Keep two pieces of state

Store a pending jump press and its timestamp separately from the last valid ground contact and the remaining ground-jump allowance. A fresh press is useful only while its buffer window remains open. Ground eligibility comes from current ground contact or an unconsumed grace window. Other rules, such as a disabled action during a cutscene, still apply.

When a jump starts, consume the pending press and the ground-jump allowance together. Otherwise a second check may turn one press into repeated jumps, or reuse coyote time immediately after a deliberate jump. Decide whether releasing the button cancels a pending press; retaining a tap and requiring the button to remain held are different policies.

Worked example: late departure and early landing

An illustrative controller uses 80 milliseconds of coyote time and a 100-millisecond input buffer. These are design-example values, not claimed Celeste constants. Last ground contact occurs at 1000 milliseconds, the player presses at 1060, and the next decision occurs at 1066. Contact age is 1066 - 1000 = 66 milliseconds, and press age is 1066 - 1060 = 6 milliseconds. Both windows permit the jump if the allowance is unconsumed.

In a separate landing, the player presses at 1940 milliseconds and lands at 2000. The stored press is 2000 - 1940 = 60 milliseconds old, so it can trigger on landing. Consume it immediately; holding the button afterward must not create another buffered press unless repeat behavior is explicitly intended.

Integrate with fresh contact information

Define when input is captured, movement resolves collisions and landing becomes known. In Godot, is_on_floor() reports the result of the last move_and_slide() call, so reading it before movement does not reveal a landing that has not yet been resolved. [2]

Process a buffered jump when a fresh landing is confirmed, and avoid refilling a consumed allowance from stale grounded data. Reset relevant state on respawn, teleport or a controller-mode change. Use one monotonic time domain for the windows and decide whether pausing freezes it. Log press time, contact time, acceptance reason and consumption to explain edge cases.

Tune the boundaries deliberately

Test presses just inside and outside both windows, repeated taps, held input, slopes and moving platforms. Long windows can cause unintended jumps after players change their minds or leave support. Distinguish stepping off a ledge from launching a jump and from intentional drop-through actions. Buffering cannot repair incorrect collision detection; coyote time should not silently grant an extra airborne jump. Measure acceptance against the intended rules, not just whether the controller feels more permissive.

Sources

• [1] Celeste & Forgiveness — Maddy Thorson, original developer explanation.
• [2] CharacterBody2D: Floor Contact and Movement — Godot Engine contributors.