
游戏后端深度解析 – 《真人快打X》和《 injustice 2》

从动态延迟到固定延迟: 从可变的5到20帧输入延迟切换到固定的3帧延迟是核心玩家体验的“胜利”。因为在格斗游戏中,确保可预测性与原始响应能力同样重要。
回滚性能是乘法的: 应用于模拟帧的每项优化相对于仅渲染帧的效果可以提高多达8倍,因此需要彻底重新思考性能预算。
确定性使一切成为可能: 完全的比特确定性不仅仅是正确性要求。正如斯泰隆所说,这使得离线去同步调试、比赛回放和整个回滚模型成为可能。
基准测试应针对现实,而非最坏情况: NetherRealm花费了数月时间优化几乎从未在实践中发生的场景;真实的Beta遥测和对人类输入节奏的理解完全修正了目标。
粒子和去同步需要专用系统: 对非确定性粒子效果的简单重新模拟在大规模情况下会产生损坏的视觉效果,而回滚引起的去同步需要一流的工具来快速捕捉和修复。
迈克尔·斯塔隆(Michael Stallone),现任 NetherRealm Studios 技术总监,曾担任引擎团队的首席软件工程师,发表了一个 2017年 GDC 的演讲,详细说明了 NetherRealm 如何在大约七到八个人年的工程努力中,将 真人快打 X 和 正义联盟 2 的网络模型从锁步转为回滚,并在一个实时补丁中实施(对每种技术的解释在这里)。
间接地,这突显了任何游戏工作室,无论大小,都可以应用于其多人游戏以改善在线架构和玩家体验的最佳实践。让我们回到开始。
从不可预测到固定:回滚的玩家体验案例
NetherRealm 转变的原因不仅仅是技术上的。因为玩家不满意。
在锁步下,输入延迟是动态的。根据任何给定时刻的网络状况,它在 5 到 20 帧之间波动。对于像 真人快打 这样的格斗游戏来说,这是一个严重的问题。玩家以特定的按键节奏执行连击,并期望每次都能以相同的方式工作。当延迟在战斗中途发生变化时,肌肉记忆停止工作。节奏被打破。
关键是,这影响了对于游戏开发者的反馈循环,玩家并没有将此描述为“高延迟”,他们只是描述游戏感觉不对。
转向回滚提供了三帧固定的输入延迟,支持最多十帧的网络延迟(333 毫秒的往返时间),然后游戏暂停。
可预测性,而不仅仅是低延迟,是格斗游戏玩家所需要的。固定的 5 帧延迟每次都胜过动态的 3 到 15 帧延迟。
回滚的真正成本是乘法的
在回滚之前,NetherRealm 每帧的闲置时间为 9 到 10 毫秒。在最初的回滚实施之后,这个数字跃升到 30 毫秒。几乎是他们 16.66 毫秒预算的两倍。控制台世代的跳跃使他们在 CPU 资源的使用上有了大量的余地,而他们不得不为此付出代价。
成本之所以如此高,是由于结构性原因。在回滚系统中,每个模拟帧都运行与呈现帧相同的游戏逻辑,只是活动的系统更少。
在所有八个模拟帧中优化某项内容,你将获得高达 8 倍的节省。仅优化呈现帧,你将获得一帧的节省。整个性能思维必须朝模拟时钟转变。
这种乘法压力在更广泛的时钟速度背景下也值得考虑。例如,从 20 Hz 移动到 60 Hz,会减少输入延迟,但也会使每秒的模拟周期翻倍,这直接增加了服务器 CPU 使用率和网络出口成本。
在理想的时钟速度和成本效益之间可能存在一个中间地带,正确的答案将取决于您的游戏对延迟的敏感程度和基础设施预算的大小。NetherRealm 的团队开始时是 30 毫秒,通过严格的分层优化达到了可交付的 13 毫秒空闲时间……这花费了相当多的人年。
确定性作为基础
NetherRealm 回滚模型中的一切都依赖于一件事:游戏在两台机器上每次都完全一样。
绝大多数 真人快打 X 是逐位确定的。每个浮点操作在每台机器上的顺序都相同。成千上万的栅栏检查在时钟的不同点验证两个客户端是否同步。
任何偏差都是失步,这都是有意而为的。因为如果你能保证确定性,很多事情就变得可能:你可以回滚,你可以为了调试而离线重放比赛,你可以用一个开发工具包重现失步,你可以在问题到达玩家之前检测到它们。
确定性并不光彩。但它是游戏体验中一切的基础。
序列化是支柱
“序列化是这一切的支柱,”斯塔隆在谈话初期说道,而整个实施也证实了这一点。
回滚框架是一个环形缓冲区,大小为回滚窗口:每帧一个条目,七个条目对应七个回滚帧。
每个包含可变状态的对象都需要能够保存和恢复。
在回滚边界上创建和销毁对象尤其棘手(如果处理不当,你最终会不断创建和销毁对象)。
NetherRealm 通过一种称为“可重建”的系统解决了这个问题:基本上,它是对对象和其上下文进行哈希处理,并且如果哈希在通过创建边界时匹配,则重用现有对象。没有重建,没有再模拟。对于声音和粒子尤其有价值,因为它们是非确定的,如果你销毁、重新创建并重新模拟它们,会产生不同的结果。
在恢复方面,工作并行化将成本从单线程的 2.7 毫秒降低到 1.3 毫秒,处理的数据量翻倍。
实际教训是:避免对可变资源的共享所有权,偏好用于序列化的唯一指针,并倾向于使用内存复制和缓冲区交换,而不是动态指针修复。
仅在序列化基础设施上的投资约为一到两个人年。
粒子系统需要专门的策略
粒子系统是性能尖峰的最大来源。天真的方法(即在每个模拟帧上重新模拟每个粒子)是非常昂贵的。并且它往往不会产生正确的结果,因为许多粒子模拟是非确定的:重新模拟八次,你将获得八种不同的结果。
为了解决这个问题,NetherRealm 建立了一个四种模式的重新模拟系统。
大多数粒子在预测模式下运行:在确认帧和呈现帧上各模拟一次。这在不在每个中间帧上运行的情况下产生了可预测的播放。例如,100 MB 的运行时缓存意味着粒子在运行时无需生成。
“更深层”的解决方案是“预测粒子重新模拟系统(PPRS)”,它以故意松散的约束哈希粒子状态。基本上不断询问:“玩家大致处于同一位置吗?他们在游戏脚本中做了大致相同的事情吗?如果是,完全重用缓存的粒子对象。不要模拟它,不要序列化它。”
正如斯塔隆所提到的,“那个 PPRS 的东西确实救了我们的命。”
PPRS 是一个超出粒子的有用模板。任何不需要完全正确的系统都是一个候选者:松散的哈希加上轻量级的序列化,可以让你在没有完全再模拟成本的情况下满足“足够接近”。条件是坚定的:你不能对游戏中依赖于正确性的任何事物这样做,只能用于视觉效果和音频。
基准测试错误的事物和人类因素
几个月以来,NetherRealm 在每一帧触发的七帧回滚的场景对性能进行测量。这在理论上是可能的。然而在现实生活中几乎从未发生过。
人类按键节奏大约是每秒六次,而不是 60 次。回滚七帧的次数仅限于网络差的情况,并且只有在对手在那个精确时刻按下按钮时。“事实证明,这种情况非常罕见,”斯塔隆指出。质量保证团队在游戏中测试反馈并告诉工程团队它很好……即便团队相信他们的性能数据是有缺陷的。
他们的基准测试是错误的。现实世界测试纠正了这一点。
这指向了关于延迟理解的更广泛的内容。大多数对话集中在网络上,但网络只是图景的一部分。此 回滚网络代码指南 中引用的研究分解了延迟的实际来源:约 55% 归因于玩家自身(人类反应时间、输入处理、显示延迟),而仅约 31% 来自网络。仅针对最坏情况的网络场景进行优化错过了对感知延迟的更大贡献者。
也就是说,来自网络的 31% 是你可以通过基础设施最直接控制的部分。Aether Studios 通过在 Rivals of Aether 2 中将游戏服务器尽可能靠近玩家,直接应对了这一点,默认情况下将网络延迟保持在最低。结果是可以测量的强大在线体验。正如 Edgegap 对 Rivals of Aether 2 如何构建其如今被 EVO 认可的在线体验 的分析详细描述的那样。通过智能基础设施减少 31%,然后将设计精力集中在 55% 上。
推测保存减少 30% 的回滚次数
仅保存确认帧是最低可行的方法。
虽然这样是正确的,因为你总是可以回滚到确认的状态,斯塔隆指出这并不是最优的。因为你没有保存中间帧,每当你的推测预测远程输入成功时,你将会回滚得比必要的更远。
NetherRealm 添加了一个推测保存系统,可以在 CPU 预算允许的情况下有条件地保存额外的帧。即保存确认帧(强制性)。然后,如果有预算,偏向于确认帧保存模拟中点,进一步向后保存你的保存点,越有可能远程输入已经被确认。最后,在帧结束时保存,如果你仍然有时间。
由于阈值可以在没有补丁的情况下进行调整,因此允许在实时环境中调优。结果是总回滚次数减少了 30%,主要是通过消除缓冲区耗尽的回滚:确认帧即将超出环形缓冲区的情况,强制进行最大深度回滚,即便没有输入实际上发生偏差。
教训是,正确性和性能优化并不是同一个目标。最小正确解决方案和良好优化的方案是非常不同的实现。
失步工具是一项一流关注
转向回滚使游戏变得更加复杂,而这种复杂性带来了更多的失步。
具体而言,不在模拟帧上运行程序系统是一个主要原因,因为游戏代码悄悄依赖于 IK、物理和其他仅在每个时间点运行一次的程序输出。
NetherRealm 的回应是将失步工具构建到开发的框架中。
由于游戏是完全确定的,任何比赛都可以仅凭记录的手柄输入和相同的网络节奏离线重播,每次产生完全相同的比赛。开发者可以注入新的失步栅栏,按照需要重播比赛,并使用一个工具包准确找出根本原因。“这是完全的救命符,”斯塔隆说。无需两个机器设置,无需现场会议即可重现问题。
他们添加了一个实用程序,让任何开发者通过单击从过去一天或一周中提取所有实时失步。夜间浸泡测试在大楼中的每个工具包上进行了在线比赛,失步被记录到内部服务器。在问题到达玩家之前,很多问题便被捕获。最终的失步率降至 1.1% 以下,斯塔隆表示他相当自信真实数据低于 0.01%。
—
这篇文章基于并引用了迈克尔·斯塔隆的原始 GDC 演讲,发布于 YouTube。原内容的所有权利均属于其各自所有者。
书写者
Edgegap团队









