Online-game server design (3)

Next, I want to talk about the NPC design and NPC intelligence on the server. First, we need to know what the NPC is and what the NPC needs to do. The full name of NPC is (non-player character). Obviously, it is a character but not a player. From this point, we can know that some NPC behaviors are similar to those of players, he can walk, fight, and breathe (This point is mentioned in the later NPC intelligence). What's different from the player's object is that, the NPC can be resumed (that is, the NPC can be re-generated within a certain period of time after being killed ). In fact, the most important thing is that all the decisions on player objects are made by players, while the decisions on NPC are made by computers, therefore, when making a decision on the NPC, we need the so-called NPC intelligence to make a decision.

Next I will talk about the NPC in two parts: the first is the NPC intelligence, and the second is how the server organizes the NPC. The reason for talking about NPC intelligence is that we can design servers to organize the NPC only when we understand what we need to do.

NPC smart

There are two types of NPC intelligence: passive events and active events. For passively triggered events, the processing is relatively simple. The event itself can call functions on the NPC, such as the death of the NPC, in fact, when the HP of the NPC is smaller than a certain value, it actively calls the ondie () function on the NPC. This kind of NPC intelligence triggered by events is called passive triggering. There are usually two types of triggers:

One is the change of the attributes of the NPC caused by other objects, and the change of attributes will also lead to some behaviors of the NPC. As a result, the NPC object contains at least the following functions:

Class NPC {

Public:

// Who is causing my attributes to change.

Onchangeattribute (object_t * Who, int which, int how, int where );

PRIVATE:

Ondie ();

Onescape ();

Onfollow ();

Onsleep ();

// A series of events.

}

This is a basic NPC structure. This passive event that triggers the NPC, I call it the reflection of the NPC. However, such a structure can only allow the NPC to passively receive some information for decision-making. Such an NPC is stupid. So how can an NPC make some decisions? There is a way to breathe. So how can we let the NPC breathe?

A very simple method is to use a timer to regularly trigger the breathing of all the NPCs so that a single NPCs can breathe. In this case, there will be a problem. When there are too many NPCs, the last NPC breathing has not been completed, and the next breathing has come again. How can this problem be solved. There is a way for the NPC to breathe asynchronously, that is, the breathing cycle of each NPC is determined based on the birth time of the NPC, at this time, the timer needs to perform a period of time to check which NPCs should breathe at the time to trigger the breathing of these NPCs.

As mentioned above, how does the system trigger the breathing rate of the NPC itself? This is like a real person. The breathing frequency is different between sleeping and intense exercise. Similarly, the breathing frequency of the NPC is different from that of the normal one during combat. A breath_ticker is required to set the current breathing frequency of the NPC.

In the NPC breathing event, how do we set the NPC intelligence? It can be summarized into two parts: checking the environment and making decisions. First, we need to make statistics on the current environment, such as whether there are several enemies in the battle, how much HP is left in the battle, and whether there are any enemies nearby. The statistical data is passed into the decision-making module. The decision-making module makes some decisions based on the NPC's own personality orientation. For example, the attention-type NPC will continue to soar when the number of HP is relatively small, for example, a smart NPC will choose to escape when there are few HP nodes. And so on.

Now, the structure of a breathing and reflecting NPC has basically been made up. Let's talk about how the system organizes an NPC to appear in the world.

NPC Organization

There are two schemes to choose from. One is to save the location information of the NPC in the scenario and load the NPC when loading the scenario. Second, the location information of the NPC is stored on the NPC. There are special events for all NPC login scenarios. What are the differences between the two methods? What are their differences?

The advantage of the previous method is that when the scenario is loaded at the same time, the scenario can manage the NPC without additional processing, the disadvantage is that the refresh is synchronized during the refresh process, that is, the NPC in a scenario may be extended within the same time. However, the design of the second method may be a little effort-consuming. A unified mechanism is required to allow the NPC to log on to the scenario, and some troublesome designs are required, however, this scheme can achieve asynchronous refresh of the NPC, which is currently widely used in online games. Next we will focus on the implementation of this method:

First, we need to introduce the concept of a "soul", that is, after an NPC dies, what disappears is his physical body, and his soul still exists in the world without breathing, floating near death, waiting for the time to reincarnation, when the reincarnation, all the previous attributes are cleared, re-on the scene to build its physical body. So how can we design such a structure? First, create a ing table for the NPC that will appear in a scenario, and give each NPC a unique identifier. After loading the scene, load the NPC that belongs to the scenario according to the graph scale. In the ondie () event of the NPC, instead of directly dropping the object destroy, the NPC's breathing is disabled, a rebirth timer is opened, and the object is set to invisable. This design can achieve asynchronous refresh of the NPC, saving server resources while making players feel more real.

(This chapter involves some server script-related things, so the next chapter will talk about some designs related to server script)

In addition, we will talk about the application of heuristic searching in NPC intelligence.

The main idea is to filter all the nodes in the next layer through an inspiration function while giving priority to search in breadth, so as to narrow the search scope within a certain range. As we all know, pathfinding A * algorithm is a typical heuristic search application. Its principle is to design a judge (point_t * point) function at the beginning to get the price of point, then, during each search, all the vertices that may arrive at the next step are evaluated by the judge () function to get two or three low-cost points and continue the search, those points that have not been selected won't be searched any more. The consequence is that they may not be the optimal path, this is also why the * algorithm goes before the obstacle while seeking the path, instead of going through the diagonal lines in advance to bypass the obstacle. If you want to find the optimal path, you cannot use the * algorithm. Instead, you must use the dynamic planning method, which consumes much more than.

In addition to finding the path, what other aspects can be applied to heuristic search? In fact, a bigger point is that any decision-making of the NPC can be done through heuristic search, for example, escape. If it is a 2D online game, there are eight directions. Which direction does the NPC choose to escape? You can set a judge (INT direction) to give the price of each vertex, calculate the enemy strength of the vertex in the judge, or how agile the enemy is, finally, choose the least expensive place to escape. Next, let's talk about the design of several smart heuristic search methods common to NPC:

Target select (select target ):

First, obtain the list of enemies near the NPC on the map. Design the judge () function to calculate the cost based on the enemy's strength and distance. Then, select the enemy with the minimum cost to initiate an active attack.

Escape (escape ):

Check your hp in the breathing event. If HP is lower than a certain value, or if you are a remote soldier and the enemy is near, the escape function is triggered, in the escape function, it also organizes a list of all the enemies around you, then designs the judge () function, first selects the biggest enemy that threatens you, the judge () the function needs to determine the speed and combat strength of the enemy, and finally obtain a major enemy. Then, it designs the path's judge () function for the main enemy, the search range may only be in the opposite direction of the main enemy, and then calculate the price based on the strength of the enemy in these directions to make the final choice.

Random Walk (Random Walk ):

I do not recommend the * Algorithm for this, because once the number of NPCS increases, the CPU consumption is terrible, and most NPCs do not need long-distance routing, you only need to walk around, so randomly give a few points nearby, and then let the NPC walk over. If it encounters an obstacle, it will stop, so there is almost no burden.

Follow target (follow the target ):

There are two methods here. One is that the NPC looks stupid, and the other is that the NPC looks smarter. The first method is to let the NPC follow the path of the target, almost no resource consumption. The other is to let the NPC determine the current position of the other party in the breathing event while following, and then go straight, and then bypass a * when encountering an obstacle, this design will consume a certain amount of system resources, so it is not recommended that many NPCs follow the goal. If a large number of NPCS follow the goal, there is a relatively simple method: let the NPC and the Target move synchronously, that is, let them speed up and move the same path. Of course, this design is only suitable for the relationship between the NPC and the target, not the target, it's just a move with the players.