Official DOTS development status and next milestones - May 2024

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


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 March, we released Entities 1.2, 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. We've also created a full list of all our DOTS tutorials, sample projects, studio case studies, and more community resources over on the Unity Blog: Start learning data-oriented design in Unity with these resources.


What's new since the 1.2 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. A new set of these improvements are available in the Entities 1.2 package and can be viewed in our changelog. Here's a recap of the most notable updates:

• There is now serialization support for UnityObjectRef<> which enables unmanaged references to Unity assets. For example, instead of a Texture on a managed IComponentData, you can have a UnityObjectRef<Texture> on an unmanaged IComponentData.
• There are new Type templates available through the Create menu, including IComponentData, ISystem, IJobEntity and Baker types.
• As we work towards our efforts to consolidate entities and game object workflows, we’ve changed the way we are storing entities in preparation for future work. Entity IDs are now globally unique and can be moved efficiently from one entity's world to another. This will not impact ECS workflows in Unity 6, with the exception that it disambiguates debugging so you always get the exact entity in your debugger.
• Several fixes have been applied to the entities hierarchy window:
  • Selecting entities and systems within the hierarchy works again.
  • We’ve fixed an invalid range check that was failing after removing entities from the hierarchy view in perfectly valid use cases.
  • We’ve fixed the entities hierarchy from throwing exceptions when entities were destroyed.
  • The entities hierarchy now removes all nodes of a scene and subscenes when the scene is unloaded.
  • An exception is no longer thrown when entering a prefab from the Entities Hierarchy.
• Various performance improvements for baking have landed, along with significant performance improvements when creating archetypes and entity queries in worlds with a large number of existing types. Performance improvements have also been made for LocalToWorld systems and non-dirty hierarchies.
• We’ve fixed an issue where an EntityQuery using WithNone<T> on an enableable component wasn’t inserting a necessary job dependency.
• EntityQuery singleton methods now correctly handle cases where the query contains enableable components.
• Several memory leak issues, such as those affecting world deserialization and content delivery, have been fixed.
• A fix has been added for breakpoints in jobs defined in systems with System.API.
• In preparation for efforts on our roadmap, know that Entity IDs are now globally unique, and you can now move them efficiently from one Entity’s world to another. This does not impact ECS workflows, but it does disambiguate debugging by always showing exact entities.

There have also been recent minor updates to the other DOTS packages, like improved ways to interact with and modify colliders at runtime with Unity Physics. Multiplayer-specific updates have been outlined over on our May 2024 Multiplayer Update. For more details across all DOTS packages, please check out the detailed changelogs for each below:

• Entities
• Netcode for Entities
• Unity Physics
• Havok Physics for Unity
• Entities Graphics

Lastly, all of the recent benefits (and 50+ fixes) of ECS delivered with the 2022 LTS / ECS 1.1 / ECS 1.2 are now available in the just-released Unity 6 Preview.


New learning resources and DOTS sample project

We released our new exciting Megacity Metro sample in March, which focuses on creating multi-platform multiplayer games with support for mobile devices and cross-play. It serves as a guide for creating a competitive action game with more than 100+ concurrent players, demonstrating the use of DOTS, Netcode for Entities, Physics, Rendering, and Unity Gaming Services. You can review our live overview session from GDC 2024 here or replay our recent webinar to catch a deeper breakdown of the sample and how to kickstart your next ambitious multiplayer title in Unity 2022 LTS.

Speaking of GDC 2024, don't miss our other DOTS-related session from the event – Improving performance with DOTS baking – and the DOTS updates we announced in the official Unity roadmap presentation (specifics shared later in this post within the roadmap section).

In addition to Megacity Metro, we've also posted new intro DOTS tutorials and hosted several virtual workshops (like How to Convert a Game to DOTS) for those looking to get started with ECS. Browse our latest DOTS resource roundup for the full list of learning materials, from educational video tutorials to inspiring customer stories that’ll help you gain practical insights and guidance so you can hit the ground running with DOTS.

Additionally, if your studio seeks to invest in more hands-on experience working with Jobs and ECS, we have officially launched our live DOTS Fundamentals Course through Unity Professional Training.

For the next batch of learning resources, we're preparing new content targeted for Unity 6. More details about this effort will be shared at Unite 2024, keep an eye out for updates!


Grateful for Your Feedback

We've been receiving amazing feedback from the community both online and at events like GDC 2024. Know that we are carefully reviewing your input as always for consideration towards our roadmap. The current predominant themes we've been hearing from you are continued needs for ECS-based systems like Animation, updated and more comprehensive learning resources, and ease-of-use improvements for the ECS user experience.

Thanks as always for looping us in on your needs as you work with DOTS, keep the feedback coming!

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.



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:

1. Consolidation of ECS workflows:
We’re still heavily focused on understanding and addressing feedback from users adopting ECS in production. Based on the feedback that we’ve received so far, we'll be focused on the following:

• Unification of Entities and GameObjects:
  In past forum updates, we've mentioned our efforts to consolidate ECS workflows and we just revealed more details about this at GDC 2024. If you haven't caught the news already from the Unity Roadmap for Unity 6 and beyond presentation, we're bringing GameObjects and Entities closer together to deliver data-oriented performance to all Unity projects. Editor authoring workflows will be able to leverage the power of ECS to support the authoring functionality and runtime complexity that many projects need today. It will also become easier for you to introduce targeted ECS solutions within your GameObject-based projects to tackle specific performance issues. Importantly, many users will be able to enjoy performance benefits of ECS without having to directly work with complex ECS workflows, unless they need to. Our primary milestones for this work involve the following:
  
  1. At its core, every GameObject in your project will exist as an Entity to simplify the manipulation of project data through both architectures.
     
     
  2. GameObject and Entity transformation APIs and data structures will be aligned to boost synchronization performance.
     
     
  3. Scene and build workflows will be unified to provide a streamlined and cohesive experience regardless of which system you use to manipulate project data.

The consolidation of Entities and GameObjects will arrive in a future version of Unity, after the release of Unity 6.​

• Enabling open-world game creation (ECS Animation and Worldbuilding):
  The authoring workflow performance benefits offered by the consolidation of Entities and GameObjects is allowing us to create improved ECS-based reworks of the Editor's Animation and Worldbuilding systems. These new systems enable us to deliver more dynamic and scalable editor workflows, along with unprecedented complexity at runtime. You'll be able to have many more and higher-complexity characters on-screen along with support for large open worlds by default in your projects. More updates on this work will be shared in the future, so be sure to keep an eye on the Animation and Worldbuilding forums.
  
  
• Deprecation of Aspects and Entities.ForEach:
  Entities.ForEach was an API that helped many new users quickly take advantage of the power of burst and jobs to iterate over Entities quickly. As time went on, we introduced new APIs that required less code-gen (and thus less impact on compile time) and we heard from users that they largely preferred the structure that IJobEntity and IJobChunk gave them when organizing their code. 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.
  
  Aspects provide an abstraction over component data inside of ECS. The aim was to provide simpler APIs that involved a large number of individual components. The long term plan was for Aspects to be used in helper methods to manipulate component data in a simpler, safer, and more stable manner. However, 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.

​

2. 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're also working on a new update to the broadphase. You'll be able to change it to operate incrementally using the PhysicsStepAuthoring component (see parameters Incremental Dynamic Broadphase and Incremental Static Broadphase), and the PhysicsStep Entities components. When the feature is enabled, the bounding volume hierarchy inside the broadphase – used for spatial acceleration during collision detection and for collider queries such as ray and collider casts – is no longer built from scratch every frame, but incrementally updated from one frame to the next. This can lead to drastic performance improvements for scenes with large numbers of rigid bodies of which only a very small subset changes between frames. Changes to rigid body transformations or colliders are rare. This feature can be enabled for dynamic bodies and static bodies separately, which makes it applicable to large and mostly static worlds with massive numbers of static rigid bodies and a reasonable number of dynamic bodies. By default, this feature is disabled.

Also coming up for physics is a new Collider.BakeTransform function that provides the ability to arbitrarily scale or otherwise transform any collider at runtime efficiently. There will also be a new CompoundCollider.Update function that will allow modifying the shape or transformation of child colliders within a compound collider without having to recreate the entire compound collider from scratch. This will greatly reduce computation time for these dynamic collider cases. Additionally, spring and damping parameters for motors are now supported for custom components through baking, and in the Unity Physics API and custom components. This allows you to tweak how a motor moves to reach its target. Use damping to adjust how much overshoot a motor may have when approaching a target, and use the spring parameter to adjust how bouncy it is.

As part of streamlining our physics workflows, we are also considering the deprecation of Unity Cloth in a future version of Unity. If your studio/company is using Cloth, please let us know in the comments so we can get in touch about your experience with the feature. In general, be sure to visit our Physics forum for any physics-related questions or feedback you'd like to discuss.


3. Enabling cross-play multiplayer game creation:
With the release of the new DOTS/Multiplayer demo project Megacity Metro, extensive Netcode updates, and the expanded Multiplayer tooling kit, we've been highly focused on providing creators with efficient out-of-the-box support for a variety of multiplayer genres. 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 May 2024 Multiplayer Update.


4. 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.


5. 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.


6. 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.


7. New education content:
We’re working on an extensive e-book that will explain the benefits of DOTS and provide a high-level overview of its features. Our goal with this guide is to help creators gain a foundational understanding of ECS before diving into our samples and tutorials. A new series of Unity Physics samples structured around real-world use cases are also in development. Lastly, we’re working on a new DOTS game sample where two spaceship factions battle for ultimate domination. This sample will showcase large-scale simulation of many simple entities that have relationships between each other.


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


See you at our upcoming events!

Coming up on May 15 2024: A free online webinar that reviews the Megacity Metro sample project and demonstrates important features of Netcode for Entities, Multiplayer Play Mode, and more. Register here.

Also, Unite 2024 has just been announced! We hope to see you at the biggest Unity event of the year, happening this September 18–20 in Barcelona. We're preparing to share new updates and resources targeted for Unity 6 at this event, so keep an eye on this page for more details on what to expect and how to attend.


Thank you!

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

 

IJobEntity and idiomatic foreach aren't going anywhere

 

Ah yeah, I see what they mean now

 

I think we definitely want a way to specify a kind of 'meta' type for queries and iteration. But Aspects ended up trying to do way too much, and the impact on iteration time through a very large amount of source-gen was just not going to work.

Unfortunately, this means that solving the real problem (type associations) requires going back to the drawing board in order to do it in a way that wouldn't require the same level of expensive source-gen, which in turn means it wasn't something we could just easily fix in place. The path to cheap, but useful, source-gen usage requires particular approaches to the API to get right.

 

Aspects will remain for the entirety of the Entities 1.x line. We don't want to pull the rug out from anyone using it currently, just signal that we don't intend to carry it forward to the next major release.

There's a lot I like about Aspects, particularly as you say the simplicity of wrapping up optional components without resorting to OOP, and hopefully we'll come up with an alternative that captures the best elements without requiring either the remaining engineering investment or iteration time cost that make Aspect support difficult.

Lastly since Aspects support is codegen based, it's hopefully straightforward to replace and even conceivable someone could support it as an auxiliary library (although I should caveat I haven't actually seriously looked into the latter).

 

Looking forward to sharing details when we can, which isn't now.

 

For this case, we're looking at a means of implementing long-running jobs. This will likely involve managing state so these jobs can be paused and resumed in a controlled fashion, but the key will be to ensure it is easy and stable to use. We are also hoping to explore e/p core usage, but how we end up taking advantage of that is still uncertain. i.e. if you have 4 efficiency cores and each has a worker thread, and you have 7 background jobs, they still need to be able to alternate processing in some fashion.