Resolved Default event system

No current plans for a built-in events system unfortunately. The thing is; there are many different best ways to implement an event system, and the best way depends heavily on the combination of all kinds of specific requirements for your specific use case:

• Events happen frequently, or infrequently?
• Do events need composition, or not?
• Should events be associated to an entity (in dynamicBuffer) so that event consumers can efficiently query components on that entity as they iterate events, or not?
  • If event is associated to entity...
    • Max one event per entity per frame, or potentially multiple events per entity per frame?
      
    • Is the same entity responsible for both the creation and the consumption of its events? (affects potential for parallelism)
• Needs to deal with managed land (ex: events that update UI), or not?
• Single event consumer, or multiple consumers?
• Possibility of an event having to exist for multiple frames before its consumer system has a chance to run?
• Needs to be created immediately in jobs, or can it wait for an ECB?
• Support ordered events of different types where order can't be determined by type (execute an event of type A, then one of type B, then another of type A...), or not?
• Processed in parallel, or not?
• Created in parallel, or not?
  • Deterministic order when created in parallel, or not?
• Small amount of different types of events, or very large amount (to the point where we might have a jobs overhead problem if going with one job per event type)?
• Netcode compatible (events detectable by clients), or not?
  • part of prediction, or presentation-only?

• etc...

Every different permutation of these options above might result in a different implementation. If we chose to build one, it would be hard to choose what to optimize it for. Or we could go with the most flexible possible event system, but then performance would be much worse than it could be in most cases