游戏帧同步的流程与实现

大纲

现代多人游戏中，多个客户端之间的通讯大多以同步多方状态为主要目标，为了实现这一目标，主要有两个技术方向：

状态同步

状态同步简单来说就是同步游戏中的各种状态，当客户端发送游戏动作到服务器，服务器接收到之后，通过计算游戏行为的结果，然后广播下发给客户端游戏中的各种状态数据。客户端接收到状态数据后显示内容。这种做法类似于各个客户端都在远程操作服务器上的软件。例如最高的mud，以及日后大量的国产网游，特别是回合制游戏，大多采用这种方式。

状态同步的流程：

为了给游戏玩家更好的体验，减少同步的数据量，客户端也会做很多的本地运算，减少服务器同步的频率以及数据量。

状态同步其实是一种不严谨的同步，它的思想中不同玩家屏幕上的一致性的表现并不是重要指标，只要每次操作的结果相同即可。所以状态同步对网络延迟的要求并不高。例如：RPG游戏中200~300ms的延迟对用户来说是可以接受的，但在RTS（即时战略）游戏中50ms的延迟却会很受伤。

帧同步

帧同步是RTS游戏经常采用的一种同步技术，状态同步中数据量会随着需要同步的单位数量增长，而对于RTS来讲动不动就是几百个单位可以被操作，如果这些都需要同步的话，数据量是不能被接受的，所以帧同步不同步状态，之同步操作。例如游戏中同步玩家的操作指令，操作指令包含当前的帧索引。

简单来说，客户端发送游戏动作到服务器，服务器接收并汇总，然后直接转发给所有客户端，或者客户端直接通过P2P技术发送。客户端根据收到的游戏动作来做运算和显示。这种做法等于客户端之间相互远程控制其他客户端上的游戏软件。早期的ipx网络游戏，例如红色警戒、帝国时代、星际争霸，以及大量支持网络连线双打游戏机模拟机，都是采用这种方式。

那些游戏需要使用帧同步呢？

帧同步的流程

帧同步主要依赖客户端的能力，服务器仅仅是做一个转发，甚至客户端可以无需服务器，通过P2P方式来转发数据。由于只是转发游戏的行为，所以广播的数据量比状态同步要小很多。非常适合游戏行为非常频繁的动作游戏，诸如飞行射击、FPS、RTS（即时战略）。

状态同步由于要把整个游戏的状态都广播下去，如果游戏中的对象特别多，比如满屏的子弹、怪物，那么要广播的数据量就会很大，这个时候帧同步的优势就比较明显，因为不管有多少”机器控制的角色“，仅仅需要广播玩家角色有关的操作即可。反过来，如果游戏中有大量玩家同时聚集，那么帧同步和状态同步的差异就不太明显。反而状态同步能得到更多安全性，因为游戏运算在服务器上，比较容易防止外挂。

简单来说，帧同步技术最要的概念是”相同的输入 + 相同的时机 = 相同的显示“。也就是说，游戏接收来自网络的多个客户端的操作，如果这些操作在各个客户端上都是一样的，那么多个客户端的显示也就是一样的，进而带来了”同步“的效果。在这种情况下，各个客户端的运算要绝对一致，不能依赖诸如本地时间、本地随机等”输入“，而要一切以网络来的数据为主。

因为帧同步的特性，因此很容易做出战斗回放，即服务器记录所有操作，客户端请求到操作文件再执行一次。帧同步的特性导致客户端的逻辑实现和表现实现必须完全分离。

帧同步的目的在于消除网络波动性带给玩家的卡顿以及忽快忽慢的不良体验。

状态同步和帧同步的比较和选择

对于单位比较多的即时策略游戏，帧同步是很好的选择。相反的，如果玩家比较多，状态同步则更加合适，因为安全性更高。一般大型MMOARPG都采用状态同步，由于状态同步采用C/S架构，所有状态由服务器来控制，安全性比较高，但流量比较大。帧同步采用的是囚徒模式，所有C端强制采用一个逻辑帧率，从而保证输出一致，其特点是流量小，安全性较差。

囚徒模式又叫锁步模式，就是把所有参与对战的客户端看成排成一列的囚犯，这些囚犯们的左脚都被锁链给连起来，如果要往前走，就只能同时迈步，如果其中某个人走快了或走慢了，都回让整队人停下来。

帧同步是一种对同步源进行像素级同步显示的处理技术，对于网络上的多个接入者，一个信号将会通过主机同步发送给其他人，并同步显示在各个终端上。同步信号可以是每帧的像素数据，也可以是影响数据变化的关键事件信息。

帧同步在网络游戏应用中的设计有别于传统的MMORPG游戏，因为可以承载大量的后台计算，实现类单机的效果，所以可以在射击类、飞行类游戏中实现弹幕计算或格斗类的高精度打击效果。

什么叫做帧同步呢？服务器收集客户端手机发送过来的操作，然后在特定的时间（收集完成之后），再广播发送给每个客户端。客户端根据接收到的输入，进行同样的逻辑处理，最终得到同样的结果的过程。在实现上，一般都是以服务器按固定的帧率，来搜集每个客户端的输入，然后把这些输入广播给所有客户端。由于每个操作指令到达所有客户端的时间（帧）都是一样的，所以每个客户端运算的结果也是一样的，也就是同样的输入就会得到同样的结果。

这就好像是玩家通过网络将操作手柄连接到你的手机，这种同步方案是传统单机局域网游戏中最常见的。

帧同步模型最大的优点在于强一致性，每个客户端的表现是完全一样的，非常适合高度要求操作技巧的游戏。由于广播的仅仅是玩家的操作，所以数据量很少。不管游戏中的角色数量、状态数量有多大多复杂，都不会影响广播的数据量。

帧同步模型最大的缺点是对所有玩家的延迟都有要求，一般来说要求在50毫秒以内，如果有一个客户端网络卡住了，所有客户端都要停下来等待。

另外在帧同步模式中，数据同步的频率较高，网络延迟越小越好。由于TCP的滑动窗口机制和重传机制，导致延时机制，导致延时无法控制。因此帧同步一般采用UDP进行网络传输，但UDP又会衍生出可靠性问题，对于客户端，如果某些UDP包没有收到，就会出现丢帧的情况。

客户端A的操作A1与客户端B的操作B1，共同封装成OperateCmd数据发送给PVP服务器，PVP服务器每66毫秒产生一个逻辑祯，在该桢所在时间段内，收到A1和B1后，生成一个Frame数据块，在该帧时间结束时，将Frame发送给客户端A和B。Frame数据块内有该帧的帧号，客户端A和B接收到Frame数据后，便知道该帧内，客户端A和客户端B都做了什么操作。然后根据接收到的消息A1和B1进行游戏表现，最终呈现给玩家A和B的结果是一致性的，从而实现客户端A和B的数据同步。

帧同步既然是在特定时间发送，也就是说每隔一段时间收集用户操作指令，那么要间隔多久内。例如每隔一段时间搜索用户的操作。此时，如果时间太快则网络速率达不到要求，如果时间太长则用户操作不流程。哪里多少才比较合适呢？根据统计玩家至少要在50ms 100ms可以完成一次，一般维持到15 20次左右会比较安全。

当我们在做一些跟网络游戏相关的机器学习任务的时候，有时需要对整个游戏系统的运行机制有所了解才能更好的应对，对于网游而言，首当其冲的机制便是同步了。当然，大部分的机器学习从业者是不会懂游戏开发的，更不会不懂同步机制，此文我将基于我个人的一些研究和理解对网游中的同步机制做一个简单的介绍，以便大家更加顺利的开展游戏相关的机器学习任务。

与单机游戏不同，网络游戏有很多人通过远程的方式参与游戏，不管是服务器还是玩家，用的都是自己独立的设备，也就是说所有的客户端和服务器都是各自独立的游戏世界，要让游戏玩下去就得保证所有的游戏世界都是一致的，于是便有了 同步 。

在理想的情况下，所有人操作的游戏世界，在同一时刻应该是完全步调一致的，但由于网络延迟以及其他不同设备环境的差异，完全一致时不可能的，而 同步 的目的是希望尽可能的一致，而对一致性的要求，不同的游戏类型也会有不同的要求。

通常帧同步和状态同步是这样区分的：

当然这两种方式并非是非此即彼的，在一些复杂的网络游戏中，混用两种方式也是比较常见的。

尽管为了游戏体验，游戏客户端可能会做很多体验上的改进操作，跟我下面讲的并不会完全一致，但归根揭底，帧同步和状态同步必然会遵循上述几点，在设计算法时无需在意那些为了优化体验的细节。

以下是一些具有代表性游戏的同步方式：

帧同步是比较容易理解的，所有的客户端都是一个完整独立的系统，并且我们指导游戏中的随机性均是伪随机，在seed确定的情况下，每个系统的状态的改变只取决于游戏的输入，也就是说我们通过服务器来转发所有玩家的操作输入客户端游戏系统，那么就能保障所有的客户端都是同步的。

比如某个时刻，玩家0做了操作x， 整个同步过程如下：

显而易见的，因为只同步了用户的操作，这个数据传输量其实是很少的，所以很省流量，除非玩家特别多...

对于绝大多数的状态同步游戏，它的逻辑计算完全放在服务器上，因此也十分好理解。客户端只是相当于一个表现层，用来展示服务器发送过来的数据。就像我们打开一个网页，网页上的数据都是从服务器发过来的，因此我们本地是没办法作弊的，除非黑了服务器，因此这种状态同步的游戏基本上是没有外挂的。

但是有一种特殊的情况，就是FPS类型的游戏，如果靠服务器来运算，整个延迟下来就没法正常玩了...因此它的战斗逻辑会在客户端，而只向服务器汇报结果，因此类似吃鸡的这种游戏会有很多的外挂。

对于战斗逻辑在服务器的状态同步游戏，它的安全性是十分高的，因为想作弊就得黑入服务器，这个难度可想而知。但是FPS类型游戏部分战斗逻辑在客户端，这个会好被外挂修改，这也是FPS游戏外挂多难以根治的主要原因。

而帧同步的游戏整个计算逻辑在客户端，因此，开挂者因为可以获得全系统的信息，于是就可以很容易做开图之类的外挂。

EA的云端同步功能可以让你在玩游戏时，将游戏存档保存到EA的服务器上，并在其他设备上恢复游戏数据。你可以在EA游戏中，找到"云存档同步"选项，登录EA账号后，开启这项功能，游戏进行暂存和上传时，它就会自动将存档保存在EA的服务器上。

---