游戏中的回放系统是如何实现的?

回放系统,是电子游戏中常见的一项功能。通过回放,我们可以观摩高手之间的对决,重复享受游戏中的精彩瞬间,甚至还可以拿到敌方玩家的比赛录像进行分析和学习。总的来说,回放功能常用于记录整个比赛的过程细节或者展示游戏中的精彩瞬间,非常贴合竞技类游戏玩家的需求。

精彩瞬间展示:FIFA / 实况足球 / NBA2K / 守望先锋 / 极限竞速:地平线 / 跑跑卡丁车

全局比赛录制、下载、播放:守望先锋 / CSGO / Dota / LOL / 魔兽争霸 / 星际争霸 / 红色警戒 / 坦克世界 / 绝地求生 / 王者荣耀

其实早在20世纪90年代,回放系统就已经诞生并广泛用于即时战略、第一人称射击以及体育竞技等类型的游戏当中。

当我们打开CSGo或者Dota回放文件夹的时候会发现这些回放的文件并不大,一场比赛下来最多也就几十兆,远小于对应时长的视频,那么回放到底是如何实现的呢?

第一种,逐帧的录制游戏画面。就像现实中体育赛事用摄像机捕捉现场画面那样,我们可以游戏渲染的时候直接从底层抓取画面信息来持续的生成一个视频流文件,然后通过任意的一个视频播放器都进行解析和回放。

一般来说,由于存储空间以及各种性能问题,录制游戏画面方式几乎不会被用于游戏开发中。

第二种,逐帧录制玩家的输入操作。其实游戏本身就是一个可视化的软件程序(或者说是一个渲染器),每一时刻的画面都是通过玩家的操作逻辑来驱动的。在考虑游戏内进行回放的情况下(比如死亡回放),我们完全没有必要去录制冗余的画面信息,只需要记录玩家的输入信息然后去驱动游戏逻辑改变画面就可以了。

通常来说,这种实现方式可以完美的利用游戏逻辑去进行回放,而且消耗非常小。对于帧同步(LockStep)的网络游戏,不需要额外做太多的工作,适合性能要求严格、物理计算不太需要同步的RTS、MOBA、FTG等类型游戏。

有了玩家输入信息我们可以较好的向前推进游戏流程,但是却很难执行倒退、向前跳跃等操作。举个场景,假如玩家A在第10帧点击攻击按钮击杀了一个AI并回复了5点生命值,第20帧点击武器制作按钮制作了一把新的武器但是同时由于被敌人击杀而掉落。

如果回放时想从第50帧跳回到第5帧的画面,那么就需要把玩家A复活,新创建的武器删掉,扣掉恢复的生命并复活AI。按照上述的第二种方案我们在只记录玩家的输入信息【5帧:攻击按钮 20帧:制作按钮】的情况下,几乎不可能顺利还原所有逻辑。根本的原因是,游戏很容易根据当前的场景和玩家输入推算出下一帧的结果,却很难根据当前一帧的结果和玩家输入推算出上一帧的游戏状态。

除此之外,我们需要保证任何一个操作都必须有一个回滚的逻辑并且不同播放端回滚后的结果是严格一致的的,这些都都远远增大了跳跃播放的难度。

因此,我们可以考虑第三种方案,定时记录玩家以及游戏世界的状态信息(或者说游戏快照)。所谓的状态信息就是某一时刻的对象身上附带的状态信息,比如玩家的生命值、移动位置等。如果我有了每一帧玩家的坐标信息,我就可以完美的处理播放、快进、跳跃等逻辑,但很明显这样要记录的数据要多很多。

总的来说,回放的本质是记录游戏的过程信息,画面是最终的表现效果。为了更好的利用游戏程序本身提供渲染功能和逻辑计算功能,同时从性能、数据量、自由度等多角度考虑,我们通常会根据游戏的类型来选择第二种或者第三种方案来实现游戏内部的回放系统。

通过上面的描述,我们很容易发现,回放系统的实现逻辑与网络同步非常相似。从原理上来讲,我们完全可以认为网络同步是实现回放系统的技术基础,上面第二种方案对应的就是网络同步中的“帧同步(LockStep)”技术,第三种方案对应就是网络同步中的“状态同步”技术。

虽然大家常把网络同步可以简单分为帧同步和状态同步,但实际上这两个概念是国内开发者不断摸索和自创的名词,并非严格指某种固定的算法,他们有很多变种,甚至可以结合到一起去使用。

在如今的游戏中,状态同步是比较流行的实现方式,也可以比较好支持回放的各种功能(比如吃鸡、守望、彩六等)。但是如果频繁的录制整个世界的快照会导致消耗非常大,所以通常会采用定时录制快照+持续录制Delta的方式进行处理,简单来说就是每隔一段时间录制一个存档点(称为Checkpoint),每个存档点之间持续的录制Delta数据(变化的状态信息),每次加载回放的时候都先找到合适的存档点,然后再通过读取中间的Delta数据快进过去。

Unreal的回放系统就是按照上面的方式实现的,可以比较好的支持快进、跳转、暂停等大部分回放功能,我会在下一篇文章中详细的分析虚幻引擎回放系统的实现原理,尽请期待!