Official DOTS development status and next milestones – September 2022

Hi everybody, here is our Q3 update for the DOTS roadmap!

DOTS Recap
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.

ECS for Unity 2022.2 beta is available!
We’re happy to share that experimental Entities 1.0 and its compatible packages are now publicly available! This is a preparation step ahead of the pre-release version of Entities 1.0 and its compatible packages with Unity 2022.2 Tech Stream. Experimental Entities 1.0 is compatible with Unity 2022.2 beta. Please find more information about this release from Matt Fuad in this forum post. If you are unfamiliar with DOTS and ECS, I recommend this Q&A with Jason Weimann.

We are also excited to continue to present new production stories from ECS early adopters, to make the technology grounded in real use cases, and help you understand what it can enable for your game productions. So far this year we’ve had:

• Ramen VR - Zenith: The Last City (March 2022): CTO Lauren Frazier explains how ECS helped them scale up their gameplay for managing a VR MMO game architecture.
• Electric Square - Detonation Racing (March 2022): Lead Developer Jonas De Maeseneer covers the use of ECS for deterministic gameplay for QA and design loops, as well as streaming for a high-pace Apple Arcade racing game.
• Stunlock Studios - V Rising (June 2022): In a 3h-long Twitch stream, lead developers Rasmus Höök and Fredrik Haraldsson presented their use of ECS, from world building in the editor with custom visual scripting, to scalable open-world streaming.
• Kasedo Games - IXION (August 2022): Technical Director Jérémy Guéry walks us through how ECS has powered heavy NPC simulation for their city builder in space.

Entities 1.0 introduces a number of exciting new capabilities, resulting in a variety of breaking changes from Entities 0.5x versions. Our goal in releasing this experimental version ahead of the full pre-release is to gather additional feedback from you and use this as an opportunity to adjust our deliverables.

Here is a highlight of the important changes we hope to get feedback for, you can read more details about those in @jivalenzuela's forum post for framework changes and @arnaud-carre's forum post for Entities Graphics:

• Editor data modes: a brand new paradigm for working, in place, with data that has wildly different representations at authoring time and at runtime.
• Non-destructive editing of subscenes while in Play mode: allows you to make permanent changes to your game while playing, and in a safe manner.
• New Journaling window: lets you record and explore ECS events directly from the Editor, allowing you to follow every single transformation a specific entity went through without requiring any complicated debugging setup.
• Conversion becomes Baking: those APIs have been improved to simplify the use of GameObject-based data for ECS-based gameplay.
• Build Configs workflow consolidation: we used to have a separate build config process we have merged into the main Unity workflow.
• New Transforms: we are introducing breaking changes for transform management to make the set of APIs simpler, and better suited for more use cases.
• Simpler ForEach: continuously simplifying the experience of writing gameplay code for ECS, this directly reduces boilerplate code for entities looping, and nested loops.
• Easier gameplay code with Aspects: this new concept makes it easier to build gameplay code with ECS, by removing a lot of the boilerplate code usually required.
• Reduce the number of Archetypes with enable-able components: provides a first-class way to balance efficient component data design and system strategies.
• Increase Burst coverage of your code: ISystem and IJobEntity usage has been expanded to decrease the impact of managed code in systems and jobs.
• Hybrid Renderer becomes Entities Graphics: this was renamed to reduce confusion about the meaning of this package, refactoring is not expected beyond some class renaming.

While we hope to get feedback from you on those topics, please be aware this experimental release will differ from the pre-release in several ways, which means the scope is not yet complete. Here are the highlights of what we expect to be different between experimental Entities 1.0, and the pre-release Entities 1.0:

• Documentation is not fully complete: while we believe we have decent coverage of API documentation, more guides and manuals, as well as samples will be made available with the pre-release.
• Entities Graphics gap with WebGL: Entities Graphics is looking forward to WebGPU platform support to leverage compute shaders. However, we recognize many of you will need to support WebGL for a long time. We expect to share, alongside the pre-release, clarity on how to bridge ECS gameplay with the existing GameObject render pipeline to WebGL.
• Deprecated features to be removed: while we plan to remove a few features in the pre-release, those are still available in the experimental Entities 1.0 for allowing you to compare: old transform system, runtime conversion, TransformUsageFlags.
• Addressables scalability gap: we miss the Content Manager and Content Delivery systems in the experimental Entities 1.0 meant to use Addressables with ECS gameplay at scale. Those were late for this deliverable and are still expected for the pre-release.
• Unity Physics Motor Fixes: Motors max impulse parameters have not been implemented resulting in some behavior instabilities. Additionally, GameObjects motors components cannot be baked. We expect these issues to be resolved for the pre-release.
• Havok Physics for Unity to land directly with the pre-release: we made some adjustments to the pricing of Havok Physics for Unity that required a few changes. We chose to land all of it properly directly with the pre-release and skip the beta phase. More details on pricing here.

Acquisition of Rival, the powerful ECS-based character controller
To get you started as fast as possible, Unity has acquired Rival, a powerful ECS-based character controller, which has been built for extensibility & performance with networking in mind. Its creator @philsa-unity has joined the Unity team, welcome Philippe!

While Rival is still an asset on the Asset Store at the moment, we will follow up in the near future with a dedicated communication and update of our plans to make this character controller well integrated into our package ecosystem.

ECS for Unity 2022, what to expect?
Moving forward, we will reduce the emphasis on individual package versions and simply talk about ECS for Unity 2022. It represents a first step in overcoming some of the limitations of the Unity engine, enabling creators to build more ambitious games. ECS for Unity 2022 will receive the same level of support for production on all platforms as any other released feature of Unity engine.

Using ECS introduces additional complexity that can be unnecessary to your project. This is why ECS for Unity 2022 particularly brings value to seasoned Unity creators who have the experience of previously shipped Unity titles and understand the limits of the GameObject and MonoBehaviors architecture they are trying to overcome. This is for us the beginning of a journey that will eventually bring the value of data-oriented design transparently to all users through familiar workflows.

ECS has been used during its experimental phase by studios of all sizes, across genres, who successfully shipped titles on most of the platforms Unity supports including desktop, mobile, consoles, or VR headsets. Their common point was ambitious gameplay on demanding devices that push the limits of Unity engine. They regularly reported the following benefits that we will try to validate at scale for productions based on Unity 2022:

• ECS for Unity is best as an optional framework compatible with the GameObject ecosystem: ECS for Unity offers streamlined workflows and a familiar authoring experience in the Unity editor, compatible with existing GameObject ecosystems. You can leverage your existing Unity expertise and assets to focus on the creation of ambitious games.
• Game code based on an ECS architecture can quickly adapt to major gameplay changes: Game code based on an ECS architecture pattern can avoid the drawbacks of object-oriented programming with GameObjects. Development teams can very quickly absorb important gameplay changes by eliminating most of the refactoring that would have been necessary with object-oriented architectures.
• Game code based on ECS provides an unprecedented and extensible level of control and determinism: Unity engine is very approachable thanks to C# scripting, MonoBehaviour, and object-oriented GameObjects. This comes at the cost of limited memory control and unpredictable execution at runtime. ECS for Unity provides memory control and determinism by design. This creates optimization opportunities at scale, and new game code possibilities based on determinism. ECS for Unity is a C# package distributed with source code, allowing you to explore, debug and extend it!
• Game code based on ECS, Burst, and the Job System best leverage the hardware resources: with game code based on an ECS architecture, development teams can maximize the use of the target platform hardware resources, at the memory and CPU level, with a maximized use of Burst and Jobs.
• ECS for Unity enables spikeless streaming and memory-efficient large-scale rendering: ECS for Unity offers an efficient data pipeline that enables streaming and rendering of complex, large-scale game experiences, fitting the memory and processing constraints of low-end to high-end devices. You can leverage ECS performance and scalability boost in coordination with Unity’s asset pipeline data, and render it using SRP, including URP and HDRP.
• ECS for Unity provides deterministic large-scale simulation and powers Havok Physics for Unity: Simulation code based on an ECS architecture pattern can scale to an unprecedented amount of entities, and ensure determinism. ECS for Unity provides a robust out-of-the-box ECS-based physic engine with a versatile character controller. For complex productions needing a AAA production-proven physics engine, ECS for Unity powers the availability of Havok Physics for Unity.
• ECS for Unity is made to support the creation of ambitious multiplayer games: ECS for Unity provides many benefits allowing to turn any project into an ambitious multiplayer game. When using ECS over GameObjects, you can synchronize more data over the network, support more players, build games highly reliant on rollback and determinism, reduce development risk and decrease iteration time. ECS for Unity comes with a server-authoritative netcode library.

Roadmap
The teams working on data-oriented solutions aim at enabling creators to build more ambitious games with Unity. With the releases of Burst, Jobs, and now ECS, we have landed a series of foundations in that direction. Here are the next steps we are considering moving forward in order of priority:

1. Foundation Consolidation: while we obtained a lot of feedback already for ECS during its experimental phase, we expect to see a wide range of new use cases emerge from the use of ECS in Unity 2022. This is why our short-term focus will be to observe how you use such technologies and seek for immediate opportunities to smooth out the overall workflow.
2. Cross-play multiplayer game creation: there are a number of remaining gaps to guarantee efficient out-of-the-box support for many genres of multiplayer games. Those gaps can be about determinism for Burst across CPU architecture, ECS-based animation, and more.
3. Open-world game creation: there are a number of remaining gaps to provide proper open-world support in Unity. This is about world creation, terrain LODs and streaming, the use of ECS in the editor, large-scale transformation systems, and more.

Your feedback is important
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.

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 a release every quarter in 2022, a regularly updated roadmap, frequent forum communications, and production stories from ECS early adopters, we hope you’re excited to see those years of effort translating to concrete deliveries. The teams behind data-oriented technologies 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

 

Pretty cool.

There's even 1.0 manual already available:
https://docs.unity3d.com/Packages/com.unity.entities@1.0/manual/index.html

There are some weird inconsistencies in the manual, like .ForEach is being deprecated in ISystems, and at the same time - starter manual suggesting .ForEach via SystemBase. Kinda counterproductive to teach things which should not be used. Perhaps new Query API should be suggested instead, but, maybe its not available for SystemBase so idk. Need to see what's actually going on.


One important thing though, please make Baker / subscenes feature Unity Cloud Build supported.
This was a major blocker to even try to use subscenes in previous versions, since they're not being built properly.

Hopefully, with platforms package gone this should be supported via default build pipeline.

 

Hello, I get that command buffers are now accessed through singleton entities but what are all the "systems" entities we se in the hierarchy in play mode ??

 

The entity preview is a downgrade from the entity inspector in my opinion :
1) I have to select a component to see it's value
2) I can't view 2 components values at the same time
3) thre is no way to distinguish betwen data compoent, tag component and buffer components
4) I can't filter the components

New :



Old :



EDIT : the inspector is still available but you have to go through the system's entity query to get to it. Selecting the entity in the entity hierarchy does not open the entity inspector.

EDIT 2 : The entity inspecor is now editable but values are not set to the GameObject and reverted once you exit the field.

 

Just click on this circle

 

Thanks

 

No I have not added anything to the systems.

 

Good move. I probably was the only one really shouting about how cool IJobEntity is. It is simple, and offers all the performance of manual chunk stuff without the swathe of boilerplate. Getting rid of the others will consolidate written code in general (asset store, community, progression etc).

At least I didn't run into any limitations (much - there are a few little oddities but I've yet to ride experimental 1.0 so I'll not comment on those).

 

Excited to see this release!

Can we get an update regarding LOD crossfade? The feature matrix in the docs seems outdated.

 

Is there no more script templates or am I missing anything ? I made my own cause I could not find it anymore but It would be good to have at least one for Authring component (monobehaviour + baker), one for ISystem and maybe one for aspect and runtime component?

 

To clean up the view a bit you can select the ConvertedScene in the world dropdown

 

The `Upgrading to Experimental ECS for 2022.2 Beta` card in the roadmap has the wrong link: https://docs.hq.unity3d.com/Packages/com.unity.entities@1.0/manual/upgrade-guide.html instead of https://docs.unity3d.com/Packages/com.unity.entities@1.0/manual/upgrade-guide.html (notice the missing "hq" after the "docs")

 

No. Please dun hide internal system entities in UI as it violates data transparency. What u should do is provide folder grouping at Entities Hierarchy window just like how Systems window works so u fold and unfold easily. But yeah seems like all systems are become singleton by default. I guess can hide all of the systems that has only System Instance component but if there's other component the systems should not hide so developer can inspect all the data for the particular system easily and able to search for that component by typing c:xxx.

On top of it, this grouping feature can further expand it to group entities at subscene. For this I think can provide both folder grouping and inverted triangle grouping to serve different use cases. For example, inverted triangle grouping can use it to grouping multiple entities as a character but currently u need to use Transform related system component to achieve similar feature which greatly impacts player runtime performance for nothing just only for grouping purpose. It's just convenient grouping feature for dots developer and it totally doesn't affect player runtime build.

Spoiler

 

>Unity Pro – New and existing plans will include Unity Mars, as well as Havok Physics for Unity with the release of Unity 2022.2 this fall.
Hah, after ecs 1.0 havok will it be fully paid?

 

Please consider making simple tool that can sort filter and group(subgroup) entities based on anything. Not only some hardcoded hide builtins. and ability to save user grouping and filtering options for fast access

 

1) Seems like Entities Hierarchy window just missing the capability to toggle on/off subscene to open/close so I can no longer need to use Hierarchy window anymore. Will this annoying issue be addressed very soon?

2) Currently Entities Hierarchy window still not able to search and display namespace prefix properly yet but inspector can display it properly

Spoiler

Spoiler

Spoiler

Code (csharp):

1.  
2. class Cube
3. {
4.     public struct MovableCubeComponent : IComponentData { }
5. }
6.  

 

I see that you're changing how you're doing Transforms, and that it's still in development before the 1.0 release. In that case, might I make a suggestion before it's too late?

My suggestions:
- renaming

LocalToWorldTransform

to

Transform

or

WorldTransform

.
- renaming

LocalToParentTransform

to

LocalTransform

.
- renaming

ParentToWorldTransform

to

ParentTransform

.

As descriptive and systematically accurate as the name

LocalToWorldTransform

is, I feel it's actually more confusing a name than

Transform

or

WorldTransform

, similar to my other suggestions. That's a problem when people are trying to understand code at a glance. Giving the names distinct patterns I feel alleviates that.

 

The current names describe the space transformation the structs provide, I don't see where confusion comes in. Your suggested names remove information and can in turn be confusing themselves.

"WorldTransform" - Assume it's [from local space to] world space? How do we know what space we're coming from?
"LocalTransform?" - Local space [to parent space]? The name describes nothing about a relationship to the parent, and again how do we know we're talking transformation to parent space? Local space is already a thing, we could totally say that a "LocalTransform" is an identity transformation of a vector into the object's local space.
And "ParentTransform" is parent space [to world space]? Why is this suddenly relative to world space when "LocalTransform" isn't?

Bigger issue is that terminology here can be offputting to people coming from backgrounds where what Entities calls "local" is "object" space, and "parent" is what's called "local" space, though I'm in favor of the terms used by Entities purely because of things like the Transform component's localPosition / localRotation being there for ages (... edit: gave it more thought, and never mind, those values do actually refer to the "local" (relative to parent) location of the object yet there's the property localToWorldMatrix which gives a different meaning to "local" (relative to object), so I suppose just saying "local" and "parent" in Entities is clear enough).

 

Good news, Worth looking forward to!

 

Hi. I appreciate the decision to let users disable the automatic bootstrapping process. However, I wonder if you could provide an example of how to programmatically compose and update a World? I'm one of those people who like to compose a world manually and update its systems in whichever order we find fit without involving any of the system ordering attributes.

 

The API you are looking for is ICustomBootstrap. Explicit system ordering has been a feature of my framework for a long time now. And while I am still in the process of migrating to the new release, I've already verified this feature. If you want to know more, start a different thread and mention me.

 

Thanks. I will look into it. Btw, I've been keeping an eye for Latios for a while.

 

Will Havok be available to purchase on its own?

 

The issue I am having with ICustomBootstrap and the new ISystem: When any EntityCommandBufferSystem is added to both Worlds, then SystemAPI.GetSingleton<Any Entity CommandBufferSystem.Singleton>() fails in both worlds: default world because it contains two Singletons, and World2 contains zero. See screenshot here. Do you have any idea what is going on or do you not have that issue?

 

I haven't experimented with that use case yet. If I do get around to it and learn something, I will get back to you, assuming I remember (I won't ).

 

Does 1.0 support terrain yet?? If no, will there be a dedicated dots terrain?? What about the other world building tools like splines?

 

UPDATED
Appreciate your help! And this might be a silly follow up question: what is the API for doing that; how would I modify the following (which leads to 1 ECB system per world, but 2 ECB singletons in Default World and 0 AnotherWorld) ?

Code (CSharp):

1.         List<Type> anotherWorldSystems = new List<Type>();
2.         anotherWorldSystems.Add(typeof(BeginSimulationEntityCommandBufferSystem));
3.         DefaultWorldInitialization.AddSystemsToRootLevelSystemGroups(anotherWorld, anotherWorldSystems);
4.         ScriptBehaviourUpdateOrder.AppendWorldToCurrentPlayerLoop(anotherWorld);

Edit:
Never mind. Turns out it was a stupid mistake on my end after all. This innocuous little line moved ALL entities from "anotherWorld" (which I use as a loading/staging World) to the Default World, INLCUDING the ECB singleton.

Code (CSharp):

1. _entityManager.MoveEntitiesFrom(anotherWorldEntityManager);

Which of course leads to a duplication of the ECB Singleton in the Default world, and 0 Singletons in "anotherWorld"

 

What does this mean for those that have only Unity Plus?
Havok vs Unity physics is kind of important decision because it's a question of Stateless vs Stateful physics.

And how I read it now is, if you want stateful physics in DOTS you need Unity Pro+. That's hm. I reserve any kind of opinion unless I know more.

edit:
Was just asking - I should have researched a bit.
So Havok DOTS physics is free for Unity Free/Plus. Pro is needed for consoles and then Havok is also included. So, seems cool all in all.

 

FYI: I'm a Plus subscriber and I'm planning to make use of Havok physics. I really hope you aren't planning removing it from the Plus subscription package.

 

I guess I'll voice my displeasure the current decision. Its extremely disappointing to see it disappear from the free/plus tier. Being able to stack rigidbodies and have a useful visual debugger feel like pretty basic things that Unity Physics just doesn't provide in its current state.

 

As I understand it, havok is free for Free/Plus, but without a license, with >= Pro with a license

However, some statements from Unity stuf are a bit contradictory here, so everything is a bit unclear.

 

The URLs to "Ramen VR - Zenith: The Last City " and "Electric Square - Detonation Racing " are the same

 

Aahhh...thanks. Appreciate the response.

 

When can we expect the dots animation update?

 

Some time after 1.0 is released. Safest to assume is few months to few years after Entitiesb1.0.

DOTS team possibly didn't event touched it yet, since core DOTS Entities 1.0 is not ready yet.

So unill then, your best bet is to create your own, or use existing frameworks.

 

I think currently Live Baking options is hidden at public Entities release. At time of writing the latest 1.0.0-exp.12 still dun have that option. I would like u to make sure that the next entities release will expose Live Baking options. Another request is please move Clear Entities Cache button back to menu instead of at Preferences widow since currently I need to use it very frequently. The current Entities release is not stable and I always get Entity header error.

 

Yeah it's hidden for some reason or by accident. If you go to the unity about window, type internal.
Go back to preferences and the option will have appeared.

 

Can u try to push dots addressables feature available at Entities experimental release instead of waiting until pre-release? I think it's really important to test this essential feature as early as possible to make sure there is no critical bug before entering pre-release stage.