作者：Ian Schreiber

此刻你可能有某些想法，获得了某些反馈。在生活和游戏设计中，你可以永远坐在那里构思最佳的选择，但是有时你需要为目标开始工作。选择方向并开始行动，即便它可能不是最棒的选择。你应当相信，可以在开发过程中不断重复，修改犯下的各种错误。（请点击此处阅读本系列第1、第2、第3、第4、第5、第6、第7、第8、第9、第10、第11、第13、第14、第15、第16、第17、第18课程内容）

今天，我要探讨的就是游戏测试。正如我们看到的那样，游戏测试的形式多种多样，为使得我们的时间能够换得最大化价值，重点在于能够辨别区分这些方法。

不同种类的测试

“测试”和“游戏”一样被过度使用，对不同的人来说有着不同的含义。总体而言，这个术语涵盖了所有你在开发过程中为实现提升游戏质量的目标而玩游戏的行为。但是，不同的测试或许有不同的目标，在开始行动之前先了解目标是很重要的。

漏洞测试（游戏邦注：也称为“质量保证”）

质量保证的目标是找到设计方面的游戏行为错误。这个过程无需考虑“趣味性”。如果设计师表示游戏应当有某种表现，但事实上游戏的表现与之不同（游戏邦注：即便游戏目前的做法更好），这便是需要识别到的漏洞。

通常情况下，我们认为漏洞测试专属于电子游戏。其实，桌游也存在相应类型的测试，其目标在于找到规则中的漏洞和游戏玩法中的迷失之地，也就是游戏中设计师未曾考虑到的缺陷。

集中测试

在集中测试中，你可以聚集目标用户群体中的部分玩家，看看游戏在满足用户需求方面的表现如何。通常情况下是出于营销目标而采用这种测试，但是此类测试若能将游戏设计师容纳其中，那么也可以让游戏更受目标群体欢迎。

可用性测试

在可用性测试中，玩家需要完成具体的任务，目标在于查看他们是否能够理解如何控制游戏。软件行业经常使用这种测试，以确保软件易于学习和使用。电子游戏也可以利用这种测试，易用性测试的结果可以用来改变控制，或者修改早期关卡来更有效地教授游戏的控制方式。

对桌游而言，可用性更为重要，因为没有电脑来对玩家的输入做出回应。如果你误解了《大富翁》中房屋的用处，将其建设在Community Chest上，游戏并不会阻拦你这么做。通过观察尝试玩游戏的玩家，你可以学到许多有关如何设计各种游戏的东西，使得游戏更容易使用。

平衡测试

如果某种类型的玩法存在会导致玩家忽略游戏中多数有趣选择，那么有趣的游戏便会迅速变得枯燥乏味。如果胜利的战略只有1种，而胜利的关键是哪个玩家能够更好地使用这种战略，那么其趣味性就不如那些有多种胜利途径的游戏。比如，如果某个玩家存在明显的优势，那么让其他玩家感受到游戏并非不公平就变得很重要了。该类型测试的目标是找到游戏中的不平衡之处，这样设计师才能够进行修正。

趣味性测试

可用、平衡和功能丰富的游戏仍然有可能不有趣。这种难以捉摸的“趣味性因素”可能难以有意地进行设计，但是当人们在玩游戏时，是否有趣就显而易见了。游戏的某些层面可能比其他层面更为有趣，因而弄清楚游戏的哪些部分需要保持不变也是很重要的。

所有这些测试的形式有些共有的元素。尽管不能说是完全相同，但是这些测试的最好的方法也颇为相似。所有测试对项目的成功都很重要。那么，为什么要进行区分呢？

原因在于，每种测试适用于项目的不同阶段。每种测试有着不同的目标，只有先了解目标，才有可能实现。

顺序

你应当在何时采用何种类型的测试呢？你要以何种顺序来安排测试呢？这取决于你的项目，因而顺序的确定与你作为设计师的判断力之间有所关联。但是，以下提供了某些经验法则：

1、在项目早期，你需要确保项目能够实现设计目标（游戏邦注：“设计目标”通常是制作一款有趣的游戏）。趣味性测试是必要的，这可以确保你不在错误的方向上花费大量的时间。如果你制作的游戏是针对某个特定的市场，那么集中测试可能也应当在早期阶段进行，询问目标玩家某概念的游戏对他们来说是否有趣。

2、一旦你知道拥有某些东西，你就需要加固机制。对整款游戏进行设计，确保所有的细节都被顾及到。测试游戏中的“漏洞”。（游戏邦注：应当注意的是，漏洞测试贯穿软件项目的整个开发过程，项目完成度越高测试越频繁。但是，非数字化游戏的“反漏洞”更加容易，而“漏洞”的存在可能会中止测试进程，所以在开发过程早期制定一套完整的规则很重要。）

3、一旦游戏变得有缺且设计完成后，测试就要逐渐从趣味性测试转变成游戏平衡测试。确保所有数值和玩家能力与你的设计一致。

4、当游戏能够运转并且平衡后，到末期你就要更多地考虑游戏的可用性。改变可用性并不会改变机制，发生改变的仅仅是那些机制呈现给玩家的方式而已。这个重要的步骤往往被忽略。游戏的习得只能靠其他玩家教授（游戏邦注：即自己阅读规则的对立面），这便是你需要在项目中避免出现的可用性错误。此刻你可能还需要进行额外的专注测试，确保游戏的主题和视觉元素能够吸引目标用户。

正如我上文说过的那样，这些只是经验之谈。如果你的游戏被特定群体玩家所接受这个层面特别重要，那么就要在项目开发的所有阶段进行集中测试。无需恪守这个测试顺序。

不同种类的测试者

因为测试分为不同种类，所以自然也会有不同种类的测试者。每种测试者都有其优点和缺点，而有些测试者对于某些类型的测试格外重要。

1、自己。你自己就是最有价值的测试者。不要忘却你自己体验游戏的能力。你对自己游戏的了解比任何人都要透彻。

2、其他游戏设计师。如果你足够幸运，认识其他技术娴熟的游戏设计师，那么你可以通过他们来开展某些有意义的测试。他们会批判性地分析你的游戏，并提出设计解决方案。

3、好友和家人。愿意花时间来测试你的游戏的亲密人士也很有用。他们较为容易接近。热心听从他们的意见，不要浪费他们的善意之举。应当注意的是，并不是所有类型的测试都适合使用这部分人。尽管他们是早期测试的优秀测试者，但是可能并不适合漏洞或平衡性等更细节的测试，因为他们可能并不知道如何去寻找其中的不足之处。

4、经验丰富的游戏玩家。经验丰富的游戏玩家精于寻找游戏中的优势战略，适合进行平衡测试。

5、陌生人。目标群体中的人适合进行专注测试和可用性测试，而且他们在趣味性测试方面也非常重要。但是，寻找测试者需要某些技巧，我们不能就这样走上街头随便找个不认识的人，让你玩玩游戏。我们将在将来的课程中深入探讨这个问题。

亲疏度顺序

通常来说，测试者的亲疏度安排顺序是从较为亲密到较为疏远。首先进行自我测试，然后召集好友，然后是能提供意见的熟人（游戏邦注：包括设计师、玩家或属于目标市场的人），最后是陌生人。

如果你过早地将自己的作品展现给他人，游戏中存在的大量设计缺陷和规则漏洞可能会浪费他们的时间并且令其产生挫败感，你应当要善待测试者。而且，如果你过早地使用陌生人测试者，可能无法得到有价值的反馈。比如，如果你的游戏原型只有粗糙的艺术和游戏成分，测试者可能会更多地抱怨图像的质量，而没有将注意力集中在游戏玩法上。

在这个阶段，你只需要进行自我测试，这样你就不需要依靠其他人或者对他们的意见进行跟踪。从实践上来说，设计师最终会因为过于熟悉自己的项目和系统而忽略某些显而易见的问题。如果你使用某个种类测试者的时间过长，那么也会出现同样的问题。在项目测试过程中，你需要引入新鲜的观点来审视游戏。

自我测试

在测试早期，当你自行玩游戏时，以下是某些你应当注意的地方：

1、你的游戏是否与设计目标相符？

是否有趣？虽然多数情况下你自己并非判断有效性的理想测试者，但是如果你自己都体会不到乐趣，那么其他人或许也体会不到。

2、规则是否存在漏洞？

“漏洞”指的是规则没有说明如何进展的情境。比如，可能你制定的规则是玩家的军队可以攻击其他玩家的军队，但是你没有制定如何化解攻击的规则。这种情况下会发生什么事情呢？实际操作中所发生的事情就是，玩家只能做着等待设计师决定采取何种措施！

比如，考虑以下4 X 4格子一字棋的规则：

(1) 玩家：2

(2) 目标：将标志连成一线。

(3) 背景：绘制4 X 4的正方形方格。

(4) 游戏过程：玩家在回合内在空白格子内画上自己的标志。

(5) 完结：任意在回合内将自己的标志连成一线（游戏邦注：包括横、竖和斜线）的玩家获得胜利。

如果你尝试自遵循这些规则来玩游戏，那么你会很快意识到游戏无法开始，没有规则指明玩家将使用何种标志或者哪个玩家先行动。为解决这个问题，你可以添加某个条件。比如：

背景：绘制4 X 4的正方形方格。选择先行动的玩家，指定其使用“X”标志。另一个玩家使用“O”标志。

3、是否出现死路？

“死路”指游戏到达无法继续进展下去的状态，但此刻游戏依然没有结束。想想上文中我们修改过的4X4一字棋规则。假设两个玩家画满了棋盘上所有的格子，但没有人获胜。这种情况下，游戏无法进展下去，因为规则要求玩家必须在空白的格子上画标志。现在没有空白的格子，因而玩家无法继续按回合进展下去。但是游戏依然没有结束，因为两名玩家都没有获胜。在这种情况下，就必须添加新的规则（游戏邦注：比如，在完结条目中添加，如果玩家无法继续行动且没有人获得胜利，那么游戏结果就是平局）。

4、是否有不清楚的规则？

在脑中假设规则却没有将其写下来，这对我们来说是很自然的情况。尽力审查规则，看看自己是否假定了某些玩家意识不到的东西。

5、是否存在明显的优势规则？

是否存在某个可以很容易地赢得游戏的战略。努力找到它。相比被测试者发现（游戏邦注：更糟糕的情况是，在游戏发布后被玩家发现）来说，自己发现并修正产生的尴尬要少得多。在你自己制作的游戏中找到清晰度和优势规则缺陷往往较难，毕竟你曾努力将游戏设计得毫无问题。但是，在这方面做些努力，你可能会在早期便找到和修正某些错误（游戏邦注：从长期来看，这会节省设计师大量时间，也就有更多的时间重复审视游戏设计的其他部分）。

你或许会认为，寻找优势规则是项目后期游戏平衡时需要做的工作。有时确实是这样的，这取决于优势的程度。如果优势过于明显而且很显然已经有碍于你从测试中获得真实信息，那么就要马上纠正。

独自测试难点

以下是某些难以独自进行测试的东西：

1、即时多人游戏，比如那些你需要比对手更快地打出卡片或说出答案的游戏。

2、隐藏信息游戏，每个玩家拥有的信息只有自己知晓，而且向对手保密很重要的游戏。

3、贸易、谈判和拍卖游戏，在此类游戏中每个玩家都必须对某件道具出价，不同玩家对物品的价值判断可能并不相同。

对于后面两个，有某些方法可以进行测试，比如将自己的行动限制在当你处在每个玩家的境地下可能采取的做法，这样就可以知道玩家可能有的想法。有些人会觉得这种测试较为困难。

最简单的解决方案就是，不要使用无法自行测试的机制。另一种方法是在这种情况下增加1或2个玩家进行测试。

让游戏获得发展

经验丰富的设计师往往会说游戏可以“自行成长”，就像游戏自己拥有生命，设计师只是在引导而不是创造。从表面上看，这听起来似乎很奇怪，但是实际上，如果设计师不玩或改变游戏，游戏也只是待在那里而已。这里在发生什么事呢？

我想，真正发生的事情就是，游戏的创造是个学习的过程。你或许对游戏如何终结有自己的想法，但是最终版本可能与你最初的愿景有很大的差别。发生这种改变的原因在于，刚开始你对自己的游戏并不十分了解。你有某些基础想法，但是你并没有真正明白机制的互动形式以及动态和美学的情况。在测试过程中，你对游戏系统的运转方式有更深的了解。随着你逐渐学习和了解，你就更能够预测改变会对系统产生怎样的影响。

但是，现在你没有这种经验，至少在这款游戏的经验方面仍有所欠缺。自行测试是你的首个发现之举。在你发现的过程中，好似游戏想要往某个新方向发展，好似游戏有自己的生命。如果你感觉到这一点，那么听从游戏的想法。看看这样的发现会给你带来何种结果。

游戏邦注：本文发稿于2009年8月6日，所涉时间、事件和数据均以此为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Level 12: Solo Testing

Ian Schreiber

At this point you have some ideas, and you have some feedback. As with many things in life and in game design, you could sit here forever contemplating which is the best choice… but at some point you’ll need to start working towards your goal. Choose a direction and go with it, even if it might not be the best one. Trust that you will be able to use the iterative process to fix any mistakes you make along the way.

Today I’d like to cover the general concept of playtesting. As we will see, there are many different kinds of playtesting, and it is important to be able to differentiate between them in order to get maximum value from our time.

Readings

There are no readings for today, other than this blog post. Take the time that you would have spend reading, and use it to work on your Design Project.

Different Kinds of Playtesting

The word “playtesting,” like the word “game,” is overused and can mean different things to different people. In general, the term covers any activity where you are playing a game in progress for the purpose of improving it. But different playtests may have different goals, and it is important to know what your goals are before you do anything.

I’ll be playing a bit fast and loose with terminology here, so in this case the concepts are more important than the labels I’m giving them.

Bug Testing (or Quality Assurance)

The purpose of QA is to find errors in the game’s behavior relative to its design. “Fun” does not enter the equation. If the designer says that the game should do one thing and it actually does another (even if what the game is doing may be superior), that is a bug that needs to be identified.

Normally, we think of bug testing as specific to video games. Board games do have a corresponding kind of testing, where the purpose is to find holes in the rules and dead ends in gameplay – gaps in the game that the designer did not cover.

Focus Testing

In a focus test, you bring together players that are part of the target audience’s demographic in order to determine how well a game serves their needs. This is normally done for marketing purposes, but if game designers are involved it can also help to make the game more enjoyable for that particular demographic.

Usability Testing

In a usability test, players are given specific tasks to accomplish in an attempt to see whether they understand how to control the game. This is done frequently in the greater software industry to make sure that a piece of software is easy to learn and easy to use. Video games can take advantage of this as well, and results from a usability test can be used to either change the controls or modify the early levels to teach those controls more effectively.

In board games, usability is doubly important, because there is no computer to respond to player input for you. If you misunderstand how houses work in Monopoly and place them on Community Chest spaces, the game will not stop you. By observing players who are trying to play your game, you can learn a lot about how to design the various game bits so that they are easy and intuitive to use.

Balance Testing

A fun game can quickly become boring if some kind of play exploit exists that lets a player bypass most of the interesting choices in the game. If only one strategy can win and it is just a matter of which player follows that strategy the best, it is not as interesting as if there are multiple paths to victory. Likewise, if one player has a clear advantage over the others, it is important to identify that so that players do not feel the game is being unfair. The purpose of this kind of test is to identify imbalances in the game so that the designer can fix them.

Fun Testing

A game can be usable, balanced and functional and still be uninteresting. That elusive “fun factor” may be hard to design intentionally, but when people are playing the game it is pretty obvious whether they are having fun or not. Certain aspects of the game may be more fun than others, so it is also important to figure out what parts of the game need to stay the same… not just what to change.

All of these forms of testing have some elements in common. Best practices are similar if not identical. All are important to the success of a project. So why make a distinction?

The reason is that each is appropriate at different stages of completion in a project. Each kind of testing has different goals, and you need to know what your goal is before you can achieve it.

Order of Effects

When should you do which kind of playtesting? What order do you do them in? A lot depends on your particular project, so some of this will be up to your judgment as the designer. However, there are some rules of thumb.

Very early on in the project, you need to make sure your project will meet its design goals (usually the “design goal” is to make a game that’s fun to play). Testing for fun is necessary to make sure you do not spend a lot of time building on the wrong foundation. If you are making a game for a specific market, focus testing may be involved at an early stage as well, simply to ask the target audience if a game with a particular concept sounds interesting to them at all.

Once you know that you have something, you need to solidify the mechanics. Design the whole game, making sure that all the details are taken care of. Test for “bugs.” (Note that bug testing in software projects is often done continually throughout the project, increasing in intensity toward the end. Non-digital games are easier to “debug” though, and a “bug” can stop a playtest in its tracks, so it is important for us to have a complete set of rules early in the process.)

Once the game is fun and the design is complete, gradually shift from testing for fun to testing for game balance. Make sure that all the numeric values and player abilities are where you want them to be.

When the game is working and balanced, towards the end, you’ll want to think more about the usability of the game. When you change usability you are not changing any mechanics, merely the way those mechanics are presented visually to the players. This is an important step that is often neglected. If you’ve ever encountered a game that you could only learn by being taught by another player (as opposed to reading the rules yourself), that is the kind of usability failure you want to avoid in your own projects. You may also do additional focus testing at this time, to make sure that the theme and visual elements of the game appeal to the target audience.

As I said, these are just guidelines. If it is incredibly important that your game be well received by a particular demographic, for example, you may be doing focus testing throughout the project at all stages. Do not let this order of things be your master.

Different Kinds of Playtesters

As there are different kinds of testing, there are also different kinds of testers. Each kind of tester has their own strengths and weaknesses, and some are more important for some kinds of testing than others.

Yourself. You are your own most valuable playtester. Do not forget your ability to play your game on your own. You know your game better than anyone.

Other game designers. If you are lucky enough to personally know some other skilled game designers, you can get some very useful testing done through them. They are able to critically analyze your game and propose design solutions. (If you do not know any professional designers, perhaps you can at least make contact with other participants of this course.)

Close friends, family, and confidantes. People close to you who are willing to provide their time to test your game are very useful. They are approachable and can make themselves available as a favor to you. Take good care of them, and do not abuse their kindness. Note that these people may not fall into any of the other categories, so while they are good for early tests, they may not be appropriate in more focused testing for bugs or balance since they may not know what to look for.

Experienced gamers. Skilled game players are great at finding exploits and dominant strategies in a game, and are appropriate for balance testing.

Complete strangers. People in your target audience are appropriate for focus testing and usability testing, and they are absolutely critical when testing for fun. Finding them can be tricky, though, because it is not in most of our natures to just walk up to someone we’ve never met and ask them to play a game. We will talk more about this in the coming weeks.

Order of Familiarity

In general, you will want to go through testers in order from more to less familiar. Test with yourself first, then with close friends, then with acquaintances that are useful (because they are designers, gamers, or part of the target market), and then with strangers.

If you show your work to other people too early, it will likely be in such a rough state with multiple design flaws and holes in the rules that it will waste their time and frustrate them, and you want to treat your playtesters better than that. Also, if you start playtesting with strangers too early in the process, you may not get useful feedback – if your game prototype is in a rough state with only crude art and components, for example, the playtesters may be so busy commenting on the poor quality of the pieces that they will not be able to concentrate on the gameplay.

At this point you might be tempted to just do all of the playtesting by yourself, so that you don’t need to rely on other people or keep track of them. In practice, the designer eventually gets too close to their own project and is so familiar with the game’s systems that they can miss some really obvious flaws. If you keep the same set of playtesters for long enough, they will suffer from this problem as well. You need to bring in fresh sets of eyes to look at your game on a continuing basis throughout the project.

Playing By Yourself

In the early part of playtesting, when you are playing the game on your own, here are some things you should be looking for:

Does the game meet your design goals?

Is it fun, at least for you? While you are not the ideal playtester to judge effectiveness most of the time, if you are not having fun then most other people will probably not either.

Are there any holes in the rules?

A “hole” is a situation where the rules simply do not say how to proceed. For example, perhaps one of your rules is that a player’s army can attack another player’s army, but you don’t yet have rules for resolving the attack. What happens in this case? In practice, what happens is that the players sit around and wait while the designer figures out what to do!

As an example, consider these rules for Tic-Tac-Toe played on a 4×4 grid:

Players: 2

Objective: Get a straight line of symbols.

Setup: Draw a 4×4 square grid.

Progression of play: On your turn, place your symbol (“X” or “O”) on an empty square.

Resolution: If either player on their turn has a set of four of their symbol in a straight line (across, down, or diagonally), they win.

If you try to play this game just following the rules, you’ll quickly realize that you can’t even start – nowhere does it say which player is X or O, or who takes the first turn! To fix this, you would add a situation to handle this. For example:

Setup: Draw a 4×4 square grid. Choose a player to go first, who is assigned the symbol “X”. The other player is given the symbol “O”.

Are there any dead ends?

A “dead end” is a game state where there is no way to proceed further, but the game is not resolved. Consider our revised 4×4 Tic-Tac-Toe rules above. Suppose that both players fill up all squares on the board without anyone winning. At this point the game cannot proceed, because the rules say a player must place their symbol on an empty square. There is no empty square, so the player cannot take a turn. But there is also no resolution, because neither player has won. In this case, a new rule would have to be added (such as: in the resolution, if neither player can make a legal move and no one has won, then the game ends in a tie).

Are any of the rules unclear?

It is natural for us to assume things that are in our head, to the point that we often forget to write them down in our rules. Try to look at your rules and see if there is anything you are assuming that your players might not.

Are there any really obvious rules exploits?

Is there a single strategy that wins the game easily? Try to find it. It’s much less embarrassing if you find and fix it yourself, as opposed to having it discovered by your playtesters (or worse, your players after you release the game). Clarity and exploits are often hard to find in your own game; you tried to design this game to not have any problems, after all. Still, make an honest effort, and sometimes you will be rewarded by finding and fixing errors early (which saves a lot of time in the long run, leaving you more time to iterate on other parts of your design).

You might think that looking for exploits is something to do later in the project when balancing the game. Sometimes it is. It is a matter of degree. If an exploit is so powerful and so obvious that it prevents your playtests from giving you real information about your game, fix it now.

Solo Test Difficulties

There are a few things that are hard to test alone:

Realtime multiplayer games, such as games where you must slap a card or say an answer faster than your opponent.

Hidden information games, where each player has information that only they know and that is important to keep secret from the opponent.

Trading, negotiation, and auction games, where each player must place a value on an item, and different players may value things differently (and especially when players can artificially extort high prices or drive up the cost of an item at auction just to make their opponent pay more).

For the latter two, it is possible to play anyway, by simply limiting your actions to what you think you would do if you were in each player’s situation, knowing only what they would reasonably know. Some people find this more difficult than others.

The simplest answer here is, for the purposes of this project, to not use mechanics that you can’t test yourself. The alternative is to bring in another player or two early on in this case only, after you take things as far as you can on your own.

Let It Grow

Experienced designers often talk of a game “making itself” – as if the game has a life of its own, and the designer is merely guiding it rather than creating it. On the surface, this seems strange because really, the game is just sitting there and doing nothing unless the designer is playing it or changing it. What’s going on here?

I think that what is really happening is that the creation of a game is a learning process. You may have some idea of where you want your game to end up, but the final version may be very different from what you originally envisioned. The reason why it changes is that at the beginning, you don’t know very much about your game. You have some basic ideas, but you don’t actually know how the mechanics will interact, or what the actual dynamics and aesthetics will be. As you playtest, you learn more about how your game’s systems are working. As you learn, you become more able to predict the effects that changes will have on the system.

Right now, though, you don’t have that experience… at least not with this game. Playtesting on your own is your first act of discovery. As you discover, it may seem as though your game wants to grow in a new direction, as if it has a life of its own. If you feel that, go ahead and listen to your game. See where the process of discovery takes you. (Source: Game Design Concepts)