为什么FPS对射的时候要来回跑--valve的多人对战同步技术

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

较早的文章了，介绍了source引擎在多人对战网络同步（尤其是用于fps游戏）中的做法，在行业内影响了很多多人对战游戏的开发。

在了解了其中的技术和概念之后，对于玩家来说，就会知道为什么fps游戏对射的时候不要静止，要来回跑，除了让对方难以瞄准外，物理技术上也是如此哦

基本概念

这个图可以说很好地表达了，客户端和服务器之间的关系。

1. 服务器一般以一定帧数（比如30帧，也可以更高）的速度tick，然后以一定频率（一般低于tick的频率）来发snapshot给客户端
2. 1. 服务器常常也buffer一些指令
3. 客户端以一定频率发送input的指令（和tick帧数保持一致），然后本地buffer一定时间（比如100ms的服务器传过来的snapshot）

这两点放在一起，就可以建立起一个逻辑基本正确的客户端服务器多人对战系统了。

延时和体验

但是逻辑基本正确的系统是远远不够的，对人对战的体验和单机打怪（我们认为这个是好的标准）之间的差异就来自延时。

这里的延时包括：对于移动以及射击会有所不同，按照程序执行的顺序

1. 按下鼠标到网络packet发出--客户端帧数越高越好
2. 网络延时（ping）--延时最大头
3. 服务器上面buffering的时间--可以根据重要性进行取舍
4. 服务器上面执行时间（帧数越高越低）
5. 服务器执行结果下行，又是一个网络延时（ping）--延时最大头
6. 客户端buffering时间
7. 客户端显示时间（敌人倒地飙血等等）

input prediction(预演)

所以，按照初始的客户端服务器逻辑，一枪开出去或者一个移动操作做出来，要经过这么久才能有所反应，70ms延时，要150ms左右才能走完循环，这个体验延迟感很强，就是有问题。

所以引入一个input prediction的概念：就是不等服务器返回确认，就立刻做出表现，移动，开枪射击的弹道火花等等，然后在服务器回包的时候做一个正确性验证，不对的话就纠正。

entity interpolation(平滑插值)

然后平滑可以作为一个原则，加入到整个同步过程的方方面：

1. entity移动，服务器发过来的是一个新的位置，那么就通过一些插值（可以是线性，可以是曲线（走一个寻路））
2. 本地纠正，如果服务器验证和本地预演不匹配，那么一个瞬移就太糙了，可以走一个平滑的插值过去

延时和逻辑正确

延时带来的更严重的一个问题是逻辑正确性，由于时差的问题，我们本地客户端看到的东西，和服务器上面的不完全一致，然后客户端的命令走到服务器上进一步有一个延时。

如图中，我们在客户端上看到的是蓝色线条的敌人，但是一枪开出去的逻辑到了服务器上，敌人已经向左走了一段距离，这就会造成该打到的没打到。

lag compensation(延迟补偿)

处理这个方法就是，开枪这种指令到服务器上都是有时间戳的，然后服务器会把敌人会退到开枪的这个瞬间，然后做计算命中，这样逻辑就正确了。

但是这个也不是绝对准确的，只能说是一个相对准确，因为这个回退位置不可能和你本地的时间完全一致，只能说是一个近似一致的。

但是如果敌人是静止的，那就完全一致了，所以一个静止的敌人总是更容易被打中，即便技术上也是如此。

优化

这里谈的是fps游戏，实际上这个系统可以用于大量的游戏系统，比如mmo，然后体验的优化就可以包括：

1. 预演做的更好：比如加上搓招，前摇等过程，尽可能把能预演的都做好，把“拙”藏好
2. 降低延时：
3. 1. 网络路线选择的更好
   2. 让服务器和客户端tick的速度更高
   3. 可以的话减少buffering
   4. 可以的话减少移动插值的delay

死穴与逻辑冲突

在理解了工作原理之后，我们就知道有一些事情是不可避免的，比如：

1. 你看见敌人的瞬间就躲到掩体里，但是敌人还是爆了你的头--这是有可能的，你的即时反应还没有同步到服务器上，而服务器上计算命中是一个延迟补偿的，所以本地虽然没看到，但是还是被击中了
2. 移动的shooter比静止的shooter有优势，这里是两个原因
3. 1. 上面延迟补偿部分提到了，移动的人对于另外一台的机器上的人来说，和服务器上不会在像素级完全一致
   2. 另外就是有移动插值的存在，我们看动的物体总是有一定的延时，

所以fps游戏的时候，两边对射，千万别静止站着，要左右跑，物理技术上就会比站着有优势哦