网游帧同步的分析与设计

今年的春节非同寻常，假期时间比较长，恰好自己也打算利用春节的假期充充电，所以系统的研究和设计了一下帧同步方案，将其作为自己和公司的一个技术储备，本文中如有疏漏和错误，还请各位多多指教。

我一直在脑补这样一种游戏类型，开放世界+位面战斗，这是一种状态同步与帧同步结合的游戏玩法，既不失去在大世界中与玩家交互的乐趣，又可以在战斗时达到极致的爽快感，只要没有进入战斗，那么一直是状态同步的，所有的技能在状态同步下只支持空放，这时的技能只是一个展示炫耀的作用，所有的开放世界玩法都是在状态同步下进行的，那么打怪和PVP则需要原地进入一个位面，在位面中使用帧同步技术来处理战斗，理论上是可以让战斗效果达到主机游戏的水平的，当然这种类型的游戏就失去了野外抢怪、偷袭玩家的乐趣，但是换来的是极致的战斗体验，个人认为舍弃这些也值得。

国内的大厂都很喜欢做MMORPG和ARPG，也深耕于此，但是直至目前为止，战斗系统都做的比较简单，而且在表现上都是取巧的设计，国内的ARPG的A，不是Action而是Animation，甚至很多游戏都还是站桩式的战斗系统，打击感完全依靠夸张的动画或者特效来模拟，之所以没法做成真正的动作游戏是因为大都在采用状态同步，战斗的判定和AI也都是由服务器来驱动，前后端的同一帧状态不对等，无法保证每一个客户端的每一帧都得到相同的运算结果，所以在设计一些实时性高的技能玩法时捉襟见肘，例如：投技、实时QTE、锁镜头慢放、空中连击、打怪的复杂表现等等，虽然我们使用状态同步也实现了这些玩法，但在这中间做了很多的让步和取巧处理，对于战斗策划的限制还是比较多的。目前市面上的大部分RPG、ARPG都是使用的状态同步，网上的资料也比较多，所以本篇文章就不详细介绍状态同步了。而帧同步的理论基础就是保证每个客户端的帧步调一致（Lockstep），每个客户端表现的无论是玩家还是NPC都是一致的，所以在理论上，帧同步网游的战斗效果可以做到跟单机游戏一样的表现。

我们从最核心的同步部分开始，帧同步，顾名思义就是每个人的每一帧都是同步的、一致的，流程如图1：

图1

忽略图中的播放帧和逻辑帧，后面的内容会对其进行描述。图例中有2个玩家，这2个玩家与服务器的开始时间和帧率都是相等的，理想情况下是不存在谁快谁慢，客户端每一帧都会将玩家的操作指令上报给服务端，服务端收集齐了所有玩家在这一帧的指令或者服务端的时间已经到达了该帧的时间点，服务端统一将此帧产生的指令广播给客户端，客户端收到后，再按照服务端广播的指令进行相应帧的表现处理，然后步进逻辑帧，所有的游戏逻辑计算都放在了客户端，服务端只负责转发每一帧的消息。上图中的逻辑帧、缓冲帧、播放帧会在后面有所说明，在此只需要清楚，逻辑帧所包含的指令是经过确认的真实指令。

电影院播放的电影胶片是按照每秒24张图片进行的刷新，也就是每秒24帧，每帧的时间是41ms，那么游戏只要大于等于24帧，玩家看到的图像就是连贯的，我所做过的手机游戏都是维持在30帧的，所以上图中我默认每帧是33ms。

但是现实总是事与愿违，每个玩家的网络情况是不确定的、终端机的性能是不确定的，我们来看图2这种情况：

图2

上图出现了两个典型的问题：

1. 第1帧执行之前的操作一切都是正常的，Client1和Client2的用户指令都发给了服务端，服务端也在第1帧执行之前将这一帧的指令返回给了两个客户端，其中Client1正常收到了返回，但是Client2由于网络或者终端卡顿，在第一帧应该执行的时候并没有收到服务端返回的第1帧指令。
2. 在第1帧和第2帧之间，Client1和Client2都向服务端发送了用户指令，由于网络延迟导致了服务端在执行到第2帧的时候，一直没有收齐所有用户指令，此时服务端认为Client1在这一帧没有任何操作，于是将其余的用户指令下发下去，由于客户端和服务端的帧都是同步的，当Client2收到服务端的第2帧指令时，在自己本地的时间轴上，已经过了第2帧，甚至已经执行到了第3帧。

我将这种问题称作