Looking for users very familiar with the addressables or AssetBundle technology to help shape the content pipeline!
We’re consistently working on these products and on the upcoming content directories. To ensure our solutions align with real-world needs, we want to actively involve those who push our current setup to its limits in our process.
If you maintain a large library, have built your own workaround for organizing things, or just have strong opinions about what’s broken today, we’d like to hear from you.
What we’re asking for:
- Opinions on what we’re building directly via a private Unity group space.
What you get:
- Direct influence on the future of Unity’s content pipeline and what we prioritise
- Early access to see what we’re building
If you’re interested, please fill out this form and we’ll be in touch.
my opinion is that addressables and assetBundles in current form dont deserve improvements. They deserves obsoletion and annihilation in favor of ContentDirectories
Delete the older and make the new one as flexible as possible. If people needs different solution, they usually have really specific requirements and they have the skills and knowledge to implements them.
Addressable is really bad. Each time I tried to implements it, I always end up having to do some sort of generic handling of all asset because artist are unable to respect correctly bundle logic. This is such a pain point that even when the teams I am working with have needs of better asset management for loading and memory they always prefer not to implement it.
Also, it is really a turnoff to have to switch everything to addressable whenever we only want to use for a small portion of the game.
make everything to be ContentDirectory in Unity7
Thus making it the only Universal solution in unity and we never ever end up in situation when something work in simple build but dont work from AssetBundles.
May be even in editor use ContentDirectory to load assets from AssetDatabase. Like make AssetDatabase to be actually ContentDirectory. Thus work with it on every step so it become very strong very fast.
one Builtin content directory - it get sources from scene list, all Resources folders and some builtin assets. this one registered automatically before first scene load because even first scene will be inside of it. Some built in SO store dict with connections of every scene name and asset name from Resources to Loadable’s . This way SceneManager and Resources Api can work on names as always.
And developers additionally create main game ContentDirectory that pack additional assets on top of builtin one into second content directory. This developers register manually.
same on top of mechanism can be used to build more than one ContentDirectory where second know content of first one and can load assets from it e.g. DLC (Current Version unable to do this)
This way going from Resources to ContetnDirectories will be as smooth as possible for developers and actually move to ContentDirectories only part of project will work without issues
Ok so firstly, I know JesOb is on the list, but simonrobidas please join the above list if you haven’t already (you too Thaina!). Would love to hear more from all of you!
You’re both saying something along the same lines, so apologies for replying together.
Content directories is exactly what you’re talking about Simon. It is effectively an (efficient) build system that accepts ScriptableObjects, and then spits out a ton of highly granular artifacts that you can individually load and unload. It’s super simple, super flexible, without all of the constraints of AssetBundles which really bleed into the design of Addressables. There is no “bundle logic” or colocation of assets - it just works.
I’ve been writing a blog post which will dive more into the technical design of content directories, and how it will be expanded to fulfil the full AssetBundle use case, which should help shed some light on what we’re delivering now, and where we’re headed in 2027.
Beyond that, we have big ambitions for other parts of the Unity tech stack that can/will switch over to content directories, but if I go too far into the future roadmap I’ll get in trouble!
That was not an issue, because addressable really is async. You cannot know when it will finished and async pattern is the official C# protocol for this kind of job
And instead what we actually need is async everywhere
in favor of ContentDirectories