#[auto_system] simplified system configuration

[stepancheg]

I struggle the most with Bevy system configurations.

When the number of systems is greater than 100, and you are doing rapid prototyping (rather than slowly developed and peer reviewed mod for example), bugs are unavoidable. I have already encountered several incorrectly configured systems in my yet very small application.

Moreover, code refactoring is hard. For example, the number of code changes needed to move system from one file to another, or split a system into two systems, is too high.

I posted about it before, and suggested a few approaches to fix it, for example:

• Before/After barrier RFC: Barriers with Before/After markers #10618
• Parameter metadata RFC: SystemParam::user_meta #10678
• Non-unique resources NonUniqueResourceId rfcs#73
• Better piping requested by someone else Explore other potential approaches to bevy system piping. #8857

So far, none was accepted, unfortunately.

Here I'm describing an approach I'm using in my project.

#[auto_xxx]

TL;DR

Using fictional example. Code looks like this:

/// Logical, rather than physical camera position
#[derive(Resource, Default)]
#[auto_resource]
struct MyCameraPosition { x: i32, y: i32 }

#[auto_system]
fn process_keyboard(
  input: Res<Input<KeyCode>>,
  #[before]
  camera: ResMut<MyCameraPosition>>,
) { /* handle keys, update camera */ }

#[auto_system]
fn update_camera(
  #[after]
  camera: Res<MyCameraPosition>,
  actual_camera: QueryMut<&mut Transform, With<MyCameraMarker>>,
) { /* sync MyCameraPosition to actual camera transform */ }

And finally, my app main function looks like this:

fn main() {
  let mut app = App::new();
  app.add_plugins(DefaultPlugins);
  apply_auto_configs(&mut app);
  app.run();
}

And that's it. Functions are private, no plugins, systems are not added explicitly. Just add these functions, and all systems and resources are installed.

How does it work

Basic idea is this.

I'm using linkme crate to collect configurations.

"Framework" implementation is these 7 lines of code:

#[doc(hidden)] // Populated by proc macros, not used directly
#[linkme::distributed_slice]
pub static AUTO_CONFIG: [fn(&mut App)];

pub fn apply_auto_configs(app: &mut App) {
    for config in AUTO_CONFIG {
        config(app);
    }
}

AUTO_CONFIG contains all the configurations, and apply_auto_configs needs to be called from my app main plugin.

AUTO_CONFIG is populated by proc macros. For example, for #[auto_resource] proc-macro generated code looks like this (first level of proc macro expansion):

#[linkme::distributed_slice(AUTO_CONFIGS)]
static auto_config_CameraController: fn(&mut bevy::app::App) = {
    |app| {
        app.init_resource::<CameraController>();
    }
};

What annotations are supported

#[auto_config]

The most generic one: takes an &mut App, and runs code on it.

#[auto_config]
fn default_cursor(app: &mut App) {
    app.add_systems(
        OnEnter(CursorState::Default),
        set_window_cursor_icon(CursorIcon::Default),
    );
}

Kind of auto-discoverable lightweight plugin.

#[auto_plugin]

Applied to Plugin, calls app.add_plugins().

#[derive(Default)]
#[auto_plugin]
struct MyPlugin;

impl Plugin for MyPlugin { ... }

#[auto_resource] and #[auto_state]

Calls app.init_resource() or app.init_state():

#[derive(Resource, Default)]
#[auto_resource]
pub struct MyCameraController { ... }

#[derive(States, Default, Copy, Clone, Debug, Eq, PartialEq, Hash)]
#[auto_state]
pub(crate) enum MyAppState {
    #[default]
    Normal,
    Console,
}

#[auto_system]

And finally, the most useful one is #[auto_system]:

#[auto_system(
  schedule = Startup, // Update by default
  before(system1, system2), // equivalent to `.before(system1).before(system2)`
  after(system3, system4),
  run_if(in_state(ControlState::Console)),
)]
fn my_system(
  #[after]
  read_resource: Res<MyRes>,
)

Arguments for #[auto_system] are self-explanatory.

But additionally, Res or ResMut parameters of the system can be marked as #[before] and #[after].

• #[before] translates to .before(ResourceTypeSet::<MyRes>::new())
• #[after] translates to .after(ResourceTypeSet::<MyRes>::new())

So systems with #[before] and #[after] on the same resource have dependency relationship using shared system set ResourceTypeSet<MyRes>. (And the same with events.)

Potential extension: groups

In my kitchen sink implementation all configurations are added into the same group. Could possibly be extended to have groups of configurations, for example:

#[auto_system(group = stress_test)]
fn my_system() {
}

fn main() {
  ...
  if args.stress_test {
    apply_auto_configs_from_group(&mut app, "stress_test");
  } else {
    apply_auto_configs(&mut app);
  }
}

Final thoughts

With "groups" this can be used to configure Bevy and Bevy mods, but I don't think it is needed there, because the complexity of Bevy core and Bevy plugins is not in system configurations. Moverover, this setup does not support generic code (e.g. if an #[auto_system] needs to be instantiate twice with different type parameters).

This might be useful mostly for final applications developed by Bevy users.

I'm certain Bevy needs some solution to reduce boiledplate of system configurations. I'd say core Bevy needs it, but perhaps as a mod.

Unfortunately, it is unlike I will be able to publish this code as an open source project — I don't have time cannot maintain it long term.

The best I can do is either:

• show the code to someone who might be interested in maintaining this project
• submit it to core Bevy with tests, documentation and everything, but without promise to support it — I have free time now, but I won't have time in a few months

[tim-blackbird]

The linkme crate cannot be used because it does not support wasm. dtolnay/linkme#6 (comment)

[tim-blackbird]

As I said, it can be supported by generating code instead of relying on linker. If your main platform is not wasm, this is fine.

Can you elaborate on this? There's no issue as long as wasm can be supported in a reasonable way.

You don't have to use it.

The issue is that it can't be used in any part of Bevy itself or any third party plugin that wants to support wasm. A situation where you have to avoid using a core feature to maintain wasm support seems untenable to me.

[stepancheg]

Can you elaborate on this?

On linux it relies on linker:

#[linkme::distributed_slice]
pub static AUTO_CONFIG: [fn(&mut App)];

on wasm that would be:

pub static AUTO_CONFIGS: &[fn(&mut App)] = // this file is generated

This code can be generated by running an app on linux (or mac or windows) with a flag, or env variable which regenerates this file (using information from linker).

Another possibility is to generate this file just from build.rs. We only need symbol names, these are easy to obtain by naive parsing of .rs files.

[cart]

Adding a piece the most core part of Bevy that doesn't support a major platform like wasm, in a reasonable way, is extremely unlikely to happen. I'd personally be against it.

I feel the same way about this. I have no interest in adding official "core" ECS patterns that only work on some platforms (and might not work on future platforms). Its the same reason we aren't using linkme for things like "reflect type registration".

Introducing another build step (especially external commands, but also build.rs) to generate the binding code for these platforms is a level of jank that I do not consider worth what we gain. Ex: would the build.rs re-scan and parse every file? What would that do to incremental compile times?

[cart]

Introducing this officially would be "infectious". Some subset of Bevy plugins would choose to use this pattern and then suddenly a bunch of people need build.rs jank to support all platforms.

[stepancheg]

would the build.rs re-scan and parse every file

Only on wasm. And it is relatively cheap. For example,

time shasum crates/**.rs | wc -l

in bevy repository (tens of crates, 541 file, 172 KLOC) takes 80 milliseconds.

Some subset of Bevy plugins would choose to use this pattern

As I mentioned in the original post, plugins are not meant to use it unless they specify a "group" and initialize the systems inside the plugin, not rely on user using auto configuration.

Anyway, my problem is mostly solved, so I wanted to share my experience. If Bevy maintainer do not consider boilerplate for system configuration problematic, no solution will be good enough.

[SkiFire13]

This would also be problematic with multiple Apps. More in general, global state/configuration are undesiderable, see for example #6101

[stepancheg]

Multiple apps are either

• not needed for most people
• secondary apps don't have to be configured this way
• or can be configured using groups

Regardless of that this is not meant to be universal 100% replacement of manual configuration.

[IronGremlin]

Your general gripes about system initialization and interdependency are not widely accepted as shared pain points.

This means either you are trying to solve your problems in a way that is distinct from the way others are trying to solve these same problems, or, it means you've found novel problems.

Because you have not currently mentioned any novel problems, and because the examples you provide do not seem novel, this suggests that you're just trying to solve things in a different way, and because you are experiencing pain nobody else seems to be experiencing, I am forced to conclude that the way you've identified to solve these problems is what we know colloquially as "a bad way."

If you were to share either the ways in which you've tried and failed to solve these problems, or the novel nature of the problems causing you this pain, it might help the reader to take your suggestion more seriously.

As is I see an inadequate and over complicated set of tools to solve a problem I don't have.

[stepancheg]

are not widely accepted as shared pain points

I do not understand that.

I have three likely incorrect explanations of that:

• either users of Bevy do not write sufficiently large programs
• or do not aim at writing a lot of code fast
• or do not aim at making their programs work like clockwork, where systems are executed correctly in the same frame without randomly delaying signal to effect by one frame or more

If you were to share either the ways in which you've tried and failed to solve these problems

The way I usually write code: I just rapidly write a lot of code, and constantly change it, refactor and reshuffle.

Nothing unusual: just systems with before/after dependencies. Almost every system has at least one dependency, usually more than one.

It is hard to explain without showing the real commits.

One example.

Yesterday I had to refactor code which updates "game state". (For certain performance, complexity, testing reasons it is stored as single resource, not as millions of entities).

• Systems which update the state should be scheduled before the "tick" (e.g. code which handles "click")
• Systems which update the graphics from the game state should be scheduled after the "tick"

So the systems now look like:

// These are in different files, and actually there are more than three of these

#[auto_system]
fn handle_click_to_spawn_something(
  ...,
  #[before]
  state: ResMut<GameState>,
) { ... }

#[auto_system]
fn game_tick(
  #[in_set]
  state: ResMut<GameState>,
) { ... }

#[auto_system]
fn sync_state_to_graphic_entities(
  #[after]
  state: Res<GameState>
  commands: mut Commands,
) {
  // spawn/despawn
}

This is how it works now, in Update schedule.

Yesterday "tick" was in FixedUpdate schedule, and I needed to move it to Update schedule and update dependencies (to reduce delay between state and visuals/signals).

How I did it? I found all the references to Res<GameState> and ResMut<GameState> and marked them as #[before], #[after] and #[in_set].

(I literally just clicked "Find usages" in CLion, and it has shown me all the system params of that resource).

And now I'm certain that ordering is correct.

Moreover, when I'm looking at certain system (function signature), I just see from the system function signature that it is scheduled correctly: #[before] and #[after] annotations are right there. I don't need to go to plugin build to double check it.

If I split a system in two, or merge two into one, I'm certain ordering is correct, because again it is right at hand.

Official way to support this ordering would require extra steps:

• create a SystemSet label
• mark all the systems with these labels (before/after/in_set) (tens line apart from system declaration)
• every time function is mechanically split, look carefully at Plugin to check that everything is annotated correctly
• do it every time when refactoring something
• and yet, still not be certain that you did not forgot to add ordering in one of tens of places

One guy in another thread implicitly suggested that I'm just dumb because I don't keep all the setup in my head. Well, this is partially true (I don't keep it in my head) but that guy is wrong (his implications only mean he is not working as efficiently as he could). Best programmer is lazy programmer. I don't want to think carefully about system ordering, I don't want to remember things, and I don't want to check and recheck everything. I better spend my brain energy on thinking about the project I want to do, and let the machine do mundane task of configuring the systems.

I don't think my problems are special. Just usual problems. But I need to automate more.

[IronGremlin]

or do not aim at making their programs work like clockwork, where systems are executed correctly in the same frame without randomly delaying signal to effect by one frame or more

90% of the time I encounter a problem about system ordering, I solve it by redefining the problem such that my systems don't need to care. The other 10% of the time I either try to identify an approximate phase in some sort of linear processing pipeline and slap it into a custom schedule, I use a pipe, or I just consolidate the systems into one system.

After I've gotten used to solving problems in this way as a default, the rate at which I even need to think about it at all has dropped off drastically. Most systems I do not explicitly order beyond simply assigning them to some quasi-relevant custom Schedule or SystemSet.

Almost every system has at least one dependency, usually more than one.

I am not looking at real code here, so I reserve judgement, but this sets off some alarm bells for me. Like if you are needing to chain or before/after every system you write, there's something seriously wrong going on.

Let's take a look at your suggested steps for solving this category of problem.

create a SystemSet label

Potentially this is good, I might note here that custom Schedules are often also a really good tool to use. Also I'm sure this is a nit, but just in case, we are talking about like a chain of related system sets, right? Because we're describing what happens when we've identified an unresolvable concern that requires specific linear processing? And not like somehow something you're going through every time you write a new function?

mark all the systems with these labels (before/after/in_set)

All of which systems? How many? Why/how have we suddenly identified a linear processing concern somewhere that was somehow a surprise that seems to concern a wide variety of different systems?

every time function is mechanically split, look carefully at Plugin to check that everything is annotated correctly

What do we mean by "mechanically split?" Why are we including checking these concerns if we've explicitly ordered a system, but not if we used your implicit "via param" method? Is it more difficult to check how we've set up system ordering in the bounds of the setup / initialization code for the Plugin that owns this set of systems or to look throughout our entire ****ing application to find every use of a specific parameter?

and yet, still not be certain that you did not forgot to add ordering in one of tens of places

The declaration of ordering is generally local to the logical constraint that imposed the concern of the ordering.

If that is spread out all over the damn place, I've made a bad architectural call somewhere.

To be honest I would consider the whole idea that you'd base system ordering around a specific resource param as a MASSIVE red flag, because it implies to me that you're describing a system for carefully arranging reads and writes to a shared global state, and that this is somehow a technique that you are using with great frequency.

Like -maybe- you might somehow come up with something that required that, but like, that should feel wrong and dirty architecturally. You should be looking for tools to avoid doing that, not looking for tools to make that easier.

[stepancheg]

I use a pipe, or I just consolidate the systems into one system

• Reduces parallelism
• Does not allow multiple consumers or multiple producers
• Generally introduces unnecessary dependencies in code (for example, module which does state update logic has to pick into module which does graphics)

if you are needing to chain or before/after every system you write, there's something seriously wrong going on.

It is entirely possible that I don't understand something, but for me it looks like if someone adds a system without any ordering (before/after/chain/in_set/pipe etc in default schedule), they are doing something wrong. Because the system will work on the wrong frame.

custom Schedules are often also a really good tool to use

Reducing parallelism.

Basically, this solution is somewhat equivalent to "let's just put all the systems into one big fancy chain", explicitly.

What I say, let's just declare interface dependencies (or barriers), and let the machine sort it out.

mark all the systems with these labels (before/after/in_set)
All of which systems?

All systems which need to be executed strictly before or after "tick" in my example above unless they have implicit dependencies via other systems.

• For example, there's a system which computes location based on window cursor. It updates resource CursorLocation.
• Then there's a system which reads CursorLocation, and tries to match it to a building or an animal. Depending on what it picks, it updates BuildingSelected or AnimalSelected, but not both, because that's what I want. It is automatically scheduled after previous system
• System which works with building reads BuildingSelected resource and updates GameState (and automatically "after")
• System which works with animal reads AnimalSelected resource and updates GameState (also automatically "after")
• Then game state reads GameState and automatically scheduled after two previous systems

What do we mean by "mechanically split?"

I have a system, for example, update_animals. During development it grew large, and I split it into update_cows and update_sheep. Like refactor a bit, and half of code goes into one system, and another half goes to another system.

Is it more difficult to check how we've set up system ordering in the bounds of the setup / initialization code for the Plugin that owns this set of systems or to look throughout our entire ****ing application to find every use of a specific parameter?

Suppose in this hypothetical example, systems updates resource like Animals.

Parameter is annotated with #[before]. If I split the system in two, both systems get ResMut<AnimalsUpdate> parameter, which I annotate with #[before] just by copy-paste.

If for some reason, I want to split resource AnimalsUpdate into CowsUpdate and SheepUpdate, I automatically naturally mark it with #[before] on update side and #[in_set] on process side.

The declaration of ordering is generally local to the logical constraint that imposed the concern of the ordering.

In my case, logical constraint is a resource. Systems which write to the resource are marked #[before]. Systems which read from the resource are marker #[after] (this is simplified description).

Like on the writer side I don't care who is going to read it, I only care that writes are before reads.

And on the reader side, I don't care who writes it, I only care that I process it after whoever writes this resource, or several resources from different subsystems.

MASSIVE red flag
wrong and dirty

Your opinion is appreciated.

In my opinion the approach I propose actually makes code not just easier to write, but also much cleaner (on the writer side I don't know and don't care who exactly reads it and vice versa). Like dependency injection and separation of interface and implementation.

I think I just failed to explain it. Sorry about that.

[IronGremlin]

Basically, this solution is somewhat equivalent to "let's just put all the systems into one big fancy chain", explicitly.

No, not even remotely close. Custom schedules give you more "buckets" into which to throw code that'll execute at the same time.

Using custom schedules without thinking too hard is answering "How early does this need to run" with an answer like "Kind of!" instead of an answer like "stage 0.16."

If we run into problems, then we solve that problem, but because we're being good ECS citizens and writing stateless systems, the vast majority of our logic isn't interrelated in such a way that it needs to give a crap about precisely when it executes.

As long as "Kind of early" executes before "middle of the frame" and "late in the frame", everything will go fine, if we need more fine-grained control for a specific reason, we can use something more complicated.

[animal vs. building selection]

Yeah I just solve for this by having a run-condition on the appropriate resource(s). Way easier than treating it as an execution ordering concern. I might also use an event queue if I care even less about exactly what frame the action gets resolved in.

Run conditions are a really strong tool for that kind of thing.

I have a system, for example, update_animals. During development it grew large, and I split it into update_cows and update_sheep.

Sorry, I meant like, what do we mean in terms of behavior that makes us care about this from a system ordering perspective?

The way I see it, when this happens, you have three basic scenarios:

• We haven't introduced a new ordering concern because this logic can safely run in parallel because it's being dispatched against different sets of entities, so, they all go to the same spot in the graph
• We identified a specific reason this workload might benefit from being split, which implies it's own specific ordering constraints local to the functionality I am splitting, in which case, the "root" of this new graph stays at the same place and the "children" don't need to care
• We haven't introduced a new ordering concern but we do have a bunch of code overlap between our "children", so we make a utility function (typically I do this via a shared SystemParam method)

None of those generally have any kind of cascading implications, which is part of why I am confused.

[general responses to my commentaries around code smell]

It should not be controversial for me to indicate that stateless systems are the norm and that stateful concerns regarding global resources are a code smell in the context of an ECS.

In my opinion the approach I propose actually makes code not just easier to write, but also much cleaner

Yes, but if your motivation for writing code like this is that you want to be able to define system ordering as a set of stateful operations against global resources, you have not used an approach that helps you write good ECS systems.

This is like building a hammer with which to break the wings of Pegasus so that he sticks to the road when you ride him.

[stepancheg]

Basically, this solution is somewhat equivalent to "let's just put all the systems into one big fancy chain", explicitly.
No, not even remotely close. Custom schedules give you more "buckets" into which to throw code that'll execute at the same time.

Or system sets, which at least allow some parallelism for unrelated systems.

So you say, you do care about system ordering. But you do it by organizing code into buckets.

This is suboptimal:

• unnecessarily reduces parallelism
• forces to design stages (unnecessary mental overload)

For example, I have systems:

• converts window cursor to ray (consumed by several systems depending on the state)
• intersect ray with entity (again, consumed by different systems depending on what entity is picked)
• handle key press to do something with entity (multiple systems)

These must be executed in this order.

Three stages already, and it is not yet the end of the loop. What if I need to split "intersect ray with entity" into two systems: one which converts ray to game coordinates, and another which converts game coordinates to entity — should I introduce another stage and reshuffle all the systems? Maybe that's perfect design on paper, but a lot of headache.

In my case, I just declare dependency using the barrier resource.

Run conditions are a really strong tool for that kind of thing.

I use run conditions. run_if is in the example I posted. Run conditions and ordering are not directly related.

I have a system, for example, update_animals. During development it grew large, and I split it into update_cows and update_sheep.
Sorry, I meant like, what do we mean in terms of behavior that makes us care about this from a system ordering perspective?

I mean, if there's some ordering implied for the original system, this ordering must be preserved in the new two systems.

I must not accidentally lose dependency or dependent on any of the new systems. And not introduce unnecessary dependency by the way (which would happen if I just copy-paste initialization code in the plugin).

If we run into problems, then we solve that problem

One frame delay, and problems reproducible only on certain machines (like with more CPUs) under certain system conditions (like heavy CPU load), and not exactly the problems easy to fix or even to detect.

I'm quite certain that many real world projects in Bevy have unintentional one frame delay for certain operations — simply because missing dependency is too easy to overlook.

It should not be controversial for me to indicate that stateless systems are the norm and that stateful concerns regarding global resources are a

There are no stateless systems. With rare exceptions system exists to to modify something (resources, entities, events, states, etc).

One is not necessarily better than the other. I use resources, because they are the most basic primitive. I could easily use events for example, and synchronize on events, would be the same from different angle. Or entities. It does not matter.

It should not be controversial for me to indicate that stateless systems are the norm and that stateful concerns regarding global resources are a code smell in the context of an ECS.

Are there some de facto code style for ECS or something?

Again, I could easily change synchronization to entities instead of resource using the same #[before] and #[after] annotations. I just don't need it.

the vast majority of our logic isn't interrelated in such a way that it needs to give a crap about precisely when it executes

I don't care when precisely it is executed. But I care greatly about about relative ordering between certain systems which are logically directly connected.

System A makes some change, and system B must observe this change in the same frame, so I add dependency link between A and B. That's it.

[IronGremlin]

For example, I have systems:

• converts window cursor to ray (consumed by several systems depending on the state)
• intersect ray with entity (again, consumed by different systems depending on what entity is picked)
• handle key press to do something with entity (multiple systems)

I'm going to make the argument here that it really feels like these are not really concerns about system ordering, they are concerns that are unnecessarily bloating trivial system ordering problems by "artificially" inflating the number of systems you're using.

There are plenty of methods and techniques for breaking out logic that do not involve writing new systems - things like SystemParams, WorldQuery, Command implementations, etc.

Case in point, it seems like logic for window cursor -> Ray and ray -> entity selection probably make more sense as methods on a SystemParam struct and not an actual system, because neither one of these feels like it really needs to modify the state of the world or do expensive work we need to cache for assessment - we just have a common operation against a subset of the world state that needs to be executed in multiple system contexts to yield a specific result.

For the general problem of like, I have some kind of operation that yields an entity, and it becomes problematic to reify that entity into a specific set of components without writing a brand new system each time - this was also a conceptual issue I had a lot of trouble with. The solution I ended up implementing, with assistance from the community, was to derive an abstract representation of the "sorts" of component sets an activity would be able to interact with, and then to reify that representation into operations on world state using custom commands.

Lemme know if that doesn't make a whole lot of sense to you, it's a big concept to try to fit into a couple of sentences, so I don't really feel like I'm doing it justice - but the conceptual upshot here is that it's a technique to allow us to scope behavior against the world state we actually care about instead of fragmenting that concern any time we have a new "sort" of entity to worry about, which is something we generally want to avoid for more reasons than just "it makes ordering harder to deal with."

Also just as like, an aside here, I am not trying to make the argument that any of these techniques are somehow "obvious," only that they're working more with the engine than against the engine.

I mean, if there's some ordering implied for the original system, this ordering must be preserved in the new two systems.

Yes, but this is only disruptive if you're actually introducing a new "branch" point in the schedule graph. If these new systems have the same ordering constraints as the last one, this doesn't require revisiting any assumptions you've made up until this point or doing anything unique. You just schedule your systems the same way the original system was scheduled.

My experience is that system ordering as a concern, when it is a concern, is almost always local to some concept of a "process" or a "mechanic" - I do not generally have concerns around system / behavior ordering that require systems to care about the state of a variable in the world, because that's not how I structure my code, because to structure my code that way introduces a shitload of conceptual overhead I'd rather not try to deal with.

Because of this, typically when I think about system ordering, I think about it in terms of how a system relates to other systems, and not how or when a system interacts with it's parameters, because I have made the architectural decision to always assume indeterminately ordered access to world state, because I am writing code in an engine that defaults to parallel execution with it's own ideas about how to order operations against world state.

I'm quite certain that many real world projects in Bevy have unintentional one frame delay for certain operations

Sure, for certain values of "unintentional." I generally structure my code as if world state were a giant double buffer, because it essentially IS a giant double buffer, and I find that most behaviors don't actually need to worry about the delay, because if everything is delayed by 30 ms, then it all plays out at the same rate in the end anyway.

Then only scenario in which this becomes a problem is if you have a chain of operations implicitly depending on each other, but like, don't do that, and if you're forced to, you expect it'll be a pain in the ass.

Much like how in Unity, an OnUpdate method blocks the main thread - there are tools the engine gives you to resolve this when it becomes a problem, that doesn't mean you want to default to always using those tools just in case it becomes a problem, because that would introduce a shitload of unnecessary conceptual overhead - the only scenario in which this becomes a problem is when you have code that cannot execute in a reasonable timeframe. So like, don't write that code, and if you're forced to, expect it'll be a pain in the ass.

[stepancheg]

it seems like logic for window cursor -> Ray and ray -> entity selection probably make more sense as methods on a SystemParam struct and not an actual system

Sometimes I need a system which produces the result for two unrelated systems (for example, a system which updates debugging window with cursor position, and a system which actually implements game logic based on selection) — I don't want to mix them together. Mostly for better modularity.

I use custom SystemParam sometimes though.

The solution I ended up implementing, with assistance from the community, was to derive an abstract representation of the "sorts" of component sets an activity would be able to interact with, and then to reify that representation into operations on world state using custom commands.
Lemme know if that doesn't make a whole lot of sense to you

I must admit it doesn't.

it's a big concept to try to fit into a couple of sentences

If there's some non-trivial idea behind it, then maybe link to some post or comment? I won't necessarily use it, but it is fun to learn something new.

I mean, if there's some ordering implied for the original system, this ordering must be preserved in the new two systems.
You just schedule your systems the same way the original system was scheduled.

And adding unnecessary dependency. Which may not be too harmful for one particular case, but it will be an obstacle on the following changes: there's a bunch of dependencies for this group of systems, and I'm not completely sure which ones I really need, but scary to touch it because there's no protection against incorrect order: I may accidentally break something.

(And yes, it may introduce a branch if the second system does not need to depend on all the systems first system depends on).

typically when I think about system ordering, I think about it in terms of how a system relates to other systems

With #[auto_system] it works too:

#[auto_system]
fn system1() { }

#[auto_system(after(system1))]
fn system2() {}

Ordering with parameters is safer though because:

• it is clear why exactly this dependency exists: because of this data (as resource, event, entity etc). In a week away from keyboard I don't need to relearn what exactly these systems do to verify whether this dependency is correct
• no need to make functions public and all parameters of these functions also public (which increase code quality)

I generally structure my code as if world state were a giant double buffer, because it essentially IS a giant double buffer, and I find that most behaviors don't actually need to worry about the delay, because if everything is delayed by 30 ms, then it all plays out at the same rate in the end anyway.

30 milliseconds I guess you take from one iteration of your loop, and one iteration of render loop?

Well, if your keypress to world state update to graphic entity update is two main loop iterations, you add extra 15 ms. It is not the same.

But worse than that (in my opinion) you add non-determinism.

there are tools the engine gives you to resolve this when it becomes a problem

As I said before, such issues are not even easy to detect because concurrent execution is non-deterministic. The issue may reveal only on another machine, or only on release build, or only in the certain part of the game (if you are doing a game), or all three combined. And it is hard to diagnose and debug. Like your user report: your game crashes. Or feels unresponsive. Or just gameplay bug which looks like logic bug. There's nothing you can do about it, because you cannot even reproduce it locally.

you want to default to always using those tools just in case it becomes a problem

I use these tools to not even think whether it will create problems or not (although I have already pointed to several known problems).

For example, I know that some two systems (run_if(in_state(Cond))) will run in the same state in one frame in certain order. So I don't have to think what will happen if state is changed, but there's some unprocessed event somewhere which will popup in ten minutes when state changes back.

[IronGremlin]

And adding unnecessary dependency.

Not a -new- one. Also not unnecessary.

My point here is that this is not an "infectious" concern - splitting a function into two does not have cascading implications for the ordering of other systems.

This is basically the exact case for exporting named SystemSets - so if you must commit a sin and define scheduling ordering outside the bounds of a module/plugin, you can use an exported identifier to do so instead of making all your functions public and sweating bullets when you make changes.

I get the idea that like, maybe you do not want to have to pre-load every plugin with SystemSets ahead of time - but then like, don't do that. Just use this kind of case to help you define them when you need them, and build out your graph as your needs evolve.

If there's some non-trivial idea behind it, then maybe link to some post or comment?

No luck on finding this in condensed form so far, but this_project makes extensive use of the technique to convert between 'logical game components as assets' to entities with Components.

I found that project to be super informative and interesting, I hope you also get some value out of it.

is clear why exactly this dependency exists

Yeah that's not translating.

I don't look at a mutable resource system parameter and automatically make sense of what "before", "after" and "in_set" are supposed to imply with respect to a resource. I can see how you might use that structure to enforce guarantees, but which code goes in which bucket and why doesn't make any sense, so this still seems like a puzzle I need to go solve to me. It also introduces a potentially bigger question to me, where like, OK, if I care about a specific ordering of my access to this resource in a frame, why am I only giving myself three processing stages that mention it?

I have this big complicated need for ordering of writes that can't be handled with built in tools but somehow all my needs can be supported by three stages of processing per resource?

you add non-determinism.

Quick aside:

Mutable access to shared system params in Bevy is a non-specific, but stable ordering. This is not the same as true non-determinism in write ordering. This does not absolve programs written in Bevy of all concerns of this nature, but it's a pretty significant mitigation.

Cross platform troubleshooting can be a bitch for sure, but like, bugs exist. There is nothing stopping a user of this technique from forgetting to specify an ordering, selecting the wrong token to order against, etc.

Also, AFAIK, we're discussing "specific ordering of writes as mandatory, declared relative to mutable state" vs. "specific ordering between systems if/when you've identified a need for a specific ordering, and agnosticism about state prior to this frame wherever possible," not like, "I will never again write code that is parallel because it scares me" vs. "throw everything in update and let god sort it out."

[stepancheg]

No luck on finding this in condensed form so far, but this_project makes extensive use of the technique to convert between 'logical game components as assets' to entities with Components.

I tried reading it.

No way I could work with this project without significant slowdown. Bits like this makes this code fragile. Too easy to make mistake

https://github.com/Leafwing-Studios/Emergence/blob/1dc8ab5050739f8047f24c7a3f60ab091cd46888/emergence_lib/src/crafting/mod.rs#L45-L56

if I care about a specific ordering of my access to this resource in a frame, why am I only giving myself three processing stages that mention it?

It covers 99% of use cases. For the remaining, systems can be ordered differently (with systems sets, explicit before/after etc).

Mutable access to shared system params in Bevy is a non-specific, but stable ordering.

Not true. Here is example:

https://gist.github.com/stepancheg/0b4cd6d2e62363ef5470bc156ec59220

It prints "system1" and "system2" in random order, both access shared resource mutably.

There is nothing stopping a user of this technique from forgetting to specify an ordering, selecting the wrong token to order against, etc.

There's no silver bullet, but my argument is that ordering by annotating system params makes correct scheduling easier to maintain.

throw everything in update and let god sort it out

Let clearly defined simple algorithm sort it out.

[nicopap]

I for one feel the pain of scheduling. To quote stepancheg:

• either users of Bevy do not write sufficiently large programs
• or do not aim at writing a lot of code fast
• or do not aim at making their programs work like clockwork, where systems are executed correctly in the same frame without randomly delaying signal to effect by one frame or more

I think it's indeed very difficult to have a predictable schedule when you have even just a few systems that touch the same thing.

In truth, I don't think there should be too much disparate systems touching mutably the same components/resources, so the issue with schedule predictability shouldn't show much too often, but when it shows up it's a headache.

The problem, as stepancheg rightly identified, is that the only relationship between systems is either implicit (by not declaring them) or decoupled from the system (in the add_systems with .chain(), .after(…), and .before(…) ) And I think this decoupling makes things hard to follow.

I think an approach where scheduling is inherent to the system would help a bit. For one, it would enable some form of composability of schedule that up to now is just not possible in bevy. But all approaches suggested by stepancheg up to now felt awkward and not really fit for bevy.

I don't really think #[auto_system] helps much more than the other alternatives stepancheg suggested. The ability to add systems through an attribute macro over add_systems doesn't really contribute to making scheduling easier. It's orthogonal. As long as you can attach scheduling metadata to individual systems it should be fine.

I don't really have a concrete suggestion though ¯\_(ツ)_/¯