Rhapsody 🏳️‍⚧️ Θ∆

One of my gamedev students asked me this question recently and it got me thinking about how to explain it without just saying "Just do it so your motion is consistent." And the best explanation I could come up with was doing some algebra. So I figured I'd write down the explanation here.

DISCLAIMER: I am not a mathematician. I haven't been in a mathematics class in over 4 years. I'm fairly sure this is right and it produces a satisfactory outcome, but I am not a qualified math teacher. Approach with caution.

Let's say you want to move a character left in a 2D world measured in pixels. The most intuitive solution might be to code that every frame:

Let's say this does what you want, so you send it to playtesters. They come back complaining, some that it moves too slowly and others that it moves too quickly. Well that's a problem! And the difference you'll find is in framerates.

See, you developed your game at 60 frames per second, and it ran just fine. The ones who found it too slow were running at lower FPS values, let's say 30. And the ones who found it too fast were running at higher FPS values, like 120. And the simplified explanation for this is:
Your program is experiencing itself in frames, but your players experience it in seconds.

The program is, for all intents and purposes, running just fine and smoothly. Every frame, the character moves the same amount. But in our fleshy human forms, we experience time in a different sense, and can calculate that in seconds. Or minutes, or hours. This is why a car is measured by how many kilometers or miles it's moving per hour. Or why the speed of light is often explained in meters per second. Linear time is a consistent, measurable standard to measure rates in.

So to understand how fast we'll see the character moving, we'll need to convert the pixels per frame to pixels per second. Keep in mind that a rate can be defined as a fraction, so kilometers per hour can be abbreviated as km/h. I'm abbreviating pixels as "p," frames as "f", and seconds as "s". Considering that we have frames per second, we can solve using the following:
$\frac{\mathrm{p<!--\; -->}}{\mathrm{f<!--\; -->}}\times <!--\; -->\frac{\mathrm{f<!--\; -->}}{\mathrm{s<!--\; -->}}=<!--\; -->\frac{\mathrm{p<!--\; -->}\mathrm{f<!--\; -->}}{\mathrm{f<!--\; -->}\mathrm{s<!--\; -->}}$

f exists in both the top and bottom, so it can be canceled out. This leaves us with the result:
$\frac{\mathrm{p<!--\; -->}}{\mathrm{f<!--\; -->}}\times <!--\; -->\frac{\mathrm{f<!--\; -->}}{\mathrm{s<!--\; -->}}=<!--\; -->\frac{\mathrm{p<!--\; -->}}{\mathrm{s<!--\; -->}}$

Now, we can plug in our measurements from earlier. There is one pixel per frame and 60 frames per second on the development machine. So:
$\frac{\mathrm{1<!--\; -->}\mathrm{p<!--\; -->}}{\mathrm{f<!--\; -->}}\times <!--\; -->\frac{\mathrm{60<!--\; -->}\mathrm{f<!--\; -->}}{\mathrm{s<!--\; -->}}=<!--\; -->\frac{\mathrm{60<!--\; -->}\mathrm{p<!--\; -->}}{\mathrm{s<!--\; -->}}$

In plain speak, this means the player will see the character moving at 60 pixels per second. Similarly, calculating for the other machines will produce 30 pixels per second and 120 pixels per second, respectively. So while they experience the same pixels per frame, we experience different pixels per second.

To fix this, we need a consistent number of pixels per second, rather than per frame. But we can only control pixels per frame. So we need to find an equation that takes a number of pixels per second and calculates the number of pixels we need in that frame. Fortunately, we have an equation with pixels per second and pixels per frame already in it, so we just need to solve by isolating pixels per frame on one side of the equation. To do so, we just divide both sides by frames per second.
(Keep in mind that dividing by a fraction is the same as multiplying by the flipped-over fraction.)
$\frac{\mathrm{p<!--\; -->}}{\mathrm{f<!--\; -->}}\times <!--\; -->\frac{\mathrm{f<!--\; -->}}{\mathrm{s<!--\; -->}}\times <!--\; -->\frac{\mathrm{s<!--\; -->}}{\mathrm{f<!--\; -->}}=<!--\; -->\frac{\mathrm{p<!--\; -->}}{\mathrm{s<!--\; -->}}\times <!--\; -->\frac{\mathrm{s<!--\; -->}}{\mathrm{f<!--\; -->}}$

f/s and s/f cancel each other out, so we're met with:
$\frac{\mathrm{p<!--\; -->}}{\mathrm{f<!--\; -->}}=<!--\; -->\frac{\mathrm{p<!--\; -->}}{\mathrm{s<!--\; -->}}\times <!--\; -->\frac{\mathrm{s<!--\; -->}}{\mathrm{f<!--\; -->}}$

Perfect! So we've isolated the amount of pixels per frame, which tells us our correct course of action:
We simply need to multiply our consistent rate (pixels per second) by the amount of seconds per frame.
And that is exactly what deltaTime represents! It's the number of seconds since the last frame, and by incorporating it into our movement per frame, we're able to ensure that regardless of framerate, we get a static number of pixels per second!

And if you're unsure what rate to use, you can just use the number of pixels per second we calculated using your framerate. In the example, it'd be 60 pixels per second. Thus, each frame, we would do:

I hope this is a sufficient and understandable definition. Let me know if anything was confusing or could be worded better in the comments!

Happy coding and stay hydrated <3