腾讯互动娱乐工程师
| 介绍
车辆的物理同步一直是多人网络游戏中难以处理的部分。 本文主要分析了车辆物理同步的具体难点，简单介绍了UE4、《火箭联盟》和《看门狗2》中车辆物理同步的情况。 采用的车辆物理同步方案。
01
车辆物理模拟
游戏中经常使用的交通工具有很多类型，例如汽车、摩托车、船和飞机。 其中，汽车是最常见的交通工具。 除非另有说明，车辆通常默认指汽车。
当然，无论是哪种车辆，其在现实世界中的运动状态都是复杂的。 如何合理简化和解耦车辆的运动状态，建立合适的物理仿真模型，让玩家感受到真实的物理效果，对于车辆的物理模拟至关重要。
以游戏中最常见的汽车为例，为了最大程度地还原真实的驾驶体验，需要模拟悬架在经过障碍物时的缓冲效果、发动机驱动汽车经过障碍物后的加速效果。踩油门，转动方向盘时控制轮胎的方向。 转向作用。
一般来说，不同物理引擎上的汽车物理模拟是相似的，可以大致抽象为以下过程：
02
车辆物理同步困难
与大多数游戏场景中需要物理同步的物体相比，车辆的运动状态更加复杂，网络同步更加困难。 主要困难体现在以下几个方面：
（1）移动速度快：游戏中车辆的主要作用是提高玩家控制的角色的移动速度。 因此，大多数情况下车辆的移动速度都非常快。 即使是轻微的网络延迟也会造成很大的损害。 误差大；
(2)大量的物理交互：玩家在驾驶车辆时，可能会频繁地与场景中的其他物体发生碰撞、摩擦或挤压等物理交互。 这些物理交互会导致车辆运动状态（速度、方向和方位）发生剧烈变化，进一步增加物理同步的难度；
(3)质量要求高：车辆的运动轨迹是平滑曲线，对物理同步质量要求较高。 频繁拉动形成的不自然轨迹会立即吸引玩家的注意力，影响玩家的游戏体验；
（4）输入预测困难：从第1节车辆的物理模拟过程中不难得知，车辆的运动状态很大程度上是由输入数据决定的。 输入数据来自于玩家的操作，其变化难以预测。 当然，它对车辆运动状态造成的变化也是难以预测的；
03
车辆物理同步解决方案
3.1 基本思想
物理同步的基本思想是预测+纠错。 车辆也是如此。 它与普通物体相比只是有以下区别：
1、车辆的运动状态由当前运动状态和输入数据确定。 仅同步车辆的运动状态无法满足预测要求；
2、玩家操作车辆时，客户端输入的数据必须立即生效，否则网络传输带来的输入延迟将极大影响玩家的操作体验；
为了满足上述限制，最简单、最直接的解决方案是主控端直接利用输入数据修改车辆的运动状态，然后将输入数据发送到服务器，然后服务器进行广播到其他仿真终端，以及服务器和仿真终端之间的输入数据分别用于修改车辆的运动状态。 最后，通过物理同步来修正仿真过程中不确定物理引擎的差异。
红色虚线圆圈代表服务器同步的运动状态，绿色虚线圆圈代表服务器同时预测的结果，黑色实线圆圈代表当前运动状态。
从上图可以看出，为了满足输入数据立即生效的要求，服务器上车辆的运动状态必须滞后于主控端的运动状态。 此时，当服务器将运动状态发送给主控端并尝试进行物理同步时，主控端不仅要根据输入数据进行物理模拟，还要根据物理同步的处理逻辑来修正运动状态。同步。
如何权衡两者之间的关系是车辆物理同步的关键点之一。 如果利用服务器发送的滞后数据来纠正主控端的运动状态，则主控端可能会出现拉动问题。 如果根据主机的物理模拟结果来修正服务器的运动状态，就会面临玩家作弊的风险。
另外，由于模拟端的数据来自于服务器，即使是模拟端的预测也只能减少与服务器的延迟。 预先预测的主控端明显比服务器快，所以模拟端和主控端之间肯定会存在延迟。 如何减少仿真端与主控端之间的延迟是车辆物理同步的另一个重点。
3.2 UE4原生解决方案
UE4利用导航预测算法来实现适合多种应用场景的物理同步解决方案。 因此，UE4对于车辆的物理同步并没有做太多的额外处理。 它仍然采用其通用的物理同步方案，根据服务器下发的运动状态强制纠正客户端的运动状态。
有关UE4物理同步的更多详细信息，请参阅文章UE4物理同步()。
同时，主控端每帧都会向服务器发送最新的输入数据，以保证主控端与服务器的运动状态不会有太大差异。
因此，当网络延迟较大，主控端的输入数据无法及时发送到服务器时，主控端会在影响下不断将车辆的运动状态修正为服务器下发的运动状态。物理同步逻辑。 此时服务器发出的运动状态是利用很久以前的输入数据进行物理模拟的结果，因此玩家此时会感觉车辆失去控制，无法及时响应其输入数据。
另外，即使网络延迟很小，玩家操作车辆时车辆也会来回摆动。 这主要有两个原因：
1、由于外推算法的缺陷，UE4的物理同步方案在处理持续转动的物体时会出现频繁的抖动；
2、主控端物理仿真结果与物理同步结果冲突；
总体来说，UE4原生的解决方案在处理车辆物理同步方面存在致命缺陷，并不是一个好的解决方案。
3.3 预测一切：《火箭联盟》的灵感
根据《火箭联盟》在GDC 2018（上）的演讲可以知道，作为一款以载具和球体物理交互为核心玩法的多人PC游戏，《火箭联盟》更具挑战性的点在于它不仅需要处理车辆的物理同步问题，还需要处理网络延迟引起的碰撞问题。
首先，作为一款PC游戏，使用权威的服务器来防止玩家作弊是必不可少的。 在此基础上，为了让玩家有零延迟的操作体验（No Input Delay），《火箭联盟》采用了客户端在接收到输入数据时立即对被操纵的载具进行物理模拟的策略，即客户提前预测。
我们先不讨论客户端模拟结果与服务端模拟结果不一致后如何纠正错误。 这种方案会带来一个非常致命的问题：在同一个客户端上，玩家操作的车辆比服务器快，而玩家操作的车辆又比服务器快。 球员要踢的球比发球员慢。
球员踢出的球比发球员慢也不难理解。 既然权威服务器是为了防止玩家作弊，那么对于影响比赛结果的球，其物理状态（位置和速度）由服务器同步到客户端，而客户端只负责渲染是非常合理的解决方案。
当未来的车辆准备踢球时，自然会出现玩家认为自己已经踢了球，但服务器却认为玩家根本没有碰球的问题。
如上图所示，球从左向右移动，车辆从上向下移动3D道具，准备踢球。
如何解决这个问题呢？ 如果直接使用滞后补偿方案，那么当低延迟玩家立即踢球时，他会发现由于其他高延迟玩家的交互，球突然从他身边飞走了。
延迟补偿具体实现：
当客户端踢球时，车辆和球的数据一起发送到服务器。 服务器收到数据包后，将球拉回到网络延迟前的位置，并确认客户端是否踢出了球。 如果验证通过，服务器将接受客户端的结果，认为客户端已经踢出了球，并纠正球的物理状态。
让高延迟玩家影响低延迟玩家的游戏体验，显然是不可接受的。 为了兼顾所有玩家的游戏体验，《火箭联盟》最终采用了类似于《守望先锋》的关键帧同步方案：
1、客户端接收到输入数据时直接开始物理模拟，然后记录当前物理帧号以及所有物体的物理状态作为当前关键帧游戏开发物理学，并将关键帧数据存储到关键帧缓存队列中；
2、客户端将输入数据和对应的物理帧号发送给服务器；
3、服务器收到客户端同步的数据后开始物理模拟，然后将当前物理帧号以及所有物体的物理状态同步给客户端；
4、客户端收到服务器同步的数据后，从关键帧缓存队列中找到对应的关键帧数据并进行比较。 对于间隙较大的对象，其物理状态直接回溯到服务器同步的状态；
5、回溯完成后，从关键帧缓存队列中检索后续的输入操作，然后一次性进行多次物理模拟，直到消耗完所有输入数据，以确保客户端在正确的状态下重新预测；
如上图所示，客户端收到输入数据后直接让车辆移动。 此时，由于缺少服务器同步的数据，客户端的球处于静止状态。 直到后来服务器同步数据才发现，从第一帧开始，小球的状态就与服务器不同步，而车辆却因为输入数据没有变化而保持与服务器同步。
此时客户端首先回到第一帧，然后将球的状态修正为服务器同步的状态。 由于客户端最新的物理帧为4，所以物理模拟会一次执行3次，以正确的状态预测车辆和球，以保证客户端上的车辆和球比服务器上的速度更快。 这样，当客户端上的车辆踢球时，它会使用未来的车辆来踢球。 只要客户端的网络稳定游戏图片，客户端的预测结果就会与服务器的结果类似，并且客户端不会出现任何延迟。
由于客户端会预测所有物体（玩家操作的车辆、其他玩家操作的车辆、球）的物理状态，以确保它们的物理状态在同一时间线上，因此这种预测策略称为客户端全预测。 （客户预测一切）。
梳理《火箭联盟》的物理同步方案不难知道，当预测失败时，需要在一帧内完成回溯和多次物理模拟操作，消耗了大量的CPU开销。 为了尽可能避免客户端预测失败的问题，《火箭联盟》将服务端和客户端的物理帧率均设置为120帧，以减少每次物理模拟的差异，但过高的物理帧率无疑会影响游戏体验。进一步增加CPU开销。 因此，《火箭联盟》的物理同步方案更适合PC或主机游戏，但不适合手机游戏。 另外，当游戏中物体过多时，CPU开销以及每个关键帧需要保存的数据也会迅速增加，因此不适合场景太大、物体较多的游戏。
当然，尽管火箭联盟的物理同步方案在应用中存在诸多限制，但其回溯+修正+重预测的方案确实可以有效解决服务器同步数据与客户端预测数据冲突时的拉取问题。
3.4 痛苦之路：全面补丁的《看门狗2》
在 GDC 2017 上，育碧开发者详细分享了《看门狗 2》中车辆物理同步的策略。
《看门狗2》的网络模型是基于P2P状态同步的。 主控终端接收输入数据时直接进行物理模拟，然后将车辆的物理状态同步到模拟终端，并在模拟终端上使用导航预测。 算法进行预测以减少车辆延迟。 由于仿真端不使用车辆的输入数据进行物理仿真，因此车辆转弯时会因频繁预测失败而出现抖动。
最好的解决方案是使用输入数据来驱动车辆的物理模拟系统，然后根据轮胎方向和速度等物理属性来预测车辆的转向变化。 然而《看门狗2》的开发团队觉得这很复杂，所以他们采用了更简单的解决方案，直接利用车辆的角速度进行外推来预测车辆的转向。 结果确实平滑了很多，但仍然可见。 有轻微抖动。
正是因为预测机制的缺陷，导致车辆的轨迹会被频繁修正，所以《看门狗2》又做了一个补丁：利用主控端同步快照（Snapshot，即车辆的物理特性）车辆）到模拟终端。 state）对仿真端的车辆进行插值，以获得更准确的运动轨迹。
但插值值会增加仿真端车辆的延迟，而外插值则可以减小延迟带来的运动状态差异。 因此，《看门狗2》采用了混合插值和外插的策略，尽量减少模拟端和主控端车辆的差异。 事实上，这个策略非常简单。 可以概括为一个原则：如果有最新的快照，首先使用插值来获得更准确的轨迹。 如果不是，则使用外推值来最小化与主控端的差异。 下图展示了该策略的工作原理：
如上图所示，当仿真端接收到第一个SnapShot（红点）时，由于没有下一个SanpShot进行插值，此时进行的是外推，所以仿真端的运动轨迹与实际端不一致主控终端。 当接收到第二个快照时，插值开始。 这时，模拟端就能以更准确的运动轨迹追上主控端。 最终，模拟端与客户端之间的延迟为3帧，而如果单纯使用插值，则延迟为5帧。
在《浅谈网络同步在游戏史上的发展与变迁（下）》一文中，对这个过程的解读显然是错误的。
另外游戏开发物理学，当网络比较好的时候，模拟终端有可能在赶上最新的SnapShot之前就收到了新的SanpShot。 这时，如何确定外插值和内插值的比例是一个大问题。 如果外推值比例太大，车辆运动轨迹的精度就会变差。 如果插值的比例太大，车辆延迟会增加。
因此，《看门狗2》引入了TimeOffset的概念，利用TimeOffset来确定内插值和外推值的比例。 TimeOffset的大小是平均网络延迟加上由车速确定的修正值，最大限制为300ms。
TimeOffset 必须大于网络延迟才合理。 如下图所示，如果外推值的预测完全正确，那么T时刻模拟车辆的物理状态一定与宿主车辆的物理状态一致（SnapShot 3同步的数据）。 此时外推该值会增大模拟端与主控端的差异。
考虑到网络的波动性和预测的不准确性，需要根据网络延迟添加一个修正值，但这个修正值是一个经验值。
当然，混合外插值和内插值的解决方案只能减少延迟，而不能完全消除延迟。 当一个玩家操作的车辆与另一个玩家操作的车辆相撞时，仍然会出现玩家当前的车辆与其他玩家过去的车辆相撞的问题，这就是《火箭联盟》面临的问题。 更糟糕的是，当车辆相互碰撞时，这个解决方案会产生错误。
如下图所示，我们假设下面两辆车相撞。 此时，模拟终端上的白色汽车与蓝色汽车发生碰撞后，由于尚未收到主控终端发送的SnapShot，因此会采用外推法继续向前行驶。 白色汽车因碰撞在主控终端上向后移动，然后将向后移动的Snap Shot发送到模拟终端。 当模拟端的白色汽车收到快照时，由于外推值的影响，它会向后移动更长的距离。
由于《看门狗 2》没有权威服务器，因此没有权威的冲突结果让客户端有机会纠正网络延迟的差异。 因此，为了赋予车辆更自然的碰撞表现，《看门狗2》添加了物理模拟混合补丁：在碰撞过程中，模拟侧的车辆完全由物理模拟控制，然后继续下降。 物理模拟的权重增加了网络同步的权重，让车辆在碰撞时表现得更加自然。 最终，虽然使用物理模拟融合之后的碰撞效果不是很自然，但至少比使用物理模拟融合之前的碰撞效果要好很多。
总体来说，《看门狗2》最终的车辆物理同步效果并不好。 虽然主要是受到P2P网络模型的限制，但这也在一定程度上说明了车辆的物理同步确实是困难的，否则不需要应用那么多补丁才能得到勉强可见的效果。 里面提到的大部分优化策略参考价值不大。 它们都是为了弥补P2P的缺点而制作的补丁。 唯一值得参考的一点是，通过插值和外推的混合，确保仿真端车辆能够达到预期的性能。 轨迹移动更精准，同时减少与主机的延迟。
04
总结
物理同步一直是多人网游中比较难处理的部分，而处理物理模拟逻辑复杂的车辆更是难上加难。 目前，车辆物理同步还没有通用的解决方案。 具体的同步策略基本上需要根据项目的具体需求和约束条件来确定。 就像《火箭联盟》的方案一样，可以获得很棒的同步效果，但其回溯和高物理帧率带来的巨大CPU开销使其在手游中很难实现。
>>>参考文章
1. 车辆动力学及其在Unity和UE4中的实现
2.一篇详细解释UE4物理同步的文章
3. 浅谈物理引擎的网络同步解决方案
4.GDC 2018，火箭科学！ 火箭联盟的物理细节详解
5.快节奏多人游戏（第四部分）：延迟补偿
6. Copy Chaos – 《看门狗 2》中的车辆同步（翻译）
7、手游中车辆物理同步的实现方案
8.外推物理插值模式
9.详细探讨网络同步在游戏史上的发展变化（下）
