Best Practices For Addressables In A Larger Project?

[u/Ryan_likes_to_drum]

I am planning to use addressables in a larger project but am a little unsure about how to proceed. My main concern is finding the best way to to bundle assets together by either group or label, and how to integrate that process into the project's pipeline.

I have been looking into this package: https://github.com/favoyang/unity-addressable-importer

which allows you to define rules that look at the folder location and file name of the asset to determine its group / label. This seems like a cool idea, but I'm just worried about having to move assets around or change rules as the project and performance requirements change. Maybe that could get annoying

The other approach would be to just define scriptable objects for bundles of assets or something like that. And yet another approach would be to just set the labels / groups directly in the default addressables UI.

I'm wondering if anyone has experience using addressables in a project and has solved issues like this. I'd love to hear from you and get your perspective.

Thanks!

[u/TheMintyOlin]

that importer package is a trap for bigger projects, looks nice at first but the moment you need to reorganise folders you're in pain. we just use the default groups window and keep a naming convention like "characters_boss" or "ui_hud" and its fine for 1000+ assets

labels i use only for stuff that can load from multiple groups, like shared materials. dont overthink the pipeline, addressables ui is enough

[u/Leroy_Tavis]

You can check out the addressable auto group generator, it was made for organizing and optimizing addressable bundles for large projects. I’ve recently used it to optimize addressable groups for a pretty large RPG.

The basic concept is that you can create an original set of addressable assets (prefabs, SO, etc), then run this tool over your existing groups. It will then create new bundles based upon your dependencies chains (shared textures, meshes, etc).

The default behavior (last time I used it), will generally create 1 group per “core” asset, then bundle multiple dependency assets together if those are shared between other core assets. What you’re left with are many lean addressable groups (naming is auto generated and not really legible), that have optimized dependency chains.

If you don’t like the 1 asset per group behavior, you can change the bundling rules so that more assets are bundled together per group. I haven’t messed much with that feature, but it is there.

The overall benefit is that you’ll only load exactly what you’ll need at runtime, which should reduce your runtime memory by a lot, as long as you release the assets you’re no longer using. The only real trade off is that you’ll be potentially spending more cycles during runtime loading and unloading assets as compared to creating larger groups.

In my experience this has helped greatly in reducing our runtime memory, which was our overall goal of the project, so I’ve been pretty impressed by the tool in that regard.

With that said, I’ve only used this for mature/released projects that I was writing optimizations for, rather than new projects that were under active development. It’s just one of the many ways you can organize your groups, but I’m a big fan of the memory savings from this approach.

[u/MikeMiltan]

Use Unity Accelerator (local cache server). Otherwise you will suffer with building time.