Players often use the same words for three different problems. A weapon feels “heavy.” A character feels “sluggish.” The controls feel “unresponsive.” In conversation these complaints blur together. In the systems that produce them, they are distinct. Treating them as interchangeable leads to the wrong fixes and the wrong conclusions about what a game is actually doing to the player’s sense of control.
The Sensation Players Report
The blurred complaint usually arrives after a failed action. The player pressed the button, the expected motion did not occur in the expected way, and the result felt wrong. Sometimes the motion was slow but deliberate. Sometimes the motion arrived late relative to the input. Sometimes the input itself seemed to vanish. From the player’s seat the emotional result can feel similar: a loss of agency. The underlying causes are not.
Three Separate Feelings
Weight is the sense that an action carries mass and commitment. Delay is the sense that the system is taking longer than expected to acknowledge an input. Bad input response is the sense that the system is inconsistently registering, buffering, or discarding what the player asked for. Each produces a different kind of friction and requires a different kind of attention.
The Suspected Machinery
The three sensations map onto different clusters of variables.
Weight: Commitment Before Result
Weight is generated primarily in the startup and body of an animation. Slow initial acceleration, visible posture change, early audio, camera adjustment, and restricted input buffering during the motion all signal that the character has taken on mass. The player feels the cost before the hit lands or the movement completes. When these signals are coherent, the action feels heavy but intentional. The player may still dislike the cost, yet they understand it as a property of the action rather than a failure of the controls.
Delay: Latency Between Request and Acknowledgment
Delay sits between the input and the first visible or audible response. It can come from input buffering rules, animation blend times, state-machine checks, network lag, or simple engine overhead. A short, consistent delay can be adapted to. An inconsistent or unexpectedly long delay breaks the sense that the character is an extension of the player’s will. The action may eventually look correct; the problem is that it did not begin when the player believed they had asked for it.
Bad Input Response: Inconsistent Registration and Priority
Bad response occurs when the system fails to accept, prioritize, or resolve inputs in a predictable way. Common sources include overly strict buffer windows, aggressive animation cancel restrictions, conflicting priority between movement and action states, or frame-rate-dependent input polling. The player presses the button and receives either nothing, the wrong action, or an action that begins only after an unpredictable additional wait. Unlike weight or clean delay, this sensation carries the specific frustration of being ignored.
The Field Test
I isolated the three sensations across several action RPGs and character-action titles on PC by forcing each variable set in turn while holding the others as steady as possible.
For weight: compared weapons and moves that differed mainly in startup acceleration, posture, and early audio while sharing similar total time-to-result.
For delay: introduced controlled additional input-to-animation latency and observed how players described the change.
For bad response: examined situations with known tight or inconsistent buffer windows, animation locks, and state conflicts, then recorded whether inputs were dropped, delayed, or misresolved.
All sessions used high-frame-rate capture and repeated identical input sequences. Exact internal timings remained hidden; the player-facing consequences were still distinguishable. The limitation is that real games rarely present pure cases—the three problems often overlap. The purest examples, however, produce recognizably different language from players.
Observable Patterns
When weight was increased without adding delay or input loss, players described the character as “slower” or “more committed” but rarely as “broken.” When clean delay was added, players said the controls felt “laggy” or “floaty.” When inputs were dropped or inconsistently buffered, the language shifted to “unresponsive,” “janky,” or “the game isn’t listening.” The vocabulary tracks the underlying machinery more closely than it first appears.
The Competing Explanation
One alternative is that players cannot tell the difference and that the distinctions are analytical rather than experiential. In casual conversation the words do blur. Under controlled comparison, however, the same players reliably sort the sensations once they are shown side by side. The confusion is real; it is not total.
A second alternative is that all three problems are simply forms of latency and should be solved the same way—by making everything faster. Speed can mask certain issues, yet it cannot convert a dropped input into a registered one, nor can it turn an intentionally heavy startup into a light one without changing the identity of the action. Treating every complaint as a request for less latency leads to systems that feel both weightless and still unreliable.
The Conclusion
Weight, delay, and bad input response are three different ways a game can distance the player from the character. Weight is a designed cost that can be respected or rejected. Delay is a temporal gap that can be consistent or erratic. Bad input response is a failure of the contract that the button will do something predictable.
When designers and players collapse the three into a single complaint about “feel,” the conversation loses the ability to diagnose. A heavy weapon is not fixed by tightening the input buffer. A dropped input is not fixed by shortening an animation. An inconsistent delay is not fixed by adding more camera shake. Each problem lives in a different part of the pipeline and answers to a different standard of correctness.
The player’s body already knows the difference. The language we use to talk about systems is what still needs to catch up.
No entries yet — sign the first.