Early inputs must be buffered for execution
Aliases: buffered input · action queue · buffer window · game feel
What it is
Input buffering stores a valid command issued before the current action ends and triggers it at the first moment the system can actually execute it. The problem it solves is not "let players press fewer buttons" but keeping player intent from having to land precisely on a frame boundary the player cannot even see — exactly when an action truly ends is internal engine state, and there is always some gap between that and when a player feels it has ended; the buffer exists to absorb that gap.
Why it happens
In-game actions typically move through startup, impact, recovery, and a state transition, and players often decide what to do next while the previous action is still visibly playing out — this matches the natural way people anticipate and prepare for a following move. Without buffering, a reasonably timed but slightly early input is simply discarded, and the player has to wait for the window to open and press again; that arrangement lets operational rhythm end up governed by the engine's internal technical timing cuts rather than by the player's own tactical intent — which gets things backward, since what players care about is what they want to do, not which frame the engine happens to permit it on. A finite buffer preserves that continuity of rhythm, but it must accept only commands that remain legal and still aligned with the player's current intent at the moment of execution — this is what separates good buffering from a simple queue: a queue mechanically executes every historical command, while good buffering has to judge which historical commands still count by the time they can fire.
Where it stops holding
Buffering should not force through an old command the player has since regretted, or one the situation has already made obsolete — in that case the buffer betrays the player's actual current intent rather than serving it. It also should not carry a command across a state change that genuinely calls for new judgement, such as the original target having died, or the player having since changed direction; executing a stale buffered command across that kind of boundary produces a result the player experiences as "not what I want right now." Precision, competitive, or rhythm-focused play can use a shorter buffer window, provided the window's length is predictable to the player and the system gives clear enough feedback for players to know whether their input was actually captured into the buffer. One distinction worth stressing: network-level latency compensation solves a different problem and is not a substitute for a local input queue — network compensation deals with timing differences in data transmission, local buffering deals with timing differences inside the action state machine, and the two cannot stand in for each other.
Applying it
- For each category of action, separately define which specific commands can be buffered, how long the buffer window lasts, the priority among multiple buffered commands, and the specific conditions that cancel them; actively clear an invalidated buffer the moment one of the state changes described above occurs, rather than leaving stale commands sitting there waiting to misfire.
- Confirm to the player, through a small animation, a highlighted button prompt, or a preparatory pose on the character, that "this early input of yours has just been recorded" — this avoids players pressing again out of uncertainty about whether their input registered, which itself creates new misoperations.
- How to check: record every early press players make near an action boundary and check individually whether each one executes on the first legal frame the system allows; for any case that was not executed, or executed incorrectly, check whether the documented buffering rules can fully explain why — if they cannot, the rules themselves have a gap.