Action games are extremely sensitive to latency

What it is

Input latency is end-to-end time from a player input to a corresponding change in image, sound, or game state. Action games make timing, evasion, aim, and combos core abilities, so latency consumes a time window players should control; the same few tens of milliseconds are nearly imperceptible in turn-based or menu play, because that kind of play never asked for millisecond-scale judgement in the first place — whether latency is harmful depends on what the gameplay demands of timing precision, not on a performance number considered in isolation.

Why it happens

Players predict what happens next from perceived state and adjust input ahead of time — this is feedforward control, not reaction after the fact. Latency lengthens the loop between perception and action, so a judgement that was correct when made is no longer valid for the current situation by the time its result actually appears; in narrow adjudication windows, the system can effectively finish ruling an action a "miss" before the player has even seen their input take effect. Latency also corrupts practice in a subtler way: players cannot tell whether a failure came from their own mistimed judgement or from the system's own lag, and these two require entirely different corrections — conflating them prevents players from building a stable, consistent action model, so practice stops translating into improvement.

Where it stops holding

A deliberate charge move, an attack's recovery frames, or a sense of "weight" can carry a long animation duration without that being latency — the distinguishing factor is whether that duration stays consistent with when the input was issued, the visual telegraph the animation gives beforehand, and the game's own rules; as long as players can see the charge coming and plan around it, a long animation is not by itself a responsiveness problem. Networked play needs to separate local input delay from network synchronization state — server-side sync problems should never be repackaged as "the character feels heavy," since the two call for entirely different fixes. Different devices (touch, controller, keyboard-mouse) and different display modes (cloud gaming, local rendering, different refresh rates) each tolerate a different latency budget; there is no single "acceptable number of milliseconds" that applies universally.

Applying it

• Measure the latency contributed separately by controller polling, game-engine processing, rendering, display output, and network transmission, to locate exactly which stage the problem lives in, rather than reporting one aggregate frame-rate number that hides the actual bottleneck.
• Shorten the critical path for high-frequency actions, defensive moves, and precision inputs first, since these are exactly where players are most sensitive to latency; where a given stage of delay genuinely cannot be removed, widen the adjudication window somewhat, or add predictive feedback that lets players perceive the system has already registered their input.
• How to check: record the player's actual input moment and the first visible on-screen response, then compare the two frame by frame; separately, have the same players experience different latency versions in a task with a narrow timing window and check whether their success rate and subjective rating decline together.

Related

• Same group: W3.01.2 Latency is felt as unresponsive control · W3.01.3 Latency jitter is more harmful than stable latency
• Nearby: I1 State, time, and response · W3.02 Input buffering and forgiveness · W4.01 Immediate feedback
• Search terms: input latency · end-to-end latency · game feel · response time