主程技术分享: 游戏项目帧同步,状态同步如何选

Clank的游戏栈

墨衍会员 · AI 创作全网分发码龄21年

关注

原创 2022-03-28 14:32:32 5.9k 阅读 AI 写同款· GEO 优化 ›

网络游戏开发项目中帧同步,状态同步如何选？

网络游戏的核心技术之一就是玩家的网络同步,主流的网络同步有”帧同步”与”状态同步”。今天我们来分析一下这两种同步模式。同时教大家如何在自己的项目中采用最合适的同步方式。接下来从以下3个方面来阐述:

1: 状态同步的原理与常用的处理方式;

2: 帧同步的原理与常用的处理方式;

3: 哪些游戏适合帧同步,哪些游戏适合状态同步;

这里有个学习交流小组里面有大佬有萌新大家可以一起学习交流哦

希望能帮助大家掌握帧同步与状态同步原理，并能做出对项目与团队最正确的选择。

状态同步的原理与常用的处理方式

状态同步是在服务器上跑完整的游戏逻辑，包含每个角色在游戏地图上行走，攻击。角色与角色的战斗，都要编写代码实现在服务端。可以理解为是跑在服务端的没有图像渲染的游戏。同时由于多人在线，服务器端接收每个玩家的客户端传过来的输入操作，根据玩家操作来迭代计算游戏。一般采用状态同步的网络游戏，在服务器上实现战斗逻辑，寻路导航，地图, 技能释放, 怪物AI行为决策, 物理引擎等常见的游戏开发的功能与模块(具体是哪些模块需要根据不同的项目来决定)。

每个玩家+NPC+怪物都在服务器上有对应的数据对象，并且这么多对象都要处理，而且这些对象为避免线程锁等开销，一般都在一个线程, 所以像MMORPG 每个地图的同时在线的游戏人数是有上限的，上限取决于服务器的机器配置与游戏逻辑的复杂度。比如魔兽世界”一个地图”最多同时在线约3000人左右。有人就会问魔兽世界每天同时在线的人数远远超过3000人，怎么你说它一个地图最多是3000人”同时在线”呢？这里的”同时在线”指的是同一个地图的两个玩家，走到同一个地方，彼此能看到对方。而不是两个玩家同时在玩同一个地图名字，但是走到地图的同一个位置彼此看不见 (相当于两个不同的逻辑服，用的是同一个地图)。到目前为止你可以想像成状态同步的服务器是一个跑有若干玩家的游戏逻辑，这些玩家的操作输入指令来自于网络客户端。

游戏玩家是要看图像的，不能只看数据在那里跑, 客户端就要根据服务器上的”状态”重现出服务器上当前的游戏画面。如果客户端把服务器上所有的玩家角色都创建并渲染出来, 客户端性能可能达不到,也没有必要，每个玩家都有一个特定的”视野” 范围, 视野内的游戏角色的画面在客户端构建同步出来就可以了，视野外的可以不用管。所以客户端是同步视野范围内服务器的状态的画面。

大家都是根据服务器上的状态来显示画面的，所以不同客户端能”同步”。准确的讲是同步显示的服务器上元素状态。什么是”状态”？一般游戏里面我们把一些关键的信息叫做”状态”, 举一个例子:

   角色怪物出生
   角色怪物的Idle, Walk, Attack, Dead等

接下来我们拿玩家从创建对象, 到待机,到行走，到攻击，回到待机来举例，来看下角色的状态变化以及这个过程中客户端如何同步。

服务器上创建了一个角色对象A,这个角色对象A就会出现在”若干玩家”的视野里(AOI算法),对于这若干玩家而言状态发生了变化，服务器给它们都发送一个角色创建的状态信息含角色的位置，角色的类型，朝向角度,角色状态(Idle)等,这些玩家客户端就把这些角色创建出来。对于角色对象A对应的客户端，服务器要把它视野范围内(AOI)的其它客户端的角色状态发送给它，然后它根据这些状态信息把画面绘制出来。接下来服务器就按照角色状态进行迭代，待机的待机，行走的行走。客户端按照状态也进行迭代，一但状态变化就同步，我们接着角色对象A创建出来的idle状态来分析，那么服务器上角色对象A是Idle其它玩家看它也是Idle。角色对象A发了一个行走的操作给服务器,服务器先判断这个操作的合法性，如果合法，服务器就把角色对象A的状态(位置,旋转,状态等关键指标)+玩家的行走操作(寻路走到目的地dst)一起发送给能看见A玩家的人(能看见A的客户端+包含A自己)，关键来了，收到这个状态变化后，每个客户端先重置一下角色数据的状态(位置,旋转,缩放)与服务器同步，在大家都同步到服务器的状态的基础上再做寻路移动操作。接下来角色对象A开始行走了，服务器上要寻路，然后迭代A的行走数据,客户端上的对象A也要寻路,也要再客户端上行走，这个过程可以和服务器失去联系(服务器走服务器的，客户端走客户的端的)。这样角色A就在客户端走起来。行走过程中客户端A发现了一个怪物，点了一下怪物，触发攻击操作,这个时候服务端收到这个客户端A的攻击操作,先判断检查是否合法,如果合法了角色A就要从Walk状态到Attack状态了,这个时候服务端先把服务器上角色A目前的状态(位置,旋转,缩放等)+服务器上角色A的操作一起发给对可见角色A的客户端+角色A自己。收到这个数据后，先同步状态(重置客户端上的角色状态到为服务器上的状态),然后基于同步服务端状态后的再做攻击操作，客户端播放攻击动画，服务端计算攻击逻辑和伤害。当服务器迭代的过程中发现了怪物已经被打死了(状态变化),那么就把角色A的状态+怪物状态,同步给对角色A感兴趣的客户端，然后同步怪物与角色A的状态，然后客户端就把角色A由攻击变成idle状态了，位置也同步了服务器上的。

总结一下,客户端根据服务器的状态+后续操作来重现游戏画面，服务器接收玩家操作,独立迭代游戏逻辑,迭代中发现状态变化(玩家操作等决策引起),通知客户端，客户端先同步服务器上的状态，然后基于这个状态再结合操作播放动画。总之服务端迭代服务端的，客户端迭代客户端的,服务器每次状态变化，同步到客户端后再接着播放动画。客户端与服务器上同步的是服务器上的最后的一个状态。

帧同步的原理与常用的处理方式

做单机游戏时，根据客户端的帧率来驱动我们的游戏逻辑，每帧检查玩家有没有操作,如果有操作就进行处理。单机游戏的本质就是基于帧率来进行驱动的。帧同步原理就是把这个帧率在本机的转为由服务器每隔一段时间向客户端发送数据来作为帧来驱动游戏, 同样的服务器的驱动,同样的客户端逻辑代码，每个客户端跑出来的结果就是一致的。

服务端只要负责把每帧采集到的玩家操作，转给所有客户端, 这样客户端根据服务端的帧操作来迭代游戏。客户端的帧率是60左右给玩家的感觉是比较流畅的,服务器以多少的帧率来驱动客户端玩家感觉会是流畅的呢？60FPS是画面的流畅度，服务器同步的是操作,人的反应时间是50~100ms,所以服务器只需要20FPS左右就能够获得非常流畅的操作手感，所以帧同步服务器的帧率一般是每秒15~20FPS左右。

了解帧以后，接下来看如何基于帧同步, 服务器如果确认了每秒20FPS,那么服务器帧的时间间隔就确定了为50ms, 当我们收到一个新的服务器帧的时候，先不着急处理，而是先要回到上一帧的状态(位置，旋转等),然后基于上一帧的操作来使用50ms时间间隔来迭代这帧的结果，再基于当前同步后的状态处理服务器给我们发过来的帧操作，播放动画等。所以帧同步是每帧都同步。客户端根据当前帧来展现动画，到下一帧来的时候先做同步计算，这样达到客户端同步，这里的同步准确的说是每一个服务器帧都进行同步, 这一帧能同步是基于上一帧同步的基础上同样的操作+同样的时间间隔迭代出来的同步。和状态同步不同，状态同步的状态全部记录在服务端了，而帧同步是需要依赖前一帧，前一帧又依赖前前帧，这样直到第1帧。所以帧同步每次断线重连，时间久就是这个道理，因为要重新新从第一帧开始算起。

哪些游戏适合帧同步,哪些游戏适合状态同步

搞懂了上面的原理,我们来看下哪些游戏适合帧同步,哪些游戏适合状态同步。状态同步基本上适合绝大部分的游戏,包括帧同步擅长的领域用状态同步做也能做的很好。帧同步的局限性就大很多了，接下来我们来分析帧同步的优点与缺点。帧同步与状态同步相比，服务器要简单很多，而且服务器的项目可以高度重用，因为写好一个游戏的服务端帧同步，下一个游戏的服务器基本不用改，所以腾讯推出一些服务端的集成方案就有帧同步的服务器，每个游戏项目都可以用, 做到服务端高度重用。帧同步与状态同步相比，帧同步更平滑,不会有一些峰值，这样导致玩家的手感一直很好，什么叫做峰值，状态同步，突然某个时刻状态变化比较多，同步的数据量大，网络和处理可能会有瞬间的卡顿，而这种可能就影响关键时候的手感,帧同步在这块就更平滑。每次只要同步玩家的操作，数据包更小。所以一些强调操作手感的游戏是可以用帧同步来做的。帧同步每一个玩家对应的角色都要在客户端计算迭代,而不像状态同步只迭代视野范围内的，所以帧同步对客户端的运算量会变大，同时帧同步不能适用在同时3000人一起玩的游戏，因为3000个角色都要在客户端，每帧都同时迭代计算，客户端性能达不到。所有MMORPG, 这种游戏基本都不采用帧同步，采用帧同步的都是固定一起对战的人数的，如王者荣耀5v5, 守望先锋等。帧同步每次同步都是当前帧依赖前一帧,每次断线重连，只能从第1帧开始迭代计算，快速的跳到最新的帧，所以采用帧同步的游戏一局的时间不能太长,比如一局游戏可以打2天，你每帧都要保存住，如果某个玩家断线从连，要从2天前的帧开始计算，这个就只能呵呵了，MMORPG 这种游戏不适合帧同步。帧同步的计算全部放客户端，所以没有状态同步那么安全。

分析完后我们得到一条结论: 一局时间不长的游戏,每一局不允许玩家中途进来的游戏,每一局的人数是少量固定的(5vs5, 10vs10)，对客户端计算不敏感，这种游戏可以采用帧同步。帧同步能获得很好的操作手感，降低服务端的开发难度,如果没有服务端的团队，还可以用腾讯的帧同步服务器。