Because our FixedUpdate is so fast, after every 100ms frame, the next 5 FixedUpdates execute immediately, before starting on another heavy Update pass. In this situation, the game-time doesn’t slow down, relative to wall-clock time. Instead, game time is shrunken and expanded!

Imagine if you read the wall-time value of Time.realtimeSinceStartup in the FixedUpdate — it would be extremely incorrect. This is a strong reason to keep wall-clock time out of your game calculations. Unity plays around with the way game-time flows depending on the load. You want your game to simulate nicely even when game-time is being stretched.

Conclusion

Let’s take stock:

Game-time can drastically differ from wall-clock time, so avoid using the latter.

Make use of Time.fixedDeltaTime and Time.maximumDeltaTime to tune the specific performance characteristics of your game. These can all be changed at runtime, too!

Stuttering can occur even with an empty load on the engine.

Be careful of sampling issues. Debug your frame timesteps to see what is actually happening.

Further, I showed the behavior of the timestep in isolated cases, but in reality all of these situations overlap. A single long Update could trigger a series of longer FixedUpdate steps, causing the Update to slow down, etc. It’s one big feedback loop. Hopefully, though, this gives you some intuition behind it.

Thanks for reading! Drop me a line on Twitter if you have questions or if you have information to add. I’d love to make this article a one-stop-shop for timestep information. Additionally, if you think I’ve gotten something wrong, please let me know!

FAQ

Finally, let’s answer a few frequent questions. Perhaps you’ve come here from Google just for these (I suggest reading the above article for context).

# Help! My game is stuttering!

The first thing to do is figure out why your game is stuttering. Stutter can be a result of mismatched timesteps (see first section) or could be from a variety of different performance issues (your update or fixed update are too long and Unity stutters to compensate in other ways). Drop a few console lines, or graph out the data on when your frames are rendered, and then see what looks wrong compared to the graphs above.

# Is FixedUpdate always called every 0.02 seconds?

No, FixedUpdate will run once for every 0.02 game-time seconds, but precisely when in real time this happens is unspecified and can vary drastically. See above: “A Heavy Load in FixedUpdate”.

# How does the Unity timestep respond to low framerates?

Depending on the source of the slowness, it will do different things. For slow FixedUpdates, it slows down the overall game-time (the game will run for 0.5 seconds in the span of one real time second). In some cases, the rendering rate can be drastically cut, even if the problem is your FixedUpdate speed.

For slow Updates, FixedUpdates get crunched together during the “catch up” phase between the longer Updates. Otherwise, generally the the Update dynamic timestep just gets longer.

# What is the value of Time.deltaTime in the Update function?

You can generally think of it as the difference in game-time between frames being rendered to the screen. When at performance, this is the same as the wall time between frames. However, if the game slows down because of FixedUpdate lag, Time.deltaTime will shrink, even if the render frame rate remains the same! Weird!

# Should I put my code in FixedUpdate or Update?

This is a subtle question, with no correct answer, unfortunately. Code in FixedUpdate means your game is deterministic, but FixedUpdate can’t adapt to varying framerates. Under load, your game will slow down. You must be much more careful that FixedUpdate can run at display frame rate.

If you favor determinism and systematic stability, go for FixedUpdate. If you don’t want to worry about it too terribly much, go with the default Unity approach of putting physics-related code in FixedUpdate and the rest in Update.

I wrote up my opinions in detail in a Reddit comment with two different takes on the matter.

# Does physics have to run in FixedUpdate?

Unity provides the ability to remove the physics update from FixedUpdate, letting you manually step the physics engine on your own time. This is great, but probably should be used with caution. It is a non-standard approach, and may play oddly with plugins and other engine features.

On top of this, Unity now supports the ability to have separate physics worlds. This lets you simulate an entirely separate physics system outside of the game loop.

If you’re reading this from the future, you may also be interested in Unity’s new Havok and DOTS Physics systems.

# Where can I learn more about time steps?

This article is built upon the shoulders of others. Chief among them is the Gaffer on Games: Fix Your Timestep article. See Google for a cached link if it goes down. Additional sources, in no particular order:

Finally, you can reach out to me on Twitter if you have any questions.