The core of the architecture is the introduction of a new construct to ECS: the **Message**.
A Message is fundamentally a variant of Component, in that it only contains data. But, it is designed to be temporary and is discarded at the end of each frame. It is used to communicate useful information between Systems.
We also introduce some extra information to Systems. Each System must declare the Messages that it **Receives**, the Messages that it **Sends**, the Components that it **Reads** and the Components that it **Writes**.
We have TransformComponent, which contains position and orientation data, and VelocityComponent, which contains an *x* and *y* component for linear motion.
Our MotionSystem reads each Entity that has both a TransformComponent and a VelocityComponent, and emits a MotionMessage, which contains a reference to the Entity and the *x* and *y* velocity given by the VelocityComponent.
We also have a **TeleportSystem** that needs to teleport the character forward a bit. Let's say when the player presses the X button, a TeleportMessage is fired. The TeleportSystem reads this message and emits a MotionMessage in response.
Now we have our **MotionSystem**. The MotionSystem declares that it Writes the TransformComponent, reads the MotionMessages that apply to each TransformComponent, and applies them simultaneously, adding their *x* and *y* values to the TransformComponent. Voilà! No race conditions! We can re-use similar behaviors easily without re-writing code by consolidating Messages.
That's right! With the power of graph theory, we can construct an order for our Systems so that any System which Sends a certain Message runs before any System that Reads the same Message. This means, when you write behavior for your game, you *never* have to specify the order in which your Systems run. You simply write code, and the Systems run in a valid order, every time, without surprising you.
Systems are not allowed to create message cycles. If System A sends Message B, which is read by System B which emits Message C, which is read by System A, then we cannot create a valid ordering of Systems. This is not a flaw in the architecture; a cycle means you have a feedback loop of data which can usually be easily eliminated.
The other restriction involves two separate systems which Write the same Component. They may do so, but they must declare a priority. If we allowed Systems to Write components willy-nilly, we would introduce the possibility of two Systems changing the same component on the same frame, creating a race condition. If we have two Systems where it makes sense to change the same Component, we can either create a new Message and System to consolidate the changes, or we can declare write priority so that one System's changes always override the other's. This way we can avoid race conditions.
If you are used to programming games in an object-oriented way, you will likely find the pattern counter-intuitive at first. You will have to completely invert how you think about constructing game objects. But once you learn to think in a MECS way, you will be shocked at how flexible and simple your programs become.
