[If you can't control your actions in a game, might the game be to blame? In a technical article, Neversoft co-founder Mick West examines the problem of response lag in games, along with a number of possible solutions.]

Responsiveness is something that can make or break a game at first impression. This is especially true in reviews where a game with poor responsiveness will be described as "sluggish," "unresponsive," "floaty," or "sloppy." A better game might be called "tight" or "responsive."

Several factors contribute to perceived responsiveness, and this article looks at some of them from a programmer's perspective, offering a few routes to making your game more responsive.

Response Lag

Response lag is the delay between the player triggering an event and the player receiving feedback (usually visual) that the event has occurred. If the delay is too long, the game feels unresponsive. Several factors contribute to the length of this response lag.

If your game is unresponsive, it may well be the cumulative effects of four or five different factors. Adjusting one factor alone may not make a perceptible difference, but addressing all the factors can lead to a noticeable improvement.

Players, and sometime even designers, cannot always put into words what they feel is wrong with a particular game's controls. Often they will try to do something that requires some synchronization, but will fail, and they won't be able to tell you "the event happened 0.10 seconds after my input," but will instead say the game felt "slow" or "not tight" or "difficult."

Or they might not be able to tell you anything concrete, and simply say the game sucks, without really understanding why it sucks.

Designers and programmers need to be aware of response lag and the negative effect it has on a game, even if test players do not directly report it as a factor.

Why Lag Happens

To understand why lag occurs, you need to understand the sequence of events that occur from the time the user presses a button, to the time the results appear on screen. To understand this, we need to look at the main loop structure of the game. The main loop performs two basic tasks: logic and rendering.

The logic portion of a main loop updates the game state (the internal representation of the game objects and environment), while the rendering portion creates a frame that's displayed on the television.

At some point in the main loop, usually at the start, we also get input from the user, which is sometimes considered a third task in the main loop, but is also commonly a part of the logic task. I've kept it separate here because it's important to see in what order things happen.

There are several ways a main loop can be structured. The simplest is shown in Listing 1, where we simply alternate between calling the logic and the rendering code. We assume that some frame synchronization occurs in the call to Rendering() and that we're running at a fixed frame rate, usually 60fps or 30fps for an NTSC console game.

Listing 1: The Simplest Main Loop

while (1) {
Input();
Logic();
Rendering();
}

The main loop here also only shows half the story. The call to Rendering() is doing the CPU side of the rendering task, which is iterating over the environment and the object, culling, animating, sorting, setting up transforms, and building a display list for the GPU to execute.

The actual GPU rendering is performed after the CPU rendering and usually is asynchronous, so while the main loop is processing the next frame, the GPU is still rendering the previous one.

So when does the lag come in? To understand the factors that contribute to lag, you need to understand the sequence of events that occurs from the user pressing a button to the feedback for pressing that button.

At the highest level, the user presses a button; the game logic reads that button press and updates the game state; the CPU render function sets up a frame with this new game state, then the GPU renders it; and finally this new frame is displayed on the screen.

Figure 1: When a player presses a button, the game can take up to three frames (in the best case) to create visual feedback and programming problems can introduce additional frames of lag. The actual lag time is multiplied by the length of a single game frame.

Figure 1 shows this sequence graphically. Sometime in Frame 1, the player presses a button to fire a gun. Since the input processing has already been done for that frame, this input is read in Frame 2. Frame 2 updates the logic state based on this button press (a shot is fired).

Also in Frame 2, the CPU side of rendering is performed with this new logic state. Then in Frame 3, the GPU performs the actual rendering of this new logic state. Finally at the start of Frame 4, the newly rendered frame is presented to the user by flipping the frame buffers.