Official Notice on DOTS compatibility with Unity 2021.1

While all this is mostly speculation, I must say the combination of what had been communicated makes me wonder like many here if I should continue pouring time into ECS:

• Wording about package manager changes such as „experimental packages may never be released and dropped without explanation“
• ECS is disconnected from Tech Stream (so far it was the other way around: hybrid renderer only works if you have the latest beta)
• No responses anymore to issues in Hybrid render Thread

Looks awefully similar to preparing big announcement that could trigger an outcry such as „we decided to drop it and keep only BURST and Jobs“....and then Unity can point back to all this previous communication „we always said experimental stuff has no guaranty to ever make it“...

 

Could also be an announcement about making an Entities-focused version of the Unity engine, or something like that. I'd actually be really happy about that.

I really doubt they're planning to drop support for the ECS stuff. They did mention that new versions of the Entities packages are on their way

But I think the most likely scenario is that all of this is happening for very banal reasons. Like needing a version of the engine that supports some new C# feature in order to continue DOTS development

 

I think this is what will probably happen. They want to keep the development of Unity and ECS in lockstep; if a lot of the changes to do this are in the core engine, then this could require a different variant of the engine so they don't mess with monobehaviour land's stability. My only concern is that if they are releasing a separate version of the engine for entities (during entities development, there would be only one engine when DOTS is 1.0) that the differences between the entities version of the engine and the monobehaviour engine will create some headaches when using third party assets / libraries and the SRPs.

 

I also doubt that they will drop Entities they have invested to much in it and it is so promising theology it would be stupid to bury it. Dedicated DOTS Unity could be nice, but I doubt it is the case.

 

I don't mind the concept of keeping ECS development in one LTS version of Unity. ECS is way more developed than what it was, but it is still pretty experimental. I just feel like the style of announcement was weird. I do have to wonder if Unity's plans are changing. It also makes me wonder how much Unity's focus may change as a function of going public.
For the record, I really like the direction ECS is going, and I'm happy for it to be in the experimental phase for a while, if thats what it takes. I would be very frustrated if ECS was dropped. If a major, promising development like that was dropped I would have to really reconsider Unity.

 

If it helps the DOTS team release ECS updates on a smoother, maybe more frequent schedule, I don’t think it’s so bad.

the Hybrid Renderer is a question mark, but hopefully there will be more info about that soon.

Thing maybe I’m most bummed about is that we probably won’t get code generator support this year. :/

Hopefully this is a good thing. I doubt this means they’re going to cancel ECS, or spin off an ECS-specific version of Unity.

If they were to cancel ECS after all of the marketing, I think they know it would be a serious, self-inflicted blow.

 

Reading through the weekly reports of 2021.2A changelogs, Burst complier seems to be actively developed and moving in lock step with SRP development. For one, programmers tasked to Burst appear regularly in this very forum responding to bug reports and rapidly deploying fixes.

For example, look at this thread: https://forum.unity.com/threads/burst-1-5-1-calling-directly-from-managed-code.1088344/

Someone finds an problem with Bursted code. Unity employees cant reproduce and ask for repos. Further tests user discovers the issue. Unity reproduces, fixes, and notifies the user and the world at large that a fix is coming down the pipeline.

This is how communication should be. A back and forth. Not dropping bombshells and radio silence.

I really fear something similar to the Depreciation of UNet is going on in the background. Programmers cleaning up the loose ends with Entities with the next and final release and putting it on life support in LTS version. Then everyone washes their hands of the entire package and moves on.

Thankfully the ultimate core of Unity DOTS is still moving forward, Burst and Jobs. I can easily see a potential Mirror like situation occurring where the community decides to pick up the pieces where Unity left them and continue on without official support.

I personally am moving in that direction with my various projects. Thankfully I've never really subscribed to the whole separate ecosystem that DOTS envisioned so conversion to core Bursted IJobParallelFor simply means removing all the IComponentData inheritance from structs and reorganizing all my data into NativeArrays I pass around.

An added bonus is the ability to finally use all the fancy and exciting features Burst 1.5 brought in without waiting for / if the next Entities will be pushed out to the general public. Bursted functions in managed code, bursted mods, bursted temporary ValueTuples, and more. Burst 1.5 is an evolution in performance and maybe someday, in the far far future, bursted Mono. I dont know how but I believe in Unity, at least the Burst department.

Unity ECS or DOTS as it's now called these days was a great and grand experiment. From the first days of complete confusion about what to do and how to do simple tasks to nowadays combing through Burst output to achieve that illusive loop vectorization. I've learned a lot about ECS architecture in my journey with this package these past few years and honest cant go back to programming OOS. Thank you Unity for all you've done and the money you sunk into this black hole to educate at least a part of the programming world about the brilliance of ECS structure.

It'll go up there in programming heaven with UNet and people will talk about the possibilities of what could've been years down the line. Until then, back to ripping my code apart trying to stick everything I can into bursted functions.

 

SRP is now tied to Unity versions officially. I use SRP loosely to refer to the whole suite, HDRP, URP, VFX, SG, etc.. If you have followed the pain that SRP was before they tied that knot, you have a pretty good idea of what is likely going on here.

HR alone is enough to force DOTS down the same path. Once they tied SRP to specific Unity versions that ties pretty much every package that integrates with SRP to the same fate. It's a chain reaction that is going to suck in a whole bunch of packages I think.

Which is good.

The communication not so much.

 

They did not say anything about only LTS versions being supported. Also they can tie hybrid render to a specific unity version. So it is likely something beyond just this.

Actually it sounds like LTS 2021 will not be supported.

 

A few days later, this news has really got me down.

Being unable to use newer Jobs, Burst, and render pipeline versions until next year, and the uncertainty it casts on whether or not Unity will stop developing ECS, have me waking up depressed. I'm uncertain about the way forward for our code, and I'm less confident in Unity with each day that they don't give us some explanation. Any explanation.

Unity, @Joachim_Ante, you've got to give us something. People can't trust in a platform with an uncertain future.

 

No one stops developing Entities (and DOTS in general). One of the reason for all of that is the 2021 delivery cycle. Unity announced new packages delivery rules for the 2021 cycle and developing DOTS in these rules can be not safe for non-DOTS users, as DOTS often require changes not only in a package but in the engine itself (and I think all of us understand this). Thus Unity need, for now, to change delivery rules for DOTS and consider the best strategy for both sides. It's one step forward to better stability of an engine and DOTS. There will be much more info on this coming. Just let's wait a bit

 

Are you referring to specific information that you know is coming, which isn't publicly available?

 

I think he's referring to this:

 

With that quote, it looks like my fears were unfounded. That's confirmation that they intend to develop and release Entities.

And it was in the very first post of this thread. I was just wrong. Thanks for pointing out that quote. That helped a lot more than telling someone to "Just wait a bit. "

 

Don't blame yourself, it's a group-psychosis... Too many doom-filled posts alter the readers' mindset. One of the darker side effect of our socialized nature.

 

If you're afraid of what happened to UNet - remember, that Mirror still exists.
And Mirror (formerly HLAPI Pro) never had open sources in the first place, it was decompiled from a dll.

Entities do have full open source, and can be modified directly even now, simply by moving from Library to Packages.

Something that is being widely adopted cannot be removed that easily.
And personally, I don't see myself making games without Entities anymore, so yeah.

 

Given the state 2021 is in, both as a Unity version and as a year in genera, I think this is a quite acceptable state of affairs.

 

I must be in the minority who reads this as mostly positive. The current entities packages are going to be kept on 2020 LTS which makes sense; that's the stable version Unity recommends for active development. The 2021 cycle sounds like it is going to have some deep engine refactoring/integration which requires everything be broken for a while, but should result in usability and performance improvements once it is finished.

You need to break a few eggs to make an omelet, and I am getting pretty hungry so let's start breaking those eggs. Speaking of which, I should probably go make breakfast.

 

I don't pretend to know the full scope of this, to me it seems Unity had big problems satisfying DOTS development when the other parts of what happens at Unity have little to do with DOTS and are moving so fast. Moving fast means changes and routines that constantly break. Must be frustrating, especially when the things breaking have nothing to do with DOTS.

So when Entities specific changes to Unity will be kept in 2020 LTS it would make this a more flexible solution.
It's the closest thing to a Unity fork and breaking free from Unity MonoBehaviour and it's development cycle which always seemed counter-productive to begin with. I've read voices very early on who advocated for a fork.

I don't know, maybe I'm completely off.

I'm using entities 0.17 in 2021.1, haven't found anything that's breaking. I think I'm okay with staying in 2020 for DOTS projects when 0.18 comes around.

 

And if that would be the official explanation most people here would understand and support that. It's the lack of explanation that worries people.

I too find this move as is pretty disheartening. I waited for Entities 0.18 to start a new attempt getting into it. Not sure if this is a good plan now. Keeping users in the dark about such important changes gives the feeling of something shady is happening. If it were just bugs or development reality everyone would understand and it would hurt nothing to tell us. If they don't tell it "must" be something else.

 

Reading this thread, lack of communication is oddly similar to the UNET days in 2015.
It would be great if anyone from Unity could open up.
I've already invested close to a year of work into DOTSNET. It's not obvious if I should keep working on it, or not.

If you guys want to sail back to GameObjects, that's cool.
If you guys want to go full on DOTS, that's cool.

Just need to know what to focus my/our time on

 

This is my worry, too. I am a DOTS advocate since the days of [Inject] (2018). We have production code that's dependent on Unity.Entities. Just give us a clear answer. Should we keep investing on Entities or not?

 

I for one see this as the best news this year.

We all knew this was coming, Unity has been backpedaling on DOTS and especially ECS ever since the IPO .

They have already wasted 5 years of development effort on this mess and let's be honest, it won't ever be in a state that people can actually build games in a DOTS/ECS environment.

Some elements are still usable I suppose, For example Jobs is pretty nice, though you could do the same with the .net Task library, Burst is funny, though you have to specifically write code for it and you can't use 90% of the C# language.

As for the concept of ECS, It's pretty much unproven tech to work in game development, after all these Years Unity can't decide on an API, imagine that, it's just not workable, Code is convoluted and hard to work with, a real big complex game is just not fit for a ECS system, and that's fine.

The whole ECS craze just reminds me of the MVC craze from years ago. Forcing some pattern doesen't make your life as a developer better, nor necessary faster code.
You could very well write performant code using a non ECS framework or coding pattern. But getting offtopic here.

No real companies are using ECS because of its development status, and it won't improve, Unity moved (thankfully!) a lot of the developers off the project and to other things.

95% of the paying users of this engine need work done on the actual stuff they use, for instance the runtime (mono has to be upgraded, .net core class libraries and runtime) Unity finally realized to focus on their paying customers and what they actually need fixed.

So I watch with excitement as ECS will slowely be burried and forgotten. and we can move on to an actual game engine we can use to build games.

Thank you Unity management, No shame in throwing in the towel.

 

I think you should check out the video by Blizzard explaining how they used ECS architecture for their game Overwatch. It basically disproves your whole point.

But this steers the discussion offtopic. We actually need more informations about the current situation with ECS, and its future.

 

Slow down there @Vincenzo lol.

"Future releases of Entities will not be compatible with Unity 2021 until the end of the year at the earliest."

Q: "Will future Entities packages still be released?"
A: "Yes, Entities 0.18 is on its way."

Some people are not even bothering to read? They are still working on entities, and have not indicated that it is going away. This post is about release management of the packages with unity versions.

My take is, I'd really like to use 2021, so that's a bit of a bummer having to wait until next year. Things like still being stuck on the package version of UI Toolkit sucks, as upgrading is harder the more use of UI Toolkit you have in your project. Also, bugs and features .

But I'm still looking forward to new Entities releases.
But yeah, expected a followup post from unity by now lol. People freaking out haha.

 

Overwatch is the only production game that used ECS, and there have not been any since. and if you talk to the individual developers about it, they are not convinced that they would keep using the pattern for all their games, and also talked about how it worked well because of their large team size, but also added a lot more development time.

Also you just misread the announcement.
" at the earliest." Basically that means there is no date.. and unity officially already told that they downsized the ECS team a lot, and if you talk to internal Unity people you would know what I know, ECS is going to be slowely but surely die off.

 

As long as Unity isn't dropping ECS than it's fine
Unity 2020.3 is "usable" for me after they fixed ambient light for the Hybrid Renderer
Audio can be worked around with hybrid component
I don't think I can go back to writing OOP game code anymore.

And Havok Physics is too good to pass on.
Actually I was seriously considering switching to Unreal, last year
But unity DOTS with havok made me stayed.
Unreal's new chaos physics is still a mess atm.

 

They will not drop it, that's not what they're saying in the first post.

If they drop parts of DOTS, after they pretty much halted development of other parts of the engine because of it, they might as well shut down the company.

Do expect them to be really late (which is kinda implied in the first post), do expect the first release to be disappointing. <- Going by experience for EVERY feature they released in the last 5-6 years.

 

I hate that you're cheering on the demise of this tech. We are paying customers, too. Some of us depends on it. As a counterexample to your assertion that no "real" company uses it, I'll just show you this. You're naive and I hope that Unity is indeed continuing Entities just to spite you.

 

Big and complex stuff is exactly what an ECS architecture is designed for I think. I wrote an entire physics engine using a custom ECS architecture built on Burst and Jobs, and the resulting code is shorter, cleaner, more readable, and orders of magnitude more performant than the traditional object-oriented architecture I started with.

ECS has its own strengths and weaknesses, just as MVC (or any other pattern/paradigm) does. But imho, dealing with large and complex is one of its strengths.

 

Minecraft (C++ version) uses ECS

 

Doom Eternal is also likely ECS. they said they just have a bunch of jobs don't even have a real main thread just one for OS requirements.

 

So its either you're speculating, talking true BS, or trolling.

First - there's no way ECS would die out. Because that's whole architecture standard. And its not new, or even close to extinction. There is a lot of games that use entities / ECS approach for networking, game logic, UI, visuals, physics, and more.

Moreover, most (if not all) sane and usable engines are using DOD / SoA for internals.
Because its performant and makes most sense.

Second - if you think that package is going anywhere - you're wrong.
If you think that if Unity stops supporting anything - its gone in an instant - you're wrong as well.
There's a big and passionate comunity surrounding this package.

Third - even in this state Entities are better than MonoBehaviour approach. OOP does not cut it for strategies, complex simulation, networking, heck even plain serialization. Code quality and tests with MonoBehaviours? Thought so.

Fourth - you do realize there are already different packages for Unity that are different ECS implementations?
Sure they do not use Burst / Jobs, but they exist for a reason.

 

Why are you people acting like ECS is a new thing? It has been a thing since the late 90s.

AFAIK Thief 1 used it. Dungeon Siege too.

It's not a new pattern.

It is of far more limited use than Unity wants you to think though.

 

@hippocoder please look at a couple of posts above, Vincenzo feels to me like a troll

 

Could those compatible parts of DOTS (Burst, Jobs, Mathematics, Collections) be added to Unity Core?

I can't really see any reason for them to be external packages, especially Mathematics, Jobs and Collections. They could be a great benefit for other projects, not only DOTS/ECS based.

 

If they'll be in core - every bug fixes, changes etc. will require a new version of Unity editor. With packages, they can release and fix bugs often in the same Unity version.

 

I think that would be possible to work if Unity ship the packages as build-in and updates via Package Manager.

 

@hippocoder is back? That's the only good news I see in this entire thread.

 

Just as with any other core Unity feature. New Unity versions are released every 2-3 weeks, so it's not a deal either.

Unless they move to a newer version of Unity, likely making the package incompatible with previous versions. In those cases getting the bugs fixed requires you to upgrade your Unity anyways. Can't see the advantage.

 

It's not. Especially with the latest LTS and TECH stream process changes for reducing engine release count. And focusing on the solidify of the editor.

This highly depends on the package. For example, Mathematics requires zero changes in the engine, if today they'll find a bug in something in the package and will fix - it will work in all current versions, it will work on all previous versions like 2018 2019 2020. Same for jobs (don't mix with built-in jobs in core). Some other packages will be closely tied to the engine, some not. This is the main Unity intention why they've moved to packages. It gives you more flexibility, and more often release a cycle of features. it allows them to untie features from the engine, not all of them but it's much better than nothing. In the case of DOTS it was only a couple of major releases that require you to move on to different Unity versions.

 

April Fool's Day Averyone!

 

This hasn't worked yet though, with almost all packages being tied to specific versions of Unity, our the package creators have to maintain 2-3 versions in parallel for backwards compatibility like text mesh pro is doing.

Maybe one day things will mature enough for this to be feasible, but I'll believe it when I see it.

 

Tons of games use ECS. At Disney, almost all of our games (except casual) were built on a ECS framework (across 3 langs/platforms over the course of a decade). I have even worked on ECS flash(as/air) games back in the day. It is not a new thing.

 

If Unity is unsure about DOTS, I don't mind an open discussion about what are the other ways to make Unity performant by default, but this kind of posting saying that "hey stay on 2020 LTS for now if you're using Entities package (...) I will leave the thread open for questions, but please understand that this is the information we can share at this point in time" is truly some top level PR bullshit.

Can't we just have a nice conversation channel between game developers, tools developers and engine developers?

This is the first time in my 10 years of using Unity that I don't know where approximately the engine is going. How can a business navigate with such turbulences? Even if it is clear that DOTS should not be used in production now, certainly there are companies like mine doing R&D and taking some risks to push their games higher on the quality ladder. We knew that using HDRP + DOTS was going to be a bumpy road, but when we started our project in 2018, we thought that both were clearly going to be part of Unity 2021, so we decided to jump on the Unity performance and rendering boat.

As in any risk, we know things might change drastically and mean big changes on our end. It is part of the game. But now we're reading this and we're just really not sure what to understand of it. It would be nice to have at least some (1) honesty / transparency and (2) some form of predictability. When we jumped from Unity 4 to 5 and adopted Enlighten and PBR when they were in preview / beta forms, we took a risk but it paid of as we used that workflow for years.

The question is: What is the highest quality, most performant way to make a game in Unity if we were to start a project now and ship in 2024? Can Unity even answer that?



Can we get an updated timeline like the above, if there are still such plans?

 

the point is not how to interpret unity's words, you should avoid vague speech in the first place, if you did so, please clarify as quick as possible rather than silience or provide another vague speech (or promise) 3 months later.

 

Agreed. Assuming there is a straightforward, stability-based reason for this, a more professional way to handle it would have been:

1. In 2020, realize Entities won't be compatible with 2021 Unity versions.
2. Make an internal company plan for when Entities would be compatible with Unity Tech releases again.
3. Before Unity 2021.1 is released, make a company blog post announcing this, with information about why, and when it is planned to be supported again. Clearly tell customers that ECS development is not in jeopardy. This should come from people with decision-making power at the company, so there is more reason to believe it.
4. Monitor the comments, and respond to pertinent user questions.
5. Point users to this blog post through other media, like user email and a post in this forum.

Plain and simple, what's happening now is unprofessional behavior. We can be huge fans of Unity (which I am) and still call this what it is.

Unity is fond of saying that it wants to act as part of our engineering teams. Can you imagine if you were an engine engineer at a game company, and you communicated to the rest of the team in the way they are doing right now?

 

I agree with the above post, it's a lot of hindsight though. You know how it goes in development.

I'm waiting patiently for more info from the Entities devs and why we should be excited again. There were so many things added and changed for the better, yet the lack of enabled/disabled state which is so integral to the performance is taking way too long for what it should be. At the beginning I thought it would be something small and quickly added but the more time went on, the less I understood what's the hold-up.

What I'm really interested in, why does Entities depend on engine changes so much?

 

The whole enable/disable state on everything that was originally announced never sounded like a good idea to me. For most projects it's probably fine but I really don't think it scales that well when you think about it. If this was simply a global thing where you bool checked on every query (job) for every entity it ends up being a lot of checks.

(pure speculation) As for why it depends on engine changes, my guess is it's likely to do with them working towards rewriting the entire code gen to use source generators instead of IL post processing. I'm somewhat surprised they didn't choose to abandon 2020 instead of 2021 considering entities is still a preview package.

That all said, considering we're stuck on 2020.3 at work i have no complaints.

 

While I agree that the way they are handling this isn't optimal, I don't think this is as simple as people realize.

There's not a lot of incentive for Unity to post updates if people aren't going to read them anyways. Count how many posts in this thread suspect Unity is quitting Entities (they clearly are not if you actually read) to see what I mean. Had this thread not blown up with such chaos, I believe we would have gotten clarification by now.

Also, while I do think this could have been announced more cleanly, I don't think it could have been announced any sooner and with any more details. As some of you know, I pay really close attention to the release cycles of DOTS packages so that I can ensure rapid patch releases of my framework with the DOTS releases. You may recall Unity had a lot of trouble with "shipstopping" issues between when the release notes for Entities 0.17 was first posted on this forum and when 0.17 actually released. From the various posts from Unity on the matter, it seemed there were several QA cycles that failed before one was finally accepted and released. And from other posts regarding Entities 0.18, I'm seeing the same pattern with the same interval between updates, this thread being the latest. So while this is speculation, I believe Entities 0.18 was going to be out last week if it passed a QA cycle (which I don't think was the first for 0.18), but it didn't, and the team realized they needed to change strategies if they want to make more progress. I don't think they have fully solidified that new strategy, but they knew enough to warn us about the incompatibility with 2021 moving forward. They just happened to word that warning cryptically.

So yes. Unity could be better at communicating. But that doesn't mean we as a community can't improve either.