The future of a GameObjectEntity (or similar) workflow

I read in a lot of threads here and there that GameObjectEntity will eventually be deprecated in favor of ConvertToEntity. We've just started the development of our next game, and while the ECS way of doing things is great, it's not there yet. There's a bunch of built-in and asset store stuff that is only available as MonoBehaviours and Gameobjects.

We'll probably convert a lot of stuff to ECS in development, but I'm pretty sure we'll need a way for both systems to work with each other, until the moment we ship. Now, the best way to deal with this is having a kind of GameObjectEntity workflow, having both IComponentData and Monobehaviours on some Entities, and systems being able to manipulate those. Either by using GameObjectEntity itself or calling EntityManager.AddComponentObject() manually. Is this bound to disappear?

ConvertToEntity can be useful, but those are not real MonoBehaviours, it's only a conversion. Will the ECS get rid of GameObjectEntities and/or EntityManager.AddComponentObject() to become pure ECS only at some point in the short to medium term?

 

Please don't remove GameObjectEntity yet. I've found that we can't easily port our current implementation to Entity Conversion. It seems like if we use conversion, we have to rewrite every system/managers we have to conform to it. It's just not a smart thing to do for us when the game is already too big.

 

You can use conversion system pretty much exactly the same as GameObjectEntity. What is GOE providing you?

 

Here's our problem with it: https://forum.unity.com/threads/convert-to-entity-is-so-slow.703115/

 

GameObjectEntity is providing us a way to make a GameObject and its components visible to the ECS World. I plan on making a big part of our game in ECS, but some of it can't just be converted for now.

For those things where I absolutely need GameObject and MonoBehaviours, I plan on making something like an hybrid of GameObjectEntity and ConvertToEntity to insert them in ECS. Some of my MBs will convert to IComponentData, the rest will be AddComponentObject'ed, then I'll make systems that will manage all of it.

The thing I like about this strategy is that when some of my MBs will be ported to a usable version in ECS, it will already have a large part of it managed in ECS systems, and the refactoring will be smoother.

 

I think the main problem here is, that ecs in current state is lacking everything other than the foundation. You don't have skin mesh renderer, you don't have animation, you don't have particle system and many more. It's simply impossible to make a game with pure ecs, it's just lacking too many things. So if you want to take the advantage of ECS, you have to somehow connect gameobject with the ecs entity together. I mean, the conversion work flow even won't work for static objects baked with lightmap.
The conversion workflow won't work well if the needed basic build blocks are still missing, because... they are just missing, how can they be converted.

 

This is why conversion has the option of injecting the game object.

 

Really glad to hear that more systems are coming in the next months, because DOTS is recently so deadly quiet which made me a little bit worried about the progress

 

Wow! All those systems are only 1 month away! Thanks Joachim! lol.

I'm always watching this forum but the core ecs has been stable for quite a while and I'm guessing many (me) are just waiting for them to start ecs'ifying various feature systems.

 

That's good to hear. I don't mind if there are no more updates to GameObjectEntity as long as it still works. We're heavily invested in it as far as our game is concerned.