#Eight years later, DOTS still feels like a compatibility minefield.

1 messages · Page 1 of 1 (latest)

round bloom
#

I’ve been an excited DOTS devotee since the day it was announced. Unfortunately, after 8+ years, it’s still unclear in what parts of Unity are compatible with DOTS. And it’s unclear how to find out.

Here are a list of major Unity features. It’s unclear if - or how much - of their APIs can be called from a Bursted Job:

  • Cinemachine
  • Animation State Machines
  • Audio Features/Sources/Listeners
  • TextMesh Pro
  • Landscape Features
  • Speedtree
  • Sky & Weather Features
  • Misc. Material/Shader features
  • Postprocessing Effects
  • Advanced lighting (GI or Raytracing)
  • UI Toolkit
  • Navmesh Agents
  • ML features
  • Unity Analytics
  • Unity Ads
  • VR/MR Features

Consider someone trying to figure out if it’s safe to use ECS for the core logic of their next project. If they plan to use MonoBehaviors, they’ll know all of these features will be available to them. If they write DOTS based code? How can they know? Will they run into any unforeseen compatibility gotchas, 3 years down the line? Will they find out a year before shipping that the solution Unity suggests for a problem will only work for MonoBehavior code? How can they find out what will be safely available to them, before they invest?

For some features like Rendering, Physics, Networking, or Skinned Animation, DOTS-specific versions of them had to be written from the ground up. Is that how we are meant to know if a Unity feature is ready for DOTS? Should we be waiting for new DOTS versions of the above list? Where’s the communication?

Joachim’s original sell for DOTS was always that it could be used for the main gameplay logic of a game - not just grass, or side features. But the way things have evolved, it feels like isolated side features of a game is the only safe way to plan to use DOTS in a project. And that also seems to be the only way almost all released projects (ones that use a variate of Unity features) have used it: “Let us tell you where we were able to incorporate DOTS.”

(Cont.)

#

…The fact that there isn’t a clear compatibility graph, where I can go to see which of unity’s features have DOTS API compatibility or not, is really confusing in 2024. It makes it seem like DOTS was rushed out the door with a “production ready” tag on it, because internal development was dragging on with not clear end in sight. And that the definition of “production ready” was warped in this case, to mean “technically usable for some features in a game, but not like we pitched it”.

It makes it seem like the company wanted to hide this fact, ship DOTS, and then get to slowly adding DOTS compatibility in the engine over some untold years to come, while hoping people won’t talk about that too much. As a strong believer in the tech, I am hoping this is wrong.

But the current state seems to make Joachim’s vision for DOTS - that you could write your core game code using it - an irresponsibly risky choice. How can any company that needs to plan a reliable production schedule and profit from their games confidently use it in that way, knowing what Unity features will or won’t be compatible?

round bloom
#

Also - please don’t say “many of these things won’t be more performant in a job, so you should do them on the main thread anyway.”

The problem with this argument is that if you’re writing your core game logic in ECS and Bursted Jobs, then not using those things for certain features means carving out exceptions for just them. And that realistically means bifurcating your code in such ways that it gets difficult for a team to understand and maintain:

“Why is the code to play the audio for this attack not written with the rest of the attack code?”

Things like that. Confusions like these increase the chance for bugs, and increase the difficulty of onboarding new team members. And questions like that do not typically exist with slower MonoBehavior-based code.

And that argument also doesn’t solve the discovery problem - understanding from the start what features will be compatible with DOTS and what won’t.

left lantern
#

Everything is compatible with ECS, because you can create a SystemBase and access whatever managed classes you need. Not everything is Burst compatible though, and that doesn't have to be a deal-breaker.

#

DOTS is a toolkit and you have to decide if the benefits are worth it to you. You could just use some bursted jobs to take advantage of multithreading, or implement some part(s) of your game in ECS. If you think having special cases for some things is unacceptable then you are going to leave a lot of potential improvements on the floor.

#

“Why is the code to play the audio for this attack not written with the rest of the attack code?”
I think you should learn more about ECS because this question doesn't really make sense as in ECS these would be separate things anyway

#

“many of these things won’t be more performant in a job, so you should do them on the main thread anyway.”
Why would you use jobs if they are slower? Not every ECS system needs to run jobs, you can work with entities on the main thread fine, and is not uncommon. You can choose between ISystem for burst code or SystemBase for managed code which allows you to access all those systems you listed above

round bloom
#

I would respectfully caution against being too sure of all the appropriate ways to use an ECS pattern. There may be legitimate use cases you’re not familiar with.

#

Re: why don’t always do the most performant thing?

Code readability and maintainability. In a large enough team, over a long enough project, it’s sometimes as important as performance. A code structure with a high number of organizational rules to remember can be inefficient in a number of ways, from slow implementation, to increased likelihood of bugs, to difficult onboarding.

For example, I just had a Unity dev give me a recommendation to solve a DOTS problem that explicitly gave up some performance, in favor of code simplicity. So in any case, DOTS devs also sometimes think that way.

#

I mean, we aren’t writing in Assembly, for a reason. :p

#

If I have a programmer who needs to learn “how to implement an attack?” <- the best answer I can give them is one with the smartest intersection of performance and code simplicity. And the code would need to be written ahead of time with that in mind, so that I can give them that answer.

#

To say something on topic:

“Why use jobs if they are slower?”

I think the more common case would end up being:

  1. You have a logical unit of work that you want to do in a job.

  2. You find that only some of the components of that work can be done in a burst compatible job. Theoretically it all could be - but it can’t, because some engine features aren’t burst compatible.

  3. So you hit a need to split up the components of this logical unit of work, for reasons that are only about Burst compatibility. This forces code to now be done in multiple places, based on something other than what would be the most logical, intuitive organization. That compatibility is now driving the code organization.

#

And information about that compatibility isn’t easily found by a user, before implementation.

#

To come full circle - Remember, Joachim’s original Unite pitch for DOTS was that it would be possible to write a game’s core gameplay logic using it.

If half of what that logic is doing must be run on the main thread, because parts of Unity aren’t burst compatible, that breaks that premise, imo.

novel shore
#

I agree (and I think everyone else does too) that it doesn't match the original vision. But that's not because it was "rushed out the door", it's because the original vision was made with little perspective of the reality of development and the future of Unity; and the pitch has changed over the years into what we have now, with ECS-GameObject/Transform compatibility on the horizon being the major choice that sets the direction for its future.

And information about that compatibility isn’t easily found by a user, before implementation.

Is it that difficult? If it's managed data then it's not burst compatible. If those objects don't bake to Entities Components then they're not going to have that level of interfacing. You can start with the assumption that you'll be using SystemBase and write your performance-intensive core logic using basic IComponents and whatever choice of system you want. Note that it's fairly easy to walk up or down the system choices, going from SystemBase to ISystem, to IJobEntity, to IJobChunk, so you're not trapped if something unexpected did occur.

It can be clunky to learn some of the patterns because of this, but it doesn't stop Entities from being production ready. I think it's not for every production, because you'll need to have a bunch of experience to not walk into the many footguns it can have (most, unrelated to this compatibility imo).

round bloom
#

This is what I mean:

I set out to see if Unity provides a DOTS-compatible navmesh solution. There is no clear place to go find an answer to this question. And after a bunch of unofficial forum diving, the answer seems to be “maybe…there was an effort to write one four years ago, but that seems to have stalled…but parts of the implementation are still around, in an incompleted state.”:

https://discussions.unity.com/t/dots-navigation/761365

https://discussions.unity.com/t/is-there-any-intention-for-a-solid-plan-for-terrain-navmesh-pathfinding-in-dots/923870

https://docs.unity3d.com/ScriptReference/Experimental.AI.NavMeshQuery.html

Is this API something Unity recommends we use? That information isn’t anywhere.

This is what I mean by a compatibility minefield. In order to use DOTS for more than just personal experiments - in order to plan to use it as a central part of a project - right now that requires rabbit hole investigations into a wide range of features like this. Many of which don’t have clear answers.

#

Most companies can’t afford to get funding and start development on a game, only to realize later they’ll need to write their own DOTS compatible pathfinding solution (or adopt another unofficial one).

clever mulch
#

to be dots compatible, you don't need to be job/burst compatible

round bloom
#

The existing Unity navmesh solution is obsolete?

clever mulch