战神新游戏普通难度，战神应该先玩哪一作

来源：头条浏览：0 2023-01-01 06:04:01

对于大多数游戏来说，测试是必要的一环，玩上的调整、调试、体验上的优化等，都可以在接触到更多用户之前让产品尽可能出色。但是正确的测试方法可以获得有价值的信息并帮助游戏迭代，错误的方法可能会得到迭代的、无用的反馈，浪费团队的人力和时间。那么，如何测试是正确的呢？在此前的GDC市场占有率中，索尼圣莫尼卡工作室的助理制片人Ed Dearien分享了这款游戏的测试颠覆过程，他表示，没有测试就没有现在的《战神》。以下是GameLook听力的完整内容：

战神新游戏普通难度，战神应该先玩哪一作

Ed Dearien :简单来说，没有测试，游戏就不是现在这个样子，测试给我们的游戏带来了很大的好处。我希望分享结束的时候看到这些。通过共享《战神》的测试流程，我们想给你们一些启发。或者，也可以直接使用我们的测试方法。或者，你可以告诉我像《战神》这样的大游戏测试需要什么。另外，这里所说的测试是外部测试。你能做的测试类型有内部审核、焦点小组、市场调查等多种，但这些都不是我们今天要说的。我今天说的测试是让别人体验你的游戏，然后他们反馈给你。

今天出席的工作室成员还有圣莫妮卡工作室的播放总监Jeet Shroff和Kevin Keeker。 Jeet在《战神》测试中从创意负责人的角度接受了指导。 Kevin是SIE的首席用户体验研究者，目前专注于PS独家游戏。他负责用户调查策略，获取了大量数据，帮我们应对了所有的0755-。我是Ed Dearien，在圣莫妮卡工作室做助理制片人。我的主要职责是搭建所有外部测试，也就是我们团队和Kevin团队之间的桥梁。需要注意的是，这里的内容很有戏剧性，如果不想看的话可以提前离开。为什么要推翻以前的测试过程？

在开始之前，首先再想想什么是背景，测试的问题吧。一切都从这张图开始，代表着《战神》的新愿景。虽然和终端游戏的版本不太一样，但是创意总监Cory Barlog展示了想要实现的效果。这款游戏的愿景与过去的战神系列不同，它采取了更娱乐的方式，专注于奎爷的关系链。在这些愿景中，最中心的是给整个系列带来角色成长的想法。以角色为中心成长有剧本、战斗、探索三种方法。值得强调的是，这款游戏既不是重置，也不是翻拍，而是全新想象的产品，是奎爷故事的延续，换句话说，这是玩家们几十年熟悉的同一个quist。这很重要是因为有人玩过以前的游戏，在玩那个游戏时有来自以前游戏的期待。因此，工作室在开发新的《战神》时面临着许多挑战。

第一个挑战是全新的愿景，新的武器、设定加入了北欧神话，男孩也增加了。另外，因为这不是新的IP，所以知道新玩家和老玩家之间的期待有差异。我们也知道这是一个很难研发的游戏，因为它是一个具有高质量标准的大游戏项目。这是工作室在PS4平台上的第一个游戏，所以你需要熟悉新的技术和设备。

由于新游戏的目标与上一款游戏大不相同，在策划和创意原型阶段需要付出很多努力，所有这些挑战在游戏开发初期都变得困难，而且这些东西之间似乎一直存在着冲突。结果，我们的第一个工作就是把这些不同的部分分开制作，所以从前期制作到阿尔法测试需要很长时间和进度，给队伍带来了很大的挫败感，更重要的是，这还是战神游戏吗？

所以在2016年阿尔法测试之前，我们都有这些负担。这是我们第一次从一开始就体验完整的游戏。从一开始我就知道并不是所有的功能都完全内置于最终的游戏版本中，但这是我们作为团队第一次完全体验了自己开发的游戏。那么结果如何呢？说实话，当时的游戏版本没意思。

大多数游戏的阿尔法都会遇到这种情况，但游戏中有很多让玩家感到沮丧的时刻。此外，很容易就发现有很多事情需要重复。例如，由于游戏的重要功能还没有实现，当时的版本有很多必须填补的空白。为了让巨大的解谜游戏制作出很多片段也不会成为一体，我们需要加速。到了阿尔法阶段，我们剩下的时间不多了，这个阶段的游戏状态会告诉我们应该加速制作。然而，问题不仅如此。我们甚至开始怀疑我们是否有能力承受这个项目的研发。当时显然不够，所以我很清楚必须重新考虑我们的研发方法。这个时候，我们开始看到了现在的玩法测试的进展。我们一直在做测试，工作室也一直有内部测试，但我知道这些测试没那么有效率，有问题。

首先，这些测试不会告诉我们任何新的信息。有时我觉得自己像在看沙漠里的沙子。得到的反馈非常表面，但往往只是用不同的方法解释已经存在的问题。人们常说很难控制游戏里的摄像头，或者很难追踪敌人，但是在我们得到这些问题之后，就无法得到其他的信息。第二个问题是，我们没有全球进程。就像我刚才说的，队伍在不断地测试，但是不同的部分之间是隔绝的，从整个游戏的角度来看没有东西。例如，我们的反馈有些是水平的，有些是战斗的，但没有把它们融合在一起。因此，我们得到了很多相反的反馈，很难决定下一步该怎么做。

这是一个更大的游戏，与我们一直以来习惯的项目不同。这个新游戏有新的目标，它有更复杂更深刻的剧情，所以以前测试游戏的方法行不通。

我开始怀疑整个测试，团队里的疑问越来越多。我们为什么要做测试？我们总是得到同样的反馈。这是浪费时间。

同时，我们的姐妹工作室Guerrilla Games正好完成了《战神》的研发。他们听说我们要推翻测试过程，提出了一些建议。于是我们给他们打电话，说在交流的过程中，他们一开始也和我们一样遇到了这些测试问题，说明他们如何建立高效的测试过程，他们又遇到了一个问题，那就是在测试的时候要付出多少努力这次通话给了我们灵感，马上联系了Kevin开始工作。这时，我们意识到我们大大低估了Kevin团队拥有的可能性。但并不是所有的团队都有如此强大的用户调查团队的支持，所以今天我的分享主要集中在更多工作室通用的概念上。新的测试流程

所以我们重新调整了测试流程，首先弄清楚了为什么要测试，测试的目标是什么，然后进入了不同类型的测试，分析了得到的数据。首先问这个问题。为什么要进行游戏测试？我们发现的最主要目的是通过测试验证我们的愿景是如何实现的。应该注意的是，我说的不是验证游戏的愿景。游戏的愿景已经确定了，所以我们要做的就是通过反馈了解我们的愿景是如何实现的。

必须确保能够获得可行的数据。如上所述，很难获得问题以外的信息。最后，我们通过游戏测试的目的是让游戏更有趣，但并不是在测试过程中询问玩家这个游戏是否有趣。对我们来说更重要的是，通过了解反馈数据和做出相应的提高，让游戏变得更好。这样想对我们来说很重要。这是因为测试的基调决定了并不告诉开发者他们是对是错。我们测试的目的是收集反馈数据，并由研发团队决定如何利用这些数据。因此，我们必须确保获得研发团队做出最佳决策所需的数据。

因此，整个过程从确定测试目标开始。需要确保这些目标是明确和可衡量的。因为在此之前，我们会询问人们UI是否足够直观，然后停止进一步的理解。但是，UI是否只是一个很好的起点，我们发现我们必须真正聚焦于反馈。例如，询问菜单流程、人们对初学者教程的理解等更详细的问题。接着，我意识到这需要做很多工作，并开始进行游戏测试，作为游戏功能的一部分。这意味着，和其他功能一样，有赞助商，必须有人努力。为此，组建了由创意总监Cory Barlog领导的测试突击队。对我们来说，重要的是领导团队必须是整个过程的核心。在继续测试的过程中，会出现问题，因此需要更多的部门参与才能进行更改。最终，需要一种衡量测试是否成功的方法来确定在游戏中所做的更改是否有效。为此，我们每次都做同样的测试。一次测试不可能解决所有的问题，所以我们利用这些测试来积累和前进游戏。因此，我们在每次测试中得到了一些重要的反馈，使下一个测试目标更加明确。确定测试目标很重要。你需要知道你想通过测试来实现。

接下来，确认测试的频率。这是我们最初提议的测试日历。我在3月做的日历上，列出了到11月为止的测试日程。蓝色是可用性测试，棕色黄色是比较大的游戏测试。稍后具体说明。像很多研发日历一样，一旦开始，这些计划会发生很多变化，所以虽然这不是我们实际使用的测试日程，但还是值得分享一些心得的。首先考试永远都有下一个。让团队有自信是很重要的。让别人觉得测试可靠，意味着一致性很重要。如果继续取消或更改测试时间，测试结果就不那么可靠了，所以从一开始就决定测试频率，尽力而为。

对我们来说，这意味着需要承担风险，平衡新功能。我们的游戏还在开发中，测试的迭代是其中的一部分，所以让领导团队理解这个想法很重要。我们有时会要求对游戏进行比较大的改变。这对我们来说是必要的。因为每次的测试都很重要。最后，你需要保证每次测试都能给游戏带来些许进步。每次测试都是基于上次。也就是说，使用了不同类型的测试。我们从整体上看问题，找出痛点，然后深入理解问题的原因。例如，你不可能通过一次测试就解决照相机的问题。我们一直在不断调整，所以我们需要不断确保取得有意义的进展。接下来，我们将看一下这两种测试类型都使用了哪些测试类型，以及它们各自带来了什么样的测试反馈。我们主要使用两种测试。一个是无引导通关( unguided playthrough )和另一个是可用性测试，他们有非常具体的测试目标。从战略上利用这些测试，帮助我们找到了中心问题。首先从最初的类型开始说。

无诱导通关测试的主要目的是找到痛点。那就从整体的游戏出发，测试目标的达成度。总体来说，我们可以知道人们在玩游戏的时候在哪里遇到了最多的问题，在哪里需要投入更多的精力。这种测试的目的是尽量减少与测试者的交互，使其看起来像在自己家里玩游戏一样自然。也就是说，除非他们求助，否则我们不会介入测试。或者，我知道测试员遇到了游戏的bug和问题。这样的测试有助于验证整个游戏的一部分，包括测量整体节奏、理解剧本和平衡难度。这些问题有助于从更高的层面理解问题出在哪里。另一个是可用性测试。在之前的测试中发现了一些痛点，在这样的测试中对其进行了挖掘。其目的是找出这些痛点的原因，并迅速找到适合您的解决方案。因为在整体测试中，会遇到很多噪音，而且往往会与其他游戏系统相关联，带来非常一般的反馈。

例如，有人可能会说战斗并不愉快，但可用性测试表明，真正的问题在于摄像机的灵敏度。因此，像我们这样的大游戏需要一种机制来过滤这些无用的信息，从而找到核心问题的所在。这些测试规模比较小，时间短。此时，我们的用户调查员会和测试者一起发现问题。我们鼓励试验人员和调查人员进行开放式对话。有问题的反馈是建设性的，但你会知道这些反馈正在朝着正确的方向发展。这些功能是我们进行的可用性测试，可以看出这些是非常核心的功能。这是我们的意图。我们的时间有限，需要确保这些功能总是以正确的方式重复。这带来了以下问题。如何从测试反馈中提取有意义的数据？

我们的测试将反馈分为两类，因为主要取决于如何提出这些问题。一个是来自用户的自发反馈，另一个是我们具体询问的信息。我们将前者分类为非直接反馈。 Kevin把这个称为红色按钮。为什么这么说呢，因为玩家们从游戏测试中的体验中不断地给予反馈。这个信息随时会带来反馈，通常会让研发团队发现需要深入理解的具体问题。直接反馈是指我们通常通过调查形式获得的结果，所以我们总是以非直接反馈开始。为什么这么说，是因为对游戏系统提出的问题不想偏离玩家的体验。

这些是比较具体的反馈，可以想象我们收到了很多用户的反馈。但是，Kevin和他的团队根据这些问题分为加法和减法。加法意味着强化，减法意味着减少。这样可以看到重要的问题，而不会使问题过度复杂化。

这是我们非直接反馈收集的重要问题，例如在第一行，四位被调查者告诉我们Valkyries太难了。我知道这是意外的。这个列表都是用户通过自己的体验反馈的。

接下来我们来看看直接的反馈。可以看出测试者最多的问题体现在敌人的难易度上。 40%的人提到了这个问题。然后让一些玩家进行更多的测试，以确定问题出在哪里。通过将问题简化为直接和非直接的反馈，建立了共识。因为给我们看了整个游戏的数据，所以如果在团队里的话，开发的功能就是这个问题列表之一。通过这个展示方法，可以从整体上看问题，清楚地知道应该把注意力放在哪里。随着想知道的事情开始变化，应该知道的数据也不同。因此，随着游戏的不断优化，这些数据表也在不断地变化和重复。非常重要的是，每个研发部门都需要不同的数据类型。等级企划可能想看等级分解的相关数据，战斗企划可能想看玩家数据，所以需要和不同的队伍进行沟通。请确认他们需要的数据是什么。因为不同部门的人很难使用共同的数据。

那么，我们的测试流程怎么样？回顾一下之前的总结吧。确保你的测试有明确的目标，形成可靠的测试体系并继续下去，在不同类型的测试中发挥你的优势，确保你的测试反馈考虑到了整个团队的需求。但是过程和使用它的人一样重要，我们的新部分，只是试着去做。所以，我给你举几个例子。它们给我们带来了有价值的经验和教训。

当我们设计游戏时，团队喜欢用“幻想和功能”来描述它。幻想是带来的用户体验，功能是操作和照相机等更具体的游戏。了解了这些之后，我们在做测试的时候有了非常明确的目标。无向导通关测试验证了虚幻的体验。可用性测试可以验证功能性问题。

以游戏中的船为例。

用早期的游戏设计文档来说，小船是为了探索而设计的，是为了收集、听故事、体验战斗。这是设计的优先顺序。如果你玩过《地平线：零之曙光（Horizon Zero Dawn）》，你会发现实际体验和最初的设计非常接近，除了战斗以外，后者不会出现在游戏中。为什么？战神系列几乎可以随时战斗，《战神》在飞行中也可以战斗。说实话，我们在赛艇上的战斗主要是为了整体的游戏体验，赛艇的主要设计目标是让玩家探索世界，了解更多的剧情，战斗是赛艇设计中优先级最低的。但是移除这个功能是球队做出的艰难决定，战神本来就应该战斗。因此，在该决定之后，小组提出了疑问。这是因为它打破了战神系列的经典传统。

但我们还在没有船体战斗的情况下继续测试。虽然当时的剧本还没有进去，但作为整体的感觉，人们不想在坐船的时候战斗。这太晚了，太无聊了，所以他们不喜欢。船上的战斗很糟糕。我们阿尔法得到的反馈是坐船是一种糟糕的体验，所以所有这些负面反馈都与战斗有关，在我们的会议上也经常被讨论。要么把战斗加到小船上，要么直接舍弃小船这个功能。所以，我们可以归纳为两个方面。从幻想的角度来看，玩家们在游戏中乘船的场景太多了，功能的角度，他们觉得船走得太慢了，很难控制。正如我刚才所说，关于船的幻想部分(剧本)还没有参加，所以很明显船体的操作很无聊。我们必须注意不要管理关于船的幻想部分的反馈，但是我们可以解决功能性问题。于是我们问了自己。 “现在，你能做什么来提高乘船的体验？还是得等到船体剧本来？在可用性测试中能发现问题吗？于是我们就这样做了。我对小船进行了很多高质量的更新。这样就解决了游戏中许多类似的功能。最终的剧本被追加的时候，我们可以整体地看这个问题。然后，可以听到奎托斯的经典故事。关于船的故事，也有一个故事。测试刚结束，没有船坞。每次被试试图下船时，都需要我们工作人员的帮助。这需要我们进一步调试错误，所以这个体验很辛苦。所以，我们必须进行下一次测试。这对球队来说是重要的时刻。因为这是我第一次看到我们想要的船体测试体验。

第一个测试员结束两个小时的测试后，他的操作遇到了船坞的bug，我们不知道该怎么应对。因为第二个测试员没有遇到船坞的问题，所以采访了他在小船停下后的反应是什么。他说他在等奎托斯讲完他的故事。这时，我们发现小船完成了在游戏中的使命，人们可以在没有战斗的情况下享受乘船的体验。

那么，我们能从这里学到什么？

我们随时可以恢复战斗。有时也会得到直接恢复战斗的反馈。但是，在测试中，你不知道最终乘船的体验应该是什么吧。因为当时还没有完整的内容。所以，我明白了必须慎重处理反馈。特别是在计划意图还没有完全实现之前。下一个故事是最终老大

这是玩家第一次体验完整的游戏结局，我们觉得很好。但是测试者们直接告诉我们，他们不喜欢芙蕾雅最后突然变黑。我们也很惊讶。芙蕾雅本来就不是小人，遇到了这种不可能的情况，她该怎么办？我们发现玩家的态度有所分化。有的玩家同情芙蓉雅，有的玩家认为她很暴力。为此，我们问了自己。 “为什么玩家会认为芙蕾雅是暴徒？我们以为玩家可能不理解她的遭遇，所以在这个场景之后不久添加了场景。我让阿特柔问了这个问题。 “你要是也出现同样的情况，会让我杀了你吗？ ”奎托斯的回答是肯定的，他说，如果不是父母，就不能真正理解这个选择。我们增加了这一节之后，发现效果非常好，玩家们不再给芙蕾雅负面反馈。我们学到了什么？

当你开启测试时，你可能会觉得一切都结束了，但你可能会突然得到意想不到的反馈，或者和你想达到的效果完全相反。每个玩游戏的人都有自己独特的角度。因此，他们会误会什么。测试告诉我们认真倾听人们的反馈。因为我们很容易直接说玩家没有get到我们想表达的内容。这可能会孤立大部分玩家。重要的是，我发现测试不仅是为了测试玩法，有时还能测试人们对剧本的理解。

你可能听不懂这张图在说什么，但我要谈谈我们的好朋友“橄榄披萨男孩”。当有人体验了你的游戏非常讨厌的时候，会发生什么？他们写了一份长长的差评清单，在所有给定的反馈中指出了痛点，在我们的测试中遇到过这样的事情。

读一下他的反馈吧。 “我厌倦了解谜。更糟糕的是，解谜的部分比动作的部分还多。当这个游戏被称为战神的时候，这是不能接受的。想想你点了肉食者披萨。送餐后，发现披萨上橄榄比肉多。我对游戏的这一部分有这样的感觉。我在玩游戏的时候想要很多动作场景。我希望披萨上有很多肉粒，但是没有。我体验了大量像铺满橄榄的肉披萨一样的谜题。谁希望自己点的肉披萨上沾满了橄榄？没有人！有谁想让奎托斯和劳拉一直在游戏中完成解谜吗？没有人！请给我更多的动作，减少愚蠢的谜题。另外，这些解谜很无聊。喂，是1998年的《战神2》吗？他们只是把20年前的地牢平台游戏带回了战神系列。 ”

所以研发团队读了这篇评论，在测试途中用披萨比喻的这个人成了团队的名人。他的反馈明确地表明，他是以前战神游戏的忠实粉丝。因此，一方面，我们发现了一件令人担忧的事情。战神系列的老粉丝不喜欢新游戏。但用大量的披萨来比喻，就明显地表达了他对战神系列的热爱，给我们新游戏的新愿景带来了挑战。

所以，我们学到了什么？首先，新游戏不会让所有人满意。我们在做战神系列的重塑项目。解开谜题和战斗一样多的游戏。这一点不会改变。有讨厌的人也没关系。而且，从其他反馈中我们发现，我们做得非常好，人们喜欢游戏的角色、设定和剧本，在玩耍方面的迭代取得了平衡。因此，接下来的心得是从战略角度看玩家的反馈。这个玩家不喜欢解谜，但喜欢解谜的用户会明确地告诉你该怎么办。但他喜欢游戏的战斗部分，所以我们聚焦于他和关于战斗的评论，发现他想说的是游戏开始的战斗节奏很慢。因此，我们决定调整战斗节奏，让喜欢战斗的玩家从一开始就找到喜欢的挑战，同时参与解谜。即使他们不喜欢解谜，这也是有价值的反馈。但是，话还没说完。收到反馈的第二天，我收到了邮件。 “吃午饭之前，应该给这个人买披萨，但是我撒了橄榄，所以我这么做了。

我们撒了很多橄榄。为了明确我们不是恶作剧，在这个口罩后面他笑得很开心。我向他保证我点了肉披萨作为午饭。

最后一个例子与游戏难度有关。我们的游戏有各种难度设置，可以随时调整难度。我们假设你开始选择通常的难度，但觉得游戏的挑战不够，随时会有更多的挑战。在没有增加难度功能的情况下，我们长期依赖普通难度来判断游戏难度是否合理，但有一次测试的时候，我们故意增加了难度。因为以前测试的大部分反馈都说太简单了。但是，我们想知道最难的天花板在哪里。所以，我们大幅提高了难度。结果，玩家的反馈太难了，我们又回来了。在下一个测试中，我们添加了难度切换功能。这让战斗企划非常兴奋。这是因为他们可以看到对更高难度的反馈是什么。我们得到了非常好的反馈，所有人都给出了满分的评价。但是我们的团队成员很喜欢困难的模式，所以他们看到玩家的反馈非常好的时候也很高兴。例如，游戏体验展示了他们的战斗技巧，据说很有成就感，但后来看了测试数据，很多玩家选择了简单的模式，所以这里面有很多故事。

我从这次测试中学到了一些东西。首先是尽快把重要的功能交到玩家手中。因为我们的游戏一开始一直被设计成可以调整难度，所以这实际上改变了我们加入游戏的方式。增加难度调整功能后，我们发现有很多用户在使用，但是很长一段时间以来，我们都是基于中难度平衡体验进行测试的。因此，根据版本的不同，无法判断各玩家的技术水平，所以据说太简单或太难了。第二个心得是，我们需要从多个方面来看待反馈。在玩家的反馈中，他们认为他们选择了高难度模式。因为评论的描述与期待的高难度反应相同，所以从游戏视频和难度设定的选择等多个角度来看评论很重要。根据这些数据构建尽可能准确的用户数据库。

最后的心得是，高难度不等于乐趣。即使玩家选择了简单的难度，也不会影响游戏的功能和体验，会给我们带来有价值的反馈。我们开始测试并不是为了怀疑游戏的目标，而是用它来看看我们对这个目标的实现有多好是一个非常重要的理念。有时候你可能会得到一些令人挫败的反馈，但通过测试你会得到有价值的信息。这些反馈需要正确的心情。不是每个人都喜欢你的游戏。这不是问题。

我们从一开始就对自己说all-in，但要做好它需要时间和努力。每次测试都可以让我们的游戏变得更好，慢慢知道哪些数据有价值，哪些数据没有价值。最后，谈几点想法。希望对你们的测试过程有帮助。每个团队的动作模式都不一样。有些东西可能对我们有帮助，但对你们不一定管用。你们必须决定哪个对自己有帮助。我们认为团队成员参加很重要。我们把所有的测试直播给整个研发团队，谁都能看到。这在很多方面给我们带来帮助，让人们提出很多问题。另外，团队还可以自己评估发生了什么，并向上司讲述其想法。第二，测试的效果可以通过领导层的参与变得更好。 Cory参与了整个测试过程，我相信这一点。可以听到测试结果和所有人对下一次测试的想法。所有这些都是从领导者重视并参加测试开始的。第三，与QA团队的关系很重要。因为在测试之前可能会出现问题，添加会破坏其他功能的东西。这都是游戏开发的一部分，但QA的观点很重要。但是，同样重要的是降低用户调查的门槛。重要的是我们要让调查者掌握最新的信息。他们对游戏和系统了解得越多，他们就越能对你有帮助，所以分享今天重要的信息是继续测试。考试面临着痛苦的状况。我们也确实为了应对反馈进行了计划调整，但是测试也以非常重大和积极的方式影响了游戏。以上就是今天分享的全部。