以前在做飞机游戏 (Wings of Fate) 的时候，实现过一个改善同步的技术，用来降低高ping客户端的延时感受（客户端的动态预测和延时补偿技术）。前两天跟朋友L聊天时表达了一下，觉得有记录下来的价值，遂有此文，以备日后参考。

有A和B两个客户端，在B移动时，A的客户端上会以一定频率收到B的移动信息同步。如果总是等到收到B的信息后再去被动地移动，那就会导致在A的机器上，B的移动总是滞后的。这一般是典型MMO如WOW的做法，而对某些类型的游戏(fps，空战)来讲，这种延迟是难以接受的。

一个做法是，A总是通过B之前的移动去预测其接下来的移动情况（Q3的做法），这样有极大的可能（实测至少90%以上的情况下）在服务器把B的真实移动信息发过来时，双方是匹配的（也就是预测准确）。在这种完美情况下，在A机器上体验到的B的移动就没有滞后（这个“没有滞后”是相对服务器而言的，因为所有的计算以服务器为准，因此此处暂不考虑服务器跟B之间的延时）。预测本身可以通过缓存之前若干秒的操作队列来实现，注意仅依靠当前的状态是不够的。

这种预测会在B有新的操作事件发生的时候失败，而这里的处理与Q3稍有不同。比如B正在往前飞，突然松开了W键开始减速直到停下。在未收到B的减速及停止消息前，A仍保持了B在全速往前飞的预测，此时若收到了减速的信号（同步过来的加速度突然变为负向的，速度开始变化）此时A可以意识到，自己坐标系中的B已然偏离了正确的位置。那么可以采用一个补偿算法去修正B。修正的幅度可以参考当前客户端的延迟情况。这个算法可以是激进的（尽量迅速地校准，牺牲平滑性）或保守的（保证飞行的平滑性，牺牲修正速度）。

当然了，前文中服务器与B（消息发送端）之间的延时，仍然对玩家体验有决定性影响。当客户端把自身的操作发给服务器时，这时的延时真正的决定了客户端的最快反应时间。这时网络环境的好坏，会直接影响玩家（在游戏中实际表现出）的反应速度。

[2014-03-16] Update:

补充几句话，怎么判断什么时候用这个预测和补偿，用的时候强度有多大呢？仍以前面的AB客户端为例的话，一般来讲约 100ms 的阙值即可（延时越敏感，客户端B的avatar移动速度越快，这个值应越低）。当A与服务器之间的延时(可定期roundtrip测得)高于阙值时，就可以开始缓存操作序列来做预测了。

(全文完)