nba回放系统为什么那么好(游戏中的回放系统是如何实现的？)

本文首发“游戏开发那些事”

作者：Jerish

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

从实现技术角度来讲，下面的这些功能本质上都属于回放的一部分：

• 精彩瞬间展示: FIFA / 实况足球 / NBA2K / 守望先锋 / 极限竞速：地平线 / 跑跑卡丁车
• 死亡回放: 守望先锋 / 彩虹六号 / 使命召唤 / CODM
• 全局比赛录制、下载、播放: 守望先锋 / CSGO / Dota / LOL / 魔兽争霸 / 星际争霸 / 红色警戒 / 坦克世界 / 绝地求生 / 王者荣耀
• 观战（常用于非实时观战）: CSGo / 堡垒之夜 / Dota
• 时光倒流：Braid / 极限竞速：地平线

彩虹6号中的击杀回放

守望先锋中的完整比赛回放

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

回放系统的录制方式

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

Dota录制文件大小，打开后一般是乱码

通常来说有三种方式，我们会逐一的展开来讲：

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

优点：

• 播放简单，随便找个视频播放器即可
• 方便分享到社交平台
• 完美支持倒放和跳跃进度

缺点：

• 占用大量的存储空间
• 录制性能开销较大
• 加载速度慢，很难实时地用于游戏中
• 不够灵活，视角受限，无法定制特殊功能

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

实况足球比赛回放（可以任意调整视角）

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

录制帧输入，回放时按照时间触发这些指令信息即可

优点：

• 录制数据极小，存储空间友好，网络发送便捷
• 录制性能开销几乎可以忽略
• 对于帧同步的游戏，额外开发工作较少
• 播放视角可以随意调整和定制

缺点：

• 回放消耗性能很大，等价于重新跑游戏
• 进度跳跃比较困难、倒放很困难
• 只能在游戏内播放
• 要严格保证游戏内逻辑计算结果的一致性

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

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

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

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

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

Dota中的回放，录制状态信息

优点：

• 录制数据量中等，可以根据具体情况调整和优化
• 录制性能开销较少
• 回放时性能消耗尚可
• 可以支持跳跃、倒放等常见功能
• 不用担心计算一致性问题（浮点数精度、随机数等）
• 播放视角可以随意调整和定制

缺点：

• 实现逻辑相对复杂
• 只能在游戏内播放
• 录制数据量和性能上不如第二种方案

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

回放系统与网络同步

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

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

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

Checkpoint Delta方案示意图

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

UE中的回放录制命令