利用惯性和加速度进行网游位置同步
带宽限制下的视觉实体属性传播
(Propagation of Visual Entity Properties Under Bandwidth Constraints)
(http://blog.csdn.net/lfhfut/archive/2008/03/02/2138512.aspx)
一文中使用滞后补偿时间(LCT, Lag Compensation Time)来平滑客户端的显示.
在此方法下, 客户端主角显示在未来位置, 超前于服务器时间,
而同伴显示过去的位置, 滞后于服务器时间.
所以两个人一齐跑时, 总是会发现同伴落后于自己.
为了减弱同伴落后问题, LCT应该用于远方物体的位置同步, 越远LCT可以越大.
就像我们观察星星, 我们看到是其实是几万年前星星的样子, 因为星星距离我们有几万光年.
对于周围近距离的物体, LCT应该尽量小, 接近0.
所以上文并没有解决客户端的平滑问题.
文中所述的导航预测算法(DR, Dead Reckoning)并不应该放弃.
导航预测算法的原理是推算出未来的位置，LCT是将过去的位置作为现在位置来处理.
对于邻近物体, 应该显示未来的位置.
因为出于操作感的考虑, 主角的位置是超前于服务器的, 不可能等服务器确认后再移动.
所以周围同伴的位置也应该是超前的, 这样才不会有同伴总是落后于自己的现象.
导航预测算法不适用的主要原因是, 网游人物的移动是高度随机的, 状态更新太频繁.
这其实不是问题, 因为有预测肯定比没有预测要好.
在预测范围内, 就不必发位置更新.
最差情况下, 每个预测结果都是错误的, 必须修正为实际的位置,
这就退化成为没有预测的简单的位置更新方法.
但是如果网络延时50ms, 这50ms的预测是必须的.
因为客户端表现的是超前服务器50ms前的景象.
这就存在同伴掉下悬崖的现象, 因为同伴在悬崖边上的停止的消息要在50ms后才到.
这种问题在预测法中是无法解决的, 除非添加行为预测.
但是可以添加一个加速度来减少这种预测错误.
导航预测算法适用于飞机飞行模拟这类具有很大惯性的移动.
网游中的移动问题根源就是惯性不足, 有了惯性, 角色将无法任意更改移动状态,
从而大大减少预测错误.
人物在悬崖边上停止的动作必须有个减速的过程, 只要在50ms之前减速,
就会正确计算出停止点, 避免了坠崖. 开始移动时也是有个加速过程.
并且, 客户端主角的惯性可以大于服务器端, 而周围物体的惯性可以小于服务器端.
产生的效果是, 主角的动作变迟钝, 减少超前时间.
而周围物体稍稍灵活, 增加了超前时间.
或许我们所处的世界也是虚拟的, 创世者为了位置同步而给我们这个世界加上了惯性和加速度的规则.
（转载请注明来源于金庆的专栏）