游戏架构 游戏架构设计(3)

原创文章，转载请注明出处：服务器非业余研究-sunface

NPC智能

　　NPC智能分为两种，一种是被动触发的事件，一种是主动触发的事件。对于被动触发的事件，处理起来相对来说简单一些，可以由事件本身来呼叫NPC身上的函数，比如说NPC的死亡，实际上是在NPC的HP小于一定值的时候，来主动呼叫NPC身上的OnDie() 函数，这种由事件来触发NPC行为的NPC智能，我称为被动触发。这种类型的触发往往分为两种：

一种是由别的物件导致的NPC的属性变化，然后属性变化的同时会导致NPC产生一些行为。由此一来，NPC物件里面至少包含以下几种函数：

class NPC {

public:

    // 是谁在什么地方导致了我哪项属性改变了多少。

    OnChangeAttribute(object_t *who, int which, int how, int where);

Private:

    OnDie();

    OnEscape();

    OnFollow();

    OnSleep();

    // 一系列的事件。

}

　　这是一个基本的NPC的结构，这种被动的触发NPC的事件，我称它为NPC的反射。但是，这样的结构只能让NPC被动的接收一些信息来做出决策，这样的NPC是愚蠢的。那么，怎么样让一个NPC能够主动的做出一些决策呢？这里有一种方法：呼吸。那么怎么样让NPC有呼吸呢？

　　一种很简单的方法，用一个计时器，定时的触发所有NPC的呼吸，这样就可以让一个NPC有呼吸起来。这样的话会有一个问题，当NPC太多的时候，上一次NPC的呼吸还没有呼吸完，下一次呼吸又来了，那么怎么解决这个问题呢。这里有一种方法，让NPC异步的进行呼吸，即每个NPC的呼吸周期是根据NPC出生的时间来定的，这个时候计时器需要做的就是隔一段时间检查一下，哪些NPC到时间该呼吸了，就来触发这些NPC的呼吸。

　　上面提到的是系统如何来触发NPC的呼吸，那么NPC本身的呼吸频率该如何设定呢？这个就好象现实中的人一样，睡觉的时候和进行激烈运动的时候，呼吸频率是不一样的。同样，NPC在战斗的时候，和平常的时候，呼吸频率也不一样。那么就需要一个Breath_Ticker来设置NPC当前的呼吸频率。

　　那么在NPC的呼吸事件里面，我们怎么样来设置NPC的智能呢？大体可以概括为检查环境和做出决策两个部分。首先，需要对当前环境进行数字上的统计，比如说是否在战斗中，战斗有几个敌人，自己的HP还剩多少，以及附近有没有敌人等等之类的统计。统计出来的数据传入本身的决策模块，决策模块则根据NPC自身的性格取向来做出一些决策，比如说野蛮型的NPC会在HP比较少的时候仍然猛扑猛打，又比如说智慧型的NPC则会在HP比较少的时候选择逃跑。等等之类的。

　　至此，一个可以呼吸，反射的NPC的结构已经基本构成了，那么接下来我们就来谈谈系统如何组织让一个NPC出现在世界里面。

NPC的组织

　　这里有两种方案可供选择，其一：NPC的位置信息保存在场景里面，载入场景的时候载入NPC。其二，NPC的位置信息保存在NPC身上，有专门的事件让所有的NPC登陆场景。这两种方法有什么区别呢？又各有什么好坏呢？

　　前一种方法好处在于场景载入的时候同时载入了NPC，场景就可以对NPC进行管理，不需要多余的处理，而弊端则在于在刷新的时候是同步刷新的，也就是说一个场景里面的NPC可能会在同一时间内长出来。而对于第二种方法呢，设计起来会稍微麻烦一些，需要一个统一的机制让NPC登陆到场景，还需要一些比较麻烦的设计，但是这种方案可以实现NPC异步的刷新，是目前网络游戏普遍采用的方法，下面我们就来着重谈谈这种方法的实现：

　　首先我们要引入一个“灵魂”的概念，即一个NPC在死后，消失的只是他的肉体，他的灵魂仍然在世界中存在着，没有呼吸，在死亡的附近漂浮，等着到时间投胎，投胎的时候把之前的所有属性清零，重新在场景上构建其肉体。那么，我们怎么来设计这样一个结构呢？首先把一个场景里面要出现的NPC制作成图量表，给每个NPC一个独一无二的标识符，在载入场景之后，根据图量表来载入属于该场景的NPC。在NPC的OnDie() 事件里面不直接把该物件destroy 掉，而是关闭NPC的呼吸，然后打开一个重生的计时器，最后把该物件设置为invisable。这样的设计，可以实现NPC的异步刷新，在节省服务器资源的同时也让玩家觉得更加的真实。

（这一章节已经牵扯到一些服务器脚本相关的东西，所以下一章节将谈谈服务器脚本相关的一些设计）

　　补充的谈谈启发式搜索（heuristic searching）在NPC智能中的应用。

　　其主要思路是在广度优先搜索的同时，将下一层的所有节点经过一个启发函数进行过滤，一定范围内缩小搜索范围。众所周知的寻路A*算法就是典型的启发式搜索的应用，其原理是一开始设计一个Judge(point_t* point)函数，来获得point这个一点的代价，然后每次搜索的时候把下一步可能到达的所有点都经过Judge()函数评价一下，获取两到三个代价比较小的点，继续搜索，那些没被选上的点就不会在继续搜索下去了，这样带来的后果的是可能求出来的不是最优路径，这也是为什么A*算法在寻路的时候会走到障碍物前面再绕过去，而不是预先就走斜线来绕过该障碍物。如果要寻出最优化的路径的话，是不能用A*算法的，而是要用动态规划的方法，其消耗是远大于A*的。

　　那么，除了在寻路之外，还有哪些地方可以应用到启发式搜索呢？其实说得大一点，NPC的任何决策都可以用启发式搜索来做，比如说逃跑吧，如果是一个2D的网络游戏，有八个方向，NPC选择哪个方向逃跑呢？就可以设置一个Judge(int direction)来给定每个点的代价，在Judge里面算上该点的敌人的强弱，或者该敌人的敏捷如何等等，最后选择代价最小的地方逃跑。下面，我们就来谈谈对于几种NPC常见的智能的启发式搜索法的设计：

Target select （选择目标）：

　　首先获得地图上离该NPC附近的敌人列表。设计Judge() 函数，根据敌人的强弱，敌人的远近，算出代价。然后选择代价最小的敌人进行主动攻击。

Escape（逃跑）：

　　在呼吸事件里面检查自己的HP，如果HP低于某个值的时候，或者如果你是远程兵种，而敌人近身的话，则触发逃跑函数，在逃跑函数里面也是对周围的所有的敌人组织成列表，然后设计Judge() 函数，先选择出对你构成威胁最大的敌人，该Judge() 函数需要判断敌人的速度，战斗力强弱，最后得出一个主要敌人，然后针对该主要敌人进行路径的Judge() 的函数的设计，搜索的范围只可能是和主要敌人相反的方向，然后再根据该几个方向的敌人的强弱来计算代价，做出最后的选择。

Random walk（随机走路）：

　　这个我并不推荐用A*算法，因为NPC一旦多起来，那么这个对CPU的消耗是很恐怖的，而且NPC大多不需要长距离的寻路，只需要在附近走走即可，那么，就在附近随机的给几个点，然后让NPC走过去，如果碰到障碍物就停下来，这样几乎无任何负担。

Follow Target（追随目标）：

　　这里有两种方法，一种方法NPC看上去比较愚蠢，一种方法看上去NPC比较聪明，第一种方法就是让NPC跟着目标的路点走即可，几乎没有资源消耗。而后一种则是让NPC在跟随的时候，在呼吸事件里面判断对方的当前位置，然后走直线，碰上障碍物了用A*绕过去，该种设计会消耗一定量的系统资源，所以不推荐NPC大量的追随目标，如果需要大量的NPC追随目标的话，还有一个比较简单的方法：让NPC和目标同步移动，即让他们的速度统一，移动的时候走同样的路点，当然，这种设计只适合NPC所跟随的目标不是追杀的关系，只是跟随着玩家走而已了。

　在这一章节，我想谈谈关于服务器端的脚本的相关设计。因为在上一章节里面，谈NPC智能相关的时候已经接触到一些脚本相关的东东了。还是先来谈谈脚本的作用吧。

　　在基于编译的服务器端程序中，是无法在程序的运行过程中构建一些东西的，那么这个时候就需要脚本语言的支持了，由于脚本语言涉及到逻辑判断，所以光提供一些函数接口是没用的，还需要提供一些简单的语法和文法解析的功能。其实说到底，任何的事件都可以看成两个部分：第一是对自身，或者别的物件的数值的改变，另外一个就是将该事件以文字或者图形的方式广播出去。那么，这里牵扯到一个很重要的话题，就是对某一物件进行寻址。恩，谈到这，我想将本章节分为三个部分来谈，首先是服务器如何来管理动态创建出来的物件（服务器内存管理），第二是如何对某一物件进行寻址，第三则是脚本语言的组织和解释。其实之所以到第四章再来谈服务器的内存管理是因为在前几章谈这个的话，大家对其没有一个感性的认识