My main goal was to try and organize the information in a way that makes it easier to find what you want, however, I realise that there’s probably some gaps that we could fill in too.
So, I’d be interested to hear about whether there’s any documentation for Addressables that you feel is missing, or could be improved, and also whether these changes I made are an improvement for you.
Personally the thing i struggled most with the assets was:
Having a build target of webgl, and providing my own hosting, so I want to be able to upload it all to my website, yet still have it work in the editor without needing to go to my website, and not lose my marbles as to whats where and why i cant find it
Some example scripts on loading from such would also be good, so how to load scenes, etc.
A lot of the documentation is seemingly written from the perspective of using addressable to deliver cloud data which is good but addressable is also necessary for memory management and loading which confuses people.
It would be nice to have a more focused “Addressables for memory management” section that focuses on smaller scale use cases. Along with a section for potentially supporting user mods.
To be honest, so long as Addressables is built on Asset Bundles and has all the same issues with releasing assets from memory, addressables usage for memory management is pretty limited.
We need an addressables 3.0 that drops asset bundles and uses a new, better underlying system.
Good timing as I configured my game for addressables and CCD yesterday.
Something that I’ve faced often in my current project and previous workplaces is exact nature of “download on demand”.
I think a common pattern used for addressables is simply.
index catalog:
Used to list all the potential data you could download (i.e. a list of unity scenes with meta data, thumbnails, descriptions etc)
Per bundle catalog:
Load a self contained scene, on demand (i.e. user presses download)
The exact nature of how this is done has not been made clear to me, we had to create a catalog for every new unity scene that only contained the scene and nothing else,.and the update our main catalog, which at the time required releasing a new version of the app.
Eventually we dropped addressables and just used asset bundles which had the same result but without the boiler plate of the catalogs
That company stopped using addressables/bundles altogether and now just loads .obj and astc textures directly.
This was back in 2020-2021 though so I’m sure a lot has changed, but that basic pattern of having a light data layer addressables group which lets the application know what is available for download, combined with download on demand layer, would be good to know best practices for that workflow.
As for the current state of unity documentation, I always just feed it into GPT to ask it to give me a dot point “how to”:
The Loading section contains this kind of info: Load scenes | Addressables | 2.7.3 - however this page only contains one example. Is there something different you’d want from this page?
We briefly talk about strategies for organizing assets here: Introduction to creating and organizing Addressable assets | Addressables | 2.7.3 but it’s quite high level. As with many things in Unity it’s hard to give general advice when every project has its own unique requirements, but I think in this situation we could give some specific examples and pointers to help understand the best practices better. I can do some investigation my end and get this info added to the documentation.
Totally agree—this is an often-overlooked point. Addressables are the sleeper feature that every developer ends up learning to ship a title.
The typical path goes something like this:
“I don’t need addressables – I just ship all my assets with the game.”
“Why is my game using 10 GB of memory at runtime?”
“I need to become proficient at partitioning assets … so that my game uses 2 GB of runtime memory instead of 8 GB.”
“I’m partitioning and configuring assets intelligently. Some assets are packed together for space optimization and others are packed separately for load times. And never enable CRC checks because it destroys load performance. Enabling compression causes the entire bundle to be loaded into memory.”
“I have addressable handle memory leaks?”
For many of us out there, addressables are about memory, load times, and control. Once a project gets big enough, there’s just no way around it.
Ironically, I think the engine should be handling this for me. If I can come up with a heuristic for asset paging, it certainly can too.
The documentation should raise two critical warnings for developers who use Addressables to ship assets locally with their game.
CRC checks absolutely destroy load times. The performance hit is severe enough that a warning dialog should be mandatory.
Compression silently duplicates the entire asset bundle into a temporary location. So if your install size is 10GB, it effectively becomes 20GB.
Yes, these settings are technically documented. But honestly, both are incredibly destructive and the impact is far from obvious. They deserve more prominent warnings.
Appreciate the info. Recently I’ve been integrating Addressables for memory management since some Steam users couldn’t load the game anymore and I can only test down to Steam deck spec at the moment so this was unexpected.
The learning curve has been steep to say the least. Starting with the editor defaulting to completely different loading mechanism that has nothing in common with the release build and this option being hidden in some far off submenu. This makes sense if bundles are remote, not so much when they are local. I will disable CRC checks since there’s really no benefit for local bundles. And some larger bundles need to be prewarmed with LZ4, perhaps uncompressed is the way.
I’d appreciate more in-depth explanations and examples using some of the features and methods available in the ResourceManager class.
There are powerful methods in there for customizing the usage of Addressables that go largely hidden.
Explanations on the usage of ChainOperations, GenericGroupOperations, Completed operations.
On a personal level, when working with those, it’s usually related to whether or not a handle from these methods need to be released, or it’ll create a memory leak.
If memory serves, creating a generic group operation, and releasing one of the handles used in it works, but when you release the group operation, it errors out.
Some of these nuances would be nice to have explained.
I’d appreciate if you can add section where we use Addressable for Android and iOs at the same time, on iOs we have enough space so addressables will be embeded but on Android they will b preloaded from Googleplay official space.
Im always confuse how these 2 situations are handled.
Thanks
As said by @jGate99, it would be great to have some example on how to handle Google Play asset pack via install-time and on-demand delivery type on Android, and maybe texture compression targeting if possible.
And it would be good to have exemple on how to use it with iOS on demand resources too.
These 2 features are a must have on mobile but there is no exemple on how to get them work with Adressable.
By the sounds of it you have a number of case examples here:
sacb0y would like more on memory management with it, wouldnt we all
Simon_Nordon would like more clarity on how it all hangs together, to make better informed decisions, and clearly many of would appreciate it too
me - Id like something more on self hosted and development where the local assets are used for my web games
stonestad - added some tips which would be a great start to some best practice and considerations pages
MattVer would like more advice on when to to free up handles, and control it all
jGate99 would like some info for android and IOS - which probably ties in a little with my request
I think if you can add some usage cases, of how people can go about setting things up not using unity cloud, how maybe it would go up on itch.io or their own webserver, an other non PC targets, how, to best keep memory low usage, how not to mess that up and yet do better memory management.
I know I followed one of the making the big scene thing run in web, and they used addressables, but also used cloud, so when I tried to do without cloud, i bumped around like i had to head butt everything to see if that was a way forward.
Yes, while this has some use I mean more like the scenario @stonstad , addressable become mandatory for avoiding too much memory.
It took me looking elsewhere to find a more concise example of “I have a ton of objects I need to potentially load, but I don’t need them all the time only circumstantially” like for example a dress up/customization system where you have 1000+ objects with different textures and materials and you need their icons for UI, then their objects when they’re selected to load on to the character.
And then presumably make sure any unneeded stuff loaded is cleared as they leave dress up/customization (I think this causes a stutter if I remember right)
I would say a use case like the above is fairly common
Visual equipment systems
RPG armor
Character dress up
All associated UI with the above
Changing appearance between cinematics
A more organized information set on handling something like this would be helpful, not just for me since I’ve already worked it out for the most part. But when people ask linking to the documentation it’s not very clear how it applies to their needs. But I would like to know the “unity recommended” method as well since that’s always an important factor.
Speaking of itch.io this was another reason for using addressable, to reduce individual file size.
Since the size of the game was less an issue, and the size of each file was more an issue. I think itch didn’t like single files larger than 100mb which made getting a web build out very challenging. Addressable is the only real solution to manage this besides aggressive compression…
this is exactly what I want it for right now.. Im jsut starting out on a 2d game that isnt like asteroid and … well.. i want different stuffs, but i also dont want to load huge asset maps of crap im not using as my game will be web hosted on my own server… (possibly also built for android)
Edit: I dont normally do 2d, but as 3d lighting hates me to a level yet before unknown… F it, this has to be better.
Yes, I have dabbled, but only dabbled. Hence some official decent grounding material would be a great bonus because im not waist deep in it, ive paddled arounds with my trousers rolled up, with no major aim in mind.. this one.. i have plans.. and frankly i really feel i need it
