ECS idiomatic way of compontents interaction

[jacek-kurlit]

Hi,

I'm programmer with OOP background and I try to understand ECS better and as I understood it is functional paradigm.

I wanted to create tanks game to learn bevy and now I struggle with one issue - reusability.
In my game tank when tank move it:

• Changes position
• Leave tracks on ground
• Play engine sound
  It also can shoot and rotate etc.
  Tank can be controlled by player and AI but movement looks always as described above. The only difference is who is giving command to tank.
  My question is how to handle this in ECS so both player and AI can ruse same logic for moving tank?
  My first thought is to use OOP and implement it as:

#[derive(Component, Default)]
struct Tank {
    current_transform: Transform, // copy of entity transform obtained during entity spawn
    move_speed: f32,
    rotation_speed: f32,
    bullet_sprite: Handle<Image>,
    tracks_sprite: Handle<Image>,
}

impl Tank {
    fn move_to_new_position(
        &mut self,
        direction: Vec3,
        time: &Res<Time>,
        commands: &mut Commands,
    ) -> Vec3 {
        self.current_transform.translation += direction * self.move_speed * time.delta_seconds();
        // create tracks on ground
        // play engine sound
        self.current_transform.translation
    }
...
}

and system for handling player input

fn handle_player_input(
    mut player_query: Query<(&mut Transform, &mut Tank), With<Player>>,
    keyboard: Res<Input<KeyCode>>,
    time: Res<Time>,
    mut commands: Commands,
) {
    let (mut player_transform, mut tank) = player_query.single_mut();
    if keyboard.pressed(KeyCode::W) {
        let new_position = tank.move_to_new_position(player_transform.up(), &time, &mut commands);
        player_transform.translation = new_position;
    }
...
}

But something is telling me this is not correct way for ECS as I need to keep copy of transform in Tank component while in order to affect player/enemy entity I need to copy it back to entity transform.
What other options are there?
Should I use multiple system to achieve that or maybe events?

[nicopap]

Well, it's difficult to judge of the quality of code when there is no line returns 🙂 . here is how to format code on Github I'll update this answer after I've copy/pasted your code in my text editor and inspected it myself

[jacek-kurlit]

I'm sorry, I have used single ` instead of tripple.
Now it is fixed

[nicopap]

A few things. I think you are overthinking this, I think you wrote pretty fluent bevy ECS-style code!

There is a few recommendations:

• Why store a Transform in the Tank component? The single responsibility principle would require to read & write from the Transform component rather than copy it in Tank. In any case, whenever you need the Transform of a tank in a system, you can always query it. And you can always pass it as argument to a method of Tank if needed.
• Why not write a system dedicated to moving tanks? handle_player_input can only handle... player input! Maybe abstract the "intent" into its own component and work on that when moving the tank. For example:

fn update_player_intent(
    mut player_query: Query<&mut MoveIntent, With<Player>>,
    keyboard: Res<Input<KeyCode>>
) {
    for mut intent in &mut player_query {
        if keyboard.just_pressed() {
            *intent = ;// ...
        }
    }
}

enum Direction { Up, Down, Left, Right }
// For a crate that does it for you, use
// https://crates.io/crates/leafwing-input-manager
#[derive(Component)]
struct MoveIntent {
    direction: Direction
}
fn handle_tank_intent(
    mut tank_query: Query<(&mut Transform, &mut Tank, &MoveIntent)>,
    mut commands: Commands,
    time: Res<Time>,
) {
    for (mut transform, mut tank, intent) in &mut tank_query {
        // move_to_new_position(&mut self, Transform, &MoveIntent, &Time, &mut Commands)
        let new_position = tank.move_to_new_position(*transform, intent, &time, &mut commands);
        transform.translation = new_position;
    }
    
}

Now the AI can have its own system (say update_ai_intent) and just update their entity's MoveIntent component, the handle_tank_intent will use MoveIntent, whether it's set by update_player_intent or update_ai_intent.

Also note that people would prefer implementing the logic in the handle_tank_intent system rather than in a method of Tank and calling that method. This is because ECS logic usually depend on several components and your methods end up having a lot of parameters. You don't want to "encapsulate" several components into structs.

[jacek-kurlit]

Thank you for the answer! This is what I thought it should look like.
I was also thinking about using events instead of Move Intent but it would be problematic to get transform related to with the event right?

[nicopap]

An event would work, but you then need to keep track of the related entity in your event type

struct MoveRequest {
  to_move: Entity,
  direction: Direction,
}
fn handle_tank_move_request(
  mut requests: EventReader<MoveRequest>,
  mut query: Query<(&mut Transform, &mut Tank)>,
) {
  for request in requests.iter() {
    let Ok((mut transform, mut tank)) = query.get_mut(request.to_move) else { continue };
    if request.direction == foobar {
      transform.translation = bazbar;
      // etc
    }
  }
}

It's not worse or better, just different. The advantage of a component is that it's always associated with an entity. Another difference is that events are not persistent, so you need to handle them differently from a component.

[jacek-kurlit]

That's clarify a lot, thanks!

[minecrawler]

Something I always keep in mind is: Don't put logic onto components! Create a system for it. Systems can be very generic and adapted for a variety of uses. You don't fall into an inheritance trap with them as well, since systems are composited (Composition over Inheritance!)

Also, only put the most specific information into component fields, so that you can reuse the other parts (like Transform) in the ECS context. That becomes useful when you want the transform, but not the rest of the tank. You'd always need to work with the specific Tank object instead of the generic Transform. What if you want to add other objects, like trees, houses, bikes, humans and dragons and want to calculate collision? What if you want the bikes and humans to reuse the movement logic? If you don't separate common stuff out, you'd need to write logic for every specific object :)

[jacek-kurlit]

Thank you for answer.
I have OOP mindset and putting logic into objects is the way I think but I'm always eager to try different approaches.