Entity creation/destruction callbacks in DOTS

I've been messing with DOTS for a bit now, and I'm thinking about integrating it with my project slowly. However I need a way to be able to create healthbars for entities which have a HealthData component (I have not thought too much about the case where I want healthdata without healthbars because I might need that, but I'm sure it could be fixed by adding a flag or some other data component). Currently, I am using gameobjects with ConvertToEntity components, and in a start method of some monobehaviour I am instantiating a healthbar prefab which is just a worldspace canvas with some images (I know this is terribly inefficient, just testing) and placing it above the entities that need a healthbar. That is alright, but if I was to create new entities inside a System, I would need a way to create the healthbar in monobehaviour land. Currently I am just calling a Manager from the System and handling the creation of the entities and the healthbars there, same with destruction.

I feel that calling monobehaviour managers (which I dislike using even in conventional unity) defeats the purpose of ECS, so does anyone have a better way to know when an entity has been created/destroyed?

Thank you

 

There is a method AddHybridComponent in GameObjectConversionSystem which you can use to add the HealthBar GameObject to the entity. This health bar is a companion to this entity, which means it will instantiate/destroy along with the entity and also will copy entities Translation/Rotation. So in practice you can have Unit Gameobject (with ConvertToEntity component). This Unit has child GameObject with HealthBar component.

Code (CSharp):

1. public class HealthBar : MonoBehaviour, IConvertGameObjectToEntity {
2. // HealthBar Code
3. ...
4.  
5. public void Convert(Entity entity, EntityManager dstManager, GameObjectConversionSystem conversionSystem) {
6.   conversionSystem.AddHybridComponent(this);
7. }
8. }

*Use 0.6 or 0.9 version of Entities, as other one does not have this feature or have this broken.

 

https://docs.unity3d.com/Packages/com.unity.entities@0.8/manual/system_state_components.html

 

Hm, this is useful information but I don't see how that would work in this case because I still need the image/canvas in regular gameobject land because those are not convertable. Perhaps I'm misunderstanding something, time will tell. Thank you

 

Cool, thank you. However, I still need the events for other systems (such as UI) which have to be in gameobject land, and also from what I understand I will not be able to access any data of the entities after they have been destroyed even if I attach a system state component and handle that in a system.

 

I suggest you use a hybrid approach. Mixing monobehavior with ecs is a valid approach when it makes sense.

What I do in my game is the following: For complex UI involving events, such as buttons and scroll views, I use a good old fashioned Canvas and a mononbehavior to handle all of it. For simple but numerous UI, such as health bars and unit highlighting, I use ECS in combination with manual calls to Graphics.Draw() in its own UI system, not monobehavior.

Basically, unless you want to reinvent the wheel and write a whole UI system that can handle what the normal Unity UI already does and take weeks if not months to implement, a basic rule of thumb is to use ECS and jobs whenever there's lots of computation or drawing to be done, otherwise just use the Canvas.

Though if you do want to go the whole way pure ECS, I remember a thread claiming to have rewritten a lot of the canvas functionality in ECS. You might want to look into that and see if it satisfies your goals.

 

My bad for only glancing over the page, you are absolutely right, they are partly what I'm looking for. However, I still need to have some kind of event if I plan on staying hybrid and using the traditional unity UI> I have found a way to raise events from within systems which works for now so I'll be using that. Thank you

 

I definitely was not planning on going full pure ECS, which is why I wanted to know how to recieve entity related events. (example: show something on screen using traditional UI when my enemy entity dies) But perhaps my question was not exactly what I wanted since things are still a bit foggy.

And for the healthbars that is useful knowledge, I'll be looking into it, thank you.

 

System state components are extremely verbose, I like the core design but when combined with Entities.ForEach I really dislike the high level flow. Can anyone think of a good way to abstract them out a bit, are there any generic patterns you could use with them?

 

Is this new API what you are talking about?

 

I see system state components as more of an optional feature in a reactive system. Reactive might need system state, the component itself, or just the component type depending on the context.

Like you might have several different entities that should only exist together. You might have some notion of a primary or top level entity that once removed all associated entities are removed. The primary and associated might all have different needs for what data is required to cleanup. I tend to think the majority would not actually need system state.

A common pattern we have is logical hierarchies where the top level we need an id from the component to trigger a network message. The rest of the hierarchy can cleanup itself when destroyed without any additional state..