网络游戏的状态同步和帧同步

游戏开发中，有两种主要的同步模式，一种是状态同步, 一种是帧同步, 这两种同步模式是完全不一样的。

接下来我们来分别的分析一下他们同步的原理。

先看状态同步，服务器上跑所有的游戏逻辑(没有图像，动画, 只有数据), 所有的结果都由服务器游戏逻辑计算出来，

比如玩家A打死了一个怪，服务器上的游戏逻辑判定玩家A打死了一个怪，才会把这个消息广播给对这个事件感兴趣的玩家(AOI),收到事件的玩家，才会播放怪死亡的动画。服务器上的逻辑，是靠玩家发送过来的操作来驱动的。比如，玩家A放了一个大招, 玩家的客户端，不会马上放大招，而是会把这个操作发送给服务器，服务器验证玩家A能否发大招(蓝是否够，是否在buff冷冻期等),如果A能发大招，服务器就发一个大招，然后把事件广播给对这个玩家A感兴趣的客户端和玩家A自己，这样就看到玩家A发了一个大招了(播放动画)。至于这个大招照成的伤害，服务器会把状态同步给客户端，客户端根据服务器的状态播放动画就可以了。状态同步的几个核心技术点:

(1) 服务器上跑游戏逻辑;

(2)玩家的操作需要验证;

(3)找出对玩家A操作感兴趣的玩家来节约带宽(AOI)

(4)服务器上状态改变了，发消息给客户端，客户端马上同步到服务器上的状态;

再来看帧同步，你可以把帧同步想象成写单机游戏, 同一个游戏里面的两个游戏手柄，玩家A，玩家B各控制一个游戏手柄。游戏引擎以一个帧率来采集玩家的操作，把玩家的操作，输入游戏代码逻辑，这样驱动游戏角色的处理和游戏向前推进。同步的理论就是: 同样的输入 + 同样的代码 得到同样的结果。好接下来，我们就把两个玩家分开，不是连在机器上的两个游戏手柄，而是把这两个游戏手柄用网络连接起来，这样，还是能符合 同样的输入+同样的代码得同样得画面。本地单机游戏得时候，游戏引擎是以帧率来采集操作，而变成网络后，就是由服务器来每隔一段时间触发一帧, 时间间隔用来收集玩家的操作，等帧时间一到，就把采集到的操作发送给同局游戏的所有的客户端。所有的客户端就会接收到这个操作，客户端就计算，这样大家看到的画面都是一致的, 服务器又继续采集等待客户端发过来的操作，直到下一帧触发。

帧同步的难点:

(1) 同样的输入 + 同样的代码 = 同样的结果，有些不同机器，浮点数计算，误差，会导致不同结果。

(2) 游戏手感完全取决于转发操作的流畅程度，网络波动，TCP会卡住后面的数据包，影响手感，一般采用UDP，

同时设计的时候,克服UDP的缺点丢包时序等，需要系统的综合设计。

(3) 帧预测与结果同步，这块不难，但是很多小伙伴想不明白。

这里有个教学视频可以学习一下, 或者加入Unity交流小组进行交流
————————————————
版权声明：本文为CSDN博主「Clank的游戏栈」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/voidinit/article/details/119883749