What would happen if you had important code placed in wrong Update method? Would players (and most importantly your boss) notice at all? Imagine that players had movement based on physics, and you inserted all the physics code in regular Update(). Normal Update executes more often on faster computers because it depends on FPS. People with better computers will move faster than other players. Isn’t that great feature for your game?
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?
This article is about Update methods in Unity, they are necessary to know if you want to code your game correctly, however even before you start coding your game you should think about planning it. Having a good game plan or game design document is a necessity before you start programming. That’s why consider giving a read to game design document tutorial, not only it contains sample GDD template but it also explains how to create your own indie game plan.
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, it doesn’t mean there’s none.
Update: For Common Code & Animations
So if we already messed a little bit with Unity we know that Update executes all the time or “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 the background, or your game is an unoptimized bigot – then you won’t have 30 – 60 FPS required for smooth gameplay.
If your game has 15 FPS, then Update method will call 15 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() or LateUdate(), 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 put the code in FixedUpdate instead. One more use for FixedUpdate is calculating physics, so anything related to Rigidbody, also goes here.
LateUpdate: For Overwritten Code
LateUpdate is executed per frame, just like Update, but after all other code. Its useful when something is influencing our Update() code 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 object 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 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 games, 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 faster 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. To make use of FTS, set how fast will character heal or how fast he gets hungry in FixedUpdate.
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 code and animations use normal Update().
- For anything related to the physics, increasing numbers or movement, 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.