DEV Community: The Gamedev Guru

The Ultimate Guide to Draw Call Batching in Unity 2020+

The Gamedev Guru — Mon, 13 Jan 2020 18:49:10 +0000

[Find the original post at Unity Draw Calls]

Draw calls are never a problem. That is, until you add one more element and suddenly your render thread becomes your new bottleneck. Can you guess why keeping Unity draw calls at bay is today more relevant than ever?

Warning: this is an in-depth post, make yourself comfortable and grab a tea. Use the table of contents if you're in a rush.

Quick Navigation (redirects to my blog)

My Background Story

Signs You Have Too Many Draw Calls

Soft Sign: Battery Draining Too Quickly

Soft Sign: Device Heating Up

Soft Sign: Game-Play Not Running Smoothly

Soft-Sign: VR Users Look Paler Than Ever

Hard Sign: The Profiler Reveals a Render Thread Bottleneck

Wait... What's a Draw Call?

Batches vs SetPasses

Counting Unity Draw Calls

3 Reasons to Keep Draw Calls at Bay

Fight the Battle: Batching Unity Draw Calls

Requirement: Merging Unity Materials

Technique 1: Static Batching

Technique 2: GPU Instancing

Technique 3: Dynamic Batching

Technique 4: Run-Time Batching API

See Draw Call Batching in Action

\
Taken with my Nokia 3210

My Background Story

Just a few years ago, I was an inexperienced young lad... Especially when it came to game programming.

I was working on one of my first professional assignments and my task was clear.

I just had to improve and implement several gameplay systems for an existing game.

Fair enough.

So that's what I focused on for months. Creating fun for my players it is.

The thing is, every other area in game development remained pretty much unknown to me.

And I couldn't stop asking myself...

What if I have to put off a fire in one of these areas I have no idea about?

That simple thought made me very uncomfortable. After all, I didn't want to disappoint my boss. He hired me for a reason so they he expected me to know my stuff.

Yet I knew it was only about time I had to face problems I never dealt with.

And I didn't feel prepared.

In any case, I happily kept adding content and worried no further. Everything was going smoothly and I received good feedback on my work.

Even better, performance was great all long...

Until it wasn't.

After several months, I noticed something was off.

I went to the stores and started noticing more and more negative reviews.

I was used to a certain proportion of negative reviews. That's always part of exposing your work to the world.

But the trend worried me. It was getting worse than ever.

More users started complaining about battery draining faster, the device heating more than ever and the gameplay feeling too slow.

It took me some time to connect the dots.

That must be the performance thing, I thought.

I started worrying that I messed up the user experience.

Even worse, what would my client think of me? It surely had to be the work I did on gameplay.

Worry quickly transformed into stress.

I was used to stress. After all, I often spent over 12 hours a day at the University just a few years before.

But this time it was different. It was not about me anymore. It was about real people that I was disappointing.

Armed with courage, I started digging into the unknown world of performance.

And that I did especially over my free time.

I quickly learned about the Unity Profiler. That valuable tool showed me how the render thread appeared to be taking just too long. But I didn't know why.

So I kept investigating.

However, no matter how much time I put in, problems arose faster than I could fix them.

I was about to give up.

Maybe game development wasn't for me, after all.

But then, I became one of the luckiest developer of the world.

I was lucky enough to come across a great online article about technical debt. And I realized I dug my own graveyard.

But at the same time, I became inspired.

Over time, I introduced content that exploded the amount of unity draw calls I had in the game. And draw calls were supposed to be kind of requests to draw something on the screen.

Are 130 draw calls too much? Yeah, that must be it, I thought. I added non-optimized content that is causing the battery drain and slow gameplay, so now I just need to optimize it.

So I got to work and started the long journey of optimizing my materials. After all, draw calls were highly related to the material setup in Unity. The juicy over-hours were on me. I caused that problem, so I was ready to suck it up.

I couldn't stop thinking about the long-term problems, though.

If I had this problem, chances were other people had it as well.

As I saw it, the only way to solve this problem was to create processes to continuously monitor performance metrics.

That was my second job.

In a matter of days, I implemented a prototype system to continuously monitor the number of unity draw calls in the game. I wanted to make sure people submitted only optimized content in the future, especially myself.

Still, I struggled to keep the deadlines.

I knew I had to be resilient. And that I became.

With endless effort, I unified game materials substantially and greatly reduced the number of shaders.

This long journey brought me to a draw call count well under 60.

Performance was great again, as everyone held to the performance guidelines. The processes made sure of that.

And I was proud of that.

However, I still had my inner voice reminding me about these players that I upset.

They used to have great times playing the game. They made friends through it. They went as far as to strengthen their relationships with their family members.

That's why I worked hard to alleviate the pain they showed through the reviews.

But these players never came back. I lost them forever.

And that was heart-breaking.

Losing these players taught me how important it was to monitor performance all along the project.

Loading times, frame-rate, performance spikes, battery and power efficiency... All of that way matters more than I thought.

This was one of the defining moments that made me focus so heavily on game performance optimization. I learned the lesson.

The game is still performing well today. And thanks to the optimizations, the ports to weaker platforms became much easier.

Ever since then, I monitor the performance of my games almost daily.

But I don't do this alone.

I have systems in place that report me these numbers automatically. When something is off, I go and investigate.

Monitoring unity draw calls is now more important than ever with Virtual Reality gaining so much traction. We have to render at consistent frame-rates of 72, 90 or even 144 Hz. Those timings don't give you a substantial CPU budget.

"You better spend well the little technical budget you have in VR" --Rubén Torres Bonet

Signs You Have Too Many Draw Calls

At any specific moment during gameplay, there are some important signs to watch for.

Over time, you'll develop a sixth sense that will spawn some chills running down your spine whenever you experience these situations.

However, symptoms are just symptoms. They do not always reveal a draw call problem, as bottlenecks can origin from many corners. To make the distinction more clear, I divided them in two categories.

Soft symptoms are a weak indication for high draw calls; they can perfectly come from other performance factors such as overdraw.

Lastly, hard signs are those that strongly show that your game might have too many draw calls.

Soft Sign: Battery Draining Too Quickly

Phone batteries usually last for a day or two under average use.

But games excel at stealing the energy from your users' lithium ions.

However, realize that power consumption varies across different games. Optimized games will relax your CPU and GPU so they consume fewer watts.

And optimizing your game is important because your users became pretty good at noticing how much battery your game takes for breakfast.

Even if you didn't care about your users (who doesn't?), this is still a relevant factor for you.

This is why...

Efficient games let your players play for longer sessions. And the more they play, the more money will land in your pocket (or your employer's). More In-App Purchases sold, more ads consumed, more word-of-mouth marketing, you name it.

Optimizing for battery is a good return on investment.

Soft Sign: Device Heating Up

Most of the energy you take from your users' devices is converted into heat (and light). Surprise.

This might be handy in winter to warm up your hands. But still, there are 3 seasons left where your users would prefer to go around without a portable battery pack.

I still remember my times in Berlin ordering Glühwein just to warm up my hands during winter. I didn't enjoy the wine-based drink, but I learned to appreciate the warm sensation in my hands.

So I kept buying it.

If you're targeting a VR headset, you should especially optimize for energy efficiency. That is, unless you're developing an application to replace a conventional face tanner.

Source: AlienwareArena

Soft Sign: Game-Play Not Running Smoothly

Picture this...

You're playing a slow-paced multi-player shooter.

But as you're new to it, so everybody plays it better than you.

After hours of frustration, you finally have your chance: a distracted sniper.

You're sneaking upon him from behind. They didn't notice you yet, but you know it's only about time they turn their back to you. So you get ready to aim for the perfect head-shot.

You slowly move your mouse to aim a few pixels higher.

But after a delay of half a second, your cross-hair is now suddenly pointing at the sky.

The sniper notices you and by the time you realize it you're already dead.

What the hell has just happened?

Low frame-rate.

Now, low performance could happen for multiple reasons, such as garbage collection, but a high amount of unity draw calls is surely one of them.

I remember the early days of Counter Strike where people with the beefiest GPUs threw smoke grenades to gain an unfair advantage. Players with low-end computers couldn't really handle smoke that well, so they ended up dying of low frame-rate. This was probably more due to overdraw than draw-calls, but I still find it memorable to mention.

Soft-Sign: VR Users Look Paler Than Ever

The lower your VR game performs, the worse your users will feel.

Wait, I can say this in a different way.

The more potential draw calls you have, the worse your worst case becomes.

Yeah, that's better.

"Performance spikes are the quickest way to convert VR players into patients" --Rubén Torres Bonet

Hard Sign: Unity Profiler Reveals a Render Thread Bottleneck

If your render thread is taking too long to execute, chances are you have too many draw calls. Or worse, you might have too many SetPasses (we'll see the difference in the next section).

Your main thread is probably just idling around while the render thread finishes processing all draw calls.

You can identify this situation through the Unity Profiler, as seen below.

\
Unity Draw Calls: Expensive Render Thread

The more of these signs you have, the higher the chances are that your game has way too many draw calls.

And we've been speaking about draw calls for a long time.

But what's exactly a draw call?

Wait... What's a Draw Call?

Simply put, a draw call is your CPU asking your GPU to draw something.

It's your CPU saying: hey, draw this chair in that corner over there with these textures and lighting information.

If you have many "things", then you prepare many draw calls:

I want a chair in that corner
And also another chair there in the other corner
Oh, and a bookcase as well.

The issue is, preparing unity draw calls steals a huge portion of your CPU time and energy. Unity has to convert your scene content into a format your GPU understands. And a very expensive part of this process is to set the correct render parameters, such as textures, shaders, meshes, etc...

Setting rendering parameters manually is tedious. That's why game developers introduced the concept of materials.

A material is a data structure with information about how to draw an object. It contains a shader with all its parameters, plus information about how to set the GPU render state.

And every material you add to your scene increases the complexity of your rendering pipeline. Each material adds at least one SetPass (this sets rendering parameters). And you really want to minimize those if you want your game to perform well.

Does this mean we cannot draw too many objects at once?

Not necessarily.

Game developers use batching to group the rendering of similar objects into the same draw call.That way, the CPU pays the price of a single draw call to render multiple objects.

With batching, we ask the gpu once to draw three chairs here, there and behind instead of asking three different times.

Now, the key is understanding what "similar" (objects) means.

In batching, it all comes down to using the same material across different objects. Really. If you get this done, you achieved the most complicated step.

With the help of the Unity Frame Debugger, you can see below the sequence for 4 draw calls: 3 for the furniture and 1 for the floor.

Unity Draw Calls: No Batching

That was expensive.

But batching will help us reduce these draw calls. This, in turn, will reduce the CPU load of your players. Having more resources lets you add more gameplay features or just keep it that way to reduce the energy consumption of the device.

Batches vs SetPasses

There's a little detail that few developers know of.

There's a difference between the Batches *and *SetPasses metrics you see in the profiler and stats window.

But this difference has a huge impact.

Batches are what we usually describe as draw calls. Those are plain draw commands, e.g. draw this object here and then this other one there. This is mostly about drawing an object with the current global render state. Same shader, similar parameters.

SetPasses, however, describe a more expensive operation: material changes. Changing a material is expensive because we have to set a new render state. This includes shader parameters and pipeline settings, such as alpha blending, Z testing, Z writing, etc...

Let me explain this to you with an example.

Let's consider we have 3 chairs sharing the same mesh.

We'll now explore three scenarios with different batching and material setup. Each scenario will result indifferent batches and SetPasses. Check the following table;

The first and second scenarios are similar: different materials skyrocket our SetPass count. And those have the worst performance hit in the render thread. Batching is not possible, as batching requires using identical materials.

However, we see a hint of light with the third scenario. Sharing materials makes all the difference. Having a unique material reduces the SetPass count to 1, which gives you an incredible performance boost. Sure, we still have three draw calls, but those are very cheap.

Finally, if you really want to kick ass, then the fourth scenario is for you. Here, we enable batching. And batching loves unique materials. Enabling batching reduces the Draw Call count to 1. Here we have the perfect output: 1 SetPass, 1 Batch

Counting Unity Draw Calls

Before we dig into fighting draw calls, we first need the proper tools to measure them. There are many tools available for this, such as RenderDoc, but we will stick to the simplest: the stats window and the Unity Frame Debugger.

You can access the stats window any time by clicking on the *Stats *button on the top-right corner of the game view. This panel shows you metrics for the current game view. Expect these numbers to evolve if your screen contents change (which should if you're serious about game development).

There, pay attention to Batches (draw calls) and SetPasses (material changes). As we saw, these are connected but have a different performance impact profile.

\
Unity Performance Stats Window

Lastly, you can and should use the Unity Frame Debugger. This tool will show you the specific draw calls (batches) that you're issuing for the current view. You can open it in Window → Analysis → Frame Debugger. This image shows you what to expect.

3 Reasons to Keep Draw Calls at Bay

My experience has taught me it is crucial to reduce SetPasses and draw calls even if they are not the bottleneck of your game. Here are my top reasons to reduce draw calls from the start of a project:

It makes porting to future platforms much easier.\ You surely spent thousands of hours working on your game. That's a baseline cost everyone has to pay to get their game shipped.\ Once you paid that price, why not profit from it further and port it to other platforms? It will take you a fraction of the cost to multiply your sales.\ The thing is, the more optimized your game is, the less effort you must put in the porting process.
Save time and pain by optimizing now rather than in the future.\ Just optimize them today, really. You probably know how it feels to optimize a dozen of assets a colleague of yours created a year ago. Especially when that colleague of yours left your project.\ This becomes crucial when shopping in the asset store. Most assets from the store are poorly implemented and use multi-material setups. Those will make your life impossible when targeting mobile.
It improves the efficiency of your game.\ Your game will use less CPU resources and perform better, which is critical in VR. You'll steal less energy from your players' batteries. The players and environment will reward you for that with better reviews and more in-app purchases. The longer your users play your game, the more ads they will see, the faster they'll consume and pay for your content.

You see, while working with Unity you are adding draw calls by default. Assets tend to use different materials unless you pay attention to them. And by using different materials, you're adding draw calls that you cannot batch. Over time, this will explode.

Fight the Battle: Batching Unity Draw Calls

Instead of drawing one object 10 times, we draw 10 objects once.

That's the power of batching.

The main requirement to batch draw calls is to get the objects to use the same drawing properties (material). When that happens, Unity can then merge the different meshes into a single chunk that uses the common material.

As we said, most assets will use different materials by default. But worry no further, we'll see several ways to merge materials into a single one.

Below there's a flowchart diagram that summarizes the options you have for batching in Unity.

\
Unity Draw Call Reduction: The Guru's Batching Diagram

Your entry point is to find out if the objects you want to batch share the same material.

Sharing materials is a precondition for batching to work. Different materials have different drawing settings that change the global GPU render state.

If these objects don't use the exact same material but they're similar enough, then you must merge them into a single one. This usually involves creating shared texture atlases and updating the individual objects' UV coordinates to point at the new correct locations. There are tools to help you out here.

Once your objects use the same material, you have many options to batch these draw calls.

The batching technique I suggest you to use use depends on the nature of the objects you want to batch.

But before getting into batching, let's see how to merge materials.

(Get the full-resolution diagram here)

Requirement: Merging Unity Materials

The first requirement to merge materials is this:

The materials for the objects you want to batch must use the same shader

Changing the current shader is one of the most expensive operations you can do. This slows down rendering significantly.

Almost every game must change shaders to some degree, and that's fine as you're aware of its cost. Try to reduce the shader count you have in your project (including shader variants).

If you can merge two shaders that look alike into the same one, you'll get huge wins in performance.

So the first step is to remove shaders from your project, whenever you can. Chances are, you can get many original materials to look similarly under a common shader.

Once your target objects use the same shader, the next step is to merge their materials. That is probably complicated, as they probably had different material parameters such as:

Textures: each material often has one or more textures that are not shared with other materials. One way to use the same texture across different materials is by creating bigger textures that contain all individual textures. Those textures are called atlases.
Decimal values: such as metallic, specular and other parameters. To merge those, you can either find a common average value that suits them all or create a texture atlas containing that value in a specific channel. You can re-purpose the 3 or 4 texture channels for different parameters, e.g. storing the metallic value in the red channel.

Now, if you have several objects with the same material but they must have different parameters, you can give MaterialPropertyBlock a shot. Instead of creating individual material instances, you can create a *MaterialPropertyBlock *for each renderer that needs custom parameters. You can then set your individual parameters in each of these blocks. This will not reduce your draw calls but it will make rendering much cheaper, as you're explicitly telling Unity what's different about each object.

Creating texture atlases for materials sharing a shader often follows this pattern:

Create a big texture we'll call texture atlas.
Take a texture channel of all materials and fit its textures into the newly created texture atlas.
Go over the meshes using these materials to recalculate their UVs. The new UVs will point at the new sub-region of the texture atlas that contains the original texture.
Disable the old mesh and instead use the new mesh with the updated UVs.
Unlink the original material to use the merged material.
Repeat all these steps per additional texture property your shader takes.

I recommend you to do this in your 3d software. If you have the time, this is the best method because it gives you fine control over the process. This will improve the output quality because you can tweak critical variables such as texel resolution. You can also apply more advanced techniques such as palettes.

If you don't have the time, resources or experience to do this, then I'll take you through another path...

Use tools to do this for you.

As a programmer, I'm not as efficient with 3d modeling tools so I often use this approach.

In no particular order, here are some Unity packages you can use to merge materials within Unity:

Once we merged multiple materials into a single material, then we can start batching our draw calls.

You need criteria that help you choose between the different batching methods.

There's always a price to pay with all batching techniques. They all have some requirements that might be hard to meet depending on your gameplay situation.

Let's explain it following the diagram sequence.

Technique 1: Unity Static Batching

Static batching is enabled by default (and I suggest you to keep it that way).

Unity applies this technique automatically to all static objects in the scene that share a material. If we start with the following draw calls:

Draw static chair 1
Draw static chair 2
Draw static table

Then static batching creates a single draw call out of them:

Draw the static dining furniture (containing 2 chairs and a table).

Unity Draw Call Batching Settings

You can find this setting under player settings, as shown on the image. Select the target platform you're aiming for to enable it.

Note for later that dynamic batching is also enabled/disabled in the player settings.

More precisely, Unity will look for objects whose batching static flag is enabled. Then, Unity will attempt to merge those that share a material.

Unity static batching works by creating a huge mesh containing the individual meshes. But Unity doesn't discard the individual meshes. Instead, Unity keeps the original meshes intact so we are still able to render them individually. We need this for frustrum culling to work. This way, we can draw only the objects that lie within the visible field of view and discard those who aren't.

By having all meshes in a single mesh, we're able to draw them all without changing the render state.

Static batching happens just before you hit the play button on the editor and also happens while making a build. Unity goes through each scene and tries to batch as many static objects as possible.

Unity Draw Calls: Static Batching

The main limit to static batching is the amount of vertices and indices each batch can have. This is often 64k for each, but check the updated requirements here.

The downside to static batching is an increased memory usage. If you have 100 stones and each stone model takes 1MB, then you can expect memory usage to be around 100MB+. This happens because the huge batched mesh contains all stones together as a single mesh.

But memory usage shouldn't be a concern for you. After all, you can check out my Unity Addressables Tutorial that will help you get huge memory savings.

Technique 2: Unity GPU Instancing

GPU instancing is one of my favorite batching techniques because it works with non-static objects.

If we have these draw calls:

Draw dynamic stone 1
...
Draw dynamic stone 100

Then with GPU instancing we convert them to a single draw call:

Draw 100 dynamic stones here and there and there...

This is a setting you activate per material, as seen below.

Unity GPU Instancing: Material Settings

GPU instancing lets you draw the same mesh several times very efficiently. Unity does it by passing a list of transforms. After all, each stone had its own position, rotation and scale.

This is a powerful technique because it does not skyrocket the memory usage and it doesn't require the objects to be static, compared to static batching.

Unity Draw Calls: GPU Instancing

To make GPU instancing work, you just need to enable it in the material inspector. If you have multiple objects with the same mesh and material, then they'll batch automatically.

However, there's a performance cost of creating the list of transforms. You pay this price once if no object moves/rotates/scales during gameplay. But you can pay this once per frame if an object changes per frame.

Technique 3: Unity Dynamic Batching

If you cannot meet the requirements of static batching and GPU instancing, you still have hope.

You can still batch dynamic objects that use different meshes with dynamic batching.

Unity Draw Calls: Dynamic Batching

However, bear in mind that Unity dynamic batching is heavily limited. You can apply it only to meshes that have less than 300 vertices and 900 vertex attributes (colors, UVs, etc). The material should use a single-pass shader as well. Make sure to check the full list of requirements here.

The reason for this limit is the CPU performance cost of creating these batches in run-time. Above 300 vertices it becomes hard to justify the batching CPU cost compared to issuing the draw calls individually.

Not only that, dynamic batching is highly unpredictable. You cannot really tell how your objects will batch. And the result often changes from frame to frame. It's confusing to check out the Unity Frame Debugger and see how results dramatically change across frames.

In my opinion, this should be your method of last resort. But hey, it's still a tool, don't overlook it.

Technique 4: Unity Run-Time Batching API

For all special cases where you want to have finer control over batching, you can just do it manually.

Don't worry, you won't have to deal with vertices yourself.

Unity gives you access to 2 powerful APIs to combine meshes in run-time.

Let's say you're driving a car. In the interior you see several elements such as the seats, the handles, the windshield and all the coffee mugs you accumulated over time. You customize these elements before the race starts.

Once you made your choice and start the race, these elements become kind of static within your car. Let me explain this...

The car itself is dynamic. After all, you're driving it .

But all its non-moving inner parts? They can be considered static relative to the car object. The windshield will always remain at the same place within the car.

Yet, Unity considers all these pieces to be dynamic. That's why static batching won't work in this situation.

Still, we can profit from the static batching APIs to create these batches manually.

The easy way is to use StaticBatchingUtility.Combine. This function takes a root game object and will iterate over all its children and merge their geometry into a big single chunk. One requirement that is easy to forget is that the import settings of all sub-meshes to batch must allow CPU read/write.

The second way is by using Mesh.CombineMeshes. This function indirectly takes a list of meshes and creates a combined mesh. You can then assign that mesh to a mesh filter and you're good to go.

I simplified the explanation for both functions. Check the documentation for details on how to use them.

In the image below, you see how I applied the power of the StaticBatchingUtility API to batch a few dynamic tanks into a single static batch. And I do this in run-time.

Unity Draw Calls: Manual Batching With StaticBatchingUtility.Combine

See Draw Call Batching in Action

I know...

With so many possibilities, benefits and limitations, batching draw calls in Unity can be overwhelming at first.

It's hard to understand in an hour what took me years to master.

But you can take shortcuts.

That's why I prepared a resources pack to guide you in optimizing your game.

This is what you're getting:

A full-resolution image of the batching diagram, including a printable version to keep at hand
The Unity project with four scenes showing you how I apply the four batching techniques

Get it here.

Breaking the Rules of Unity Garbage Collection

The Gamedev Guru — Wed, 01 Jan 2020 21:02:42 +0000

Once upon a time, there was a unity game programmer called Lancelot. A very passionate one, I would say. He didn't know yet, but eventually he would face the darkest side of Unity garbage collection.

(No time to read? Long story short version here)

Lancelot was always looking for bigger and bigger titles to work on. And so he worked hard to get his big chance in the games industry.

It was not easy, that he knew.

These spots in the game industry were and still are reserved for a small minority of game programmers. And he wasn't sure he'd be up to the standards, anyway.

But he persisted and continued to sharpen his programming skills.

Lancelot started working on small games. Maybe at some point, he would get the big chance he was looking for, he thought.

Years passed till he got the opportunity he was waiting for. He was asked to port a big VR game to a mobile platform. As excited as Lancelot was, he couldn't stop wondering if he was good enough for the task. It was daunting but he accepted the challenge. He knew that he could only grow out of that.

Lancelot's biggest concern was the need to massively improve the performance of the game. It was a double challenge, in fact. He had to improve performance by 20% for a considerably less powerful platform.

After months of non-stop work, he finally managed to optimize the game enough to have a rock-solid performance baseline.

However, an unexpected issue was just around the corner...

The unity profiler revealed him a considerable frame-rate drop every few seconds. And that worried him, because that wouldn't allow him to ship the game. The game release was in jeopardy. That made him utterly uncomfortable.

Based on his previous experience, Lancelot quickly suspected of the garbage collector. After all, he knew that allocating temporary memory in the game too often could cause these performance spikes. Just like the trash can in everyone's kitchen, you know it's time to clean it when it reaches 80% of its capacity.

And so he spent days fighting the bothersome memory allocations. He performed all types of optimizations he could think of. Object pools, data caching, data structure optimizations...

Spending these days optimizing got him a bit ahead in the performance journey. Lancelot was proud of his work, but his concerns only grew when he saw the garbage collector still running every 15 seconds.

Playing the game in VR with these performance drops would somehow make people look pale.

"How could that be happening?" he wondered.

With more patience and digging, Lancelot discovered a second source of memory allocations he didn't see before. Those happened in a 3rd party library.

He had a look and soon realized he was in the worst position ever: that library was closed source. Not only that, he also tried using Unity's incremental garbage collector but he couldn't afford to pay its performance price.

Lancelot was running out of options.

He felt desperate but managed to keep calm. He's been in worse situations after all.

He could reverse engineer the library and do the memory allocation optimizations himself. The problem was that the license disallowed such things. And he was too young to go to jail.

The second option he considered was to pre-allocate a lot of memory on the heap. He knew that unity triggered the garbage collection process when the heap usage reached a certain percentage. So increasing the heap should give him more time between garbage collections.

Sadly, that was still not enough.

It slowly felt as if he had no control over the situation. It was tough, but again, he persisted.

So Lancelot came up with a crazy idea. What if he disabled the garbage collection entirely? Was that even possible? He felt in his bones how risky such an idea was. He didn't want to add the possibility for the game to crash at unpredictable points. Last time he checked, that was no fun for the players. Maybe times did change, but better safe than sorry.

On top of that, he worried about delaying the release of the game. He didn't want his players to miss this title for Christmas. He remembered how much fun he had playing EverQuest during these holidays. He wouldn't take that away from the players.

Reached this point, he had no other choice than to disable the garbage collector.

He got into research mode and found that he could indeed manually disable the garbage collection. He ran dozens of experiments to see how long the game would hold without running out of memory. He did all sorts of tests to stress the system. Clicking everywhere, walking and jumping around, switching between different applications.

Numbers started arriving in his spreadsheet: 25 minutes, 28 minutes, 30 minutes... He also noted how the heap usage increased over time to be certain he'd never exceed a safe budget.

With those numbers, Lancelot established a generous safe margin and prepared a prototype. He would run the garbage collection manually during loading screens and every few minutes.

He had hope again.

He politely asked QA to go through the game dozens of times.

Memory was always within the budget. No crashes. No side effects.

This long journey brought him to the point where he was able to ship the game.

And guess what? Hundreds of players are now enjoying it over the Christmas period.

In the beginning, he was not comfortable with this solution. It was a risky move and he knew it. But he managed to pull it off.

Lancelot learned to be comfortable with the uncomfortable. He learned to be more pragmatic. Because there are times when a programmer has to be.

Does anything of the story ring a bell? If so, your intuition is probably right.

That programmer was me.

For the times you need it, this is how you can manage the garbage collector:

public class GarbageCollectionManager : MonoBehaviour
{
  [SerializeField] private float maxTimeBetweenGarbageCollections = 60f;
  private float _timeSinceLastGarbageCollection;

  private void Start()
  {
#if !UNITY_EDITOR
    GarbageCollector.GCMode = GarbageCollector.Mode.Disabled;
#endif
    // You might want to run this during loading times, screen fades and such.
    // Events.OnScreenFade += CollectGarbage;
  }

  private void Update()
  {
    _timeSinceLastGarbageCollection += Time.unscaledDeltaTime;
    if (_timeSinceLastGarbageCollection > maxTimeBetweenGarbageCollections)
    {
      CollectGarbage();
    }
  }

  private void CollectGarbage()
  {
    _timeSinceLastGarbageCollection = 0f;
    Debug.Log("Collecting garbage"); // talking about garbage... 
#if !UNITY_EDITOR
    // Not supported on the editor
    GarbageCollector.GCMode = GarbageCollector.Mode.Enabled;
    GC.Collect();
    GarbageCollector.GCMode = GarbageCollector.Mode.Disabled;
#endif
  }
}

~~~~

That code snippet shows you how to disable automatic garbage collections. It runs the GC process manually every minute and possibly during screen transitions (fade to black).

Be aware of its possible **side effects**:

-   **Crashes**: if you don't play safe enough you'll run out of memory. Worse, the OS might kill your game when you switch between applications
-   **Longer garbage collection times**: increasing the heap will make future garbage collections slower

If you need to **produce generous amounts of garbage**, here's a straightforward method that'll just work:

public class GenerousGarbageCreator : MonoBehaviour
{
[SerializeField] private int garbageCreationRate = 1024;
private static int[] _garbage;
void Update()
{
_garbage = new int[garbageCreationRate];
}
}

~~~~

This is what you'll be getting in the profiler:

Unity Garbage Collection: Time-Based Manual Trigger

There you see an increasing memory usage. The growing heap usage is highlighted as "mono". Luckily for us, we're running the manual garbage collector every 3 seconds.

You can clearly see this garbage generation-clearance cycle in the profiler graph. For those game developers who studied physics, you might recognize it as a sawtooth wave shape.

For more general memory optimizations, you might be interested in Unity Addressables. With addressables you get to reduce your total memory usage so you can trigger garbage collections less frequently. In turn, this will reduce the performance spikes your players will experience.

If you want the source code of this project, you know where to find it (spoiler: here).

I'm looking forward to working with you all in 2020. Happy new year.

Ruben

Unity: Your Scene Hierarchy is Robbing you Performance

The Gamedev Guru — Thu, 21 Nov 2019 07:03:17 +0000

You've optimized all of the low-hanging fruits of your game. Except that you didn't. You missed a sneaky, non-so-obvious spot: optimizing your Unity Scene Hierarchy.

[The original entry with its formatting can be found at Unity Optimization: Your Scene Hierarchy is Robbing you Performance]

What's the crack with the hierarchy now?

I want to show you something.

Launch Unity and open your game project. Then, run your game on your target device and attach the Unity Profiler to it. Record a few frames during gameplay.

In the Unity Profiler, look for the following unpleasant profiler markers:

UpdateRendererBoundingVolumes
Physics.SyncColliderTransform
TransformChangedâ€‹Dispatch

You didn't find any?

Keep looking. I'm sure you'll find at least one.

They'll spawn when you're about to give up. As soon as you mouse over the close button of the Profiler, they'll show up.

Found them already?

If so, it's your lucky day.

I discovered those in my previous project as well and I learned how to land a final blow to them.

I know the evil behind them...

Do you want to know the performance secrets of Unity Scene Hierarchies?

Quick Navigation (opens in a new tab)

Level 1 Developer: A Typical Unity Scene Hierarchy

Level 2 Developer: An Optimized Unity Scene Hierarchy

The Gamedev Guru's Golden Rules of a Clean Unity Scene Hierarchy

Level 3 Developer: The FAP Hierarchy Tool

The Gamedev Guru's Hierarchy Score

Level 1 Developer: A Typical Unity Scene Hierarchy

I still remember the first Unity project I worked on, just slightly over a decade ago.

I was not sure what the difference between game objects and components were.

But that didn't matter. I created games anyway.

Deep Unity Scene Hierarchy

Was it uncommon to see a messy unity scene hierarchy like this?

Actually, yes. Because it used to be worse than that.

Interestingly enough, you can get away with this kind of hierarchies most of the time.

But you'll suffer. You'll pay the price later on.

Luckily, before I started developing games professionally, I learned to appreciate more structured hierarchies.

A great scene hierarchy structure can be your best friend. Structure makes development and collaboration much easier.

It doesn't have to be the best, whatever that means. It's enough for it to be good.

But bear with me here. This is important.

Having a cluttered unity scene hierarchy is dangerous and will get you into trouble. This is so because it's highly unlikely you'll directly notice its side effects.

There'll be a creepy ghost chasing you, pulling you back, slowing you down. Sometimes you think you hear something, but when you look back, there's nothing. So you get used to walking slower.

I learned to diagnose these side effects over the years. And the main problem is that the side effects of a messy unity scene hierarchy are not obvious to spot.

You'll see the profiler and wonder what some markers mean. Their names are often cryptic... what secrets do they hide?

The only thing you can be sure of is this:

Mysterious markers tell you something's worth investigating

When you and I talk about structuring your scenes better, we usually discuss about increasing clarity and reducing maintenance cost.

But performance? Just like my cat *gitignores *all the toys she has around my flat, everybody forgets about performance when it comes to the Unity Scene Hierarchy.

Let's analyze the previously shown unity scene hierarchy. It contains 2,000 rotating spheres nested on top of each other.

What does the profiler say about it? Look, don't be scared.

Unity Scene Hierarchy Optimization-Deep-Hierarchy Profiler Overview

That's pretty bad for a simple prefab and a rotation script applied to a built-in sphere.

As you can see, *Physics.SyncColliderTransform *and *UpdateRendererBoundingVolumes *are taking a huge portion of your frame budget.

But let's not stop analyzing there, because I'm quite curious about this case.

Let's dig further. I hope you saved some 4G data this month for this impressive image.

Unity Scene Hierarchy Optimization-Deep-Hierarchy Profiler Details

Here lies the key of the article.

Unoptimized hierarchies causes two BIG problems in Unity.

Deep hierarchies do not allow the job system to work efficiently in parallel.
Nested hierarchies cause bottlenecks in several subsystems within Unity.

Remember my words...

Because this applies to all types of dynamic objects and especially user interfaces.

In case you're wondering, I own a Threadripper with 16 physical cores and 32 threads. Do you know how many am I using effectively in this project? Just one.

There're so many ways to say the same: the performance of your game will suffer. And by trying to fix this mess by following your gut feeling based on those mysterious names, you'll start to age blazingly faster.

What would a Level 2 Developer do with 2,000 objects?

Level 2 Developer: An Optimized Unity Scene Hierarchy

A Level 2 Unity Developer knows that parenting transforms comes at a price.

The Level 2 Developer also knows this price is paid in milliseconds of CPU time. Or, similarly put, it is paid in hours of overtime spent by the developer chasing this up.

Ask yourself: do you have enough CPU budget to pay for this expensive hierarchy?

From which area of your game are you subtracting those milliseconds from?

Will your game bombard the player with less and less flashy particles? Or will you cut the number of city invaders your player will have to defend from?

Hopefully, you'll do nothing of these two things., but rather...

"Create efficient Scene Hierarchies. Destroy those who aren't so."

Rubén Torres Bonet

The reason complicated parenting steals resources from your game is simple:

Each transform modification affects its children and potentially its parent and siblings

Unity recalculates a lot of thingies for you when you change an object's position, rotation or scale.

This process is transparently done for you, so you can focus on developing your game. That is great, but the price to pay for it becomes astronomical if you're caught off-guard.

The solution?

Keep it simple, adhere to...

The Gamedev Guru's Golden Rules of a Clean Unity Scene Hierarchy

No more than 50 total child elements per game object
No more than 4 levels of depth in any game object

Isn't that simple?

A Level 2 Developer will keep their unity scene hierarchies as flat as possible.

Look below. Same amount of objects, this time structured under a flat hierarchy.

Savings are huge, I see.

But doing this is easier said than done, right? Detaching and destroying relation(ships) between objects is a laborious, error-prone and time-intensive task.

What would a Level 3 developer do?

Level 3 Developer: The FAP Hierarchy Tool

A good Unity developer gets things done.

A great Unity developer gets things done faster, more accurately.

But how is that?

By using tools.

Because the only cheap hierarchy is the empty one, there's one key answer you need to answer at all points from your game...

How complex are your hierarchies?

You can answer this by methodically analyzing your hierarchies and giving it a score.

The Gamedev Guru's Hierarchy Score

Below 35: Smells of Trouble. RUN!
Around 50: You might be OK (For now)
Above 70: Profit! (But don't relax)

So what are the math formulas I need to calculate the score?

Luckily, none. I've done this for you.

I prototyped a tool to automatically analyze and detect bottlenecks in your hierarchy based on The Gamedev Guru's Golden Rules of a Clean Hierarchy.

I call this tool...

The Fabulous Advanced Profiling Hierarchy Tool

Run your game. Get to a point of interest. Open the tool and let it do the work for you.

The Gamedev Guru's FAP Hierarchy Tool

Let the tool *whisper *in your ear the magical melody of an integer that we will call... score.

Once you know what your score is, you know what to do... Or not?

Because I'm not giving you only that tool, but also a bonus script to boost your hierarchy problem-solving techniques.

I'm giving you the extraordinary power of the simple *DetachGameObject.cs *Demigod script.

You're not likely to encounter many 27-line scripts that will help you improving performance so much in that small time frame.

What this does is simple: it'll move your heavy and nested game objects to the root of the scene hierarchy in run-time. That way, you'll profit from having structured hierarchies during development and gain an insane performance advantage during run-time.

Chances are, you can do this for the great part of your hierarchy that is heavily nested for structure's sake.

Claim your free bonuses***** before they become a 404 error* (opens in a new tab)

And after that? Comment below and share your score.

Unity UI: My Top 3 Optimization Strategies

The Gamedev Guru — Sat, 12 Oct 2019 10:13:58 +0000

[Read the original blog post on Unity UI Optimization at The Gamedev Guru's Blog]

I normally do not share my past struggles, but this topic deserves it.
What to do when you lose hope with Unity UI?

I still remember that weekend, about five years ago...

I spent the entire weekend worried about all the technical debt I was
accumulating over the months in one of my projects. I had done
things *too *quickly, without really understanding them. Clearly enough,
that had to stop working at some point.

The thing is, I owed my clients results but I had no idea how to bring
them. That morning though, I said to myself: Rubén, this is enough.
Stop the excuses. You are becoming a professional today.

So, I decided to gather every single resource I could find about user
interfaces in Unity, because that was the biggest hurdle I was dealing
with for several weeks. I read forums, best practices, Unite videos,
read all blogs I could find on that topic and did my own research.

Did you ever experience this feeling of slowly getting overwhelmed by
technical debt? It accumulates over time and someday you either give up
or decide to crush it. In my case, it was the later.

You probably heard that optimizing UI in Unity is challenging. Or, if
lucky, you know it from first-hand experience. Yes, Unity UI is a
powerful tool and I love it. However, its mightiness can quickly
transform into a deadly weapon if it falls into inexperienced hands. And
so were my hands back then.

If I had to confess anything to you today, it would be this: I wished I
had had a solid foundation on Unity UI before I designed the UI of
several games.

It is SO easy to do it wrong, SO easy to get frustrated. In my opinion,
there's something even easier than that. That is, for your client to
ask you to do over-hours to get your shit together.

In my experience in the professional sector, companies do not want
developers who design poorly optimizable interfaces and leave the tuning
task to experienced programmers. They rather want developers who
create visually stunning interfaces, but also performant.

And even in the indie development scene, where would you choose to spend
your time on? Bringing fun to your players, or spending hours clicking
through the profiler to find bottlenecks?

In my opinion: no matter your role, you should understand basic Unity UI
design principles. But this takes time and project experience. You might
not have any of these.

Hopefully, I can help you there.

Today, I will give you one of my most powerful tools: The Guru's UI
Development Diagram

As usual, I'd like to start with the Level 1 Developer construct

Level 1 Unity UI Developer: free-style UI

This is where we all start: free-style design, free-style results.

I used to import sprites with whatever settings. Then, I would add them
as images everywhere with no predefined criteria. And so I ended up with
an unstructured hierarchy full of components that I didn't need. I used
the wrong systems for the wrong reasons.

Overlapping UI elements, a motherload of batches, profiler spikes. Those
are all common.

Do I have anything against this?

Partially. I think it is great to play around and to make mistakes.
Breaking and repairing help learning.

But if you want to do this for a living, at some point you might want to
level up your skills and embrace professionalism.

This becomes unacceptable in the games industry, especially in Virtual
Reality. If you do this in VR you will turn players into patients.

Such a chaotic Canvas hierarchy structure could look like this:

Level 1 Unity UI Developer: Unstructured Unity UI Hierarchy

You do a lot of nesting, you use auto-layout components everywhere and
there is a lack of rules.

At some point, someone will ask you to optimize your UI. That could be
your players, your boss or even your own pride.

But you might not be ready for this. You might be caught off-guard
having other tasks on your plate. And UI development is daunting at the
beginning.

The reason for its complexity lies in the amount of factors it involves.
Leaving the visual appeal aside, you can say that the way you work
with Unity UI will have a big impact in three critical hardware pieces:
the CPU, the GPU, and the developer theirself.

If you are lost, it's good, because...

I am about to show you something cool

Let's level up as a developer!

Level 2 Unity UI Developer: The Guru's UI Development Diagram

Here we are with a Venn Diagram. I decided to call it The Guru's UI
Development Diagram.

There we see three big chunks related to Unity UI Optimization: CPU,
GPU, and Developer. Those are the main resources you will have to spare
when developing UI.

I want to give you a short overview before we start digging in the
topics.

You pay the CPU toll mainly when generating and submitting batches of
UI. You can think of them as UI components, such as images. The more of
those you have, the more strain you will put in your processor.

The turn for the GPU. You pay the GPU resources mostly in concept of
overdraw. This means, stacking layers of graphics on top of each
other.

Lastly, the developer pain is paid in time. You spend time every time
you design or maintain your UI. Unity offers you some tools to make it
easier for you, e.g. auto-layout helpers.

The cost of the three components rely mostly on you, but they sometimes
counteract each other. It's very challenging to perform in every
aspect, unless you are very experienced and you have the right tools.

Eventually, you will get there.

I would like you to have a closer look at the attached Guru's UI
Development Diagram.

You might be confused. That's alright because we are going to cover
each section separately. You will get to understand all of it.

For now, you only have to understand one thing: in the end, it will be
up to you to find the balance between the three variables in your game.

Before we start with each component, have a look at these general rules:

The easier you want the UI design workflow to be, the less performant your UI will be.
If you want more GPU performance, you will have to focus on finely tweaking graphical elements and avoid element stacking.
For more CPU performance, you will need to reduce the amount of graphical elements present in the hierarchy.

Let's move on, I can't wait to show you the CPU side of Unity UI
Optimization!

Level 2 Unity UI Developer: The CPU

In my opinion, this is very simple.

The golden rule is:

Every time you add a UI component in your scene, you are adding CPU
overhead

Each component increases the CPU cost for the following reasons:

RectTransform calculation: this is pretty much free in simple canvas hierarchies. However, your CPU will have a harder time if you are using auto-layout components to ease your UI design workflow, such as vertical layout groups and such. The issue with those is that most *RectTransforms *present in the hierarchy will now depend on each other, so the calculation becomes more complex.
Vertex generation: the GPU understands vertices, thus those must be provided by the CPU. Vertices must be generated based on the entire canvas hierarchy of the involved RectTransform elements*. *The vertices depend as well on the specific type of UI element you added (images, texts). Under this category, we also include the cost for the CPU to add other per-vertex attributes such as colors and UVs.

Dynamic batching: because draw calls are expensive, Unity does its best to dynamically batch as many of them as possible. Think of this as combining a large number of small groups of vertices into a single, huge group of vertices. Because... would you rather go to the supermarket ten times to bring an apple each, or go just once and grab them all together? Batching is, however, an expensive operation for the CPU which increases with the amount of UI elements you have.
Draw call emission: finally, the generated batches must be sent to the GPU. These graphical processing units are very picky with the data formats they accept, so the CPU has to make extra work to pack them in a way that they like.

This is expensive, yes. But luckily for us, Unity is kind of smart and
caches the canvas so these expensive processes do not happen in every
frame.

Just as I brought you good news, I will give you the bad ones: this
cache is super easy to break.

Changing almost any attribute of any UI element will break the cache of
your canvas. If that happens, we go through most of the process again.
These changes, by the way, trigger what is called a canvas rebuild.

I'll give you some examples of the breaking changes: scaling,
positioning, rotation, color, image swapping, animations and more.

After exposing the basics, I want to conclude with three practical
observations:

The more elements you have in your Unity Canvas, the more CPU overhead you will have on each canvas rebuild.
Avoid any kind of changes in UI to avoid canvas rebuilds. If
needed, then put dynamic elements in different
canvases.
Canvases are either static or dynamic. Design accordingly.

Level 2 Unity UI Developer: The GPU

Now is the turn for the friendly Graphical Processing Unit, don't you
think?

The GPU is the piece of hardware that makes us fall in love with games.
We owe them so much. What about showing it some affection? Well, we
can...

By treating it well.

But guess what? UI can make the GPU pretty upset. Especially mobile
GPUs, where it is relatively easy to be memory-bound. To put it simply:

In mobile, there is a massive reason UI is expensive: overdraw!

*Overdraw *happens when we render the same pixel multiple times per
frame. And this is soooo easy to achieve with Unity.

Every time to add a Unity UI Image, you are commanding your GPU to
draw a full rectangle, rendering every single pixel inside that
rectangle. And it does not matter if the pixel you are drawing is
transparent, it will cost you still.

That means, I advise you to be careful with the transparent regions of
your sprites!

This has some implications for you. If you add 10 full-screen images,
then you get 10x overdraw. As my grandmother used to say, WTAIWYG!
(What You Add Is What You Get).

Stacking of layers on top of each other will slowly enrage your GPU. It
will add milliseconds to it, which is a crime in VR games where your
budget could very well be under 13ms.

I do not want to get too technical in this post... but I can't just
help it! Some day you will be having a delicious coffee break
conversation with your colleagues and you might feel tempted to drop a
few intellectual lines. If that's the case, say this one aloud:

UI Overdraw is expensive in mobile because you devour the precious
memory bandwidth of the device and this is further worsened by the alpha
blending happening internally

You'll make some jaws drop.

The key lesson is easy: avoid stacking UI elements on top of each other
and you will be fine

GPU cost mainly comes from stacking graphical layers on top of each other. Avoid these.
Reduce the space UI takes in screen to reduce GPU cost.
Implement sprite atlasing to improve CPU and GPU performance.

PRO TIP #1: Sprite Atlasing

PRO TIP #2: Opaque UI Shading (Advanced)

Level 2 Unity UI Developer: The Developer!

I am afraid we often under-estimate the effort required to design,
implement and especially maintain optimized user interfaces in Unity.

Surely, Unity improved in this area during the last few years and now it
is easier and faster than ever to create those. But this comes at a
cost.

In general, the more Unity UI extras you use, the worse your game
will perform.

The auto-layout helpers are especially expensive. Unfortunately, they are the most helpful. For
instance, I find Vertical Layout Groups especially handy when designing
responsive UI. These neat scripts help you organize your elements in a
manner that is structured and therefore visually appealing.

The problem I see with those is that they incur on a big CPU cost
whenever there are canvas rebuilds!

You might be able to get away with UI helpers if your UI is static 99%
of the time, but the frame it isn't, you will notice it.

We love working with helpers, but we don't want to ruin our
performance. Here's one trick you can try: keep the auto-layout helpers
around while designing but disable them all just before saving your
scene. By doing this, they will be deactivated for run-time players, but
they already did their work for you!

I don't want to disappoint you, so just remember that this auto-layout
disabling secret will not work if your UI content is dynamic.

At the end of the day, the more tasks you delegate to Unity, the more
work your hardware will have to do. Find your own balance here! You can
start using those helpers but be ready to remove them if you have to.

While optimizing, do the biggest gains for the buck first. Only advance
in the ladder of diminishing returns if the profiler tells you that you
have to.

For instance, creating sprite atlases is easy and will bring you good
fortune. Tweaking graphics to avoid transparent regions, however, is
more time-consuming. Lastly, creating your own UI shaders might bring
you big gains but at a big cost.

Remember, saving a few microseconds in your game might not be worth if
it costs you weeks of your life-time and your application does not
need it. This should not be taken as an excuse to never
care; optimizations in the future are more expensive than in the
present.

Profile before you optimize
Keep profiling
Go for the biggest gains for the buck first

Level 3 Developer: The Sweet Spots

From the Venn Diagram, you might see several sweet spots where you
could find yourself in: Fine-Grained UI Development, Coarse-Grained
UI Development, Massive PP *and *Balance.

They sounded quite obscure to me at the beginning, but then, with time,
it all started to make sense to me. Experience brought understanding.

What I still hold true is that, the more tools you know, the better.
This is the main way I am able to recognize the subtle patterns in all
problems. And, when you recognize the heart of the challenge, you know
which tool to take out of your toolbox.

Nothing will help your team more than having a developer possessing both
a high-level overview of UI and an eye for detail.

A Level 3 developer would confidently answer important practical
questions that only come through experience. I can think of a few that
any client could ask you:

Here's a UI architecture for you. How performant is it?
What are 3 alternatives I have to optimize this user interface?
Can you show me numerical proof?

You see, I prepared a few Unity examples for you.

The examples you will have access to illustrate each of the UI
optimization methods I propose.

Not only that, I analyzed them all so you can feel safe the information
is accurate.

Because... do you know what comes after speaking out of our gut
feelings? Speaking with certainty, based on real experience.

So, are you serious about becoming a Level 3 Unity UI Developer?

---> Grab Now the Level 3 Guide from my Blog Post .

Unity Addressables: The Final Quiz Analysis

The Gamedev Guru — Mon, 07 Oct 2019 20:48:48 +0000

This post on Unity Addressables Quiz was originally published with its original formatting in The Gamedev Guru's Blog

Heya, Unity Addressables fan.

Last week, I posted a short but powerful article detailing three Unity Addressables benefits for your game. The article was very well received, thanks for your active participation.

Just at the end of that post, you were given the chance to test your knowledge in Unity Addressables through a short quiz.

The goal I had in mind when creating the quiz was to help you become aware of the areas you might be less familiar with, so you can get to develop your skills where you need the most.

I'll confess that, initially, I didn't expect many people to go through the quiz. After all, quizzes can be daunting and, as usual, there's this extra babbling coming from me.

But to my surprise, the quiz results well outperformed my expectations. I'm really happy to see that so many people accepted the challenge. You all rock!

I got some interesting statistics out of the quiz. Here are some figures I wanted to share with you:

The greatest part of the people who started it, about 80%, actually were determined enough to finish it
The average score was about 12, which is pretty damn good for an API that was only introduced recently
5% of the quiz participants fell in the Troll Guru rank
About 35% are part of the Apprentice Guru group
45% of the participants scored enough to be Enlightened Gurus
But only 5% made it to be considered The Final Boss Guru

So, congratulations if you were part of the quiz experience!

And independently from the score you got, I am sure it will not take you much effort to reach the production-level required score of 20+. I'll be helping you along the path.

In this post, I will explain the most interesting challenges posed in the quiz. Some answers might differ depending on your particular context, so make sure to comment at the end of the post if you had a complementary experience.

If you didn't complete the quiz before, do it now before reading further.

Do not cheat. I'll know.

What were your results? Are you a Troll Guru, an Apprentice Guru, an Enlightened Guru _or _The Final Boss Guru? Share your results in the comments section.

Trusting that you finished it, let's have a look at the questions and some of the answers. The format should be self-explanatory, but I admit I could have chosen less cheesy graphics for it— yes, that's me.

Question 1: Intense Memory Pressure

An angry player leaves a 1-star review because your game uses too much memory. You...

Answer in public, telling the player to upgrade their device and then come back

This is a popular answer somehow. As much as we might feel like answering this, chances are, we have been too busy (or lazy) to implement a proper architecture. Blaming players for playing with a brick-phone won't get us more sales, so a better strategy is to fix our mess.

Switch to a more advanced texture compression method, e.g. ETC2 to ASTC

This is helpful and you should indeed switch to more advanced compression methods, where possible. But this solution will only take you so far. You'll get moderate gains in memory usage and texture quality, but they'll not be enough to cover your memory pressure issues.

Split your scenes into sub-scenes, so less content is loaded in memory

In general, sub-scenes used to be a good solution. I've used them in the past with great success. However, if you are having bad reviews already, chances are it is too late to introduce such a massive change in the architecture of your game. Better to look somewhere else.

Implement an asset lazy-loading mechanism through AssetReferences

Over 75% of people agreed on this, that's great.

AssetReferences are likely to give you the biggest gain for the buck. The migration to this workflow is usually straight-forward and much easier than the other alternatives.

However, be aware that, in some cases, it might be hard to work around the asynchronous requirements of the Unity Addressables API.

Question 2: Endless Loading Times

You press the play button. By the time your in-game scene is loaded, your coffee is cold. You...

Blame the artists and ask them to put every texture into atlases. Also, you buy a faster PC

10% of the subscribers chose this one. I love you guys.

Reduce the texture size globally, so asset loading is much faster. You don't submit these meta file changes in your versioning system

I've done this a few times recently. It works.

However, the pay to price is high. Your versioning system might go nuts and your changelists will be full of garbage. This is indeed hard to manage, as if you ignore these temporal texture import settings modifications, the real changes will mostly go unnoticed and won't be submitted.

Create custom scenes that contain just the functionality you are working on

Creating sub-scenes for faster iterations might be a possibility for your game, but in my experience, they tend to be left unmaintained. With time, they break and one might spend more time fixing them than the gain you eventually had back then.

Consider implementing sub-scenes only if you don't see these problems in your project.

Remove direct references and add indirect references instead, so only the required assets are loaded

Indirect references for the winner.

Direct references will implicitly ask Unity to load all their content as soon as the script holding them is instantiated. Indirect references, however, gives you full control over the when/how/what. That means, you can delay loading until you need it, if at all, saving you from unnecessary loading times and wasted memory.

Question 3: What Play Mode Script?

You are currently implementing materials for your new characters. You want to try Addressables, so in the Play Mode script section of Addressables, you select...

Fast Mode: we want it always fast, after all

This is a valid option, but fast mode does no validation at all of important aspects of development, such as asset dependencies and cross-references.

If there are no substantial changes in the content you're working on, fast mode will be fine. Otherwise, we can do better.

Packed Play Mode: yes! we want our characters to be packed

No! The Packed play mode requires you packing the assets every time you do a change in your addressable asset contents, otherwise you'll end up loading the old versions.

You don't want to be packing every time, it's a huge time sink.

But you might consider packed play mode once you're done working with addressables content to gain faster iterations, as these assets will require minimum processing while being loaded.

35% of the Guru Challengers chose this answer.

Virtual Mode: it sounds safer than fast mode

Virtual Mode is the option I suggest you using while actively working on your addressable content.

The virtual mode is fast enough to keep iteration times short and at the same time, it'll give you useful validation checks to avoid screwing it up and finding out the mess way too late.

Question 4: Oops... Error Diagnosing

You try Addressables but you don't recall your assets looking pink in your Android device. How weird! You...

Enable the ADDRESSABLES_LOG_ALL symbol, make a development build and check the logcat logs

If you came to me with such a description, I wouldn't necessarily take you down this road directly.

The main issue with adding scripting defines and checking the logs on the device is the time it takes to prepare such a build, deploy it, test it and gather useful information from the logs.

There are indeed better ways to tackle this, but certainly keep this as a backup option if they fail to give you an accurate diagnosis of the problem.

Set the play mode script to Packed Play Mode and run it in the editor to further diagnose the issue with the Addressable Profiler

Emulating as much as you can the environment in which the content will be displayed is my preferred option, as it takes the least total amount of time. You do this by selecting the packed play mode in the main Addressables Window settings. The Unity Editor will load the addressable resources directly from the built content, so this is expected to give you a similar behavior than on the device, as long as the editor can load such a content.

You can also try running it in virtual play mode, which does some validation on top of the traditional asset loading pipeline for addressables.

Don't forget to count on the Addressable Profiler's help, a tool that will inform you about the addressable operations that are taking place at all times in your game.

This answer was correctly chosen by 66% of the participants.

Post in StackOverflow and Unity Answers

12% of you see value in posting questions on these platforms, as there are always people willing to help. But preparing a reproduction project, posting and refreshing your screen with F5 is likely to take you much longer than just diagnosing and fixing the problem yourself. Trust me, this should be your last resort.

Question 5: Heavy Video Packing

You want your mp4 trailer video to be included in your game. You...

Toss it into the StreamingAssets folder

The StreamingAssets directory works just fine, especially when coupled with famous video plugins you find in the store. The assets stored in that directory are not packed together like Resources do but rather left as individual files when your game is installed. Its simplicity and easy I/O is the reason it is the default method of playing video.

The biggest con is that the assets stored in StreamingAssets are forcefully packed in your distributed game from the beginning, so they are likely to take a lot of space in your build.

Why would your users have to wait 5 minutes longer just to download the credits video that will be played at the end of a 30+ hours game?

Mark it as Addressable, add a "videos" label to it

Sure, making it addressable sounds cool. But adding a "videos" label to it?

Usually, labels are used to download all assets belonging to that label category at once. Unless you have a very specific use case, doing this is not likely to help your project.

Mark it as Addressable, adding it to a "videos" group with the following attributes: static content, no compression

Videos are not likely to change, so making them static makes sense. Also, there's no need to compress them, as the used video codec should already offer you compression. Adding LZ4 or LZMA compression on top of this already-compressed content will only incur in CPU overhead. Your users' battery will drain faster as well. I'm sure your players wouldn't appreciate it.

Mark it as Addressable, adding it to a "videos" group with the following attributes: dynamic content, LZMA compression

Dynamic, compressed content is by far the most commonly chosen answer. But it is a misleading one.

For the reasons stated above, you should avoid using compression on already compressed content. And videos are often enough very static, so by marking that group dynamic you wouldn't be helping your asset building workflows.

Most people (46%) thought this was to best option.

Question 6: Memory on Instance Releasing

You loaded your asset once through LoadAssetAsync. Now you're done with it, so you...

Call Addressables.Release, so the memory is immediately released

There's no guarantee that the memory will be freed right away, as the current documentation correctly points out. But do not worry about it too much, it will be correctly freed by Unity. 23% popular.

Call Destroy, we better make sure we free that memory up

Addressables is, as of now, unaware of traditional Unity instantiation and destroy mechanisms. If you do so by yourself, you are doing it at your own risk and bookkeeping. If you mess it up, the API and OS are unlikely to be happy about it. And you will know.

Call Addressables.Release, so the memory is released at some point in the future

The documentation implies that the memory occupied by addressable assets will be freed at some point in the future after calling the Unity addressables release method.

You can count on Unity smartly deciding when it is time to do just so (e.g. low memory situations, Resources.UnloadAllUnusedAssets, etc.). You guys got this one right!

Question 7: Loading with LoadAssetAsync

You're excited about doing your first Addressables.LoadAssetAsync. So you call it and use its returned handle like...

while (handle.Status == AsyncOperationStatus.Succeeded) ;

I confess to you that I've tried this method to try to force a synchronous behavior out of the Addressables API (e.g. Photon Networking under Unity Addressables).

But you can guess what happened after seeing the answer's smiley. My computer's fan started spinning insanely fast and I had to reboot the computer as the OS became utterly unresponsive. I'm not trying this again any time soon, thanks.

Doing this loop is likely to cause a deadlock, as part of the loading process is executed in Unity's main thread. And that line of code is the easiest way to block your main thread.

await handle.Task; or yield return handle;

These two solutions are asynchronous ways of waiting for the loading process to finish before continuing with our code. That's great stuff for you and me, as they offer great readability and are easy to maintain.

However, be aware they incur on some performance penalty.

handle.Completed += OnLoadCompleted;

This is the simplest and yet most powerful option to do something after the asset has been loaded into memory.

Keep in mind, though, that you're introducing lambdas and/or callbacks. They will reduce the readability of your code and therefore make your programming style more dangerous. Unless you are a pro, of course.

Question 8: Migrating to Better Workflows

You have a bunch of skyboxes living as direct references in your Skybox manager as a list of materials. Those are eating all your memory, so you...

Move them into the Resources folder and start using Resources.Load as you need them

No! Bad boy!

Don't ever use the Resources directory for heavy assets. They are a major cause of pain, tears and burnouts in large scale projects. It is indeed surprisingly easy to misuse the Resources API. Read more info on why it is so here

Put all skyboxes in an asset bundle that you will load appropriately

Asset bundles were a much-needed solution back then. But we have better solutions now with Unity Addressables.

The issue is that working with asset bundles is way more tedious and expensive to implement and maintain than just using Unity Addressables. Unless you're doing a port and you don't want to touch much of the original systems, try to avoid them.

Replace the list of skybox materials with a list of AssetReference's and load them as you need

Using Unity Addressables is probably the best option to tackle this kind of memory issues.

One of the reasons it is such a silver bullet is because you can easily migrate from the most popular approaches of managing content such as direct references, resources API, additive scenes and asset bundles.

Unity Addressables are a simpler way to develop more efficient games.

Decrease the skybox texture sizes

Tweaking the texture import settings works up to a point. This has an upper ceiling limit, as you cannot infinitely go lower in memory usage (and quality) without re-categorizing your 3d game into pixel-art. This just doesn't scale well.

Chances are very high that you didn't reach the rank of The Final Boss Guru.

But that's good, because that means there's massive room for improving and optimizing the way you develop and ship games. And what is more important, your players will appreciate the expertise you build in each of these areas. The only place you want to read 1-star reviews is at the app store of your competitor's game.

Given the importance of delivering enjoyable experiences to your players, I will share something with you.

Between you and me: I have a work-in-progress plan for maximizing the potential of your game with Addressables. In the upcoming weeks, I will be revealing to you more information about the Unity Addressables level-up program I'm developing. That program is going to get you to the production level you need to deliver the games people will deeply enjoy (purchasing and) playing.

To make sure you don't miss on the upcoming content, subscribe now to the newsletter. I'll keep you posted.

Till then, comment below on what you would like to learn the most and also how you plan to use Unity Addressables in your project.

See you soon on the blog!

Rubén

3 Ways Unity Addressables Will Save Your Game

The Gamedev Guru — Sun, 29 Sep 2019 14:10:11 +0000

[This post on Unity Addressables Benefits was originally posted with its original formatting at The Gamedev Guru's Blog]

If you've been following me, you will probably know my interest in Unity Addressables. That is for a reason.

Unity Addressables is a powerful Unity package that upgrades the way you and I have been tackling some of the most important challenges in Game Development: efficient, pain-free content management.

When managing your game assets, it's hard to keep good standards that prevent our project from becoming a disgusting pile of mess. A big issue there is the coupling between the different responsibilities of our asset management systems.

The way we store the assets in our project has way too much to do with the method we load them, and later use them.

For instance, you may decide to store an innocent sprite in the Resources folder. This, in turn, will force Unity to build the player in a way that that sprite is put into special archive files. And the fact that it was put there, will corner you into loading it through the Resources API.

Things get messy quicker than you can realize!

One choice, multiple long-term consequences.

A good system will prevent you and me from easily making sloppy mistakes like that. A great system will be that, and also easy to learn and use.

With Unity Addressables, we separate the asset management concerns. Our goal is to remain flexible and to keep our project maintainable.

Here are 3 proven ways Unity Addressables will help you and your games:

1. Reduce Your Game's Memory Pressure

When you publish your game, you'll be required on most platforms to specify the minimum hardware specifications your players must meet to buy and play your game.

The math is easy here: the more hardware power you demand, the fewer will buy your game. Or, seen from another perspective, the better memory management you do, the higher the amount of content and fun you can offer in your game.

Unity Addressables helps you in this regard enormously!

To give you a brief idea, converting this kind of code:

public class CharacterCustomization : MonoBehaviour
{
    [SerializeField] private List<Material> _armorVariations;
    [SerializeField] private MeshRenderer _armorRenderer;

    public void ChangeArmorVariation(int variationId)
    {
        _armorRenderer.material = _armorVariations[variationId];
    }
}

Into this other one:

using UnityEngine.AddressableAssets;

public class CharacterCustomizationV2 : MonoBehaviour
{
    [SerializeField] private List<AssetReference> _armorVariations;
    [SerializeField] private MeshRenderer _armorRenderer;

    public IEnumerator ChangeArmorVariation(int variationId)
    {
        var loadProcess = _armorVariations[variationId].LoadAssetAsync();
        yield return loadProcess;
        _armorRenderer.material = loadProcess.Result;
    }
}

Will bring you these results:

Easy gains I'd say.

2. Sell Your Next DLC - Quick and Easy

The fact that Addessables gives you full control over how, when and where to store and load your game assets is incredibly useful for implementing and selling Downloadable Content.

Even if you are not thinking of releasing DLCs any time soon, just by using Unity Addressables in your project, you will have done already a big chunk of the work ahead.

Other approaches for selling DLCs, such as Asset Bundles, are a very deprecated way of doing the same thing but at a much higher cost. Maintaining a well-functioning Asset Bundle pipeline is painfully time-consuming and requires a high degree of expensive expertise.

There are many ways you can approach implementing DLCs in Unity, but for starters, this is a good starting point:

public class DlcManager : MonoBehaviour
{
    // ...
    public IEnumerator TryDownloadDlc()
    {
        if (_hasBoughtDlc && _dlcDownloaded == false)
        {
            var operationHandle = Addressables.DownloadDependenciesAsync("DLC-Content");
            while (operationHandle.IsDone == false)
            {
                _progressText.text = $"{operationHandle.PercentComplete * 100.0f} %";
                yield return operationHandle;
            }
        }
    }
}

You get the idea.

Why would you say no to selling more entertainment for your players at a fraction of the cost?

3. Reduce Your Iteration Times

Using Unity Addressables will reduce the time wasted waiting in several areas.

Tell me, how frustrating is it to be blocked for half a minute after pressing the Unity play button? And it only gets worse if you deploy your build on another platform, such as mobile or WebGL. This all starts adding minutes and minutes to your iteration times. It gets old so quickly.

I don't like waiting either.

But do you know what I like? Unity Addressables, my long-awaited hero. This is how Addressables will help you:

A) Reduced Build Size

Your game has a lot of content, I get it. Gamers love enjoying content. Developers love creating content.

That doesn't mean, however, that every single asset you produced has to be included in the build your players will install. In fact, you should remove as much as possible.

Players want to start playing ASAP. And they're not happy when your game steals 2GB of their data plan and 30 minutes of their gaming time. They'll just keep downloading Candy Crush kind of games that install well under 50MB.

One strategy is to include only the assets needed to run your game up to the main menu. Then, you can progressively download the rest of your content in the background, starting of course downloading the first level of your game.

It's also neat to realize that your deployment times during development will sink. You'll be able to iterate more times each day; this benefit quickly adds up in the long term.

B) Reduced Load Times

We, both as game developers and as players, hate waiting. Waiting takes us out of the zone and before you realize it, it is time to go to bed.

Unity is working hard towards reducing the time it takes us to start playing our games, both in the Unity Editor and in the games we distribute.

But not hard enough.

Things look promising in the future, but not without side effects. Avoiding domain reloads in Unity 2019.3 looks promising, but as of today that's still in beta and not everyone can profit from it.

In the mean-time, we can do better than just being frustrated.

Let's say you're working on a medieval game. Several months ago, you implemented armor types for your game. You did a pretty damn good job and generated over 100MB of content.

At some point, it was time to move on and right now you're working on something else, let's say sword fighting.

Realize that, every time you press the play button to work on your features, you are loading an insane amount of data coming from all the already developed features, and loading this data takes a massive amount of time. You press play to test your sword fighting animations, and you spend 5 seconds waiting due to loading the armor features you implemented.

The time wasted in loading is mostly spent on I/O (Input/Output), because memory bandwidth is expensive. And, on top of that, your CPU has to process it. You, as a developer, pay this time penalty while developing in the Unity Editor. But your players pay it as well in the games you are distributing.

Knowing how big of a deal this can be, let's ask ourselves: which shortcuts can we take here?

It turns out that Unity Addressables can help us here in two ways.

Addressables will reduce your Players' Loading Times

We can alleviate some of our players' pain.

Keeping indirect references to our assets instead of direct references will drastically improve your loading times.

By using indirect references (AssetReference), Unity will not load everything at once but only what you tell it to. And more importantly, you have direct control over when that happens.

Addressables will reduce your Unity Editor Iteration Times

How much do you know about the play mode script in the Unity Addressables Window? The play mode script defines how the Unity Editor should load the content marked as Addressable.

With Packed Play Mode selected, Unity will directly load your pre-built addressable assets with little to no processing overhead, effectively reducing your Unity Editor iteration times

Just do not forget to build the player content for this to work

What if you applied these strategies to your most demanding content?

4. Extra: Are You There Yet?

It is true. Unity Addressables is very helpful. But this package will help only those who want to be helped.

After reading how Addressables will help you producing better and selling more to your players, you probably want to start with it right away. However, starting in this new unknown area may be challenging.

To make the most of your chance, answer these questions first:

Where are you standing right now? Are you just starting, or are your skills production-ready?
When to use indirect references, when to use direct references?
What's the bigger picture?
What is your next logical step?

[

→ Take this short quiz now to test your answers ←

Unity Immediate and the Art of Automating Playthroughs

The Gamedev Guru — Tue, 17 Sep 2019 17:50:26 +0000

If you love developing hard games but aren't a good player yourself, you have a challenge ahead.

Last week, while working on a game, I noticed that I could not beat my own levels anymore. I wanted to reach the final boss, so to speak, and that single thingy took me longer than I'd be happy to admit. It might be the age, or that the game is simply too hard.

So I started looking for different ways to save time. As always, cheating was an option. I also thought of making a special, shorter version of my gameplay to avoid playing through the same hard spots every single time. After all, I just wanted to test the final boss!

As you know, there are many ways of approaching this. But, in my case, I came up with an alternative approach that ended up being surprisingly useful. This strategy helped me shortening the testing times of my games plus cutting the design iteration times.

If you are a programmer or designer, this article will give you insight into a second approach for handling these challenges. If you have any other role, well, share this article with the right person.

To present the use case, I looked for an open-source game on GitHub. And so I found a cute little game called Popcorn that I borrowed from TheAislan (full credits to him!). It's a basic 2d platform game that features simple 2d physics mechanics, perfect for our use case. Check the screenshot above, isn't it adorable?

I'll start off by telling you how I used to deal with testing...

Level 1 Unity Developer: The Grind

A decade ago, grinding was my preferred way of working (oh dear). All the testing I did was manual, and it was all fun.

Then, weeks passed and the game got more and more complex. I started growing frustrated, since now playing every time took me almost 20 minutes. Tweaking the final boss scene transformed from being a pleasant moment to sucking all my mana and burning the entire QA's yearly budget.

Something had to be done, and so I searched for solutions.

One workaround was to split each level in multiple, even finer sub-levels. That way, we could just load the specific sub-level we want to test. This solution might work well for games whose level areas are highly independent of each other, such as platform games. This has some overhead on the programmer when it comes to scene management, but it's quite alright.

Another possibility is to add custom in-game panels or UI inspectors to enabling cheating and special actions. Those could allow the developer to skip certain parts, increase stats or just disable annoying ads. These work just well, but some time has to be spent on preparing and maintaining the front-end.

And here comes the classic: a configuration file to be loaded in run-time. That sneaky file can be used to choose which features or cheats to enable. That may look like below:

{
  "GodMode": true,
  "AllLevelsUnlocked": true,
  "Gold": 500,
  "SkipAds": true,
  "UnlimitedTime": true
}

You can load such a configuration file through a C# script like below:

[Serializable]
public class Cheats
{
    public bool GodMode;
    public bool AllLevelsUnlocked;
    public int Gold;
    public bool UnlimitedTime;
}
var cheats = JsonUtility.FromJson(File.ReadAllText(Path.Combine(Application.persistentDataPath, "cheats.txt")));
player.Gold = cheats.Gold;

Of course, make sure not to enable that feature in release versions 😉

These options have one common problem: we have to pre-define what is possible in advance. We get what we programmed; we don't get what we didn't.

That can quickly become a time sink:

During testing, we decide we need X. Therefore, we stop playing and wait for a programmer to implement X.
We then replay till that point and perform X, only to realize we actually wanted to do Y.

In some situations, we could clearly profit from having more flexibility.

So I asked myself: can we do better?

...Continue reading the article at TheGamedev.Guru