Best practices for systems which must operate on non-exclusive lists of components?

[meowitzher]

I am trying to set up a damage system in Bevy. There is a Health component and a Damage component. The naive approach is to get all of the objects with health in one query, get all of the objects with damage in another, then loop through them both and check for any collisions, reacting appropriately, etc. etc.

Naturally, the player has a health component, but doesn't need a damage component. Projectiles like lasers need a damage component, but don't need a health component. There's a simple system we can use for these purposes:

fn damage_system(mut health: Query<&mut Health, Without<Damage>>, mut damage: Query<&mut Damage, Without<Health>>)

The problem comes when we start to think about the types of components we could have on more complicated entities. It is common to have enemies deal contact damage, for example. Presumably these would need both damage and health components. We'll call such entities "contacts" for the purposes of brevity.

We now need to check the following:

1. if a contact has damaged an entity with health but no damage
2. if an entity with damage but no health has damaged a contact
3. if two contacts have damaged each other.

(Option 3 can be ignored depending on the design of your game, but for generality I'll include it.)

In order to cover all of these possibilities, while respecting the rules of queries needing to not overlap, we can accomplish this with three systems total which essentially do exactly the same thing. (In theory we'd need four including the above, but we can fold that into Option 2):

fn contact_health_system(mut health: Query<&mut Health, Without<Damage>>, mut contacts: Query<&Damage, With<Health>>) 
{
    //Handles Option 1
}

fn damage_system(mut health: Query<&mut Health>, mut damage: Query<&mut Damage, Without<Health>>)
{
    //Handles the first case and Option 2
}

fn contacts_system(mut health: Query<(&mut Health, &mut Damage)>)
{
    //Use .iter_combinations to handle Option 3
}

While this works, it definitely feels quite inelegant. It also scales badly if we include more optional components which are interacting. In looking for solutions, I found the ParamSet functionality in the Bevy cheatbook, but given that we can't access it's composite parts simultaneously, it doesn't seem to help in this instance. Another option seems to be using an exclusive system with world access, although to me that feels even more inelegant and overkill than should be necessary.

Does anyone have advice or tips on better ways to achieve this functionality, or is this probably the best way to go? I recognize that ownership and mutability rules might just be in the way here somewhat unavoidably. The best solution I've been able to imagine is adding a third marker component, getting a query of all marked entities, then using .iter_combinations and only acting if the first has a health component and the second has a damage component. However, I'm not sure of the ease/efficiency of checking components on an entity, and the $n^2$ scaling on .iter_combinations seems like it would bloat the system with needless damage v damage and health v health checks.

[tim-blackbird]

I came across the same issues myself. I've solved this, plus the issue of code duplication, using events.

pub struct DamageEvent {
    pub damage: f32,
    pub target: Entity,
}

pub fn process_damage_events(
    mut events: EventReader<DamageEvent>,
    mut health_query: Query<&mut Health>,
) {
    for &DamageEvent { damage, target } in events.iter() {
        // If this entity has a Health component, damage it.
        if let Ok(mut health) = health_query.get_mut(target) {
            health -= damage;
        }
    }
}

fn contact_damage(
    mut events: EventWriter<DamageEvent>,
    query: Query<(&ContactDamage, &CollidingEntities)>,
) {
    for (contact_damage, collisions) in query.iter() {
        for target in collisions {
            events.send(DamageEvent {
                damage: contact_damage.damage,
                target,
            });
        }
    }
}

Now, any system that deals damage in some way can simply send a DamageEvent.
This is useful to avoid dealing with aliased mutability, and the process_damage_events system is now the only place damaging the Health component so adding extra logic to damaging entities is a lot easier.
Say for example you wanted to add Armor to entities to prevent some damage, now you only need to modify one system instead of all of these different systems.

[meowitzher]

Thanks for this! Events definitely seem like a useful concept for reducing code re-use, I can think of a few other places in my code they'd be handy.

However, I do think that having a list of all colliding entities doesn't fit that well with the way I'm approaching things. I'm using the types of entities which interact as a level of my broad phase: no need to check collisions between entities that have no systems they interact in. So collisions between lasers and coins, for example, are never even looked for.

It seems like I still need for multiple systems to generate the events, but it's absolutely an improvement to only have the actual logic be performed in one system. (Especially for system ordering!)

[tim-blackbird]

i'm using bevy_rapier, so it's re-using the broadphase/narrowphase from there, and the colliders have layermasks so the unneeded interactions (like between a laser and a coin) are skipped at that stage.
That way CollidingEntities will only ever contain the relevant entities (for the most part q:).

[meowitzher]

I figured, and that's a great system!

My layer mask checks occur inside of my systems, so after that "phase" of the collision detection, but before the narrow phase of actually checking collisions.

I doubt it's as efficient as the complexity of the game grows, but I find it easier to develop when I have less external crate code such as rapier to worry about interfacing with when it's not necessary.

[meowitzher]

An alternate method I've found (marking the other answer as correct as I think it is the best for most users not doing weird stuff like me), is using Parent and Child entities. Contacts can be simulated by having a parent entity with a Health component, and a child entity containing the damage component. This allows us to just use the first system as there will be no overlap between entities having a Health component and a Damage component.

The Bevy Cheatbook has a great chapter on them for those interested: https://bevy-cheatbook.github.io/features/parent-child.html

The downside of this is potentially having duplicate copies of our colliders when the hit and hurt boxes for a contact are the same, but it also has upside that they are different by default, so there's no extra code needed to accommodate two different shapes for the same entity.