CS模式网络游戏的运动同步总结

概述

       目前有2种网络游戏拓扑结构：Peer to Peer和Client/Server模式。在RTS类型的游戏中大都使用Peer to Peer的帧锁定同步算法（如红警、帝国时代、war3等)。目前主流引擎都自带的是Client/Server模式的服务器（如Unity3d, UE4等）。在此推荐《multiplayer game programming》，该书对帧同步算法和CS模式的同步都有详细的阐述；并且该书介绍的对象同步思路与ue4的思路类似。

 

本文只对CS模式下的运动同步进行总结，CS模式下，server是绝对的权威，一切以server为准。

记住：延迟是无法消除的，要尽可能地隐藏延迟，让玩家具有良好的体验。

 

先定义一个符号：

  运动状态 S:   S表示某个运动状态(如位置、速度、转速等)

  操作事件  I:   I表示运动输入命令事件(如 加速度、立即停止、力等)

  突发事件 E:  如受到阻挡、炮弹冲击等非人为直接输入。 

 

0. Round Trip Time(RTT)

    

1. 哑终端方式（dump terminal）

    类似早期的终端，只发送键盘和鼠标输入给服务器，客户端不具有逻辑计算功能。

    时序图如下：

      

       如上图所示，客户端状态需要服务器同步过来，自己没有主动性，表现出一卡一卡的体验。

        用户的输入需要过RTT后才能得到反馈，客户端的状态比服务器滞后RTT/2时长。

 

2. client Interpolation

    还是使用的哑终端方式，服务器给出状态a,b；然后客户端使用ab的插值进行平滑过渡。

    时序图如下：

      

     客户端比服务器滞后RTT/2 + 包同步间隔，客户端逻辑带有内插值功能。

 

3. client prediction & server correction

    客户端具有预测功能（和服务器具有同样的代码逻辑），服务器会将状态同步到客户端，然后客户端进行较正。这个里面细节较多，主要分2个方面

进行考虑：

    a.  非本地玩家（机器人、其它远程玩家）的运动同步

       时序图如下：

         

     客户端0收到同步消息时，计算出当前服务器的状态；然后我们并不能立即用这个状态（会造成突兀抖动），需要进行插值平滑过渡到该状态。

 

    b. 本地玩家的运动同步

       时序图如下：

        

     本地玩家端会立即响应用户输入，这样会比服务器端状态提前。当没有用户输入时，收到服务器的同步校正信息后，处理情况跟simulate模式相同。

      要注意输入的时间戳和服务器发送的输入处理结果时间戳， 它们都是该客户端的本地时间。

 

    c. 上述情况的合成时序图

         将上述2个图拼在一起进行观察。

 

     d.  我们还需要平滑地插值

            为了避免出现抖动，我们都到服务器的同步校正后，不能立即设置运动状态，需要进行平滑过渡到该状态。