Feedback Addressables Frustrating in Practice

I've used other game engines where memory managed workflows are like this:
- Reference some data in an asset
- Add the data ref to a loading list to be used when a level/context is activated
- In game script reference and use the data
- Data is unloaded when the level/context changes and the new level/context loading list omits the data ref

The addressables system is quite frustrating to work with, and not just because of the asynchronous bits. Let's see how the pipeline looks:
- I have some assets that already reference data. Too bad you have to add new AssetReferences to the same asset. Mysteriously there is not even a convenient way to get those AssetReferences from the existing prefab data. You have to check an addressables check box on the data first, then add it to the asset a separate reference, then add it to an addressable group with an appropriate label.
- Now I want to use the data in game script. OK load every asset with that label - when it is done loading infer the type from any components on it. But how to actually use it in the original context? Looks like you have to store some reverse look up tables to navigate from the AssetReference to the IResourceLocation, to the actual asset itself.
- So when all is said and done script can't even use the new AssetReferences directly, but can only use them to get a solid reference by dressing it up with indirection.

Am I doing something wrong? It sure feels like it.

The example cases are not bad in a vacuum, but in practice these development pipelines feel unplanned and impractical. Setting up data with labels and using a separate API for common load/instance actions is fine on their own, but the overall workflow is a complexity minefield.

 

I assume you want to load an asset afterwards and not on loading time? If not you can just reference the asset and have it loaded when you referencing asset is loaded.

For the case you want to load something in the middle of your game you need to work with the AssetReference or load via Address from the API. If you want so filter for a specific type of asset to load you can use one of the derived classes of AssetReference.

You are speaking of a level context, could this workflow just be achieved by loading scenes?

 

Well even in a single player, linear game there will be shared assets between scenes. So sure, for stuff like level geo and props keeping everything in the scene is fine, and does not require anything special from the addressables system (but even there you will find gotchas about loading inactivated scenes).

Think about the contexts of shared content across levels (say sound effects), streaming levels, or player customized MP. Any asset management here will already be indirect; it is adding complexity and indirection on top of this that I find is an issue. Even a simple game will run into these cases - it feels like the pipeline evolved from a technical solution instead of from a designed workflow, of which there are many good examples already around the industry.

 

I think root problem is the AssetBundle system. Everything that is a dependency of an asset in an bundle gets pulled in and duplicated if referenced by more than on bundle. And the biggest Problem: unloading a bundle as a wohl is the only efficient way to free up memory. You can call Resources.UnloadUnusedAssets, but this can cause spikes...

When memory pressure is not a problem you can get away with adding folders in groups and generate a dependency on them by your scene. I think that is the use case Unity wants us to do. Many features works with scenes, Occlusion Culling, Lightmaps, etc).

So sure if you have a more complex scenario, like streaming parts of a level, this does not work. I end up doing a system that is works on AssetPostProcessor. Sorting assets into groups and adds labels extracted by their name and location in project. It is not fun, but the only way when you want to keep track of 20.000+ assets. I banged my head multiple times to find a good layout for my assets to have them unloaded without packing every asset into a single bundle.

In the end the main flaw is the AssetBundle system on which Addressables build on. So no real way around it without changing the underlying system.

 

The biggest outright blocker to using Addressables is that the developer facing API and docs are what i would politely call a doubleslit experiment in insanity, you have to go through the slit to see if you come out insane or not. I've liked almost all the other newer stuff in Unity and have used quite a few of them. But i can't think of anything nice to say about Addressables, especially on the API side where one actually loads unloads and handles references, it's a mess and many methods behave radically different in build and editor.