网络游戏的位置同步.docVIP

网络游戏的位置同步 　有关位置同步的方案实际上已经比较成熟，网上也有比较多的资料可供参考。在《带宽限制下的视觉实体属性传播》一文中，作者也简单提到了位置同步方案的构造过程，但涉及到细节的地方没有深入，这里专门针对这一主题做些回顾。 　　最直接的同步方案就是客户端在每次发生位置改变时都向服务器报告?，服务器再转发给周围的其他玩家，其他客户端将对应的游戏实体移动到新的位置上。 　　但是这样存在一个问题，每个玩家的位置都是自己先开始移动，一段时间之后才在其他玩家的客户端上表现出来。如果只是希望每个客户端上看到的游戏对象都同时开始移动，那可以让玩家的每一步操作都由服务器确认之后再执行，这样误差将缩减到不同客户端之间的网络延时差。但是显然的，这样的做法不可能真正被采用，因为这将使得玩家的游戏体验非常的糟糕。有谁能忍受连每走一步路都要卡一下的游戏呢？ 　　既然一定存在先后时间差，那需要一种方法来让不同客户端上看到的玩家位置不至于有太大的误差，尤其是不能有影响到游戏公平性的误差存在。根据误差出现的直接原因：时间差，我们应该能够想到一个解决方案，那就是让其他客户端设法弥补掉这段时间差内少走的距离。这样的话也就要求我们的消息包中多带一个开始移动的时间数据，用于其他客户端在收到这个消息包时计算对应的玩家实体已经移动过的时间和距离。 　　我们以一个实际的例子来说明如何减少这种误差的影响。假设玩家A以速度V从P1点去到P2点，A的网络延时为T1，在A旁边有个玩家B，他的网络延时为T2。B收到服务器转发过来的移动包时，A在其自己的客户端上已经移动了T1+T2的时间，在这段时间内他自己已经走过了V*(T1+T2)的距离。如果这时在B的客户端上开始将实体A从P1移动到P2，那显然两个客户端上看到的A的位置始终存在V*(T1+T2)的误差。 　　为了使A在B客户端上显示的位置与其实际位置的误差尽可能的缩小，一个简单的做法是直接将A的位置向前拖V*(T1+T2)然后开始移动，这样两者之间的误差便消除了。但这样会使得客户端的显示太鲁莽，要让其看起来平滑一些，我们可以考虑使用一些算法，比如计算出A从当前位置走到P2点还需要的时间，然后加快其速度使其在规定的时间内到达P2点，这样A和B看到的最终时间是相同的，但中间过程还是存在较多误差。另一种较好的做法是先让A以一个可接受的较快速度移动到其当前应该所在的位置稍前一点的地方，然后以正常速度移动到P2点，这样后面的移动情况与其实际移动情况基本吻合了。 　　看起来这个方案很完美，但是这里却忽略了一个问题：我们假设的是每次移动时都知道玩家要去的确切位置。这在靠鼠标点击来移动的2D游戏中是正好合适的，但是在WOW一类的靠键盘来移动的3D游戏中却没有办法采用。WOW中的移动消息都只能向服务器报告当前的坐标及朝向信息。 　　这类移动的位置同步其实也可以采用类似方案，服务器将移动玩家的当前位置信息广播给周围的其他玩家，当然其中也包含了时间戳。当其他玩家收到这个移动包后，表示的是在过去的某个时间里该玩家移动到了这个位置。如果只是简单地将其对应的实体移动到这个位置，那同样的，也存在位置误差。 　　与上一种情况类似，如果我们知道该玩家的移动速度，再通过数据包中的时间戳，假设该玩家还在以相同的速度朝相同的方向移动，那我们也可以预测出该玩家从开始移动到现在这段时间内他走了多远了距离。我们也可以将其位置做适当的修正，并使其继续移动下去。 　　我们需要先停下来考虑一下这些算法的部分细节。其中出现了一些数据是否应该包含在我们的每个消息包中，也就是我们需要考虑的另外一个问题：移动同步的消息中应该包含哪些数据，以及这些数据到底应该向哪些玩家广播。 　　对于2D游戏的情况来说，我们的算法需要的数据有：玩家的速度V，玩家开始移动的时间T0，收到数据包的时间T1，玩家当前位置P1和玩家要去的位置P2。T1和P1从当前客户端上都可以取到，而速度V一般来说不会经常改变，至少不是每次移动时都不一样，所以我们可以为速度的改变设计单独的消息码，这样V值也是可以在客户端上取到的。最后，每个移动消息中包含的数据只需要有移动到的位置P2和开始移动的时间T0。 　　其他客户端在使用特定算法将玩家移动到P2后会将其停在此处，直到收到下一个移动包时再开始移动。而对于在移动过程中又收到了新的移动包的处理过程基本类似，不做过多描述。 　　对于3D游戏的情况，算法是基本相同的，但是没有目标点，替换为移动方向，比如是向正前方移动，还是向左或向右移动等。在这种情况下，只要没有收到玩家停止移动的消息，其他客户端上都会以最后一次收到的移动包的状态来继续模拟移动。 　　所以，在网络偶尔卡一下的时候也会出现一些奇怪的现象。比如WOW中，看到队友直冲冲地走下了悬崖，你刚喊了句“怎么掉下去了？”只