Events

Event - object that contains data that can be used by Engine to update it state or trigger some internal process.

Why events are needed: Most parts of system should not change state directly, but only trigger change process or notify about some event that happend. This allows logic to stay pure for easy extension of Engine by adding new events while also keeping most of the layers strict in-out processing.

All Events are generated by Engine as reaction to layer changes. They can depend by what happens inside and what generates Events, but this process is abstracted and handled by Engine. It creates event with needed data and puts it into special event container, which can be used later to abstractly exctracted later.

Engine users do not work with Events directly.

Event pattern allows layers to communicate with each other while staying pure and not coupled.

Event typing

Events should not use classes for type checking because they can be passed by network, so prototype is lost.

To determine type of event there should be special field with unique string literal.

Event flow

Engine generates events, adds informantion to define from where Event came and then puts them into Event collection. In places where Event needed Engine looks into collection to see if new Events happend. It allows to abstract event transporting, make it clearer and decouple parts of Engine from each other.

Generation

Events can be generated in:

• World simulation layer (Events that update resources, components or entities)
• Validation layer (disconnect player command because of suspicious player activity)
• Networking layer (player connected, player disconnected, new message recieved) both on Server and Client
• Preprocessing (Client World Simulation) layer
• Display layer (disconnect because of critical error, move forward, move backward)

Consumption

Events can be handled in different layers:

• Networking layer (disconnect player command)
• World simulation layer (Player actions, world changes)
• Preprocessing layer (e.g., camera movement, animation or model change based on input)

Sometimes they can be only related to client-side or server-side. Since events can be needed anywhere, each layer should take them as arguments and then return emmited events. Then engine propagates them to all targeted layers.

Event description:

Some event characteristics will be described here to allow better understanding of design principles.

Events are routed

Since events can be handled on different engine layers it's needed to be expicitely known where they should go. But this should be defined not by logic that creates event, but user should in advance provide Engine routing informations which defines where each event is needed.

It gives additional sequrity layer so Engine will remove any not registered events on Server automatically.

Example:

• User clicks on unit. This generates event telling preprocessing layer that some entity was clicked.
  Preprocessing layer movement rule takes entity that was clicked and caches it's information to apply subsequent movement input to this exact entity.
• User tries to attack enemy player. This creates attack event which goes to server side.
• User changes game speed modifier from 1x to x3 in UI. This generates change game speed event which goes to server. On server game time rule takes this event and changes apropriate component on game time entity so now time goes 3 times faster.

Events are time bound

Since events can be viable for one frame only or it might be improtant when they where created, they need to keep time when they where emitted.

Example:

• World layer rule generates event which tells that character was killed. This event is viable for next frame only, so other rules use this information to do their own stuff and trigger some ingame progress or clean up this entity if needed.
• User did several input actions in one frame. Rule received them all, but they are incompatible, so it takes latest event only.

Events can be part of the game world

Some entities just describe temporary incidents of the game world. Those events usually don't need to be serialized.

Example:

• Two physics objects collided
• Character died
• User clicked some button

Serialized examples?