Overview of Event Messaging Systems
Event messaging systems are essential to a game engine because they allow systems to communicate with each other. Open 3D Engine (O3DE) uses a few types of communication methods, which are separated into the following modules:
- Event Bus (EBus): A single global bus that all modules can use to invoke requests and dispatch messages, respectively known as request and notification buses.
AZ::Interface: A C++ template class for a global interface that other components can invoke requests from, equivalent to the EBus sytem’s request bus.
AZ::Event: A C++ template class that can publish single-value messages, which other components can subscribe to, equivalent to the EBus system’s notification bus.
The functionality of these three modules overlaps in some ways:
AZ::Interface provides a request interface,
AZ::Event provides a publish-subscribe interface, and EBus provides both. However, all three modules have strengths and weaknesses that make them more suitable for different scenarios.
The following table compares some key characteristics of EBus,
AZ::Event. You can find all three event messaging modules throughout O3DE’s code base.
|Communication model||EBus is a general purpose event messaging system whose design focuses on abstraction and decoupling systems. It allows many source components to provide requests or publish messages. It also allows many listener components to invoke those requests or subscribe to those messages—all without the components needing to know about each other. Unlike ||An |
Some patterns for cross-entity communication include:
|Lifetime||EBus is a global singleton that initializes when the application launches and gets destroyed when the application terminates.||There can be only a single instance of an ||There can be many instances of an |
|Scripting||EBus supports script binding for both its notification bus (like |
|Advantages||EBus is O3DE’s most flexible and powerful event messaging system. Any system can connect to it and communicate with any other system by simply providing a system’s EBus name. EBus is generally used for situations in which event flow is more important than the source of the event.||Compared to EBus, ||Compared to EBus, |
|Examples||EBus examples are similar to ||A spawner-spawnee system. The spawner interface contains functions to manage spawnees. If you want another class to spawn something, that class can make a request via ||In the networking layer, when a remote procedure call (RPC) is sent, it signals an |