Architecture and differences between mobile games, web games, and client game servers

Gameres asset protection network released, Wen/Wei yixiao

There is essentially no difference between a browser game and a client game server. The difference is the game type.

Type 1: weak interaction servers such as cards and parkour

Due to weak interaction, players do not need to face-to-face pk in real time. Just click the offline data of the other party, calculate the ranking list, and buy and sell the items, therefore, simple HTTP servers are often used:

During login, asymmetric encryption (RSA, DH) can be used. Based on the client uid, the server also has the server private key, and the Encrypted Key obtained by hash calculation is sent to the client. Then both parties use HTTP Communication and use that key for RC4 encryption. After receiving the key and timestamp, the client saves them in the memory for subsequent communication. The server does not need to save the key, this is because the UID and timestamp uploaded by the client and the private key of the server can be calculated every time. It simulates TLS behavior to ensure the client identity between multiple HTTP requests, and ensures that the same person's two logon keys are different through timestamps.

At the beginning of each game, visit and request the level data. After the game is finished, submit it again to check whether it is legal and what rewards are obtained. The database can be used for a single MySQL or MongoDB instance, cache the backend redis instance (optional ). If you want to implement notifications, let the client round-robin the server for 15 seconds at a scheduled time. If there is a message, retrieve it. If there is no message, you can gradually extend the polling time, for example, 30 seconds. If there is a message, the polling time is shortened to 10 seconds and 5 seconds. Even if the two chat, the latency can be adaptive.

This type of server is more than enough to implement a three-country strategy or card and cool-run game. This type of game is developed quickly by using HTTP because of its simple logic and poor interaction between players, debugging only requires a browser to clear the logic debugging.

Type 2: First Generation game server 1978

In 1978, Roy Trubshaw, a student at the University of Essex of the famous British financial University, compiled the world's first mud program mud1. after the University of Essex connected ARPANET in 1980, it joined many external players, including foreign players. Since the source code of the mud1 program is shared by ARPANET, many adapted versions have emerged. So far, mud has become popular in the world. Based on the continuous improvement of mud1, the open-source mudos (1991) has become the originator of many online games:

Mudos is developed in C language. Because there is strong interaction (chat, transaction, and PK) between players, mudos uses a single thread without blocking socket to serve all players, all players' requests are sent to the same thread for processing. The main thread updates all objects every second (Network sending and receiving, updating the object state machine, processing timeout, refresh the map, and refreshing the NPC ).

The gaming world is organized in the form of rooms. Each room can be moved to the next room in four directions: Southeast and northwest. Because the earliest online games in Europe and America were in the form of a dungeon maze, therefore, the basic unit of a scenario is "room ". Mudos uses a scripting language called LPC to describe the whole world (including room topology, configuration, NPC, and various plots ). Senior players (Wizards) in the game can constantly add room and plot for the game by modifying the script. In early years, mud1 had only 17 rooms, and Roy Trubshaw handed it over to his younger brother Richard battle after graduation. In Richard battle's hand, he continued to add various methods to over one hundred rooms, finally let mud develop.

The user uses a client such as telnet to connect to mudos using the TCP protocol and uses plain text for the game. Each Command is separated by a carriage return. For example, in 1995, the first mud game "Knight's line" in China, you typed: "Go East", and the game will prompt you: "Back Garden-the back garden of yunzhuang is full of flowers and plants, some zhuangding are watering the flowers. This is the place where shame grows. The only exit here is north. Here are: Hua Yao a mu (a mu), there are two Zhuang Ding (Zhuang ding) ", and then you continue to use text operations, view the information of a mu:" Look a mu ", the system prompts: "Hua Yao a mu (a mu) is a disciple of Lu chengfeng and is ordered to take care of the mimosa. He looks like he is in his third-year-old age. He is very elegant and has a talent set. His martial arts looks [not very high], and the shot seems to be [very light ]". Then you can choose to beat him to get mimosa, But if you eat mimosa, you may die of poisoning. In the early days when resources on the Internet were poor, such games had a strong sense of substitution.

User data is stored in a file. When each user logs on, all user data is loaded from the text file, and all operations are performed in the memory. You do not need to brush back to the disk immediately. If the user exits, or the data changes are detected every five minutes, the disk is saved. Such a system was not a big problem when each server was carrying a game with 4000 people at the same time. Since the release of mudos in 1991, all regions around the world are improving, expanding, and exiting the new version. With the enhancement of Windows graphics Functions. In 1997 game uo, the X and Y coordinates added to the role are based on mudos. Maps are added to each room and animations are added to each role, formed the first generation of graphics network games.

Because the game content can be customized through the LPC script, mudos has become the first server engine in the real world. The engine is developed at one time and then different game content is created. Many of the following Games in China, such as "King of Kings", were directly developed on mudos like "uo". The map added to the room had the coordinates of the role and other elements, this architecture has provided solid support for the first generation of MMORPG in China until 2003, with the development of games based on mudos.

Although a lot of things are added to the graphics behind them, the essence of these MMORPG backend is mudos. As the game content becomes more and more complex, the architecture becomes more and more difficult, and various load problems gradually floated onto the water, so we had our second generation game server.

Type 3: Second Generation game Server 2003

After 2000, online games had moved away from the original text mud and entered the era of comprehensive graphics. The first thing that can't bear is actually a lot of small files. The user goes online and offline, and reads and writes user data frequently, resulting in an increasing load. As the number of online users increases and game data increases, servers become overwhelmed. At the same time, the ext disk partition was weak in the early days, and there was a slight power failure, which could easily lead to massive data loss. Therefore, the first step is to split the file and store it in the database.

At this time, the game server has been separated from the old mudos system. companies start to re-develop their own game server with C when referring to the mudos structure. The script also discards the LPC and uses Python or Lua with better scalability. Because the main logic uses a single-threaded model, the structure of a traditional single server becomes a bottleneck as the game content increases. As a result, someone began to split the game world into the following model:

The pressure on the game server is relaxed after the split, but the two game servers access the database at the same time, with a large number of repeated accesses and a large amount of data exchange, making the database the next bottleneck. As a result, the Database Front-end proxy is formed. The game server accesses the database instead of directly accessing the database, but also accessing the database by proxy, and provides memory-level cache. In the early years, mysql4 did not provide a storage process. This front-end proxy is generally running on the same platform as MySQL. It converts the advanced data operation commands sent by the game server into specific database operations, to some extent, the stored procedure is replaced:

However, this structure does not last for a long time, because the player often needs to switch the connection in switching scenarios, and the intermediate state is prone to disorder. In addition, when there are more game servers, the data interaction between them will become more troublesome. As a result, people split the network functions and independently developed a gateway service gate (Session in some places, in some cases, such as linksvr, the names are different ):

The network functions are extracted separately, allowing users to connect to a gateway server, and then the gateway server forwards data to the backend game server. Game servers are also centrally connected to network management for data exchange. This type of server can stably provide game services to players. One gateway serves 1-2 million people, and each backend game server provides 5-1 million services, depending on the game type and complexity, the figure hides many unimportant servers, such as logon and management. This is currently the most widely used model. So far, many new projects will use this structure to build it.

People have inertia. According to previous experience, it seems that the more open the mudos split, the better the performance. As a result, we continue to think that the gateway can be split. Basic services such as chat transactions can be split, and web interfaces can be provided. databases can be split, so we have the following model:

Is this model easy to use? It is indeed successful that the game has used an architecture similar to this and has taken advantage of its performance, such as some large MMORPG. However, there are two challenges: the complexity of the state machine may double each time a level-1 server is added, leading to an increase in R & D and Bug Locating costs. In addition, the challenges to the development team are relatively large. Once the project time is tight, developers are not experienced enough to easily get rid of it.

For example, I have met a first-line game company in Shanghai with an RPG architecture. I read the experiences of their team members and asked about their launch date, advise them to use a slightly simpler model. People are confident that they want to implement a successful project. As a result, they began coding without hesitation. After more than a year of project development, there was no such thing.

Nowadays, when the success rate of a game is not high, the ROI needs to be considered in the first complex architecture. For example, how many PCU will your game go to within six months of its launch? If an aprg game cannot reach people in each group of servers, it is more economical to choose a structure that is closer to the actual situation. Even if your project is truly targeted at 10 thousand people, I believe that your project has already made a lot of money at that time, and you are counting on the money to gradually iterate and split it again and again, I believe that my heart is happy.

The above types basically start from splitting mudos and split each part of mudos from a single machine to a distributed one by one. Although today many new projects use a similar structure above, or they have split other hotspot modules. Because they are essentially decomposition of mudos, they are classified as the second generation of game servers.

Type 4: third-generation game Server 2007

From the beginning of World of Warcraft, the seamless world map has been deeply rooted in the hearts of the people, compared with the previous game players to take a few steps but also need to switch the scene, each switch will have to wait for dozens of seconds loading is a very damaging game experience. Therefore, for large MMORPG after 2005, seamless map has become a standard configuration. Compared with the previous game cutting by map, the seamless world does not have people on a map and only one server handles them:

Each node server is used to manage a map area, and nodemaster (Nm) provides them with overall management. A higher level of world provides management services at the Chinese mainland level. Some detailed servers are omitted here, such as the traditional database front-end, Login server, log and monitoring, all of which are summarized by admin. In this structure, players need to simply process from one region to another:

PLAYER 1 is completely controlled by node A, and Player 3 is completely controlled by Node B. Players on the 2nd node at the edge of two nodes provide services at the same time by a and B. When PLAYER 2 moves from A to B, both requests the left side of Player A and requests the right side of Player B. However, Player 2 still belongs to administrator. It is not until PLAYER 2 leaves the AB boundary far away that it is completely managed by B. According to this logic, world maps are divided into one area and managed by different nodes.

Geographically there is no need to connect the regions where a node is in charge. For example, if there are fewer people in the peripheral part of the mainland and in the mountainous part, they can be handed over to a node for management, however, these blocks are geographically independent. Which blocks does a node manage? You can change the configuration on the nodemaster during regular maintenance based on the load of the game in real time.

So the first problem is that many node servers need to communicate with gamers. They need to ask which gate is the number of players with a specific uid on the management server, in the past, it was not a problem to cut servers by scenario. After a single question, the server can be cached. However, the number of server types has increased a lot, and the players are also drifting. It is troublesome to search for players by uid; on the other hand, the gate needs to dynamically calculate and communicate with which nodes based on coordinates, resulting in increasingly thick logic: the "user object" is cut out from the gate responsible for connection management, so it is imperative to have the following model:

The gateway server returns to the streamlined network forwarding function again, while the user logic is borne by the OBJ server divided by uid. The gate is distributed according to the load during network access, OBJ is distributed according to the resource ID (UID). In this way, the user can communicate with each other and directly calculate the OBJ server id based on the UID to send data. The new independent OBJ provides more high-level services:

• Object movement: manages the movement of players in different regions under different node jurisdictions and communicates with the desired node.

• Data Broadcast: node can set several tags for each user, and then notify the object master to broadcast by TAG.

• Object message: a common message is pushed to send data to a user and directly tells obj. You do not need to deal with gate directly.

• Chat with friends: the chat between roles goes directly to OBJ/obj master.
  

After the entire server body is divided into three layers, the Node focuses on the scenario, the OBJ focuses on the player object, and the gate focuses on the network. This model is widely used in seamless scenario servers. However, with the passage of time, load problems become more and more obvious. For an activity, areas that are far inactive become very active, and the adjustment by weekly maintenance is heavy, therefore, dynamic load balancing is available.

There are two methods for Dynamic Server Load balancer. The first method is to dynamically move and modify the boundaries of each node according to the load, different player objects are migrated from one node to another using the previous method:

Figure 11 Dynamic Load Balancing

In this way, the node master regularly finds the hotspot areas on the map, computes the new scene cutting method, and then tells other servers to start adjusting. The specific processing method is the same as that of moving the above object across the border.

However, the above implementation is relatively complicated, so people have designed a simpler and more direct method:

Figure 12 grid-based Dynamic Load Balancing

The map is also evenly cut into static grids according to the standard size. Each grid is taken care of by a specific node, but it can be migrated to other nodes in real time based on the load. The migration is divided into three phases: Preparation, switchover, and completion. The three States are maintained by the node master. In the preparation phase, the new node starts to synchronize the data in the grid on the old node. After the grid is completed, the node is told to nm. After the NM is confirmed as OK, the new node is notified to complete the switchover. After the switch is complete, if the OBJ server is still communicating with the old node, the old node will correct it and the corrected OBJ will correct its status, communicates with the new node.

Many seamless dynamic load balancing servers claim to support an unlimited number of people, but it does not mean that the maximum number of MMORPG games can be expanded infinitely, because such a system is subject to network bandwidth and client performance. The bandwidth determines the maximum number of broadcasts in the same region, and the client performance determines the number of roles that can be drawn on the same screen.

Since the introduction of the distributed object model in seamless maps, it has completely escaped from the mudos system and become a new server model. Due to the introduction of Dynamic Server Load balancer, seamless servers are even more powerful than the upper limit of the number of game servers of the previous generation, and provide a better gaming experience, we call it the third-generation game server architecture. Online Games started with playing large multiplayer roles. RPG online games once occupied more than 90% in a long period of time, making the server architecture based on MMORPG flourish, however, as gamers get tired of RPG games, various non-Mmorpg games have sprung up and become popular in the market.

Type 5: War network game server

There are two differences between the classic network server and RPG games: RPG is server-specific, and users in Beijing and Guangzhou are always dead-handed. In the war network, although each game is generally within 8 people, there is only one server in the country, and all players can play together, while players and players are connected using P2P, make up a game:

Players use the match making server to create, join, automatically match, and invite a game. The server selects a person as the host, and other P2P players connect to the master node. Stun is a traction server that helps players establish P2P connections. Since P2P connections are only about 75%, gamers that cannot communicate with each other will forward messages through forward.

A large number of connection battles, sports and competitive games adopt a similar structure. P2P has a mesh model (all players are connected to each other) and a star model (all players are connected to one primary player ). Complex game statuses are difficult to form consistency under the mesh model, so the star P2P model has stood the test of history. In addition to game data, the war network system that supports voice also sends voice data of all players to the player's host and returns it to all users by means of audio mixing and deduplication.

War network games are dominated by sports, sports, and action games. Slow-paced RPG games (including arpg) are essentially different, the fierce game process will inevitably bring about more complex synchronization strategies of RPG games. This synchronization mechanism often results in a lot of game results directly calculated by the client, today, cracking is everywhere. How can we ensure the fairness of the game results?

The main method is the voting method. All clients are independently calculated and then passed to the server. If the results are the same, the record will be updated. If the results are inconsistent, the final result will be determined using a similar voting method. At the same time, it records all the input of this drama game. If possible, find another idle game client to check whether the entire game is the result. Users who are often suspected of cheating are recorded for reference during Operation staff seal.

Type 7: Casual game server

Casual Games are similar to battle network servers. They are all in a region-wide architecture. The difference is that there are room servers and specific game servers. Instead of playing P2P, the game subjects are connected to dedicated game servers for processing:

In the same region as the architecture of the war network, user data cannot be loaded to the memory at one time as the partition RPG, and then directly modified in the memory. In a region-wide architecture, in order to deal with a single user playing several games at the same time, user data must be differentiated between basic data and different game data, while game data must distinguish between point data and document data. Points such as Shengping can be directly submitted for incremental modification, while more common document-type data requires a read/write token. There is only one write token, and there are many read tokens. When a game with the same account is played on two computers at the same time, the first game that started to obtain a write token can operate any user data. In addition to the incremental change of the leader's negative points, the game started later adopts the read-only mode for user data to ensure that the game can run, but will prompt the user to lock the game data.

Type 8: Modern online games

Starting from the early Korean action games, traditional online Combat games and RPG games began to try to integrate. Simple action games are easy for players to get tired, and Their persistence is not as high as RPG games. simple RPG battles are slow and boring, which cannot meet the intense confrontation expectations of many players, so the two began to integrate into a new generation: Action + town model. Players gather in cities and towns, and then several people go out in the form of copies to complete various RPG tasks in the form of action games. In essence, it is a set of rpg server + replica server. Since the number of characters in each copy can be controlled within 8 people, a more real-time gaming experience can be achieved, making the player play faster.

　　

Architecture and differences between mobile games, web games, and client game servers