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?
Update Has 3 Versions
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!
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 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().
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 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 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.
Frames Per Second
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
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.