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

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

服务器的广播

　　服务器的广播的重点就在于如何计算出广播的对象。很显然，在一张很大的地图里面，某个玩家在最东边的一个动作，一个在最西边的玩家是应该看不到的，那么怎么来计算广播的对象呢？最简单的办法，就是把地图分块，分成大小合适的小块，然后每次只象周围几个小块的玩家进行广播。那么究竟切到多大比较合适呢？一般来说，切得块大了，内存的消耗会增大，切得块小了，CPU的消耗会增大（原因会在后面提到）。个人觉得切成一屏左右的小块比较合适，每次广播广播周围九个小块的玩家，由于广播的操作非常频繁，那么遍利周围九块的操作就会变得相当的频繁，所以如果块分得小了，那么遍利的范围就会扩大，CPU的资源会很快的被吃完。

　　切好块以后，怎么让玩家在各个块之间走来走去呢？让我们来想想在切换一次块的时候要做哪些工作。首先，要算出下个块的周围九块的玩家有哪些是现在当前块没有的，把自己的信息广播给那些玩家，同时也要算出下个块周围九块里面有哪些物件是现在没有的，把那些物件的信息广播给自己，然后把下个块的周围九快里没有的，而现在的块周围九块里面有的物件的消失信息广播给自己，同时也把自己消失的消息广播给那些物件。这个操作不仅烦琐而且会吃掉不少CPU资源，那么有什么办法可以很快的算出这些物件呢？一个个做比较？显然看起来就不是个好办法，这里可以参照二维矩阵碰撞检测的一些思路，以自己周围九块为一个矩阵，目标块周围九块为另一个矩阵，检测这两个矩阵是否碰撞，如果两个矩阵相交，那么没相交的那些块怎么算。这里可以把相交的块的坐标转换成内部坐标，然后再进行运算。

　　对于广播还有另外一种解决方法，实施起来不如切块来的简单，这种方法需要客户端来协助进行运算。首先在服务器端的连接结构里面需要增加一个广播对象的队列，该队列在客户端登陆服务器的时候由服务器传给客户端，然后客户端自己来维护这个队列，当有人走出客户端视野的时候，由客户端主动要求服务器给那个物件发送消失的消息。而对于有人总进视野的情况，则比较麻烦了。

　　首先需要客户端在每次给服务器发送update position的消息的时候，服务器都给该连接算出一个视野范围，然后在需要广播的时候，循环整张地图上的玩家，找到坐标在其视野范围内的玩家。使用这种方法的好处在于不存在转换块的时候需要一次性广播大量的消息，缺点就是在计算广播对象的时候需要遍历整个地图上的玩家，如果当一个地图上的玩家多得比较离谱的时候，该操作就会比较的慢。

服务器的同步

　　同步在网络游戏中是非常重要的，它保证了每个玩家在屏幕上看到的东西大体是一样的。其实呢，解决同步问题的最简单的方法就是把每个玩家的动作都向其他玩家广播一遍，这里其实就存在两个问题：1，向哪些玩家广播，广播哪些消息。2，如果网络延迟怎么办。事实上呢，第一个问题是个非常简单的问题，不过之所以我提出这个问题来，是提醒大家在设计自己的消息结构的时候，需要把这个因素考虑进去。而对于第二个问题，则是一个挺麻烦的问题，大家可以来看这么个例子：

　　比如有一个玩家A向服务器发了条指令，说我现在在P1点，要去P2点。指令发出的时间是T0，服务器收到指令的时间是T1，然后向周围的玩家广播这条消息，消息的内容是“玩家A从P1到P2”有一个在A附近的玩家B，收到服务器的这则广播的消息的时间是T2，然后开始在客户端上画图，A从P1到P2点。这个时候就存在一个不同步的问题，玩家A和玩家B的屏幕上显示的画面相差了T2-T1的时间。这个时候怎么办呢？

　　有个解决方案，我给它取名叫 预测拉扯，虽然有些怪异了点，不过基本上大家也能从字面上来理解它的意思。要解决这个问题，首先要定义一个值叫：预测误差。然后需要在服务器端每个玩家连接的类里面加一项属性，叫latency，然后在玩家登陆的时候，对客户端的时间和服务器的时间进行比较，得出来的差值保存在latency里面。还是上面的那个例子，服务器广播消息的时候，就根据要广播对象的latency，计算出一个客户端的CurrentTime，然后在消息头里面包含这个CurrentTime，然后再进行广播。并且同时在玩家A的客户端本地建立一个队列，保存该条消息，只到获得服务器验证就从未被验证的消息队列里面将该消息删除，如果验证失败，则会被拉扯回P1点。然后当玩家B收到了服务器发过来的消息“玩家A从P1到P2”这个时候就检查消息里面服务器发出的时间和本地时间做比较，如果大于定义的预测误差，就算出在T2这个时间，玩家A的屏幕上走到的地点P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再继续走下去，这样就能保证同步。更进一步，为了保证客户端运行起来更加smooth，我并不推荐直接把玩家拉扯过去，而是算出P3偏后的一点P4，然后用(P4-P1)/T(P4-P3)来算出一个很快的速度S，然后让玩家A用速度S快速移动到P4，这样的处理方法是比较合理的，这种解决方案的原形在国际上被称为（Full plesiochronous），当然，该原形被我篡改了很多来适应网络游戏的同步，所以而变成所谓的：预测拉扯。

　　另外一个解决方案，我给它取名叫 验证同步，听名字也知道，大体的意思就是每条指令在经过服务器验证通过了以后再执行动作。具体的思路如下：首先也需要在每个玩家连接类型里面定义一个latency，然后在客户端响应玩家鼠标行走的同时，客户端并不会先行走动，而是发一条走路的指令给服务器，然后等待服务器的验证。服务器接受到这条消息以后，进行逻辑层的验证，然后计算出需要广播的范围，包括玩家A在内，根据各个客户端不同的latency生成不同的消息头，开始广播，这个时候这个玩家的走路信息就是完全同步的了。这个方法的优点是能保证各个客户端之间绝对的同步，缺点是当网络延迟比较大的时候，玩家的客户端的行为会变得比较不流畅，给玩家带来很不爽的感觉。该种解决方案的原形在国际上被称为（Hierarchical master-slave synchronization），80年代以后被广泛应用于网络的各个领域。

　　最后一种解决方案是一种理想化的解决方案，在国际上被称为Mutual synchronization，是一种对未来网络的前景的良好预测出来的解决方案。这里之所以要提这个方案，并不是说我们已经完全的实现了这种方案，而只是在网络游戏领域的某些方面应用到这种方案的某些思想。我对该种方案取名为：半服务器同步。大体的设计思路如下：

　　首先客户端需要在登陆世界的时候建立很多张广播列表，这些列表在客户端后台和服务器要进行不及时同步，之所以要建立多张列表，是因为要广播的类型是不止一种的，比如说有local message,有remote message,还有global message 等等，这些列表都需要在客户端登陆的时候根据服务器发过来的消息建立好。在建立列表的同时，还需要获得每个列表中广播对象的latency，并且要维护一张完整的用户状态列表在后台，也是不及时的和服务器进行同步，根据本地的用户状态表，可以做到一部分决策由客户端自己来决定，当客户端发送这部分决策的时候，则直接将最终决策发送到各个广播列表里面的客户端，并对其时间进行校对，保证每个客户端在收到的消息的时间是和根据本地时间进行校对过的。那么再采用预测拉扯中提到过的计算提前量，提高速度行走过去的方法，将会使同步变得非常的smooth。该方案的优点是不通过服务器，客户端自己之间进行同步，大大的降低了由于网络延迟而带来的误差，并且由于大部分决策都可以由客户端来做，也大大的降低了服务器的资源。由此带来的弊端就是由于消息和决策权都放在客户端本地，所以给外挂提供了很大的可乘之机。

　　下面我想来谈谈关于服务器上NPC的设计以及NPC智能等一些方面涉及到的问题。首先，我们需要知道什么是NPC，NPC需要做什么。NPC的全称是（Non-Player Character），很显然，他是一个character，但不是玩家，那么从这点上可以知道，NPC的某些行为是和玩家类似的，他可以行走，可以战斗，可以呼吸（这点将在后面的NPC智能里面提到），另外一点和玩家物件不同的是，NPC可以复生（即NPC被打死以后在一定时间内可以重新出来）。其实还有最重要的一点，就是玩家物件的所有决策都是玩家做出来的，而NPC的决策则是由计算机做出来的，所以在对NPC做何种决策的时候，需要所谓的NPC智能来进行决策。

　　下面我将分两个部分来谈谈NPC，首先是NPC智能，其次是服务器如何对NPC进行组织。之所以要先谈NPC智能是因为只有当我们了解清楚我们需要NPC做什么之后，才好开始设计服务器来对NPC进行组织。