Question Combining ECS workflow with standard OOP Unity

Hello
I'm just getting started with ECS and DOTS.

My initial idea was to use ECS to manage the game's world (tiles, objects, random generation, etc) for maximum performance.
This seems fitting to me as this includes managing a lot of objects.
However, I can't wrap my head around using DOTS for other parts in the game, like character management or UI menus.
Ideally, I would like to keep using the standard OOP workflow for most of my systems.

Is it possible to elegantly hybrid DOTS with OOP?
If so, what are the sync/entry points between the two?
Thanks!

 

If your GameObjects are prefabs, yes. If your GameObjects are in the scene, then it depends on your definition of "elegant", though I would lean towards "no". Most solutions for this tend to be very hacky.

 

It seems like the consensus is to "bind" your monobehaviours to the ECS system by throwing them in managed components.

Although the official examples don't offer elegant ways of doing this.

 

Similar question was asked here, including my answer: https://forum.unity.com/threads/combine-ecs-and-monobehavior-on-same-object.1456273

That covers the case of generating objects from entities. If you're going in the other direction and want to manipulate entities from the OOP side without using the above pattern, it comes down to making calls to the World's EntityManager from the mono side.

E.g. World.DefaultGameObjectInjectionWorld.EntityManager.DoStuff

The https://assetstore.unity.com/packages/tools/behavior-ai/agents-navigation-239233 plugin on the store is also a good example of how to get the two worlds to interact, if you're willing to study the code. (Asset not made by me, so this isn't a promotion!)

 

It depends. This is quite common question now, so I'll just leave previous answer:
https://forum.unity.com/threads/can-traditional-gameobjects-and-ecs-coexist.1482477/#post-9240462

You don't have to add them as part of managed component. Add MonoBehaviour directly to the entity as component.

Basically, don't do this:

Code (CSharp):

1. public partial class ISomeManagedComponent : IComponentData {
2.     public T SomeMonoBehaviour;
3. }

Do this instead:

Code (CSharp):

1. T someMonoBehaviour;
2. // where T : UnityEngine.Object -- which means you can add ScriptableObjects, Materials etc as well.
3. EntityManager.AddComponentObject(entity, someMonoBehaviour);

 

Oh nice, that is pretty clean.

While I have you hear, maybe you can clean up my understanding. I mental framework that has helped me understand ECS is to think that;

Transforms, Meshes, Materials, Colliders, Rigid bodies and Pure game logic can be converted to burstable entities. Everything else (Sound, UI, Input etc) Will remain OOP for the foreseeable future. So abandon the idea of pure ECS game and think more in terms of ECS embedded inside of an OOP application. It's still your usual OOP game, but high intensity Update Loops (transforms, physics, rendering and certian game logic) will be ECS

The one exception is animations, which will eventually be an a true ECS entity like the others.

 

Basically, yes. Everything that can be considered as "simulation" work, or any kind of data processing can be moved to the ECS side. Rest can be kept as default MonoBehaviour, or anything really whatever you prefer. Inputs can be read once per frame inside of "InputPollingSystem" and picked up later by any system or in jobs. It doesn't matter if its old input system or newer one. See discussion here and here.

If you don't want custom solutions that is.
Everything can be moved to the ECS side if you're willing to build up those features. Even sounds, and animation.

E.g. Latios Framework can be used for lots of features that aren't yet available (sound - Myri, animation - Kinematon, other core features).
Or NSprites for 2d sprites.
Or Rukhanka for full fledges 3d animation.
There's custom CC included in physics that was previously an asset store called Rival.
There are lots of good custom solutions already.

In house systems are still in development hell, so expect them to be delayed. But, its sooner or later will be available. Probably later though.

The only aspect that is lacking is UI.
But in that regard you can always build your own system for mass entity numbers (like damage numbers popups etc) and just use renderers or sprites with custom shader.

For the default HUD like health, armor etc its cheaper just use uGUI and access data from the managed system. Cost of applying data is near non-exist and equal to what it was before just with MB's. Probably even less if done correctly.