State of ECS & DOTS

It's almost like there are two separate factions within Unity, with one running this skunkworks DOTS project.
The other is completely disinterested in this work being completed.
Worrisome signs for ECS:
- Removed from package manager
- Did not get verified in 2020
- Is not on the official 2021 priority list
- The items on the priority list are very much focusing on the GameObject workflow, even though DOTS versions were announced earlier.

So does Unity not plan to focus on this until '22? It's a bad look when they've been pushing this so hard at every opportunity, and then just shove it to side. Let's not forget, ECS + Jobs was the focus of their keynote at Unite Austin. That was over 3 years ago. A 2022 release puts at 5 years from initial announcement. That's an eternity in tech years.

I see glimpses of what might be in the preview packages and project tiny, but at some point I'd expect Unity to stop operating like a rag tag bunch of devs in a garage and more like a NYSE-traded $40 bn-makret cap company and actually ship meaningful upgrades to their customers.

Will the full-on Entities workflow ever see the light of day?

 

I find that the DOTS stack is very much worked on, witness the last release of entities 17 and related packages.
This is basically an entirely new way of thinking. They are effectively rewriting the whole engine.
I don't know when the first unity version was ever released (or when it's development started for that matter) but I don't think we can expect a full feature coverage in just a few years.

As for the road map, it may not be clear in their communication but I think that there are 2 distinct road maps one for the "Unity Engine" and one for the "DOTS stack".

With so much people relying on the Unity engine, they can't just stop everything and focus only on DOTS.

The packages were removed from the package manager in order to avoid misleading teams into starting a project with DOTS without being fully aware of it's current state and feature set.

 

I am aware, that focus on DOTS (before name was even cobbled out), is at least since Unity 5.
That is when since, Unity engine internals star evolving and changing.
Apparently even GO hierarchy trees were changed behind the scene back then, to be more effiecent Or something like that.

As the result we have seen Jobs and Burst released already. Now is entities part, which is still in dev. (preview).

 

I think this is the right approach. Unity unfortunately is considered by many to be a company that releases half baked solutions. So taking the time to make sure ECS is properly ready is a good thing that will hopefully also help change that perception.
I just wish Unity would be a bit more communicative about the state of DOTS. In the last year there was hardly any news about it and it was difficult to tell if any progress was being made at all.

 

Reading in between the lines it appears DOTS 1.0 release now means matching the features of Unity minus prefab workflows.

Really looking forward to it, and it will be worth the wait, but rebuilding all of Unity with a new pattern isn't going to happen this year or next year. Go DOTS team go!

 

Well, you can already use DOTS in production, albeit its somewhat lacking proper integration / default components.
Hybrid approach is completely viable option - authoring components from MonoBehaviours is possible.
Even authoring from ScriptableObjects is possible.

Sync'ing results back to MonoBehaviours might be a bottleneck, but everything except visualization layer can be ECS based already. Arrange correct update order - and you can even use both workflows in same project just fine with little overhead (mainly ECS -> Transform syncs).

Other than that - with 2021.2 there's a significant performance improvements (more burst-able internals), meaning engine is slowly transfering to DOTS.

Also, DOTS getting faster with each release is a good sign of development too.

 

DOTS is already pleasant to use. It basically let's you write ergonomic C in C# with Burst, what else could you ask for?
: )

 

I'm waiting more than a decade for proper and no bugs GameObject prefab workflow.
And I'm still waiting.

 

"There Is No Such Thing as Bug Free Software"

 

I feel benefits other than performance should be pushed as hard as performance has, considering a ton of uses for such a paradigm don't seem like they'd benefit much, if at all, from being grouped in cache efficiently, such as a list of extremly varied entities meant to represent some form of "type", like cards.

But inform us unlearned individuals as to how this can help more simply architect dynamic interaction. Dynamism (emergent gameplay) is an aspect that the players can more immediately and viscerally appreciate. The joy of emergence is far more valueable to players than merely having prettier vistas or more samey objects on screen.

Boids or boid(-like) examples are not enough of an incentive.

 

Danny, that are odd questions. Are you new to this? Just asking.
Especially a genre like immersive sims (Prey, System Shock, etc...) benefits a lot from a data-oriented approach. Both for the programmers (easier to design data, write code, more bug-free) and designers. They perform and scale very well due to ECS.

You are questioning something that will improve all these fields that you mentioned and not only for gameplay mechanics, writing code, designing gameplay, but also graphics, with rendering of millions of objects, animations, etc...

So, what's really left to improve here? I think DOTS covers pretty much all bases even though some improvements might not be obvious.

 

Like most new features in Unity, you give it 6 or 7+ years to be safe, actually it's better to forget all about it, it may never come to happen.
EDIT : I agree with what Joachim said, and hope DOTS workflow will be seamless and intuitive so that the entire user base welcomes it and migrate to it.
Even if it takes some time.

 

I'd say ECS benefits overall coherent experience.

If something is expected to X then that something will do X just like the rest of the world.
As an example, AI won't suddenly break because some unexpected thing have happened.

-- or --

You've got an entity that does X, Y, Z.
And you've already got X, Y logic. There isn't a need to implement X, Y again.
Without overhead of inheritance and without spaghetti code. Reduction in dependencies also help with code maintanance in future.

Moreover, if you write tests, that X, and Y behaviour are already covered by tests.
Meaning you'll spend less time in QA / fixing bugs.

Emergent experience comes from actual system interactions, and they still here.
Randomization didn't go out of the window all of a sudden.

E.g. status effects. Generate damage data with a status effect data. Attach it to the entity that gets damaged.
You can query different components, whether its player, terrain, tree, some random crate or a bird, and systems can run on those queries generating unique interactions.

-- or --

You can also run identical logic on a single query and provide identical response for every entity.

-- or --

Run systems on actual status data and perform some wicked damage combos. Like Fire + Shock == Overload

Those are valid approaches and its possible. Nobody stops you from doing so.
And if you want to implement all of those after some time, your code won't break. That's the beauty of ECS. Interaction options are limitless, and the only barrier is your imagination, creativity and time available.



TL;DR:
ECS brings lots of benefits, and it requires a bit of learning. But its 100% worth it.

Most of folks bashing ECS in this thread either never tried learning it, or failed to do so.
Which is expected, because it requires different approach and time to switch mindsets.

To those willing to try it - I'd recommend Unity v2020.2 + newest ECS version + DOTS stack.
Read manual, ask on forum if something too hard to understand or not working as expected. Its pretty much viable option on par of MonoBehaviour approach nowadays.

Or use best of both MonoBehaviour and Entities. You can do that too.
SystemBase codegen now supports querying managed objects attached to entities via .AddComponentObject<T>(). It just won't be burstable and will not be multithreaded, but will still work just fine.

And also, take your time learning. Life is not a sprint, its a marathone.

 

I am mentioning how they are "marketting it" as well as tutorial focus. I was most certainly not stating ECS doesn't makes sense in these contexts. Literally insinuating the opposite.

 

DOTS is like the large hadron collider. Something is always crashing into something else. That something often being reality itself.

 

'Run systems on actual status data and perform some wicked damage combos. Like Fire + Shock == Overload

Those are valid approaches and its possible. Nobody stops you from doing so.
And if you want to implement all of those after some time, your code won't break. That's the beauty of ECS. Interaction options are limitless, and the only barrier is your imagination, creativity and time available.'

You know, this statement is so accurate. I often build more and more complex systems in. And the old frameworks failed when it comes to adding more on top (at a certain point it breaks down, or becomes speghetti). Whereas by the time I write enough systems to overwhelm ECS, there will be a larger core count CPU released. Together with compute shaders, they offer a limitless playground for sandbox / simulation game dev. Although I didnt find a way around using Unity's audio system, I saw some threads about using OS specific implementations for audio output with better latency (Audio definitely needs more love).

I am however particularly worried about 'The items on the priority list are very much focusing on the GameObject workflow, even though DOTS versions were announced earlier.' I did see a lot of ECS bashing in the forums and people wanting to stick to the old ways. And I am not sure if they are making a dots editor anymore, or a dots node system, or sticking with the old ones out of ease/time frames imposed by being a company that went public on the market last year. I think this often makes us who invest time into these tools a bit worried about unity's future. I also think Burst and ECS is a game changer in the industry and really forward thinking. The engineers in 2018 really impressed me and I hope to see more of these kinds of tech demos in the future ^^

 

The people who really like DOTS seem to be the same people who enjoy programming in assembly or C. In other words people who do not really understand OOP well. DOTS has advantages that make it worthwhile but ease of use and code smell are not among them.

At the rate it is developing and based on unity's history. When it comes out of preview it will be totally different and 3 or 5 years in the future.

 

Well I disagree. I did OOP for a good 12 years before I used DOTS. I enjoy dots because it does the job better for game programming. Unless you're mostly just using all premade solutions. Anything that involves processing, like custom slicing mesh systems, or anything really unique functionally, works better by default with DOTS. I also think assembly or C are way more tedious then DOTS. I don't know if you either lack the DOTS knowledge or simply underestimate assembly or C, but that statement seems a bit off.
I think compared to the early version of DOTS, the current one is a lot more streamlined and has less boiler code. It's also more intuitive. I don't think they've changed it as much lately, they are mostly working on tooling now and optimizations.
Edit: I also want to add, monobehaviour workflow is very quick, and OOP in general, but it has a lot of bottlenecks when you scale it up. I think in general DOTS is better for shipping games that are high in quality and bigger in scope. Hybrid approach would be the best for many projects in the mean time. But for simpler (mobile, web) games, it probably doesn't need 50k spaceships lol.

 

Alright, its confirmed that I was using assembly in Unity since 2015.

Thing is, games are about composition, not inheritance. If you do inheritance over composition in Unity, you'll end up with a bunch of non-usable spaghetti for years to support forward. Been there, tried that.

And data oriented composition is implemented with DOTS way simpler.

By the way, DOTS != no inheritance. You can pretty much inherit any kind of system, which will provide same logic as in OOP world.

 

I agree with you about inheritance except for interfaces. I disagree that inheritance == OOP. Modern OOP has moved away from inheritance. I never had all these problems people seem to have with OOP design.

 

While I could tear this argument to shreds, I really would like to know why you have these impressions. When you say "enjoy programming" do you mean "comfortable with" or "prefer over C++, C#, Java, Python, ect"? And when you say that such people don't understand OOP well, what aspects do you believe they don't understand? What evidence have you seen that suggest that someone who loves DOTS is perhaps incompetent in traditional OOP projects?

For what it is worth, I do believe that even without accounting for the learning curve, DOTS still requires someone to maintain a larger cognitive context when writing code. I don't believe those problems stem from the lack of the architecture being built exclusively from OOP principles, but rather other reasons that relate to DOTS pre-1.0 status. In DOTS, OOP exists, but it is seen as a tool rather than the foundation.

 

In some cases DOTS is more OOP than traditional C# like langs.

I have started programming in 2001 and most loved language was C# from .Net Framework 1.1 and up
Learn C++, JavaScript, PHP and others

Heavy learn how to create good Program and Game Architecture, and you know what?

Many best practices of programming say:
- Prefer Composition over Inheritance (3 cases when it is not possible)
- SOLID - best on composition and mostly by default done with DOTS
- DRY, YAGNI, KISS - mostly done when in composition with small components
- All Design Patterns base one (Gang Of Four) and game specific all work on top of composition
- Most Game Engines go composition route (Unity is strict one, because you even cant inherit GameObject)

Today I can say that good OOP programmer is programmer that can create good composition of program and keep inheritance chain as small as possible.

ECS is best in composition and very good in systems with loop (not so good for console apps)
Games async in deep nature, ECS too

Most bad tool that you can use (tool of last resort) is Delegates because they very hard in maintenance for big projects ECS even dont allow to use it (easely)

In MonoBehaviour Land you have Update and LateUpdate Events but best practice is dont use it because of bad performance, use separate Behaviour that call update on all your components. ECS have this by default

We now even use Systems Of ECS for MonoBehaviours to create manageable update loop in components.

And so on

 

Isn't that actually the same as using the Update from MonoBeahavior or worse (MonoBehavior are manages native)? Or am I getting something wrong?

 

The theory is that every MonoBehaviour "event" method (like Update, FixedUpdate, etc) are called from the C++-side, in theory, if you're doing it clever and do not use events, actions or other costly methods, you can reduce the overhead calling these mean.

It was true a couple years ago, I haven't tested it for a long time if it is true nowadays. In general everyone should try to use as few MonoBehaviours as possible when it comes to the Update-cycle for sure (I know it is opposite to the composition Unity provides, but optimizing to performance sometimes means you need to avoid stuff).

 

I'm gonna be honest - i don't really know why, but when you have a group of lets say 500~1000 monobehaviours running something like a simple random move or follow the leader logic. It's way more performant to have a manager object running one Update() and updating each of those instead of them running Update() them selves.

Not to mention that Update() is pretty costly even if it's not running any code.

 

It just occurred to me how KSP implemented part modules, which are their own components that exist in the parent Part-MonoBehavior. They implemented most of all message methods, an iterate over all modules and call the part module counterparts.

 

Yes. Most or All (dont know for sure) builtin events in MonoBehavior called from C++ side and this is true for today. Most overhead is not only jump from C++ to C# side but additional checks that this MonoBeh is not dead, not disabled and so on because Unity dont know anything about your code. So making it manually you can do it way faster because if you know your code you can just write something like

foreach( var mob in AllMobs ) mob.Update();

and bypass overhead of Engine. In Unity Learn Best practices you can find lessons about performance and read more detailed info about all this stuff

Actually Unity create new modern architecture in Engine based on all old bad stuff that they have in Engine today and can not be changed because of back compatibility. DOTS is better almost in any sense, but it young and now have only very low level API and thus hard to use for novices.
When Unity done with low level they will create high level that will be as easy to use as current MonoBeh land, but we in 2-3 years from that moment now

 

One advantage of the magic methods is that if you don't implement them, Unity knows and doesn't even try to call them. Is there a way to test whether a manual update call is faster?
In my example from KSP, e.g. Update is also called when the method is empty.

 

I had the same worries. I switched my project from ECS/DOTS to GameObjects. I had developed it over 8 months using ECS/ DOTS. I am very glad that I switched. Switch when you still can and are not to deep in ECS / DOTS.

 

https://blogs.unity3d.com/2015/12/23/1k-update-calls/

 

Here you might have to test whether the manual iteration has not been optimized away by the compiler. I've already seen this at another benchmark where a test was way too fast and in the end only the whole loop was optimized away because the compiler noticed that it didn't need it and wrote the final value directly.

 

Its faster to use single manager to update MonoBehaviours because of native call overhead.
E.g. if you have 1 manager that receives Unity's .Update() and executes internal update on 10000 objects it would be miles faster than 10000 MonoBehaviour .Update() calls. Ran that test ages ago, but benefits we're substantial, in X-ms. (without compiler stripping calls, same workload)

Also, note that Unity will run any callback, that is empty. Meaning empty calls will get a native call overhead. That's why best practice is to remove empty callbacks.

Con of this approach is obviously exception handling, and stacktraces. Exceptions will stall whole application without try / catch, and stacktraces cannot be clicked on once Debug.Log is thrown into console manually.

Extra pro: You can fully control and insert / remove updates at will. Meaning you no longer need coroutines, and their GC alloc creation overhead is removed as well.



On the side note:
Another benefit of custom update manager - it allows to synchronize order of execution between ECS and MonoBehaviour world.

What I've ended up doing with my manager upon ECS transfer, I've made it SystemBase, added custom system group and ordered it after everything.

As a result - MonoBehaviours run after ECS done and results sync'ed. This also allows avoid structural changes of ECS while jobs running and freely author new entities from MonoBehaviour logic, modify them, or read from EntityManager.

 

Catching up on the discussion here. To clarify my original post, I'm by no means doubting or questioning the value of DOTS. The benefits of DOTS are numerous and clear (once the APIs and engine/editor integration are stable). My original post was focusing more on Unity's approach to communicate with its customers and the community when it comes to new features. I'm not minimizing the effort that goes into rolling some of this new tech out, but Unity ain't a small company, and if they're going to tease features in a subscription-based product, they should do much better at delivering meaningful updates in a timely manner.

And sure, while you can technically ship a project with DOTS in its current state, that's not the point.
There just seems to be a lack of focus, and the things that software engineers get excited about seem to be pushed to the side in favor of flashy new features to sell to CAD shops and marketing agencies. The technologists and the business folks at Unity clearly need to get on the same page.

It's not that I disagree with @Joachim_Ante that 1.0 should be solid and have "parity" with GameObject workflows, but the pace at which DOTS is publicly moving doesn't inspire much desire to sink meaningful time into the technology, and Unity needs more people who use Unity in a professional capacity test-driving this stuff to get valuable feedback about how it will fit into customers' workflows.

Edit: spacing

 

TLDR: lack of communication in a visible place

Very much this.
I basicly started with Unity in ECS / DOTS (yeah... not my greatest idea) because I liked this new programming approach (and always wanted to make a game).
I was away from Unity since around May last year and checking back I was expecting to see some big changes (as happened in the time before, eg. ForEach, authoring). Following the official blog and YouTube channel I was like "huh? Seems like DOTS is dead and it is all about how your car company can bring their products into Unity".
I am not saying that is what it is like, but it is what it looks like.
https://blogs.unity3d.com/2020/08/13/the-road-to-2021/ is from 13th August 2020. I guess the DOTS update will be in the "road to 2022" blog post then. Fingers crossed it will still be "road to 202x"

My personal main issues with DOTS are:

1)
I am basicly completly new to game programming and Unity, so figuring out how to do something in Unity and then convert it to DOTS is sometimes (not allways) challenging. Partially, I know I did this to myself by starting Unity with DOTS. But also I see a big lack of information on how to do things if you do not regularly go through the forums. There seemed to be an initiative e.g. with the Bullet spawner or the Pong example on YouTube by Unity, but then it just died.
I did a udemy course for DOTS a few days ago as a refresher (worked for that purpose) but my knowledge was in many small ways ahead of the presenter there, e.g. to use the "in" keywords for readonly access (maybe I should offer an udemy course ).
My point here is you can find info on how to do things if you search enough, but quality can be questionable.

2)
Actually the most difficult part for me is not developing my game in DOTS, it is how to get things (audio, particles) that are not supported in DOTS yet working. I have hacked together some things that "work" but e.g. audio seems a bit stuttery.
Also there are different suggestions how to do things like this this around, some official guidelines would be nice to see how to handle these things.
Physics are a part that are sooo much more complicated to do in DOTS vs legacy, and I don't think I noticed any progress in usability there at all.
How to do events or use tagging components vs flag filtering? I found answers to those, but you have to search for them in the forums and rely on the posters knowing what they are doing (there are many great people here though).
Official info from Unity (it's not done yet, here is how to do it for know) in one place would really go a long way for me.

 

Eight months since the DOTS "no show" and we're still clinging to hope. It seems more likely that the DOTS-hype achieved it's real goal...a very successful IPO in September 2020. Is DOTS the killer app? I think that if it was, someone else would've picked up on it by now and beaten Unity to it, focused as it is on extending the state of art of its older tech? This experience forced me to step back and realise just how big the world of real-time 3D engine architecture actually is. I still like Unity, but after being burned like that I now have divided loyalty

 

Well DOTs is obviously years behind schedule and they now have changed their goal of incrementally releasing and instead are focusing on releasing a whole new game engine basically. Originally they said Unity would be totally transitioned to ECS in 2022. I can see why without physics, animation and graphics it is hard to make a game.

The issue is that this will be an incredibly complex undertaking. Even in the best case it would take 2 years but in reality it is more like 5 years if even. I guess in theory they could make their end of 2022 deadline but in reality that is not happening. Total rewrites have a very poor history in the industry.

Maybe Unity should just split off what they have and rethink some aspects. Other programming paradigms besides ECS exist.

Create a game engine tailored to high performance and determinism and go ahead and make it a separate game engine without the tech debit. Not everything needs to be ECS. Hierarchies should be a native concept for graphics and transforms.

 

Why would that be better than this situation? Even if you don't work in ECS, you're enjoying the results. A lot of stuff under the hood is being reworked with the new paradigm in mind or straight used.
If you make a separate engine you need to work on everything twice, why would that be better than working on advancements in the GameObject world and working on the new toolset simultaniously?

 

I don't see any evidence that Unity is reworked below the hood. I do not think anyone that works at Unity has made that claim either.

Too much complexity. Unity is already suffering from too many render pipelines + too many platforms. Unity has two and soon to be three input systems, multiple GUI etc. Keep it simple start with desktop + one render pipeline and target high end PC games and later high end consoles. Really you only need PC, Xbox and Playstation that is it. Should be a Unreal 5 competitor.

You also end up with an overly complex editor that is not tailored for your paradigm.

 

The entire DOTS spawned from the need of reworking the transform system under the hood. They made the transforms like this and realized that this can be beneficial for everyone. So DOTS was born (or at least the early version of it).
But you're deliberately stretching my words here. Not the _entire_ software is being reworked, but individual services. Like the mentioned transform system or the Playables. They are working on Audio graph, Kinematica, Animation Rigging and I'm pretty sure there are a lot of under the hood / service reworks I (or we) don't even know about.

Or you could just ignore half of it and your problem is solved. I really don't understand you guys. Why are you bothered by the render pipelines? You could just use the built in and be happy and let others use the cutting edge. Those who are willing to take the risk. It is free to allow others to work with experimental services.

Unity is not Unreal. And never will be. Unity has different strengths and weaknesses. If you want Unreal, why don't you just use Unreal?

 

You couldn't be further from the truth:

• TransformAccessArray
• RaycastCommand and friends
• Particle System Jobs
• Animation Jobs
• Nav Mesh Low-Level API
• NativeArray API for Meshes, Textures, and Compute Buffers,
• NativeArray API for some 2D renderers
• A bunch of Unity API is now thread-safe like animation curve sampling
• 2D packages use lots of DOTS API under the hood
• Barracuda
• AI Planner
• Ect.

Also, lots of forum posts by Unity developers related to those areas. They're pretty scattered throughout the forums though.

 

Oh, you're right, now you have mentioned it. Even I forgot that they reworked more. It just became natural.

 

Unity has a lot of arms and moving parts. You will find marketing etc and shareholders don't agree with development teams. This is nothing new. It is simply that tech companies have much more transparency so you can access that tech while it is still being made while some other part of the company wants to increase that part of business and so on.

Ultimately we are programmers. We understand that the money-making part of Unity is something a group like us can and should ignore. If Unity's marketing says "hey guys, grab dots and make millions" then you probably should wait for Joachim to say the same thing. And he is not saying that. He is saying work takes time and they removed it from package manager until such a time it's mature.

That's not the same as public-facing website stuff. So lets agree to mature as DOTS matures. We look at evidence then we judge when we will use it or not. Not advertising

 

I think because the focus on multiple renderers has impacts on real world production. For example, my games use the built in render pipeline. I stay with it because I have invested technology that works only with it and changing to URP, even though I would love to do it, means a big investment in time, recreating shaders and more. It brings the stress of knowing built in will be removed and that my games are not future proofed, and that I'll likely have to rework these rather large games that are already established and selling well at some unknown point in the future instead of building on what I already have with a known quantity of consistency in the engine. The multiple renderers means new technologies that are pulling focus like shader graph are not available for built in, making them inaccessible without those game upgrades I mentioned. And of course many assets on the asset store available only for certain render pipelines.

I would love to switch to URP, and I'm sure I will be forced to eventually, but because of tte fragmentation upgrading established unity projects has become a night mare for many. So the increasing amount of fragmentation is not something that is easily ignored for many people because it has real world consequences.

 

Yes, but we all know that Unity won't be able to retire the built in at least for another four but more likely six years. (Introducing a "-final-final-001.zip" URP/HDRP and the corresponding LTS.
Don't get me wrong, I hope your game is successful and all, but I doubt that 4-6 years isn't enough to find the time to move it to the new rendering pipeline or statistically, more likely retire it. I understand your anxiety, but I think it comes from not thinking this through. In the immediate future, nothing is putting any production in danger.

Well, as of the Asset Store, I think most of the Asset Store creators are doing it wrong. I saw a couple, who are selling the URP/HDRP solutions separately (or at least the HDRP), and I support that wholeheartedly (okay, I'm the guy, who buys the asset even if I don't need it, on full price, just to support awesome creators).

 

As always you have well thought out advice I appreciate it.

I do want to say though that saying Asset store creators are doing it wrong reminds me of Steve Jobs saying we were holding the iPhone wrong during antennae gate, and I'm not sure what 'doing it right' would look like. Their approach exists because of the state of the Unity landscape, which is fractured with multiple pipelines. It's kind of like making the same asset available for different engines which many do. From what I am reading on forum posts, it's very difficult for asset creators to keep up with changes across pipelines, let alone within them, and if it wasn't fractured they wouldn't do it.

And to circle back to DOTS quickly, I think for people like me DOTS is seen as another hurdle to overcome rather than a welcome feature, because it involves the same kind of performance oriented, top down workflow favoured by languages like ActionScript 3, which brought performance but was part of what discouraged the Flash community by eroding fast iteration and intuitiveness. Many of us connected wth Unity because of GameObject/Composition ease of use. While a top down, almost severe, way of coding and control may be highly efficient and performant, there are benefits to both approaches. What it kind of looks like Unity is trying to do, and I HOPE this is what they are trying to do, is get the performance of DOTS working under the hood while keeping the front facing hierarchy/GameObject paradigm that so many people find easy and useable intact.

 

Right now there's parallel paths being developed that make the nomenclature confusing:

• Shared performance core
  • Job system
  • Native memory,
  • Burst
• Branch A: Low-Level APIs for GameObjects (not this subforum)
  • All the things I mentioned earlier in this thread
  • Added by individual engine feature teams, not the "DOTS Team"
  • For people who like the GameObject architecture but need performance in a few key areas
• Branch B: "DOTS Team" DOTS (this subforum)
  • ECS and everything that works with it
  • Tiny
  • Open up Engine APIs where extreme customization is necessary
  • For people who want to do everything data-oriented and move past the limitations of GameObjects

I don't think it was always planned to evolve this way, but I do like this approach. It really tailors better to individual use cases. But we need some new nomenclature for these three parts so that people don't try using ECS when they really just want the low-level APIs for a half-finished GameObject-based project.

 

I agree, because my instinct says many people like me who are not trained coders still don't understand what's DOTS is. I mean is ECS a way of coding that can be applied to any language? Is it a part of DOTS? Is DOTS a combination of technologies? Because its ill defined in minds of many people, many people will see it as an existential threat.

I really believe a plain English - or whichever language - overview of what DOTS is, and I mean like for dummies really plain you-think-its-clear-but-still-dumb-it-down-more explanation-not-for-coders-for-artists-too would go a huge way towards moving DOTS forward in the popular consciousness.

 

Well, hope this helps a little bit:

- DOTS is a couple of technologies together (hence the name Stack), it contains the Job System, Burst Compiler and ECS
- Data-Oriented because it concentrates on the data more and less on the code. Because every application is a data-transformation-automata (in mathematical sense), including games, the enterprise software development usually forgets about it or treat it with less importance.
- Job System is for writing multi-threaded code more easily and more importantly safely (it is easy to make mistakes when you write parallel algorithms)
- Burst Compiler is a piece of technology which "magically" makes your set of code into parallelized code using highly specific SIMDs (Single Instruction on Multiple Data) - in English this means most CPUs are capable of doing the same thing on more than one set of data at once if you write your code on specific way (making the execution faster and using less energy), this is what the Burst Compiler tries to achieve.
- ECS is a paradigm, it based on Data-Oriented Design and makes you think about your data first and the ways you are transforming your data rather than objects and behaviors. It is very customary to hold up in opposition of the OOP paradigm, but this is not a real opposition. In ECS you still use composition and OOP basics. The difference lies more in the way you think about your program. In "classic" OOP you set up your objects, usually put together the data it holds and the behavior it displays. In ECS you think about what kind of data you need and what kind of transformations you will do on the data.

But maybe Code Monkey is better at explaining things than I am, so I will leave this here:

 

1: ECS is a programming paradigm.
2: DOTS is all the stuff made using that paradigm.
3: The Job System and Burst Compiler are supporting technology. They do not necessarily need to use the ECS paradigm. But Burst does not support .Net classes.

What unity calls ECS is much lower level than most ECS systems and they are trying to make a whole game engine out of it. Literally, no one has ever tried this.