最终幻想7重制版攻略图文版（最终幻想7最强装备搭配）

更新：2022-07-03 09:57:59编辑：李慧归类：资讯

随着游戏市场的成熟，玩家们对游戏品质的要求越来越高，因此在发布之初就解决大量影响用户体验的问题是至关重要的。过去几年，因为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。