Sonic Dream Team - Sega
Why are you writing this?
I have been making games as a hobby on and off since 2008, when recently I got the opportunity to make Sonic Dream Team with the team at HARDlight. As I look back on my development experience I found that a lot of the difficulties I faced were either not documented at all, or had very little information online, so with the effort of making as much information public to everyone, I thought I could write up a series of articles on various topics exploring the more useful tips, tricks and lessons I learned over the years.
I’d like to point out, most of the information here is very Unity-heavy, although a lot of it is applicable to any game engine. So without further ado, let’s get started!
What are target frame rates?
For those new to game development, frame rates are effectively how many frames are going to be computed and rendered per second by your game. So 60fps (fps stands for frames per second) would mean your code is being executed and your graphics are rendering 60 times every second.
- For 60fps, you want your frame times to be under 16.6ms
- For 30fps, you want your frame times to be under 32ms
- Profilers typically display frame times to help indicate how much time that frame took to compute and render in real time. So if you think about it, for your game to run 60 frames in one second, you need each frame to take 0.0166 seconds, if you multiply that by 1000 to convert it into milliseconds, this is how we get to the 16.6 milliseconds above
- Whenever you are profiling frames in your game, try to keep your total frame time under those values for a smoother gameplay experience. Opt for heavy processing to be done under loading times where the player won’t see or care about the game lagging or heavily dropping frames
For mobile developers
When targetting mobile devices, it’s essential to leave at least 35% extra of the target frame time free on top of those values above, as recommended by Unity. This 35% will act as a buffer to allow the devices to cool down and not overheat over time. For example, if you are targetting 60fps, you will want your frame times to be under 11ms, to leave 5ms (35% of 16.6) or so for the CPU to cool down.
Note: this is one of those tips that applies to any game in any game engine, as it’s really more about leaving space for mobile devices to cool down and not overheat.
A word of caution on FixedUpdate
Be very careful when using the FixedUpdate event, you should really really really only use it for physics calculations in your game, everything else you will want to do on Update or in async methods or coroutines.
This is because FixedUpdate is called every physics simulation, which can and often happens multiple times in the same frame, more so if you increase the refresh rate on your project settings, which also increases physics update frequency. This is unlike Update that is called every update loop guaranteed to be once per frame.
To illustrate this with some maths, let’s imagine we are erroneously doing 3 calculations in Fixed Update, if these are called 3 times per frame, you would end up with the following:
calculations x update calls x fps
3 x 3 x 60 = 540
You would be doing 540 calculations every second, instead of 180!
Unity lifecycle events always have a cost
Note: To be clear, I’m referring here to Unity’s lifecycle events such as Start, Update, FixedUpdate, etc… and not the UnityEvent class that allows listening to and invoking events.
Unity uses a magic method system where upon accessing a MonoBehaviour script for the first time, the underlying scripting system will inspect it for any magic methods and cache this information in various different lists, so it can call them at the appropriate times, can you see the problem with this?
If you extend from MonoBehaviour, even if you’re extended method is doing nothing, it will force the engine to take time to perform checks to see if the game object is valid and alive, the script is enabled and valid, if the magic method is valid, then marshalling code calls from C++ to C# just to… do nothing! If you consider that these events are available on every component, as well as the fact this happens every time the methods are called, the amount of calls will exponentially grow very rapidly over time, especially for Update and FixedUpdate calls.
You would think this would be as simple as removing the method if you don’t need it, but it’s very easy to get into the trap of making a base class that extends from MonoBehaviour and then make the lifecycle events abstract or virtual, and now you’re stuck with a bunch of derived classes that do nothing on the lifecycle events but incur the cost of being executed anyway. This is especially painful to know, if you consider that making a lifecycle event virtual even if you don’t override it, will still incur the cost, since the scripting system will detect the base class has a magic method that needs to be invoked.
If you want to read more about this, there’s a very useful Unity article (albeit very old) that dives deeper into this issue: 10000 Update() calls
For this I suggest moving any logic you can into some kind of centralised manager class, and instead make your script register against that manager on Start or Awake, then if you want something to happen on Update or FixedUpdate, make a separate method with a different name, not named after the events, and manually invoke it yourself from the manager’s Update or FixedUpdate. Because there is only one manager, you reduce the problems described above to only one script.
Alternatively, if you cannot absolutely get away with having a huge number of components/game objects, consider moving into Unity’s Job System and/or the Burst compiler.
Consider turning off one of the physics simulations
By default, Unity has both 2D and 3D physics simulations turned on, this means if your game is exclusively 2D or 3D, the engine will be doing a bunch of simulations in one of the dimensions that are never used.
Make sure to disable the simulation you don’t need in the relevant 3D/2D option.
In Unity 6 for 3D games, 2D physics simulation can be turned off by going to: Project Settings -> Physics 2D -> Find “Simulation Mode” field -> Change the value of this to “Script”
In Unity 6 for 2D games, 3D physics simulation can be turned off by going to: Project Settings -> Physics -> Settings -> Change tab to “Game Object” -> Find “Simulation Mode” field -> Change the value of this to “Script”
The default value for these is “Fixed Update”, by setting the value to “Script”, the simulation will never be executed unless you manually call Physics.Simulate() which most of the times won’t be the case.
Other optimisations
I’ve left this for some smaller optimisations that don’t need to be delved into too deeply:
- If you are in a situation where you are targetting a wide range of devices (like Genshin Impact, that does everything from PC, to consoles and mobile devices), consider implementing some kind of system that chooses different atlas variants with lower resolutions for devices with low memory limits, and higher resolutions for high memory limits
OnDisableis always called afterOnDestroy, this can be a trap if you have code running in both events, you can probably get away with usingOnDisablemost of the time. UseOnDestroyif you want to do some cleanup when the object is destroyed, useOnDisablefor everything else and be careful to not write logic that makes it so one event will depend on the other or vice-versa- Some very kind Japanese people have written a large document of performance optimisations for Unity that I often refer to, and published it freely on Github, you can find it here if you are interested in reading more
Final thoughts
And that’s it for now! In the next article, I will be going over CPU optimisations for particle systems, refresh rate considerations and optimising for garbage collection, so stay tuned for more!