概述
目前有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. 我们还需要平滑地插值
为了避免出现抖动,我们都到服务器的同步校正后,不能立即设置运动状态,需要进行平滑过渡到该状态。