Turbo Makes Games congradulated me on discovering this: Expand your GameObject games to ECS/DOTS

Until now they told you to scrap your old GameObject projects if you want to make a DOTS/ECS project. I'm telling you, you don't have to. With the proper Software Architecture Design Pattern you can keep your player controller, code the enemies in new levels in DOTS, and bingo bango, it works. Sound like magic? Nah I'll tell you the gist:

1) Start with your mature GameObject game and do nothing. Easy first step.
2) Have an int to determine game type if entity game or gameobject level.
3) In entity level: Disable player gameobject rendering and collision.
4) In the start, read in player entity data such as position/facing/velocity/etc into the gameobject rigidbody, etc.
5) Do your normal playercontroller stuff completely unchanged for the rest.
6) At the end, feed in the force vector and angular change into the entity from your gameobject player rigidbody into the player entity.


Works like a charm! If you force velocity or position, you'll mess with collision systems. So don't do that. Only set force and angular change. Of course all enemies must be entities as well as the levels. Your only monobehavior script is the Playercontroller which works for both GameObject levels and Entity levels. If you're smart you can even translate inventory states and such.

Videos about this:

&

I'm making a much better video like tomorrow. I need sleep. I'm exhausted from coding all day and patching my game. If you understand the above videos or description, all your old successful games can now get ECS/DOTS levels!!!! Having just one monobehavior does not really slow it down at all, The problem comes if you try and slog a ton of them together. Just one player mono all enemies and environment will be ECS. It works, I show you it live in those videos.

The beauty of this solution is that you edit the PlayerController once and it updates both the gameobject game and Entity game at the same time. Proper design patterns says to never edit a bunch of similar methods multiple times.

,Jim

 

They did not.

But nice work, regardless!

 

Most people think freedom is great, but a few people will think it'd be awesome to be a dictator. Are "they" for freedom or dictatorships? Depends how you ask. The grand majority of people are for freedom.

Most people do say not to turn gameobject games into updated levels with Entities.... especially people who have attempted it... The grand grand majority said to abandon your old projects. This is why I explained how I did it and how it is easy. I identified a large majority saying NOT to do turn your gameobject game into entity levels. If everyone was saying not to do this, I would have not have posted a solution to it. It would have been a waste of my time.

 

Can you please define, "majority"? This statement is quite bold without backup on your words. Don't you agree?

However, some DOTS developers (not majority, nor officials) suggested in past, that it may be easier to develop game with DOTS in mind, than converting whole game to DOTS.

Saying that, consensus is in general, that DOTS can be used to optimise selected existing systems and behaviours.

However, it may be fairly complex to modify code, which was heavily oriented on OOP design. Or relias on libraries, which uses features not supported by DOTS.

Also, not every game needs DOTS features and such level of optimisations, to work as designed. It is an additional heavy learning curve, on top of existing project. Should be avaluated if required.

 

To me, what you are describing is hell. I would much rather finish my game with the GameObjects workflow than have to maintain sync between MonoBehaviours and ECS in such a "mixing" way. Everything will become more and more difficult to maintain, and as soon as you introduce new features in ECS, you have to introduce it in MonoBehaviour as well or you kind of lose half your levels (and vice versa).

Hybrid workflow, imo, is using GameObjects and Entities in different areas (GO for UI, ECS for simulation, etc...) with as few friction/bindings between the two as possible. Mixing is having an Entity AND a GO for a given "thing", and it feels weird and wrong and I do not want to do that.

Maybe I'm wrong because I do not have enough experience (I actually stopped testing ECS when I encountered a situation that would require me to do such a mixing), but it feels wrong to me to do that, it feels like shooting my own foot for no valid reason other than "I want so much to use ECS I'm ready to injure myself".

If it works out for you, then I'm happy for you, though.

 

Hm, I'm not sure what the discovery is. For a space shooter I don't think you're reliant on the animation system, are you?
So, what's holding you back from going pure DOTS with hybrid renderer and DOTS Physics?
This roundabout way doesn't make much sense to me unless it's for a very good reason. Might have missed the actual reason.

Syncing Entities Transform and Gameobject Transform has been done since the first Entities release. Nothing new about it. While the performance hit of syncing position/rotation can't be solved with entangled GOs and Entities, syncing other values can be and would be a waste of performance that's honestly much more overall than some random read ever would be.

 

>This roundabout way doesn't make much sense to me

As you update your playercontroller once, it works backwardly for your gameobject levels and forwardly towards your entity levels. In software engineering, one goal is always to update your code in one place.