One-shot systems via Commands for scripting-like logic

[alice-i-cecile]

What problem does this solve or what need does it fill?

Some operations are only done very rarely: scripting-like game logic that modifies levels, unlocks achievements or handles a boss's special attack come to mind.

These systems clutter the schedule, waste resources as they constantly spin, and are harder to extend.

What solution would you like?

There are two parts to my proposed solution:

1. Add Commands::run_system(system: impl Into<SystemDescriptor>). This runs the specified system on the World the next time commands are processed.
2. Create a pattern where we store references to system functions on components, and dynamically run those systems when the appropriate trigger is met, allowing for scripting-like flexibility with low-overhead and seamless ergonomic Bevy syntax.

What alternative(s) have you considered?

Writing custom commands types each time will be onerous and have much increased boilerplate, and because they take exclusive access to World, force the users to learn a new syntax and reduce our ability to parallelize commands of this sort in the future.

This same functionality could also be framed as "dynamically inserting systems", but that may complicate the API somewhat when you often don't end up caring a lot about overhead.

Other approaches to reactivity may be able to fill this niche in some form instead.

Additional context

Making sure the ordering on this is correct enough is going to be one of the larger challenges. May be better to wait until after #1375. Chaining also needs some careful thought.

Brought up in response to the following user request:

Is it possible / practical / good practice to pass a function around inside an event? My thought process is an NPC could have an interaction with a very specific procedure following it like opening a secret door across the map or unlocking a new dialogue option with another NPC so much so that having a system that contains every one of these niche interactions inside a match would be rather hideous.

Depending on the efficiency and ergonomics of this, could also be used to support push data-flow for UI (see #254).

Related to #1273.

[Ratysz]

Create a pattern where we store references to system functions on components [...]

I'm not sure what this entails on Bevy side. A mention in the book(s) and an example?

This same functionality could also be framed as "dynamically inserting systems", but that may complicate the API somewhat when you often don't end up caring a lot about overhead.

I'm not sure what you mean by that. Inserting systems dynamically is not an API problem: it can't be done without forcing the systems executor to recalculate its cached data, which is necessarily slow.

Making sure the ordering on this is correct enough is going to be one of the larger challenges. May be better to wait until after #1375.

Commands' order is entirely dependant on the order of the systems that issue them. This reads like proposing we add another layer of ordering on top of that, which is bound to get ugly. Stageless won't change anything here.

Chaining also needs some careful thought.

Why? Chaining two systems is essentially making them into one system, no special considerations needed.

---

I don't think there are any obstacles for a built-in arbitrary closure command (if we don't have one already). Dressing said closure up as a system shouldn't be a challenge, at first glance, but: systems are stateful - they have their own local variables. How should that be handled here?

This might be once again us running into the trap of trying to jam everything and anything into our system abstraction.

I think it's best to instead consider the accessor API for this. It's semantically more correct: a thing that's not a normally scheduled system but needs potentially-shared access to world data.

[cart]

I think pre-registering a system with the executor, retrieving a handle from that, then triggering a run of the system via commands (or some other abstraction) is probably the way to go if we want to support this.

It definitely has synergies with "reactivity", which entails running a pre-defined system on a trigger. The only difference is "manual trigger" vs "data access trigger".

The executor is already "greedy" (it just loops over systems that need to run and sees if they can run), so this feels like a natural extension of that. Reactions and manual system triggers should both probably run before the source system's dependencies run, so I think its probably just a matter of only flipping the "finished" state for the source system once all triggered systems have finished.

[alice-i-cecile]

I think pre-registering a system with the executor, retrieving a handle from that, then triggering a run of the system via commands (or some other abstraction) is probably the way to go if we want to support this.

I'm on board with this strategy: should be quite clean and support the scripting-like use cases very nicely. As long as we can store the handles on components we should be good.

[alice-i-cecile]

I'm not sure what this entails on Bevy side. A mention in the book(s) and an example?

Yes, likely as part of an example game of some sort plus a page in the book. This sort of design pattern is really important to communicate IMO, but very challenging to understand without context.

[alice-i-cecile]

One other useful bit of functionality that would be helpful: the ability to pass in new data to the system via the Input type on system chaining. This should probably be split from the default no-input form for ergonomic reasons.

[Ratysz]

That's not what chaining is for. We don't have a centralized way to pipe data directly between systems (like in e.g. run criteria), and I don't think we need one - events and other kinds of channels should work just fine.

[mockersf]

there's also the config method on FunctionSystem that can be used to setup locals

[alice-i-cecile]

For posterity, my current thinking is that this pattern is less than optimal. It creates a lot of spaghetti in terms of dependencies and ordering, and has a serious but largely hidden performance impact. It's also very painful to refactor away from.

Instead, I think there are two, better alternatives:

• create a well-scoped event type, which stores a FnMut with the appropriate data types, and then process it in its own system. Possibly in combination with Suggestion: Entity Events #2070.
• work to dynamically add-and-remove systems based on world state in order to disable specialized scripting systems when they're not needed. Blocked on API for dynamic management of systems (adding and removing at runtime) #279, and by extension ECS Mad Science Lab, stageless-ish R&D #2801.