DOTS is even more of a dumpster fire than the URP/HDRP.
They have an unstable base layer that is constantly changing (eg. SystemBase and for each is literally what, two months old and the old stuff is depreciated now?), a version control system for packages that doesn’t work at all (see all the threads on why don’t my packages work?).
...and guess what? They’re using that as a base to build the physics, audio, networking, animation and visual scripting on.
No wonder its taking forever... those poor other teams are royally screwed, because every time they make any progress, the DOTS guys go and re do everything from scratch.
codegen? nah. we’re giving up on that too now, it was too hard.
...I mean, the demos are great and all, but DOTS is a mess.
Its not a “step up”, its a vague pie in the sky idea, and a bunch of people making a big old mess.
Its not even part of the 2020 roadmap.
- laying out instances of the same Component next to each other in memory
- Burst.Compiling their Update() functions
- adding backwards compatible APIs to do parallel loops etc over multiple components
Given the culture of constant rewrites Unity has displayed (and I'm sure they have lots of techdebt to make rewrites feel appealing), its seems far from certain that they explored avenues like this sufficiently.
Or maybe they felt their earlier modification of Mono, which kept them on an old version of .NET for so long, was too painful to even consider touching the runtime ever again.
And if those Update functions reference other objects and do something with them? If the engine automatically realigns the order in which Update is called on objects then you can't do something like that, you'd run into weird behavior. Or do I somehow misunderstand?
From what I understand, the whole point of DOTS is to get people to write code that uncouples the data from what operates on the data. Once they have that they can shuffle these calls around.
But you're right to be skeptical, this is not something I've thought through that thoroughly :)