Multiplayer game backend architecture is a complex and challenging field. There are many factors that must be taken into account when designing and implementing a multiplayer game, including performance, scalability, reliability, security, and data flow. Check out what a heavily simplified multiplayer game backend looks like

Google’s high-level game backend architecture and data flow

Google’s high-level game backend architecture and data flow

One approach that can make multiplayer game backends more robust and easier to reason about is the use of a message queue architecture with unidirectional data flow. This approach is inspired by the popular front-end data library Redux, which simplifies the management of application state.

In a message queue architecture with unidirectional data flow — which we refer to as the “Tashi architecture” — all in-game events are treated as messages that are added to a queue. These messages are processed in a predictable and deterministic way, with the game state being updated as a result of the processing of these messages. See how simple that is in the case of Redux:

Redux architecture

Redux architecture

This approach has several advantages for multiplayer game backends. First, it allows for easier debugging and testing, as the processing of messages can be traced through the system in a linear fashion. Second, it makes it easier to scale the non-multiplayer parts of the backend backend (you can leverage the Tashi multiplayer engine for that, currently in closed beta), as messages can be processed in parallel and distributed across multiple servers. Third, it simplifies the implementation of new features, as all in-game events are available as a data stream that can be easily consumed — and added to — by other systems.

For example, if all in-game events are available as a data stream, it becomes much easier to implement analytics, advertising, and other additional functionality. This is because these systems can simply consume the data stream and perform their own processing on top of it, without having to be tightly integrated with the rest of the system.

In summary, the use of a message queue architecture with unidirectional data flow can make multiplayer game backends more robust and easier to reason about. By treating all in-game events as messages and processing them in a predictable and deterministic way, it becomes easier to debug and test the backend, scale it to meet the needs of the game, and add new features.

How Do I Try It?

Simple! Sign up for our closed beta program here.