Shulou(Shulou.com)06/01 Report--

This article mainly introduces the basic system of game server development and the example analysis of server-side development skills, the article is very detailed, has a certain reference value, interested friends must read it!

First of all, to be clear, there is an essential difference between doing game server development and doing traditional web development. Game server development, if there is no experience, there is no clear goal at the beginning, unlike web, some clear MVC architecture is often to meet the needs of planning as soon as possible, to achieve the function as soon as possible, to make the game run as soon as possible. But as there are more and more functions, the old code is modified more and more frequently, and the pile of bug exposed during game testing makes people feel even more helpless. At this time, we think of refactoring and the design of the architecture.

The framework design of the game is very important, good framework code analysis, clear responsibility, strong expansibility, easy to debug. These will save us a lot of time for development. So how to design the framework of the game? Maybe every game is different, but it's basically the same.

For the architecture design of the game server, we should first understand what the server architecture of the game consists of. What functions does a game need to have when it comes online? Some people may say, as long as the game is running, there is no problem accessing the server. The answer is no, the game architecture itself represents a system, which includes:

1, system initialization

2, game logic

3, database system

4, cache system.

5, game log

6, game management tools

7, common service components

Everything in this system is indispensable, and they work together to serve the entire operation process of the game. Let's introduce the functions of each system little by little.

One, system initialization

System initialization is what needs to be done when the server starts when there is no client connection. It is basically the reading of the configuration file and initializing the system parameters. But what we have to consider is where the parameters needed for system initialization are configured, whether they are configured on the local server or in the database, and go to the database when the server is started. Whether the configuration changes need to restart the server, and so on.

Second, game logic

Game logic is not only the core function of the game, but also the service center of the whole game. Whether it is developed or not directly determines the performance of the game server in operation. What should we pay attention to in the development of game logic?

(1) Network communication

The game is a kind of business with strong network interaction, and good underlying communication can maximize the performance of the game, increase the number of people online while being processed by a single server, and bring a better experience to the game. at least it is not easy to cause stutters in data interaction caused by the network layer. I recommend Netty here, which is currently the most popular NIO framework, and its usage can be seen in my previous article, so I won't say much about it here.

Some people wonder, the code also needs to be hierarchical? Of course, different codes represent different functional implementations. Today's development languages are all object-oriented, if we clutter the functional code together without thinking and sorting, it seems to achieve the function quickly at first, but in the later stage, if we want to change the requirements, or add new requirements to the original code, it is really defeated by yourself. So the code must be layered, mainly with the following layers:

A, the protocol layer, also known as the foreground and background interaction layer, is mainly responsible for analyzing the interaction protocol with the foreground and returning data. There is basically no business logic implementation at this layer. The data that interacts with the foreground starts and ends at this level. For example, if you use the Netty framework, then the ChannelHandlerContext of Netty, that is, Ctx, can only appear in this layer. It cannot appear in the implementation of the game business logic code, receive the request from the client, parse the required parameters in this layer, and then pass the parameters to the business logic method. After the business logic method is processed, the data to be returned to the client is returned to this layer, where the data is organized and returned to the client. In this way, the business logic can be separated from the network layer, and the business logic is only concerned with the business implementation, and it is also convenient for unit testing of the business logic.

B, business logic layer, here deals with the real game logic, the calculation of the price, the clearance of the customs, the timing of the timing. The saved data of the saved data. But this layer does not directly manipulate the cache or database, but only deals with game logic calculations. Because the business logic layer is the core of the whole game event processing, whether his processing is correct or not directly determines the correctness of the game. So the code of this layer should be implemented by diagonal-oriented method as far as possible. Do not duplicate code or similar functions to copy and paste, so that it is very inconvenient to modify, may be modified in one place, and forgot to modify the same code. Also consider that each method is testable, and it is best to have no more than 100 rows for a method. In addition, you can read more books on design patterns, which can help us design flexible and clean code.

Third, database system

The database is the core of storing the database, but when the game data is stored in the database, it will pass through the IO of the network and disk, and its access speed is very slow compared to the memory. Generally speaking, every time you visit the database, you have to establish a connection with the database. After the access is completed, in order to save the connection resources of the database, you have to disconnect the connection. This imperceptibly adds overhead to the server, which may be slower when accessing a large amount of data, and the game requires low latency, what should I do? We thought of the database connection pool, that is, put the connection that accesses the database into one place to manage. I keep opening it when I use it, get it there when I use it, and put it back after using it. So you don't have to make a new connection every time. But if we want to achieve a set of connection pool management components, it will take time not to say, the control of the technology is also a test, but also after testing, and so on, fortunately, the Internet open source today, there are some ready-made can be used, here recommended Mybatis, that is, to achieve the separation of code and SQL, but also enough flexibility to write SQL, is a good choice.

Fourth, cache system

In the game, the interaction between the client and the server requires low latency, and the lower the delay, the better the user experience. As mentioned before, low latency requires the server to process business as quickly as possible. For a client to respond to a request in the shortest possible time, the minimum must not exceed 500ms, because coupled with the back and forth network transmission time, it is basically 600ms-to 700ms, players will feel the game card. If you take the data directly from the database and save it back to the database after processing, this performance can not keep up. In the server, data processing in memory is the fastest, so we have to load some commonly used data into memory in advance, such as game data configuration table, frequently logged-in player data and so on. In this way, when dealing with the business, you don't have to go to the database, just take it from the memory, and the speed is faster. There are two common caches in the game, 1, directly store data in jvm or server memory, 2, use third-party caching tools, Redis is recommended here, detailed usage can be queried by yourself.

Fifth, game log

Log is a good thing, a game can not lose the log, and the log must be recorded in detail. It is the record of the player's behavior in the whole game, with this record, we can analyze the player's behavior, find out the shortcomings of the game, and the log is also a good credential and quick way to deal with the player's problems in the game.

In the game, the log is divided into: 1, the system log, which mainly records the system situation of the game server. For example: whether the database can be connected properly, whether the server starts normally, whether the data is loaded properly; 2, the player behavior log, such as what requests the players sent, what items they got, how much currency they consumed, and so on. 3, statistical log, this kind of log is a kind of statistics on the behavior of all players in the game, according to this statistics to analyze the behavior of most players, get some commonalities or differences, in order to operate different activities to attract users to consume.

In architecture design, logging must be a mandatory behavior, because if it is not mandatory, some function may forget to add logs for some reason, so when something goes wrong with this function, or the operation of some databases that ask us for this function, it's dumbfounded. We have to add more demand and change the code. Logs must be designed in a good format, and the data recorded in the logs should be easy to read and decompose. The log behavior can be described by an enumeration, which is added as a parameter to the last processing method of the function, so that no matter who calls the method, the parameter description is added.

As the saying goes, if you want to do good work, you must first sharpen its tools. The game management tool is a tool to deal with a series of problems in the operation of the game. It is not only for developers, but mostly for operators. After the game is launched, we need to deal with the online problems differently. It is impossible for programmers to deal with all the problems, so programmers have come up with a way to make you a tool to deal with whomever you like.

Sixth, game management tools

The game management tool is a growing system because it is often implemented with problems encountered in the game. But according to experience, there are some necessary functions, such as: server management, mainly responsible for server opening and shutting down, server configuration information, player information query, player management, such as kicking, sealing. Statistical query, player behavior log query, statistical query, secondary retention query, mail service, modification of player data, etc., according to the different requirements of the game, anything that can be realized by the tool can be achieved in the game management tool. It is management for all servers. A good and complete game management tool can improve the efficiency of dealing with problems encountered in game operation and provide better service for players.

Seven, common components

The common component is to provide public services for the operation of the game, for example, the recharge server, we do not have to take a recharge server, and you cannot provide multiple recharge server addresses to connect with third-party companies, they absolutely do not do it, this is crazy; there are also the gift package code for the operation and activities, as well as the management of registered users, players can enter different areas with a registered account, and so on. These are all services provided for all district servers, so they should be done separately from the game logic, so it is easy to manage, deploy and load balance. There is also the login verification of SDK. Now there are more mobile games, which need to be verified in docking with the channel. This is often a lot of http requests, which are slow, so this should be done separately. Do not verify it in the game logic, because the access time of network IO is uncontrollable, and http is a blocking request.

So, to sum up, a game server is composed of at least several major functional modules: a, game logic engineering; b, log processing engineering; c, recharge engineering; d, game management tool engineering; e, user login engineering; f, public activity engineering, etc., according to the different needs of the game, there may be others. In the design of the architecture, we must take into account the distributed deployment of the system, as far as possible to remove the common functions to do, so as to enhance the scalability of the system.

Some suggestions for server-side development

As the basic outline of game server-side development, this paper is a summary of game practice development. The first part is the professional foundation, which is used to guide recruitment and internship assessment. The second part is the introduction to the game, which describes the basic points of the game server-side development. The third part is the server-side architecture, which introduces some basic principles in the architecture design. I hope I can help you all.

A professional foundation

1.1 Network

1.1.1 understanding of TCP/IP protocol

Network transmission model

Sliding window technology

A three-way handshake for establishing a connection and a four-way handshake for disconnection

Various states in the process of connection establishment and disconnection

Transmission efficiency of TCP/IP Protocol

Thinking

1) Please explain the basic principles of DOS attack and DRDOS attack

2) one 100Byte packet, reduced to 50Byte, and its transmission efficiency is improved by 50%.

3) how to explain the TIMEWAIT status?

1.1.2 master common network communication models

Select

Epoll, the difference and application between edge trigger and platform starting point

The difference and Application between Select and Epoll

1.2 Storage

Computer system storage system

The memory structure of the program at run time

Computer file system, page table structure

The implementation principle, application scene and difference of memory pool and object pool

The use of Relational Database MySQL

Shared memory

1.3 Program

Have a deep understanding of the language CAccord +.

Deep understanding of interface, encapsulation and polymorphism, and practical experience

Deep understanding of commonly used data structures: array, linked list, binary tree, hash table

Familiar with commonly used algorithms and related complexity: bubble sorting, fast sorting

Introduction to game development

2.1 defensive programming

Don't trust client data, be sure to check it. As a server, you can't determine who your client is, and you can't assume it's well-intentioned. Please protect yourself. (this is the basic criterion for judging whether a server-side programmer is getting started.)

Be sure to judge the validity of the passed-on parameters and return values of the function. Internal subsystems and functional modules do not have too much trust, requiring low coupling and high cohesion.

For plug-in module design, the robustness of module function should be built-in to minimize the coupling between modules.

2.2 Design pattern

The Tao is natural. Don't be superstitious, infatuated with design patterns, let alone copy mechanically.

Simplify, solve the problem in the simplest way

To borrow a sentence from Dabao: the design is made in this day, and you can get it by a good hand.

2.3 Network Model

Self-made Wheels: must Select, Epoll and Epoll be more efficient than Select?

Open source framework: Libevent, libev, ACE

2.4 data persistence

Custom file storage, such as Fantasy Journey to the West

Relational database: MySQL

NO-SQL database: MongoDB

The selection of storage system should take into account factors: stability, performance, scalability

2.5 memory Management

Use memory pools and object pools to prohibit dynamic memory allocation during operation

It is better to check strictly the pointer parameters of input and output than to lack them.

Write memory protection. Use functions with memory protection (strncpy, memcpy, snprintf, vsnprintf, etc.) to prevent array subscripts from crossing the bounds

Prevent read memory overflow and make sure the string ends with'\ 0'

2.6 Log system

Simple and efficient, a large number of log operations should not affect program performance

Stable, so that the server crashes so that logs are not lost

Complete, the player must keep a log for key operations. Ideally, the player data can be reconstructed at any time through the log.

Switch, to add level switch control to the development log

2.7 Communication protocol

Using PDL (Protocol Design Language), such as Protobuf, can generate the front and back end code at the same time, reduce the cost of joint debugging of the front and back end protocols, and have good expansibility.

JSON, text protocol, simple, self-explanatory, no co-tuning cost, good scalability, and convenient for packet filtering and logging

Custom binary protocol, compact, efficient transmission performance, completely controllable, almost non-scalable

2.8Global unique Key (GUID)

Prepare for the suit.

It is easy to track props and equipment flow.

Each character, equipment, and prop should have a global unique Key

2.9 Multithreading and synchronization

Synchronization of message queues

2.10 state machine

Strengthen the state of the role

Check and check of pre-status

2.11 packet operation

Merge, merge packets within the same frame to reduce the number of IO operations

Single copy, try to keep only one copy with a package to reduce the number of memory copies

Reducing useless packets of Intermediate process in AOI synchronization

2.12 status monitoring

Monitor the internal status of the server at any time

Memory pool, object pool usage

Frame processing time

Network IO

Packet processing performance

The number of times processed by various business logic

2.13 packet frequency control

Based on the packet frequency control of each player and each protocol, paralyzed transmission gears

2.14 switch control

Each module has a switch, which can urgently shut down any function module that has a problem.

2.15 Anti-plug-in and anti-cheating

Packet frequency control can eliminate transmission gears.

Package id self-increment check, can destroy WPE

Packet check code can eliminate packet interception and tampering.

Pattern recognition? 99% of non-human operations can be kicked out.

As vice rises one foot, virtue rises ten

2.16 Hot Update

Hot update of core configuration logic, such as anti-addiction system, packet frequency control, switch control, etc.

Basic code hot updates, such as Erlang,Lua, etc.

2.17 Anti-brushing

Log the output of key system resources (such as Yuanbao, energy value, props, equipment, etc.)

The output and consumption of resources depend on the detection of two or more independent conditions as far as possible.

Strictly check the preconditions of each operation.

Verify the validity of parameters

2.18 Anti-crash

The bottom layer of the system has nothing to do with specific business logic, and a large number of robot stress tests can be used to expose all kinds of bug to ensure stability.

Business logic recommends using scripts

Systematic assurance that the game will not collapse

2.19 performance optimization

Asynchronization of IO operation

IO operations merge caching (transactional commit db operations, package merging, file log caching)

Cache mechanism

Reduce race conditions (avoid frequent switching in and out, minimize the use of locking, multithreading is not necessarily due to single threading) multithreading is not necessarily faster than single threading

Reduce memory replication

Test yourself, talk with the data, don't guess.

2.20 operational support

Interface support: real-time query, control instruction, data monitoring, customer service processing, etc.

Implementation consider providing Http interface

2.21 disaster recovery and fault plan

Slightly

Three server-side architecture

3.1 what is a good architecture?

Meet business requirements

Be able to quickly achieve planning requirements and respond to changes in requirements

System-level stability guarantee

Simplify development. Keep complexity at the bottom of the architecture, reduce the technical requirements for developers, logical development does not rely on the strong technical strength of developers themselves, and improve development efficiency.

Perfect operation support system

3.2 thoughts on the practice of Architecture

Simple, the architecture that meets the needs is a good architecture.

Design performance, seize the important 20%, there is no need to pick performance from the program code

Hot update is a must

People will inevitably make mistakes, and try their best to use a set of mechanisms to ensure the robustness of logic.

The design of game server is a challenging task, the development of game server has changed from single server structure to multi-service organization, and even the distributed solution of bigworld engine has appeared. Recently, we have learned that atlas, the server solution of Unreal, is also based on cluster.

Load balancing is a very complex issue. Instead of talking about the design of servers like bigworld and atlas, it is more about dividing the server structure based on functions and scenarios.

First of all, let's talk about the idea that server partition is based on the following principles:

Separate the functions that occupy more system resources (cpu, memory, IO, etc.) in the game and become a server independently.

For different games under the same server architecture, some servers should be reused as much as possible (process-level reuse).

Adapt to multi-core processors in a multi-threaded and concurrent programming way.

It is better to copy more data between servers than to maintain a clear data flow.

The process is divided mainly according to the scene. If you want to divide the process by function, you must keep the whole logic simple enough to meet the above 1 and 2 points.

Server structure diagram:

A brief description of each server:

Gateway is an application gateway, which is mainly used to maintain the connection with client. The server requires two kinds of IO, uses high concurrent connection and low throughput network model for client, such as IOCP, and uses high throughput connection to the server, such as blocking or asynchronous IO.

Gateways are mainly used for the following purposes:

Share the network IO resources

At the same time, it also shares the cpu-intensive operations such as encryption and decryption of network message packets, compression and decompression.

Client and internal server groups are isolated, and for client, all it needs to know is information about the gateway (ip and port).

Since client maintains a constant connection with the gateway, operations such as switching scene servers are transparent to client.

Maintain player login status.

World Server is a control center that distributes various computing resources to each server. It has the following responsibilities:

Manage and maintain multiple Scene Server.

Manage and maintain multiple functional servers, mainly synchronizing data to functional servers.

Complex forwarding of data between other servers and Gateway.

To achieve other cross-scene functions, such as team formation, chat, gangs and so on.

Phys Server is mainly used for player movement, collision detection and so on.

All players' mobile operations are checked on the server, so the server itself has all the map terrain and other related information. The specific check process is as follows: first, Worldserver receives a mobile message, WorldServer receives it, requests Phys Server to check, Phys Server checks successfully, and then returns to world Server, and then world server passes it to the corresponding Scene Server.

Scene Server scenario server, divided by scenario, each server is responsible for the scenario should be configurable. Ideally, it can be adjusted dynamically.

ItemMgr Server item management server is responsible for the production process of all items. Store an item drop database on the server and load it into memory when the server is initialized. Any server that needs to generate items communicates directly with that server.

AIServer is another functional server that manages the AI of all NPC. The AI server usually has two inputs, one is the player-related operation information sent by Scene Server, and the other is the clock Timer driver. In this design, AIServer is a client with many NPC for other servers. AIserver needs to synchronize all AI-related data, including a lot of player data. Due to the Timer driver feature of AIServer, the TBB library can be used to achieve multicore performance to a large extent.

Split the online game server into multiple processes and deploy them separately. The advantage of this design is that the modules are naturally separated and can be designed separately. Sharing the load can improve the bearing capacity of the whole system.

The disadvantage is that the network environment is not so reliable. Cross-process communication is unpredictable to a certain extent. Communication between servers is often difficult to set up a debugging environment, and it is easy to mess things up. And managing multiple connections correctly and efficiently is also a challenge for programmers.

In previous years, I have also written several related designs. I have been thinking about a question these days: if we want to do a low-level general module, it will make the follow-up development more convenient. What kind of needs should be addressed. This requirement should be single and basic, which is needed by every application.

Just as TCP protocol solves the problem of stable and reliable peer-to-peer data flow communication on the Internet. What the game world really needs is a stable and reliable point-to-point communication within the game system.

We can do this over a TCP connection. Once implemented, it can bring great convenience to the development of game services.

Various services in the game system, including not limited to login, auction, battle scenarios, data services, and other independent services, can be regarded as several terminals on the network. Each player can also be a separate terminal. Together, they form a network. On this network, the terminals can connect and communicate reliably.

The implementation can be like this: each virtual terminal has a unique address (Game Network Address, GNA) on the game virtual network (Game Network). This address can be pre-set or dynamically assigned. Each terminal can access the network through a unique TCP connection through several access points (GNAP) of the game network. Authentication is required in the access process.

The authentication process depends on internal security mechanisms, which can include password certificates or special access point distinctions. (for example, players need a specific access point to access the network, and the terminals connected to this access point must be players.)

After the authentication is passed, the network assigns a fixed game domain name to the terminal. For example, players will be assigned a domain name such as player.12345 when entering, and database access may be assigned to database.

By default, the game network provides a domain name query service (this service can be registered to the network through the authentication process), so that each terminal can query the corresponding address through the domain name.

Then, all the legally connected terminals in the game network can initiate connections and communicate with each other through their addresses. The whole protocol is based on the TCP protocol and works on the only TCP connection. It is different from connecting directly using TCP. It is reliable for each terminal to initiate a connection with each other in the game network. Not only can players initiate a connection to a service, but vice versa. Direct connections between players are also feasible (whether this is allowed or not depends on the design).

Because each virtual connection is based on a single TCP connection. Therefore, all kinds of unreliability of TCP connections initiated on the Internet are reduced. The authentication process is also unique at one time. And we provide domain name reverse search service, our game service can clearly and securely know who is connected.

The system can be designed so that each terminal on the game network is offline, and the domain name service will broadcast this message and notify everyone. This kind of broadcasting service is difficult to achieve on the Internet, but whether it is broadcast or multicast, it is feasible in this virtual game network.

In this design. On the logical level, we can allow players to send chat messages directly from the client to the chat server without the need to establish redundant TCP connections and unnecessary processing of forwarding and processing chat messages. The chat server can exist independently in the game network. You can also let the broadcast service actively push messages to the player, and the server initiates a connection to the player, rather than all connection requests are initiated by the player.

The composition of the virtual game network is an independent level, which can be realized by putting aside the specific game logic, and can separately consider the specific design scheme according to the carrying capacity. It is very conducive to stripping out specific game projects for development and optimization.

In the end, we may need a set of C libraries for communication within the game network. Api can be similar to socket api. Two more access and leave the game network can be done.

The above is all the contents of this article entitled "sample Analysis of basic system of Game Server Development and Server-side Development skills". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.