游戏程序当前的状态随时间和玩家的输入会进行变化。也就是说游戏是有状态的程序。多人游戏也不例外，但由于多人玩家之间存在交互，复杂性会更高。

例如贪吃蛇游戏，我们假设它的操作会发送到服务器，那它的核心游戏逻辑应该是：

服务端接收该消息做出对应的动作，这个过程会以固定的间隔运行。每一次循环都被称为 frame 或 tick。

客户端将解析服务端发送的消息，也就是每一帧的动作，渲染到游戏华中中。

为了确保所有客户端都同步帧，最简单的方法是让客户端以固定的间隔向服务器发送更新。发送的消息包含用户的输入，当然也可以发送 no user input。

服务器收集“所有用户”的输入后，就可以生成下一次 frame 帧。

上图演示了客户端与服务端的交互过程。T0 ~ T1 时间段，客户端保持等待，或者说空闲状态，直到服务器响应 frame，等待时间的大小取决于网络质量，约 50 毫秒到 500 毫秒，人眼能够注意到任何超过 100 毫秒的延迟，因此这个等待时间对于某些游戏来说是不可接受的。

锁步状态更新，还有一个问题。游戏的延迟来自最慢的用户 。

上图有两个客户端。客户端 B 的网络比较差，A 和 B 都在 T0 时间点向服务器发送了用户输入，A 的请求在 T1 到达服务端，B 的请求在 T2 到达服务端，前面我们提到，服务器需要收集“所有用户”的请求后才开始工作，因此需要到 T2 时间点才开始生成 frame。

因为 Client B 比较慢，我们“惩罚”了所有的玩家。

假如我们不等待所有客户端的用户输入，低延迟玩家又会获得优势，因为它的输入到达服务器的时间更短，会更快处理。例如，两个玩家 A、B 同时互相射击预期是同时死亡，但是 A 玩家延迟比 B 玩家更低，因此在处理 B 玩家的用户输入时，A 玩家已经干掉 B 玩家了。

小结一下，锁步状态更新存在的问题，如下。

回合制类型的游戏大多数使用这种方法，因为玩家确实需要等待，例如《炉石传说》。

对于慢节奏的游戏，少量延迟也是可以接受的，例如《QQ农场》。

但是对于快节奏的游戏，锁步状态更新的这些问题都是致命的，不可能操纵游戏人物进入某一个建筑，500 毫秒后，我才能进入。我们一起来看看下一种方法。

客户端预测，在玩家的计算机上，运行游戏逻辑，来模拟游戏的行为，而不是等待服务器更新。

例如我们生成 Tn 时间点的游戏状态，我们需要 Tn-1 时间点的所有玩家状态和 Tn-1 时间点所有玩家的输入。

假设，我们现在的固定频率为 1 s，每 1s 需要给服务器发送一个请求，获取玩家状态并更新玩家的状态。

在 T0 时间点，客户端将用户的输入发送到服务器，用于获取 T1 时间点的游戏状态。在 T1 时间点，客户端已经可以渲染画面了，实际上客户端的响应是在 T3 时刻，也就是说客户端没有等待来自服务器的响应。

使用这个方法，需要满足一些前置条件：

满足这两点，客户端预测的结果也不一定总是对的。就比如刚提到的，使用相同的公式以及相同的随机种子，进行伪随机算法，但不同平台的浮点计算，可能会存在微小的差异。再设想一个场景，如下图。

客户端 A 尝试使用 T0 时间点的信息模拟 T1 时间点上的游戏状态，但客户端 B 也在 T0 时间点提交了用户输入，客户端 A 并不知道这个用户输入。

这意味着客户端 A 对 T1 时间的预测将是错误的是，但！由于客户端 A 仍然从服务器接收 T1 时间点的状态，因此客户端有机会在 T3 时间点修正错误。

客户端需要知道，自己的预测是否正确，以及如何修正错误。

修正错误通常叫做 Reconcilation 和解。

需要根据上下文来实现和解部分，下面我们通过一个简单的例子来理解这个概念。这个例子只是抛弃我们的预测，并将其游戏状态替换为服务器响应的正确状态。

这种和解的方式有一个明显的缺点，如果服务器响应的游戏状态和客户端预测差异太大，则游戏画面可能会出现错误。例如我们预测敌人在 T0 时间点向南移动，但在 T3 时间点，我们意识到它在向北移动，然后通过使用服务器的响应进行和解，敌人将从北“飞到”正确的位置。

有一些方法可以解决此问题，这里不展开讨论，感兴趣可以搜一下实体插值 Entity Interpolation。

小结一下，客户端预测技术，让客户端以自己的更新频率运行，与服务器的更新频率无关，所以服务器如果出现阻塞，不会影响客户端的帧。

但它也带来复杂性，如下。

还给我们带来了敌人从南飞到北的问题。

目前为止，我们都在讨论客户端，接下来看看服务端如何解决帧同步。

利用服务端解决帧同步问题，首先需要解决的是网络延迟带来的问题。如下图。

用户 A 在 T 处进行了操作（比如按下了一个技能键），该操作应该在 T+20ms 处理，但由于延迟，服务器在 T+120ms 才接收到输入。

在游戏中，用户做出指定操作后，应该立即有反应。立即有反应，这个立即是多久，取决于游戏的类型，比如之前我们提到的回合制，它的立即可能是几十秒。我们可以通过 T + X，表示立即反应的时间，T 代表用户的输入时刻，X 代表的是延迟。X 可以为 0，这代表真正的立即 :-)

解决这个问题的思路，与之前客户端预测中使用的办法类似，就是通过客户端的用户输入，来和解服务器中的玩家游戏状态。

所有的用户输入，都需要时间戳进行标记，该时间戳用于告诉服务器，什么时刻处理此用户输入。

为什么在同一水平线上，Client A 的时间是 Time X，而 Server 的时间是 Time Y？

因为客户端和服务端独立运行，通常时间会有所不同，在多人游戏中，我们可以特殊处理其中的差异。在特殊处理时，我们应该使客户端的时间大于服务端的时间，因为这样可以存在更大的灵活性

上图演示了一个客户端与服务端之间的交互。

服务端和解部分（上图红色底色部分），主要维护 3 个部分，如下。

服务端和解过程，如下。

我并没有做过这些工作，分享的知识都是我对它感兴趣，在网上看了许多经验后整理的。