For me current Addressanles form is very far from production usable 
Not Universally usable from protortype to production
Small project or prototypes where they just big overkill to support, but if I dont use them then when project grows there will be big pain to move to Addresables from resources.
To fix that, idea Of AssetReference must be separated out of Addresables package. May be new Unity UnityObjectRef< T > and RuntimeContentManager will solve that when ECSForAll comes to unity core.
.
Deduplication
RaventurnPatrick wrote correctly I can add only that having those groups and manual setup of all assets and custom paths for them is bad design in first place
Thats why we have so many automatisation tools on store to create groups based on rules rather manually. Groups must be set of rules instead of set of final asset references. Rules like: add all prefabs from folder X; add those few direct links; and so on. It must be easy to add project specific rules.
And yes after gathering all assets based on rules run explicit deduplication step as RaventurnPatrick mentioned.
.
Separation of Concerns and Explicit Control
- Asset building
- Asset uploading
- Asset downloading
- Asset mounting to runtime FAT (Bundles mouting)
- Asset Loading and Unloading into RAM (must )
Thay all different things and must be implemented independently as separate easy to reason about maangers that can be customized or replaced by user code for project needs. Each must be simple abstract class or interface with very few methods
Also nothing must be automatic like start download 5 Gig bundle because some script request material from it. Those things must be explicitly controllable and auto load only if I with that behavior otherwise error or just return null.
After Bundles downloaded and mounted to system any asset from them must be easily loadable synchronously without any issues or deadlocks.
.
Contextual Asset Load/Unload
Current addresable dont unload assets at all (becase unloading happend only when bundle unloads from memory) and even when unload happens it unload only assets loaded from exact unloaded bundle.
If asset A from bundle bA has dependency on asset B from bundle bB and asset B 100MB in size than unloading asset A will not unload asset B automatically. it will be unloaded only when entire bundle bB will be unloaded.
This way we can say that entire asset referencing thing of Addressables dont work in many cases in practice.
What we need is ContextualLoading like
New loaded scene create LoadContext and all assets loaded for that scene with scene file and dynamic ones will be unloaded when scene itself and created LoadContext will be unloaded. All assets and their dependencies. So if I load prefab that reference material that reference textures than unloading LoadContext must unload all materials and textures of prefab regardless of bundles they coming from.
.
Deterministic Asset References and Overrides
Runtime system must use deterministic asset references like AssetDatabase do
so if Asset has guid xxx and internal id yyy, system must be able to load it from any bundle regardless how it was build, even If I build small new bundle with only one asset xxx[yyy] and mount it to RuntimFAT than all assets from other bundles must see it like it work in editor
No any hardcoded paths or unique asset ids based on asset content or build version. This is exactly going against what we need in practice. We need to create new bundle with new version of my texture (christmas texture) without need to rebuild any other bundle. Just download that new bundle and mount to runtimeFAT so all loaded prefabs will use my new christnass texture because they just load asset xxx[yyy] and dont care where it come from.
Important notice is that mounting that new Christmus Bundle must override xxx[yyy] asset in runtime Fat from old bundle to new one. So new RuntimeFAT record must say they asset with key xxx[yyy] now must be loaded from ChristmassBundle[InternalBundleAddress] so all new load operations that try to load xxx[yyy] as dependency will load it from new place.
I argue that such system must use Editor asset Address directly in runtime
guid[inernalId] => 9c8d7e6f5a4b3c2d1e0f1234567890ab[9284517365129837461]
than in any time we can figure out what was wrong because we have same asset address in editor
.
Use asset bundles in Editor directly
Make it able to mount bundle into editor AssetDatabase so we can see all assets in it as readonly assets (same as assets from packages) and compose new assets and levels using them.
This is very useful for very big projects divided into pieces and also very handy for mod creation because modders can mount original game bundles to editor and create new content based on them easily. This is already possible with some ugly workflow. having streamlined one will be huge win for Unity and for Us.
.
Independent bundle building
Deterministic Asset References and Overrides will naturally allow use to build any bundle separately without building entire project and allow build small overrides for any part of project for hot updates and for mod support
We must be able to say that we dont need to collect dependencies automatically inside SBP we collect them beforehand and build only what asked to build. For Example we can use already builded bundles end remove all assets that already in them when building new ones. This way we can easily build DLCs or Mods that use content already shipped with game
Also there must be Api to correctly collect dependencies because for some reason SPB use different method to collect dependencies, not what we have in AssetDatabase Api
.
Scriptable Build Pipeline documentation
Write good documentation for Scriptable Build Pipeline package
We need to to be able to create our own customized vertions Asset building steps
