Has anyone here successfully used Addressables?

[Quasimodem1]

Sorry if this ends up being a bit of a rant, I’ve reached my wit’s end for about the 4th time just now with Unity’s horrid Addressables system. I’m very curious to know if there’s anyone out there who has managed to build an entire project with it, start to finish, is happy with the results, and ships tiny patches in a way that lives up to the “promise” of Addressables?

My 18-month experience with it has been almost entirely negative. I think it’s very well-documented on this forum how poor the documentation and API design is. The docs are a messy chain of revisions, deletions, and redactions across the shambling history of the feature, and are nearly devoid of solid code examples and best practices.

The API is similarly a mess of deprecated, obsolete, and poorly designed methods. Let’s select such a method at random and see what we can learn, say ClearDependencyCacheAsync(). Judging from the name, it sounds quite low-level and something I would have to have solid knowledge of the internal Addressables caching system to even know how or when to call it. Oh and what’s this, there are 10 overloads, 2 of them obsolete, and 0 of them commented in the DLL?

I will go out on a limb and say that the entire reason Unity is anything at all is due to its awesome serialization engine which allows you to drag and drop references to objects in those wonderful little public fields in the inspector and so simply instantiate them with the ultra-powerful Instantiate() call. Am I wrong in thinking that’s why most of us fell in love with Unity in the first place? Am I also wrong in thinking that Addressables destroys this workflow with the underlying notion that everything must now be asynchronous and strung together through a tangled web of AssetReferences and async loads and instantiates? I think you would have to be an amazing architect to construct a game that would operate entirely on async references. Has anyone managed this in a way you’re happy with?

Starting in late 2019, at the strong recommendation of Unity, I attempted to migrate my project to Addressables in order to be able to deliver patches on Switch and keep them below the 512mb limit. That attempt nearly cost me my entire development budget, as I hit an incredible torrent of bugs and issues and had to roll back my attempt after 2 months of concerted effort.

Early in 2021, I again tried this with another large project, this time armed with the practical synchronous fallback of WaitForCompletion(). Much of the team’s workflow was destroyed during this process as we painfully worked through the fog of documentation and numerous bugs. No gains were made other than the hope that our assets would prove to be now organized well enough to again ship small patches on Switch.

Now this brings us up to current day, where I have started from scratch with a new project and the intention to make Addressables right at the core of the whole thing. To Unity’s credit, it seems many of the previous bugs have been resolved. The documentation and API is still a mess however, and the contortions I’m forced to go through to keep my project coherent is still a huge burden. I frequently find myself hitting roadblocks and needing to spend hours digging through the source code to familiarize myself with the internals in order to move forward.

In my opinion, this is the cardinal sin of a 3rd party library. I want a black box that does what it says on the tin. Unfortunately, time and time again, Addressables proves itself to be a muddy, murky box with tons of confusing, misleading, and flat-out wrong stuff on the tin.

I get that the core of Unity was never built with something like Addressables in mind and the whole thing was an effort of shoe-horning. Also the Addressables devs are probably really depressed and despondent at how it’s turned out. But the real bad news is that I can find a number of other examples of recent Unity feature attempts that have gone off the rails in similar fashion. I felt like I used to know what Unity’s bread and butter was and where they were headed. That hasn’t been true for a number of years now. For the first time in my life, I’m starting to regret hitching my wagon to Unity.

So! Please regale me with your stories of how you have used Addressables to great results because I would like to learn new things and again feel good about having my studio be married to Unity.

[LilMako17]

Yes, I work for a small indie studio, and we have shipped a F2P Gacha RPG mobile game (ios / android) with Addressables (yes, the product is still live and being supported currently). We started development in 2019 and have stuck with the library through a lot of rough growth period. I won’t say it’s perfect, but we have shipped with it. I’ve had to make a lot of work arounds, and I’ve come very close to forking the source code several times, but I have managed to pull through.

Our core architecture relies on using ScriptableObjects as a library / database of “static data” (i.e we have a class called CurrencyData that extends ScriptableObject, we have 1 ScriptableObject instance for each currency in the game). Each ScriptableObject has a plethora of AssetReference fields that define links to all our assets that need to be loaded in the game (i.e. scenes, prefabs, sounds, sprites, etc.). We do no serialize AssetReferences anywhere else. Our scenes and prefabs dont have Asset References fields. This library of ScriptableObjects it then shoved into one asset bundle with no dependencies, and no scenes or prefabs have direct references to these ScriptableObjects. On boot, the game then downloads this ScriptableObject library from remote asset bundles, and persists it in memory in a singleton class the rest of the code base can access.

When we say we want to load level 1, we grab the ScriptableObject instance that represents level 1, as well as other related ScriptableObjects, like characters, FX, etc. and aggregate a list of all their AssetReferences. We then use AssetReference.LoadAssetAsync() to preload all the relevant assets while on a loading screen, and keep them cached in AssetReference.Asset. The game code will then also access the ScriptableObject’s asset reference field to use loaded assets at runtime (i.e sounds, prefabs, sprites, etc.). All this code is handled by a central AssetManager class so we can keep it one place, and so we can keep track of handles internally so we can also eventually unload what we loaded.

This system has some good benefits, like any team member can easily add new assets to the game through the Unity Editor with no code changes. All they have to do is drag n’ drop the asset they want into the ScriptableObject field and Unity will automatically mark it as addressable. These assets will automatically get incorporated into our Asset Bundle builds thanks to Addressables. Its easy for us to scale up to large amount of assets, and still continue to only load what we need for each combat. Addressables handles all the “content update” checking logic to see if there are new asset bundles to download.

Of course, as I alluded to earlier, there also have been a lot of hurdles I’ve had to jump through:

Managing sprites in SpriteAtlases is really hard with Addressables. Because of how AssetReference serializes them as SpriteAtlas guid + sprite name string, if I rename a sprite, or move a sprite to a different atlas, all the serialized asset reference that referenced that sprite are now just broken. Its also frustrating that you can’t use the object picker to assign an atlased sprite to an AssetReference like you can with prefabs. I had to write a lot of custom tooling to work around these issues. I think for my next project I will write a custom serialized wrapper class for this so I can save the guid of the sprite asset to help mitigate these issues.

When I started the project, Addressables did not supply any variation of ClearCache(), so I had to roll my own. This took a while for me to figure out how Addressables worked with the cache, and my code is still fairly fragile, but it works for the scope of this project.

At various points in 2020, Addressables went through a few internal changes that caused breaking changes in our project I had to do a lot of rewrites for. Some of these workarounds in our code may not be necessary any more, but as its a shipped project now, I’m inclined to not touch our code asset management code as long as it continues to function. Reflecting back, a lot of the problems that actually effected my project were due to “growing pains” that I don’t think are relevant for the current version of Addressables. However, there are still a few times, even continuing into 2021, I have been disappointed in the lack of stability in the library. There have been several times where I’ve had to just outright avoid updates to the library and wait for another version. You really gotta be picky with what version updates you get, and test thoroughly to make sure nothing broke.

So, in conclusion, yes I think Addressables is currently in a state where it can work for shipped games for mobile phones atleast. I think that if you want to use Asset Bundles, with the plan to release regular remote content updates for your game, you’re going to end up writing a lot of the same kinds of code / APIs that the Addressables library supplies. if you are unhappy with the Addressables API though, you should probably just roll your own. At, the end of the day Addressables is just a helper lib on top of Unity’s Asset Bundles system.

[SugoiDev]

If anyone comes to this thread looking for something simpler, there’s this pretty cool library @locus84 created: GitHub - locus84/Locus-Bundle-System: Simple Unity Addressables Alternative That Supports Synchronized API

There’s also a forum thread for it: Simpler Alternative to Addressables.

I have no affiliation to it, and I haven’t shipped anything with it (yet), I just think it’s neat. Also, locus is pretty responsive.

[skullthug]

@LilMako17

Managing sprites in SpriteAtlases is really hard with Addressables. Because of how AssetReference serializes them as SpriteAtlas guid + sprite name string, if I rename a sprite, or move a sprite to a different atlas, all the serialized asset reference that referenced that sprite are now just broken. Its also frustrating that you can’t use the object picker to assign an atlased sprite to an AssetReference like you can with prefabs. I had to write a lot of custom tooling to work around these issues. I think for my next project I will write a custom serialized wrapper class for this so I can save the guid of the sprite asset to help mitigate these issues.

Oh god no, I just switched over to using Addressables for my sprite loading (non-atlased) and… you’re right, renaming the sprite filename totally breaks the inspector assignment. >:(

[cpspace]

Poor performance has been a massive issue for me: waiting for the Addressables inspector window to update. Or waiting for them to build, is a massive headache. Sometimes they fail, and no reason is given in the console.