Why game servers and chat must exist separately

Hello, Habr! I present to you the translation of the article " Why you should run your game servers independently from your chat " by Joe Hanson.


Multiplayer game developers often face a dilemma:

  • Use existing game servers (on which the game runs directly) to provide chat functionality
  • Use separate servers to implement chat functionality

In the end - it's just a chat, right? Small messages are sent from user to user / small user group, that’s all. So why not just add some functionality to your existing servers? What could go wrong?

Although at first glance this solution may seem good, a number of problems may arise in connection with it. Below we will talk about why you should separate game servers and various social features (especially chat). This separation will allow us to improve the performance and scalability of the game, while at the same time giving us the ability to easily add new "social" features and expand their functionality in the future. More details - under the cut.

Microservices make the game more manageable


A microservice-oriented architecture breaks up a large application, in our case, a game, into small modular services that can be changed independently of one another and interacting with each other through simple public APIs. This approach makes it easy to add new functionality and support existing ones.

Separating game servers from chat functionality makes the entire application infrastructure more manageable and brings us closer to a fully microservice-oriented architecture. Let's take a closer look at the in-game chat and its “relationship” with game servers that provide the basic functionality of the game.

When using the "monolithic" architecture, the development team is limited to one technology stack - the same programming languages, databases and development environments with which the game was already written. The inclusion of new programmers in the team or the introduction of new technologies is realized much easier and faster with a microservice approach to architecture.

Dependencies also become much more visible on monolithic architectures. Failure of the only function of the application can lead to an inoperative state of the entire game. Dividing the game into microservices makes it easier to isolate and fix bugs in any single module.

The main purpose of game servers (which they do well, or, at least, should do well) is to synchronize and transmit to the players information about the movements and condition of the players in real. The technologies used on game servers to achieve these goals are hardly the best solution for implementing chat. Separated components, as already noted, are more convenient in support and independent scaling.

image

The figure above illustrates the infrastructure of the game, in which chat and game servers exist separately from each other.

In addition to chat, you can also add other services that exist separately from game servers, such as: authorization, statistics, information about the best players, etc.

Providing seamless gaming experience and effective chat


Game performance in general is a very important factor for multiplayer games. The slow speed of the game will lead to the inevitable loss of players. When using monolithic architecture, the game can show good performance at the testing stage, but in combat conditions with a large number of real players scattered around the world and exchanging information at great speed, lags and an increase in delays both from the chat side and from the side quickly appear actually games.

Separation of chat and game logic provides the most efficient use of processor and network resources. The main objective of game servers is to provide a “seamless” (with a minimum number of lags / delays) gaming experience for each player. Thus, the computing power of servers should be used to achieve maximum game performance.

Let's say we have a battle arena game - for example, LoL or EVE Online. We want to provide the ability to simultaneously play several hundred players in one game world. These are thousands of messages representing information about all the actions of players sent through game servers in real time. Add chat messages here. It is possible that some players will spam in the chat in order to specially slow down the speed of the game server (on its shoulders will be both the transfer of information about the game world and the transmission of chat messages). Of course, it is possible to catch such players and, for example, block chat for them, but for this you still need to perform additional calculations on the game servers, thus eating up some of the resources that could be intended for the game.

The game server is already loaded with a variety of calculations related to physics, graphics and sound. Adding the functionality of sending messages - from player to player / group / team, their parsing and routing - all this gradually complicates the application infrastructure and leads to a decrease in the overall performance of the game.

An attempt to launch chat channels separately from channels of a multiplayer game will lead to the loss of valuable computing power that could be used to implement complex game mechanics instead of solving the problems of routing chat messages.

UDP vs. TCP: When are both needed, and when is one enough?


Let's move on to the choice between the UDP and TCP protocols for implementing online games. Which one is better to choose in a given situation?

Dynamic multiplayer games (shooters, MOBA, etc.) use the UDP protocol to synchronize the movements of players and update the state of the game. UDP is ideal for exchanging the sending of this information at a very high speed, but it does not guarantee reliable delivery of messages and their receipt in the correct order.
TCP guarantees message delivery, making it an ideal choice for implementing chat. You can achieve excellent performance if the game itself uses the UDP protocol, and various social features use the TCP protocol.

image

In games that do not have high dynamics (such as turn-based strategies), TCP, due to its high reliability, may be a suitable option for implementing both chat and game logic. Of course, at the same time, the need to separate game servers and chat servers does not go away. Especially when the game becomes popular and thousands of players begin to play at the same time.

Delay is also an element that needs attention, since the standards that define acceptable delays for the functionality of the multiplayer games themselves and delays for social features (like chat) are different. For a multiplayer game (including synchronizing the state of the game between players and transmitting information about one player to another player), the delay should not exceed 20 milliseconds, while for chat applications, the permissible delay is 250 milliseconds.

Thus, we have two types of real-time messaging with different standards. If they work independently of each other, we can easily change the implementation of each of them, based on the relevant requirements.

Chat Extensibility


Supporting chat as a standalone application and choosing a standard industry protocol (for example, XMPP or WebSockets) or using a remote service (for example, PubNub) makes it easy to add new social features.

To begin with, it’s enough to implement the basic functionality of the chat (sufficient for messaging). Having implemented the basic infrastructure for the chat, later we can begin to expand it. By adding a little code, we can easily add various additional chat features, such as: an indicator that the player is typing; indicator of user presence on the network; counter of unread messages and other useful features that players usually expect from chat.

Conclusion


Big and small game development companies (including Pocket Games and EVE Online) are gradually moving (or have already switched) to this architecture. Starting with scalability and high performance and ending with the freedom to implement new technologies (without having to lock inside one stack), the advantages are obvious: the separation of chat and game servers is the way to go.

Also popular now: