Why game servers and chat should exist separately

Hello, Habr! I present to your attention the translation of the article " " Joe Hanson.
 
 
Why game servers and chat should exist separately
 
Developers of multiplayer games often face a dilemma:
 
 
 
Use already existing game servers (on which, directly, the game works) to ensure the functionality of the chat
 
Use separate servers to implement chat functionality
 
 
In the end, it's just a chat, right? Small messages are transmitted from the user to the user /small group of users, that's all. So why not just add some functionality to the already running servers? What can go wrong?
 
 
Although at first glance this decision may seem good, a number of problems can 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 opportunity to easily add new "social features" and expand their functionality in the future. Read more - under the cut.
 

 

Microservices make the game more manageable


 
The micro-service-oriented architecture breaks up a large application, in our case a game, into small modular, mutually independent services (services) interacting with each other through simple public APIs. This approach ensures the ease of adding new functionality and support for an existing one.
 
 
Separating game servers from chat functionality makes the entire application infrastructure more manageable and brings us closer to a completely micro-service-oriented architecture. Let's take a closer look at the in-game chat and its "relationship" with the game servers that provide the basic functionality of the game.
 
 
When using a "monolithic" architecture, the development team is limited to a single stack of technologies - the same programming languages, databases and development environments with which the game is already written. The inclusion of new programmers in the team or the introduction of new technologies is much easier and faster with a micro-service approach to architecture.
 
 
Dependencies also become much more noticeable on monolithic architectures. The failure of a single application function can result in a non-working state of the whole game. Separation of the game into microservices facilitates isolation and fixes of bugs in any separate module.
 
 
The main purpose of game servers (with which they are good at coping, or at least have to do well) is to synchronize and transfer players information about the movements and status of players in real. The technologies used on gaming 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.
 
 

 
 
The figure above illustrates the game infrastructure in which chat and game servers exist separately from each other.
 
 
In addition to the chat, you can also add other services that exist separately from the game servers, such as authorization, statistics, information about the best players, etc.
 
 

Providing seamless game experience and effective chat


 
The performance of the game as a whole is a very important factor for a multiplayer game. 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 lot of real players scattered all over the world and exchanging information at a tremendous speed, lags and delays both from the chat side and from the side are quickly manifested, in fact, the game.
 
 
Separation of chat and game logic provides the most efficient use of processor and network resources. The main task of gaming servers is to provide a "seamless" (with a minimum amount of lag /delay) gaming experience for each player. Thus, the processing power of the servers should be used to achieve maximum game performance.
 
 
Let's say we have a game of the genre of battle arena - for example, LoL or EVE Online. We want to ensure the possibility of simultaneously playing several hundred players in one game world. These are thousands of messages that represent information about all the actions of players sent through real-time game servers. We add here also chat messages. It is possible that some players will spam into the chat to specifically slow down the speed of the game server (on the shoulders of which will lie 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 some of the resources that could be intended for the game.
 
 
The game server is already loaded with various calculations related to physics, graphics and sound. Adding the functionality of sending messages - from the player to the player /group /team, their parsing and routing - all this gradually complicates the application's infrastructure and leads to a deterioration in overall game performance.
 
 
Attempting to start chat channels separately from the channels of a multiplayer game will result in the loss of valuable processing power that could be used to implement complex game mechanics instead of solving the problems of routing chat messages.
 
 

UDP vs. TCP: When you need both, and when is enough for one?


 
Let's pass to a question on a choice between protocols UDP and TCP for realization of online games. Which of them is better to choose in this or that 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 this information at very high speed, but it does not guarantee reliable delivery of messages and their receipt in the correct order.
 
TCP ensures delivery of messages, which makes it an ideal choice for chat implementation. You can achieve excellent performance, if the game itself will use the UDP protocol, and various social features - the TCP protocol.
 
 

 
 
In games that are not very dynamic (such as turn-based strategies), TCP, due to its high reliability, can be an appropriate option for implementing both chat and game logic. Of course, at the same time, there is no need to separate game servers and chat servers. Especially when the game becomes popular and thousands of players start playing at the same time.
 
 
Delay is also an element that requires attention, since the standards that define the allowable delays for the multiplayer games themselves and delays for social features (like chat) are different. For multiplayer games (including synchronization of the game state between players and transfer of information about some players to other players), the delay should not exceed 20 milliseconds, while for chat applications the allowable 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.
 
 

Extensibility of chat functionality


 
Chat support as a standalone application and choice for this industry standard protocol (for example, XMPP or WebSockets) or using a remote service (for example, PubNub) makes it easy to add new social features.
 
 
For starters, it is enough to implement the basic functionality of the chat (sufficient for messaging). Implementing the basic infrastructure for chat, later we can begin to expand it. In addition to adding code, we can easily add various additional chat functions, such as: an indicator of what the player is printing; presence indicator of the user in the network; the counter of unread messages and other useful features that players usually expect from a chat.
 
 

Conclusion


 
Large and small companies that develop games (including Pocket Games and EVE Online) are gradually moving (or already switched) to this architecture. Beginning with scalability and high performance and ending with the freedom to implement new technologies (without having to be locked inside one stack), the benefits are obvious: sharing chat and game servers is the way to go.
+ 0 -

Add comment