{"id":439,"date":"2021-11-05T03:25:56","date_gmt":"2021-11-05T03:25:56","guid":{"rendered":"https:\/\/globalgoodplay.com\/?p=439"},"modified":"2022-11-07T09:58:05","modified_gmt":"2022-11-07T09:58:05","slug":"optimize-your-games-in-unity-the-ultimate-guide","status":"publish","type":"post","link":"https:\/\/globalgoodplay.com\/?p=439","title":{"rendered":"Optimize Your Games In Unity \u2013 The Ultimate Guide"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n
\n
When developing your game, one of the hardest things to do is optimization, no matter if you are creating a mobile, desktop or a console game.<\/div>\n
<\/div>\n
And we all know that if your game is not well optimized, it will result in downloads lost, refunds requested, and ultimately labeling your game and your game development company as the ones who create poor games.<\/div>\n
<\/div>\n
In this post, I will go over everything I learned over the course of 8 years developing games in Unity. I will share with you the wrong way and the right way to do things and I will explain everything I am using in the examples.<\/div>\n
<\/div>\n<\/div>\n<\/div>\n
\n
\n

Important Information Before We Start<\/h3>\n<\/div>\n<\/div>\n
\n
\n
When it comes to optimization the Profiler is your best friend. Always profile your games on the platform you are creating them, especially mobile games.<\/div>\n
<\/div>\n
The Profiler will give you information about the performance of your game and any spikes that are causing low performance.<\/div>\n
<\/div>\n
That being said, everything that I am going to talk about in this post are things that will help you write better and more optimized code and use optimized options for your game which will help you boost your game to > 60 FPS.<\/div>\n
<\/div>\n
The order by which I will write every tip doesn\u2019t matter, I will write everything I know how I remember it and I will add new things as I learn them. You can use the menu navigation on the left side to directly navigate to the part you want to learn.<\/div>\n
<\/div>\n
Now let\u2019s get started.<\/div>\n
<\/div>\n<\/div>\n<\/div>\n
\n
\n

Always Cache Your Components<\/h3>\n<\/div>\n<\/div>\n
\n
\n
A good practice that you need to get used to is to always cache your variables. Code like<\/div>\n<\/div>\n<\/div>\n
\n
\n
is very costly for your game performance, especially on mobile devices. If you need to access any component of any game object, always declare the type of the component you need<\/div>\n<\/div>\n<\/div>\n
\n
\n

and then in Awake get a reference to that variable<\/p>\n<\/div>\n<\/div>\n

\n
\n

I know that we can also use the Start function for this purpose, even the OnEnable function, but I used the Awake function for this example because the Awake function is the first initialization function that is called when the game starts, and if I want to get a reference to variables or initialize variables I always do it in the Awake function as that will be the first thing that will be executed and then the game can start normally.<\/p>\n

After that you can safely apply force to your Rigidbody variable:<\/p>\n<\/div>\n<\/div>\n

\n
\n

Caching Components VS SerializeField<\/h3>\n<\/div>\n<\/div>\n
\n
\n

There is another way how we can get a reference to cached variables and that is by adding the SerializeField keyword above the variable declaration:<\/p>\n<\/div>\n<\/div>\n

\n
\n

This will expose the variable in the Inspector tab and we can now drag the game object itself providing that it has the desired component attached on it, in the exposed variable field to get a reference to it:<\/p>\n<\/div>\n<\/div>\n

\n
\"Img-1-2.jpg\"<\/div>\n<\/div>\n
\n
\n

Now which of the two methods is more optimized, the answer is SerializeField. Because you don\u2019t need to use code to get a reference to the desired component, and this is very effective especially if you have a lot of game objects such as enemies or collectable items that need to get a certain component when they are spawned.<\/p>\n

Now there will be times where you need to get a reference to a component via code, but whenever you can, try to get a reference to the component of a game object by using SerializeField and attaching the desired component in the appropriate slot in the Inspector tab.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Cache Your Non-Component Variables As Well<\/h3>\n<\/div>\n<\/div>\n
\n
\n
One of the things that I see A LOT in tutorials and courses online are the following:<\/div>\n<\/div>\n<\/div>\n
\n
\n
Once I profiled a mobile game that I was currently working on, and I found out that by creating a new Vector3 variable in the Update function like you see in the example above, it was taking my code 0.02 ms more to execute the code.<\/div>\n
<\/div>\n
Given the fact that to get to 60 FPS and above, all of your code needs to execute at 16 ms tops, you can imagine how unoptimized this one simple line of code is.<\/div>\n
<\/div>\n
The solution is to cache the variable before you use it:<\/div>\n<\/div>\n<\/div>\n
\n
\n

This is also a rule for any other variable types. It is always better to do<\/p>\n<\/div>\n<\/div>\n

\n
\n

than<\/p>\n<\/div>\n<\/div>\n

\n
\n
So get in a habit to do this with all of your variables especially object type variables like vectors, components and custom classes you create, but also do this with floats, ints, booleans, and strings.<\/div>\n
<\/div>\n<\/div>\n<\/div>\n
\n
\n

Don\u2019t Use Camera.main<\/h3>\n<\/div>\n<\/div>\n
\n
\n
This is also something that I see a lot in online tutorials and course which is killing your performance. Accessing the camera by using<\/div>\n<\/div>\n<\/div>\n
\n
\n
especially if you use this a lot will slow down your game. This is in a way connected to caching that we talked about above, but the solution for this, again, is to cache the camera variable before using i<\/div>\n<\/div>\n<\/div>\n
\n
\n

Avoid Repeated Access to MonoBehaviour Transform<\/h3>\n<\/div>\n<\/div>\n
\n
\n

Another thing that you need to be careful of is reusing the transform property of MonoBehaviour. This internally calls GetComponent to get the Transform component attached on the game object.<\/p>\n

Again, the solution for this is to cache the transform variable:<\/p>\n<\/div>\n<\/div>\n

\n
\n

Optimizing Strings<\/h3>\n<\/div>\n<\/div>\n
\n
\n
One of the heaviest performances in your Unity game are the strings that you are using. Yeah, you read it right, STRINGS.<\/div>\n
<\/div>\n
The first mistake you will see everything online is when collision check is performed:<\/div>\n<\/div>\n<\/div>\n
\n
\n

This is not the way to go. When you are checking the tag of the collided game object it is better to use CompareTag function<\/p>\n<\/div>\n<\/div>\n

\n
\n

Another common mistake is when declaring an empty string people usually write:<\/p>\n<\/div>\n<\/div>\n

\n
\n

A better way is to use string.Empty:<\/p>\n<\/div>\n<\/div>\n

\n
\n

Strings And Text UI<\/h3>\n<\/div>\n<\/div>\n
\n
\n

When using strings and text UI you need to be careful when you are updating the text often, especially if that happens in the Update function.<\/p>\n

This is something a lot of people do with timers, the usually write code that looks like this:<\/p>\n<\/div>\n<\/div>\n

\n
\n

While this looks like a very simple operation, it is going to slow down your game significantly, especially a mobile.<\/p>\n

The reason for that is because a string is an object type variable. Every time you concatenate a string like you see in the line 9 in the code above, you create a new object.<\/p>\n

Now imagine doing this in the Update function which is called every frame. You are creating a new object that is stacked up memory every single frame and this is something mobile devices can\u2019t handle.<\/p>\n

The solution is to use StringBuilders.<\/p>\n<\/div>\n<\/div>\n

\n
\n
Use string builders wherever you need to use strings often especially when it comes to timers and countdowns.<\/div>\n
<\/div>\n<\/div>\n<\/div>\n
\n
\n

Avoid Using Instantiate Function During Gameplay<\/h3>\n<\/div>\n<\/div>\n
\n
\n

When it comes to Instantiate function, which creates a copy of the provided prefab, you will find different opinions online. The majority say don\u2019t use Instantiate during gameplay.<\/p>\n

This is somewhat true. I say somewhat because I\u2019ve used Instantiate during gameplay in one of my mobile games and when I profiled the game it was running smoothly never going below 60 FPS.<\/p>\n

This goes to show that you should always revert back to the Profiler and the stats you see there.<\/p>\n

That being said, it is always a better idea to use the pooling technique instead of relying on Instantiate, especially if you are spawning bullets, collectable items or any other game element that is often spawned in the game.<\/p>\n

If you don\u2019t know what is pooling, I am going to leave a basic generic pooling class below for you to inspect the code and learn:<\/div>\n<\/div>\n<\/div>\n
\n
\n

But sometimes there will be situations where you simply need to use Instantiate as that is the shortest solution, and there is no harm in using it if you see that the Profiler is not showing any issues, so keep that in mind.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Remove Empty Callback Functions<\/h3>\n<\/div>\n<\/div>\n
\n
\n

As you already know, Awake, Start, and OnEnable initialization functions are called when the game object is spawned.<\/p>\n

Update and LateUpdate are called every frame and LateUpdate is called every fixed frame rate.<\/p>\n

The issue with these functions is that they will be called even if they are empty because Unity doesn\u2019t know that these functions are empty e.g. they don\u2019t have any code inside.<\/p>\n<\/div>\n<\/div>\n

\n
\n
even if they are empty like in the example above, Unity is going to call them.<\/div>\n
<\/div>\n
Now you might say, okay but they don\u2019t have any code inside so what is the harm when nothing is going to be executed.<\/div>\n
<\/div>\n
The harm is the fact that whenever a game object is instantiated in the game, Unity will add any defined callbacks, such as Awake or Update, to a list of functions that will be called at specific moments(Awake will be called when the object is spawned, Update will be called every frame and so on).<\/div>\n
<\/div>\n
This will waste CPU power due to the cost of the engine invoking these functions. And this can be a problem especially if you leave empty callback functions in let\u2019s say a bullet prefab that you call every time you shoot, or a collectable item that is spawned when the player makes an achievement and so on.<\/div>\n
<\/div>\n
Not to mention if you are creating a larger game and over time you populate your scenes with thousands of game objects with empty Awake, Start, Update, and so on, which can cause slow scene load time.<\/div>\n
<\/div>\n<\/div>\n<\/div>\n
\n
\n
I am going to attach the two functions on two prefabs and I am going to spawn 1000 copies of each prefab using the following code:<\/div>\n<\/div>\n<\/div>\n
\n
\n
Let\u2019s take a look at the Profiler and see what happens when we instantiate the object that has empty callback functions and what happens when we instantiate the object that doesn\u2019t have empty call back functions:<\/div>\n<\/div>\n<\/div>\n
\n
\n

As you saw from the example, just by having empty Start and Update functions in the class the spike on the Profiler skyrocketed when we created objects which had that class attached to them.<\/p>\n<\/div>\n<\/div>\n

\n
\n

When Raycasting Use Zero Allocation Code<\/h3>\n<\/div>\n<\/div>\n
\n
\n

Avoid using raycast code that allocates memory. All raycast functions have their non memory allocation version:<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/section>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

When developing your game, one of the hardest things to do is optimization, no matter if you are creating a mobile, desktop or a console game. And we all know that if your game is not well optimized, it will result in downloads lost, refunds requested, and ultimately labeling your game and your game development<\/p>\n","protected":false},"author":1,"featured_media":597,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-439","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=\/wp\/v2\/posts\/439"}],"collection":[{"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=439"}],"version-history":[{"count":2,"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=\/wp\/v2\/posts\/439\/revisions"}],"predecessor-version":[{"id":598,"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=\/wp\/v2\/posts\/439\/revisions\/598"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=\/wp\/v2\/media\/597"}],"wp:attachment":[{"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=439"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=439"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/globalgoodplay.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=439"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}