Advanced System Scheduler

[DasLixou]

This PR introduces a graph-based scheduler for events which can be hinted for order with

let a = world.add_system(system_a);
// Run system B after A
world.add_system(system_b.after(a));
// Run system C before A
world.add_system(system_c.before(a));

Important Change

Systems don't run on insert order anymore!

Dependencies

• Added petgraph with features graphmap and without defaults

Future notes

This still isn't 100% flexible for modular use, because the SystemId is still required. We can't change this to the TypeId of a system because of the flexibility to add multiple of the same TypeId-erased systems.

[rj00a]

Initial thoughts:

• I am not yet convinced a graph-based scheduler is something we want (flecs seems to be doing fine without one). In a world with plugins, ideally the plugin will add its items to the World without consideration for order. If that plugin depends on another plugin being setup first, it will call the setup routine for its dependencies before adding itself to the World. Priority is intended for the situations where that isn't quite sufficient.
• For "run once per frame" systems, it is already possible to emulate system sets/schedules to some extent using events. Consider what happens if we make PreUpdate, Update, and PostUpdate events, for instance.
• I don't believe ordering on individual systems is desirable. We really want to talk about sets of systems, like bevy's SystemSet. A module/plugin may want to keep its systems an implementation detail and only expose system sets in the public API.
• If possible, I would like to keep dependencies to an absolute minimum and avoid adding a dependency on petgraph.

In conclusion, I would like to gather some experience using evenio on a non-trivial project before adding something like this.

[DasLixou]

Initial thoughts:

* I am not yet convinced a graph-based scheduler is something we want ([flecs](https://github.com/SanderMertens/flecs) seems to be doing fine without one). In a world with plugins, ideally the plugin will add its items to the `World` without consideration for order. If that plugin depends on another plugin being setup first, it will call the setup routine for its dependencies before adding itself to the `World`. `Priority` is intended for the situations where that isn't quite sufficient.

* For "run once per frame" systems, it is already possible to emulate system sets/schedules to some extent using events. Consider what happens if we make `PreUpdate`, `Update`, and `PostUpdate` events, for instance.

* I don't believe ordering on individual systems is desirable. We really want to talk about _sets_ of systems, like bevy's `SystemSet`. A module/plugin may want to keep its systems an implementation detail and only expose system sets in the public API.

* If possible, I would like to keep dependencies to an absolute minimum and avoid adding a dependency on `petgraph`.

In conclusion, I would like to gather some experience using evenio on a non-trivial project before adding something like this.

I can see your point, still i think that ordering is important. But I think handling this with sets is also fine.

The use-cases I am thinking this for are both doable in sets:

• Making EventKind non-special - this would then be some sort of ApplySet. Still unsure how we would do a "be after applyset by default but you can overwrite it".
• Event Validation - checking if an event is valid and surpasses checks before going further into the system. This could also be done in a set which should be placed before the "normal" logic...

[DasLixou]

Also, if you don't want the dependency on petgraph, I got a simple no-dependency graph library from me laying around. Could also include that. Would be 1 file for graph and probably 1 file for this specific iterating algorithm. Or we could just directly make that algorithm work on a scheduler list.
The main thing is that ordering is possible to at least some point.

[rj00a]

Making EventKind non-special - this would then be some sort of ApplySet. Still unsure how we would do a "be after applyset by default but you can overwrite it".

Can you expand on this? Is this going to be compatible with my plans in #5 and #4?

[DasLixou]

Making EventKind non-special - this would then be some sort of ApplySet. Still unsure how we would do a "be after applyset by default but you can overwrite it".

Can you expand on this? Is this going to be compatible with my plans in #5 and #4?

Uhh... #5 will be interesting. When we do this we need some sort of event sorting rather than system sorting for events when I understood your thoughts. I already tried to implement such thing for a UI lib but wasn't so happy with it.
But maybe I also just misunderstand your BitSet thing

[DasLixou]

#4 on the other hand is fairly easy to implement with this

[rj00a]

(Discussed on Discord. Closing for now)