Game Object + DOTS?

Hello,
Can you do in DOTS things like inheritance, composition or apply design patterns, scale your game, apply changes and improvements… or you have to combine it with OO?

Would be a good idea to go full DOTS if you are starting a new (big)project or maybe build your game as usual and use DOTS for the most demanding tasks like rendering, updating actors, etc.

Thanks in advance :wink:

Hi,

Inheritance with struct is not possible, howerver not all DOTS elements are structs.
You can still go with composition but keep in mind that if you add a composition element to a struct, (I think) it will have the same memory footprint whether or not the data is actually populated, so going that way to “work around” inheritance may not be a good idea, you are much better doing your composition by doing separate ICoponentData.

You should also consider the authoring aspect of the game. The conversion workflow is a great tool to handle the authoring in a familar way (monobehaviour), and use the power of DOTS for runtime.

Beside, if you plan on starting a big project, I would assume the release date is not in hte near future so the DOTS stack may cahnge a lot by then (if it’s even feature complete by that time), so going with the hybrid approach would IMO be the safest move.

So my advise would be to use classic appraoch for the first implementation to prototyp in a wuick and familiar fashion and then try to move some of the simpler behaviour to DOTS, and continue to do so with incrementaly more complex behaviour (where DOTS suport the requiered features).

1 Like

Inheritance - You subclass systems and logic, not components. However, most shared functionality can be delegated to static classes.
Composition - Lots of small components = lots of composition.
Design Patterns - There is a different set of design patterns in DOD rather than OOP. Some overlap, most don’t.
Scaling - ECS is waaaaaay better at this. You break processes up into stages and each stage could have several variants for different EntityQueries. So adding a new type involves adding new components and systems. No interface modifications required.
Changes and Improvements - It is still C#, and C# lets you do this.

Every game’s need is different. If you can easily decouple the ECS aspects from the classic aspects with a very small bridge between the two, mixing them is fine. If not, I suggest choosing one or the other. ECS can use hybrid components and GameObjects, but your logic is still primarily in systems and static classes. You should use Jobs and Burst regardless of whether or not you use ECS for a big project. Those are easy performance wins.

1 Like

Hello and, what about things like an inventory system. Would you do it also from scratch in DOTS or better reuse something you already have in OO?
The real question, is it a good idea to mix things where there is a way to integrate DOTs and OO. Or it is just the best to go DOTS for everything?

Thanks for the points!

I would do it from scratch so that I could reuse it in other DOTS projects.

For your second question, see my last paragraph of my previous post.