Guide

Game input buffering explained

Harbor Ruins' bridge boss punished players who felt responsive. During the hammer slam's 28-frame recovery, testers mashed dodge three frames before animation end — inputs that should have been “early but fair.” The engine dropped them. On the next attempt they waited, pressed dodge one frame late, and ate a follow-up sweep. Session surveys blamed “laggy controls,” not difficulty. The refactor added a 10-frame pre-input buffer on dodge, parry, and light attack during recovery and hitstun, plus a one-slot action queue that cleared on taking damage. Perfect-dodge rate on that encounter rose 38% with zero animation changes. Input buffering is invisible when it works and catastrophic when it does not.

Input buffering stores player commands briefly so they execute the moment the character becomes able — bridging human reaction time and rigid frame data. It pairs with dodge i-frames, parry windows, and combo cancel chains. This guide covers pre-input queues, per-action buffer lengths, coyote time and jump grace, implementation patterns, the Harbor Ruins refactor, a technique decision table, pitfalls, and a production checklist.

What input buffering is (and is not)

Buffering is leniency at state boundaries, not free actions. The player presses a button while the character is still in recovery, hitstun, or a non-cancelable animation; the engine remembers that press and fires the action on the first legal frame. Without buffering, only frame-perfect inputs register — fine for frame-data lab tools, brutal for action games on consumer hardware.

Buffering is distinct from:

Input lag — delay between physical press and game receipt (display, polling, netcode). Buffering cannot fix high latency; it only helps at animation edges.
Macro / turbo — repeating inputs automatically. Buffers accept at most one early press per window in fair designs.
Assist modes — auto-dodge or slowdown. Buffers preserve skill while forgiving timing jitter.

Fighting games popularized explicit buffer systems; platformers added coyote time for jumps; action RPGs buffer dodge out of attack recovery. The pattern is genre-agnostic: anywhere strict state machines meet human thumbs, buffers help.

Buffer archetypes

Pre-input buffer (action queue)

While in state S, pressing action A stores A in a queue. When S ends (or a cancel window opens), A executes immediately. Most systems allow one queued action — a second press overwrites the first. Queue depth above one enables unintentional combo mashing and feels mushy in competitive modes.

Typical buffer lengths: 6–12 frames (100–200 ms at 60 FPS) for dodge and attack cancels; 3–6 frames for jump out of landing lag; 1–3 frames for fighting-game special-move inputs during blockstun.

Coyote time and jump grace

Coyote time lets the player jump for a few frames after walking off a ledge — the character is airborne visually but still treated as grounded for jump purposes. Jump buffering stores a jump press during landing recovery so the next hop fires on the first airborne-legal frame. Together they make platforming feel crisp without widening hitboxes.

Coyote windows of 6–10 frames are common in platformers; tighter games use 3–5. Pair coyote time with landing lag tuning so skilled players still optimize jump timing.

Leniency windows (parry, perfect dodge, QTE)

Some buffers are symmetric: the parry button pressed slightly before or after the strike's active frames still counts. This is often implemented as expanding the parry state backward and forward in time rather than a queue. Document whether early parry whiffs (risk) or is ignored (safe) — players learn different habits from each.

Directional and chord buffers

Fighting-game specials buffer motion inputs (quarter-circle + punch) across multiple frames. Store the last N directional samples and match against move templates on button press. Chord buffers (hold block, press special) need clear priority rules so block does not eat the special accidentally.

Per-action buffer policy

Not every action deserves the same leniency. A spreadsheet per character move prevents designers from accidentally making one string unbeatable.

Action	Typical buffer	Queue depth	Clear queue on
Dodge / roll	8–12 frames in recovery	1	Hit during recovery, stamina empty
Light attack cancel	6–10 frames end of swing	1	Whiff into unsafe state
Parry	3–6 frames before/after window	0 (window expand)	Failed parry punish window
Jump	6–10 coyote + 4–8 pre-land	1	Hard knockdown
Interact / use	10–20 frames near prompt	1	Leave trigger volume
Ultimate / super	0–4 frames (often none)	0	Always manual timing

High-commit actions (supers, healing items) often have no buffer so players cannot accidentally spend resources. Defensive options usually get the longest buffers because failure feels like the game stole input.

Implementation patterns

Single-slot queue struct

Each frame: if input pressed and action bufferable, set queuedAction and queueExpiryFrame = current + BUFFER_LEN. On state transition to idle or cancel window, if queue not expired, execute and clear. Expire queues on damage, grab, or hard stun unless design explicitly allows trade hits.

Consume-on-execute vs consume-on-press

Consume-on-execute keeps the queue until the action fires (fairer). Consume-on-press drops the input if the press frame was illegal even if a buffer would have helped — common bug in first-pass implementations. Unit-test both edges.

Multiplayer and rollback

Buffers must be deterministic in rollback netcode: queue state is part of the simulation frame. Serialize queue type and expiry frame in savestates. Mismatched buffer constants between client versions desync fights instantly.

Debug visualization

Ship a dev overlay: color the character when a queue is armed, show countdown frames, log dropped inputs. Harbor Ruins used this to prove 22% of failed dodges were three-frame early presses, not netcode.

Harbor Ruins bridge boss refactor

Problem: hammer slam recovery was 28 frames; dodge startup was 8 frames. Players reacting at 200 ms (12 frames) could only succeed if they pressed during the last 8 frames of recovery — a 29% visual window. Early presses vanished.

Changes:

10-frame pre-input buffer on dodge and parry during boss attack recovery and player hitstun.
One-slot queue; new press replaces old; queue clears on hit during recovery.
Parry leniency expanded 4 frames before active frames (whiff punish unchanged).
UI: subtle foot ring pulse when dodge queue armed (accessibility toggle).

Metrics after patch: perfect-dodge rate +38%, “controls unfair” survey responses −52%, average attempts to clear −1.4. No change to boss damage or i-frame count — only input leniency at boundaries.

Technique decision table

Technique	Feel	Best for	Risk
No buffering	Precise, harsh	Fighting lab, rhythm games	Blamed on “lag”; high quit rate
Pre-input queue (1 deep)	Responsive cancels	Action RPG, soulslike, brawler	Accidental double actions if depth > 1
Coyote + jump buffer	Forgiving platforming	Platformer, metroidvania	Trivializes edge jumps if too wide
Parry window expand	Readable defense	Timing parry games	Removes risk if early parry is safe
Global input lag reduction	Snappier everywhere	Competitive fighters	Does not help animation-edge timing alone
Auto-combo assist	Low skill floor	Mobile action, kids modes	Skilled players feel patronized

Common pitfalls

Buffer longer than recovery — dodge queues through entire enemy string; cap buffer to fraction of recovery.
Queue survives hitstun — player buffers dodge while getting comboed, escapes for free; clear on damage unless trade designed.
Overwrite without feedback — second press silently replaces first; players think input failed. Optional UI pulse helps.
Inconsistent per move — light attack buffers but heavy does not with no telegraph; document or unify.
Coyote time on air actions — double-jump coyote breaks level geometry; restrict to grounded jump only.
Buffer + infinite stamina — spam buffer dodge with no cost; tie execution to resource check at fire frame.
Netcode desync — buffer constants differ client/server; version and test rollback.
Fighting-game OS infinite — option-select buffers into unbeatable offense; cap OS chains in competitive modes.

Production checklist

Spreadsheet: every player action with buffer length, queue depth, and clear conditions.
Implement single-slot queue with expiry frame; consume on execute, not on press.
Clear queues on hit, grab, hard knockdown, and resource failure at execution frame.
Unit tests: press N frames before legal state, assert fire on frame 0 of legal state.
Dev overlay for queue armed / expired / dropped inputs.
Playtest with artificial +50 ms input lag; buffers should still feel fair.
Separate accessibility preset: wider parry/dodge buffers, labeled in options.
Rollback: include queue state in snapshots; lock buffer constants in netcode manifest.
Telemetry: early-input drop rate, queue success rate, post-fight control fairness surveys.
QA boss encounters with buffer off vs on to isolate timing complaints from difficulty.

Key takeaways

Input buffering bridges human reaction time and strict animation states — it is leniency at boundaries, not free actions.
One-slot pre-input queues are the default for action games — depth above one causes mush and accidental cancels.
Coyote time and jump buffering are platformer buffers — tune separately from combat recovery queues.
Clear queues on damage unless trades are intentional — buffered escape mid-combo breaks encounter design.
Harbor Ruins fixed perceived lag with 10-frame dodge buffers, not by weakening the boss — measure early-input drops before blaming netcode.