SE首席AI工程师分享：FF7重制版是怎么做自动QA的？

【GameLook专稿，未经授权不得转载】

GameLook报道/随着游戏市场的成熟，玩家们对游戏品质的要求越来越高，因此在发布之初就解决大量影响用户体验的问题是至关重要的。过去几年，因为bug而受到打击的热门游戏不胜枚举，比如《无人深空》、《赛博朋克2077》，都是因为发布之后大量的问题导致了滑铁卢。

当然，游戏研发本身就是困难的，在时间和资金有限的前提下，想要对大量内容做QA显然非常耗时耗力。那么，有没有更好的方式节约QA成本呢？

在此前的GDC演讲中，Square Enix首席AI工程师Fabien Gravot分享了《最终幻想7重制版（Final Fantasy VII Remake）》的自动QA回放系统，并表示可以用于大量的新项目。

以下是GameLook听译的全部内容：

Fabien Gravot：

我是Square Enix首席AI工程师Fabien Gravot，今天的题目是“最终幻想7重制版：自动QA和未来的工具”，但在开始之前，需要强调的是，我们提到的所有东西都是在《最终幻想7重制版》研发过程的最后才做出来的，但不同的团队组合让我们持续对这些工具优化，未来也可以用于其他项目。

首先，我想谈谈QA项目部分，主要聚焦于回放系统，我们使用了什么类型的数据和工作流程、结果等，随后还会提及一些探索的方式，并总结哪些是有效的。

不过，第一个要说的是，游戏研发在不断升级，更多的内容、更多互动，不同玩法类型的创作者自由，而且游戏发布之后不再是结束，你还需要在随后推出持续的内容、服务和支持。这一切都让游戏QA成本越来越高，你需要对游戏内容不断地测试。

我们能做点什么来提升呢？一些报告工具可以帮你节约时间和人力，比如自动bug数据报告、自动崩溃或者维护报告，我们可以遥测数据报告，来确定内容质量是否达到了要求。

我们还可以做一些工具对游戏自动回放或者体验，比如脚本、回放或者探索等。

自动回放工具

先来说回放系统，即使是这一项，我们也可以分为两大类，一种是在不改变游戏代码的情况下，你如何控制游戏回放，你可以控制时间或者截屏，这一种方式比较方便的是，你可以在最终版本的时候放到游戏里测试，因此它往往用在研发结束的时候。

你还可以在游戏引擎方面做一些改变，不过可能仅限于用户可以做的一些事，尤其是不要影响到游戏运行状态，你希望对游戏操作模拟器进行控制，或许还会测试更多的可能。你是在测试阶段使用这些工具，不过这些改变往往不会是具有决定性的，你可能会在第一个可玩版本之后就是用它，这也是我们今天聚焦的内容。

第一个回放案例，我首先会用game pad录制游戏玩法视频，包括在新手教程阶段的战斗输入。

然后我们暂停，并对其回放，我们的测试工具可以对所有的行动选择进行尝试，以便测试所有的功能都可用。

对于回放系统，我们使用了一个启动器，随后开启了两个处理过程，一个是自动QA服务器，主要用于监控和控制游戏，第二个是watchdog，它可以处理平台独立代码，并开始和监控游戏运行。

Watchdog负责开始游戏处理过程，包括录制视频、音频等，一旦游戏开始，它就会向watchdog发送信息，而且游戏还会向自动QA服务器发送整体游戏状态，后者会向游戏发送一些请求。

我们还会加入一些UI指令，比如停止等。在游戏里，我们可以分为两个部分，一个是可以对游戏引擎带来影响的通信和默认行为，另一方面则是具体的游戏QA代码，以确定游戏状态机，接下来我们看游戏案例。

在《最终幻想7重制版》中，我们增加了多个Bots，（下图）左侧是一些衡量角色在什么地方的bot，比如你到底是在场景中，还是带着装备，但基本上来说，都是通过bot来控制走向。

中间的可能是最复杂的一个，它将bot混合到战斗场景中，以确定带来你想要的战斗技巧和效果，如果需要的话可以回放。最后是一些小游戏，我们增加了专门的按钮，只是为了精准获取回放数据。

我们再来说说通用游戏状态（generic game state）以及我们使用了什么数据，这个状态的数据包括：我们在哪里（位置、关卡id，以及速度）、什么时间（游戏里的时间、UTC时间、真实时间和帧数），随后是一些你想要知道的游戏内活动，比如按了哪些键、有什么输入，你还要知道为什么要这么做，主要是通过了解游戏状态堆栈实现。

这里我们说的不是游戏状态而是游戏状态堆栈，为什么？因为我们可以收集回放数据并开启跟随模式，比如当你离NPC的任务特别远，就可能会停止奔跑，这时候你可能会开始一场战斗，随着新手教程的结束，你可以追踪后续的战斗，通过游戏状态来看在什么地方遇到的问题。

对于状态，我们是通过id的方式进行标记，比如类型或者游戏id，当我们做回放的时候可以存储用户数据，还可以存储同步flag以及timeout override。我们不会详细说所有的同步flag，但我们可以了解一些。

假设你有一个游戏状态并想要达到这个阶段，你在回放数据，到了应该开始游戏状态的时候或许它没有出现，所以，如果你发现了这样的non relocatable flag，就意味着你需要在这些位置增加它，以便开始游戏状态。

你可以将non relocatable start增加到这些位置，也可以给出等待指令，如果开启了游戏状态，则启动End Time out，你必须在这之前完成回放。

接下来看relocatable flag，它和之前的很相似，但并没有在这个地方开始，因为这时候可能不是游戏状态开始的准确位置。我们可以推动更多，将所有东西放到一起，如果我们开始同步，我们就可以基于原始状态持续时间知道end time out，我们会尝试用数据代替。

这是可skippable flag的一个案例，意味着如果有新的状态开启或者新的战斗，只要它是可跳过的，我们就跳过，比如关闭新手教程菜单。随后我们开始startable同步，这些主要用于互动。

我们还可以有Optional flag，比如在回放的时候，如果遇到了可选状态，就可以直接跳过它们。

现在我们讲讲移动部分，但我们并没有一个导航网格，实际上我们在回放期间打造了一个3D方格地图，我们既可以使用录制的地图也可以使用回放地图。当动态与指令不匹配的时候，我们会试图检测墙壁，比如我们的目标是红线前面的方格，但最终却走到了另一边。如果迷失方向，可以试着做寻路，我们还会用简单的启发来拓展地图，用来帮助玩家寻路。

我们可以发现很多东西可以在项目之间共享，虽然不是具体的代码，但只要你使用同一个游戏引擎，这些工具都是通用的。

接下来我们说说工作流，你会让某人录制屏幕以获得回放数据，还可以用Game Build系统触发或Jenkins请求Build machine或者让Test Machine测试游戏，通过发回的测试结果做测试监控，但我们还会向系统发送一些执令做bug归类，有些会直接发送给QA团队或者游戏团队，比如游戏崩溃或者维护，还有些结果会发送给自动QA专家，比如有些回放失败可能是工具的问题，我们需要对它进行分析和debug。

回放系统的优势是什么？我们可以通过它找到一些罕见的bug，比如和游戏逻辑、多线程等相关的bug，有些甚至发生的概率不足0.3%，通过这个系统，我们可以每天测试300次，还可以测试比较大的代码改动导致的问题。我们可以测试帧率交叉的游戏环节，我们还可以全天候测试。

它唯一的不足在于，只是测试录制的方向，如果你想要做更完整的测试，可能需要录制很多回放。

自动探索系统

接下来我们看一些探索案例，在这个案例中，我们尝试通过一个服务期内两个游戏行为的方式做分布式探索，测试目标是找到没有去过的地方，探索整个地图。

通过探索方式，我们可以找到一些不经意加入的bug，我们可以捕捉性能分析，比如FPS游戏，还可以检测关卡冲突。不过它的问题在于，对于复杂的游戏，探索的方式无法检测出所有完成关卡方式可能造成的问题。

所以我们的方式就是将两者混合起来，如动图所示，我们试图到地图的每一个角落，第一次探索是随机的，随后我们回通过标记的方式探索离角色最近的未被探索区域（蓝色），通过两者的结合，我们可以找到地图中的所有漏洞，随后就开始探索新区域的地图。

一旦遇到了事件弹出，我们就可以用回放数据同步，然后回到探索任务，直到任务结束或者战斗结束，再次回到回放数据，随后会根据结果决定接下来要探索的地图区域是哪里。

我们可以对回访数据进行遥测，比如这是14个重叠的回放数据。

总结

总的来说，我们的工具优势在于它可以做大量的自动重复测试，可以在多个项目之间共享研发成本，比如很多工具可以做成通用的，存储大量数据甚至用户数据管理关卡的变化，这样它就不会仅限于某一个游戏使用。

不过，它的劣势在于，无法做qualitative QA，比如一些图形问题，但我们可以将图形影像或者视频交给专业的人士去解决。

我们未来想做的是，增加更多的视频、截屏用于QA测试，我们还希望将它拓展到其他游戏行为当中，比如我们的菜单，或许还可以应用到小游戏上，我们还想要一些工具来找到关卡冲突当中比较大的变化，以上就是今天分享的所有内容。