Events

Event layer is entry point for all world updates. They are mainly generated by player in presentational layer and passed to server-side.

Events are needed to provide general way to update game state. Also, they makes it possible for lower layers to communicate to higher ones.

Engine transforms input coming from Presentation layer into events, World layer can dispatch data that is transformed into events as well.

Events can be generated in:

World simulation layer (collision, player died event)
Framing 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)
Input Mapping layer (move forward, move backward)

Events can be consumed in different layers:

Networking layer (disconnect player command)
World simulation layer (Physics, player actions)
Presentational layer (e.g., camera movement, animation or model change based on input)

Sometimes they can be only related to client-side or server-side. Because of that, events require target when created by emmiter.

Since events can be needed anywhere, each layer should take them as arguments and then return emmited events. Then engine propagates them.

Event description:

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

Since events can be handled on different engine layers it's needed to be expicitely notated on where they should go.

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.

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.

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

Example:

Serialized examples?