High-performance MMORPG general server engine design-> Basic Concepts

In view of the company's confidentiality agreements, this seriesArticleNo specific game details or implementations are involved. I am also the first to participate in the design of such engines, so it is inevitable that there will be some mistakes. If you have any opinions, we welcome the discussion in the industry. The purpose of this series of articles is not to preach, but to focus on sharing and discussion.
The server engine of Mmorpg is an essential component driving the entire game. In the age of plug-ins, the server's position has become increasingly important, many games have handed over a lot of logic originally handled by the client to the server for processing, so as to avoid the impact of various plug-ins on game fairness. It is very difficult to design a general and high-performance MMORPG service engine. In general, how many people can an online game host and what functions can it implement, what operational activities can be carried out is closely related to a server engine that is not powerful enough. It can be said that the server engine is the heart of the game. If it is not well designed, it will be "arrhythmia ", "myocardial infarction", and then cannot support enough online users, operate "card", and finally die. Well-designed engines, such as wow and Eve Online, leave a lot of space for operation and planning, so that there is no "technical problem" in the game's success.
In general, of course, it is to think that the more users a game is installed, the better. Of course, there are many practical constraints here. The first is in operation, the old players in the game are always at a higher level and more powerful, because of the competitive nature of the game, players like to enter the new server, so the number of online users of a group of servers always keeps rising when the server is started, and then drops and becomes stable after a certain point. The second reason is that the game scenario is not infinitely large, and there are inherent gamer density restrictions. If a game screen is full of people, it is estimated that you will not feel fun. According to these two features, the service engine of MMORPG needs high performance, so that as to carry as many users as possible at the time of service opening, and must have a high degree of scalability, users can use a large amount of server resources to pull users during peak hours. After stable operation, extra server resources can be saved to other server groups.
In the simplest way, the MMORPG game is basically a classic C-S structure system, so the simplest structure is
Server
|
|

Client

At this time, the server needs to handle everything, that is, it is a little tired, so there is no need to count on the carrying capacity, and there is no need to think about the expansion capacity, but it is better than simply, if the design performance is well designed, it is guaranteed. There is an open-source C # service engine developed by uo for your reference, http://www.runuo.com /. In fact, in essence, the MMORPG server is no different from the enterprise application, so we can solve the problem in a similar way. If there is a performance problem and one server cannot solve the problem, we can use two servers, it is a divide-and-conquer policy. To improve performance, we need to start from the slowest part of the system. If some experienced developers know that the slowest part of the system is the database. Therefore, to improve the system response, we generally directly read the role data into the memory for processing when the user's role logs on, but the memory data is not safe, what should I do if the server loses power? I need to regularly send user data changes to the database, so there is no delay in reading/writing the database, of course, when the power is down, the data after the last storage will still fall. This is called the server back-to-file. We generally do not need to handle this small probability event, in general, when a game encounters occasional failback, it is basically equipped with experience compensation for online users. In the future, the architecture may expand. To make it easier for you to write SQL statements all over the world, we abstract database operations into database services, so that multiple servers can be used equally, you can also use a single server as the database service host, for example:

DB-Service
|
Server
|
Client

 

This figure looks familiar to me. Well, the three-tier architecture is not like this. At this time, the pressure on the system is not on data storage, so the pressure is on the logic of the game. Now, the game must simultaneously process a large number of concurrent network requests, in addition, we need to perform operations on the game logic. One side is a high I/O application, and the other side is a high CPU operation, which is put in one piece, that is, half of the flame and half of the sea, either burning or drowned. High network I/O does not require strong CPU computing performance. For example, a vro, the core router of a man, bears the route of the egress network of the whole city. Io is high and scary, the router is actually a special computer, but the CPU of this core router is not actually higher than the CPU of our home PC, or even a little lower. However, the CPU consumption of the game's logical operations is the actual consumption. Assuming that the game has 1000 players online, it takes 1 ms to process each event, assuming that each player has four events to handle every second, the computing power of one 4-core CPU or two dual-core CPUs is exhausted for the 1000 players, this is an ideal scenario. If you want to process the NPC, monsters, and items, you need a lot of CPU resources. If all the CPU resources are logical operations, the CPU capacity required for network message processing is insufficient. Although the consumption is low, it is always consumed. Therefore, we continue to adopt a divide-and-conquer approach to handle this problem. We separate the front-end server from the Logic Server, front-end servers are used to process a large number of user links and message distribution, while logic servers are used to process game logic. Because the game logic consumes more CPU, a front-end server can carry n logic servers, so the structure is changed:

 

logic-Service Logic-service DB-service
|
-------------------------------------
|
front server
|
client

we can continue to classify the game logic. Since MMORPG players start from the game, therefore, logic servers can also be called scene servers (map servers). Some games are divided into many scenarios even if there is no scenario switch, however, the seamless splicing technology makes you feel that it is not separated. The player logic can be divided into the continuous event logic and the instantaneous logic. The continuous Event Logic is an event that needs to be reflected with other users in the scene. It can also be called a scene event. For example, if I attack a strange event, this event needs to be notified to all players in the scene, it will also affect the subsequent actions. The so-called instantaneous event, that is, it only affects the player's own status and does not need to notify other players or affect the scene (of course, if it has an impact on the scene, it is necessary to notify other players in the scene ). Some events even notify all users in the system in different scenarios (for example, a player kills a famous boss, or notify the apprentice of the master to be attacked somewhere [if you want to implement the mentoring system]). Most of the player's logic is completed in the scenario, so the implementation of the scenario logic is very important. This part of the operation involves interaction between multiple objects. If you want to use multiple threads to improve the degree of parallelism to improve performance, it will be counterproductive, because it is necessary to ensure the computing data security to avoid dirty reads, in a multi-threaded environment, a large number of locks need to be processed. I believe that the game's business logic also needs to process locks, preventing deadlocks all the Program Members will get mad. For this high-CPU computing scenario, A large number of threads will waste a lot of valuable CPU time on thread switching. Therefore, generally, the logic server of the game is a single-process, single-thread structure and uses a large loop to drive the entire event logic. Then you may ask, if there is a single process and a single thread, isn't it possible to use only one CPU core? Of course, a game cannot have only one scenario. We can run n scenario services on one server to process the logic of N scenarios (based on experience, N = the number of CPU cores has the best performance ). So you can see why I did not write the Logic Server but the logic service.
after a player connects to the front server, how can he send data to that logic service? Here, we need the Scenario Management Service. Based on my ideas, I want to provide a user proxy in the Scenario Management Service. The user proxy knows that the user is in that scenario and acts as the proxy for the user login scenario, the structure chart continues to evolve to:

Logic-Service Logic-service DB-Service
|
------------------------------------
|
Scene Manager
|

Front Server
|
Client
Because the data of the front server is forwarded to the scene by the Scenario Management Server, we can deploy multiple front servers on the front end, because one front server only has Mbps of bandwidth, when front server performance is insufficient or the bandwidth is insufficient, we can solve this problem through two methods, while Scene Manager only performs packet forwarding through the user proxy, so the carrying capacity is quite high. After the enhancement, the system is shown as follows:
Logic-Service Logic-service DB-Service
|
------------------------------------
|
Scene Manager
|
----------------
|
Front server front Server
|
Client client

Considering that the front server may have CPU surplus, some transient events can also be handed over to the front server for processing. Of course, there is a public and time-consuming instantaneous logic that needs to be stripped out, that is, the login logic. The login logic is the same for each group of servers. Therefore, we can authorize the login of N groups of servers to a unified Login server, so we will evolve again.

Logic-Service Logic-service DB-Service
|
-----------------------------------
|
Scene Manager
|
-------------------------------------
|
Front server front Server login server
|
Client client

 

It seems to be a bit like this, but you can also make some details based on different needs, such as the AI operation of monsters. If it is just a simple logic operation, in fact, it can be processed directly in the logic of the Scenario Server (in fact, it is a bit like taking monsters as part of the scenario ). If complex AI is required, the AI of monsters needs to be computed in a separate process. In fact, monsters are treated as special players. This mode is quite special, this method is generally used for Big Boss because it is resource-consuming.
After writing so much, I don't know if it is clear. But today I will talk about it here. Next time we will look at the specific design of each part from the details, and we may have some implementations. If you are interested in continuing to discuss with me before I write the next article, you can add MSN superpowerlee@hotmail.com or Gtalk superpowerlee@gmail.com
I would like to thank Liu Yang of iiegg and Wang qiuting for their great support. As a newcomer, it is really lucky to receive the selfless help from the industry's predecessors.

 

This article is the result of Comrade Alexander's independent thinking. It is possible that the final result may coincide with the existing information on some networks, because the same product design philosophy is the same and is not plagiarized. You are welcome to discuss this article, and you are welcome to repost it. If you repost it, please indicate the source. Thank you.