为什么某些联网游戏使用插值而有些使用寻路来进行远程移动？

这是一个悬而未决的问题，但我希望看到有人为这两者做出良好的推理。

举两个例子：

插值模型

考虑一下Valve模型，其中客户端经常接收位置更新，而远程设备使用此数据上的插值来更新其位置。

寻找路径

在此模型中，认为用户发送了目的地，并且每个人都找到了目的地。

什么类型的游戏适合每种游戏，什么时候应该使用？

我已经为两个实时AAA网络游戏编写了网络代码，其中一个用于智能手机，一个用于手持式控制台。

为了直接回答“为什么”的问题，有些游戏使用一种或另一种，因为它比另一种更适合他们。这不仅取决于游戏的类型，还取决于我们所讨论的网络类型（与旨在通过3G进行游戏的游戏相比，链接的游戏机柜具有不同的条件）某些游戏实际上同时使用或完全使用同步数据的不同方法！

我想概括一下，不仅要考虑位置数据，还要考虑可以在两个网络客户端之间同步的几乎任何类型的数据。

除了两种可能性之外，我想提出一个介于硬更新和软更新之间的频谱。

• 非常困难的更新是离散事件，这些离散事件会立即更改另一个客户端的状态，而没有任何插值类型，这是因为数据具有关键性质（玩家死亡），因为它不是适用插值的数据类型（在线象棋游戏，聊天消息等），或者是因为您的网络允许您这样做（想像链接的游戏机机柜，每秒60次可靠地发送整个游戏状态完全在可能的范围内）。

  使用这种方法，网络延迟将始终显示为延迟更新，并表现为字符跳来跳去。

• 内/外推式硬更新类似于非常硬的更新，但是对于不断变化的数据，实际上每次更改时都不可能可靠地发送数据。考虑发送位置和速度矢量；您应该能够在两点之间插值数据，并在它们之后进行插值。如果传入数据与您的推断不一致，则应制定应急计划。我会说大多数需要排名更新的游戏都使用这种方法。

• 同步更新的硬性与插值/外推的硬性相似，但很少需要同步。您应该将此数据用于真正难以进行内插/外推的数据，例如格斗游戏中的时钟（两边都设置一次，之后就没有必要再次进行同步了）

• 延迟的硬更新类似于硬更新，但是您看到的是过去的数据。我怀疑在日本的许多音乐街机游戏中，您可以与他人播放歌曲，而您实际上是在与过去，可能是几小时甚至几天之前记录的播放器数据进行播放。当然，此类更新仅在您不与其他玩家真正互动时才可用。

• 软更新包括发送计划数据以及在所有主机上运行计划。这就是您所谓的“寻路”。这样同步数据所需的数据量要少得多；如果您可以避免在将数据呈现给用户的方式上出现某些差异（例如同步数百个敌人时），则可以使用这些类型的更新。

  当然，计划数据更新本身也可以像您想要的那样硬/软。

• 当可以在行动发生之前很久就可靠地计算出行动的结果时，可以使用非常软的更新。您只发送结果，而另一个客户端仅播放它。例如，某些浏览器和智能手机游戏可让您与其他人作战，但实际的战斗需要花费数小时才能解决（例如类似Travian的游戏）。这些游戏很可能在战斗开始的那一刻计算结果，而您只是看到了战斗的结果。

  另一个非网络示例是在《文明4》中启用了战斗动画。当您攻击某人时，会立即计算出战斗的结果，但是您会看到回放的动画效果。我可以向您保证，战斗不会像动画那样被计算。

如您所见，有很多同步数据的方法，而且我敢肯定，您可以想象到许多其他方法。除了最简单的在线游戏之外，所有其他在线游戏极有可能会混合使用这些方法，具体取决于它们同步的数据类型，游戏类型，甚至是网络状态（在延迟很低时使用硬更新，然后当滞后时间变高时可以更新更新）。

我对Valve的开发过程没有任何见识，所以这纯粹是我的观点，但是：

插值法：我想说，这对于快节奏的游戏（例如FPS）会更好，在这种情况下，在玩家之间按时保持敌人的位置很重要。插值意味着即使丢弃某些数据包（AFAIK，大多数多人FPS都使用UDP而不是TCP / IP，这既保证了数据包的完整性也不保证其到达的顺序），您在屏幕上的移动也会很顺畅。

寻路：如果时间不是您玩法的关键因素，并且算法在重新运行时能找到一致的路径，那么寻路可能会很有趣，因为它不需要您频繁发送更新信息，也不需要每次更新单个位置实体。我想说这似乎适合基于回合的系统，例如，您可以限制网络请求的数量（回合开始时一个，回合结束时一个，以确保所有客户端都保持“理智” ”状态。

再说一次，我从来没有从事过网络游戏或大型游戏工作室的工作，但是从我读过的书中有时我就是这样：)

熊猫睡衣的答案非常好。

基本上，问题归结为您可以发送的最少数据量将使多个客户端对彼此的状态保持相同的了解，以及在滞后期间客户端可能处于不同状态的情况下，您如何处理滞后。

如此生成程序，最容易事先知道所有交互作用，因为如果所有变量都已知，则结果已知。例如，隔离一个房间中您知道其处理方法的人，并给他一些数据集，您可以准确地预测结果。因此，您可以为其他所有客户提供结果，而无需他们等待该客户完成计算。

但是他没有提到一种方法。强制结果。

如果系统期望某个实体执行某个操作，而其他操作则依赖于该操作，并且其他计算已将该操作考虑在内，并且已经用预期的结果进行了预处理。然后，为了保持同步，将整个系统停止，同时将不在正确位置的一个实体正确地放回到其路径上。

一个现实世界的例子是所有其他实体都处于保留模式，以确保向我发送适当的补偿。