帧同步优化难点及解决方案

帧同步这部分比较复杂，细枝末节有很多优化点，也有一些不同的优化方向，根据不同项目类型、对操作手感的要求、联机玩家的个数等，会有不同的难点和痛点。不同的优化方向，优化手法的差异，可能导致一些争论。并且，帧同步，本身也有很多变种，以应对不同的需求。所以，本文一切都是基于作者的项目类型（ACT）来做的方案和优化，并不一定适合其它也需要帧同步的游戏，故在此提前说一下，以免引起一些不必要的误解。

帧同步的几个难点

帧同步的基础原理，以及和状态同步的区别，已经有很多文章介绍，我就不再赘述，大家可以自行google。以下只说几个难点。

保证客户端独自计算的正确，即一致性

帧同步的基础，是不同的客户端，基于相同的操作指令顺序，各自执行逻辑，能得到相同的效果。就如大家所知道的，在Unity引擎中，不同的调用顺序，时序，浮点数计算的偏差，容器的排序不确定性，Coroutine内写逻辑带来的不确定性，物理浮点数，随机数值带来的不确定性等等。

有些比较好解决，比如随机数值，只需要做随机种子即可。

有些需要注意代码规范，比如在帧同步的战斗中，逻辑部分不使用Coroutine，不依赖类似Dictionary等不确定顺序的容器的循环等。

还有最基础的，要通过一个统一的逻辑Tick入口，来更新整个战斗逻辑，而不是每个逻辑自己去Update。保证每次Tick都从上到下，每次执行的顺序一致。

物理方面，因为我们战斗逻辑不需要物理，碰撞都是自己做的碰撞逻辑，所以，跳过不说，这块可以参考别的文章。

最后，浮点数计算无法保证一致性，我们需要转换为定点数。关于定点数的实现，比较简单的方式是，在原来浮点数的基础上乘1000或10000，对应地方除以1000或10000，这种做法最为简单，再辅以三角函数查表，能解决一些问题，减少计算不一致的概率。但是，这种做法是治标不治本的方式，存在一些隐患（举个例子，例如一个int和一个float做乘法，如果原数值就要*1000，那最后算出来的数值，可能会非常大，有越界的风险。）

最佳的解决办法是：使用实现更加精确和严谨，并经过验证的定点数数学库，在C#上，有一个定点数的实现，Photon网络的早期版本，Truesync有一个很不错的定点数实现。

定点数的实现

其中FP，就可以完全代替Float，我们只需要将我们自己的逻辑部分，Float等改造为FP，就可以轻松解决。并且，能够很好的和我们Protobuf的序列化方式集成（注意代码中的Attribute，如下图），保证我们的配置文件，也是定点数的。

TSVector对应Vector3，只要基于FP，可以自己扩展自己的数据结构。（当然，如果用到了复杂的插件，并且不开源，那么对于定点数的改造，就会困难很多）

三角函数通过查表方式实现，保证了定点数的准确

我个人认为，这一套的实现，是优于简单的乘10000，除10000的方式。带来的坏处，可能就是计算性能略差一点点，但是我们大量测试下来，对计算性能的影响很小，应该是能胜任绝大部分项目的需求。

对于计算的不确定性，我们也有一些小的隐患，就是我们用到了Physics.Raycast来检测地面和围墙，让人物可以上下坡，走楼梯等高低不平的路，也可以有形状不规则的墙。这里会获得一个浮点数的位置，可能会导致不确定性，这里，我们用了数值截断等方式，尽量规避，经过反复测试，没有出现过不一致。但是这种方式，毕竟在逻辑上，存在隐患，更好的方式，是实现一套基于定点数的raycast机制，我们人力有限，就没时间精力去做了。这块有篇文章讲得更细致一些，大家可以参看：
帧同步：浮点精度测试
https://zhuanlan.zhihu.com/p/30422277

帧同步网络协议的实现

在处理好了基础的计算一致性问题后，我们就要考虑网络如何通信。这里，我不谈p2p方式了，我们以下谈的，都是多client，一个server的模式，server负责统一tick，并转发client的指令，通知其他client，可以参看文章：
网游流畅基础：帧同步游戏开发
http://www.10tiao.com/html/255/201609/2650586281/4.html

首先，是网络协议的选择。TCP和UDP的选择，我就不多说了，帧同步肯定要基于UDP才能保证更低的延迟。在UDP的选择上，我看网上有些文章，容易导入一个误区，即，我们是要用可靠传输的UDP，还是冗余信息的UDP。

基于可靠传输的UDP，是指在UDP上加一层封装，自己去实现丢包处理，消息序列，重传等类似TCP的消息处理方式，保证上层逻辑在处理数据包的时候，不需要考虑包的顺序，丢包等。类似的实现有Enet，KCP等。

冗余信息的UDP，是指需要上层逻辑自己处理丢包，乱序，重传等问题，底层直接用原始的UDP，或者用类似Enet的Unsequenced模式。常见的处理方式，就是两端的消息里面，带有确认帧信息，比如客户端(C)通知服务器(S)第100帧的数据，S收到后通知C，已收到C的第100帧，如果C一直没收到S的通知（丢包，乱序等原因），就会继续发送第100帧的数据给S，直到收到S的确认信息。

有些文章介绍的时候，没有明确这两者的区别，但是这两种方式，区别是巨大的。可靠传输的UDP，在帧同步中，个人认为是不合适的，因为他为了保证包的顺序和处理丢包重传等，在网络不佳的情况下，Delay很大，将导致收发包处理都会变成类似TCP的效果，只是比TCP会好一些。必须要用冗余信息的UDP的方式，才能获得好的效果。并且实现并不复杂，只要和服务器商议好确认帧和如何重传即可，自己实现，有很大的优化空间。例如，我们的协议定义类似如下：

双方都要通知对方，已经接受哪一帧的通知了，并通过cmd list重发没有收到的指令

这里简单说一下，对于这种收发频繁的消息，如果使用Protobuf，会造成每个逻辑帧的GC，这是非常不好的，解决方案，要么对Protobuf做无GC改造，要么就自己实现一个简单的byte[]读写。无GC改造工程太大，感觉无必要，我们只是在战斗的几个频繁发送的消息，需要自己处理一下byte[]读写即可。

在这部分需要补充一下，KCP作者韦易笑提到KCP+FEC的模式，可以比冗余方式，有更好的效果，我之前并没有仔细研究过这个模式，不过可以推荐大家看一下。

因为我们项目早期，服务器定下了使用Enet，我评估了一下，反正使用冗余包的方式，所以没有纠结Enet或KCP，后续其实想改成KCP，服务器不想再动，也就放下了。

Enet麻烦的地方是，Enet的ipv6版本，是一个不成熟的Pull Request，Enet作者没有Merge（并且存在好几个ipv6的Pull Request），我不确定稳定性，还好看了下Commit，加上测试下来，没有太大问题。KCP我没有评估过ipv6的问题，不过Github上有C#版本，改一下ipv6支持应该很简单。

逻辑和显示的分离

这部分在很多讲帧同步的文章中都提过了。配置的数据和显示要分离，在战斗中，战斗的逻辑，也要和显示做到分离。

例如，我们动作切换的逻辑，是基于自己抽象的逻辑帧，而不是基于Animator中一个Clip的播放。比如一个攻击动作，当第10帧的时候，开始出现攻击框，并开始检测和敌人受击框的碰撞，这个时候的第10帧，必须是独立的逻辑，不能依赖于Animator播放的时间，或者AnimatorStateInfo的NormalizedTime等。甚至，当我们不加载角色的模型，一样可以跑战斗的逻辑。如果抽离得好，还可以放到服务器跑，做为战斗的验证程序，王者荣耀就是这样做的。

联机如何做到流畅战斗

前面所有的准备，最终的目的，都是为了战斗的流畅。特别是我们这种ACT游戏，或者格斗类游戏，对按键以后操作反馈的即时性，要求非常高，一点点延迟，都会影响玩家的手感，导致玩家的连招操作打断，非常影响体验。我们对延迟的敏感性，甚至比MOBA类游戏还要高，我们要做到好的操作手感，还要联机战斗（PVP，组队PVE），都需要把帧同步做到极致，不能因为延迟卡住或者操作反馈出现变化。

因为这个原因，我们不能用Lockstep的方式，Lockstep更适合网络环境良好的内网，或者对操作延迟不敏感的类型（例如我听过还有项目用来做卡牌类的帧同步）。

我们也不能用缓存服务器确认操作的方式，也就是一些游戏做的指令Buffer。具体描述，王者荣耀的分析文章，讲得很具体了。这也是他们说的模式，这个模式能解决一些小的网络波动，对一些操作反馈不需要太高的游戏，例如有些游戏攻击前会有一个比较长的前摇动作，这类游戏，用这种方式，应该就能解决大部分问题。但是这种方式还是存在隐患，即使通过策略能很好地动态调整Buffer，也还是难以解决高延迟下的卡顿和不流畅。王者荣耀优化得很好，他们说能让Buffer长度为0，文章只提到通过平滑插值和逻辑表现分离来优化，更细节的没有提到，我不确定他们是否只是基于这个方式来优化的。目前也没有看到更具体的分析。

指令Buffer的方式，也不能满足我们的需求，或者说，我没有找到基于此方式，能优化到王者荣耀的效果的办法。我也测试过其他MOBA和ACT，ARPG类游戏的联机，在高延迟，网络波动情况下，没有比王者表现更好的了。

最后，在仔细研究了我们的需求后，找到一篇指导性的文章，非常适合我们：
Understanding Fighting Game Networking
http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking/

这篇文章非常详细地介绍了各种方式，最终回滚逻辑(Rollback)是终极的解决方案，国内也有文章提到过，即：
Skywind Inside 再谈网游同步技术
http://www.skywind.me/blog/archives/1343#more-1343

文章里面提到的Time Warp方式，我理解回滚逻辑，和Time Warp是一个概念。

游戏逻辑的回滚

回滚逻辑，就是我们解决问题的方案。可以这样理解，客户端的时间，领先服务器，客户端不需要服务器确认帧返回才执行指令，而是玩家输入，立刻执行（其他玩家的输入，按照其最近一个输入做预测，或者其他更优化的预测方案），然后将指令发送给服务器，服务器收到后给客户端确认，客户端收到确认后，如果服务确认的操作，和之前执行的一样（自己和其他玩家预测的操作），将不做任何改变，如果不一样（预测错误），就会将游戏整体逻辑回滚到最后一次服务器确认的正确帧，然后再追上当前客户端的帧。

此处逻辑较为复杂，我尝试举个例子说明下。

当前客户端(A,B)执行到100帧，服务器执行到97帧。在100帧的时候，A执行了移动，B执行了攻击，A和B都通知服务器：我已经执行到100帧，我的操作是移动(A)，攻击(B)。服务器在自己的98帧或99帧收到了A,B的消息，存在对应帧的操作数据中，等服务器执行到100帧的时候（或提前），将这个数据广播给AB。

然后A和B立刻开始执行100帧，A执行移动，预测B不执行操作。而B执行攻击，预测A执行攻击（可能A的99帧也是攻击），A和B各自预测对方的操作。

在A和B执行完100帧后，他们会各自保存100帧的状态快照，以及100帧各自的操作（包括预测的操作），以备万一预测错误，做逻辑回滚。

执行几帧后，A和B来到了103帧，服务器到了100帧，他开始广播数据给AB，在一定延迟后，AB收到了服务器确认的100帧的数据，这时候，AB可能已经执行到104了。A和B各自去核对服务器的数据和自己预测的数据是否相同。例如A核对后，100帧的操作，和自己预测的一样，A不做任何处理，继续往前。而B核对后，发现在100帧，B对A的预测，和服务器确认的A的操作，是不一样的（B预测的是攻击，而实际A的操作是移动），B就回滚到上一个确认一样的帧，即99帧，然后根据确认的100帧操作去执行100帧，然后快速执行101~103的帧逻辑，之后继续执行104帧，其中（101~104）还是预测的逻辑帧。

因为客户端对当前操作的立刻执行，这个操作手感，是完全和PVE（不联网状态）是一样的，不存在任何Delay。所以，能做到绝佳的操作手感。当预测不一样的时候，做逻辑回滚，快速追回当前操作。

这样，对于网络好的玩家，和网络不好的玩家，都不会互相影响，不会像Lockstep一样，网络好的玩家，会被网络不好的玩家Lock住。也不会被网络延迟Lock住，客户端可以一直往前预测。

对于网络好的玩家(A)，可以动态调整（根据动态的Latency），让客户端领先服务器少一些，尽量减少预测量，就会尽量减少回滚，例如网络好的，可能客户端只领先2~3帧。

对于网络不好的玩家(B)，动态调整，领先服务器多一些，根据Latency调整，例如领先5帧。

那么，A可能预测错的情况，只有2~3帧，而网络不好的B，可能预测错误的帧有5帧。通过优化的预测技术，和消息通知的优化，可以进一步减少A和B的预测错误率。对于A而言，战斗是顺畅的，手感很好，少数情况的回滚，优化好了，并不会带来卡顿和延迟感。

重点优化的是B，即网络不好的玩家，他的操作体验。因为客户端不等待服务器确认，就执行操作，所以B的操作手感，和A是一致的，区别只在于，B因为延迟，预测了比较多的帧，可能导致预测错，回滚会多一些。比如按照B的预测，应该在100帧击中A，但是因为预测错误A的操作，回滚重新执行后，B可能在100帧不会击中A。这对于B来说，通过插值和一些平滑方式，B的感受是不会有太大区别的，因为B看自己，操作自己都是及时反馈的，他感觉自己是平滑的。

这种方式，保证了网络不好的B的操作手感，和A一致。回滚导致的一些轻微的抖动，都是B看A的抖动，通过优化（插值，平滑等），进一步减少这些后，B的感受是很好的。我们测试在200~300毫秒随机延迟的情况下，B的操作手感良好。

这里，客户端提前服务器的方式，并且在延迟增大的情况下，客户端将加速，和
守望先锋的处理方式是一样的。当然，他们肯定比我做得好很多：
https://mp.weixin.qq.com/s/cOGn8-rHWLIxdDz-R3pXDg

希望我已经大致讲清楚了这个逻辑，大家参看几篇链接的文章，能体会更深。

这里，我要强调的一点是，我们这里的预测执行，是真实逻辑的预测，和很多介绍帧同步文章提到的预测是不同的。有些文章介绍的预测执行，只是View层面的预测，例如前摇动作和位移，但是逻辑是不会提前执行的，还是要等服务器的返回。这两种预测执行（View的预测执行，和真实逻辑的预测执行）是完全不是一个概念的，这里需要仔细地区分。

这里有很多的可以优化的点，我就不一一介绍了，以后可能零散地再谈。

游戏逻辑的快照（snapshot）

我们的逻辑之所以能回滚，都是基于对每一帧状态可以处理快照，存储下每一帧的状态，并可以回滚到任何一帧的状态。
Understanding Fighting Game Networking文章：
http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking/

守望先锋网络文章：
https://mp.weixin.qq.com/s/cOGn8-rHWLIxdDz-R3pXDg

以上两篇文章都一笔带过了快照的说明。他们说的快照，可能略有不同，但是思路，都是能保存下每一帧的状态。如果去处理快照（Understanding那篇文章做的是模拟器游戏，可以方便地以内存快照的方式来做），是一个难点。
这也是我前面文章，提到ECS在这个方式下的应用：
https://zhuanlan.zhihu.com/p/38280972

云风的解释：

云风博客截图，地址https://blog.codingnow.com/2017/06/overwatch_ecs.html

ECS是一个好的处理方式，并且我找到一篇文章，也这样做了（我看过他开源的demo，做得还不够好，应该还是demo阶段，不太像是一个成型的项目）。
https://www.kisence.com/2017/11/12/guan-yu-zheng-tong-bu-de-xie-xin-de/

这篇文章的思路是很清晰的，并且也点到了一些实实在在的痛点，解决思路也基本是正确的，可以参看。

这块我做得比较早了，当时守望先锋的文章还没出，我的战斗也没有基于ECS，所以，在处理快照上，只有自己理顺逻辑来做了。

我的思路是，通过一个回滚接口，需要数据回滚的部分，实现接口，各自处理自己的保存快照和回滚。就像我们序列化一个复杂的配置，每个配置各自序列化自己的部分，最终合并成一个序列化好的文件。

首先，定义接口，和快照数据的Reader和Writer

然后，就是每个模块，自己去处理自己的TakeSnapshot和Rollback，例如：

简单的数值回滚

复制的列表回滚和调用子模块回滚

思路理顺以后，就可以很方便地处理了，注意Write和Read的顺序，注意处理好List，就解决了大部分问题。当然，在实现逻辑的过程中，时刻要注意，一个模块如何回滚（例如获取随机数也需要回滚）。

有一个更简单的方式，就是给属性打Attribute，然后写通用的方法。例如，我早期的实现方案：

给属性打标签

根据标签，通用的读写方法，通过反射来读写，就不需要每个模块自己去实现自己的方法了：

部分代码

这种方法，能很好地解决大部分问题，甚至前面提到的Truesync，也是用的这种方式来做。

但是这种方法有个难以回避的问题，就是GC，因为基于反射，当我们调用field的GetValue和SetValue的时候，GC难以避免。并且，因为全自动，不方便处理一些特殊逻辑，调试优化也不方便，最后改成了现有的方式，虽然看起来笨重一些，但是可控性更强，我后续做的很多优化，都方便很多。

关于快照，也有很多可以优化的点，无论是GC内存上的，还是运行效率上的，都需要优化好，否则，可能带来性能问题。这块优化，有空另辟文章再细谈吧。

当我们有了快照，就可以支持回滚，甚至跳转。例如我们要看战斗录像，如果没有快照，我们要跳到1000帧，就需要从第一帧，根据保存的操作指令，一直快速执行到1000帧，而有了快照，可以直接跳到1000帧，不需要执行中间的过程，如果需要在不同的帧之间切换，只需要跳转即可，这将带来巨大的帮助。

自动测试

由于帧同步需要测试一致性的问题，对我们来说，回滚也是需要大量测试的问题。自动测试是必须要做的一步，这块没有什么特别的点，主要就是保存好操作，快照，log，然后对不同客户端的数据做比对，找到不同的地方，查错改正。

我们现在做到，一步操作，自动循环战斗，将每一盘战斗数据上传内网log服务器。

当有很多盘战斗的数据后，通过工具自动解析比对数据，找到不同步的点。也是还可以优化得更好，只是现在感觉已经够用了。经过大量的内部自动测试，目前战斗的一致性，是很好的。

总结

我们现在的帧同步方案，总结下来，就是预测，快照，回滚。当把这些有机地结合起来，优化好，就有了非常不错的帧同步联网效果，无论网络速度如何，只要不是延迟大到变态，都保证了非常好的操作手感。

快照回滚的方式，也不是所有游戏都适用，例如：
Skywind Inside 再谈网游同步技术文章中对此模式（Time warp或Rollback）的缺点，也说明了。
http://www.skywind.me/blog/archives/1343#more-1343

如图所述，这种模式不适合太多人的联网玩法，例如MOBA，可能就不太适用。我们最多三人联机，目前优化测试下来，效果也没有太大问题。但是联机人数越多，预测操作的错误可能性越大，导致的回滚也会越多。

一篇文章，难以讲得面面俱到，很多地方可能描述也不一定明确，并且，个人能力有限，团队人员有限（3个客户端）的情况下，必定有很多设计实现不够好的地方，大家见谅。

一些有帮助的文章再列一下：
1、Understanding Fighting Game Networking
http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking/

2、Skywind Inside " 再谈网游同步技术
http://www.skywind.me/blog/archives/1343#more-1343

3、《守望先锋》回放技术：阵亡镜头、全场最佳和亮眼表现
https://mp.weixin.qq.com/s/cOGn8-rHWLIxdDz-R3pXDg

4、《王者荣耀》技术总监复盘回炉历程
http://youxiputao.com/articles/11842

5、帧同步：浮点精度测试
https://zhuanlan.zhihu.com/p/30422277

6、A guide to understanding netcode
https://www.gamereplays.org/overwatch/portals.php?show=page&name=overwatch-a-guide-to-understanding-netcode

7、网游流畅基础：帧同步游戏开发
http://www.10tiao.com/html/255/201609/2650586281/4.html

最后啰嗦一句，如最开始所述，帧同步有很多变种、实现方式和优化方向。有时候，可能不同文章提到帧同步这个术语的时候，里面的意思，可能都有区别，大家需要仔细理清和区分。

---

这是侑虎科技第418篇文章，感谢作者Gordon供稿。欢迎转发分享，未经作者授权请勿转载。如果您有任何独到的见解或者发现也欢迎联系我们，一起探讨。QQ群：793972859（原群已满员）

作者主页：https://zhuanlan.zhihu.com/p/38468615，作者也是U Sparkle活动参与者，UWA欢迎更多开发朋友加入U Sparkle开发者计划，这个舞台有你更精彩！