Why don't DOTS Physics have functions that are available in normal, non-ECS physics?

Understanding the DOTS Physics package, I did not understand why it is developed in this configuration. Some things that are in standard Mono physics exist in DOTS Physics only as a demo in the samples project. This includes the state of collision and trigger events, raycast cars, and more. Why not make it part of a package so that it can be easily used, rather than rewriting the very oddly made demos from the samples project?

 

The approach we took here is that the DOTS physics package represents a core physics solution on top of which people can build various things. Building a vehicle that will work for every use case on the planet is probably an impossible job, so we just provide a simple vehicle for people to get started and customize to their needs. Same applies for character controller for example. Now, you could say that same applies for stateful events, since we provided the option for using that, but not enforcing everyone to have this state in their physics package, only those who need it. And also they could customize it more so that it fits their needs perfectly. In the end, if there is proof that some of these things actually work for a lot of people, we will have no problem of "promoting" it to the core package, but so far we haven't seen signal on any of the sample features that need to go in that direction.

 

Providing some wrapper or API on top of the core that is both easy to use and feature-parity with current non-DOTS physics would be definitely a good entry point for attracting users to DOTS physics.

 

Throughout development of DOTS, since it was first introduced, they always said that everything starts out with the lower-level core implementations of things, then as those APIs become ready for an actual release and they know that they are not going to change, then the higher-level and more end-user friendly API scaffolding will be built on top of that.

The more time that is spent trying to develop higher-level APIs on top of something that is still changing just to make people happy in the short term is time wasted that could/should have been spent getting the core API solid and bug free.

I, personally, would much rather the time be spent getting the core as solid and ready as it can be so that the higher-level things only have to be written once, than have some core work, then higher APIs... shoot, core changed, have to fix higher API's, shoot, core changed again, have to change higher API again.

Unity keeps trying to (in the nicest way they can) stress the fact that "in-preview" means "Don't try and build a game you want to release any time soon with this! Don't rely on this code yet, because it is going to change! You are going to have to go back and change things if you do!" but folks just don't want to hear it and don't care. People keep trying to use it as if it's production-ready, simply because they want it to be, and then get upset when things change and it breaks, exactly like they were warned that it was going to. If a sign say "Be careful, the floor is wet! Only enter if you understand that the floor is wet and that you might fall" and you enter and then slip and fall and then get mad that this happened, I don't know what else you want aside from completely closing it and not letting you in at all.

The reason that there is not yet a high-level API or feature parity is because it is simply not done/ready yet. Once it is, those things will exist. Until then, though, attracting loads of new users who don't understand these things and just want things to work perfectly right now is honestly not a great idea as that will probably just end up taking even more focus away from where it should be just trying to constantly explain that things aren't ready, such as having to rework the UI of the editor itself to add checkboxes you have to find yourself to enable, and huge bright unmissable wording.

I realize that this ended up turning into a rant, my bad for that. None of that is aimed at anyone in particular. Any time I say "you", I just mean people, in general, using Unity, but it just seems like expectations overall need to be reset and kept in check.

 

That's the exact reason I won't be using DOTS physics, not even ECS, anytime soon. I'd rather make games, not engines. That's Unity's job. I'm ok on Unity exposing it anyways for people who want to deal with it, but don't expect users to abandon GameObjects to start coding in something equivalent to low-level C just "because it's fast".

 

You are definitely correct. Unity doesn't expect this either. They have often quoted that the Monobehaviour workflow is here to stay. Anyone who likes Monobehaviour the way it is, and the performance that it currently offers, can continue to use it as is, that is not going anywhere or having any major changes (minus the addition of Bolt).

That's the thing, though. From here on out, it's not going anywhere or having any major changes. For many, there is nothing wrong with that, and there doesn't have to be anything wrong with that. Once DOTS gets finished though, it will let those who *do* want more, be able to achieve it.

 

Then I would Unity kindly ask to not show us anything. They get you hooked up with Mega City, where they built something the world has never seen before, and then expect us to wait the next 5 years to use this very same technology. ECS is a big step a head, which makes a lot of type of games possible, and of course everybody wants to use it. I am using for now only jobs, which gave me a nice performance boost and I am perfectly fine with it. But I also are annoyed that I could build it with ECS, but I don't know hot to make basic stuff like an Ontrigger function or animation...