# Game programming: an explanation of delta time

Game programmers conventionally maintain a “delta” variable that simply stores the time interval between frames (which is determined, most broadly, by the computational firepower of the underlying system, and by the efficiency of the programming language’s implementation). And as it turns out, this simple variable is absolutely essential, especially to games where a slight difference in animation speed can determine whether or not the game is even playable. Let’s find out why.

Say we’re making a simple top-down shooter game, and we want to animate the bullets. We make a nice infinite array to store coordinate-containing Bullet objects, and we append such objects to the array whenever the player presses the spacebar. In our game loop, we increment the bullets’ coordinates by a “speed” constant. But we were too lazy to really think about the situation, so we arrived at this value through trial and error, picking the most suitable distance to offset bullets each frame to make the animation smooth. Because of this, “speed” is not an accurate label for the constant: It’s like saying that an airplane’s top speed is 600 miles. Instead of representing a change in distance over a change in time (delta time, in other words), it represents the change in distance per frame. Can you see why using the latter could be problematic? While the constant we picked may work nicely on our computer, not all hardware is created equal. Animation speed, in this case, is entirely dependent on framerate, which is itself dependent on the specific system.

If we take a more scientific approach to animation, we can ensure that animation speeds are consistent and totally decoupled from the platform’s performance. Speed, as you know, is a change in distance over a change in time. Luckily, time is consistent across platforms, so we can multiply the time it takes between frames, delta, by the desired speed: 100 pixels per second, for example. By doing this, we find the framerate-dependent offset distance per frame, which is what we’re looking for. Let’s say the framerate is 50 frames per second, which is a delta value of 1/50 or 0.02 (seconds per frame). If we multiply 0.02 by 100 pixels, we get an offset distance of 2 pixels, because 2 pixels times the number of frames per second, 50, givesus the pixels per second, which is 100. Here’s what it might look like in code:

Since it generally takes a slightly greater amount of processing power to calculate framerate than delta time, this method—multiplying speed values by delta—makes most sense in practice. But it may make more sense, conceptually, to think about finding offset distance per frame in terms of framerate. Instead of multiplying 100 by our delta value, we can divide 100 by our frames per second, 50, to arrive at the same offset per frame of 2 pixels. You’re simply dividing the distance you want to cover in one second by the number of frames in each second to find the number of pixels you should offset by each frame. If we try this on a slower computer, the offset distance per frame will increase since fewer frames are rendered each second. (A game running at a meager 5 FPS will offset the same object by 20 pixels every frame to keep up.)