Is there just the one health system, i.e. not one for each actor? If that's the case then I agree that the health system should receive the events, find the needed actors, and then modify their health as needed (or pass it on to the actors to modify their own health).

If it were me, and it has been, I'd send collision events to the actor and let the actor. The actor knows what type of actor (object) it is and how to handle it.

Generally something like health would be contained in a component on the actor itself, probably in a statistics component, along with things like; stamina, speed, etc.

How you link the event that 2 objects collide to a change in your health varies:

- Register a callback, this is almost always something that physics systems implement, usually having 'collision types' that you may have set on colliders. If you are using your own collision system, you could take a similar approach and register callbacks for when actors collide.
- You can also use the event system to send an event when actors are colliding, this will definitely have more overhead than the previous approach.

There are other ways for sure, but I would make these key points again.

- Health should remain the same from actor to actor in a central 'statistic' component.
- Collision should not have a concept of what health is, coupling the health system into the collision system is not ideal
- Possibly a 3rd component (or even a script) would handle the reception of collisions, and would modify the health component accordingly.

Here is a quick example using Lua

The physics/collision component would not contain any game specific code, you would have another component for that stuff, the system components like physics and collision should work for almost any game you plan to make, where a 'Goblin' component would have its own logic strictly for goblins.

You wouldn't need a switch statement at all, instead you would map the collision type to a function callback, what I usually do is have a collision type registry which gives a unique integer to whatever string you pass in, so if you register 'Missile' first, it would get 0, than if you register 'Car' you would get 1, and so on. Depending on how you want to do things, you could have 1 callback that ALWAYS handles 1 set of collision types, ie. Missile-to-Car, or you could have callbacks that would handle each type separately. The first method would likely be more performant. So rather have one large callback with a switch statement that handles all of your collision types, you would have one callback per type.

I would say a good run down on how a collision would turn into game feedback would be.

- Create a 'Missile' actor and a 'Car' actor, both would register with their own respective collision types
- Callbacks would be registered with the collision system, each type would get a callback
- The callback would determine which actors are which in order to utilize them (if using the dual actor callback method)
- The appropriate actions would be taken to make the desired feedback



These are really simple examples, but it should help you.

Thanks