Other factors can contribute to lag, further compounding the consequences. Movement can be driven by animations, with velocity changes built into specific time points in an animation. For example, if the animator places the jump velocity impulse a fraction of a second into the animation to better match the visuals, it might look better, but it feels bad.

The animator can correct it by making sure the velocity impulse is on the first frame of animation when the player needs that immediate feedback. But then the question is how does triggering an animation translate into actual movement?

It's quite likely that animation updating is handled by the Render() function. Any events triggered by the animation will not be handled until the time around the loop, which adds another frame.

In addition, triggering an animation might not make it advance a frame until the next frame, delaying the event firing for a frame. Our lag could potentially be increased from six to eight frames, which would be quite unplayable, even at 60 frames per second.

That's not the end of it either. There are many other ways in which extra frames of lag sneak their way into a game. You might be pipelining your physics on a separate thread (or a physics processing unit).

What if you're using triple buffering to smooth your frame rate? You could be using abstract events that take a couple of passes through the system to resolve into real events. You might use a scripting language that adds an additional frame in the way it waits for an event.

It's quite possible to make your game logic incredibly flexible by abstracting various concepts of time and events, and yet while doing this, programmers can lose sight of exactly what's going on under the hood, making it far easier for additional frames of delay to creep in.

Responsiveness, Not Reaction Time

One of the great misconceptions regarding responsiveness is that it's somehow connected to human reaction time. Humans cannot physically react to a visual stimulus and then move their fingers in less than one-tenth of a second.

Game players' peak reaction times vary from 0.15 seconds to 0.30 seconds, depending on how "twitchy" they are. Quantifiables such as these are often brought up when discussing game responsiveness, but the connection is specious.

It's not how fast a player reacts to the game; it's how fast the game reacts to the player. The issue is not one of reaction times, but of synchronization.

Take Guitar Hero, for example, a game in which symbols come at you, the player, and you have to hit the correct button at a very precise point in time (when the target object is within a particular region). You are anticipating the future event, and there is no reacting involved at all.

The problems of lack of responsiveness occur when the game does not react fast enough to the player and the target object has moved beyond the target region by the time the event occurs.

If you press the button at the correct time, you do not expect the object to move even a few more pixels before it explodes. But since objects generally move at least a few pixels per frame, having a few frames of lag can permit the object to drift past its target.

Many action games are based around anticipation and button pressing. In a skateboarding game, you want to jump just before you hit the end of a rail. In a first-person shooter, you fire the instant someone moves in front of your gun.

Again, this is not reaction time. You usually have seen the target at least half a second before you shoot it, probably more, and will be either moving the gun, or waiting for the target to move in front of the gun.

Because of the somewhat unintuitive nature of these problems with responsiveness, it is important for programmers to fully understand the issues. The most important thing is to be able to clearly describe the frame-by-frame path through logic and rendering that a button-triggered action takes before it creates visual feedback. Once you have this, you can optimize it as close to the optimal pathway as possible.

[EDITOR'S NOTE: This article, originally published in Game Developer magazine, was independently selected by Gamasutra's editors, since it was deemed of value to the community. Its republishing has been made possible by Intel, as a platform and vendor-agnostic part of Intel's Visual Computing microsite.]