RigelEngine/community

I am planning to add it back as a large comment block in the code for any one to understand in the future.

Ah cool, that's a nice idea, thanks for doing that!

Is there a single entity or 3 different entities for a guard?

There is only one entity. The actor ID is used to parameterize the entity's behavior, but all three actor IDs map to the same entity, and all the logic is handled by the same code.

Where there is a check for type in receive function for shootable damage in blue guard behavior system ? does such event goto every entity which has subscribed to it or does it only goto specific entities which are involved in the event somehow ?

The BlueGuardSystem receives all events of type ShootableDamaged. So you could say that the event goes to "every entity", although it's important to note that entities do not handle events themselves normally, systems do. But indeed, the system receives this event any time a entity with a Shootable component receives damage, for any kind of entity. The event is emitted from the DamageInflictionSystem btw: https://github.com/lethal-guitar/RigelEngine/blob/be5977b2964f7fc7650983246d008d2efa11de4b/src/game_logic/damage_infliction_system.cpp#L131

So the BlueGuardSystem receives all ShootableDamaged events, even those which are emitted for other types of entities (not blue guards). But it's only interested in receiving this event for blue guard entities, so it has to do some filtering. That happens in the first line of BlueGuardSystem::receive, where we check if the entity referenced by the event has a BlueGuard component.

So that's how we check the "type" of the entity which was damaged. But there is not really a concept of "entity type" in ECS, it's more like any entity which has a BlueGuard component will exhibit the blue guard behavior, and reacting to taking damage a specific way is part of that behavior.

what kind of updates?

The idea of "update" is very generic, so it depends on what a specific system does. In ECS, every system is typically updated once every frame. In Rigel, most systems are updated at a slower rate, since the game logic updates only at 15 FPS. But the rendering system for example is updated every frame.

For the blue guard system, "update" means that the guard's AI is updated for the current frame, which can result in different things happening depending on the state of the guard and the player, like the guard might walk one step, or shoot at the player etc.

For other systems, update has a different meaning. For example, the damage infliction system does a collision check to determine if any entity with a Shootable component is touching an entity with a DamageInflicting component, and handles the damage infliction if it finds a collision. The physics system moves entities around if they have a MovingBody component with a velocity set. The player damage system checks the player for collision against any entities with a PlayerDamaging component, etc.

The blue guard's full observable behavior in the game results from the different systems working together to implement all aspects of that enemy. A blue guard entity has a PlayerDamaging component, therefore the player takes damage when touching a blue guard. It also has a Shootable component, so that the player can damage and kill a blue guard by shooting it. The BlueGuard component then holds all the state necessary to implement a blue guard's AI, which involves animation, walking, and shooting at the player. The AI is specific to the blue guard enemy, and therefore needs a dedicated system, whereas the aspects of damaging the player on contact and being shootable by the player are more general and can be used by many enemies. The systems implementing these aspects don't need to know anything about the specifics of blue guards.

In a traditional OOP implementation, you could implement this by having a base class Shootable, from which PlayerDamaging would inherit, and then a class BlueGuard inheriting from PlayerDamaging. But that would be less flexible, becau