I understand that there are two approaches to implementing game loops:

Variable time step

Fixed time step

While I understand the implementation details, I'm not sure I understand what the pros and cons for each approach. When should I use one over the other? Are there certain types of games more suitable with one approach over the other? From what I can tell, the fixed time step approach is becoming more popular in most games. Any reason for that?

zet23t
—
2014-06-30T08:35:30Z —
#2

Variable time steps are useful if you have simulations that aren't interdependent such as particle systems. If the simulated parts don't take influence on other parts of the simulation, you can be relatively sure that the simulation can be done with variable time steps. Which is useful because variable time step simulation may consume less processing cycles (unless complex calculations are required where simple calculations in succession could be way cheaper).

Fixed time steps are a requirement for deterministic simulations and stable physics simulations. Physic simulations use parameters that are optimized for certain number ranges (e.g. working with certain masses / volumes / forces). Variable time steps can cause these simulations to become numeric unstable. A common observation is that the simulation oscillates and eventually "explodes" when variable time steps are used.

I would always use fixed time steps when the simulated logic is player interdependent or when determinism is required.

Sol_HSA
—
2014-06-30T11:09:56Z —
#3

Physics simulations are generally integration problems. Using fixed timestep changes one variable to "1", simplifying math a lot. That's the biggest difference, really. And quite often, I wouldn't even want to investigate how to make the integration work right with variable timestep. =)

trigger210
—
2014-07-03T08:05:03Z —
#4

Thanks for the answers!

zet23t said:

Variable time steps are useful if you have simulations that aren't interdependent such as particle systems.

Interesting point, but I'm not sure I understand why variable time are needed for this case. What happens if a fixed time step is used for dependent components? There's probably a mathematical explanation to this, but it would be nice to understand the intuition. Thanks!

vrnunes
—
2014-07-04T21:01:06Z —
#5

Unless you have a very fast machine that can keep steady 60fps for everything, you should not put all simulations on fixed timesteps. For performance reasons, physics simulation in general runs at a lower framerate and is less smooth than the other simulations running on variable timesteps.

modular
—
2014-07-07T02:48:48Z —
#6

You can have your whole game in a fixed 60fps (as @vrnunes sais) loop and be OK. It's very easy approach, only one downside to this is that you might loose flexibility.

By meaning "flexibility" I say for example that either you can do lot's of complex and clever stuff with updating the subsystems. It's a matter of code design mostly that finally is reflected in technical implementation, also it's about practical experience to customize your system according to your preferences.

I remember I read an article on gamasutra once, and there was a guy saying about he was running his artificial intelligence in two different update loops. One in 60 and one in 30 fps, that way he could organize the updating importance much more dynamically and gain many benefits as well from the technical side.

mfdesigner
—
2014-07-09T13:02:14Z —
#7

I would suggest fixed time loop exclusively. Fixed time loop allows you to model variable time loop's behavior but not the other way around (simply do things at time epochs of interest and do nothing otherwise.)

If your game allow third party plugin to extend the platform in someway, they may need to add code at fixed time interval. If you start out as variable time loop, you are limited to one scenario only.

just my opinion

vrnunes
—
2014-07-09T18:06:29Z —
#8

Variable timesteps exist to compensate for the finite and variable execution speed that (current) computers have. If you put everything into fixed timesteps, in most computers you will either have everything running slower than expected, and/or you will see jerky animations.

Variable timesteps compensate for timing differences, and prevents that. If the game loop is running too slow, it compensates moving more. If the loop is too fast, it moves less. When framerate variates, it does a good job keeping everything as smooth as possible.

Fixed timesteps are generally used for physics, but most of the time people will run physics in much lower framerates, because if we try to run lets say, physics + everything else @ 60fps, most computers won't be able to keep the pace, so it's common to separate both: physics running at low fixed framerate, everything else at variable maximum framerate.

And even the fixed timesteps will probably be adjusted down when the hardware cannot keep the pace. How else could we (today) be sure that the user's computer will have enough CPU to keep the pace? We cannot simply tell "run this in fullhd at 60fps" and it magically obeys, it needs enough processing power to do that, and for most games it won't.

Ok, so there is also the option of calling the update more than one time to try to keep the pace, but then I would call this "variable" as well, not "fixed", as it variates update rate by the elapsed time. That is, when physics is becoming behind, we call it more than one time to keep pace. I did use this solution one time, and it worked well. But I called that variable then, not fixed.

mfdesigner
—
2014-07-14T17:11:05Z —
#9

By fixed time step, I mean the system states are updated at fixed time interval. A queue-like mechanism will manage all real time events that are accumulated between time epochs. For slow computers, at each time epoch you will have a lot of accumulated events that need update (such as animations). And in those cases, you can choose to drop events, which result in dropped frames, to catch up to real-time.