Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Per-Entity Events #1626

Closed
alice-i-cecile opened this issue Mar 12, 2021 · 5 comments
Closed

Per-Entity Events #1626

alice-i-cecile opened this issue Mar 12, 2021 · 5 comments
Labels
A-ECS Entities, components, systems, and events A-UI Graphical user interfaces, styles, layouts, and widgets C-Feature A new feature, making something new possible S-Needs-Design-Doc This issue or PR is particularly complex, and needs an approved design doc before it can be merged

Comments

@alice-i-cecile
Copy link
Member

alice-i-cecile commented Mar 12, 2021

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

Events in Bevy often want to be sent to specific consumers, but existing obvious solutions to ensure that this occurs have serious drawbacks. This is particularly true with UI.

What solution would you like?

  1. Store Event<T> components on entities.
  2. Implement WorldQuery for EventReader and EventReader.

What alternative(s) have you considered?

You could simply not use a global events resource, and carefully examine each event to see whether it's designed for the intended recipient. This is error-prone due to poor conceptual clarity, results in possibly large amounts of wasted work and doesn't parallelize well.

System chaining is a very bad solution, because it causes the systems to share resource access, doesn't work across frames, is only one-to-one and so on.

You could create new event types for each channel using a wrapper. This leads to a frustrating proliferation of events.

Channels could be implemented using a resource instead. This is harder to query for in a composable way, and you can't easily add metadata.

Additional context

This would be a valuable possible direction for #1622. It was first discussed on Discord here, with follow-up discussion.

@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible A-UI Graphical user interfaces, styles, layouts, and widgets labels Mar 12, 2021
@alice-i-cecile
Copy link
Member Author

alice-i-cecile commented Mar 12, 2021

Because channels are just entities with components, you could also query for them directly:

fn my_channel_system(mut my_events: Query<&Events<MyEvents>, With<MyChannel, HighPriority>>){
  for mut e in my_events.iter_mut (){
    // Modify the events in some strange direct fashion
  }
  
  for e in my_events.to_event_reader().iter(){
    // Act on the events
  }
}

This could also be an alternative to extending the EventReader system parameter with a second optional type parameter for the channel.

@alice-i-cecile
Copy link
Member Author

#2116 is an attempt at implementing this flavor of design.

@alice-i-cecile alice-i-cecile changed the title Event Channels Per Entity Events Apr 27, 2022
@alice-i-cecile alice-i-cecile changed the title Per Entity Events Per-Entity Events Apr 27, 2022
@alice-i-cecile
Copy link
Member Author

This is blocked on an Event trait, and #2073.

@alice-i-cecile
Copy link
Member Author

No longer blocked; although configurable event storage will be better.

Some prior art: https://crates.io/crates/bevy_eventlistener

@alice-i-cecile
Copy link
Member Author

This has been resolved by observers :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events A-UI Graphical user interfaces, styles, layouts, and widgets C-Feature A new feature, making something new possible S-Needs-Design-Doc This issue or PR is particularly complex, and needs an approved design doc before it can be merged
Projects
None yet
Development

No branches or pull requests

1 participant