In an ECS architecture, components steal all the spotlight. But components aren’t the only type of data we care about. For Blizzard’s Overwatch, the engineers quickly learned that you often want “components of one”, that is basically a singleton. I think they quoted something around half of their components were “singletons”.

In Mana, we support singletons as a first class feature, with even an added ability to consider a type a “Mutual Singleton” where it can be written to from multiple systems at the same time.

But one type of data that is rarely discussed in ECS architectures are Events, often also called messages.

In Mana, we called them Events because Messages gives the wrong idea. A Message implies the creator of the message is sending it to a known destination. That analogy doesn’t fit well to the design of Events. Instead, a system emits an event and has no idea (nor cares) who is going to use the event data.

Events are important in game development. We use them all the time. In the Mana Engine, like Components and Singletons, they are first-class features. Moreover, events are also mutual, which means the same thing as it does for Singletons. Multiple systems can emit events of the same type at the same time, safely from multiple threads.

To declare an event, it’s as easy as declaring any data type in Mana. Just a struct with a tag.

struct MyEvent

{

EVENT_DEFINITION();

//Your data members here.

};

Events have some unique data storage properties that sets them apart.

They are not bound by EntityId to any other types, the way Components are. They are simply a pool of the Event structure. Events will be automatically cleared at the end of the frame, which means you cannot get events from the previous frame.

And one important one that is just like everything else: