在帧同步模型中，每个客户端都会对整个游戏世界进行模拟。这种方法的好处在于减少了需要发送的信息。帧同步只需要发送用户的输入信息，而对于反过来的中心服务器模型来说，单位的信息则发送越频繁越好。
比如说你在游戏世界中移动角色。在中心服务器模型中，物理模拟只会在服务器执行。客户端告诉服务器，角色要往哪个方向移动。服务器会执行寻路而且开始移动角色。服务器紧接着就会尽可能频繁地告知每个客户端该角色的位置。对于游戏世界中的每个角色都要运行这样的过程。对于实时策略游戏来说，同步成千上万的单位在中心服务器模型中几乎是不可能的任务。
在帧同步模型中，在用户决定移动角色之后，就会告诉所有客户端。每个客户端都会执行寻路以及更新角色位置。只有用户输入的时候才需要通知每个客户端，然后每个客户端都会自己更新物理以及位置。
这个模型带来了一些问题。每个客户端的模拟都必须执行得一模一样。这意味着，物理模拟必须执行同样的更新次数而且每个动作都需要同样的顺序执行。如果不这么做，其中一个客户端就会跑在其他客户端之前或者之后，然后在新的命令发出之后，跑得太快或者太慢的客户端走出的路径就会不同。这些不同会根据不同的游戏玩法而不同。
另一个问题就是跨不同的机器和平台的确定性问题。计算上很小的不同都会对游戏造成蝴蝶效应。这个问题会在后续的文章中讲到。
这里的实现方案灵感来自于这篇文章：《1500个弓箭手》。每个玩家命令都会在后续的两个回合中执行。在发送动作与处理动作之间存在延迟有助于对抗网络延迟。这个实现还给我们留下了根据延迟以及机器性能动态调整每回合时长的空间。这部分在这里先不讨论，会在后续文章再说。
对于这个实现，我们有如下定义：
帧同步回合可以由多个游戏回合组成。玩家在一个帧同步回合执行一个动作。帧同步回合长度会根据性能调整。目前硬编码为200ms。
游戏回合
游戏回合就是游戏逻辑和物理模拟的更新。每个帧同步回合拥有的游戏回合次数是由性能控制的。目前硬编码为50ms，也就是每次帧同步回合有4次游戏回合。也就是每秒有20次游戏回合。
动作
一个动作就是玩家发起的一个命令。比如说在某个区域内选中单位，或者移动选中单位到目的地。
注意：我们将不使用Unity3d的物理引擎。而是使用一个确定性的自定义引擎。在后续文章中会有实现。
游戏主循环
Unity3d的循环是运行在单线程下的。可以通过在这两个函数插入自定义代码：
- Update()
- FixedUpdate()
FixedUpdate()会根据设置每秒执行固定次数。在主循环遍历中，它会被调用零次或多次，取决于上次遍历所花费的时间。FixedUpdate()有着我们想要的行为，就是每次帧同步回合都执行固定时长。但是，FixedUpdate()的频率只能在运行之前设置好。而我们希望可以根据性能调节我们的游戏帧率。
游戏帧回合
这个实现有着与FixedUpdate()在Update()函数中执行所类似的逻辑。主要不同的地方在于，我们可以调整频率。这是通过增加”累计时间”来完成的。每次调用Update()函数，上次遍历所花费的时间会添加到其中。这就是Time.deltaTime。如果累计时间大于我们的固定游戏回合帧率(50ms)，那么我们就会调用gameframe()。我们每次调用gameframe()都会在累计时间上减去50ms，所以我们一直调用，知道累计时间小于50ms。
帧同步回合
为了与其他客户端保持同步，每次帧同步回合我们都要问以下问题：
- 我们已经收到了所有客户端的下一轮动作了吗？
- 每个客户端都确认得到我们的动作了吗？
动作，也就是命令，都通过实现IAction接口来通信。有着一个无参数函数叫做ProcessAction()。这个类必须为Serializable。这意味着这个对象的所有字段也是Serializable的。当用户与UI交互，动作的实例就会创建，然后发送到我们的帧同步管理器的队列中。队列通常在游戏太慢而用户在一个帧同步回合中发送多于一个命令的时候用到。虽然每次只能发送一个命令，但没有一个会忽略。
当发送动作到其他玩家的时候，动作实例会序列化为字节数组，然后被其他玩家反序列化。一个默认的”非动作”对象会在用户没有执行任何操作的时候发送。而其他则会根据特定游戏逻辑而定。这里是一个创建新单位的动作：
实例代码可以在下面找到：
Bitbucket – Sample Lockstep
