Is this a good practice? Calling systems by command.

[EmmiaSilk]

In my current project, I have found myself frequently wanting to call functions which benefit from system dependency injection. I recently discovered Commands.run_system and Commmands.run_system_with_input, which allows me to queue up calls without needing to pass around dependencies manually.

As an example borrowed from my Cursor implementation:

pub fn listen_player_status_event(
    mut events: EventReader<PlayerStatusEvent>,
    mut commands: Commands,
    systems: Res<CursorSystems>,
) {
    for event in events.read() {
        match event {
            PlayerStatusEvent::Join(player) => {
                commands
                    .run_system_with_input(systems.on_player_joined, *player);
            }
            PlayerStatusEvent::Leave(player) => {
                commands.run_system_with_input(systems.on_player_left, *player);
            }
        }
    }
}

pub fn on_player_joined(
    In(_player): In<GamepadPlayer>,
    mut query_cursors: Query<(&GamepadPlayer, &mut Sprite)>,
) {
    // ...
}

fn on_player_left(
    In(player): In<GamepadPlayer>,
    mut commands: Commands,
    query_cursors: Query<(Entity, &GamepadPlayer), With<Cursor>>,
) {
    // ...
}

If I wanted to call on_player_joined and on_player_left directly as functions, I would have to instead pass references to all of their dependencies, which also means including their dependencies in the parent function. This quickly leads to dependency hell, which is avoided by queueing them as system commands. This does, however, come with the downside of being harder/impossible to parallelize.

Is this a good practice? Is there a more idiomatic way of doing this?

[james7132]

If the systems are not expected to run regularly (i..e only when a player clicks a specific button, or steps on a specific trap), by all means, use Commands::run_system. Your use case seems to be very well suited for this kind of approach, assuming PlayerStatusEvent is seldom triggered.

If you're expecting to run the system every frame, or even once every 10,000 frames, you might want to use a normal system with a run condition instead.

[haath]

Even though I do like this pattern, I still have to ask out of curiosity: why not just use events?

Or rather, did you discover some case that can't be elegantly handled with events?

[lucidBrot]

@haath since you asked "did you discover some case that can't be elegantly handled with events?", prepare for reading some rambling of a bevy beginner :)

I'm not OP but I keep finding myself wanting to use something similar too. The reason why I don't like using events is that I don't want to create another layer of indirection that makes it more confusing to understand the code flow.

I know, that's more or less going against the whole point of using an ECS, but I find it much more readable to have a normal function call, and passing all the Query arguments along.

For example, I have a mouse click that launches an event to start a level. There's a setup_level system that reacts to this event. It has to destruct one level and construct another, depending on what the current and next level are. If I use Events for this too, I have to carefully think about how to ensure they run in the right order (destructing the old level before constructing the new one). And then do it by specifying the required order in a different place (usually in the plugin's build function).

It's much simpler to just call two functions. And if the loop that works through the event queue sees more than one level start, I'll know that it will first finish setting up the first level, before changing to the second.
But then I must pass all parameters along. A small price to pay for simplicity. And it is probably slower, because the systems can not be parallelized as nicely as when they are separated.

Using commands.run_system((destruct_level, construct_level).chain()) is similar to just calling two functions but now the constraint and logic are in the same place as the calling code. If that chaining even works like I just imagined it. Now that I am writing this, I realize the drawback is that the ordering of handling multiple events in is probably no longer really guaranteed...

This whole text is not supposed to be a criticism though, I wouldn't have written this if you hadn't specifically asked why anyone would want to use this. Events do their job.

Writing this all out, it does seem like the easiest way to write the code that does the right thing is to use events and specify an ordering for the systems. But then it gets overwhelming after a while and I feel the urge to draw a map that shows which system "calls" or "depends on" which other system.