Why game servers and chat must exist separately
Hi, Habr! I present to your attention the translation of the article " Why you should run your computer ?" Joe Hanson.
Multiplayer game developers often face a dilemma:
In the end - it's just a chat, right? Small messages are passed from user to user / small group of users, that's all. So why not just add a bit of functionality to already running servers? What can go wrong?
')
Although at first glance this solution may seem to be quite 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 division will allow us to improve the performance and scalability of the game, at the same time giving us the opportunity to easily add new "social" features and expand their functionality in the future. In more detail, under the cat.
The microservice-oriented architecture breaks up a large application, in our case, a game, into small modular, independently changeable services (services) that interact with each other through simple public APIs. This approach provides 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 fully microservice-oriented architecture. Let's take a closer look at the in-game chat and its “relationships” with the game servers that provide the main functionality of the game.
When using the "monolithic" architecture, the development team turns out to be limited to one stack of technologies - the same programming languages, databases, and development environments with which the game has already been written. The inclusion of new programmers in the team or the introduction of new technologies is much easier and faster with the microservice approach to architecture.
Dependencies also become much more visible on monolithic architectures. Disruption of a single function of the application can lead to the inoperative state of the entire game. Dividing the game into microservices facilitates isolating and fixing bugs in any single module.
The main purpose of the game servers (with which they do well, or at least should do well) is to synchronize and transfer to the players information about the movements and state 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.
The figure above illustrates the game infrastructure 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.
The performance of the game as a whole 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 high speed, lags and increased delays from the chat side and from the side quickly appear Actually, the game.
The separation of chat and game logic provides the most efficient use of processor and network resources. The main task of the game servers is to provide a seamless (with a minimum number of lags / delays) game experience for each player. Thus, the computing power of the servers should be used to achieve maximum game performance.
Suppose we have a game of the battle arena genre - 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 via game servers in real time. Add more chat messages here. It is possible that some players will spam in chat to specifically slow down the speed of the game server (on whose shoulders will lie as the transfer of information about the game world, and the transfer 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 game servers, eating, thus, some of the resources that could be meant 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 player to player / group / team, their parsing and routing - all this gradually complicates the application infrastructure and leads to a deterioration in the overall performance of the game.
Attempting to launch chat channels separately from multiplayer channels will result in the loss of valuable computational power that could be used to implement complex game mechanics instead of solving problems in chat messages routing.
Let us turn to the question of the choice between the UDP and TCP protocols for the implementation of online games. Which one is better to choose in a given situation?
Dynamic multiplayer games (shooters, MOBA, etc.) use the UDP protocol to synchronize player movements and update game state. UDP is ideal for exchanging sending this information at very high speed, but it does not guarantee reliable message delivery and receipt in the correct order.
TCP guarantees message delivery, making it an ideal choice for chat implementation. You can achieve excellent performance if the game itself uses the UDP protocol, and various social features use the TCP protocol.
In games that are not characterized by high dynamics (such as step-by-step strategies), TCP, due to its high reliability, may be a suitable option for the implementation of both chat and game logic. Of course, the need to separate game servers and chat servers does not disappear anywhere. Especially when the game becomes popular and thousands of players start playing it at the same time.
Delay is also an element that needs attention, as the standards defining allowable delays for the functionality of multiplayer games and delays for social features (such as chat) differ. For multiplayer games (including the synchronization of the game state between players and the transfer of information about one player to another player), the delay should not exceed 20 milliseconds, while for chat applications the admissible 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 support as standalone applications and the choice for this standard industrial protocol (for example, XMPP or WebSockets) or using a remote service (for example, PubNub) opens up the possibility to add new social features with ease.
For a start, it is enough to implement the basic chat functionality (sufficient for messaging). By implementing the basic chat infrastructure, we can later begin to expand it. By adding code little by little, we can easily add various additional chat features, such as: an indicator of what a player is typing; indicator of user presence in the network; counter unread messages and other useful features that players usually expect from the chat.
Large and small companies involved in game development (including Pocket Games and EVE Online) are gradually moving (or have already moved) to this architecture. Starting with scalability and high performance and ending with the freedom to introduce new technologies (without the need to lock in one stack), the advantages are obvious: the separation of chat and game servers is the way to go.
Multiplayer game developers often face a dilemma:
- Use existing game servers (on which the game is running directly) to provide chat functionality
- Use separate servers to implement chat functionality.
In the end - it's just a chat, right? Small messages are passed from user to user / small group of users, that's all. So why not just add a bit of functionality to already running servers? What can go wrong?
')
Although at first glance this solution may seem to be quite 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 division will allow us to improve the performance and scalability of the game, at the same time giving us the opportunity to easily add new "social" features and expand their functionality in the future. In more detail, under the cat.
Microservices make the game more manageable
The microservice-oriented architecture breaks up a large application, in our case, a game, into small modular, independently changeable services (services) that interact with each other through simple public APIs. This approach provides 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 fully microservice-oriented architecture. Let's take a closer look at the in-game chat and its “relationships” with the game servers that provide the main functionality of the game.
When using the "monolithic" architecture, the development team turns out to be limited to one stack of technologies - the same programming languages, databases, and development environments with which the game has already been written. The inclusion of new programmers in the team or the introduction of new technologies is much easier and faster with the microservice approach to architecture.
Dependencies also become much more visible on monolithic architectures. Disruption of a single function of the application can lead to the inoperative state of the entire game. Dividing the game into microservices facilitates isolating and fixing bugs in any single module.
The main purpose of the game servers (with which they do well, or at least should do well) is to synchronize and transfer to the players information about the movements and state 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.
The figure above illustrates the game infrastructure 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.
Ensuring seamless gaming experience and efficient chat
The performance of the game as a whole 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 high speed, lags and increased delays from the chat side and from the side quickly appear Actually, the game.
The separation of chat and game logic provides the most efficient use of processor and network resources. The main task of the game servers is to provide a seamless (with a minimum number of lags / delays) game experience for each player. Thus, the computing power of the servers should be used to achieve maximum game performance.
Suppose we have a game of the battle arena genre - 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 via game servers in real time. Add more chat messages here. It is possible that some players will spam in chat to specifically slow down the speed of the game server (on whose shoulders will lie as the transfer of information about the game world, and the transfer 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 game servers, eating, thus, some of the resources that could be meant 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 player to player / group / team, their parsing and routing - all this gradually complicates the application infrastructure and leads to a deterioration in the overall performance of the game.
Attempting to launch chat channels separately from multiplayer channels will result in the loss of valuable computational power that could be used to implement complex game mechanics instead of solving problems in chat messages routing.
UDP vs. TCP: When are both needed, and when one is enough?
Let us turn to the question of the choice between the UDP and TCP protocols for the implementation of online games. Which one is better to choose in a given situation?
Dynamic multiplayer games (shooters, MOBA, etc.) use the UDP protocol to synchronize player movements and update game state. UDP is ideal for exchanging sending this information at very high speed, but it does not guarantee reliable message delivery and receipt in the correct order.
TCP guarantees message delivery, making it an ideal choice for chat implementation. You can achieve excellent performance if the game itself uses the UDP protocol, and various social features use the TCP protocol.
In games that are not characterized by high dynamics (such as step-by-step strategies), TCP, due to its high reliability, may be a suitable option for the implementation of both chat and game logic. Of course, the need to separate game servers and chat servers does not disappear anywhere. Especially when the game becomes popular and thousands of players start playing it at the same time.
Delay is also an element that needs attention, as the standards defining allowable delays for the functionality of multiplayer games and delays for social features (such as chat) differ. For multiplayer games (including the synchronization of the game state between players and the transfer of information about one player to another player), the delay should not exceed 20 milliseconds, while for chat applications the admissible 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 standalone applications and the choice for this standard industrial protocol (for example, XMPP or WebSockets) or using a remote service (for example, PubNub) opens up the possibility to add new social features with ease.
For a start, it is enough to implement the basic chat functionality (sufficient for messaging). By implementing the basic chat infrastructure, we can later begin to expand it. By adding code little by little, we can easily add various additional chat features, such as: an indicator of what a player is typing; indicator of user presence in the network; counter unread messages and other useful features that players usually expect from the chat.
Conclusion
Large and small companies involved in game development (including Pocket Games and EVE Online) are gradually moving (or have already moved) to this architecture. Starting with scalability and high performance and ending with the freedom to introduce new technologies (without the need to lock in one stack), the advantages are obvious: the separation of chat and game servers is the way to go.
Source: https://habr.com/ru/post/353486/
All Articles