本文系用户投稿，不代表机核网观点
导语：“可玩性”究竟是什么？ 我们可以很轻松就想到那些用来赞美一款好游戏的说话，例如“好玩”、“刺激”、“牛逼疯了”，也可以从游戏机制、艺术表现等不同维度来评价一个游戏。然而，要给“可玩性”下一个准确的定义却并不简单，因为游戏是一种很复杂的内容载体。但要想制作出一款好游戏，开发者又不得不寻求一些有效的手段，来评估他们的游戏的可玩性。
为什么可玩性测试很重要
为什么可玩性测试很重要
无论一个游戏在开发过程中借鉴了多少的过往经验和理论知识，在设计者脑内进行过多少次的模拟，都不足以准确评估这个游戏的可玩性，并确切地指出其中存在的问题。一切的游戏设计在最初都只是“假设”，游戏只有为玩家所玩后，其玩法机制、关卡设计、艺术表现等具体的问题才会逐步浮现出来。而随着开发进度的推进，游戏的修改空间会逐渐变小，越接近开发后期，作改动所需的成本就越大。因此及早而又有计划地在游戏开发的各个阶段，组织一定数量的玩家进行可玩性测试(Playtest)，可以帮助开发者们验证设计和及时发现应对未知的问题，从而降低游戏在正式推出市场后可能面临的风险(当然，严谨的测试也需要耗费不少成本)。
在完整的游戏开发周期中，可玩性测试是非常关键的环节。但可玩性测试又不同于QA测试，它的存在不是为了发现游戏在功能、性能上的问题(即使在可玩性测试中也可能出现这些问题)，而是通过分析玩家的游戏过程、提供的反馈信息来验证游戏设计，发现和修正游戏性上的问题。虽然也有将其称之为游戏测试的，但这种说法略显笼统。相对应而言，它更类似于应用开发中的可用性测试，而考虑到游戏自身最主要的功能——玩，个人更倾向于“可玩性测试”这个名称。
不同类型的测试玩家
不同类型的测试玩家
可玩性测试中的测试玩家大致可以分为以下三种类型：
Developer Tester(开发者测试者)：顾名思义这类型的测试者来自于游戏的内部开发团队。游戏开发者往往也是游戏的第一批测试者，在早期测试阶段，他们能根据既有的开发经验以及参考同类型游戏，找出游戏设计上的问题，他们的意见对于把握游戏的整体方向起到至关重要的作用。然而，只有开发者作为游戏测试者是远远不够的，首先，开发者的思维方式和操作习惯可能有别于一般玩家；更棘手的是，由于自身对游戏太过熟悉，在测试过程中也难以像刚接触游戏的玩家那样进行游戏和得到近似的体验，所以就有必要招募在开发团队之外的测试人员，来获取这些人的反馈。
Kleenex Tester(纸巾测试者)：这类型的测试者其实跟纸巾没有什么关系，而是指在可玩性测试中，他们就像纸巾一样是一次性的：在测试前如白纸一般——没有接触过这个游戏，而测试后大多也不会再参与到同一个游戏的测试中去。对游戏的有限了解往往使这些测试玩家能够更易发现游戏中那些容易令人迷惑的地方，此外，他们的反馈也是评估游戏对于新玩家是否有足够吸引力的重要依据。
Expert Tester(专家测试者)：专家测试者可以来自于上述两种测试者，也可以是社区中比较关心这个游戏的活跃用户，总之他们需要对测试游戏有更为深入的认识。在测试中他们的定位是游戏的核心玩家，需要不厌其烦地玩测试游戏，以发现诸如平衡性等细节上的问题。相对地，他们深入的游戏体验能帮助开发者评估游戏的长期和重复可玩性。
测试玩家的招募与选择
测试玩家的招募与选择
不管测试游戏到底有多么人畜无害老少咸宜，也不意味着任何人都可以是游戏的测试者。选择什么样的测试者，是根据不同的测试目标有针对性地决定的。因此在制定一个可玩性测试的计划前，游戏开发者先要明确这次测试的目标是什么。大多数时候测试者会是游戏所定位的受众群体，即喜欢这类型游戏和测试游戏所属平台上的游戏玩家，但也并不尽然，如果开发者想了解游戏能否吸引到从未接触过这类型游戏的玩家，或者游戏是否适合推出在其他新的平台，就有必要将已有的受众群体排除出来。
为了选出合适的测试者，开发者会先制作问卷让想要加入测试的玩家登记信息，以大致了解测试者的玩家画像。问卷的形式取决于实际情况，但需要登记的内容基本都包含其个人身份(年龄、性别、联系方式等)、游戏习惯(喜好的类型、设备平台、频率和时长等)方面的信息。
1 / 2
测试方法
测试方法
虽然“好玩”可能是大多数游戏追求的终极目标，但对于可玩性测试来说，“这游戏好不好玩”诸如此类的问题显然没有太大意义。好的可玩性测试，应该尽可能地挖掘出具体的，能够引导游戏开发者后续调整的信息，也就是说，比起“好不好玩”，可玩性测试更重要的是去知道“有多好玩”、“哪部分好玩哪部分不好玩”、“为什么不好玩”……在组织测试之前，开发者首先应该充分熟悉游戏流程，明确游戏内各种设计的意图、想让玩家得到怎样的体验，乃至对各个测试项的结果做预期。这样做的好处是：
- 能够更快地对不符合预期的地方作针对性调整
- 如果事先已充分明确了游戏的设计目标，那就更容易在测试中发现一些从未料想到的状况。即使未能在测试之后就找到这些问题的答案，也会对规划以后的测试有所帮助
下面我们再来谈一下可玩性测试中常用的一些方法。比较传统的方法是观察记录玩家们的游戏过程，期间的情绪、行为表现，及他们对游戏的评价和感受，并根据游戏内容设置问题让他们回答。这听起来简单，但在实际操作上有不少需要讲究之处。
还原玩家体验
1 / 3
正如前文提到，相比远程测试，开发者可能更倾向于招募玩家到公司内部进行测试。而内部测试的问题就在于，测试中玩家处于一个不熟悉的环境之中，这与他们平时玩游戏的状态是不同的。然而，只有尽可能地还原玩家平时游戏的状态，才能在最大限度上反映真实的结果。要做到这一点，能从以下几方面着手：
- 提供一个亲和舒适的游戏环境。这需要开发者注意一些细节，包括接待玩家时的态度、游戏测试室内的环境、确保游戏软硬件的正常可用等
- 除了告知必要的信息外，在测试结束之前不要去跟玩家解释游戏机制是怎样运作的，游戏时应该要怎样做；同样，如果有多名玩家一同进行测试，提醒他们在游戏过程中不要相互讨论(除非测试的项目本身是需要多人互动的)，并保留足够的间隔距离或使用挡板让他们无法相互看到他人的游戏过程。这样做的目的是使玩家专注于探索游戏之中，以免被别人先入为主而影响了自己的体验和想法
- 不要让玩家感受到观察者的存在。观察肯定是必要的，但这并不代表观察者一定要在场，许多玩家不喜欢自己在玩游戏时还要被身旁的另一个人盯着。为了避免在测试时给他们增加不必要的心理压力，有些测试室内还会包含安装有单向透视玻璃的观察室(玩家看不到观察室内的人)。也有更简单的方法，那就是通过录像拍摄下整个游戏过程
怎样获得玩家反馈？
观察是游戏测试过程中取得反馈最直接的手段，通过观看游戏流程来了解游戏进展情况，结合玩家表情、肢体语言等外在表现来了解他们的心理状态，并将这些状况一一记录下来。
如果担心观察不足以对游戏进程和玩家进行正确解读或者会遗漏细节，也可以适当地向玩家询问，甚至鼓励玩家在游戏过程中即时说出自己的思考和感受 (think out loud)，但不要在这时就开始探讨其他更深入的问题，记录玩家如何进行游戏才是测试期间的主要任务。这种方式有干扰玩家而破坏正常游戏体验的风险，需要谨慎节制地使用。
测试完成后即可进入与测试玩家的Q&A环节。开发者应该事先准备好问题清单，而不是等到与玩家交流的时候再去思考，将问题整理成问卷让玩家填写，保持同一测试项目玩家问卷的标准化以便之后作统计比较。
在问题的设置上，对于那些玩家能根据主观感受强弱来评定的测试目标，就不要只是简单地提供“是”与“否”两种选项，而是加入不同程度的分级、排序，使反馈更精确和可量化。下图Valve在《求生之路》测试中的两个问题就是很好的范例。
有些问题测试玩家可能不易给出准确的答案，因为玩家不如开发者那样对游戏知根知底，很难能在测试中就理解所有的设计意图。这种情况下同样也不要只问“是否”，而是通过一些与目标相关性较强的问题来进行评估。假设我们想知道一个卡牌游戏的上手难度，那么“你能说下你的策略吗/你能大概预测下对手接下来要怎么做吗”这类问题得到的回答，会比“你觉得这个游戏是否容易上手”的更具参考价值。
除了回答预设的问题外，还应留给玩家自由表达的空间，听取他们的意见能帮助发现更多未知的问题。条件允许的话最好能设置与玩家单独访谈的环节，这样就能根据不同玩家的意见提出问题，来获得更详尽的信息。
然而，玩家所说的就都是真心话了吗？
作为游戏开发的一方，自然希望玩家能够毫无保留地说出自己对游戏的看法，但玩家有时却会有所顾忌而无法坦陈己见。这种顾忌主要来源于这几个方面：
- 觉得自己在游戏中的表现不佳而羞于启齿
- 担心说出实话会伤害到开发者的感情
- 认为开发者不重视自己的意见
首先需要做的是向他们强调，可玩性测试的对象是游戏，而不是玩家，所以无须纠结自己在游戏里表现的好坏，如果对游戏内容不明白或觉得玩法和操作难以驾驭，那是游戏的问题而不是玩家本人的问题，而开展测试的目的正是要寻找和解决问题。为了与玩家之间建立信任，在交流的过程中，不管评价是正面还是负面，意见有没有用，都尽数记下他们提出的反馈。期间如果觉得玩家说得不对，也不要去解释和辩驳，即使每个人都希望维护自己的作品，但一旦开发者表现得强势，玩家就会变得保守。在这一阶段，开发者理应充当的是聆听者，而绝非评判者的角色。
还有一种取巧的套路是提问者假装自己不是来自游戏开发方的人，比如只是一名一同过来测试的玩家。倘若提问者能从被评判对象的立场中抽身出来，玩家也能更开放地说出自己的看法。不过这不是一种常规的做法。
上文总结的一些技巧都有助于提高测试评估的准确度，但终究传统的观察分析和问答方法还是基于主观感受和经验作判断，也就无可避免地会出现理解、描述和评判标准等方面的偏差。因此，后来越来越多的游戏在开发中逐渐引入了更精确的技术手段来进行可玩性评估。
用数据来解读游戏体验
用数据来解读游戏体验
最常用和实用的手段是统计记录测试中特定的指标数据，并对其进行分析。记录的目标对象可以是一种操作行为、数值变化、角色状态、时间、空间坐标等等，不一而足，甚至是上述多种数据的组合。但它们需要与测试目标有较强的相关性，通过统计得到的这些数据集合，能够有效反映游戏设计在玩家游玩过程中的实现情况。比方说，要评估FPS游戏中某个任务的难度，那么玩家操控角色在任务中的死亡次数，就具有很好的参考价值。在这里，任务是调查的对象，而死亡次数则是与之相关的特征信息。
当然，这只是一种简单的说明。由于每一次死亡都可以被当作是相互独立的事件，都有着各自的特征，也就是说所有的死亡事件同样能成为调查对象，因而在实际应用中往往还会详细记录下每次死亡事件相关信息，这些具体细分的信息使我们能从更全面和深入的角度来分析游戏。
1 / 2
在游戏《光环2》某个操作神风烈士的任务测试中，游戏开发者在此任务小节的死因统计图中找到了一项“有趣”的数据。从上面的饼图中我们可以发现，给予玩家致命一击的敌人主要是那些遭受洪魔感染的人类(Flood Human)，达到了56%，如果开发者想调整该小节难度的话，这会是很重要的部分。不过，反常的地方却是橙色部分的死因未知(Unknown)。在其他小节中，死因未知的情况顶多只占到总体的2%，而此处却高达16%。于是他们通过数据记录回溯对应事件的录像和时间点，播放了所有出现死因未知情况时的片段。视频显示这些玩家都被场景中的一个坑洞误导——它看起来很像是一条可以通行的路，然而，所有试图穿越它的玩家却会因此而失足坠亡。大部分测试玩家在初次游戏时都被这个不经意设下的视觉陷阱所欺骗，但这并不是Bungie工作室(《光环》系列前三作开发商)想要的效果，所以后来他们对关卡场景进行了改动，把这个坑给“填”了。试想下，假如他们只从死亡的总数，而不从死因角度分析，那就只能评估出一个被夸大的游戏难度，因为所有死亡事件中还包含了先前没有预料到的坠落死亡，以及其连带产生重复游戏而造成的死亡。
数据可视化的妙用
各种各样的数据赋予了我们从多角度审视游戏设计的能力，但在面对不同类型的数据时，解读数据的方法也应该是不尽相同的。很多时候，单纯的数值和文字描述是不够直观的，而将信息提取出来，再结合视觉处理来解释，对提高数据解读的效率，尤其是包含各种属性的多维数据，能起到不少作用。上面刚提到的饼图也算是数据可视化的一种形式。但下面要说的，则是可玩性测试中一种广泛使用的数据可视化方式——热区图。
热区图记录的目标对象的属性中，最重要的是坐标信息。但热区图不直接显示坐标数据，而是将其映射到游戏地图中，每一次目标对象出现，就在地图相应的位置画上一点，然后再统合地图上所有的点，辅以视觉处理，以“热力”的形式呈现出来。热区图中颜色代表不同程度的热力，很多时候，某一位置显示的颜色越趋近于深红色，目标对象在这位置出现的机率就越大。
1 / 3
接下来容我再以《光环2》的续作《光环3》一个例子作说明。上图图1是《光环3》多人对战地图英灵殿在Alpha测试后得到的热区图。图中小点从黑色到白色再到红色的颜色渐变，代表着对应位置发生死亡事件的多寡，颜色越红则死亡次数越多。那这张热区图反映了什么问题呢？游戏设计者希望玩家可以尽可能地体验和利用地图上的可活动区域，但我们可以看到，地图中部下方，即炮台一侧的区域却几乎不存在红点，意味着在这一带很少会出现玩家间的战斗冲突，与地图上其他活动区域形成鲜明对比。在Alpha测试后，Bungie随即针对该问题对地图内的资源作调整，从图2的Beta测试热区图中可见，区域内红点的数量大大增加，说明调整是切实有效的。在这一案例中，热区图的应用很好地提高了发现问题和验证方案的效率。(其实当初微软在测试中就差点忽视了这一问题，原因是当时的微软游戏工作室有专门评估玩家体验的用户研究部门，所以Bungie的游戏设计师不必兼顾游戏测试的工作。但这要求他们相互间有充分的沟通，也就是前面说到的——如果评估游戏体验的人不了解游戏设计的预期，就可能忽视一些问题)
数据可视化还能帮助我们从玩家操作中发现一些特别的行为模式，进而思考在这些行为模式背后，玩家为什么要这样做，他们又究竟有着怎样的体验。Priyesh N. Dixit和G. Michael Youngblood在《Understanding Playtest Data through Visual Data Mining in Interactive 3D Environments》一文中给我们展示了一种不错的思路。他们使用了一个基于Quake 3引擎制作，名为The Urban Combat Testbed的FPS游戏demo，并以每秒10次的频率记录玩家的移动轨迹数据，这些数据包含了操控角色在虚拟空间中的位置(三维坐标)及其视角方向(欧拉角)。上图是将数据导出到可视化工具后的实际显示效果，其中小球用于标记角色位置，灰白色线用于指示视角方向，而整条移动轨迹则以蓝绿红渐变色线条显示，颜色变化指示时间的流向，起始一端为蓝色，终结一端为红色。
1 / 2
在观察了导出后的可视化数据后，Dixit和Youngblood总结了几种行为模式，其中一种他们称之为Pirouette——他们注意到玩家偶尔会停在原地做一个接近360度的转向操作(图1a为其在可视化工具中的示例)，这种行为模式表明玩家当时可能处于寻路，或是确定自己位置的状态。Pirouette往往出现在玩家刚进入到新的游戏场景，和处于容易让人迷惑的场景时，但如果这种迷惑并不是游戏设计想要赋予玩家的，那之后就需要在游戏中增加视觉线索或修改场景，以引导玩家选择正确的路线。这里数据可视化的作用在于：
- 相比观看游戏录像，这可能是更高效地发现玩家特定行为模式的方法，因为它能将抽象的问题具体化，把一个时间段内玩家的行动轨迹完整显示出来，从而让我们更容易在可视化工具中找出一些有规律、有图形特点的操作组合
- 一旦从中确定了一种行为模式，便可以尝试总结这种行为模式的特征，再通过程序算法为其进行定义，找出所有的玩家行动记录中符合该定义的数据
- 最后又结合前面说到的热区图，将符合定义的数据在地图上标注出来，即能反映出不同区域中出现这种行为模式的情况(如图2a所示)
感性与理性的结合
感性与理性的结合
诚然，玩家的反馈和开发者的解读，肯定不如程序完全基于事实得到的统计数据来得客观。这是否就说明前者的作用可以被后者所取代呢？其实不然。
开发者很难在早期开发中就提供体验完备的游戏测试程序，一般只有简单零碎的游戏原型(甚至很多时候就只是纸面原型)，用来明确游戏玩法、设计方向等。另外，这时也没有开始从外界招募一般测试者，测试者基本是由有限的内部团队人员组成，但无论从样本对象还是样本数量上来说，这都不符合数据统计要求。因此在这一阶段，主观的观察和反馈是测试可玩性的主要方式。
而到了开发后期能从更多的一般玩家中获取测试数据时，主观反馈依然能起到重要的辅助作用。因为数据本身并不能直接告知我们哪里出现问题，而应该是我们主动找出与问题相关的数据特征，再从大量数据中找出符合特征的数据。此时主观反馈就能帮我们首先确定需要提取什么样的测试数据。
在我看来，传统的观察和反馈方法适用于为测试对象进行定性分析，把握游戏设计方向；而数据统计方法则适用于为测试对象进行定量分析，验证想法，找出具体的问题出处以优化游戏细节。两者更多是一种相互补充的关系。顽皮狗工作室在《神秘海域》的可玩性测试中就很成功地结合了两者来应对棘手的问题。
优秀的视觉表现一向是《神海》系列游戏引以为傲的卖点，各种宏大而又从不失精细的游戏场景，对系列玩家来说早已是见怪不怪。然而，这些场景设计如果缺乏打磨，反而会破坏游戏体验。顽皮狗团队在测试中发现，玩家有时会难以找到正确的攀爬路线——因为部分场景中的视觉环境实在太复杂。同时，《神海》的玩法也造成了玩家可能会去尝试攀爬游戏中所有他们认为可以攀爬的东西，包括但不限于屋檐、窗台、水管、藤蔓、岩石等。但事实上并非所有这一切都能用来攀爬，很多就只是单纯的视觉表现而没有特别的交互功能。这就可能给玩家带来很不好的体验：
- 玩家会被反直觉的视觉设计误导而进行无意义的操作
- 对于《神海》这种“一本道”游戏来说，体验的连续性是至关重要的，但如果玩家在错误的地方纠结太长时间，就会严重影响游戏的节奏
1 / 2
顽皮狗采用了一个简单而高效的方案来解决这个问题：每当测试玩家按下跳跃键，但角色又没有跳到另一个平台或抓住什么东西，而只是停留在原来的地方时，后台程序就会记录下这次跳跃操作时对应的三维坐标。待测试完成后，这些被称为“bad jumps”的数据会被重新导入到游戏中，每一个坐标都附以红色小球作标记显示。每次测试结束后，环境建模师都会查看场景中出现的“bad jumps”，如果红色小球密集地出现在场景中的某个位置，就说明这里很可能存在误导玩家的视觉设计。此时只要找出附近模型中那些容易令玩家误会是可以抓住的地方，修改建模使其看起来是难以抓住的，问题就能迎刃而解。
纵然“bad jumps”的定义很简单，但在未了解测试玩家的游戏体验之前，是很难想到要去抓取这样一种数据的。顽皮狗正是先通过玩家的主观反馈来为问题定性，确定出一种与之相关的行为模式，再用玩家的操作数据来进行定量分析，逐个找出各个容易误导玩家的地方，为这个在《神海》系列游戏开发中常见的问题提供了高效的解决方案。
1 / 2
此外，随着传感器技术的发展使生理测量在人机交互的研究中变得日益重要，也有部分游戏开发者开始尝试通过监测生理数据来追踪玩家体验，这些数据包括眼动追踪、表情识别、皮肤电导、心率、脑电图等。但由于监测设备成本、解读准确度和侵入性方面的原因，大多数生理测量的方法在实际应用中还并不常见，所以这里也就不再展开来说了。
写在最后
写在最后
你告诉别人自己养家糊口的职业，他们会说，“噢，你的职业就是玩游戏啊”，不，我玩的游戏没那么有趣，是有问题的，但直到解决问题之前我会一直玩，然后我再将它交给你们，让你们痛痛快快地玩。
这是《额外生命》一书中记录的，《战争机器》系列之父Bleszinski所说的一段话。书中提到在《战争机器2》正式发售前，Epic Games要进行总计约四万小时的游戏测试，可见在我们那愉快的几十上百小时的游戏体验背后，有着不怎么有趣却又冗长得多的游戏测试历程。这也凸显了测试部分在如今的游戏开发，尤其是大型游戏开发中的重要性。
文中虽然列举了一些我认为比较有代表性的例子，但正如我开始所说的，游戏是一种复杂的内容载体，不同形式的游戏的测试方法自然也无法一概而论，更非我这三言两语便能说清。国内有关Playtest的讨论似乎并不多，故以本文总结下我个人一些浅薄的见解之外，也希望借此抛砖引玉一下吧。
评论区
共 48 条评论热门最新