Unity Addressables: Your Quiz Analysis

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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!

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.

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.

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.

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

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.

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.

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.