2014.03 客户端动态预测技术和延时补偿技术

Views

以前在做飞机游戏 (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测得)高于阙值时,就可以开始缓存操作序列来做预测了。

(全文完)


comments powered by Disqus
Built with Hugo