#Slow transition from MonoBehavior to DOTS

1 messages · Page 1 of 1 (latest)

slate elk
#

This is my code from MonoBehavior

    {
        id = idCounter++; // idCounter is basically a static
        units.Add(id, this); // units is dictionary datastructure

        // from here I want to reference to a entity somehow be it be through Entities.Add() or Get an Entity from pooling
        
// after that call OnSpawnEvent
        OnSpawnedEvent?.Invoke(this);
    }

private void OnDisable()
    {
        // On death we will call OnDeath event who are subscribed to it
        OnDeathEvent?.Invoke(this);
        units.Remove(id);

        // Also we will remove links to Entities here. If possible make them go back to Object Pool as a deactivated component or something
    }

I want to slowly transition to DOTS. For that I just dont want to do a total rewrite and rather slowly transition into DOTS. From the code I want MonoBehavior somehow linked to Entities to interact with ECS codes. From ECS I want to interact with MonoBehavior stuffs as well. What to do in this case?

tiny grove
#

var entity =world. EntityManayer.CreateEntity( ). Just save the entity in mono. nothing special.

slate elk
#

Also did tried that approach but it doesn't seem to show up on Inspector

tiny grove
#

Entity is just a simple struct . It will not show up on Inspector. Anything you want to do with an entity should be done through the EntityManager.

slate elk
tiny grove
#

EntityManager can handle everything related to entities.

upbeat dragon
#

in general, it's very difficult to do this transition gradually and get any benefit out of it until it's finished; @grizzled knot i believe has experience on this subject

grizzled knot
#

yeah my company transitioned an existing product to ecs (started before I joined) and I've been feeling the consequences for years.

my general advise is don't, the overhead and pain you introduce by mixing paradigm is not worth the effort and benefits.

I love ecs and the entities package, but personally I would only use it on a reasonably fresh project. If you do really want to make the transition on an existing project I believe you will save a lot of time in the long run by starting from scratch.

That said it doesn't mean you can't get benefits from dots in your existing project. I highly recommend figuring out your slow paths and optimizing them with burst and jobs if possible. This would give you the biggest noticeable benefits anyway.

slate elk
#

i still love old MonoBehavior @grizzled knot . But biggest problem I see with ECS is how it changes every single day. It sucks seeing next day the tutorial is obsolete. But gotta go hybrid. Because will need to have active 5000+ units for Total War ish game

#

atleast partially

#

let's say pushing pathfinding and animation to ECS

#

while rest logic staying with MonoBehavior. If possible pushing few more to ECS where needed

grizzled knot
#

let's say pushing pathfinding and animation to ECS
well see 'ecs' here doesn't make much sense

#

what makes sense would be pushing your pathfinding to a burst compiled job

#

ecs is more about a way to structure your data, but what care more about at this stage is optimizing your logic

#

for the record though, ecs is reasonably stable now that it's gone 1.0

#

the only real breaking change since previews last year was the transform system changes

#

and i would expect them to be very cautious about changes going forward now that it's officially released

#

😄

slate elk
#

sighs

#

Want to use this asset

#

And this

grizzled knot
#

well that top one doesn't need ecs

#

and the bottom one honestly basically requires you to rewrite your game from scratch

slate elk
#

i want to made some critical changes even

#

like in our case we just turn off animation

#

after certain LOD distance

#

or if its behind

#

culling and what not

#

also want to do prediction based on Time.time

#

but yet problems arise when you are closeby where it may need serious calculation

#

on animation

#

5000 * 17(taking lowest low into account) transform updates

#

won't be too healthy for CPU lifecycle

grizzled knot
#

the problem is if you use a hybrid approach for an existing project

#

you're just doubling this cost

#

you now have to calculate the transform in ECS and then write it back to gameobjects as well

slate elk
#

hmm. Anyway to just tag it somehow? Like forget monobehavior update or just update only around players but visuals played in ECS

#

when we need it, we'll just update close to player

#

not all

#

or where relevant

hollow nymph
#

Everything is possible. But such systems need to be written, debugged and maintained. I have experience in maintaining different renderer pipelines (BiRP and URP) in same project. It is not direct equivalence with mono-entities interaction, but idea is similar. Shared functionality cannot have shared code anymore.

wooden nebula
#

Rarely anything in the OOP world stays absolutely independent. Rarely any feature of a game can meaningfully exist on its own. When you take out a thing to make it ECS way, you have to solve the collateral broken dependencies it would cause. More bugs would arise, more time would be wasted fixing them. You should consider this very carefully.

#

However, even though I have a very limited experience with ECS, compared to the others, I can say adding or removing systems from an ECS world is fairly trivial. Dependencies are defined purely by the data (components) each system needs.

indigo trout
#

It's possible to migrate to ECS, but you need to define a section of the code you can convert to ECS, so if by "slow" you mean bit by bit then that's not really going to happen. It sounds like you'll want to convert all your units to ECS. But unless you have a released game then as tertle says you may just be better of re-writing it from scratch as this will save you having to make ECS and MonoBehaviours work together

slate elk
#

let's say animation stuffs

#

i can live up with not converting all the codes

slate elk
#

speaking of which can your animation asset be supported by MonoBehavior but using Job System?

hollow nymph
slate elk
grizzled knot
#

there is a lot of overhead writing transforms back to gameobjects

hollow nymph
#

But, I think, both approaches are not good.

grizzled knot
#

Rukhanka is fantastic because it allows us to remove the need for gameobjects
It makes no sense to just add the gameobjects back

hollow nymph
slate elk
#

alright only need visuals but at the same time may need sync. Let's say just global position of entity version. What to do in that case?

#

or no way?

#

Altho ragdoll/hit collider is something to look out for but that'll need to work with function call/event system