Is this an anti-pattern?

[A-Walrus]

Sometimes I want to run some set of systems in multiple different places (different schedules, or multiple times in the same schedule).
The way I've ended up doing this is:

pub fn systems() -> SystemConfigs {
    (
        update_pos_map,
        add_text_components,
        apply_deferred,
        find_sequences.pipe(get_rules),
        update_active.run_if(resource_changed::<ActiveRules>()),
        apply_deferred,
    )
        .chain()
}

Using it multiple times in same schedule:

        app.init_resource::<PropertyIndex>().add_systems(
            Turn,
            (
                systems(),
                move_you,
                position::systems(),
                systems(),
                check_win,
                check_open_shut,
                apply_rules,
                handle_remove_requests,
            )
                .chain()
                .before(update_sprite_sheets),
        );

Or in multiple schedules:

        .add_systems(
            Startup,
            (setup, apply_deferred, rules::systems(), sprite::systems()).chain(),

Is this a sensible thing to do? Is there some cleaner way to do this?
Thanks!

[lee-orr]

Running the same set of systems multiple times itself is fine, but I would caution against using chain this way unless the entire thing should be sequenced linearly... so, for example, if "check_win" & "check_open_shut" don't have to happen in sequence, I'd recommend not running it as a chain.

Instead I would do one of a couple of things:

• if I have a sequenced situation and want to stick to a non-schedule based solution, I'd do something like this:

(
(update_pos_map, add_text_components),
apply_deferred,
(find_sequence.pipe(get_rules), update_active.run_if(resource_changed::<ActiveRules>()),
apply_deferred
).chain()

• otherwise, if I can separate out the logic into segments that make sense, I might create multiple custom schedules and trigger them in sequences. So for example, I might have:

#[derive(ScheduleLabel, Debug, PartialEq, Eq, Hash, Clone)]
pub struct SetupPhase;

#[derive(ScheduleLabel, Debug, PartialEq, Eq, Hash, Clone)]
pub struct ConstructionPhase;

#[derive(ScheduleLabel, Debug, PartialEq, Eq, Hash, Clone)]
pub struct AttackPhase;

#[derive(ScheduleLabel, Debug, PartialEq, Eq, Hash, Clone)]
pub struct CalcualteResources;

...

app
   .add_systems(SetupPhase, ...)
   .add_systems(ConstructionPhase, ...)
   .add_systems(AttackPhase, ...)
   .add_systems(CalcualteResources, my_repeating_functions_here)
   .add_systems(Update, run_world)

...

fn run_turn(world: &mut World) {
   let _ = world.try_run_schedule(SetupPhase);
   let _ = world.try_run_schedule(CalcualteResources); // Running the calculate resources schedule multiple times

   let _ = world.try_run_schedule(ConstructionPhase);
   let _ = world.try_run_schedule(CalcualteResources);

   let _ = world.try_run_schedule(AttackPhase);
   let _ = world.try_run_schedule(CalcualteResources);
}

Having the systems in multiple schedules is also perfectly fine! It's always more of a question of how is it easiest for you to organize stuff, keep track of it, and make changes as needed.

The main benefit of using the custom-schedule based approach is that it's modular - you can move things around easily, the systems run in the schedule will always be the same systems (taking into account run conditions...), and you can add systems to each "phase" from multiple places. BUT it has the overhead of needing some boilerplate, naming and design decisions. On the other hand, having things in a set of chained systems is really quick and easy to work with and understand, but if you want to replicate a set of systems you'll have to copy that work, and you have to access all the relevant systems from the same plugin build function.

In my experience so far, I tend to start out with a more chain-and-ad-hoc based approach, and then move to more structured solutions (custom schedules, extracting plugins & modules, etc.) as the project grows.