DOTS development status and milestones + ECS for all (September 2024)

DOTS development status / milestones + ECS for all – September 2024


Hello, all – the DOTS team is here to share our next roadmap update!


:sparkles: What is DOTS?

Unity’s Data-Oriented Tech Stack (DOTS) is a combination of technologies that work together to deliver a data-oriented approach to coding. Our goal with DOTS is to empower creators to build more ambitious games with Unity and serve their needs in the production of complex multiplayer, crossplay, and open-world games.

DOTS consists of several packages based on the Entity Component System (ECS) architecture. It also includes the Burst compiler and the C# Job System, which can be used in any Unity project regardless of whether ECS is being used.

In June 2023, we celebrated the Entities package officially entering Released status with Entities 1.0, ensuring support for production on projects using the 2022 LTS. More recently this September, we released Entities 1.3, compatible with the 2022 LTS.

If you’re looking to get started with DOTS (or just need a refresher), we recommend trying our latest Unity Learn tutorial, Basics of DOTS: Jobs and Entities. Over on the Unity Blog, you can also find a comprehensive list of DOTS tutorials, sample projects, studio case studies, and more community resources. We’ve also released even more learning content that we’ll share more about later in this post.


:tada: Updates from Unite 2024

Amongst the many exciting updates we’ve been announcing today at Unite 2024, we shared more details about our efforts to provide the benefits of ECS for all Unity creators. This work to consolidate Entities and GameObject workflows will be arriving in the next Unity generational release after Unity 6.

Many of you here are well familiar with the advantages of ECS and how it can help you create large-scale and performant games. However, many Unity creators have been unable to enjoy these benefits due to the advanced nature of ECS. To provide these benefits to all Unity users, we are building ECS into the core of the Unity editor by having every GameObject be backed by an Entity. For those that want to use ECS, creating game code will be as simple as writing Systems and Components, then adding them to your GameObjects. This will allow creators to use the GameObject workflows they already know, but with the efficient memory allocation of ECS.

As a boost to ECS for all, Transforms will also be evolving to reduce the considerable time spent to read/write/sync Transform data between GameObjects and Entities. Unified Transform will merge ECS and GameObjects Transforms so we no longer have to copy data between two different representations. We’ll also be enabling something new: mixed hierarchies that contain both Entities and GameObjects! You’ll be able to have GameObjects parents with Entity children, and vice versa — giving you even more flexibility for your project’s needs.

Most importantly, many new editor features are being built on top of this ECS foundation, allowing anyone to gain major ECS benefits even if they aren’t using ECS directly. This includes our new animation and world building systems — two of the most requested updates from ECS users today! We have a lot to share about Animation and World Building in Unity, along with many other roadmap updates, so be sure to check out the Unite 2024 Keynote and Roadmap sessions when they go live soon on Unity’s YouTube channel. We’re also sharing these updates across Unity Discussions:


:star: What’s new since the 1.3 release?

Since hitting release status for Entities, we’ve been keeping a close eye on community feedback in order to improve package stability, resolve bugs, and address high user pain issues. The Entities 1.3 package aligns with some recent updates made to the Netcode for Entities package, and also contains general fixes and a small set of improvements. These updates can be viewed in our changelog, but here are some highlights:

  • We added overloads for ComponentLookup.HasComponent, ComponentLookup.TryGetComponent, BufferLookup.HasBuffer, and BufferLookup.TryGetBuffer — adding parameter out bool entityExists — as well as dedicated ComponentLookup.EntityExists and BufferLookup.EntityExists APIs. This will allow user-code to distinguish entity non-existence from component non-existence without additional boilerplate, inside jobs.

  • The ENABLE_SIMPLE_SYSTEM_DEPENDENCIES feature will be removed in a future package release, as it no longer provides significant benefit for expected DOTS workloads.

  • The EntityQueryCaptureMode.AtRecord enum value in EntityCommandBuffer is now deprecated. All users should migrate to EntityQueryCaptureMode.AtPlayback. Capture-at-record mode can be several hundred times slower than capture-at-playback. If capture-at-record semantics are required and performance isn’t a concern, the array of entities matching the query can be captured manually and passed to the corresponding EntityCommandBuffer command.

  • Fixed regression in compilation time with assemblies with lots of system methods.

  • ArchetypeChunk.GetEnabledMask() now allows creating masks from BufferTypeHandle and DynamicComponentTypeHandle, in addition to ComponentTypeHandle.

  • EnabledRefRW and EnabledRefRO can now be created from IBufferElementData, either from an EnabledMask or a BufferLookup.

  • Added new EntityManager.SetSharedComponent(ArchetypeChunk, T) and EntityManager.SetSharedComponentManaged(ArchetypeChunk, T) methods to efficiently set shared component values for all entities in a chunk. This is generally more efficient than setting the value on each individual entity.

  • The internal capacity of Child buffer components is reduced from 8 to 0, improving the chunk utilization of parent entities. Also, the internal capacity of LinkedEntityGroup buffer components is reduced from 1 to 0, improving the chunk utilization of prefabs and prefab instances.

  • Improved performance of the LocalToWorldSystem when processing entity transform hierarchies, by distributing work more evenly across worker threads.

There have also been significant updates to other DOTS packages, especially in regards to multiplayer experiences. These updates have been outlined over on our September 2024 Multiplayer Update. For more details across all DOTS packages, please check out the detailed changelogs for each below:


:mortar_board: New learning resources and DOTS sample project

GalaxySample

Based on your feedback, we’ve released two new learning resources to help you better understand how to use ECS for your games:

  • Galaxy Game: An approachable ECS learning sample featuring a large-scale simulation of spaceship battles. Galaxy Game involves simple, useful ECS game code for AI, spatial queries, event-based logic, different unit/building types and roles, many-to-one relationships, and more.

  • Converting a game to DOTS webinar: Learn how the Data-Oriented Technology Stack (DOTS) can unlock serious performance for your existing Unity game. This tutorial provides an overview of key DOTS concepts before implementing them in a GameObject-based project. See the tech in action, and learn how and when to use different DOTS components.


:speech_balloon: Grateful for Your Feedback

We’re always so grateful for the feedback we receive from all of you – whether here on Unity Discussions or in-person at events like Unite. We’ll continue to carefully review your input for consideration towards our roadmap, and we’d especially like to hear from you now that we’re sharing more about our efforts with ECS for all.

As always, the best way to ensure your feedback is heard is by submitting and voting on ideas within our public roadmap page. Each card on the page can be clicked on to see details and voting options, and all feedback shared here is directly routed to the proper product teams.


:motorway: Roadmap

We continue to expect an increasing volume of feedback as creators leverage ECS with Unity 2022 LTS. Our roadmap remains stable and on-track for the coming year as we continue to invest in the following areas:

  • ECS for all, new Animation system, and new Worldbuilding system:
    Details in the Updates from Unite 2024 section of this post. These efforts will arrive in a future version of Unity, after the release of Unity 6.

  • Deprecation of Aspects and Entities.ForEach:
    In order to consolidate our API and improve iteration time, we have decided to remove Entities.ForEach in a future release of Entities and focus on other APIs. The two replacement APIs for Entities.ForEach in the future are IJobEntity and Idiomatic ForEach. Changes to our Transform system led Aspects to become less relevant and a growing cost in both complexity and compilation time as they extended to support additional ECS features like Enableable Components, SystemAPI.Query, and others. Both Entities.ForEach and Aspects will remain supported in Unity 6, and we’re removing their use both internally and in APIs in a future release.

  • ECS Character Controller:
    We are continuing to prepare the official production-ready release of the ECS Character Controller package. You’ll be able to use this package to easily add an efficient and highly-customizable character controller solution for ECS, and it can be used with the Unity Physics or Havok Physics for Unity packages.

  • ECS Vehicle Controller:
    We are also working on a robust controller for vehicles, enabling creators to easily build low-to-medium realism vehicles in games built with ECS. We’ll share more details in future roadmap updates.

  • Consolidation of physics workflows:
    We’ve previously shared news that we are working on a unified authoring workflow that will allow creators to change their physics backend via the Project Settings. This work is still in progress. We also discussed our work on an incremental broadphase and new Collider.BakeTransform function — these have been released with Unity Physics 1.3 and we’ll be sharing more details in our next update on the Physics section of Unity Discussions.

  • Enabling cross-play multiplayer game creation:
    You can see the full details of what we’ve been up to on the Multiplayer side – and what’s next for our multiplayer roadmap – in our September 2024 Multiplayer Update.

  • Improve parallel scheduling and configuration:
    In the current version of DOTS, all systems run on the main thread and rely on those systems to schedule jobs to enable parallelism. We’re investigating out-of-the-box parallelism of DOTS by enabling systems to run in parallel, whether or not they schedule jobs internally. We’re also investigating removing unnecessary dependencies between jobs coming from ECS systems which previously required manual intervention. Additionally, the job system is missing intuitive configuration controls needed for adjusting how jobs are run to best enable performance for individual game needs. We’re working on expanding the priority and control of how jobs run to prevent common issues users see, such as unintentionally waiting on long-running jobs on the main thread.

  • Profiler enhancements:
    The Unity Profiler is a tool you can use to get performance information about your application. You can connect it to devices (on your network or connected to your machine) to measure how your application runs on your intended release platform. A new view is in progress that will help you to understand where your game is waiting, how job dependencies interact in the Job System, and the flow of your game’s data between ECS systems and jobs when using Entities.

  • Improve Entities Graphics performance:
    Another initiative we are looking at is the support of DOTS deformation in order to provide a mesh deformation pipeline that is performant and scalable - that works on any platform with GPU compute capability supported in DOTS. We’re currently working on improving the GPU performance, as well as the current workflow, for a better and more seamless integration into the engine/SRPs. The next versions will also bring broader material support and URP support for Motion vectors.

Our public roadmap page has been updated to reflect recent changes and what we plan to deliver next.

We’re excited to hear more from you as you learn and work with ECS! Keep us posted on your ECS creations, questions, and thoughts here in this thread / forum, the DOTS roadmap portal, or over on the DOTS section of Unity’s Official Discord. Until next time!

– Ashley

31 Likes

Hello, does this change mean that we can no longer have entities without transform components at runtime?

Does the baking system still allow to specify that the transform component is not required?

In regards to ECS being tightly integrated, what is the impact on code reload times?

Also, from user generated content perspective - previously games built by Mono would be easily moddable, but bursted code would not be. I assume ECS also implies Burst will be now mandatory and used by Unity at all times? Is it possible to separate bursted built code between Unity’s and user code?

Do the unified transforms get impacted by Jobs running on ECS transforms? what is the syncing timing / process if a monobehaviour moves a transform in Update/FixedUpdate/LateUpdate vs a Job in the DOTS style? any pitfalls?

Hoping that Transforms aren’t going to be added needlessly, excited otherwise!

Thanks for the effort! Keep it up please! rooting for this change!

1 Like

No.

Yes.

It’s too early to say definitively, but there are other changes being made to generate type information offline that we think will obviate any increased code reload cost.

These two areas in the frame don’t currently overlap, but it is ultimately the same data store and so yeah they impact each other. We’re looking into changing the safety design to allow more parallel operation with hierarchies but no details yet.

:saluting_face:

8 Likes

Hello,
When you say that these areas don’t overlap, I assume that it only concerns the ECS World that is linked to GameObjects (what is currently called DefaultGameObjectInjectionWorld)? I am wondering if it will still be possible to have a background World which would update across multiple frames?

No, I mean that MonoBehaviour updates and ECS don’t currently overlap temporally in the frame.

1 Like

Will it be a Unity 6.x version, or Unity 7 etc?

Is there any, even very rough, timeframe for ECS for all, for those of us currently developing with it?

Apologies for the vagueness, we aren’t able to share more about future product naming or versions at this time. ECS for All will not be part of Unity 6 (or any 6.x release), it will be for a future major version.

2 Likes

So you are saying that if I use 2022 LTS with ECS project, I wouldn’t be able to upgrade to unity 6 because it wouldn’t support ECS?

No. What exactly did you read to reach that conclusion?

“ECS for All will not be part of Unity 6 (or any 6.x release)” ?

“ECS for All” is the name of an initiative. Read the section “Updates from Unite 2024” in OP. They’re not temporarily removing Entities or anything (that would be silly).

1 Like

“ECS for All” = the convergence of ECS and GameObject at the engine level. Currently users have to do custom work to synchronize GameObject with ECS by themselves.

1 Like

It is an interesting move to make “ECS for all”. My only concern is how many people you get to move away from what they are used to.
If you have to maintain DOTs/Entities versions of physics & graphics & netcode, separate to core Unity, it’s a duplication of engine components. (or tripling with Physics!). Can not the same systems be shared or is it a drive to move away from Components?

Hate to quote Aras but it was a suggestion of his that “it felt like the DOTS push was with the goal of achieving best runtime performance at the expense of…” easy prototyping, iteration time etc.

Much of the value of this initiative is that systems can be unified. The new worldbuilding and animation solutions directly interface with ECS while being able to affect GameObject transforms through this work.

More systems will end up leaning on ECS where there are performance or workflow benefits, and that can be made seamless to those staying with GameObject architectures.

2 Likes

They’re modifying the internals of the systems not the way that we interact with them. In the short term they will have to maintain two versions due to maintaining previous LTSes but in the long term there will only be a DOTS version for them to maintain.

1 Like

It depends a lot on the particular library we’re talking about, but in general the idea is to scaffold gameplay-layer specific APIs (MonoBehaviour) on top of simpler native interfaces. You kind of already see this with PhysX in current Unity releases: PhysX doesn’t simulate GameObjects, it simulates its own unmanaged rigid body data , and there’s a comparatively thin API layer that pushes that to MonoBehaviour land.

The difference will be that native unmanaged memory is what ECS does really well so it’s conceivable we can just write that simulation layer using ECS data types and layer MonoBehaviour accessors on top of it. This is very hand wavy obviously but explains why I’m not worried: the gameplay interaction layer is the simplest and smallest part of the scaffolding.

4 Likes

Is there any update on “Burst Determinism” -it does not want to move out of “Under Consideration” :blush:

Besides this, awesome updates! I really feel you guy’s are on the right track!

1 Like

No update, but it’s still under consideration :slight_smile: (seriously though!)

4 Likes

Any news regarding occlusion culling and GPU Resident working with Entities Graphics? I think right now they are not supported when using entities… at least not the last time I tried.

1 Like

For those that want to use ECS, creating game code will be as simple as writing Systems and Components, then adding them to your GameObjects.

For those like the structure of the an Authoring script is that workflow still going to be available, or is it getting removed in favour of directly pinning components and systems to GameObjects?