In Unity, methods are named in such a way that it’s not always obvious what they do. And especially not if you’re beginner. In such situation you should look documentation. However what if documentation is empty or is written in way so nerdy that it’s beyond what we can understand?
Table Of Contents
Unity Has Three Update Functions
In Unity there are 3 versions of this method, and they all seemingly run in the same way – constantly:
However, there’s huge difference between how they work and the output we get from them – it’s just not visible with random code, so if you tried to test it on your own and failed to tell the difference, better luck next time!
Update For Common Code
So if we already messed a little bit with Unity we know that Update executes all the time and “every second”. But that’s not true.
It looks like it executes constantly and every second. And in fact it executes constantly. But it executes much faster than every second (or slower, if you have too many Chrome tabs, or computer older than you).
Method Update is called by Unity every game frame. Ever heard of term FPS – frames per second? That’s what it is about. So if you have a slow computer, or ton of heavy programs running in background, or your game is an unoptimized bigot – then you won’t have 30 – 60 FPS required for smooth gameplay.
If your game has 20 FPS, then Update method will call 20 times per second, and animation may look laggy. If 60 FPS, then it will call 60 times per second, and the animation will look very smooth.
Obviously you don’t want to limit people with good computers and HD settings to animations set in a way that targeted slow PCs. That’s why anything related to animations should be called from Update(), because then the animation will be capped at what their computer can handle.
FixedUpdate For Physics
But wait, you don’t want to let players run or attack with speed that’s based on frames. Have you ever heard of MMORPG where knights swing their swords faster and therefore do more damage if players have good high end computers? So player with 300 FPS would do much more damage than player with 30 FPS. Crazy! Thankfully I didn’t.
FixedUpdate doesn’t execute per frame, per few frames, or anything like that. It’s executing regularly per previously set number in Unity settings (default setting is fine).
That’s why if you change player position (for example during running) in Update(), then you should either multiply it by Time.deltaTime, or put it in FixedUpdate instead. One more use for FixedUpdate is calculating physics, so anything related to Rigidbody, also goes here.
LateUpdate For Final Code & Animations
LateUpdate is executed per frame, just like Update, but after all other code. Its useful when something is influencing our code placed in Update after it executes.
So if we change position in Update(), but something that we have no control over, changes our position after our code, then we can use LateUpdate. And then it our code will be executing as last, so nothing can change it.
Real life situations? Easiest to notice are always animations and position. So if the position is shaking you could put the code to LateUpdate instead and see if it works for you.
Which Update Method Is Best?
There’s no best. If you want to just use one, I guess you would go with LateUpdate (and multiply important things by deltaTime), or with FixedUpdate.
But sooner or later you would probably have to use other update method. So in the end it’s better to use all three.
Is Update Slow?
Yes, it’s called all the time, so obviously it’s slow. Of course, if you just have one object calling Update with one or few booleans as initial checks in it – it won’t negatively impact your performance.
However, if you don’t have to, then I strongly advise you to not put code in Update. And sometimes even when it seems like you have to do it, it’s still possible to avoid it and achieve exact same or similar result.
These methods are based on either fixed time or on frames. The latter is dependent on how fast computer you have, and the former is the same on every computer.
Frames Per Second (FPS)
When I play, I turn on VSync to limit my frame rate to 60 FPS. That’s because the games I play look the same on 60 FPS and 300 FPS.
Of course there’s obvious visual difference between these numbers in high end game, however some games won’t really make advantage of 300 FPS (2D games, MOBA, and so on).
So while you will see a difference between 60 and 300 FPS in GTA V, you won’t see it in League of Legends. Not only that, but by limiting your frame rate you save some computer resources and perhaps electricity depending on computer configuration.
As a game designer, you don’t want to execute important code every frame. For example regenerating health – why in the world would player heal more if he has faster PC?
Fixed Time Step (FTS)
It’s set by default. And it’s value is good fit for most. You can however change the value in Edit > Project Settings > Time.
This is great for important code, physics, and multiplayer games especially. Here you can set how fast will character heal, how fast he gets hungry, and so on.
Summarizing Unity Update Methods
In this post you learned that there are three update functions in Unity that execute the code constantly in a loop, and they are called:
There are many ways of using them however the rule of thumb is:
- For common, general, and default code use normal Update().
- For anything related to physics or numbers increasing, use FixedUpdate().
- For any code that gets overwritten by anything else, use LateUpdate().
There are many ways to avoid update, such as Coroutines, Async Await and Trigger components. Won’t work for every case but quite often it will, and I will write a post about how to avoid update for even bigger performance in the future.