多人游戏中的帧同步策略
介绍解决该问题的基本概念和常见解决方案。
Lockstep state update 锁步状态更新Client prediction 客户端预测server reconcilation 服务端和解多人游戏的运作方式
游戏程序当前的状态随时间和玩家的输入会进行变化。也就是说游戏是有状态的程序。多人游戏也不例外，但由于多人玩家之间存在交互，复杂性会更高。
例如贪吃蛇游戏，我们假设它的操作会发送到服务器，那它的核心游戏逻辑应该是：
客户端读取用户输入改变蛇的方向，也可以没有输入，然后发送给服务端服务端接收消息，根据消息改变蛇的方向，将蛇的“头”移动一个单位空间服务端检查蛇是否撞到了墙壁或者自己，如果撞到了游戏结束，给客户端发送响应消息，更新客户端的画面。如果没有撞到，则继续接收客户端发送的消息，同时也要响应给客户端消息，告诉客户端，蛇目前的状态。服务端接收该消息做出对应的动作，这个过程会以固定的间隔运行。每一次循环都被称为 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 玩家了。
小结一下，锁步状态更新存在的问题，如下。
游戏画面是否卡顿，取决于最慢的玩家客户端需要等待来自服务器的响应，否则不会渲染画面连接非常活跃，客户端需要定期发送一些无用的心跳包，以便服务器可以确定它拥有生成 frame 所需的所有信息回合制类型的游戏大多数使用这种方法，因为玩家确实需要等待，例如《炉石传说》。
对于慢节奏的游戏，少量延迟也是可以接受的，例如《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 和解。
需要根据上下文来实现和解部分，下面我们通过一个简单的例子来理解这个概念。这个例子只是抛弃我们的预测，并将其游戏状态替换为服务器响应的正确状态。
客户端需要维护 2 个缓冲区，一个用于预测 PredictionBuffer，一个用于用户输入 InputBuffer 。它们是预测这个行为需要的上下文，请记住，预测 Tn 时刻，需要 Tn-1 的状态和 Tn-1 时刻的用户输入。它们一开始都为空
这种和解的方式有一个明显的缺点，如果服务器响应的游戏状态和客户端预测差异太大，则游戏画面可能会出现错误。例如我们预测敌人在 T0 时间点向南移动，但在 T3 时间点，我们意识到它在向北移动，然后通过使用服务器的响应进行和解，敌人将从北“飞到”正确的位置。
有一些方法可以解决此问题，这里不展开讨论，感兴趣可以搜一下实体插值 Entity Interpolation。
小结一下，客户端预测技术，让客户端以自己的更新频率运行，与服务器的更新频率无关，所以服务器如果出现阻塞，不会影响客户端的帧。
但它也带来复杂性，如下。
需要在客户端处理更多的状态和逻辑，比如我们前面提到的缓冲区和预测逻辑需要和解来自服务器的状态（正确的游戏状态）与预测之前的冲突还给我们带来了敌人从南飞到北的问题。
目前为止，我们都在讨论客户端，接下来看看服务端如何解决帧同步。
服务端和解
利用服务端解决帧同步问题，首先需要解决的是网络延迟带来的问题。如下图。
用户 A 在 T 处进行了操作（比如按下了一个技能键），该操作应该在 T+20ms 处理，但由于延迟，服务器在 T+120ms 才接收到输入。
在游戏中，用户做出指定操作后，应该立即有反应。立即有反应，这个立即是多久，取决于游戏的类型，比如之前我们提到的回合制，它的立即可能是几十秒。我们可以通过 T + X，表示立即反应的时间，T 代表用户的输入时刻，X 代表的是延迟。X 可以为 0，这代表真正的立即 :-)
解决这个问题的思路，与之前客户端预测中使用的办法类似，就是通过客户端的用户输入，来和解服务器中的玩家游戏状态。
所有的用户输入，都需要时间戳进行标记，该时间戳用于告诉服务器，什么时刻处理此用户输入。
为什么在同一水平线上，Client A 的时间是 Time X，而 Server 的时间是 Time Y？
因为客户端和服务端独立运行，通常时间会有所不同，在多人游戏中，我们可以特殊处理其中的差异。在特殊处理时，我们应该使客户端的时间大于服务端的时间，因为这样可以存在更大的灵活性
上图演示了一个客户端与服务端之间的交互。
客户端发送带有时间戳的输入。客户端告诉服务器在 X 时间点应该发生用户输入的效果服务端在 Y 时间点收到请求在 Y+1 时间点，即红色框的地方，服务端开始和解，服务端将 X 时间点的用户输入应用于最新的游戏状态，以保证 X 的 Input 发生在 X 时间点服务端发送响应，该响应中包含时间戳服务端和解部分（上图红色底色部分），主要维护 3 个部分，如下。
GameStateHistory，在一定时间范围内玩家在游戏中的状态ProcessedUserInput，在一定时间范围内处理的用户输入的历史记录UnprocessedUserInput，已收到但未处理的用户输入，也是在一定的时间内服务端和解过程，如下。
当服务端收到来自用户的输入时，首先将其放入 UnprocessedUserInput 中等待服务端开始同步帧，检查 UnprocessedUserInput 中是否存在任何早于当前帧的用户输入如果没有，只需要将最新的 GameState 更新为当前用户的输入，并执行游戏逻辑，然后广播到客户端如果有，则表示之前生成的某些游戏状态由于缺少部分用户输入而出错，需要和解，也就是更正。首先需要找到最早的，未处理的用户输入，假设它在时间 N 上，我们需要从 GameStateHistory 中获取时间 N 对应的 GameState 以及从 ProcessedUserInput 获取时间 N 上用户的输入使用这 3 条数据，就可以创建一个准确的游戏状态，然后将未处理的输入 N 移动到 ProcessingUserInput，用于之后的和解更新 GameStateHistory 中的游戏状态重复步骤 4 ~ 6，直到从 N 的时间点到最新的游戏状态服务端将最新帧广播给所有玩家我并没有做过这些工作，分享的知识都是我对它感兴趣，在网上看了许多经验后整理的。
