Game Development Reference
In-Depth Information
Capturing time
Time is important. Even in computing we have to deal with it in most applications.
However, let's say that Timmy (a friend of ours) does not believe that time is of any import-
ance and, one day, he sits down and builds a multiplayer racing game where cars move by
exactly one pixel in every frame. Happy with the result on his machine, Timmy sends the
program to his friend Jimmy, who has just bought the latest Super Ultra X CPU for his ma-
chine. They get into the race without any problems but, as soon as the green light hits,
Jimmy rushes ahead of Timmy, leaving him behind, all dusted and confused. Later on,
Timmy realizes that Jimmy's machine executes the code a lot faster than his own machine
and therefore, his car was slower. Timmy never overlooked the frame time ever again
Even though the preceding story demonstrates an oversimplified example, it reveals the
greatest flaw in ignoring time in any simulation—frames are executed at different speeds
on different machines and thus the simulation appears differently. Here is how Jimmy's
code looked like before he fixed it:
The preceding code executes each frame, and thus it is very much dependent on the CPU
and GPU speed. If on one machine this code runs at the speed of 30 frames per second, res-
ulting in 30 pixels travelled for one second, then on another machine, that code can run at
the speed of 60 frames per second, doubling the distance travelled for the same amount of
time. Not to mention that, almost always, frames take a different amount of time to run on
the same machine.
Clearly, we have a problem—game logic runs at different speeds on different systems. For-
tunately, the solution is quite simple—use elapsed time between frames to update the game
logic. Here is the same preceding example using movement, which depends on time:
