This is the third part of the King's Glory technical analysis series. If you are interested, please continue to pay attention to my blog and public account.
1. As popular as "Glory of the King"
2. Let's talk about the frame synchronization of the game from "Honor of Kings"
3. Architecture evolution of game server
1. Game server features
The game server is a long-running program, and it also serves multiple irregular and irregular network requests. So this type of service is characterized by a special focus on stability and performance. If this type of program requires multiple collaborations to improve the carrying capacity, it is also necessary to pay attention to the convenience of deployment and expansion; at the same time, it is also necessary to consider how to achieve a certain degree of disaster recovery requirements. Due to the cooperative work of multiple processes, it also brings the complexity of development, which is also a problem that needs attention.
Functional constraints are the decisive factor in architectural design. Based on the functional characteristics of the game business, the server-side system has the following special requirements:
Game and player data storage landed
Broadcast and synchronize player interaction data
Important logic should be calculated on the server, and verification should be done to prevent plug-ins.
In view of the above demand characteristics, on the server side, we often pay attention to the use of computer memory and CPU, in order to meet the requirements of high load and low response delay as much as possible under specific business codes. The most basic approach is to "change space for time", and use various caching methods to achieve a balance between CPU and memory space. There is another constraint: bandwidth. The network bandwidth directly limits the processing power of the server, so the game server architecture must also consider this factor.
2. Game Server Architecture Elements
For the game server architecture, the three most important parts are the design of how to use the CPU, memory, and network card:
Memory architecture: mainly determines how the server uses memory to maximize the use of server-side memory to increase load capacity and reduce service latency.
Logical Architecture: Design how to use processes, threads, and coroutines for CPU scheduling. Choose between different programming models such as synchronous, asynchronous, etc., to improve the stability and capacity of the server. It can be divided into different servers, or the same functional modules can be divided into different servers for processing in the way of the world server.
Communication Mode: Decide which method to use for communication. Different communication modes are used based on different game types, such as http, tcp, udp, etc.
3. Server evolution process
1. Casual games such as cards and weak interactive games
Based on different game types, the server adopts different architectures. Let's talk about the simple model first, the server using the http communication mode architecture:
This server architecture is similar to our commonly used web server architecture. It also uses nginx load clustering to support the horizontal expansion of the server, and memcache for caching. The only difference is that the communication layer needs to reprocess and encrypt the protocol. Generally, each company has its own set of HTTP-based protocol layer framework, and rarely uses open source frameworks.
2. Long link game server
The difference between a long-connection game and a weakly networked game is that in a long-connection, the player is stateful, the server can interact with the client from time to time, and the data transmission does not require a new connection every time. The frequency and speed are faster than weak network games. The architecture of long-link online games has been iterated for several generations, and the types have become increasingly rich. The following are the characteristics and architectural patterns of each generation of servers.
1), the first generation of online game server (single-threaded non-blocking)
The earliest game server was in 1978. Roy Trubshaw, a student at the University of Essex, a famous British financial school, wrote the world's first MUD program, called "MUD1".
MUD1 is a text-only world without any pictures, but players in front of different computers can take risks and communicate together in the game. Compared with the previous games with online function, MUD1 is the first real-time multiplayer interactive online game, and its biggest feature is that it can ensure the continuous development of the entire virtual world and the player's character - whether the player quits After logging in again or restarting the server, the scenes, treasure chests, monsters and puzzles in the game remain unchanged, and the player's role is still in the same state as last time.
MUD Chinese version
MUDOS uses a single-threaded non-blocking socket to serve all players, all players' requests are sent to the same thread for processing, and the main thread updates all objects (network transceiver, object status, refresh map, refresh NPC every 1 second) ). The user uses a client such as Telnet to connect to MUDOS with the Tcp protocol, and uses plain text to play the game, and each command is separated by a carriage return. Such a system at the time hosted 4,000 people playing games on each server at the same time. Since the release of MUDOS in 1991, all parts of the world have been improving, expanding and launching new versions for him.
The game content in MUDOS is customized through LPC scripts, and the logic processing adopts single-threaded tick polling. This is also the first server-side architecture model, which was later applied to different games. Like "UO", many subsequent games were directly developed on MUDOS, and until now, some turn-based games and games with small computational load still use this server architecture.
The first generation server architecture diagram:
threading model
2) , the second generation online game server (partitioned service)
Around 2000, with the emergence of graphical interfaces, more games used graphical interfaces to interact with users. At this time, with the increase in the number of people online and the increase in game data, the server becomes overwhelmed. So there is a split model. The structure of the sub-service model is as follows:
The split server model is the most typical and longest-standing model in game servers. When the capacity of the early server reached the upper limit, game developers solved it by setting up more servers. This provides many "parallel worlds" of games, allowing more space for comparison between everyone in the game. Its characteristic is that the game server is a separate world. The account of each server is independent, the user status of each server is different, a server is a world, and everyone is not involved.
Later, game players called for cross-server fights, so cross-server battles appeared. In addition, with the operation of the game, there were fewer and fewer active players in the game on a single server, so in the later stage, there were mergers and migrations of servers, and slowly The opening and merging of servers has formed a set of mature operating methods. At present, most games still use a split server structure to set up servers, and most web games still use this model.
thread scheduling
Although sub-server can solve the bottleneck of server expansion, a single server can't make full use of server resources when running in a single-threaded mode in the past, so the following two thread models have evolved.
Asynchronous - Multi-threaded, on a per scene (or room) basis, a thread is allocated. Players in each scene belong to the same thread. The scene of the game is fixed and not many, so the number of threads can be guaranteed not to increase continuously. Each scene thread also uses tick polling to regularly update the (object status, refresh map, refresh NPC) data status in the scene. If the player crosses the scene, the method of delivery and notification is used to inform the two scene threads to update the player data of the two scenes.
multi-Progress. Because under the single-process architecture, there is always a limit to the load capacity. The more complex the game, the lower the single-process load capacity. Therefore, it is necessary to break through the process limit to support more complex games. Some other benefits of multi-process systems: the ability to take advantage of multi-core CPU capabilities and easier disaster recovery.
The classic model of the multi-process system is the "three-tier architecture". For example, based on the previous scenario thread, the network part and the database part are separated into separate processes for processing, and the logical process concentrates on processing logical tasks, not dealing with IO. Network IO and disk IO are handled by the network process and the DB process respectively.
3), the third generation online game server
The previous online game servers were all divided into separate servers. Players were divided into different servers. Each server ran the same logic, and players could not interact between different servers. If you want more players to be in the same world and keep players active, there is a world server model. The world server type also has the following 3 evolutions:
Type 1 (three-tier architecture)
The gateway part is separated into a single-ended gate server, the DB part is separated into a DB server, and the network functions are extracted separately, allowing users to connect to a gateway server in a unified manner, and then the gateway server forwards the data to the back-end game server. The data exchange between the game servers is also unified to the network management for exchange. All DB interactions are connected to the DB server for proxy processing.
Type II (cluster)
With one type of experience, the follow-up must be the finer the split, the better the performance, just like the current microservices, each identical module is distributed to a server for processing, and multiple groups of server clusters form a game server. In general, we can simply divide the servers in a group into two categories: scene-related (eg: walking, fighting, etc.) and scene-irrelevant (eg: guild chat, trade that is not restricted by regions, etc.). A common solution is: gate server, scene server, non-scene server, chat manager, AI server, and database proxy server. The following model:
In the above, we briefly talk about the three types of functions of common servers:
Scene server: It is responsible for completing the main game logic, which includes: entering and exiting the character in the game scene, walking and running of the character, character fighting (including fighting monsters), claiming tasks, etc. The quality of the scene server design is the main manifestation of the performance difference of the entire game world server. Its design difficulty lies not only in the communication model, but also in the design of the entire server architecture and synchronization mechanism.
Non-scene server: It is mainly responsible for completing the game logic that is not related to the game scene. These logics can be performed normally without relying on the game's map system, such as guild chat or world chat. The reason why it is independent from the scene server is to Save the CPU and bandwidth resources of the scene server, so that the scene server can process the game logic that has a great impact on the smoothness of the game as quickly as possible.
Gateway server: In one type of architecture, players use the jump mode when jumping between multiple maps or switching scenes, so as to jump to different servers. Another way is to manage the nodes of these servers through the gateway server. Players interact with the gateway server. When each scene or server is switched, there is also a gateway server to exchange data uniformly, so that the player operation will be smoother.
With this type of server architecture, because the pressure is dispersed, the performance will be significantly improved, and the load will be larger, including some large-scale MMORPG games that use this architecture. However, with each additional level of server, the complexity of the state machine may double, which leads to an increase in the cost of research and development and bug finding.
Three types (seamless map)
The seamless map of World of Warcraft must be impressed by everyone. The movement of the whole world is not like the previous games, where you need to wait for loading when switching scenes, but walk directly over it and experience a smooth experience.
The current large map of the game adopts a 9-grid style to handle the seamless map. Since the map is not as big as the World of Warcraft, it can be processed by a single server and multiple processes. However, similar to the large world map of World of Warcraft, 2 issues must be considered:
1. How to seamlessly splicing multiple map nodes, especially when there are many map nodes, how to ensure seamless splicing
2. How to support dynamic distribution, some areas have many people, some areas have few people, to ensure the maximum utilization of server resources
In order to solve this problem, compared to the previous game cutting according to the map, there is no person on a map in the seamless world and only one server handles it. At this time, a group of servers is needed to handle it, and each Node server uses To manage a map area, the NodeMaster (NM) provides overall management for them. The higher-level World provides continental-level management services.
The area that a Node is responsible for does not need to be connected geographically, and can be managed by a Node, and there is no need to connect these blocks geographically. Which blocks a Node manages can be changed according to the real-time running load of the game and the configuration on the NodeMaster during regular maintenance.
Seamless Migration of Objects
Players A, B, and C represent 3 different states and different migration methods. Let's look at them separately.
- Player A: Player A is on the node1 map server and is controlled by node1. If it is migrated to node2, its data needs to be copied to node2, and then removed from node1.
- Player B: Player B is between node1 and node2, and is maintained by node1 and node2 at this time. If it is in the process of walking from node1 to node2, it will request to 1 and 2 at the same time, and then remove it after all the moves have passed.
- Player C: Player C is on the node2 map server and is controlled by node2. If it is migrated to node1, its data needs to be copied to node1, and then removed from node2.
The analysis of the specific World of Warcraft server is too much, we will talk about it later.
3. Room server (game lobby)
Room-style gameplay is very different from MMORPGs in that its online broadcast unit has a small amount of uncertainty and broadcasts. And need to match a room server to get a few people into a server.
The most important thing for this type of game is the capacity of its "game hall", each "game room" is limited by logic, and the player data that needs to be maintained and broadcast is limited, but the "game hall" needs to maintain a fairly high online The number of users, so generally speaking, this kind of game still needs to be "split". A typical game is a game like "League of Legends". The most challenging task in the "game lobby" is to "automatically match" players into a "game room", which requires searching and filtering all online players.
Players first log in to the "lobby server", and then select the function of team game. The server will notify all participating game clients to open a new connection to the room server, so that all participating users can interact with the game in the room server. .
Fourth, the last
Compared with Internet applications, the game industry is not perfect in openness and standardization, which has led to a mysterious veil in the game industry in many other industries, which is secret and closed.
There are many reasons for this. The complexity of the game business and the small audience are the main reasons. It does not have the support of open source organizations and community genes like web applications, nor does it have such a large audience and influence in the Internet industry, except for some Other than the well-known game engine, other functional components are built by each game company based on its own business logic. Each company's business direction is different, which increases the circulation of knowledge and the establishment of standards, which has had an impact on the development of the entire ecosystem. Constraints, especially for newcomers who want to join the game industry, the barriers to entry are high, and there are few learning materials available online.
This phenomenon is currently changing, and in addition to the growing and rich audience, there are also technical organizations that are advancing the progress of the entire community.
For example, the annual unity technology conference and other excellent open source engines are actively promoting the creation of the entire game community. In addition to attracting more excellent technical talents and teams to join, all these make the game industry more and more open and standardized , so that knowledge in the industry can also be circulated and inherited. Of course, I also hope that every game player can join in, share their knowledge, and let the spirit of free and open sharing be passed on to every place.
Quote:
http://www.skywind.me/blog/archives/1265
http://gcloud.qq.com/forum/topic/56a0bac3a90d8b775e8f3c1b
----------------------------------------end-------------------------------------
Focus on personal growth and game development, and strive to promote the growth and progress of the domestic game community.
If you want to know more interesting game technology, please pay attention to my public account, original and unique.
