GO/Entity unification concerns

Unity Engine
, , ,
1

Lots of questions came up and I’m highly concerned about the unification of entities and GOs.

My first question is a blunt one. Why?
Who is the targeted developer and team who profits from it? It sounds like a haphazardly put together elevator pitch.

Initially it was sold to me that it opens up getting missing DOTS features like animations. Now last time I was told that bakers are not working on GOs in a Scene and I should stick to subscenes. Ok, so I’m already out? That was quick.

When bakers are not working and instead IComps/IBuffers are mapped 1:1 on the GO how should anyone postprocess data? Is postprocessing even intended? If not, out again.

So now I want to take advantage of new world creation. Where should I put the world? It’s an important question because what physics engine will be picked? Do I leave it as GO, do I put it in a subscene? What colliders will be created? In both worlds? Where should I raycast? I just wrote code for PhysX and now I realize my world streaming is bottlenecking and I put everything in a subscene. Now the previous PhysX raycasts are not working anymore because it’s Unity.Physics now.

When MBs and systems are mixed. How is execution order determined? This can quickly end up in outdated data and 1 frame delays. How can execution order of MBs work alongside systems? (I do have a solution down below)

Do you realize that this could end up very confusing for everyone?

When I first heard about it I thought it was great and I’m laying out the expectations I had:

  • Subscenes are gone, bakers are a first class citizen and encouraged
  • Everything is a scene and scenes can have nested scenes
  • An entity will be created with any GO and bakers will use that
  • Through bakers finally GOs can be controlled to have Transform, hierarchy or WorldSpace, just like we control our entities now
  • MBs are baked now too and act as authoring component. (class IComp) Their underlying events are translated into SystemBase calls OnEnable → OnStart, OnUpdate → Update, etc…
  • everything flows down into entities and systems
  • PhysX will be replaced by Unity.Physics when entities is used

Maybe some of my expectations are way out there but I’m not seeing any of these things being solved. To the contrary, so I’m puzzled, what are you actually solving? I’m interested in an use case that applies to a typical game studio.

If it hasn’t been clear by now. Scenes not being baked is a total shocker I probably can not recover from.

I’d be okay on a personal level but I have a stake with the assets I have. I have no idea what even happens to my monobehaviour and DOTS version of my Third person camera.
What if someone buys the dots version and throws it on a scene GO. Now I get an angry email that nothing is working. Well, I can answer, put it in a subscene but he has a MB and PhysX world. So okay, don’t use the really nice baker but put the IComps on the GO yourself. But wait, my dots version expects unity.physics colliders. Let’s back up then, refund and use the MB third person camera instead. It works. But what did we just do? We just went back to MB. Where does the unification kick in?

We can just flip the situation too.

1 Like
2

I hope the new DOTS animation can work with Bakers and ECS. Likewise for the terrain.

I am hoping that the current direction of the GO/Entity unification will help with hybrid; but not replace the current workflow for projects that leverage ECS. If transforms can be unified and it becomes easier to interact with GameObjects that would be a big benefit.

1 Like
3

Gotta admit when I’m in the wrong. I had a crucial thing very backwards which lead to the rest.

I thought unification is used so Entities can use GO specific features easier and without any companion setup but it’s actually the other way around. Unification is added so GO can use Entities easier.

The crucial bit, animations is fully ECS. Glad tertle made me aware because I missed that (very important) detail.

At least I understand the move of having no bakers in scenes now better too. So, all good in ECS land.

4 Likes
4

ECS doesn’t really belong in Unity. It needs to be in its own engine. If they feel the need to add it to Unity then they should just make an ECS particle system component that you can attach to a gameobject along with a script with a callback method for controlling the particles.

Unity is supposed to be relatively easy to use but over the years Unity Tech have lost the plot. But then so have the users… It’s so easy to get lost in the desire for more performance.

Lets not forget the new users that have to learn all this crap.

1 Like
5

No they don’t. The normal practice of using monobehaviours is not going anywhere. DOTS will always be optional workflow you can do on top of the traditional one.

This thread is referring to the ‘ECS for All’ initiative as outlined in the DOTS development update thread: DOTS development status and milestones + ECS for all (September 2024)

I understand it to basically be implementing ECS under-the-hood for game objects/transforms, making it easier to use for those who want to use it.

2 Likes
6

Just to second this point: I haven’t watched the presentations from the event but I did at least read the post about it and that was my take away too. Which is great news if true! It’s what I assumed ECS was going to be back when they first announced it and for the first time since then I’m actually interested to see where it all goes. It’s taken way longer than it should have to get to this point but at least it seems like the efforts to refocus are pointing in the right directions finally.

Edit: Geeze I still haven’t gotten used to how to actually quote a person on the new system :stuck_out_tongue:

1 Like