Feedback: how a game tells the player it heard them

Three questions, in order

Every action the player takes asks three questions, and each one needs its own answer at its own moment. Collapsing them into a single response is the root of most feedback problems.

1. Did the game hear me? Answered immediately, by the control itself. A press state, a click, a small movement. This is separate from whether the action succeeds.
2. Did it work? Answered when the action resolves. The purchase completed, the shot fired, the door opened, the request failed.
3. What changed? Answered by the world and the interface afterwards. Currency went down, the item is in the inventory, the enemy is on fire.

The first is the one that gets missed, because engineers reasonably attach the response to the result. When the result takes 200 milliseconds to compute, the player spends 200 milliseconds believing the game is broken.

The timing budget

Interface research has settled on some thresholds that transfer well to games, and they are useful as a budget rather than as rules.

• Interface animation lives between about 150 and 300 milliseconds. Faster feels abrupt on large elements, slower feels sluggish on small ones.
• Fade out faster than you fade in. Leaving costs less attention than arriving.
• Never animate the thing the player is waiting for. Animate the frame around it and show the content immediately.
• Reduce or disable interface motion on request, which is both an accessibility feature and a preference many players have.

Layers, and the order they arrive

A single satisfying action is usually four or five cues stacked within a few frames, and the stacking order matters more than any individual cue.

Telegraphing: feedback before the event

The feedback that decides whether a fight feels fair happens before anything hits the player. A death the player saw coming and mistimed is a lesson. A death with no warning is a complaint.

• Every attack needs a windup the player can read, long enough to respond to and distinct enough to identify at a glance.
• Tells must survive the busy frame. A subtle animation is invisible when three enemies and a particle system are on screen. This is the same problem as HUD legibility over gameplay, covered in seven HUD mistakes.
• Danger zones read better than danger objects, because they say where, not just what.
• Off-screen threats need on-screen warning, or the player learns the camera is the enemy.
• Keep the vocabulary consistent. If red means unblockable, nothing else is red, and everything unblockable is.

Confirming without interrupting

Most confirmations should not be modal. A modal stops the game, takes focus, and demands a decision; it is the heaviest tool available and it gets used for the lightest events.

The test: if the player would always press the same button, the dialog is a speed bump rather than a safeguard. Delete it and make the action undoable instead.

Failure feedback, the least designed thing in most games

Players tolerate losing. They do not tolerate not knowing why they lost, and the difference between those two is entirely feedback.

1. Name the cause. What killed them, from where. Damage direction indicators are the single highest-value feedback element in most action games.
2. Show the last hit. A brief slow-motion, a highlight, a damage number, anything that connects the death to its cause.
3. Do not hide the moment behind a fade. Cutting to black instantly removes the only evidence the player had.
4. Retry in one press, holding focus, with no menu in between. The gap between failure and the next attempt is where sessions end.
5. Show progress across failures in games where runs accumulate something. It converts a loss into a step.
6. Never blame the player in text. Say what happened; the failure is already communicated.

Rewards and the moment of receipt

• Show it at the moment it happens, not in an end-of-level summary. A reward that appears three minutes later belongs to nothing.
• Show what it is and where it went, so the player can find it again.
• Offer the next action: equip it, use it, open it. A reward that ends in a dead end wastes its own momentum.
• Scale the celebration to the event. If a common drop gets the same flourish as a rare one, the flourish stops meaning anything.
• Let players skip the celebration on the hundredth time. Anything unskippable becomes an irritation at volume.

When feedback lies

Feedback is a trust mechanism, and a few common patterns spend that trust for a short-term effect.

• Progress bars that are not progress. Fake loading, or a bar that jumps to 90 and waits. Players learn quickly and stop believing any of your indicators.
• Celebration for nothing. Confetti for a routine action devalues the confetti you needed later.
• Numbers that do not add up. If the damage number and the health bar disagree, players notice and post about it.
• Near-miss theatre, where the game pretends the player almost won something they could not have won. This is the one that gets studios written about.
• Delayed bad news. Hiding a failed transaction or a lost item until later does not soften it, it turns a problem into a trust incident.

Feedback is the only conversation your game has with the player. Every unanswered press is a sentence they said and you ignored.

A feedback audit

1. Record sixty seconds of play, then step through it frame by frame at the moment of a press.
2. Count the frames until anything on screen changes. More than about six at sixty frames per second is a gap.
3. Do the same for your slowest action: the shop purchase, the save, the network call.
4. Play muted for five minutes and list everything that became unclear.
5. Play with the HUD hidden, if your game allows it, and list what became unknowable.
6. Die deliberately five times. Could you name the cause every time?
7. Count your modals. Which of them would the player always answer the same way?
8. Pick up a common item and a rare item. Is the difference in celebration proportionate?
9. Trigger a failure state in a menu: a failed purchase, a full inventory. Is there any feedback at all?
10. Watch someone else play and count the times they press twice.