InputIntermediate

Input Buffering

Remembering a slightly-early input and executing it the moment it becomes possible.

inputforgivenesscombatresponsiveness

Examples

Captured from this page's own interactive demo below.

Overview

Input buffering stores a press that arrives while the action can't start yet — mid-attack animation, just before landing, during a dodge — and fires it automatically the instant the action becomes legal, instead of throwing the press away.

It works because skilled players press early on purpose: they're queuing their next move, not mistiming. Dropping those inputs punishes exactly the players who are trying to play fluidly, and 'I pressed it and nothing happened' is the most damaging sentence in game feel.

Together with coyote time it forms the core of input forgiveness — fighting games have buffered inputs since the 90s (chaining combos would be nearly impossible otherwise), and the same idea makes jump-on-landing and queued attacks feel instant in any genre.

Interactive Demo

PRESS LANDS MID-SWING

Buffer Window150ms

Press Timing400ms

Use Cases

Fighting gamesPlatformerActionCombat

Best Practices

Do

✓Buffer the most recent press of each action with a timestamp, and check 'pressed within the last N ms' when the action becomes available.
✓Keep windows per-action: jump buffers of 100–200ms feel great, attack-chain buffers can be longer because the animation telegraphs the wait.
✓Clear the buffer once consumed — a single press must never fire the action twice.

Don't

✕Don't buffer forever — a press stored for a full second fires visibly on its own, which feels haunted, not responsive.
✕Don't buffer actions whose context changed (an attack buffered before taking a hit shouldn't come out of the stagger).
✕Don't combine buffering with animation-canceling carelessly — decide which one resolves first or combos will double-fire.

Common Mistakes

⚠Checking GetButtonDown only in the frame the action becomes legal, guaranteeing every early press is dropped.
⚠Storing the buffer as a bool with no timestamp, so a press from three seconds ago still counts as 'buffered'.
⚠Buffering in Update but consuming in FixedUpdate without care, occasionally losing or double-reading presses.

Implementation

Paste this into your AI assistant (Cursor, Copilot, Claude) to add the effect to your project.

Prompt

Add the "Input Buffering" game-feel effect to my project: Remembering a slightly-early input and executing it the moment it becomes possible.

How it works: Input buffering stores a press that arrives while the action can't start yet — mid-attack animation, just before landing, during a dodge — and fires it automatically the instant the action becomes legal, instead of throwing the press away.

Guidelines:
- Buffer the most recent press of each action with a timestamp, and check 'pressed within the last N ms' when the action becomes available.
- Keep windows per-action: jump buffers of 100–200ms feel great, attack-chain buffers can be longer because the animation telegraphs the wait.
- Clear the buffer once consumed — a single press must never fire the action twice.

Avoid:
- Don't buffer forever — a press stored for a full second fires visibly on its own, which feels haunted, not responsive.
- Don't buffer actions whose context changed (an attack buffered before taking a hit shouldn't come out of the stagger).
- Don't combine buffering with animation-canceling carelessly — decide which one resolves first or combos will double-fire.

Implement the effect in whatever engine/stack the project already uses and follow its existing code style. Wire it up where it makes sense.