Official DOTS development status and next milestones – June 2022

Hi everyone!

We’re happy to share that experimental Entities 0.51 and its compatible packages are now publicly available! This completes our second milestone toward reaching an Entities 1.0 version by providing compatibility for 2021 LTS in addition to the existing support for 2020 LTS. Please find more information about this release from Matt Fuad in this forum post.

We updated our public roadmap page, where you can discover more details about the scope of Entities 1.0 and share feedback directly with the product team. We have already collected hundreds of pieces of feedback from you, which we read in detail and leverage to inform our next steps.

We are also excited to present several production stories from DOTS early adopters. Two of those were showcased at the GDC Dev Summit: Lauren Frazier from Ramen VR talking about how the team leveraged DOTS and ECS for the VR MMO Zenith, and Jonas De Maeseneer from Electric Square discussing their own experience with it for the production of Detonation Racing. The latest one is a live stream, on June 29th on the Unity Twitch channel with Fredrik Haraldsson and Rasmus Höök from Stunlock Studios to chat about DOTS in V Rising!

Finally, I recommend the session by Damian Campeanu delivered at GDC, focusing on DOTS authoring and debugging workflows, and our DOTS Q&A session with Jason Weimann at the GameDevGuild conference on May 25th.

The remainder of this forum post is very similar to the post we did on March 15, with minor updates to reflect our progress toward Entities 1.0.

DOTS roadmap
The goal of Unity’s Data-Oriented Technology Stack (DOTS) is to enable you to build more ambitious games with Unity and serve your needs in the production of complex multiplayer, crossplay, and open-world games.

DOTS includes all the packages based on the Entity-Component-System (ECS) architecture. The notion of DOTS is often extended to include the Burst compiler and C# Job System, two technologies that have been created to support the development of ECS but are independent of it. The Burst compiler and the C# Job System are already recommended for production and can be used in any Unity project, regardless of whether ECS is being used.

The APIs allowing you to implement the ECS software architecture pattern in a Unity project are delivered in the package named Entities. To obtain the benefits of the data-oriented architecture, game code and packages need to be based on Entities.

Our short-term roadmap is focused on efforts to bring the Entities package to version 1.0, bringing the package from Experimental to Released status, per the definitions of our package lifecycle. This step is critical because it means that Entities 1.0 and its compatible packages will be supported for production, like any other feature of Unity, and its APIs would remain stable for the duration of the Unity LTS cycle.

In our previous forum post, we explained that we needed to catch up with Unity LTS releases to get to 1.0. We have now reached compatibility with 2020 LTS and 2021 LTS with the availability of experimental Entities 0.51. Our next stop is to reach compatibility with 2022 Tech Stream with the version Entities 1.0 and its compatible packages, which will represent the ECS foundation supported for production moving forward. Entities 1.0 will be a breaking change from Entities 0.51. The amount of work necessary to update will vary from project to project and will be eased with detailed migration guides.

Entities 1.0: What to expect?
First of all, Entities 1.0 represents our ability to support you with ECS in production. During the experimental phase of Entities, to progress rapidly, we did not focus our resources on our testing infrastructure. We were, in a lot of cases, simply not equipped to track, reproduce and fix issues. With Entities and its compatible packages reaching version 1.0, we join the ranks of released packages, applying the quality standards and requirements for the packages to be compatible with platforms supported by Unity.

Secondly, Entities 1.0 is only a first step in overcoming some of the limitations of the Unity engine, enabling creators to build more ambitious games. Entities 1.0 is not the end of the journey; it is the beginning, and we will need a few major releases to make its benefits fully accessible in a transparent way to all Unity users. So, while we’re making a dedicated effort to bring you strong samples, documentation, templates, and other best practices guides, we will recommend Entities 1.0 specifically to seasoned game creators who have the experience of having previously shipped a Unity title.

Finally, Entities 1.0 is focused on consolidating the value we confirmed that early adopters obtained from ECS in their production, not to solve all the problems data-oriented technologies could help with. This is why Entities 1.0 is compatible with GameObjects and contains dedicated APIs and authoring workflows to efficiently bridge existing GameObject systems in Unity with ECS-based ones. This gives you massive flexibility in building games by leveraging the value of ECS for problems it is well known to solve, while still utilizing your existing Unity pipeline and expertise.

Here is the value we start delivering for production with Entities 1.0:

• Adaptive Game Architecture: Facilitates writing and using an ECS game code architecture that adapts well to constantly changing gameplay requirements
• Integrated workflows: Ensures compatibility with GameObjects through integrated Editor and baking workflows, allowing you to leverage existing Unity systems and your team’s Unity expertise
• Control and predictability: Allows you to publish demanding games to the widest range of devices by optimizing client or server runtimes for each platform’s capabilities and constraints
• Native Code Performance: Preserves the simplicity of authoring managed code, while giving you the performance of native code with parallelization and determinism
• Made for massive data streaming: Combines Unity’s render pipelines with the efficiency of ECS, so you can achieve spike-less streaming and memory-efficient large-scale rendering
• Unprecedented simulation scale: Targets a feature-rich physics library, scalable debug tools, and an accessible API to help you achieve efficient runtime and simulation at scale
• Scalable multiplayer support: Contains the high-level networking foundations supporting the production of medium to large action games using a server authoritative model

To continue grounding this vision in reality, we are preparing more production stories from DOTS early adopters to share with you this year. Those stories will reveal why those technologies were selected, what problems they aimed to solve, and the challenges that accompanied those choices.

Your feedback is important
As mentioned at the beginning, please visit the DOTS roadmap page to gain a more complete and detailed view of the scope of our next milestones.

Each card on this interactive board is clickable, giving you more details about each topic while providing you with the option to share your feedback. If you accept to use functional cookies and log in using your Unity ID, then it’s as simple as clicking a card, selecting how important the topic is to you, adding your point of view, and submitting. This feedback is directly routed to the proper product teams.

With the release of experimental Entities 0.51, a regularly updated roadmap toward Entities 1.0, frequent forum communications, and production stories from DOTS early adopters, we hope you’re excited to see those years of efforts translating to concrete deliveries. The teams behind DOTS are working very hard to bring you the solutions you need for your ambitious projects.

As usual, please let us know what you think in this thread!

Laurent

 

Thanks for this new update

The only thing I can think of is → please make early ECS 1.0 preview.xx package accessible as soon as possible so we can start bring feedback about it

 

I have some questions for dots 1.0 release
1) Since HybridComponent feature has been deprecated, will dots 1.0 release has any new hybrid solution that able to put game object into entity and able to instantiate the entity by dots addressables? So when instantiate the entity, the game object will auto instantiate together that associated with entity just like how HybridComponent does or similar.

2) Will dots addressables support putting subscene into dots addressables like game object land that put scene into adressables?

 

Sounds good. I am also down for 1.0 - even if radioactive!

 

Any chance the bugs around CopyAndReplaceEntities are on somebodies radar?

https://fogbugz.unity3d.com/default.asp?1425370_sl2paqrmfhihfo0s

(older one: https://fogbugz.unity3d.com/default.asp?1331165_hoa8tf4ctdlcj4ag)

 

If there's anything I can do to help. I would happily iterate on the test case if there's a better way to implement rollback. This is the test case I submitted. https://github.com/nykwil/EcsRollbackTest

 

My use case is to enable auto entity association with game object, game content update for both entity and game object, game object pooling by default. Currently I use addressables to achieve game content update for game object and then manually do entity association with game object. But it starts not working really well after I upgraded project to Unity 2021.3.4f1. It seems like there's bug at Unity 2021 that blocking addressesables WaitForCompletion() API that keep blocking the main thread. It's also another main reason why I need to have official support that I can make sure it will always working out of the box.

 

I see what but don't see when. Is there any broad deadline like before? i.e. 2022Q3/4

 

Is it possible to step in Entities 1.0 all the way directly from Entities 0.17? by skipping 0.50 and 0.51?

I might reconsider for an official update of 1.0 more cuz wait another 4~5 months is affordable since all the years of previews has lived through, spare me plenty of time for game creating instead of api updating.

I can tolerate any roadmap obsolete or deprecated as long as Entities 1.0 arrives as light of god in this year

 

I uploaded a implementation of the CopyAndReplaceEntities bug using 0.51. My implementation does not share any code with nykwil's implementation. CASE IN-8077.

 

Massive Thanks to you, guys, and your hard working years will definitely fructify.

 

Hi there, Gotta Love The Progress DOTS Has Made


I Have A Question though, I Can't Find Anything On The DFG Package(Data Flow Graph Package) And It Doesn't Seem To Be Compatible With The Latest Release OF Entities

I'm Using It To Create A Custom Animation Solution That's Based On The Animation Samples

So Any Kind Of Guidance Is Appreciated

 

Hi @elliotc-unity. Can u make sure these 2 issues about platform package will be fixed at dots 1.0 release? Case 1415919
1) https://issuetracker.unity3d.com/is...-minor-versions-in-0-dot-50-platforms-version
2) https://issuetracker.unity3d.com/is...tion-does-not-have-an-option-to-run-the-build

Btw I would also like to ask how much new code changes for platform 1.0 compares with platform 0.51? Is that just almost the same?

 

We were informed, there are many significant upcoming changes.
But there will be migration documentation provided.

Please checkout this vid, for more details

 

Hi everybody, continuing to share production stories for DOTS, after Ramen VR - Zenith and Electric Square - Detonation Racing at GDC, I will be Live Streaming today with Stunlock Studios to chat about how VRising (https://playvrising.com) leverages DOTS!

Editing the original post to add this information.

 

I'd also be interested in that. We're currently using an older version of Entities and it still seems to work okay'ish. We have started porting over to 0.50/0.51 - but that has been kind of nightmare'ish. If 1.0 is a significant diff from 0.50/0.51 we may actually want to wait for 1.0 (unless going via 0.50/0.51 is likely to be less painful).

 

Did you get info about animations in their project? What are they using? Is it custom or hybrid with GO? I wonder what was that as this is the biggest hole in DOTS now.

 

They use a hybrid solution. (They did not mention it on stream but I used to work there, so we've talked about it)

 

Is this likely to mean Entities builds will just work like any other build in the classic pipeline, or are you folk looking at some other mechanism? It would be brilliant if Cloud Build supported building Entities projects by just going through the “normal” Unity build process.

 

I see. If I understand correctly, do u mean the way to build dots player runtime build will become exactly the same as oop land player runtime build i.e. File - Build Settings - Build / Build And Run at dots 1.0 release? Then it comes to another question is how dots addressables work with Entities to get a working dots player runtime build? Is that the way to setup, build and then load dots addressables entity/game object/asset is just almost the same as addressables but in ECS form?

From what I know Entities.ForEach lambda at system will be simplified to another format and also some Entities API changes that I believe all can be done by auto script upgrader? Or ISystem at 0.5x release will have some new format changes that I need to fix manually? Then the only thing left I see will have big breaking change is authoring that it evolves to something called Baker. Or it will still have current MonoBehaviour Authoring backward compatibility at 0.5x release so I still can compile my dots project properly and slowly do the migration later? And also can I still using GameObjectConversionSystem to do authoring at 1.0 release?

 

Is there any post or comment on why build configs "are slated to die"?
For now I see them as really useful thing

 

Oh this is very sad news, because build configs were very amazing and allow us to automate builds for multiple platforms with a single click. And now we need to open build window, select a platform, wait for reimport, then select a folder and then click a build button? Sounds like a thousand steps back.

 

You can make a script to do that for you:

https://docs.unity3d.com/Manual/BuildPlayerPipeline.html

 

Seems like Unity should hire some people for DOTS and HDRP. Oh wait, need a few million pay rise, sorry guys.

Joking aside if this means delivering a solid product rather than a maybe-supported one then it's absolutely the right move to pull build pipeline. A shame but understandable, otherwise we'd be investing code and time into something that only has a maybe-updated tag attached to it.

 

I think we'd all like a solid product but it seemed quite forward thinking to have the build configurations. I hope they can be revisited in the future as it seemed like a faster way of working than the current non dots workflow.

 

What does all this mean for Project Tiny? Is that going ahead?

 

From the authoring workflow preview video it was clearly stated that the project is currently on hold.

They will first focus on Dots 1.0 and maybe once that is polished and production ready they will redefine what project tiny will be.

 

And raytracing and pathtracing? Will dots be compatible with that?

 

After building my prototype with ECS 0.16 and dealing with all the difficulties with different renderers (2D and Hybrid) and so, I just would like to know if I can do with ECS 1.0:

- create (thousands) lightweight entities, give them a (sprite) render component to render a 2D image/sprite way faster than with the old

GameObject

instantiation (I don't need to see the lightweight components in the Hierarchy view, but it would be nice)
- use the "new" 2D lighting system (and if necessary the 2D renderer)
- enable/disable component system easily on demand
- have easy interaction between

MonoBehaviour

components and ECS components (e.g. my Player component is a

MonoBehaviour

, the visual representation is a ECS

ComponentData

)
- easy way to create and instantiate prefabs
- use VFX and Shader Graph

If these things could be done, I'd consider to give it a try for our prototype. I tried to update it to ECS 0.51 but I got too many problems and cancelled it after 2 days then, updating the APIs and trying to figure out how things were done in the new way.

 

I see. Then I think improve Entities compatibility with Addressables first while waiting for dots addressables is better. Currently after await Addressables.InstantiateAsync("foo").Task then using Entities add component API (EntityManager.AddComponentData() / EntityManager.AddComponentObject()/
EntityCommandBuffer.AddComponent<T>() / etc) is not working properly. I will throw u error and crash at runtime player build. Currently I'm using Addressables.InstantiateAsync("foo").WaitForCompletion() is working nicely at Unity 2020.3.x LTS but not anymore at Unity 2021.3.x LTS. It's still kind of working but it stuck at loading for quite long time and then will throw u a couple of error like load dependency error at Unity 2021.3.x LTS at Android runtime player build.


Another thing I would like dots team to really consider about new process per world feature request since I believe no matter how hard to do optimization at 1.0 release it's still hardly can get the enough editor performance. I found that there's really a need at editor for Entities to make each World as independent process instead of like currently all Worlds is put inside editor process. I think it's the main reason why it's slow at editor but it's fast at actual runtime player build. I also believe that that's why burst is also move as a independent process that no longer integrate into editor process. Currently for my dots netcode production project, it's just running at 30+ fps at i7-7700HQ laptop at editor but the same project can get 60 fps at powerful desktop pc. Since dots netcode project it needs to have very demanding client world and server world, it's better to have each new individual process per world to guarantee editor performance. But still the project is mobile dots netcode project that it's not very graphics demanding that it should get 60 fps at i7-7700HQ laptop.

 

Quick search didn't show anything on if there is an entities package that works with 2022.2 beta? It looks like there won't be until 1.0 is integrated at some point?

 

No support for 2022 until 1.0.
(They mentioned the very unlikely possibility of releasing more granular versions but I think that was only meant for after 1.0)

 

You can use burst and jobs with 2022. But no entities atm.

 

Is there any ETA on when 1.0 might drop? At least the preview package?

 

Whenever happens. Maybe next quarter, or maybe next year.
I suggest do not wait specifically for 1.0. Start doing something in DOTS now, and by the time it will land, you may be up to speed with the DOTS aspects.

 

ALbeit I respect this opinion I would suggest Fabraz to wait. I started a new DOTS-Project few days ago. I just followed a tutorial and had Unity hard crash on me and later a message indicated a burst-compiler bug. So I could not proceed and gave up. I expected ECS to be a bit more "mature", stable and usable after 4+ years of development. So if you dive into it now you may be "up to speed" when 1.0 lands. But it will potentially also cause additional frustration and "useless" work to work around the current issues. Also there will be significant changes to the API and I don't know how good or bad the "upgrade" process went for people the last times a new version arrived.

So some people are doing great stuff with ECS already (Latios Framework, Games). So it is doable. But if you are just an "average" user don't expect a smooth sailing. It has a reason UT is making it so hard to install ECS at all. So if you want to try ECS for research, learning or experimenting: go for it. If you want to build an actual game/work even UT advises against this at ECS is not sufficient for production right now. And with all the stuff still missing even 1.0 will probably leave much to be desired. So choose wisely and consider what you want to achieve and what you expect.

 

I got your points.

Yet this don't make sense to get with latest Unity feature version, as there is little of resources online.
For new starters, it would be easier to get grasp about basics in "older" entities 0.17, or 0.51, where there is quite a bunch of materials online, forum posts, docs, users articles and vids.

Unless user is able to understand DOTS source code. But then, none version of DOTS would be an issue for such user.

Either way, Unity resources are up to date, to allow learn anytime (some official examples)
https://github.com/Unity-Technologies/EntityComponentSystemSamples

The question is, is person ok to wait indefinitely, before starting to learn DOTS, until entities 1.0 is released?
In the end, it is up to the user when want to start learning new feature (released / or preview), in this case DOTS.
Unity discussed, they will present upgrade docs to entities 1.0, as they did for 0.50 / 0.51. So that gives user an opportunity to auto upgrade they project later, if they start today.

 

Are there any plans to add names to Archetype?
Would be nice to see names of archetypes in DOTS/Archetype menu.



Screenshot as of Entities 0.51

 

I'm curious how you think this would work?

 

It is an interesting question.
However, since we can set names to entities, we could have similar mechanics, to name archetypes.

I suppose, as I think more about it, problem and complexity become more trouble some, when adding and removing components at the runtime.

Perhaps we could have some definitions of archetypes with a name, which editor will use that name, when existing archetype is matching.

Just brainstorming aloud.

 

I think a more practical solution might be to be able to select an archetype from the DOTS hierarchy or the inspector.

 

both ideas sound good to me

 

Here's a thought. Instead of naming very specific archetypes where an archetype fully describes the entities that would be lumped together in a chunk, have archetypes as "named queries" in systems. Once a system registers a query for an archetype, it could describe that archetype with a name. That then opens up the possibility of selecting an archetype from the DOTS hierarchy or having multiple systems register the archetype they operate on by name instead of redefining it. It opens up a door for abuse and confusion, but I can see how it could be useful from a debugging point of view.

Further flavour could then be to list the archetype names next to an entity, similar to how an entity might be "tagged" with various tags, but ultimately giving a developer the ability to quickly reason about the different archetypes an entity might conform to.

 

Yeah, this was my very primary thought, how it could work.