DOTS Sentiment?

Unity Engine
, ,
1

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.

37 Likes
2

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.

5 Likes
3

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.

8 Likes
4

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.

28 Likes
5

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.

9 Likes
6

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

5 Likes
7

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.

9 Likes
8

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.

5 Likes
9

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?

6 Likes
10

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.

2 Likes
11

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.

12

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.

14 Likes
13

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.

16 Likes
14

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)
1 Like
15

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!

29 Likes
16

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.

5 Likes
17

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.

4 Likes
18

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.

7 Likes
19

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:

  • 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).

  • 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:

  • More existing games could get the performance boost that DOTS promised.

  • DOTS would have been more geared to be usable with the Original Unity Engine, allowing it to be more easily used by the masses.

  • DOTS would have had feature parity with MONO, since it was a performance extension for it, rather than being a replacement.

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

10 Likes
20

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

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

7 Likes