MMO游戏设计一：角色行走

假设我们目前需要做的是一款3D MMO游戏，角色行走通过上下左右键控制，方位通过鼠标滑动来控制。先憧憬一下，应该达到的要求：

1.  客户端行走时，不能出现因为网络原因卡住的现象。

关于这点，在玩DOTA时深有感触，网络延时300ms+的时候，明显感觉有顿卡，发起操作指令的时候，反应很慢。然后跑到野区打野还是一样的卡，体验很差。

2.  客户端与服务端之间的同步包尽可能的少。

带宽有限，为了尽可能的提高同时在线人数，这么做大家都懂的。

3.  其他玩家的行走，在本地客户端看来，也尽可能流畅，尽可能少的出现角色位置回拉，或者瞬移等现象。

先从第一点说起，本地客户端行走时，出现卡住一般是因为等待服务端的同步消息或者同步帧。为了提高玩家的体验，不妨先“信任”客户端的坐标，玩家本地的行走包并不需要收到服务端的确认，就可以直接行走。服务端只需要将坐标等信息广播到其它玩家同步坐标即可。

为保证客户端发送的同步包尽可能的小，同步坐标时引入速度和方位两个字段，另外携带时间戳，这样在速度和方位不变的情况下，只用发一个包；或者还有一种比较极端的方案，即在本地计算一个“模拟坐标”（其它玩家看到的坐标），然后每一帧都拿真实坐标和模拟坐标进行对比，只要在一定的误差范围内，都不必发送同步包。

服务器收到同步包之后，根据服务器当时的时间戳（假定服务端和客户端有一个好的对时协议保证时间戳的误差足够小）计算出延时，根据延时预测出玩家A目前的位置。然后将同步包发送给周围的玩家，周围玩家的客户端收到同步包后，也使用当时的时间戳，预测出玩家A此时的位置。如果延时比较大，这个时候预测的位置和同步包的位置相差可能会很大，一般有两种做法，一种是直接将玩家拉扯到预测坐标，另一种是让玩家平滑的行走过去。玩家行走到预测位置之后，这个时候启动定时器，然后根据速度定时更新坐标。

这种做法有个弊端，考虑玩家A，在延时100ms的时候，发起前进指令，行走200ms之后停下来（但此刻的延时为1500ms）。由于停下来的时候延时大，就会导致其他客户端“误以为”玩家A行走了很长的时间。后来收到停止包之后才发现“在错误的道理上走的这么远”，最后还需要将玩家A会拉到停止坐标。这就是所谓的预测-回拉现象。在实际测试中，发现回拉现象非常明显，体验极差。可以采用以下策略尽可能的规避“回拉”：

1.  限制客户端预测的行为，预测的位移不能超过允许的误差值。

2.  只要位移差不是很大，就不用回拉。其实用“像素差”来代替“位移差”更为合适，因为从感官上讲，像素差更为直接。比方说，5米处有个玩家走了1米，和50米处某个玩家走了1米，视觉差别是很大的。

3.  提高同步包的频率。理论上，同步频率越高，人物的行走看起来就越真实，误差越小。但为了尽可能的减少带宽，同步包的频率还必须控制在一定值，比方说最大频率不超过5HZ。另外，距离越近的角色，坐标同步的频率应该越高，越远的角色则同步频率越低。

参考文献：

1.  带宽限制下的视觉实体属性传播

2.  Latency Compensating Methods