Handling multiple similar (enemy) types

[adamtomecek]

This is probably more design and/or Rust question, but to me it seems many games need this and I couldn't find any example or question related to the same problem.

My game has multiple enemy types. Every type has some common behaviour like movement and stats. Most of the behaviour is shared - each enemy type moves directly to the Player location - unless enemy is in some special state in which each has a different movement pattern.

Right now, I ended up simply copy-pasting many parts of the code because I have only three enemy types, but I keep thinking there must be a better way. I can't figure out two things:

1. how to spawn enemy while having most of the code shared and only change it's type
2. how to control those different enemies together with same code

I was hoping Traits could solve my problem, so I ended up having Movement trait and implementing it for each Enemy type

pub trait EnemyMovement {
    fn move_enemy(&mut self, player: &Transform, enemy: &mut Transform, time: &Time);
}

#[derive(Component)]
pub struct BasicEnemyMovement;

impl EnemyMovement for BasicEnemyMovement {
    fn move_enemy(&mut self, player: &Transform, enemy: &mut Transform, time: &Time) {
        movement code
    }
}

For spawning, I have a huge setup with colliders, materials etc. and wanted to simply add some of my EnemyMovements based on RNG. And not having to copy the setup for each enemy type.

let movement =  match rng.gen_range(0.0..4.0) {
        x if x < 1.9 => {
            BasicEnemyMovement
        },
        _ => {
            DifferentEnemyMovement
        }
    };

But Rust cannot do this because return type for each branch is different. So I ended up with what I thought is a more sophisticated solution.

let movement =  match rng.gen_range(0.0..4.0) {
        x if x < 1.9 => {
            commands.spawn(BasicEnemyMovement).id()
        },
....
        _ => {
            commands.spawn(DifferentEnemyMovement).id()
        }
    };

let entity = commands.spawn(all my spawning code);
commands.push_children(&[movement]);

But borrow checker prevented that.

I also thought I would be able to have one movement system so I can at least move every enemy type at once. But seems like I also cannot query with dynamic types/traits like that.

pub fn move_enemies(
    mut enemy_query: Query<(&mut Transform, &mut dyn EnemyMovement)>,
   ...
) {
    for (mut enemy, mut movement) in enemy_query.iter_mut() {
        movement.move_enemy(...);
    }
}

Am I really missing something obvious (I hope so!)? Or am I using ECS in a completely wrong way? Or is this possible only using some expert knowledge Rust magic I obviously lack? There must be a better way! 🙂

[rlidwka]

how to spawn enemy while having most of the code shared and only change it's type
I was hoping Traits could solve my problem, so I ended up having Movement trait and implementing it for each Enemy type

1. idiomatic Rust approach is traits
2. idiomatic ECS approach is splitting shared functionality into components

Bevy is an ECS framework, thus it makes sense to go the latter route.

But Rust cannot do this because return type for each branch is different.

Rust can do this. In basic Rust, you would return either Box<dyn EnemyMovement> or a enum (but that won't be a Component anymore).

In Bevy, spawning different things as in your example works just fine (what did the borrow checker complain about?).

Am I really missing something obvious (I hope so!)? Or am I using ECS in a completely wrong way?

If you want to go the way you are going, the most straightforward implementation is generic functions:

pub trait EnemyMovement: Component /*+ etc.*/ {...};

pub fn move_enemies<T: EnemyMovement>(
    mut enemy_query: Query<(&mut Transform, &mut T)>,
   ...
) {
    for (mut enemy, mut movement) in enemy_query.iter_mut() {
        movement.move_enemy(...);
    }
}

But usual ECS approach is to have multiple systems, each of which contains movement code for each individual type (no traits needed).

[adamtomecek]

what did the borrow checker complain about?

the usual temporary value dropped while borrowed consider using a let binding to create a longer lived value on the line with let entity = commands.spawn(all my spawning code); which is after I spawn my movement.

Looking at your answer(s), seems like I'm doing it semi-correctly, just need to figure out the borrow checker problem and should be good to go. The rest of my code probably follows the ECS approach and there's no need to follow Rust approach.

[nicopap]

As mentioned by @rlidwka the correct approach here is using components.

In ECS: Component == Behavior

Typically you won't implement traits on components (outside of the Component trait). Usually distinct components are enough.

In this case I would go with an enum as a component.

#[derive(Component)] 
enum Movement {
  SpecialEnemy,
  Enemy,
}
// in the movement system
  for (movement, mut transform) in &mut query {
    match movement {
      Movement::SpecialEnemy => {
        // update transform based on special enemy movement
      }
      Movement::Enemy => {
        // update transform based on normal enemy movement
      }
    }
  }

If enums are too restrictive for you (this is the case if you need a 3rd party to extend/implement the behavior). You would go with trait objects (the dyn Trait thingies). In which case you would declare the component as follow

#[derive(Component)]
struct Movement(Box<dyn Move>);

// bounds are necessary to allow using this as a component field
trait Move: Send + Sync + 'static {
  fn move_stuff(&self, transform: &mut  Transform);
}