Official DOTS Development Status And Next Milestones - December 2021

Hi everyone,

Thank you very much for your patience. My name is Laurent, Product Manager for DOTS. I’m jumping in here to share an update on where we are before we share a larger and more detailed communication at the beginning of 2022.

To make it very clear: We are actively developing DOTS. Over the last year, the teams working on ECS solutions have been focused on leveraging the lessons learned from early adopters’ productions to converge toward a stable first release. Getting to a first fully supported release has been and remains our main focus.

Our original intent with the development of DOTS was that it would be fast, generally stable, and straightforward to support. Our enthusiastic commitment to this new way of building games reinforced a belief that we would get out of experimental and unsupported mode quickly. Not only did it take us more time to build a solid foundation than we envisioned, but we also realized it required a more comprehensive approach that touches almost every aspect of the Unity development experience. As such, we ended up having to rewrite APIs more often than we wished, and at times we struggled to deliver the fixes at the speed and quality that we hold ourselves to. We ended up pausing releases altogether while trying to figure out the best direction earlier this year.

We’re now confident that we have reached the point where we will be able to restart releasing public patches to our packages.

We will do this with two milestones. The first is a set of experimental packages updated to version 0.50, compatible with Unity 2020 LTS at first and targeting compatibility with the upcoming Unity 2021 LTS later in the coming year. This release will allow you to get easier access to patches and fixes compatible with ongoing LTS versions. Those packages will remain in experimental mode with this milestone, meaning they are still not recommended for production. We are targeting the first quarter of 2022 for this release.

The second milestone is the actual transition from experimental packages to full release status with the version we call Entities 1.0, which will be fully supported much like any other released feature of Unity. The 2022 LTS cycle is our preferred target for this release, but we have yet to confirm it. Entities 1.0 will not be compatible with earlier LTS versions. We will be releasing the details of the provisional scope of this version and future steps at the same time we release version 0.50. This plan will be detailed in our public roadmap space so that you can easily share your ideas and feedback.

The goal of Entities 1.0 is to augment the Unity Engine with an opt-in way of writing game code that’s compatible with the existing Unity architecture. Entities 1.0 is focused on enabling specific scenarios and types of games that were previously challenging to build in Unity. This will be illustrated with new, real-production examples from some of the early adopters of DOTS and crystallized in updated versions of DOTS samples.


DOTS Shooter will be a starting point for creating a networked shooter game with simple main thread game code. The netcode uses client/server architecture with what you expect from a complete solution with client-side prediction, interpolation, and lag compensation.


Megacity will show how to use Entities and baking workflows to author content using subscenes. As we make the authoring experience in the Editor much more integrated and robust, the subscene workflows get closer to existing Unity workflows while ensuring that they can scale to the Megacity complexity.


Unite Austin/Nordeus will show large-scale simulation of entities and how to write high-performance multithreaded game code.

Entities 1.0 is all about getting Entities to a released state, with the support, documentation, and learning content expected of a released workflow, so you can safely choose to use our ECS solution for your productions. Our current scope for this release covers APIs, authoring, and debugging workflows for entities, physics, netcode, and rendering. We are giving particular attention to ensuring that the authoring, baking, and visualization workflows are well integrated into the Editor, and that iterating and debugging Burst for game code is a productive developer experience.

Not all of Unity will have complete Entities compatibility, and based on many successful experiences of our early adopters, we are fully embracing the hybrid nature of our 1.0 release. This means the scope of 1.0 includes strong conversion workflows allowing you to choose ECS for its value in solving specific challenges while leveraging GameObjects for other aspects of your production. Our goal is to enable teams that are able to ship a GameObjects-based production to leverage ECS for reaching goals beyond what Unity used to be able to support.

To wrap this all up, we plan to share more information with you during the first quarter of 2022 with the 0.50 update to experimental packages that will enable us to ship patches again. The full list of packages will be shared closer to the release. We also intend to present at the same time the scope of 1.0 and beyond to continuously validate our direction with you as we go.

We hope that this update helps to clarify the current, ongoing work and gives you a clear overview of what to expect next.

Your feedback is important to us and will help us build the DOTS solutions you need. We love your passion for Unity and will increase our efforts in engaging with you more frequently and in an open and honest way. Please feel free to share your questions and feedback around this announcement in the thread below and we will do our best to answer.

Laurent

 

Yes! This is the type of news and announcements we were waiting for! Keeping us updated is the right approach, and you did it guys! Thank you. And I'm excited for what comes next!

 

Thank you very much for the communication and transparency! I look forward to 2022!

My only request is that this sort of communication be provided more frequently, and when unable to do so (depending on the reason) merely share something like "we can't share anything new right now, but we are still moving forward". I fully believe in DOTS as well as ECS as it has definitely improved my projects.

 

Thanks for the update!
So what can we expect from 0.5 compared to the current 0.17 release?
Some patch notes would be nice.

 

@Enzi the notes are being worked on. We'll share more details as we get closer.

 

Oh great! Looking forward to it!

 

Sounds like we will get more of the ugly hybrid approach rather than the full DOTS solution.

 

Sounds like both to me. And I'd quite like my existing mono project to be accelerated by say, DOTS hybrid renderer v2, or subscenes.

That sounds like a good candidate to mix, if possible. I want speed. I don't want to fight or work harder. That's a good customer demand.

 

I don't know about others that much, but I like the current system.
I have no problem, if Unity decides to keep mono behaviors and entities separated.
Since its less work for those, who already learned the current way.

Sure it would be nice to have one perfect system that just works right now.
To me it feels like demanding trip to mars.
Right now I'm happy that its even possible to do some ideas that has been previously impossible.

So, I'm happy if they just keep improving the current systems. Especially the audio, netcode and physics tool sets.
Also things like upgrading the good example projects to latests ecs packages. Even that would be a lot to me

 

We also want the samples (fps, megacity etc) to be continuously updated to the latest DOTS packages. That would be so helpful to get better insights on the newer not-outdated API!

 

Yes even if its just for Unity to see how it is to keep a project alive between new versions of Unity.

 

@LaurentGibert thanks for the update.
Burst stability has been great for a while, and performance is still insane.

Are there any significant (coding) ease of use improvements in V50 or V1.0?
GameObjects still seem 10x easier to use, which was always a huge selling point for Unity
Entities/Jobs/ForEach/Burst/HPC# etc. are still a little hard to use.

 

Can you PLEASE and make sure at least one of those demo / example scenes fulfills both below requirements:

1. It is maintained for a reasonable amount of time and works with many future Unity versions. If it stops being maintained it's because another sample project that fulfills roughly the same purpose has replaced it. <- Up to now none of the Unity produced demo scenes have fulfilled this requirement, in fact Unity's demo scenes are notorious for being deprecated and incompatible with newer Unity versions the moment they are released.


2. It is made reasonably well, with things that can be considered "best practices", even for secondary things. <- I remember the angry bots demo being made reasonably well (or maybe I just didn't know better at the time?), but more recent demo scenes contain things that are flat out terrible. This shouldn't happen! Users use these as examples of how to do things. But if I open a recent Unity sample what do I learn?

In the FPS Sample I learn that to deal with lightprobes, I need to MURDER my scene with so many lightprobes it starts looking like scanned data point cloud:


In the even more recent HDRP Sample, I learn that I shouldn't care about lightmap UVs at all

There are many more. My examples don't have to do anything with DOTS, it's because I know a lot more about Unity's Lighting than DOTS, so I'm more comfortable calling out lighting related things, but I hope my general point still comes through.

People use these sample scenes as examples on how to do things and all the elements, that are not obviously placeholders, should be made with the highest quality and care, as they will be used as a reference point for Unity users and will find their way in many released games.

 

Well by reading the tea leaves and such (github PRs) we should be able to "pick" (click and select) entities in the editor which is something that should have been prioritized since day 1 imho (along with collider rendering... debugging invisible colliders is a royal pain in the arse)

 

I meant for coding in particular
They'll probably figure out the Editor integration, I am not worried about that tbh.

 

THANKS!!! DOTS RULES!!!

 

Some of them have not been made by core DOTS team.
FPS sample uses various hack solutions if I remember correctly.
It would need to be most likely redesigned ground up, by DOTS team, to be up to date.
Megacity demo used old long depreciated solutions. But if I am correct there is version made by community, which works with Unity 2020.

Transiting any project to keep up to date, requires significant effort. Specially if various packages are depending. Rendering pipeline changes will be first major obstacle, to bring things up to date. Hence probably very time consuming to do so.

If anything, the best and fresh thing is, to bring completely new demo, which uses latest packages.
Something which uses networking and DOTS, i.e. combining FPS sample and Austin demo.
I wouldnt be surprised, if Unity doesn't work on it already. Or some independent group. Which later is happy to share the source code.

 

@LaurentGibert This is great news
I am curious about the state of the rest of DOTS (aside from ECS) and what improvements we can expect. Blob Assets, Burst, Native Collections and Jobs are all great tools by themselves and I'm wondering what this announcement means for them specifically. Improvements to Burst's debuggability, more BlobAsset structures (a hash-map for instance), more allocators in the style of UnsafeScratchAllocator, etc... Any of these (and/or others in the same vein) would make this announcement even better

 

Couldn't have said it better myself! I agree with you. However, what I meant by "more frequently" is like once a year or so.

I guess that's even a better idea!

 

I wonder how many coders use entities like I do :

* No hybrid renderer, no ecs transform, no conversion, I dont use any of the built-in ecs components.
* my own carefully crafted custom ecs code, components, systems, foreach jobs.
* a pool of renderer gameObjects with a custom RenderLink IComponentData and a renderSystem that runs on mainThread.
* some monobehaviours to debug and bootstrap my systems.

 

This is basically how I handle things whenever I dev in Unity, largely because it keeps tracking data flow easier.

 

@Razmot I think you may be better to create seprete thread on that. Otherwise we may get into oftopic, as question is not directly related to OP discussion.

 

@Joachim_Ante this move would definatelly please many DOTS developers
Specially many of us did asked few times, about keeping these more up to date.
But I got it l, why it hasn't happen so far. 1.0 seems good standing point, to bring these things up to pair.

 

Not production ready? I dont care just cant live without air.

 

We're the same on the first and second. We use our own renderer. I hope there wouldn't be much API changes as our ECS code is already quite extensive.

 

Did you place those probes with a script, like "auto light-probes" or manually?

 

If I understood correctly, V50 will not be compatible with 2021 LTS, is that correct?

 

Not at the beginning of 2022 (when released), but will be later. It's a huge blocker for me to be honest. My GPU animation instancing needs features from 2021 and the current entities package works fine. I'm assuming hybrid renderer is the culprit.

 

Extending the above question, will 0.5 be compatible with 2022.1/2 ? Since those versions already have changes targeting dots 1.0.
Having to wait another year for support on latest unity version would be a heavy blow T_T, specially considering that 2020/2021 have serious performance regressions and some render pipeline bugs/missing features (maybe some were backported, I haven't checked).

 

Thanks for the feedback everyone. Let me try to clarify two questions:

• Like Joe said already, yes our samples need to stay up to date, we need to do a better job with this.
• Regarding compatibility, we had decided we needed to ensure compatibility first with 2020 LTS, to ensure a better experience for many of you who have been using experimental dots in various projects on that LTS. And catching that train introduced a little bit of delay for us to ensure compatibility with upcoming 2021 LTS, but it is the plan to support it as soon as possible after the availability of 0.50, so that here is no distribution gap between 0.50 and 1.0.

Keep the questions going!

 

The entitie 0.5 will contain enable/disable function？

 

Hi @LaurentGibert. I have a couple of questions want to ask.
1) I have the impression that DOTS is very focusing on desktop but not mobile platform i.e. Android and iOS. Currently I'm using dots netcode and it has a lot of performance and networking stability issue. Is that currently there's no dots mobile project at Unity production to battle test mobile platform? Any plan to improve it?
2) The current subscene conversion speed is insanely slow. Even I just change 1 simple field of data a lot of time I need to wait for ages and even sometime need to end task Unity to make it convert properly. It seems like Entities failed to incrementally scan and update the delta changes. Any plan to improve it?
3) DOTS mobile project takes insanely long time to build. It's seems like something wrong with the dots build pipeline. Any plan to improve it?
4) Can I expect a better Entities debug and visualization tool at version 0.5?

 

While I think that keeping a hybrid apporach has its advantages and can be interesting if the integration is done properly (looks very hacky today IMO), I'm concerned about other gamedev features that could make good use of DOTS such as AI and skinned meshes.

Can we expect easy to use and well integrated DOTS versions of these features in the future?

 

Will the demos be updated in time for the 0.5 or are they slated for being released for 1.0?

 

Sadly these are not news. We knew an update was coming by looking at Github commits. What we need is a clear roadmap and vision and that's none of it.

While DOTS solves real issues in Unity, its stable core is two years late, still experimental, and hasn't received any update in a year. None of it would matter if, on the other hand, Unity would have released new ways to author high quality, stutter-free streaming environments, or just announced anything in that regard. But Unity just stalled and I certainly am not the only one losing faith in the company and its software.

Unity users jumped on the Unity 5 PBR workflow during its beta because they trusted Unity. Unity users early adopted Mecanim, Enlighten, SpeedTree, Shader Graph, VFX Graph, SRP and so on again because they trusted Unity would deliver these things down the line. The same goes for DOTS, animation, physics and world building. People who trusted Unity has now nothing to build trust on:

• Should we really believe that DOTS 0.5 will arrive in Q1 2022?
• Should we really believe that DOTS 1.0 will arrive in the next two years and be well integrated?
• Should we really spend our companies money on that high risk gamble?
• What happened to the new world building systems? Will it be DOTS or Monobehaviour?
• Will we have a DOTS animation graph?
• Will we have usable audio system for DOTS?

In the last three years, Unity went public and acquired a bunch of companies that won't give anything to game developers for the next two years, while Epic made Fortnite tech stack available to all, acquired Psyonix, Quixel, Mediatonic, RealityCapture, and more, plus they have Unreal 5 production ready now, Meta Humans, Mega Grants and free Mega Scans.

I myself bought Unity stocks, provided a lot of feedback for DOTS and HDRP. But I really am disappointed by this (lack of) update. We're not enlighened by anything here. For anyone following DOTS closely, what we read here is: "We'll give more news in 2022", and nothing else.

1. Where and what is the next Unity for games?
2. How will Unity 2022 and 2023 compare to Unreal 5?
3. Will DOTS be part of that vision?
4. Is Unity really commited to shipping DOTS-compatible and production-ready physics, animation, ui, rendering, audio and other systems?

 

In that case would it be possible to mix high performance largely static world rendering with general gameobjects that are dynamic? So that Unity handles the hard task of streaming and rendering lots of things, while I code happily and simply in gameobjects for everything else?

Obviously I'd have to keep the colliders in gameobject land but the environment rendering - the slow part of gameobjects - could be DOTS.

I feel it would be a good problem-solve for many and a great gateway to DOTS at large.

 

Sort of agree, why cant we just get back to updates now? Quite honestly, I never really expected smooth sailing from being an early adopter, but I did expect the winds to be more plentiful and bountiful than what we've had lately.

 

I feel for the DOTS team, so much attack on what it should be.

It'll be exciting to see how the new frameworks can be used!!

Edit: my $0.02, Game Objects and DOTS shouldn't mix, it sounds like a mess. I would rather choose one framework or the other.
Some may argue that this is the same fork in the road that was brought about with HDRP vs URP though. Decisions are hard.

 

Will there be dots animation and dots audio in V0.5？

 

I'm not mixing in this case, the responsibility is clearly separated, as it often is with a job like large-scale static env rendering in other engines too.

It can be achieved today with existing hybrid renderer, but the path is not smooth so I'm enquiring if Unity will smooth it.

If it goes well, I can see myself doing more and more DOTS work here and there, eventually moving over when the rest of Unity's technology is fleshed out.

 

What about Project Tiny? Will it continue it's development separate? Will it merge with the "Big DOTS" development line?
Is there even a future for a pure DOTS environment?

 

Thanks all, a few additional words to what Joachim said:

Regarding platform support, DOTS in its experimental phase was focused on solving very specific problems in the context of a limited number of early adopters projects, and this explains the partial coverage of good platform support. As we get to a released version, the normal expectation to have is to get the full platform support of Unity for this release.

About the separation or non-separation of entities and gameobject. We fully embrace an hybrid release so that we can support the largest amount of use cases for you. In certain situations it would be preferable to focus your game code in full or in part on entities, in some other cases it might not be the best approach. To help you with this, we will illustrate with real game developer projects examples, documentation and samples, how to best chose the combination of tools you need to achieve you creative goal.

Regarding the questions on the details of 0.50 and 1.0, as well as the comments related to the fact this communication is not coming with all those details already: we considered waiting for 0.50 to be finalized for this communication, but we also noticed how many of you were simply impatient to see us delivering information on a regular basis instead. This is what we are doing here, reopening the conversation, and openly sharing the best information we have. Our next communication will contain the details of 0.50, and the scope of 1.0.

Thank you for being engaged!

 

Is determinism still a goal? Burst was supposed to have deterministic floats. Right now, my team is divided between those who want to use ECS and try to hack in software floats and those who just want to give up and switch to C++ or something else.

 

Awesome. Maybe I elaborate more about one of the long term dots issue at mobile platform for dots netcode that still haven fixed yet until now. Currently one issue I encounter is sometimes it will become super unstable and start spamming lots of error code -5. I believe there's something wrong with transport package that dots netcode using it. Currently I see the transport package version ady reached 1.0.0-pre.10 version but I'm not whether this issue has been addressed and fixed. Can you make sure this issue is fixed and available at dots 0.5 release for dots netcode? https://forum.unity.com/threads/mutiple-errorcode-5-related-warnings.1098229/

Currently hybrid component feature doesn't work really well. For my project, when I use it at game object based particle system there will be some effect will be missing after converted to entity. Any plan to improve it?
And also when game object based particle system has Skinned Mesh Renderer component it will not converted that component properly too. Long time ago Hybrid Renderer team tells me that they are not planning to support game object land Skinned Mesh Renderer conversion. Is that still the case for this new plan?


More questions.
1) What's ETA to ship pure dots UI package? Up until now I still can't get any info it will release anytime soon. Currently I'm using game object based UGUI which is one of the huge bottleneck of my mobile project as I need to use very slow class type system to update UI. With dots UI package I can migrate to burst system.
2) What's the ETA to ship pure dots AI package like dots behavior tree or dots utility AI or others?
3) Is there any plan and ETA to ship pure dots AI navigation package instead of current navigation that needs to access C++ land which is kind of slow and buggy?

 

Q / Will we be able to convert all gameobjects (including the camera itself) to entities? Will we be able to convert VFX Graph particle gameobject to entity to simulate particles from millions to billions?