Gamasutra: The Art & Business of Making Gamesspacer
Programming Responsiveness

Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 23, 2014
arrowPress Releases
April 23, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Programming Responsiveness

July 9, 2008 Article Start Page 1 of 3 Next
 

[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.


Article Start Page 1 of 3 Next

Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[04.23.14]

Programmers
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[04.23.14]

Production Coordinator (temporary) - Treyarch
Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States
[04.23.14]

Senior Software Engineer-Vicarious Visions
Chukong Technologies
Chukong Technologies — Menlo Park, California, United States
[04.22.14]

Developer Relations Engineer






Comments


Jeremy Alessi
profile image
Great article!

Aaron Casillas
profile image
nice work! In regards to even triggering, one of the biggest culprits that keeps coming up in the collision system which handles volume triggers.



Say you want to fire an event upon the player touching the volume of a trigger, if the updates are too slow, the player will be well within the even trigger before its fired. This could lead to level designers feeling that there is something "untimed" about their design.



Now on the flip side, if this issue is not fixed early on in the production, then it will mean that the events in the levels, especially for a highly scripted game would have most likely been tuned with this bug; SO changing it or fixing it would break the pacing of your levels...



Another time to look for this problem is when engineers are in their "optimization" phase, one of the first things that gets tweaked is the collision system....and in a cube somewhere a level designer is pulling his hair out!

Anonymous
profile image
Good work; opened my eyes to something I've been taking for granted.

Oliver Snyders
profile image
When I started reading this, I was reminded of John Carmack's Quakecon Keynote, where he declared he wanted to find out where all the lag comes from, even if it's a fraction of a second.



Articles like this (and thinking a lot about responsiveness) is, as stated, hugely important - player feedback is one of my hang-ups and can remove all feeling from a game if the delay is significant (a few fractions of a second even).



Thanks.

Tynan Sylvester
profile image
Great article. I never realized how many different ways this can get screwed up. Add in lag from wireless controllers and drivers and I can imagine it would get pretty hellish. It's amazing how much this one subtle thing can affect enjoyment of a game. And sometimes you don't even notice it.



This is one area where old systems have an advantage. I guess the days of 1-frame reaction times, like with the good old NES, are over.

Fa rbs
profile image
Great article Mick!



Another place I've found input lag is in the network layer. Where possible you want to simulate player actions on the client, so when you turn left you don't have to wait for your input to travel up to the server, be applied to the game state, travel back to the client, then wait for render. Strangely enough I even found this once in a single player game. Input events were being batched in a network queue, pumped to localhost, received, and then interpreted all on the same machine!

Maurício Gomes
profile image
This article explained to me where my lag came from :P



I done my best to squeeze the maximum performance of my mouse-reading and drawing func, and still it lagged several frames behind, when I turned on triple buffering, the lag was reduced, but if I turned on the system cursor I could still see that lag is still present...



fortunally I gave up :P since my code was already at the state of the mininum lag (ie: the optimum code that he described in the start of the article)

B N
profile image
Hi, I didn't read this yet as I'm just heading out, but it made me immediately think about those third person games where when you move the opposite direction that you're facing the guy circles around then starts heading the direction you want to go. I think GTAIV suffers from this, and it really is annoying to me to experience this unresponsive movement. I think in a third person game the character should immediately start heading the direction that you press by turning themselves 180 degrees if necessary instead of doing a semi circle to turn around.



Maybe you guys don't even know what I am talking about, but hopefully some of you do. I think this is one of the biggest causes for me of that feeling of unresponsiveness.

William Lin
profile image
This article missed an important concept - "present". It's not only how fast computer could react to user input, it's also a problem that CPU is not dealing with "present" time. Game player always thinks what he's seeing is what is happenning at present, he presses a key according to the "present" condition he has seen on the screen, but the CPU gets the input at the time is processing the "future". So CPU must think the input comes from the current frame player is seeing not the frame CPU is processing. This is more important than the CPU reaction time to user input. Use Guitar hero as an example, the problem is not how fast player could see reaction on screen, it's how CPU identifying the correct frame the player pressed the key.

Mick West
profile image
B N, I know exactly what you are talking about, and I wrote an article about it.



http://cowboyprogramming.com/2008/04/23/running-in-circles/

Mick West
profile image
William, I think it's kind of the same issue. If there were zero lag, then all the "present" moments would be at the same time. Increasing the lag increases the time between the "present" moment, and when the computer catches up, and when that moment arrives on screen.



However, having a concept of the "present" is important for handling lag that is unavoidable. In GH (and in most games), the game needs to be aware that the player is not seeing what it thinks what the current state is, but rather is seeing a few frames back. Games should allow the player a degree of slop in their synchronization to account for this. I touched on this in my "Pushing Buttons" article:



http://cowboyprogramming.com/2007/01/02/pushhing-buttons/

Ken Nakai
profile image
The funny thing is, if the lag isn't crazy (i.e. slide show) and the game is compelling enough, gamers will deal with it. I and the gamers I know who play FPSs all deal with each game's characteristics when it comes to accuracy and response time. When the game goes online, you compensate. Obviously, there's a lot of "haxor" and "wtf?" going on because you shoot a shot that looks like it hit on target but because of net and server lag, it ends up being calculated and registered an inch to the left. You could actually control some of this with perception (if someone sees that their ping is crap, they assume that's the issue)...what if ping included the processing time as well?

Gregory Massal
profile image
With so many layers (physics, ai game logic, rendering, buffering etc, each feeding into the next) it's sometimes hard to reduce the lag. But to adopt a PC centric view, usually the hardware cursor is considered to be rather responsive, yet it is usually hard to get the same kind of responsiveness through a rendered cursor.



I've discussed the issue further here :

http://www.codermind.com/answers/How-do-I-reduce-mouse-lag-in-my-
3D-application.html



The irreducible part is : the latency of the mouse driver, the refresh rate (if you had really good control about refresh rate then it's possible to do better but that's usually something from the past like Amiga programming, not PC), and the LCD latency (LCD add latency too. They could add on average a whole frame of delay compared to an equivalent CRT and I'm not talking about remanence : see http://www.behardware.com/articles/632-1/lcds-images-delayed-comp
ared-to-crts-yes.html ).

jessica winslet
profile image
“I’m assuming you are not talking about the standard key-repeat rate here…”No, I figured that much out (not on the first try, but the 2nd try.)“For example if you are moving and change direction, then you use a different acceleration than if you are stationary and start moving.”I think I did something along those lines (will have to go back and look and see what I did.)“You’ll also want some hard limits [url=http://www.newslotsgames.net]latest slot machine games[/url] on velocity in addition to friction.”Yeah, got that. Somewhat arbitrarily chosen values, hard to figure, except by trial and error, I guess.My suspicion is that that the keyboard can never be as good as the joystick, simply because it provides less information. What few testers I’ve had have told me I’ve made improvements in the keyboard, but it’s hard to know if you’ve maxed out the “goodness” of the keyboard response.

jessica winslet
profile image
“I’m assuming you are not talking about the standard key-repeat rate here…”No, I figured that much out (not on the first try, but the 2nd try.)“For example if you are moving and change direction, then you use a different acceleration than if you are stationary and start moving.”I think I did something along those lines (will have to go back and look and see what I did.)“You’ll also want some hard limits http://www.newslotsgames.net on velocity in addition to friction.”Yeah, got that. Somewhat arbitrarily chosen values, hard to figure, except by trial and error, I guess.My suspicion is that that the keyboard can never be as good as the joystick, simply because it provides less information. What few testers I’ve had have told me I’ve made improvements in the keyboard, but it’s hard to know if you’ve maxed out the “goodness” of the keyboard response.


none
 
Comment: