-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Per-Entity Events #1626
Copy link
Copy link
Closed
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsA-UIGraphical user interfaces, styles, layouts, and widgetsGraphical user interfaces, styles, layouts, and widgetsC-FeatureA new feature, making something new possibleA new feature, making something new possibleS-Needs-Design-DocThis issue or PR is particularly complex, and needs an approved design doc before it can be mergedThis issue or PR is particularly complex, and needs an approved design doc before it can be merged
Description
Activity
Metadata
Metadata
Assignees
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsA-UIGraphical user interfaces, styles, layouts, and widgetsGraphical user interfaces, styles, layouts, and widgetsC-FeatureA new feature, making something new possibleA new feature, making something new possibleS-Needs-Design-DocThis issue or PR is particularly complex, and needs an approved design doc before it can be mergedThis issue or PR is particularly complex, and needs an approved design doc before it can be merged
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?
Event<T>components on entities.WorldQueryforEventReaderandEventReader.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.