This chapter is from the book
This chapter is from the book
This chapter is from the book
Time and Games
The majority of video games have some concept of time progression. For real-time games, that progression of time is typically measured in fractions of a second. As one example, a 30 FPS title has roughly 33ms elapse from frame to frame. But even turn-based titles do feature a progression of time, except this progression is measured in turns instead of in seconds. In this section, we look at how time should be taken into account when programming a game.
Real Time and Game Time
It is very important to distinguish real time, the amount of time that has elapsed in the real world, from game time, which is how much time has elapsed in the game’s world. Although there may often be a 1:1 correspondence between real time and game time, that certainly is not always the case. Take, for instance, a game in a paused state. Although a great deal of time might be elapsing in the real world, the game time is stopped entirely. It’s not until the game is unpaused that the game time starts updating again.
There are several other instances where the real time and game time might diverge. For example, to allow for more nuanced gunfights, Max Payne uses a “bullet time” gameplay mechanic that reduces the speed of the game. In this case, the game time must update at a substantially slower rate than actual time. On the opposite end of the spectrum, many sports games feature sped-up time. In a football game, rather than requiring a player to sit through 15 full minutes per quarter, the game may update the clock twice as fast, so it actually only takes half the time. And some games may even have time progress in reverse. For example, Prince of Persia: The Sands of Time featured a unique mechanic where the player could rewind the game time to a certain point.
With all these different ways real time and game time might diverge, it’s clear that our video game’s loop should take elapsed game time into account. The following section discusses how our game loop might be updated to account for this requirement.
Logic as a Function of Delta Time
Early games were often programmed with a specific processor speed in mind. A game’s code might be written explicitly for an 8 MHz processor, and as long as it worked properly it was considered acceptable. In such a setup, code that updates the position of an enemy might look something like this:
// Update x position by 5 pixels
enemy.position.x += 5If this code moves the enemy at the desired speed on an 8 MHz processor, what happens on a 16 MHz processor? Well, assuming that the game loop now runs twice as fast, that means that the enemy will also now move twice as fast. This could be the difference between a game that is challenging and one that is impossible. Now, imagine running this 8 MHz–designed game on a modern processor that is hundreds of times faster. The game would be over before you even blinked!
In other words, if the preceding enemy movement pseudocode were run 30 times per second (30 FPS), the enemy would move a total of 150 pixels in one second. However, at 60 FPS, the enemy would move a total of 300 pixels during that same period of time. To solve this issue, we need to introduce the concept of delta time: the amount of elapsed game time since the last frame.
In order to convert the preceding pseudocode to use delta time, we need to think of the movement not in terms of pixels per frame, but in terms of pixels per second. So if the ideal movement speed is 150 pixels per second, this pseudocode would be preferable:
// Update x position by 150 pixels/second
enemy.position.x += 150 * deltaTimeNow the code will work perfectly fine regardless of the frame rate. At 30 FPS, the enemy will move 5 pixels per frame, for a total of 150 pixels per second. At 60 FPS, the enemy will only move 2.5 pixels per frame, but that will still result in a total of 150 pixels per second. The movement certainly will be smoother in the 60 FPS case, but the overall per-second speed will be identical.
As a rule of thumb, whenever an object in the game world is having its properties modified in a way that should be done over the course of several frames, the modification should be written as a function of delta time. This applies to any number of scenarios, including movement, rotation, and scaling.
But how do you calculate what the delta time should be every frame? First, the amount of real time that has elapsed since the previous frame must be queried. This will depend greatly on the framework, and you can check the sample games to see how it’s done in a couple of them. Once the elapsed real time is determined, it can then be converted to game time. Depending on the state of game, this may be identical in duration or it may have some factor applied to it.
This improved game loop would look something like what’s shown in Listing 1.2.
Listing 1.2 Game Loop with Delta Time
whilegame is running realDeltaTime = time since last frame gameDeltaTime = realDeltaTime * gameTimeFactor// Process inputs... update game world with gameDeltaTime// Render outputs...loop
Although it may seem like a great idea to allow the simulation to run at whatever frame rate the system allows, in practice there can be several issues with this. Most notably, any game that has even basic physics (such as a platformer with jumping) will have wildly different behavior based on the frame rate. This is because of the way numeric integration works (which we’ll discuss further in Chapter 7, “Physics”), and can lead to oddities such as characters jumping higher at lower frame rates. Furthermore, any game that supports online multiplayer likely will also not function properly with variable simulation frame rates.
Though there are more complex solutions to this problem, the simplest solution is to implement frame limiting, which forces the game loop to wait until a target delta time has elapsed. For example, if the target frame rate is 30 FPS and only 30ms has elapsed when all the logic for a frame has completed, the loop will wait an additional ~3.3ms before starting its next iteration. This type of game loop is demonstrated in Listing 1.3. Even with a frame-limiting approach, keep in mind that it still is imperative that all game logic remains a function of delta time.
Listing 1.3 Game Loop with Frame Limiting
// 33.3ms for 30 FPStargetFrameTime = 33.3fwhilegame is running realDeltaTime = time since last frame gameDeltaTime = realDeltaTime * gameTimeFactor// Process inputs... update game world with gameDeltaTime// Render outputs...while(time spent this frame) < targetFrameTime// Do something to take up a small amount of time...looploop
There is one further case that must be considered: What if the game is sufficiently complex that occasionally a frame actually takes longer than the target frame time? There are a couple of solutions to this problem, but a common one is to skip rendering on the subsequent frame in an attempt to catch back up to the desired frame rate. This is known as dropping a frame, and will cause a perceptible visual hitch. You may have noticed this from time to time when playing a game and performing things slightly outside the parameters of the expected gameplay (or perhaps the game was just poorly optimized).