Latency is felt as unresponsive control

What it is

Perceived responsiveness is how immediately and credibly a player feels a character or interface reacts to input — a different question from input latency itself: latency is objective time measured in milliseconds, perceived responsiveness is a subjective judgement, and the two correlate without being identical. Latency feels "unresponsive" through more than milliseconds: whether the input is acknowledged, whether a preparatory pose is visible, whether the camera moves in sync, and whether sound and haptics arrive promptly all feed into a player's causal judgement of whether an input and its result are the same event — any one channel falling behind lowers overall perceived responsiveness even when actual system latency has not changed at all.

Why it happens

Players first feel the act of pressing a button, then expect a perceptual result to follow within a very short window; once a character begins acting only after an empty interval, the tight binding between intention and result comes apart, and the instinctive reaction is to keep pressing, press again, or pre-correct — reactions that then generate genuinely new operational errors once the system actually does respond, turning a subjective feeling of unresponsiveness into an objective source of error. A light, nearly instant acknowledgement cue (a small effect the instant a button is pressed) can effectively shorten this subjective wait, but that acknowledgement ultimately cannot substitute for the actual game state updating; if the acknowledgement and the eventual adjudication disagree over time — acknowledged but never took effect, or took effect without ever being acknowledged — the smoothness this creates in the short term gradually accumulates into distrust of the entire feedback system, and once that distrust sets in, players start doubting even the acknowledgements that are genuinely accurate.

Where it stops holding

A charge move, a heavy weapon, and attack recovery can all deliberately feel slow without this being a responsiveness problem, provided the player can see that slowness coming through some telegraph before the input itself, and can cancel the move or plan around it — whether the expectation was set in advance is the line between acceptable "slow" and an actual problem. Under a poor connection, decorative immediate feedback should not be used to mask real server-side delay, since doing so leads players to mistake a genuine network problem for a design flaw; connection state should instead be shown clearly, and local prediction should stay within a reasonable bound rather than predicting indefinitely and then correcting frequently.

Applying it

• Give a credible preparatory cue on the same frame as a consequential input, and make sure the eventual action, resource cost, and hit-state judgement catch up and stay consistent with that cue soon after — do not leave a long gap of uncertainty between the preparatory cue and the final result.
• Check that camera movement, sound, controller haptics, and animation are all reinforcing the same causal event; do not let one channel commit to a result the other channels then contradict.
• How to check: without showing players any performance data, have them describe from experience which specific inputs feel "unresponsive," then trace, frame by frame, the actual time gap between that input and each feedback channel (visual, audio, haptic) to locate exactly which channel is the culprit.

Related

• Same group: W3.01.1 Action games are extremely sensitive to latency · W3.01.3 Latency jitter is more harmful than stable latency
• Nearby: W4.01 Immediate feedback · I1 State, time, and response · W3.02 Input buffering and forgiveness
• Search terms: perceived responsiveness · input lag · game feel · action feedback