What games taught me about feedback

My first game in Alice was built around a random-number generator. You could spin it, receive a number, and follow a different path. The idea was simple, but it made one lesson obvious: an interaction needs an answer. If the player acts and the world does not respond clearly, the choice feels disconnected even when the code technically worked.

Games teach this through layers. Movement changes position, but animation, sound, camera response, and the environment tell the player how that movement felt. A hit can update a number, yet the timing around it decides whether it feels immediate or vague. The layers do not need to be loud. They need to agree. One restrained response at the correct moment is more convincing than five effects that arrive for no reason.

I carry that lesson into ordinary interfaces. Hovering a project should reveal which project is active without shifting the whole page. Copying a Discord handle should acknowledge the click and then settle back to normal. Entering a new section can have a transition, but the transition should clarify the change rather than delay it. Feedback becomes useful when it connects cause and effect.

Games also make bad feedback easy to feel. A control that fires twice, a prompt that keeps reopening, or an outline that appears without meaning can break trust quickly. The player may not know the implementation bug, but they know the world stopped listening correctly. That sensitivity is useful. It reminds me to test an interface through repeated use, not just one successful click. A responsive system is not one that moves constantly. It is one that answers precisely when a person asks it to.