Feedback DOTS Sentiment?

Bit of a weird post to write but as an active member on the forums and Unity discord, as someone working on a dots asset for the store and as someone who wants to see DOTS succeed and thrive, I feel compelled to write something.

I know there is a blog post/roadmap for DOTS planned - it really can't come soon enough.

This is all very anecdotal and my personal pov:

From people new to DOTS there's a lot of:
- "I've installed 2020.1 and enabled experimental packages but I can't find Entities"
- "How do I make something collide" etc
These are basically all fine - a lot of experienced people there who help take people through the steps and a community wiki they've started.

From people who haven't tried it out:
- "Oh I heard they're stepping back from DOTS"
- "Typical Unity, they marketed it like crazy but haven't delivered"

From people experienced there are *daily* occurrences of:
- "What is actually a good pattern for working with prefabs?"
- "How do we animate anything other than a cube?"
- Almost everybody likes the idea of subscenes but can't use them in practice
- People trying to find a combination of "Convert & Destroy", "Convert & Inject", Subscenes and runtime conversion to give them what they need to move forward.
- "It's all really buggy"
- "Yea, there's a lot of good stuff but definitely don't touch it if you want to make a game in the next few years"
- "The demos are all stuck together with duck-tape"
- Megacity doesn't work with any packages from the past year+
- "It's shocking how little Unity have achieved in the last two years"
- "I've given up and gone back to MBs"
- "It's a nice toy but you shouldn't use it for anything serious"
- "I've written a completely custom everything and only use Unity for the rendering"
- "The DOTS editor they had for Tiny was great, I still don't understand why they abandoned that"
- Generally a huge amount of frustration and feeling that progress has been *really* slow
- Rendering - From a user perspective it's really hard to feel this is making the progress it should be given its priority and of course this bleeds outside of DOTS.

I should mention there's also a lot of positive discourse about networking, optimisation strategies etc. but they tend to be re people making their own engines rather than using Unity's.

To be clear, I don't think the above is at all a fair overall assessment. I also don't think Unity/DOTS is for everyone. I am very sure the team has been working incredibly hard and believe that right now Unity's undertaking a set of mammoth tasks.

The fact I feel I need to post something here is the issue. It's about communication. From where I sit (a Unity & DOTS advocate) there's a swathe of negative sentiment. I think this is at least partly known, why people looking to get into dots struggle to even find it now and the reason for the planned post. Yet to a degree I feel Unity must be unaware of the extent given how long it's taking to publish anything and the past year's practically radio silence when it comes to "the plan"?

If there have been avenues explored and dead-ends hit, it would be great to hear about those! It would really help to feel like we know what our engine team is up to and what they've learnt along the way. Ideally more than once every few years.

I hope other people share their own takes here and I'd love for the majority to disagree! Please point out blog posts from the DOTS team I've missed, tell me about game studios that are chuffed with how things are going etc.

Edit: Wanted to reiterate something GliderGuy said - DOTS has massively elevated my technical understanding and capabilities as a programmer. Lifting up a whole community via this technology is massively impressive to me. I'm hugely grateful and it underpins my advocacy.

 

Same experience for sure.

The DOTS effort seems to have had fairly inconsistent messaging which seems to have created a range of expectations in terms of completeness / functionality. You hear everything on the Discord from "I heard Unity is going to switch entirely to DOTS soon?" to "I heard Unity is abandoning DOTS". Definitely mass confusion around it.

 

This is all exactly what I've been seeing, for new devs and experienced devs. The one thing I'd really like to add is my workflow makes it impossible to convert everything with ecs. Based on earlier news posts, I was expecting the conversion workflow to become "seamless", which I assumed would give me some sort of path for converting UGC within assetbundles. which I'm not any closer to that, which totally locks me out of Unity.Physics or havok physics (which I'd love to use). I've rewritten my dots/ecs based game five times at this point, at each major point of change unity's done. With each iteration, the framework does get easier and faster to write in, but at the same time, it feels like we're not any closer when it comes to actual gameplay code. Why are reactions / event systems so manual still? Why does rendering break skeletal meshes? Are scene based animations going to be supported at all? - something all of my users mods use.
I've been trying to finish this game for two years now, and it keeps constantly feeling like it can be finished with ECS/DOTS at the core (not rendering or physics) but even still, its death by a thousand cuts if you don't do everything in ecs. A lot of this was on me for choosing to use it in the first place, but I had planned on being in dev for two years, and unitys roadmap looked like it was going to be much further along, as the game would be nearing finish as well. This bet was wrong as it seems like we're not much further along than 2018's for each jobs.
I'd also like to mention that multiple ecs world support is still abysmal, and requires a lot of manual work to work. Plus conversion workflow is built around there only being one true world.

 

Everything I provide here is from the perspective of a programmer/software engineer. Take with a grain of salt.

tl;dr: Entities has the makings of a great refresh for Unity, but the handling of the systems built on top of it is disappointing to say the least.

As a developer who is used to bootstrapping a lot of the stuff they need from the ground up, I really appreciate the depth of control DOTS gives. The APIs, likely a product of being in perpetual early release, give extremely low level access to almost every facet of DOTS. For experienced developers with a whitebox mentality, this is great.

What isn't great, for experienced and novice developers alike is that many APIs are still super sharp and poorly documented. Tribal knowledge transferal via forum posts and Discord messages are not documentation. I have found myself spending more and more time digging through the forums and hounding questions on the official Unity discord, than I have actually spent implementing or experimenting with those solutions.

For the more novice developer, even the toy examples are set at a high bar. Going wide across all worker threads requires creating jobs that are adhere to Unity's mutual exclusion model for threadsafety. While the safety system is in place to prevent mishaps, it never explains why these are a hazard. Novice/Junior developers may end up spending countless hours banging their heads against the engine unsure why their code is breaking the safety system. Likewise, the DOTS Physics example for making a simple sphere cast uses unsafe pointers and less covered aspects of C#. Compare this to the rather simple raycast/spherecast tutorials shown for non-DOTS physics, and it significantly raises the minimum knowledge required to develop. If DOTS is the future of Unity, this initial complexity is antithetical to democratizing game development. You should not require a BS in Computer Science just to get started.

As for the feature set of DOTS itself, the core Entities, Burst, and Collections packages is rather solid. There are some bugs and definitely quite a few performance issues (not sure if they've been addressed in versions after v0.11, or if more have been introduced since). It feels more beta/release candidate quality than most of the DOTS packages out there. To it's credit, it has some really powerful low level features that make it great for hand-rolling your own solutions. Having multiple worlds and being able to efficiently snapshot the world at a given moment has made implementing rollback netcode trivial, for example. There are still a few design decisions (default system order, fixed timestep approach, etc.) that I personally find odd, but otherwise they're already fairly well formed packages.

The same cannot be said of the other DOTS packages. Animations, Audio, Physics, and particularly the Hybrid Renderer are all in varying shapes of unusable alpha to barely beta:

• Animation is extremely convoluted and lacks even basic documentation. If the goal was to get developer feedback, not even well informed and tribal knowledge equipped DOTS developers seem to be able to wrap their heads around it.
• Audio doesn't even have a high level AudioSource/Listener implementation yet. I'm resorting to pooling AudioSources in GameObject land and using AddComponentObject to control them from ECS.
• The Hybrid Renderer has such a poor compatibility matrix with the built-in and the two available SRPs, it's laughable to even consider it being a viable renderer for most production use cases. The fact that the V2 renderer cuts support entirely for the built-in render pipelines makes this edge even sharper.
• Physics is workable if you delved deep into the examples. There are still some serious performance issues due to the design. Building and Stepping the physics world is consistently the largest part of every game tick I have, even in an empty world in a release build. This definitely is in more of a workable early beta over some of the downright unusable packages in this list.

Entities was promised to be in 1.0 as of 2020.1. Now we're on the border for 2020.2 and the 2021 release cycle and it's clear that it's been deprioritized publicly. It's understandable that these are indeed pre-release packages and there will inevitably be sharp edges and API churn, but cases like the Animations package being public but nothing more than an unusable tech demo benefit neither Unity nor the developers looking for a solution.

 

After reading through the above posts (@June1111's really resonates with me) I have been compelled to throw out my two cents.


[TL;DR] Project Tiny's C# Update which caused massive upheaval, told the world that even the Pure Dots Runtime was now subject to the new Authoring Component approach, of which sent serious waves out that DOTS was going to be forever tied to the old Unity instead of being its own beast, in addition to that it wouldn't be ready for the masses any time soon.


From the beginning of using DOTS in the September of 2018, I was absolutely hyped. There were so few resources to learn DOTS back then (everything would get deprecated so fast, and new tools had no documentation, EVER) but there was this whimsical, cutting-edge, fresh feel of: "I'm making a game in a new way! And in Unity's new way!" And it was really exciting despite all of the pitfalls that came with DOTS at its early stages.

It was until around September of 2019 when something just... snapped... And, it snapped really badly.
The day Project Tiny lost what made Project Tiny Project Tiny was the day a signal went out that things were changing, and priorities were shifting focus.


If y'all can recall — Project Tiny was a beautiful, little Pure-DOTS Runtime that came with a Pure DOTS Editor of which allowed you to make playable "ads."
This editor — and the way Project Tiny handled authoring DOTS Components and Systems — was simple, but it also felt fresh and the right way to work with ECS. While it did need some improvement when it came to scalability for larger projects with big Component counts (and its workflow could have been improved) it felt like Project Tiny was a small glimpse into the Pure-DOTS future of Unity, and It was honestly truly exciting.

Everything seemed great! ... Until the both long-awaited (and now dreaded) C# Update for Project Tiny that destroyed everything that made Project Tiny what it was and with it (what felt like to me) the future of DOTS (at least in the short term).

The massive C# Update promised the one thing everything wanted — C# support — but it also changed the entire workflow to a Hybrid DOTS subset of Authoring Components and Converting GameObjects to Entities. The change was so massive it destroyed much of Project Tiny's original community of early-adopters. And now the Project Tiny forums feels like a barren wasteland, with half the Google results pointing you to the ancient, yet innovative, version of Project Tiny that no longer exists.



To me, that is when DOTS started to head down the path of: "This will not be ready for indies in the next four years."

Don't get me wrong, I am a huge fan of DOTS.
But when it feels like a huge bandaid is placed on a problem (Authoring) — of which killed off a community and eliminated the only way of working with DOTS in the way that was originally intended — I just can't feel anything but sad that this is the short-term (heck, even long-term) direction Unity has chosen for DOTS.

So after I finished my little Hybrid ECS project, messed around with DOTS for a while longer, and tried out the new version of Project Tiny — all I can say is, I'm back to MonoBehaviours, and I am disappointed with how the cookie crumbled.


I do not want this to come across as a "shame the DOTS team and their affiliates" post, because it isn't.

I have learned so much from the two years I spent on the cutting edge. I have become both a better programmer AND been spoiled by some of DOTS workflows. Working with DOTS has changed the way I write code, and taught me what true componentization looks like. Honestly, I don't regret a single moment of working with DOTS for two years despite the struggles.

But in the end... I can't help but feel like things could have went better.
And I wish they did. :c


EDIT: Not to mention when the C# Update hit they also removed a ton of Project Tiny's core features (such as 2D support)... Which didn't help community retention.

 

Multithreading is the future.

I am happy Unity is working on this, and is also the main reason I am still using Unity for my gamedev. :3

 

So, DOTS covers a much wider spectrum than just ECS. I can echo your sentiments about ECS -- I've spent probably a combined a 100+ hours trying to get something working (basically, spawning props from prefabs that should be visible in both the editor and runtime) and have come to the conclusion that what I'm trying to do is fundamentally incompatible with the way ECS is laid out, and any progress I've made is extremely hacky/buggy. However, jobs, burst and unity collections are all incredibly solid, and very useful on their own.

I think the best path forward for most devs is to pick and choose the pieces of DOTS that work well in their project instead of trying to convert their whole game to it (unless you're a big studio with the $$$ to invest in writing all the tooling that Unity hasn't done). There are some genres of game/simulation that fit naturally into pure ECS (bullet hell/space shooter come to mind), but most projects can benefit from taking the slowest/most complex parts and isolating them into jobs.

All that being said, I have a much more positive view of where ECS is going than URP. URP launched out of preview without support for very basic things (half the assets in the asset store, speed tree, point light shadows, ambient occlusion, etc) *and* with worse performance than builtin. There's a ton of very good reasons to jump onto ECS right now (even though it's in preview), but the only practical reason to be on URP is if you need shader/vfx graph.

 

For sure agree with these.

The code in the demos is just generally bad, most look like they were given to an someone who's only been coding for a year, or rushed last minute. At least they exist I guess.

Megacity didn't work for me in like, the very next build after it was released.

I feel like unity has gotten a lot done on the core of DOTS/ECS stuff, but mostly only work on things they need to get the core working. There should be more work on the nice-to-haves(overloads/apis/etc) and conversions.

I keep having the problem where I go to build something, then realize Unity still hasn't implemented a feature/api and I either need to: A: Implement it myself. Or B: Go work on another project.

We waited for nearly 2 years for NativeHashSet, despite people asking and implementations from myself and others floating around. More parallel collections in general would be nice. I'm still waiting for DOTS Animation curve(something really useful outside of animation), CharacterController, IBuffer conversion for Entities, some basic mathematics conversions/methods are missing(math.approx?). (Animation curve may be in the animation package, but I've heard nothing good so far) How long did it take Unity Physics to move to a fixed time step? A year?

Despite this, I still think DOTS has a lot of potential and I'm not going to give up on it, my project is only possible with DOTS and I love the way of writing code. It'll get there eventually, it's just annoying to have to choose to turn around or build a ramp around roadblocks that shouldn't be as prevalent at this point.

I don't really have much to base my opinion on, maybe Unity really is working hard and can't afford a single person to work on smaller things. But it sure feels like more could be done to help the experience, especially when something is missing, and when you come back almost a year later, it's still missing. Or at least communicate more about the roadmap. And I really don't mind API changes at this point as long as there is a reason.

 

I just want to know what Unity's position is. The recent roadmap blog post's exclusion of any mention of DOTS other than "we'll let you know soon" is unsettling. Sometimes (most of the time) you need longer than you thought to get things right. Understandable. But, I'd like to see a little more transparency. Feels like they're holding back some info right now while they figure out how to market their next message or something?

 

My only issue with dots is that I keep over optimizing everything before I get anything finished because how easy is to fall in the optimization rabbit hole.
I am sure I can use it for my game that I plan on releasing somewhere in 2021, I don't need to use it for every single thing after all, but I've been attempting to do everything DOTS first.

 

For me it has been in areas where I am hardware bound, like on a HoloLense. IJobParallelForTransform helped optimise some visualisation demos and menu setups, as unfortunately moving an entire project to ECS for this now seems to be too early, and I can't seem to get any existing ECS demos to run on the HoloLense.

 

Let's be honest here guys. Somebody has to say it. I hope the higher ups at Unity will read this and take it serious.

It's time to admit it my dear friends at Unity, I love you guys, and My company and many other people I personally know that are running their livelihood, companies, and production games on this engine all agree, they love Unity!!
BUT.
You guys went off to the wrong track here...
It's time to admit defeat, throw in the towel. Give up on DOTS. Give up on ECS.
It is sad to say, hard to admit it. But it was a giant time waste but it's not too late to turn this around.

Fire the main managers and directors inside unity that pushed for this technology.
Move the good engineers to other projects within the company, let's get this Unity engine train back on track!

I have been working with this engine professionally for 10 years, I have a lot of contact in the industry with companies that are working full time on production games on Consoles, Desktop and Mobile.
Non are happy with the direction Unity took. Non are using ECS or DOTS.
And they ensured from any conversation I had with them on the topic that they probably never will use it.

I personally know of one company that invested 2 years, with 20 people building a game on DOTS and eventually gave up about 3 months ago and started over from scratch in Monobehaviour, because they simply cannot keep up with the changing framework, and the general lack of functionality to do anything within the Unity engine, most API is not accessible, nor thread safe.

Dots is seen as vapourware, by the entire industry I have contact with. Let that Sink in. No professional wants to touch it. EVER.

The whole Unity engine, that people love, and use is under threat!, it has not seen any significant updates since 2017. since you guys put all your eggs in this basked called ECS, this was a giant mistake.

Right now you guys need to step back, Pull in the reins, and start over, Fix what you have, and don't introduce this broken system that is called DOTS/ECS, it was a mistake.

When you throw out 85% of what is C#, then call it HPC# and expect people to switch to it, you did something terribly wrong. You can't be better engineers as the guys at Microsoft that are outperforming Burst code with a JIT with a full C# framework. in their latest instalment called .net 5.0

When you ignore all the real issues companies are having with your engine, in favour of focussing on the light at the end of the very long DOTS tunnel, you are forgetting what all your customers are using. The Unity engine, With it's great features, of fast iteration, easy editor, build in features.

You guys completely neglected features like Networking, the DOTS networking is simply a joke.
You guys neglected the Build-In Render-pipeline, URP is still not stable and still has no feature parity and still is not even significantly faster...

You guys completely neglected the terrain problems we are all suffering with since Unity 4.

Asset developers are what kept the engine in shape, but the quality is hit or miss, and they are all massively starting to quit the asset store, because the support for the new render pipelines and other shenanigans is impossible for them. This is a big brain-drain.

You guys screwed up. BADLY. and it's on the worst moment too, Your competition is not sitting still!, they are investing massively in tools and features game developers actually need, and more and more I see companies switch over to Unreal. or other competitors and retraining their workforce. This is a wake up call guys. get on it.

Bring back the Unity we used to love, Easy to work with, Well designed standard features.

You guys sold everyone on an Idea of DOTS and ECS, but it's not bringing anyone here actual progress in game development, or even simulations.

You don't need DOTS or ECS to make performant code, or a performant game, Nor do you need it to make multi-threaded code. Believe me, I know, I am an optimisation expert for Unity Mono runtime and Il2cpp.

Unity, Focus on what is important here, your paying customers, that make actual production games. That pay your salary.

 

Just wanted to quote that as it seems to be a topic that keeps coming back now and then... Unity advertises that DOTS (more specifically ECS) is not production-ready, if a company invested 2 years and gave up due to changing framework then, well, seems like someone did not made some basic research before choosing the main project's technology.

 

After 3 years Unity still has a half-baked 'ecs' engine that is:
1) Full of bugs
2) Not complete
3) Impossible to build a game in.

Additionally:
1) They have missed almost every deadline they have set (sometimes by years)

 

I agree that there are some areas where I would really love to see production and communication improvements (hoping to learn more with that blog post).

But I just want to say that it’s not so simple as this outlook. The principle truths behind DOTS haven’t changed:

1. single-core CPU performance has largely plateaued.

2. multi-core CPU architecture is seeing strong improvement.

3. most game code (going back 20+ years) is still single-threaded, and there’s a huge multithreaded performance ceiling waiting to be exploited.

4. Most game code is not very well CPU optimized. There are huge performance gains available for games with CPU optimized code.

5. Writing multithreaded game code is very hard, and it’s Unity’s goal to solve these hard problems so that their end users don’t have to.

The bottom line is, these fundamental truths are still true. So even if there have been scheduling blunders or issues with Unity’s choice of how to approach DOTS (for example, scrapping the Tiny editor), multithreaded, CPU optimized game code is still a very logical direction for the future of game code. There are huge gains to take advantage of there, and much less to be gained by sticking with a single threaded, OOP approach.

so while I do have complaints with the messaging and timing around DOTS, I’m very, very glad the engineers at Unity are taking on the challenges of DOTS. I strongly disagree with (and am saddened by) Tim Sweeney’s view that multithreading is only suitable for engine code, and not gameplay code. I think that’s a very unfortunately view, and maybe one that’s influenced by Epic not wanting to take on the engineering risk of figuring this out.

All in all, it seems like DOTS (and ECS specifically) have turned out to be waaay more costly of an undertaking than they had originally anticipated.

I am very glad that Unity is taking on DOTS. I just hope the company, engine, and customer developers can survive the next several years of transition!

 

DOTS is really fantastic. I have a sense that I can make anything I want using even current version of it. I couldn't even imagine how good it will be in the future, if UT will not abandon it.

 

There are simpler tools that took longer than that to be fully complete, the issue here is just that they showcased it too early.

Being not complete and with bugs is the clear definition of a "preview package" or "not production-ready" for me.

About being impossible to build a game in, tell it to @eizenhorn haha

For the timeline, we are all developers and we know how those things are, what is lacking here is communication about the current roadmap of DOTS (as it seems that Unity is trying to avoid to talk about that in the last weeks).

Even the overall Unity roadmap ( https://unity3d.com/pt/unity/roadmap ) is outdated, they really need to take a look on that before anything else.

 

Abandoning is not the intention of this thread. I'm just frustrated with the state of ecs and how it hasn't been communicated well with what's been going on. I remember posts saying, just wait till next unite, something big is on the way, and getting mega city, physics, havok, or fpssample. Always felt like updates were only coming in relation to a major marketing event. Which is what you would do if you wanted to drum up hype for a new feature people can use. All the frameworks are still really rough around their edges. While yes you can put together something workable with them, its labor intensive, and introduces uncertainty to your codebase on if that package is going to see major changes, which ripples out though your codebase.
But again, that's on me for choosing to use preview software I guess. Now to throw away 2 years of my development time and sanity, kidding of course.

 

Throwing ECS and DOTS into the dumpster IS NOT the answer here.

DOTS has shown us what it's capable of in the right hands. It is truly a powerful framework that delivers the highest performance possible that the Industry has ever seen... on every platform.
It has succeeded in its promise — performance.
But as of now... The "by default" part almost feels like a lie when you have to work through extra boilerplate and manually implement half the features you would need to make a real game AND make it all Burst / Job compatible if you want the extreme performance it was advertising.


ECS is in a very weird state of existence right now.
It feels mixed with GameObjects in a way that was visioned to please non-DOTS developers, but in actuality it pleased nobody and made more people lose hope in DOTS because it appeared that Unity was backpedaling onto its previous foundation again.

If ECS wanted to thrive, it either needed to be the Unity 2, and developed in isolation, or be a more friendly environment and compatible with the Original Unity.

If ECS went with the "Unity 2" approach, it would have had the benefits of:

1. It would tell the world DOTS (and ECS) was a separate entity from the previous Unity. And that it was NOT READY for anything but messing around with it. (Preventing people from jumping on the train early and getting burned).
   
   
2. It would have allowed the DOTS Team to not worry about compatibility or usability from the start. They would have been able to do whatever they wanted for a good two years without backlash, and once they were ready to create appropriate authoring workflows and ways to work with ECS in a realistic way, they could have asked the community what they wanted and needed.

If ECS went with the "Original-Unity compatible" approach, it would be in a better version of where it is now — which is where only using a portion of the DOTS's core systems for a game allows a game to succeed while getting performance boosts. This has the benefits of:

1. More existing games could get the performance boost that DOTS promised.
   
   
2. DOTS would have been more geared to be usable with the Original Unity Engine, allowing it to be more easily used by the masses.
   
   
3. DOTS would have had feature parity with MONO, since it was a performance extension for it, rather than being a replacement.
   
   
4. ECS would have had been built to work alongside MONO to assist it in rather than replace it. ECS would have had more systems to communicate to MONO land, allowing Entities to very feasibly interact with GameObjects in every game that they were in.

Unfortunately, a different route in-between both routes was taken. Which has both stunted progress, confused developers, made people question Unity's decisions, and made others entirely jump off the ship.

Throwing DOTS aside and saying it was a two-year mistake is flat out wrong.

But I believe the winding path the ECS team took to get where they are now is more than questionable. And, luckily, I think they know that.

I have seriously high hopes for the DOTS (and ECS) future, which is why I truly hope the DOTS Blog Post will clear up everything.

Don't disappoint me Unity.

 

tl;dr:
I am extremely excited about DOTS, but right now, as an observer, I have a little bit of fear that DOTS could be in danger of being abandoned because the task of converting the Unity ecosystem to it would be too huge, too risky, and too confusing for users. It feels like we're at a bit of a crossroads. On one hand; splitting Unity between monobehaviour workflows and DOTS workflows seems like it would be a bad idea because it would make everything too confusing and it would divide the community. On the other hand; fully converting Unity to the DOTS workflow almost seems like an unimaginable task because of the sheer amount of work needed and the necessity to not break monobehaviour projects and make it accessible to everyone. I could easily see this taking another 3 years and it's very hard to tell where this is going. And on yet another hand, going back to the legacy tech stack, which was too limiting for many of us, would be a huge disappointment

I don't even really know what to suggest as a solution, or what I'd want Unity to do. It seems to me like this is just a really difficult situation that really just needs tons of time & resources....

I think keeping us updated on what work is being done on DOTS would help a lot. Maybe it's just hard to see what really got done in the last half-year or so because all we see is minor package updates and such. We need to be reassured that DOTS is on a steady path to completion and that it can be a viable standard workflow for Unity

Spoiler: Original post

My perspective is:

I really like DOTS as a paradigm; it makes it really easy to reason about your project's code architecture, easy to avoid spaghetti code, and easy to avoid spending months optimizing your game. I definitely want it to succeed and eventually become Unity's default way of working, because for me, it makes development WAY more pleasant

Unity says DOTS is experimental and WIP, so for now I fully accept the fact that bugs happen, documentation is spotty, features are missing, time estimates aren't perfect, etc....

But what I'm worried about is the accessibility side of it, or just if DOTS has a real future in general. I often wonder if DOTS will be condemned to be a thing for experts only, and I worry about this because if the audience for DOTS is too small, the tech could end up becoming an after-thought in the long run. I think what I'd like to know is if Unity really envisions a future where DOTS is the standard and is very easy to use. If making it easy to use means that user code won't be multithreaded, that would be totally fine. As long as high-performance multithreaded DOTS code can coexist with "easy-to-use" user code. But there are certain "difficulty" aspects of DOTS that I'm not sure can be solved; like the fact that transform hierarchies or physics object moves aren't "reactive" and changes don't always happen instantly. That's the kind of stuff I'm worried about

I think if Unity becomes split between Monobehaviour and DOTS, it's not going to be a good thing. There should be one unified way of doing things, so that the knowledge-base of the community can focus on one approach. For example, I think the fact that there are monobehaviour physics engines and DOTS physics engines is a big problem. All of unity should end up using UnityPhysics/Havok in the long run (it's not such a big problem that there are 2 physics engines for DOTS, because they are very interchangeable). Besides, I think you would be spreading yourselves too thin if you have to support two entire tech stacks simultaneously.

I'm also very interested in a renewed roadmap for DOTS, but I guess we'll hear about that in the blog post when it lands

 

DOTS is getting better and better.
ECS is at a point now where we're strongly considering porting a major product to it, so please @Unity keep working on it (we are already using Jobs and Burst in production)

It's also clear that many users simply don't have a proper usecase for it, try it anyways and then get utterly confused about the purpose/advantage of it all.

This is a demographic and communication issue and imho the management here needs some improvement.

 

This is about the same concern as mine, the URP/HDRP/built-in renderer stuff already got asset store go crazy with things incompatible with each other because those systems aren't.

I am afraid that the same thing will happen and we will have DOTS and non-DOTS navigation, BT, physics... so basically splitting what was supposed to be one engine (Unity) into 2 (or more) engines - Old Unity, Unity DOTS and Unity Tiny so far.

Once DOTS reaches 1.0 I expect them to take a look at how to better integrate it to the engine core without requiring us to care about if the project is either dots-compatible or not.

 

Making networking dependent on DOTs was a huge mistake. Unity could have made millions of dollars off of a networking solution/subscription service from 2017-2020, but instead decided to tie it to DOTs. Now online games that use Unity with monobehaviors use third party solutions.

DOTS is a great idea, but it should not have been tied to the current Unity stack. It involves rewriting every system from scratch, and should have been forked into a Unity 2.0 with development opened up to the community.

Unity as a business is making the mistakes that are spelled out in the Innovator's Dillema - forcing new an innovative tech to be tied to existing tech, existing teams, and existing profits. If they were to follow the recommendations in that book, they should be splitting their DOTS development into a separate silo'd team with a different monetization strategy. Rather than forcing devs to migrate to the new system (and potentially alienating existing customers), the Unity company should focus on improving the DOTs product until organic adoption grows to a critical mass.

The announcement to sunset the old Unity should be only be made once DOTs adoption reaches 80% or more, NOT 5 years before DOTs is completed.

 

This really sound like some strange subversive post to sabotage DOTS if anything. I can come up with plenty of reasons why someone would want DOTS to fail, but I won't try to read minds.
DOTS is awesome and I am using it to make some amazing stuff very easily, nobody is forcing you to use it, just go back yourself to your unity you love so much, it is still there. Don't even suggest attempting to take DOTS from those who can and want to use because you or your friends can't.

 

This is something I've been stressing about for a while. Mono is several times slower than .NET Core. The reason Burst/LLVM is giving orders of magnitude performance increases over Mono is because Mono is ancient and outdated technology. Microsoft's RyuJIT can vectorize things quite well, pull classes onto the stack (instead of GC heap), and from the tests I've seen .NET Core is very close to Burst in performance, while also supporting the standard library.

EDIT: I guess it might be related to platform support or vendor lock-in. Still sucks that we can't get .NET Core at least for PC (eg editor!)

 

As some of the others have brought up, I get some of the frustration around ECS, but not on DOTS as a whole. We've started using Burst and Jobs in production (though we are careful with parts that's still in preview) and I'm very satisfied and view that tech as quite stable. I really enjoy the tools that DOTS has introduced and how they make it possible to care about low-level stuff while also having access to high-level tools. Trying to learn assembly by looking at isolated code in the burst inspector is, for me, less intimidating than going to IL or the disassembly of an entire program. Similarly, I love having good leak detection as well as a protective safety system. By simply putting things into jobs we've made our codebase way more testable, which is also a pro, and I like finally having a "language" that encourages a data-oriented approach. I don't mind throwing away the parts of C# I didn't use anyway when I gain so much. Though I do agree that sometimes the error messages could be a bit clearer and that the documentation can be a bit too lacking, especially when venturing beyond the "basic" stuff.

I have my frustrations with Unity, but they are not with DOTS, quite the opposite in fact. However, I do agree that it would be good to get some more clarity in the roadmap for DOTS and ECS in particular.

 

One note about this is that RyuJIT doesn't deliver on one of the other promises of Burst: determinism. It's a critical feature necessary for some forms of networking and really isn't achievable in JIT'ed environments due to the impromptu optimizations the JIT may take. While it's been a common repeated ask as to when cross-platform floating point determinism will be available, Burst already supports determinism on the same CPU architecture. Could this be done in C++ with specific compiler configuration tweaks? Probably. Is C# probably the wrong language to expect this in? Probably. Can this be done in some other way (i.e .fixed point computations), probably, but it'd need to recreate the entire engine from scratch sans Unity's renderer. However, the use of HPC# w/ Burst definitely does deliver more than just more modern native vectorized performance.

 

You cannot get float math to be cross platform cross arch deterministic. it simply is impossible unless you go full IEE-754 which means turning off all float optimisations which means it's slower than a Fixed point math implementation.

Any promises Unity made on this are lies, Burst is not deterministic on the same arch by the way.

For this exact reason the guys at Exit Games made a product called Photon Quantum a complete network and physics engine in Fixed Point math, which is very fast and very advanced, supporting full deterministic predict and rollback networking. Full 2D and 3D physics. by the way, they made that in (normal) C#. I judge the chance of Unity ever getting on that level with their stuff 0%, especially considering their track record.

 

This is all well and good, and maybe there's still a place for Burst on job threads. But the main thread, and Unity scripts as a whole, are brought down by Mono, and the deterministic/non-moving GC.

 

I think the plan is to have bursted main thread code eventually

 

V e r y Y e s

[edit] Yes, I am also skeptical about DOTS right now. Reminder that id Tech 7 has all the glory of ECS already implemented. However, it all helps. It is all a step in the right direction.

 

Random forum guy says it is not deterministic. Unity says it is and that they have test coverage for it already.

 

To my knowledge, this is exactly what Burst, using FloatMode.Default and FloatMode.Strict, does. Even then due to architecture differences, you'll not achieve cross platform determinism due to ISA level differences and hardware implementation inconsistencies.

I've confirmed said claims myself already. At least for my use case of platforming + physics. I'm not sure about the future claims about actual cross-platform determinism or other use cases, but I have my own tests that confirm the bit-for-bit determinism on two amd64 machines with different OSes. I'd definitely encourage others to doublecheck this for themselves and add tests to verify it doesn't break in the long term. For my current project, this is more than sufficient, but I agree that cross-platform floating point determinism was a tall promise that hasn't been delivered and keeps get pushed back.

To achieve that they needed to recreate virtually every simulation component in Unity from the ground up, and charge a matching $12,000 / year for access to the technology and comes with CCU limitations. It's impressive work, but isn't a viable solution if it bifurcates the existing engine ecosystem in incompatible ways, requires studios to invest in a dedicated engine developers to replicate this solution, or developers are not willing or capable of paying that for their projects. They also mentioned they required multiple Ph.Ds to develop custom made numerically stable alternative algorithms to overcome accuracy issues with the Q48.16 fixed point format, so it's not all rainbows and roses with fixed point.

 

I agree that fixed point math has tons of problems. Something as simple as a trig function becomes an issue. Historically RTS games have generally used deterministic floating-point math. With a variety of strategies sometimes as simple as reduced precise deterministic rounding.

 

Yup it seems like it . Read their words below

"Deprecate system sorting via virtual functions and direct modification of system list. There are now two new properties on the UpdateInGroup attribute: OrderFirst and OrderLast. Setting either of these properties to true will group the system together with others tagged in the same way, and those systems will sort in a subgroup by themselves. This change was needed to enable Burst compatible systems in the future." - Unity Entities 0.11 Changelog

 

As a casual observer of ECS I am in agreement that Unity seemed to going full bore ECS and pushing it very hard Unite 2017-2019. It was very exciting and I actually had hope that Unity could catch up to Unreal by adopting a brand new core and ditching some legacy nonsense. Then project tiny editor released, and they seemingly hit the brakes focusing on hybrid/conversion approaches instead of making a pure ECS editor/workflows. So now it feels like they’re fumbling their way into ECS being dragged down by their legacy workflows and scripting. I’m sure they will say it was “always the plan” to have conversion workflows but it certainly didn’t feel that way initially. I don’t want them to throw DOTS into the trash, the benefits are still present as mentioned by others. It just seems like since they decided to hybridize the workflows that progress has slowed incredibly in the past year. I wish Unity could have made Unity ECS and started fresh in the future instead of dragging their 100 ton Monobehaviour history along for the ride. Maybe that never made business sense, but as an engineer taking a hard break always felt appealing.

 

Something I don't get in this thread is... how is conversion not pure ECS? Does everyone want to generate their entities by code or something?

 

Yes, Same here I dont get why they think conversion makes ecs impure. Its conversion not interpretation so conversion happens only once then you have pure entities.

 

Even if Unity manages to make Burst code deterministic on the same arch which in theory should be possible although costing massive float performance, It is still useless.

Yes sure, If you build your game for JUST modern PC's....
Though intel vs AMD and Linux vs Windows or Mac probably would still not be deterministic.

But also your entire game has to be burst'ed, which is simply unfeasible.

In the actual game production field you need to be able to have determinism between a Windows client, a Linux server, a Apple Ios Client and a Android Client with some random Chinese CPU like Hisense.

It's pretty much guaranteed you cannot get floats to be deterministic between all these platforms, it simply cannot be done.

The only way forward is a fixed point math lib and physics engine.


A lot of you guys seem to connect DOTS/ECS to being able to use Jobs or Burst, I think we should see these as separate things, You could use Jobs if you need multithreading, it doesn't mean you need DOTS or ECS in your game.

You can also multithread your code without Jobs. usually it really depends on your use case what is the best way to go about things, for instance if you need a dedicated thread that communicates over threadsafe queues. or simple quick tasks that you use the task lib/jobs for.

Also you guys seem to think Burst is the only way to get SIMD optimised code in C#, this is simply wrong, the latest .net from Microsoft has SIMD enabled JIT, and generally runs insanely fast compared to what is used in Unity. For instance for burst you have to use some kind of weird library from Unity, which follows non of the C# naming standards to enable SIMD on your math.
Whilst in the the Microsoft .net You have a math lib provided with full SIMD enabled vector math etc. it's blazing fast too.

Unity just tried to re-invent the wheel and failed, by kicking out 85% of what made C# great.
You can't use any of the C# libraries out there in burst, you are unable to re-use any of your old code, you are unable to use any of the code you find online in C# to solve real world issues. you can't do much really.
it was a bad decision, Microsoft simply has a better runtime today than unity can ever make.

 

@tertle & @UsmanMemon I'm not sure what specifically you guys are referring to that's been said here but the conversion process can include traditional managed components. Systems can run on them too. Afaik having those Companion objects around is called a hybrid workflow (i.e. not pure).

 

From my perspective (which I admit doesn’t have a lot of experience with it) you’re going through additional steps to get to the ECS implementation of the data. If the workflows are GameObjects that need to have their components converted to component data rather than creating your entity archetype definitions in the editor your creating what I feel is a “tacked on” user workflow rather than ECS being a first-class citizen of the editor and embracing the ECS data model.

I’m sure conversion is passable, and after conversion it runs as well as a “pure ECS” would. To me it feels like more runtime work, further distancing you from the actual implementation. It is desire of making ECS data alignments and queries as primary citizens rather than secondary/converted workflows from the legacy workflows.

 

ofcourse, burst was needed for dots. Tell me is microsoft's ryujt c# jobsystem aware?? or ecs aware?? or unity's new Data Flow Graph(DFG) aware?? or future data oriented solutions aware?? will it work on non-jit platforms?? i like unity math library because its like hlsl math library, is naming much of a problem?? or does it compile to machine code??.

 

I actually didn't like the lowercase math convention initially, IIRC the reason for it was something like "advanced coders who write hlsl code will likely use dots/mathematics, and some parts were converted from shader libraries", but this isn't hlsl, it's C#. Is it actually worth randomly bringing up as a complaint? Not really.

 

Appreciate all the responses people have taken the time to write here. Lots of good points made.
Some of the criticism is certainly valid but not all that constructive?
Any thoughts re suggestions / positive requests of Unity?
Specifically re DOTS, specifically without much additional overhead what are things Unity could be working on to help us?

As for me, I hope the coming dots post acknowledges and proposes a strategy to both: deal with this tide of sentiment and, help smooth the rough transition period over the coming years.
Beyond this, I would like to see a commitment to more regular communications.
My preference would be in the form of something like a monthly team blog.
It would give me more confidence to see a much more detailed DOTS roadmap that's kept live and updated - not a screenshot from 2018.
'Internal experiments' has been alluded to a lot - I for one would really appreciate learning about what some of them are and conclusions drawn. I realise that may invite unwanted discussion but personally I'm fine with this being a one-way communication and comfortable with Unity not fully justifying every decision if it means more visibility.
Other thoughts?

 

For the average person that wants to make a game, performance of the engine is just expected. A lightweight build is just expected. Using the Editor should just work and the complexity left to the people responsible for the Editor's output working well. You can already use Unity as it stands and have 9999999 tutorials and snippets and assets and whatever else to do pretty much anything you could possibly want. I think with so many people here liking it Basic, writing something in Assembly by comparison just has no appeal. That could just be my impression because I'm reasonably comfortable with the existing structure and I don't know how to do anything with dots yet.

I do think it's great there's an option this like for people with the desire to squeeze every last drop of performance possible, spend a week optimizing something that takes 5 minutes otherwise, why not.. I've done that too and it is truly satisfying when you're in the mood for it. It's also great there's an option for the drag-and-drop demographic (Visual Scripting). But... I'm only so enthusiastic while it's not taking a significant amount of Unity developers' time away from the needs of the majority. I think most of us would benefit most from improvements to the core product or having issues resolved.. not to state the obvious.

That said, I am looking forward to being as excited about this as some of you seem to be.. I'll give it a few years to mature while I continue with the current system, then if it all works out there'll be something next level to move on to.

 

Ditto on more clear/often updates. We literally have no idea what Unity's plan for the next update is unless Joachim or some other team member randomly mentions an upcoming feature in an unrelated thread, let alone in a year.

 

My main request that hasn't already been mentioned (clear and consistent messaging, regular updates, etc) is direct community engagement in the feedback process. The main issue I have with existing non-solutions is that samples and paltry documentation is not enough to even get the eager early adopter started. If there is such a high barrier for even early adopters, there is no feedback. The model that the early versions of the new Input System on GitHub used was amazing. Despite the workflow of using a git url, it acted as an effective and tight feedback loop. Issues were publicly visible and any early adopter could actively give feedback, ask for help, etc. This might be my bias as a open source developer, but openly engaging the community makes the process much less opaque.

In 2018, I was told that the Unity Companion License does not allow for submitting GitHub pull requests, and this has not moved in the 2 years since. Now there are third-party documentation repos for DOTS/ECS because the existing docs are so obtuse and samples so arcane. At the very minimum let the community contribute to the documentation of more stable DOTS packages.

Another request is to clearly mark the production readiness of packages. As evidenced in my first post in this thread, it's already pretty clear the packages are in different stages of development. Preview vs Verified are good enough for LTS users, but there are quite a few production ready, or very close to it, Preview packages in DOTS/ECS. We have terms for this already in software development: alpha, beta, release candidate, etc. etc.

Finally, internal experiments are great, but if none of them see the day of light, we're left waiting for what Unity considers to be a final solution, which may not even meet the design requirements for some developers. This is how we've ended up with 2 years of silence punctuated by marketing tech demos.The initial experiments in skinning: Joachim's GPU skinning experiments was a great example of this. While it doesn't solve every problem, it provides insight into how to solve these kinds of problems in DOTS, and that knowledge might be what unblocks projects looking to migrate to DOTS/ECS.

Overall, to sum up: be more open with the development of DOTS. If the new Input System's development cycle is anything to learn from, it's that leveraging the immediate feedback, expertise, and breadth of experience in the community ultimately leads to better developed solutions and less negative community sentiment.

 

Seconded. Remember when the unity documentation site's pages allowed user comments? Sometimes I found the most valuable help in those comments. Was pretty disappointing when those comments were removed.

 

For me, aside from more communication/updates/samples, it would be: clearly explaining what the endgame is for Unity and DOTS in the future. In other words: do we expect to reach a point where DOTS physics, NetCode, HybridRenderer, etc... can be used even by beginners. Either through making DOTS code easier, or through making it possible to have DOTS serve as a thing that does heavy-lifting behind monobehaviour OOP code. And can we expect legacy things like PhysX to be removed eventually (or be migrated to a package for long term support) in order to streamline everything and give us one official way of doing things?

So in short, will the entire community be able to transition to DOTS so we all have a common pool of knowledge/tutorials/etc...?