Designer's Workshop - 02

为了避免你还不知道……Designer's Workshop，或者「设计实验班」，是我最近想写的一系列短文，关于游戏设计和开发。第一期的链接在这里：Designer's Workshop - 01，关于原型。

如果试水效果可以，能够帮助想要入门设计的同学或者能够引发一些讨论，那么我会经常更新。

课题：游戏测试和迭代设计

课题来源：​如何将自己从受众群体的角度来思考自己的作品？有没有什么详细的例子？​​​

本期「设计实验班」的课题依然来源于很久之前的一个问题，但是我认为这个问题很有价值和讨论的意义。游戏测试一直都是游戏开发中占工作比重相当大的部分，因为整个开发迭代的流程都应当是由测试驱动的，因此这一次我想聊一聊游戏测试。

什么是迭代设计？

迭代设计，在国外游戏设计课本上被称为iterative design。这种设计流程很容易描述，也就是 测试 - 评估 - 改进 - 测试 - 评估 - 改进……

我放一张课本上的图：

迭代设计流程示意图

有一个常见的情况是，一支游戏团队夜以继日辛勤工作了好几个月（尤其是国内的那种需要加班的项目组……）之后，他们总是容易忘记“玩家能够帮助他们让游戏更靠近玩家体验目标”这一个完全符合马克思唯物主义哲学观点的事实。这样的团队越来越容易在开发中迷失方向。而迭代设计流程可以完美的，并且已经被实验证明完美地解决了这个问题。

但当然了，你也不能一直修改产品的基础设计。

从图上我们可以看出来，随着开发流程的不断深入，你的测试、评估、改进的迭代循环应当越来越紧凑。因为开发的细节越来越多，问题也随之而来。但是在开发接近尾声的时候你就不能再进行基础性的修改了（比如游戏的核心玩法），这个时候往往会牵一发而动全身。因而你可以看出来在开发前期就引入测试是多么的重要。

在什么时候进行测试？

迭代设计是由测试驱动的，因此我们要求玩家始终持续测试来确保你的游戏能够完全契合你想要的玩家体验。你可能会觉得在制作前期画面、音效都没有完善，游戏太丑了简直不堪入目，或者是只做了一点，还没把精彩的部分呈现给玩家。你可能还会觉得至少要开发一个alpha版本再给玩家测试，就像目前野蔷薇上很多作品一样。但是要知道，一旦你进入了alpha阶段，除非你是独立开发者，否则你的日程可能根本不允许你对游戏进行任何基础性修改了。

Fullerton教授强调，从一开始就进行游戏的测试和迭代。从一开始。Eric Zimmerman教授也说，当你觉得需要测试的时候，可能已经晚了。

尽早进行测试，你可以避免后期大量修改造成的不必要的开支和花销。

进行游戏测试的方法

以下是一些不同的设计测试的流程和方法，各有优劣：

1、一对一测试：正如在之前的测试脚本中描述的一样，你和单个游戏测试者在一起，在他们身后观察并且做笔记，然后在测试结束前后分别问他们问题。

2、小组测试：组织一组测试者共同测试，你需要很多要电脑……观察他们的游戏过程并且记录，在试完结束后提问。

3、反馈表格：给测试你游戏的人一个标准的问题列表，让他们在测试结束以后来回答，并且对比他们的答案。这是一个获取一定数量的反馈的非常好的办法。

4、开放讨论：在一轮游戏测试结束后，你可以进行一对一讨论，也可以进行小组讨论然后记下笔记。你既可以鼓励自由讨论，也可以更有计划地引导讨论，提出更具体的问题。

你可以结合以上的方法来用在你的游戏中。此外，在我的这篇文章中：最有价值的玩家反馈，结合李姬韧和扎克的观点略有总结。

实验：组织一次玩家测试

@森一‍ 同学说，非常缺很对实践的引导。这更坚定了我在Designer's Workshop中设置“实验环节”的信念。本期的实验环节，我将聊一聊组织一次玩家测试的过程。

我之前也就测试的问题和《拯救世界特别小队》的扎克兄聊过多次。扎克向我分享了一篇他的老师，NYU Game Center的Zimmerman教授的文章：pdf在线浏览链接。这篇文章给出了对于游戏测试时需要注意的多个问题。这篇文章写的很好，当然你最好有英文阅读能力。这篇文章也编入了课本作为扩展阅读。

扎克给我的邮件中有一段话，我觉得很有道理，分享给大家：

另外我觉得有一个误区，在 Zimmerman 的概念里，alpha test ≠ playtest ≠ user test, etc. 我之前跟别人也因为这个定义没搞清楚造成了一些混乱。Playtest 是指人们面对面在一起做的测试。因为面对面，必然跟 alpha test 相比有非常多的优势。其实我觉得 alpha test 局限性是非常大的，只能测试 bug，整体平衡，metagame。而每一时刻的体验要靠 playtest 和 usertest 的反馈来打磨。

因为是面对面，playtest 不一定要测试游戏本身。Playtest 的出发点是你有一个设计疑问，于是设计了一个 playtest，而不是反过来去想你有什么东西可以测或者玩家会喜欢玩，因此你可以做任何原型来回答你的设计疑问。比如说，你想确认玩家对世界观是否感兴趣，那就做个世界观信息的交互程序，然后看玩家点哪里——其实程序也不必做，你做个实物原型，然后设计师作为一个Game Master当作程序去跟玩家互动。你要针对自己的情况去设计这个playtest，这有一定难度。如果等到所有东西都放进去才测试就有点晚了。

玩家对游戏原型不感兴趣很正常，而且可能玩原型很痛苦，但未必意味着这个原型是不行的——原型只是来回答设计疑问的。一个好的 Playtester 其实应该承受这种痛苦并把一个游戏测完。

那么，接下来我们来看看组织一次玩家测试的步骤和注意事项。在你招募到了游戏测试者之后，不要向他们介绍你的游戏是什么、怎么玩、你们的未来开发计划等等。相比于告诉玩家怎么去思考你的游戏或者解释怎么玩，不如让他们在没有任何解释（或是最小限度的解释）的情况下玩。你要允许玩家犯错，看每个人怎么上手你的游戏。也许你的规则很让人困惑，但是还是尽量让他们自己想办法解决。只有在测试者们卡住的时候才进行解释。相比于让玩家在你的解释下进行游戏，你会从玩家们犯的错误上学到更多。

毕竟，玩家在Steam下载游戏的时候你是没有办法随着游戏一起下载到电脑上并且对玩家进行各种解释的。

1. 介绍（2到3分钟）

欢迎所有的测试者，对他们表示感谢。自我介绍一下，然后对游戏测试的流程进行较短的解释，说明一下为什么这个测试能够帮助你改进你的游戏。

2. 热身讨论（5分钟）

准备几个问题，比如问问测试者玩的哪些游戏和你的游戏比较相似以及为什么他们喜欢这些游戏等等。发掘一下测试者的喜好，让测试者逐渐感到轻松。

3. 游戏测试（15到20分钟）

告诉游戏测试者们他们将会试玩一款还在开发中的游戏，甚至是原型。这目的是让测试他们了解你在测试的是游戏而不是他们的游戏技巧，让他们给你正确的反馈。

站在测试者身后静静观察，要求测试者在玩的过程中说出自己的想法，比如做了什么选择、有什么不确定的地方，面对游戏中的问题是怎么想的等等。@琪露诺‍ 就曾经使用了这种think aloud的方法，虽然看起来可能很难为情，但这是最有价值并且很有意义的。通过这样做你能够更清晰地了解玩家内心的想法。

如果在游戏过程中玩家遇到了很大的困难，你可以帮助他们来推进游戏测试的进程，但是要确保记录下来哪里有问题以及问题为什么会出现。

4. 讨论游戏体验（15到20分钟）

大约20分钟后，差不多可以结束试玩阶段，进入和测试者一对一交流讨论的阶段了。你要为这个阶段准备一系列的问题，探讨关于整体表现、兴趣水平、挑战水平、难度等级以及对游戏功能的了解。以下是一些问题的例子：

• 整体来说，你对这款游戏有什么看法？
• 你对游戏的玩法有什么想法？
• 你觉得这款游戏上手快吗？
• 你觉得这款游戏的目标是什么？
• 你怎么想从来没玩过这款游戏的人描述它？你会说什么？
• 有没有什么你不喜欢的这款游戏的地方？是什么？
• 有没有什么东西让你感到困惑？是什么？

随着你的设计进程的深入，在这个部分你会有越来越具体的问题，比如难度、关卡推进、视觉和感觉如何、音效、音乐、风格、节奏等。这次讨论应当集中在现阶段你面对的最重要的设计问题上。

5. 尾声

最后向测试者们表示很感谢，保留联系方式以便在游戏完成后告知他们。有可能的话，送给他们一些小礼物。扎克在纽约大学做测试的时候，免费的食物总是能够吸引大量的测试者。

练习：记笔记

在游戏测试中，记录笔记是最重要的环节之一。Fullerton教授在书上给出了一张表格，你可以用来观察和记录测试者评论的表格，它被分为3部分：

（1）游戏内的观察——测试者玩游戏时你的想法；

（2）游戏后问题——这些问题被设计用于找出对游戏系统的关键部分的想法；

（3）修改想法——关于怎么改进游戏的主意。

这张表格我拍照如下，但是要注意的是，有些问题并不适用于你的游戏测试。无论什么时候，就向我在上面说过的，明确你这次的玩家测试目的是什么。实验一个新机制，实验一个新特性，实验一个世界观，实验一个市场经济体系等等，然后依照你本次测试的目的设计问题、填写评论和笔记。下次针对另一个目的进行游戏测试的时候，重新设计一份表格。

像素不好，如果可以的话请大家凑活着看

另外，关于以后的Designer's Workshop的课题，我希望能够向看我文章的全体朋友和同学征集。如果你有感兴趣的话题想要与我一起讨论，大可畅所欲言。课题不限于游戏设计中的任何环节和元素的理论分析，以及一些出色的游戏的解构。