Unity网络同步方案帧同步和状态同步

这两年做的都是帧同步和状态同步的项目，正好最近有时间总结一下什么是帧同步和状态同步，之前在做第一个足球项目的时候开会讨论了也很久开始选择的方向有点问题选的状态同步，没有选择帧同步，正好说一下来帮大家避坑

介绍

刚开始我们团队立项的休闲足球游戏，很多人应该都玩过之前的CoolGoal! - Soccer这个游戏，根据手势划线来想办法进球的一个游戏，有点像点球达人(去掉联网的部分)这样一款游戏，后来在老板的兴趣爱好下逐步扩大到多人足球模式，1v1、2v2、3v3、4v4、5v5、6v6等多人匹配模式。后面才有了我们选状态同步和帧同步方案。

开始我们使用的状态同步（实时状态同步）

设想的是每个客户端同步发送自己操作对象的位置和旋转以及一些动作和状态等，其他客户端和自己接收每个人的位置在本地做平滑补针处理。至于足球的信息同步是谁带球谁去做同步，不带球时则上一个带球人同步足球信息。这种做法在理想的情况下是没有问题的，比较丝滑。但是如果在网络信号稍微差一点的情况下，或者同步球位置的人网络差，那么这场一个人会影响所有人的体验，显然不合理。但是好处是验证比赛结果确实很好做，甚至可以不用做，比赛时就在验证。而且客户端的压力也不是很大。

后来采用的帧同步

帧同步的坑其实更多，如果你是想本地搭建一个健全的定点数物理库以及碰撞那么这个周期会非常长；

1. 持续的优化和有足够的底层基础这个是你想自己搭建物理库的基础；
2. 如果你们要做AI的话，你市面上的AI插件你必然是没法使用的，因为都是浮点数，需要自己在实现一套定点数的AI行为树；
3. 如果你们项目需要做寻路，那么当然你也需要实现一套定点数的寻路系统；
4. 抛开显示层可以使用浮点数做插值运算平滑补帧处理之外，逻辑层都不能用Unity先关的浮点数组件，包括缸体碰撞等所有的浮点数组件，你必须写一套浮点数的；当然现在有GPT你可以觉得简单，但是这件事情你如果没有搞过引擎底层的话还是慎重考虑，因为你考虑的东西应该没有底层玩家考虑的周全，持续优化点应该也会比较多；
5. 后面我会推荐一下做帧同步和状态同步的平台和我们用的健全的物理库；

状态同步

状态同步说白了就是把玩家的当前的状态行为做为一个同步的帧去做同步，通常情况下AI、技能、Buf、战斗逻辑计算都是由服务器运算，把运算的结果同步给客户端，客户端在根据收到的帧状态本子做平滑补帧更新自己的状态（动作、Buff、位置等）就好。服务器的压力会比帧同步压力大很多，客户端可以做一些本地计算来减轻服务器的压力和同步数据量。

优点

1. 比较安全，因为逻辑在服务器上的原因，防作弊机制天然就有了；
2. 状态同步对网络带宽和抖动包比较友好，延迟很高在恢复，对玩家的体验影响会小一些；
3. 断线重连机制相对好做一些，因为只需要同步当前所有对象的最新状态即可；
4. 逻辑方便优化，客户端当前屏幕中看不到的玩家都可以裁剪屏蔽，减少运算量；

缺点

1. 对比帧同步开发效率比较低，保证服务器和客户端每一个角色对象状态之间的一致比较难。比如优化一些裁剪，网络抖动等，你想让每一个角色对象状态同步还是没那么简单，这块也是需要些时间来做。
2. 打击感相对差一些，因为状态同步的计算伤害都是服务器来计算，你客户端制作同步，如果射击类或者打击感比较强的游戏想要比较精准还是很困难，系统需要在很短的时间内产生很多子弹和数据，需要的开销也不小；
3. 你的游戏越复杂你要同步的状态信息也会变大，可能一局游戏需要的数据流量会很大。

帧同步

简单来说帧同步就是 相同的状态 + 相同的指令 + 按帧顺序执行 + 相同物理库 = 相同的结果。逻辑层显示层分离，客户端使用一致的物理库和定点数，接收一样的随机种子确保逻辑一致。服务器只转发所有客户端发来的指令，客户端本地运算。

顺序执行

每帧都要有序号，需要保证所有的帧都跑一边且不能中途丢帧，如果丢帧则计算的结果肯定会不一致。

追帧

当客户端在网络上信号差或者网络波动的，接收到服务器下发多个帧，客户端就需要所加速播放帧。这里是一个追帧机制，优化可以不播放音效和特效，不影响结果的显示层逻辑都可以不处理。

重连

重连时需要拿到完整的比赛帧数据，从开始一直加速播放到当前帧（追帧机制）。

优点

1. 帧同步开发效率比较高。服务器逻辑简单只需要负责转发指令压力小，客户端封装好物理组件和碰撞等直接上手写即可。
2. 它能实现更强的打击感，打击感强除了我们说的各种反馈、特效、音效外，还有它的准确性。利用帧同步，游戏里面看到这些挥舞的动作，就能做到在比较准确的时刻产生反馈，以及动作本身的密度也可以做到很高的频率，这在状态同步下是比较难做的
3. 它的流量消耗是稳定的。大家应该看过《星级争霸》的录像，它只有几百K的大小，这里面只有驱动游戏的输入序列。帧同步只会随着玩家数量的增多，流量才会增长，如果玩家数量固定的话，不管你的游戏有多复杂，你的角色有多少，流量消耗基本上都是稳定的。
4. 可以更方便地实现观战，录像的存储、回放，以及基于录像文件的后续处理。

缺点

1. 最致命的缺点是网络要求比较高，帧同步是锁帧的，如果有网络的抖动，一段时间调用次数不稳定，网络命令的延迟就会挤压，引起卡顿。
2. 它的反外挂能力很弱，帧同步的逻辑都在客户端里面，你可以比较容易的修改它。但为什么《王者荣耀》敢用帧同步，一方面是因为当时立项的时候开发周期很短，半年时间要做上线，要有几十个英雄，存在时间的压力，另一方面，MOBA类游戏不像数值成长类的游戏，它的玩法是基于单局的，单局的作弊修改，顶多影响这一局的胜负，不会存档，不会出现刷多少钱刷多少好的装备的问题，而且作弊之后我们也很容易监测到，并给予应有的惩罚，所以我们认为这不是致命的缺点。
3. 它的断线重回时间很长，相信台下也有很多王者玩家，也曾碰到过闪退以后重回加载非常长的情况，甚至加载完以后游戏也快结束了，这是帧同步比较致命的问题。
4. 它的逻辑性能优化有很大的压力。大家应该没有见到哪一款大型游戏是用帧同步来做的，因为这些游戏的每一个逻辑对象都是需要在客户端进行运算的。如果你做一个主城，主城里面有上千人，上千人虽然玩家看不到它，但游戏仍然需要对他们进行有效的逻辑运算，所以帧同步无法做非常多的对象都需要更新的游戏场景。
5. debug困难，出现不同的情况，难以查找问题所在，一般通过debug输出关键改变信息来定位问题，但问题可能在1-20个函数之内，但只在第20个函数打了debug信息，然后需要一层层去查找出现问题的所在，考虑把出问题的局录下来，然后不断重播和调试，方便找到问题

总结

希望我的经历和理解能够帮助到大家，其中部分是借用别人的博客内容，感谢