I would like to know does official still plans to support classic game object at runtime for real game production? Real game production means the game art assets needs to strip from player runtime build and able to download and update on demand. I heard that DOTS Addressables is not planning to support classic game object instantiate. Does it means I still need to maintain both DOTS Addressables and Addressables for dots project which extremely difficult to maintain it. I hope official can solve this use case since I believe it’s very common use case for real game production.
1 Like
If by classic you mean OOP mono behaviour ang Game Objects, then they will not change.
1 Like
Currently what I want is make DOTS Addressables able to support instantiate classic game object at runtime so I dun need to maintain both DOTS Addressables and Addressables.
1 Like
No one know yet how it will be implemented in the end, but I’m pretty sure it wouldn’t be two separate things in it’s core, I believe you will need to have regular Addressables packages always as it’s core of whole pipeline, and for DOTS stuff just additional package which will extend regular Addressables and extend bundles packing pipeline and API for working with entities stuff, but core Addressables will still there as it will be foundation.
1 Like
A dev name dropped “ContentArchive” here: Link
Eizenhorn already asked the same question I wanted to ask because I’m also under the impression it could be related to DOTS Addressables. With the removal of Runtime conversion, Addressables got quite problematic in 1.0. So much so that I don’t believe that Addressables as we know them will ever be DOTS compatible.
Some info on it would be very nice! 
1 Like
There are some fundamental differences in how addressables will work for dots:
- It is not a separate package, it is the default content management system for DOTS projects
- there is no global list of assets that will be built, every reference is collected during the build. The roots of these references is the set of scenes included in the build. This means that if you build with different sets of scenes, the addressable assets will change.
- assets are built during the player build, not as a separate process.
- there are separate workflows and APIs for local content and content delivery. The runtime loading API is concerned only with local data. The delivery API is concerned only with content delivery. It is the responsibility of the developer to use the delivery API to ensure that the correct content is on the device before trying to load with the runtime API. This was done to give more control over the delivery process.
- content archives will replace asset bundles. Unity engine objects that are needed by entity scenes as well as any that are referenced by baked component data. More information about this interface can be found here: https://docs.unity3d.com/2022.2/Documentation/ScriptReference/Unity.Loading.ContentLoadInterface.html
- The content delivery system has a new caching system that is file type agnostic (in order to support content archives as well as entity binary data)
There are concepts that do carry over:
- WeakObjectReference this type is similar in functionality to WeakAssetReference in that it provides UI for dealing with references and an API to load & release objects.
- Objects can still be loaded from monobehaviors, though there must be a reference to them from DOTS serialized data in order for the build to discover them.
- The API is much simpler than Addressables, but it follows the same “load, check state, get value, release” paradigm and internally ref counts objects and dependencies to efficiently manage memory
I’m glossing over a lot of the details here but the plan is to provide more in depth user guides and samples.
9 Likes
Thanks for detail reply. I still have questions want to ask.
-
If I understand correctly, I still need to use Addressbles to support instantiate classic game object or there is workaround that seems like there’s hybrid component/companion game object solution that able to bake classic game object into dots addressables to enable hybrid workflow? But I need to have classic game object pooling by default for performance reason.
-
Do I still need to Addressables if I want to support classic scene?
-
What’s the ETA of dots addressable preview release?
Unity is working on an actual replacement to asset bundles? This is the first I’m hearing about it.
Dots addressables can load classic game objects from content archives but you will need to provide the pooling functionality as it does not handle instantiation. You would need to create a subscene that references any of these objects in order for them to get discovered during the build.
Classic addressables should probably not be used for dots projects - you would end up with duplicated data and 2 separate content loading, delivery and caching systems
I’m not sure if the DOTS preview release date has been made public. I’ll try to find out.
3 Likes
For now, content archives are only used in dots projects. We may transition to them in the future for all projects but I don’t have any details or timelines for that.
How do they work with assets like shaders, meshes, textures, etc?
Awesome. Is that very straightforward api like DotsAddressables.InstantiateGameObjectAsync method with guid?
If Dots addressables able to support classic game object then I guess no need class addressables anymore. But does Dots addressables still able to support load classic scene?
About the scene u mention are u refer to subscene? Btw does Dots addressables been battle tested build speed for large project that significantly faster than classic addressables?
@PaulBurslem How much is DOTS Addressables tied to Entities and, specifically, subscenes? I’d imagine there’ll be at least a lower level API exposed that deals independently with BlobAssets and other forms of serialized data that don’t depend on the use of subscenes at all.
I’d hope whatever integration got shipped, we’d have an API that went “Here’s a bunch of BlobAssets and some more info, package them up, thankyouverymuch” and/or similar variations.
Some context about why this matters to me (if you’d like more context on my use cases, I’d be happy to provide through private channels):
Just a disclaimer, I think Unity ECS is pretty great. It’s just limited in some aspects when it comes to networked games workflows as well as potentially too complex for other genres or games. I have implemented a fighting game rollback engine with Unity ECS (Entities 0.17) before swapping that entirely to a simpler solution that uses Burst+Jobs but no ECS. The ECS one worked okay-ish, but the new thing was just a lot simpler and got me the control I needed to achieve all the workflow stuff required.
I also am using TextAssets and BlobAssets with the old Addressable system to get around the fact that this isn’t out. If it won’t have any APIs that allow me to code a tool to package blobs myself or if it relies on sub-scenes, I need to know so that I can plan the time to improve my own custom tooling around my current system built with old Addressables.
Regardless, if major features of DOTS continue to be tied to Entities, I feel Unity’s original claim of DOTS being more than just Entities should probably be revised and clarified. Maybe I misinterpreted it as “core functionality would be mostly depend on Burst+Jobs with all the entities stuff built on top of them”. It’s okay by me if that is no longer the case or if I misinterpreted it. So long as Burst/Jobs/Collections remain independent, I’m happy. But, as its stands, with some packages being designed like this and others not (com.unity.logging seems to not depend directly on Entities) — it’s hard to know which things I would have to build in-house and which I can count on Unity to provide if I’m not on onboard the Entities train for a particular project.
Maybe call the Entities independent packages DOTS “Package Name” and the dependent ones Entities/ECS “Package Name” 