Online game server communication Architecture Design

With the increasing scale and demand of online game practitioners, more and more friends have entered the online game development field, which leads to a rapid increase in the demand for online game development technologies in the market. Currently, the online gaming industry is in short supply of "expert" developers with deep technical skills. This mainly includes two aspects: server-side designers and client-side designers. For online games, because the main game logic computing is completed on the server side, data synchronization and broadcast information transmission are also completed through the server. Therefore, having an experienced server-side designer has become one of the keys to the success of an online game product. In view of this, this article will try to discuss and summarize a series of questions about the online game server design, the author will combine his own development experience and experience, each of which will be presented one by one. We hope to help the following three types of personnel:

Persons who have certain network programming basics and are ready to enter the online gaming industry for server design;

Persons engaged in online game server design;

Technical Director of the online game project.

　　

Because the design of online game servers involves too much content, such as network communication, AI, and database design, this article will focus on network communication. When talking about network communication, we cannot help but address the following five issues:

1. Overview of common online game service communication device Architecture

2. Basic principles of online game server design

3. Basic technologies required for the communication architecture design of online game servers

4. Test the communication architecture of online game servers

5. FAQs about the communication architecture design of online game servers


Let's start with the first question:


Overview of common online game server communication architecture

Currently, there are two types of online games in the Chinese online gaming market: MMORPG (such as World of Warcraft) and casual online games (such as QQ casual games and lianzhong games, games such as bubble classes have many similarities with QQ casual games, so they are also classified as such ). Because of their completely different game styles, they differ greatly in their communication architecture design ideas. The communication architecture of these two online games is described below.

1. Communication architecture of MMORPG online games

The communication architecture of online games is usually determined based on several aspects: the functional composition of the game, the expected number of online players of the game, and the scalability of the game.

The general MMORPG game process is as follows:


A. Players register their usernames and passwords on the official game website.

B. After the registration is complete, the player chooses to activate the game account in a certain zone.

C. Players log in to the activated game partition on the game client and create a game role to play the game.


Generally, In this mode, the gamer role data cannot be used across different zones. That is, the game role created in area A cannot be used in Area B, data between different regions remains independent. We call this independent Zone A or Zone B an independent server group. An independent server group is a relatively complete game world. The communication architecture design of online game servers includes the communication architecture of the entire game world based on server groups and the server communication architecture within a server group.


Let's first take a look at how communications within a separate server group are designed.

The composition of servers in a server group should be divided based on game functions. Different game content plans have different effects on the composition of servers. Generally, we can divide servers in a group into two categories: Scene-related (such as walking and combat) and scene-unrelated (such: guild chat, unrestricted trade, etc ). To ensure the smoothness of the game, you can assign these two types of functions to different servers. In addition, computing that is time-consuming in the running of the server is generally extracted separately and completed by a separate thread or process.


Various online game projects flexibly choose their own server composition solutions based on different game features. A common solution is Scenario Server, non-Scenario Server, Server Manager, AI server, and database proxy server.

The main functions of the above servers are:


Scenario Server: It is responsible for completing the main game logic, including the role's entry and exit in the game scenario, the role's walking and running, and the role's battle (including playing monsters) and claim the task. The scenario server design is the main embodiment of the performance differences between servers in the entire game world. It is not only difficult to design communication models, more importantly, the system architecture and synchronization mechanism of the entire server are designed.


Non-Scenario Server: it is mainly responsible for completing game logic unrelated to game scenarios. These logics can also be performed without relying on the game's map system, such as Guild chat or world chat, the reason for separating it from the Scenario Server is to save the CPU and bandwidth resources of the Scenario Server, so that the scenario server can process the game logic that has a greater impact on the smoothness of the game as quickly as possible.


Server Manager: To synchronize data between scene servers and non-scene servers, we must establish a unified manager, which is the Server Manager in the server group. Its task is mainly to synchronize data between servers, such as the player's online and offline information synchronization. Its main function is to synchronize data during scenario switching. When A player needs to switch from scenario A to scenario B, the Server Manager is responsible for transferring gamer data from scenario A to scenario B, and the start and end of Data Synchronization in these two scenarios are notified through the Protocol. Therefore, to implement complicated data synchronization tasks, the server manager usually maintains a socket connection with all the scenario servers and non-scenario servers.


AI (AI) servers: Because the AI computing of monsters consumes a lot of system resources, we separate them into separate servers. The AI server is mainly used to compute the AI of monsters and return the computing results to the scene server. That is to say, the AI server serves the scene server separately, it completes the computing tasks handed over from the Scenario Server and returns the computing results to the scenario server. Therefore, in terms of network communication, AI servers only maintain socket connections with servers in many scenarios.


Database proxy server: There are two methods to read and write databases for online games. One is to directly add database access code to the application server for database access, another way is to independently read and write the database and separate it as a database proxy for unified database access and return access results.


Among them, non-scenario servers may be designed into different functions in different game projects, such as games featuring team formation, guild or full-channel chat, it is very likely that a separate Chat Server is set up to meet the players' chat needs. If a game is featured by item trade (such as auction, it is very likely that an auction server is set up separately to meet the needs of the auction. Whether it is necessary to independently process a game function into a server depends on the main scenario logic of the game based on this function (referring to the daily Game Behavior of players such as walking and fighting) depends on the extent of the impact. If this function has a great impact on the logic of the main scenario and may cause serious performance and efficiency loss to the logic of the main scenario, you should consider detaching it from the logic of the main scenario, however, whether the function can be detached has another premise: whether the function is related to the game scenario (that is, the map coordinate system. If this function is related to the scenario and does affect the execution efficiency of the main scenario logic, you may need to set up a dedicated thread on the Scenario Server to process the function, rather than separate it into a separate server.


The preceding section describes the composition of servers in a server group. How do servers communicate with each other? What is its basic communication architecture?

The single-group server architecture of MMORPG can be divided into two types: the first is the server architecture with gateway, and the second is the server architecture without gateway. The two solutions have their own advantages and disadvantages.


In terms of the server architecture with gateway, as it only provides the player with a unique communication port, there will be a smooth game experience on the player side, this is usually the solution used for ultra-large-scale seamless map online games, however, the disadvantage of this solution is that the communication architecture design in the server group is relatively complicated, the debugging is inconvenient, the communication pressure on the gateway is too high, and the requirement for the gateway communication model design is high. The second solution will open multiple game server ports to gamers at the same time. In addition to the communication ports of game scene servers, it may also provide communication ports such as chat servers. The main disadvantage of this solution is that when switching scene servers, the player client usually displays an interface such as scene transfer, which affects the smoothness of the game. In terms of client interface processing, a game based on this solution is typically manifested in the following: When scenario switching is required, it can only be transferred to another scenario through the corresponding "transfer function, or when you need to enter a new scenario, the client will wait for a long time to enter the waiting interface (Loading Interface) of the new scenario ).


From a technical point of view, I prefer to design independent server groups into a gateway-based model. Although this increases the difficulty of server design, it enhances the smoothness and security of the game, this cost is worth it.