Should I wait to use DOTS?

[marsh stratus]

I want to begin my next project using DOTS but I have some hang-ups. From what I can see some things seem overly complicated and apparently will be changed to become less complicated later on. Something like creating a component struct and then an authoring monobehavior with the same fields and then a baker to do one simple thing seems like it brings so much overhead.

Using another ECS system like Bevy with Rust requires far less overhead to
accomplish a similar goal. Obviously Bevy isnt as verbose as Unity and its not entirely comparable, its just an example.

Should I just wait for changes to be made to DOTS before starting a new project with it? I am worried I will be far into my project and changes will come requiring me to refactor many things. I might also be wrong about some things as I have yet to dive that deep into DOTS or what is apparently promised in the future.

[unkempt tapir]

don't wait! it's time! we're not allowed to change 1.x that much anyway now that it's officially out of preview, and it'll be a good long while before anything that isn't 1.x is out. (such things are pretty much still in the research phase right now.) the authoring monobehaviour thing does suck, but thing we had to autogenerate it was even worse, and now Rider has a thing i believe to generate it for you anyway.

plus, once you get underway, i suspect you'll really like the control you get from bakers; i know some large games in unity effectively implement a rickety scheme like this to have different data in editor vs in player.

plus, i haven't used bevy myself, but my impression is it doesn't give you safe parallelism in the same way unity ecs does, which can be a big deal. (somebody please correct me if i'm wrong here)

plus, netcode for entities is really pretty awesome. i'm not on the netcode team, but for my own projects, it's made me want to make stuff be multiplayer that previously would have been unthinkable, for a variety of reasons.

the main reasons i would choose not to use entities today are:
a) i need really serious scalable interop with terrain stuff (this is being worked on but release tbd, maybe closed beta soonish);
b) i need huge scale with animations and rukhanka doesn't have enough features (we have a thing coming for that, but same story as a) );
c) i'm making a single-player game that is of sufficiently small scale that i don't need the extra speed from ecs anyway
d) i'm making an mmo (netcode's model isn't totally ready for that right now)
or
e) my game is entirely made up of ui (ecs doesn't really help with ui)

[marsh stratus]

Thanks for the info, I will definitely consider all of this in whether I decide to go forward with ECS or regular game objects. I think ECS has a very bright future.
Also to mention Bevy, it uses Rust which can assure safety across threads, it is a feature of Rust. Bevy obviously doesn't compare to the features or feasibility of using something like Unity, I think its ECS system is excellent tho.
Can you clarify "b"? Is there an issue with using lots of entities with animations? The project I am going to pursue soon will have lots of entities with animations

[thin yarrow]

The official animation package (i think now called motion?) is still not available for entities.
Your options are then use some type of hybrid approach (netcode has a setup to help you with this already) or use a third party package like rukhanka for a pure entities approach (https://assetstore.unity.com/packages/tools/animation/rukhanka-ecs-animation-system-241472)
rukhanka is good and was designed to replicate Mecanim with a few limitations

[marsh stratus]

Ah okay thank you.

[thin yarrow]

By the way, bakers aren't nearly as bad as you might imagine

As mentioned above, Rider can actually generate them for you but personally I don't even bother

Though it would be very handy for someone getting into entities

(The reason I don't use it much is I think 1 component per baker is usually not a great idea otherwise you end up with 80 different authoring scripts on your gameobject which becomes very painful to maintain)

[marsh stratus]

Yea that was another issue I saw coming up, Each component requiring an authoring script and then a baker class on that authoring script. Is there a different way?

[thin yarrow]

a baker can add as many components as it wants

i group bakers by feature

and a feature might have a dozen components that can be conditionally added

[marsh stratus]

Okay thats good to know, thank you for the help. I feel like I need to look more into DOTS before making a decision