Send multiple event types from one Events

[woubuc]

Situation

I'm currently experimenting with a netcode system. When a packet comes in, the receiver system process it and sends the corresponding event. Each of these events then needs to be interpreted by the system that's responsible for that event type (movement, inventory, ...).

struct EventA;
struct EventB(usize);

// A different event emitter per event struct
fn source_system(mut ev_a: ResMut<Events<EventA>>, mut ev_b: ResMut<Events<EventB>>) {
  ev_a.send(EventA);
  ev_b.send(EventB(1));
}

// Read the events for the type we need
fn process_a(events: Res<Events<EventA>>, reader: Local<EventReader<EventA>>) {
  for evt in reader.iter(&events) {
    println!("A");
  }
}

// Repeat for the different event types
fn process_b(events: Res<Events<EventB>>, reader: Local<EventReader<EventB>>) { ... }

Problem

Using multiple event queues this way works up to a point, but I'm up to 10 different events already and foreseeing more as I add features to the game. So this is not scalable and the function signatures of my systems are massive and difficult to parse with all these different event emitters.

The usual solution would be to use an enum. However, this means that each system that is responsible for processing one of the events would need to read and iterate through all events in the queue and filter out the events it's individually responsible for, rather than being able to use a scoped event queue based on the event type.

enum Event {
  EventA,
  EventB(usize),
  EventC,
  // Lots more events
  ...
}

fn source_system(mut ev: ResMut<Events<Event>>) { ... }

// This system needs to loop over all events and then filter on the type it  actually wants, 
// instead of using a separate event queue just for the event it's after
fn process_a(events: Res<Events<Event>>, reader: Local<EventReader<Event>>) {
  for evt in reader.iter(&events) {
    if let Event::EventA = evt {
      println!("A");
    }
  }
}

// This system will again have to loop over all events, and so on for each event type
fn process_b(events: Res<Events<Event>>, reader: Local<EventReader<Event>>) { ... }

Solution

I would like to be able to send to any event queue based on the type passed in, rather than the generic type in Events<T>.

Something like:

struct EventA;
struct EventB(usize);

fn source_system(mut events: ResMut<AllEvents>) {
  events.send::<EventA>(EventA);
  events.send::<EventB>(EventB(1));
}

fn process_a(events: Res<Events<EventA>>, reader: Local<EventReader<EventA>>) { ... }
fn process_b(events: Res<Events<EventB>>, reader: Local<EventReader<EventB>>) { ... }

So I'd like to hear some thoughts/feedback on this idea. What problems are there with this approach that I didn't think of, would it be at all feasible to implement something like this in Bevy, are there any alternative approaches that would solve this problem as well that hadn't occurred to me, ...

[TheRawMeatball]

Hmm, you might actually manage to make this work in a context where you have access to Resources, like an exclusive system or a Command. Here's how it works:

trait Event {
  fn send(self, resources: &mut Resources) {
    resources.get_mut::<Events<Self>>().unwrap().send(self).unwrap();
  }
}

(the actıal impl might need to be a bit different to comply with object safety rules)
(this might work nicely if you use Reflect and #[reflect_trait])

This way, you can send any event without knowing the actual type, but these events might arrive slightly delayed, as they can only be applied at a hard sync point.

On a different note, I'm curious how you deserialize incoming events, and your overall architecture. With more info, perhaps a more efficient solution can be found.

[woubuc]

I hadn't considered that, but the system where I process all incoming events is essentially an exclusive system that runs before anything else can run. So that would probably work.

these events might arrive slightly delayed

What do you mean by "slightly delayed"? If I send the events from an exclusive system at the very first stage, I would expect them to be available in all systems that execute after it, would that not be the case?

I'm curious how you deserialize incoming events, and your overall architecture

I'm just experimenting right now so I doubt my architecture is any good, just trying to see what works. For serialising I have a Packet enum that I serialise and deserialise with serde and bincode. It's probably not the best solution, but it works fine while I play around with other things. I use laminar to send the packets between sockets, then in a system I loop through all the received events from laminar, parse the packets back into an enum with bincode, and emit the necessary events based on those received packets. Then it's up to the various systems to process the events.

[TheRawMeatball]

What do you mean by "slightly delayed"?

If they weren't already in the context of an exclusive system and were being delivered via commands, they'd be delayed in the same way spawn and despawn operations are delayed, but since you're creating the events in an exclusive system, you'll be fine.

Packet enum

Hmm, if you already have the type available, and you're already in the context of an exclusive system, why not just send the event directly? You could even make a macro that analyzes the Packet enum and implements a send function, which takes Resources, matches the enum, gets the correct channel and fires the event

[TheRawMeatball]

Also, something quite similar in scope to this just came up on discord: https://discord.com/channels/691052431525675048/692648082499829760/809495265413038101. Its in the context of parsing user input, not data but the concept still applies.

[woubuc]

Hmm, if you already have the type available, and you're already in the context of an exclusive system, why not just send the event directly?

I simplified earlier, my netcode is actually in an engine-agnostic subcrate which parses everything on a separate thread along with the laminar polling code outside of Bevy, so my system simply gets the resulting enum packets. Otherwise, yeah that would be more efficient.

Its in the context of parsing user input, not data

It's all input, whether it comes from a user action on the local machine or from a remote socket 😄

[alice-i-cecile]

I've seen this same sort of pattern come up in both UI prototyping and dispatching user inputs. I think this is worth pursuing a solution for, in some form or another.

[woubuc]

I've put together a small macro to simplify sending multiple event types at once, called event_set that kind of does what I wanted (or at least is a sufficient workaround). It doesn't need an exclusive system or any special syntax, instead it uses SystemParam to collect the needed event emitters into a single struct.

It's very basic and there's probably some complexities & edge cases that I missed. I also don't think a macro like this would be the way to go if something like it was implemented in Bevy itself. But it might be useful as inspiration or a jumping-off point.

[Ratysz]

This problem seems quite similar to error management in Rust - as in, "why do we have a new library for error handling seemingly every month". Might be a good idea to look for inspiration in that space.