作者：Ian Schreiber

前文参阅：万字长文，Ian Schreiber从多角度谈游戏制作系列1、万字长文，Ian Schreiber从多角度谈游戏制作系列2和万字长文，Ian Schreiber从多角度谈游戏制作系列3

聆听游戏测试者的反馈。也许你的游戏测试者并不是专业的设计者，有时候他们的建议可能毫无意义。但既然他们对你的游戏做出了反应，你就应该认真思考并做出具体分析。

聆听你的游戏。当游戏达到了一定的复杂度时，我们便能够完整地看到游戏的深度内容。并且，比起简单地制作出你最初设想的游戏模型，制作出完善精致的游戏更重要。

聆听你自己的心声。每一次都要根据你的设计师直觉而做出的决策，不论好坏，都能帮助你获得更好的结果。（这也是为何拥有20年设计经验的老手比起大学生更有可能成为优秀 设计师的原因，这无关所谓的“天赋”或者其它捷径。）

在此，我们先讨论第一点：聆听游戏测试者的反馈。当你到达一定的开发阶段时，你便需要开始测试游戏。你需要邀请一些局外人，特别是来自于游戏目标市场的群体，让他们帮 助测试游戏。

让玩家测试游戏和让其他设计师测试游戏大为不同。如果做的好的话，你便能够从目标用户中获得有帮助的反馈信息，而不是游戏设计师单纯的建议，因为你能够第一时间了解那 些愿意尝试游戏最后版本的玩家们此时对于游戏的看法。这是一种完全不同的技巧。因为游戏测试者并非专业设计师，所以能够给出不一样的反馈意见，而你也必须更努力地从中 找出问题的根本原因。所以在这个过程中你要保持高度的洞察力。

街头艺人

你是否看过街头艺人？他们是为路人做表演的音乐家，魔术师，变戏法的艺人或者小丑等。他们接受着观看者的“捐赠”，除了这些愿意驻足的陌生路人，他们得不到其它收入。 他们深谙如何取悦大众，因为只有这样才能养活自己，避免留宿街头。

显然，在街头表演过程中，观众的目光始终在艺人身上，那么这些表演者的目光又在哪里呢？下一次当你看表演的时候，认真地去观察这些表演者，你会发现，比起关注于自己或 者表演，他们更加专注于观众的反应。他们的目光一直在人群中追寻着兴奋点，不论看到观众的反应是肯定还是否定，他们都会适当地做出调整。也许观众更喜欢硬币魔术而非纸 牌魔术，或者更喜欢蓝调而不是爵士乐，又或者是更喜欢玩杂耍。所以对于表演者来说，最重要的技巧便是读懂观众的心思。

这些艺人不会停下表演去询问观众的反应，因为他们可以从观察中得到答案。

在游戏设计中要如何使用这一技巧？

当你邀请非设计师进行游戏测试时，你所扮演的角色无疑就是街头艺人了。所以不要单纯地询问测试者游戏是否有趣，因为他们并不会给予你准确的答案。相反地，你应该观察他 们的游戏过程，并在旁边做记录：

他们的游戏姿势是怎样的？游戏是否调动了他们的乐趣？还是他们感到游戏很无聊？或者因为游戏而感到兴奋？

他们的视线关注着哪里？频繁流连于哪里？测试者之间是否会相互观察？还是他们会不时看着作为旁观者的你？他们是否会环视测试房间细数着天花板上的砖瓦？

他们是如何移动？注重于攻击还是防御？玩家之间会合作，协商还是相互暗算？

他们是否遵从着游戏规则而游戏，或者一直“犯规”？测试者是否会陷在某些关卡并需要寻找解决方法，或者他们能够一直顺利地完成游戏？

观察结果是否符合游戏的设计目标？或者说你的游戏是否符合你的预期目标？

你还必须注意，在一次游戏测试过程中，他们的上述反应都会有所变化。你需要找出游戏哪些环节最吸引人，而你在游戏测试阶段的目标便是观察这些内容。

针对于非设计师群体准备测试

如果不是设计师，我们便很难忍受粗糙的游戏原型。特别是游戏玩家，如果他们收到一叠手写的索引卡片，并且卡片要求他们在一张笔记本纸做成的游戏棋盘上移动便士，如此， 他们可能会更多地关注于游戏组件的质量而非游戏机制吧。而这时你可能会得到很多关于美术设计或棋盘布局的评论，但是此时这些内容对你来说真的没什么价值，因为你更迫切 地希望了解玩家们的游戏体验，毕竟这个阶段我们还不用去讨论游戏的最终外观！

如果你足够幸运，能够遇到愿意应对粗糙游戏原型的测试者，你就可以省去很多不必要的工作了。也有些人认为有必要花时间去创造一些游戏组件，但是却不一定要求非常高的质 量，只要能够尽可能地仿效游戏即可。

通常情况下，我们总是不愿意在粗糙的游戏原型中投入太多时间。因为投入的时间越多，就说明我们越难对其做出修改。

如何做才能在短时间内制作出精致的游戏原型？以下是一些窍门：

谷歌图片搜索是你的好帮手。如果你想要寻找一些关于纸牌或者棋盘图像，你可以输入一些关键词。然后找到图片进行复制粘贴即可。全部过程只要几分钟。让你能够如此简单大 方地“借取”别人的图像。

而对于一些基本组件，如兵卒或者令牌等，你便可以从现有的游戏中取出类似的道具暂时填充。这样总比你使用瓶盖，便士或者其它莫名其妙的道具做原型专业多了。

对于纸牌，你可以轻松地在PPT或者Visio（游戏邦注：Visio公司在1991年推出的制作图表软件）中创造好看的图像。标准的纸牌大小是2.5英尺宽，3.5英尺高。而在8.5×11格式 的纸张上，你可以按照4×2网格横向罗列出8张纸牌，或者按照3×3网格纵向罗列出9张纸牌。用标准的纸张打印并用剪刀裁剪出来。

如果你想要创造一些容易洗牌与手持的纸牌，你可以使用一些塑料卡套（在游戏或者业余爱好者商店能够买到，这主要是用于保护《万智牌：旅法师对决》中的纸牌）。你可以将 纸牌插进这些塑料套中，让它们拥有统一的背部图案，然后在正面展示不同的卡片类型。

在现阶段，你可以将游戏棋盘印刷在1张或多张纸上。你也可以在PPT或者其它简单的工具，如MS Paint（画图工具，可以用它创建简单或者精美的图画）中的基线绘制方形，使用 文字工具编写棋盘中的文本或数字，或者你也可以复制并粘帖其它图像。

针对非设计师玩家执行测试

当你开始花费大量时间去记录并作观察时，你将会发现这比亲自玩游戏简单多了。不管你是与其他设计师一起进行测试还是单独作测试，你所扮演的都是玩家的角色，但是如果是 针对于非设计师角色的测试，你的关注焦点将转移到测试者身上，观察他们如何玩游戏并且彼此间如何进行交流。

你可以先写下一套规则，并告知测试者这些规则以及游戏相关组件，然后默默地站到旁边，不干涉他们的游戏。同时，你还必须让他们知道，你是以观察者的身份站在那里，既不 是玩家也不是参谋长。你可以让他们假装你的不存在，而自然地开始游戏。

但是测试者经常忘记这点，就像是他们在游戏中遇到一些不明白之处，就会转过头向你咨询。而这时候你不应该立刻做出回答。你应该先问他们一个问题：“如果我不在这里，而 你需要自己做出判断，你会怎么做？”而不管他们的回答是否正确，都会让他们领悟过来。并且不管玩家做出何种选择，你都能够从中了解他们是如何理解你的游戏。而在玩家回 答了你的问题后，你便可以告知他们想要的答案。但是绝不要放弃如此这种可获得有价值信息的机会。

有时候你的测试者根本不会咨询你，而是径直前进，并因此陷入了游戏“误区”。也许本来每个玩家每一回合应该抓取2张牌，但是他们却只抓了1张。或者他们在每个回合开始时 都略过了第一步。或者他们忽略了游戏中某些道具的作用。这时候你一定要克制住那种想制止他们的冲动。虽然这种感受很不妙，没有什么比看玩家违背设计初衷而继续玩游戏还 折磨人了，但因为游戏发行后可能还有玩家继续这么做，所以对你来说意识到这点非常重要，因为你可以在测试后对规则和组件做出修改。

让玩家“错误”地玩游戏也能够带来一些有益的帮助。有时候你会发现，测试者的游戏方法可能还优于你预先设定的规则。许多人，甚至是非设计师都拥有很强大的游戏直觉。而 有时候，人们总是会根据自己的直觉避开游戏中一些规则，并按照自己认为有趣的方法进行游戏。

寻找非设计师测试者

幸运的是，比起寻找游戏设计师作为测试者，非设计师测试者更好找，毕竟后者的数量远远多于前者。

你的朋友，家人或者同事都可以为你提供帮助，并且他们也很乐意帮你的忙。而如果你待在一个没有熟人的地方，你可以考虑走出家门，去外面找找愿意帮你作测试的人。

除此之外，你还必须记住，那些与你熟知的人很难直接批评你的游戏。他们也许会说那是他们玩过最有趣的游戏，即使事实并非如此。因为对他们来说，你们之间的关系比起游戏 测试结果还重要。所以对于这类型的测试者，你更应该保持密切的观察，判断哪一部分对于他们来说才是真正具有乐趣。

盲测的挑战

你可能也会想象到，与你亲自进行的游戏测试相比，盲测会面临众多问题：

1、因为你不在场，所以玩家碰到的任何问题都是他们完成游戏测试的阻碍。

2、可能出现更糟糕的情况是，玩家或许会错误地理解规则和玩游戏。如果他们不知道玩游戏的方向错误，那么你的测试结果就可能存在偏差，而测试者甚至都不知道这点。

3、反馈结果会有很大的差异。现在你或许已经知晓，测试群体的质量参差不齐。当你不在场时，无法询问目标问题，这个麻烦会更加严重。

4、你无法进行实时审查。你所获信息的唯一来源是测试群体在回忆游戏过程时的反馈。其信息的真实性可能比你在场的情况更差。

5、进行盲测需要花费更多的时间。你不能简单地将游戏原型带到好友的家中，然后马上让他体验。你需要找到方法，让测试者得到游戏的副本，然后你必须得离开。然后你必须等 待测试者根据自己的时间安排体验游戏后向你反馈结果。盲测的结果要1到2天才能够收到，这是最好的结果，但比亲自测试所需的数分钟或数小时要长得多。

因而，盲测所能提供的信息类型有限。

盲测的原因

既然盲测有如此多缺点的话，为什么还要使用呢？它有什么用处？

这是项我们从科学领域借鉴的技术。之前，某些研究人员注意到，调查者是否同测试者在同一个地方会影响实验结果。有时，测试者所说的内容是调查者想听的，而并不是他们自 己心中所想的。有时，调查者会提供微妙的非语言线索，而他们自己和测试者都没有意识到这一点，但是这会使测试结果产生偏差。比如，假设进行的是两种软饮料的口感测试实 验，如果调查者知道两份饮料的对应品牌而且他们希望测试者选择哪个品牌，他们可能会发现所有的测试者都选择了“正确的”饮品，原因只是调查者不经意间向他们传递了要做 出哪个选择的信息！

应对这种情况的解决方案便是所谓的双盲实验，也就是调查者和测试主题都不知道哪个是“正确的”选择。这消除了许多意外产生的偏见，使得测试结果更加准确。

游戏测试同科学实验有许多共同之处。二者都有假设前题（“我觉得这个游戏很有趣”）、设计实验（构建原型）、运行实验（游戏测试）和结果分析。二者的目标都是发现所研 究系统内在运转情况的更多信息。

盲测是获得玩家对游戏真实想法的唯一途径，也就是说，如果玩家是刚刚从商店中购买游戏并首次体验游戏，在设计师不在场的情况下玩家会对游戏做出何种反应。

盲测的时机

因为盲测所能提供的信息量很少，所以在游戏状态粗糙的早期并不适合进行盲测。测试者很可能在碰到问题之后无法进行下去，你也需要花费大量的时间来等待结果，而亲自在现 场测试得到结果的速度要快得多。盲测最适合开发末期，也就是在你已经自信游戏几乎没有问题的时候。

盲测的目标是找到你在亲自测试中可能无法发现的潜在问题。在亲自测试中，即便游戏测试者无需询问你任何问题，你对游戏的了解有时也会让人们轻松地通过某些规则（而这些 规则在盲测时或许会让他们感到困惑甚至放弃游戏）。或者，你可能会在向玩家介绍游戏时说出某些并没有在游戏中提供的关键信息片段（游戏邦注：比如“这是款拍卖/竞标游戏 ”），这种情况可能会让测试者脑中产生某些先入为主的观念。如果你不在场，你就会发现亲自测试结果的准确性有问题，你或许可以找到之前没有注意到的某些漏洞。

盲测的对象

多数桌游需要多个玩家。出于实践原因，游戏的多数盲测对象是固定的游戏群体。某些公司有个自愿者群体，他们会在联系测试者之后向他们发送游戏的升级版本，由此来获得他 们的反馈。对我们来说，这种方法并不适用，因为多数开发者并没有如此大的游戏公司，也没有可供征募的志愿者数据库。

理想情况下，你的盲测对象应当是游戏的目标群体用户。如果你制作的是儿童游戏，你的盲测对象应当包含目标年龄段的儿童（游戏邦注：有时候还要考虑到孩子的家长）。如果 你的游戏针对的是那些已经对德式桌上游戏狂热的玩家，那么你最好找个经常玩此类游戏的玩家群体。其他类型游戏也是如此。

在这个阶段，以下方法可以帮助你的设计项目找到盲测对象：

1、你的社交圈，包括好友、家人和同事。这些人可以是当地的，也可以居住在其他城市甚至其他国家。因为你无需待在测试现场，所以在此地理问题将不再是障碍。

2、其他处在这个阶段的人。如果你在当地已经拥有了游戏测试群体，而且之前与他们合作过，你可以在Twitter或论坛上向他们发出援助请求。可以提供盲测交换：如果他们接纳 的请求，那么你也可以作为对象来盲测他们的游戏。

3、最后，你可以通过其他的讨论论坛或网络媒体寻找桌游设计师或游戏测试者，看看是否能找到招募盲测测试者的方法。

盲测的方法

在亲自测试中，如果出现某些纰漏，你可以应付得过来。或许你意外将某些游戏组件忘在家中，或者某些规则有些不清晰，需要澄清。尽管会出现这些不理想的情况，但是当你在 场的时候，这些游戏测试问题可以得到适当的挽救。这在盲测中是无法实现的，因而你必须特别谨慎，确保你的测试者拥有为你的游戏进行测试的一切所需东西。这包括：

1、一套完整的游戏组件。再三审查清楚，确保你提供的游戏包内有玩家所需的全套东西。

2、你的游戏包内的项目清单（包含测试游戏所需的一切组件），这样测试者就可以亲自确认没有东西被遗漏。

3、一套描述如何玩游戏的完整规则。

4、一套独立的指导，阐述如何开展盲测。是否存在你特别希望玩家去做的某些测试？你只是想知道他们是否能够打通游戏？还是想知道他们觉得游戏是否有趣？你是否想让他们找 出规则的漏洞和不平衡性？

5、一套指导规则，阐述在总结游戏测试时应当做什么。测试者要如何联系你（游戏邦注：例如提供电话号码、邮箱地址等）？当他们联系你的时候应当告诉你什么内容？如果你不 提供他们反馈所需回答的问题清单，他们可能就会天马行空地“畅所欲言”，这样你得到的结果就会很混乱。要考虑下对你来说获得何种信息最有价值，何种反馈对你来说最为重要，然后要求测试者提供这些信息！

你要如何将游戏包提供给游戏测试者呢？如果他们与你住在同一个地区，你可以直接将用于测试的游戏原型交给他们。如果盲测者在外地，这就会带来额外的挑战。有两个选择可 供你考虑：

首先，你可以通过邮政将游戏原型邮寄给他们。有些测试者可能较远，仅这个步骤就会花费大量的时间（游戏邦注：也会增加开发的成本），因而要制定相对妥善的时间计划。如 果你希望玩家将原型交回给你，那么可以考虑使用往返邮件。

其次，你可以通过电子邮件来递交所有的东西。发送可以打印和组合成可玩游戏原型的文件，包括如何打印这些东西的指导文件。尽你所能地减少游戏测试者的工作量。毕竟，你 已经让他们花费时间来帮你测试游戏，不可再让他们花上几个小时的时间来打印和组建游戏原型。同时，如果你期望盲测者能够提供最真实的反馈，那么就要确保材料打印的成本 较低，同时可用性很高。比如，如果用普通纸张打印即可，就无需要求使用硬卡片纸（游戏邦注：因为这可能会让测试者再花时间跑趟印刷店）。

意外情况应对措施

在现实情况中，游戏公司绝不会只有单个盲测群体，通常都会准备数个后备军。除了更多的测试者可以提供更多数据这个显而易见的原因外，还有个原因是盲测群体并不可靠。因 为你不在场，他们可能只花一点点时间来做测试，而反馈时间可能会拖延得更久。有些群体可能会遗失部分游戏组件，或者忘记了他们的任务，或者很可能因为生活中的其他事情 而将你的游戏放在一边。你邮寄的游戏原型也有可能遗失而无法被测试者拿到。在盲测的这个阶段，你可能会发现自己处在非常令人懊恼的境地，测试结果迟迟不来，或者没有在 计划内的时间内获得反馈信息。

你有3个选择来处理这个潜在的问题。何种方法最合适要取决于你自身的情况。

1、你可以设立多个盲测群体。通常来说，设置3个较为安全。如果1个或2个群体没有反应，你至少可以获得部分结果（游戏邦注：应当注意的是，如果你与其他参与者进行“盲测 交易”，这就意味着你需要测试3个项目，因而要确保自己有足够的时间）。

2、你可以选择你认识、信任和可靠的盲测者。如果你将游戏发送给某些总是信守诺言的好友，你就不用担心他们不给你提供反馈。

3、你可以抱侥幸心理，祈祷这些糟糕的事情不发生在你身上。但在此不推荐专业游戏项目使用这种方法。

什么是游戏平衡性？

在双人游戏中，“平衡”通常指所有家都不具有任何不公平优势。但此词也也出现于单人游戏中，其中游戏玩家未面临任何除游戏本身外的对手，游戏可能存在的“不公平优势” 可以视作挑战。我们也许会说《Magic: the Gathering》的个人纸牌具有“平衡性”，即使是在所有玩家都能接触这些纸牌的情况下，这样任何个人都未存在任何有利条件。这里 出现什么情况？

就我的经验来看，通常我们谈论“游戏平衡性”主要指下列4种情况。具体情境通常能够清楚呈现我们谈论的是哪种情况：

1. 在单人游戏中，我们以“平衡性”形容挑战水平是否适合用户；

2. 在非对称多人游戏中（游戏邦注：即玩家起始位置和资源不同），我们以“平衡性”形容某玩家的起步是先于其他玩家。

3. 若游戏存在多种获胜策略或路线，我们以“平衡性”形容某种策略是否优于其他策略。

4. 在包含若干类似物件的游戏机制中，我们以“平衡性”形容物件本身，尤其是判断不同物件是否具有相同成本/效益比例。

下面我们就来详细分析各点内容，然后我们会重温平衡游戏的若干实际技能。

单人游戏的平衡性

在单人游戏中，我们以“平衡性”形容挑战水平是否适合用户。

注意通过体验游戏，用户最终会变成熟练玩家。这就是为什么电子游戏的后期关卡要比前期困难得多。形容单人游戏难度随时间而变化的专有名词是：节奏。

游戏设计师此时面临一个明显问题：我们如何把握什么是“合适”挑战水平？当然我们知道瞄准成人的逻辑/谜题游戏要比同类儿童游戏复杂很多，但除此之外，我们如何知晓什么 太难，什么太简单？最明显的答案就是：游戏测试。

但这依然存在另一问题：不是所有玩家都一样。即便就小范围的目标用户而言，他们依然呈钟型曲线分布，有些玩家非常老练，而有些则相反。在进行游戏测试时，你如何知晓玩 家分布在钟型曲线的何处？若你只是涉猎测试，最理想的方式是覆盖大面积的测试者。当你获得大量用户的反馈信息时，你就能够大致知晓总体分布。随着设计经验的增多，你对 用户的了解就会越多，此时你只需通过少量用户便能得到同等有效信息。

即便你清楚如何调整游戏难度，目标用户置身何处，面对用户多元化的情况，你如何选择游戏挑战水平？无论你采取什么措施，游戏总是在某些人看来太难，而在某些人看来太简 单，所以你将处于必输局面。若你必须选择某种水平的关卡，根据概测法，你通常会瞄准曲线的中间部分，因为这样你能够囊括最多用户。另一方式通过提供多种难度水平、障碍 或系列规则组简化或强化内容，从而起到支持两端用户的目的。

非对称游戏的平衡性

在非对称性多人游戏中（游戏邦注：玩家未基于同等位置和资源出发），我们以“平衡性”形容某起点位置是否更易于获胜。

真正对称的游戏很少。在我们看来，国际象棋、围棋之类的经典游戏具有对称性，因为每个玩家都以相同棋子数量开始游戏，遵照相同规则，但这里存在一个不对称情况：有个玩 家可以先走！若你修改游戏，让两个玩家悄悄在纸上写下自己的操作，使得移动能够同时进行，游戏就具有完全对称性。

这带来一个有趣问题：若游戏具有对称性，你是否就无需担心游戏的平衡性？毕竟两位玩家都以相同资源和初始位置开始，所以从定义来看，没有玩家具有不公平优势。这完全正 确，但设计师需考虑其他类型的平衡性，尤其是游戏是否存在优势策略。只是让所有玩家处在同等位置无法令你摆脱困境。

纵然游戏具有非对称性，你为何要费神进行平衡？一个简单的答案是：玩家通常希望在其他条件都相同的情况下，游戏不会给予某玩家任何天然优势或劣势。

非对称游戏通常更难于进行平衡。越是不对称，测试过程就越要谨慎进行。达到此种平衡的一个最简单方式是建立各玩家间的资源联系。若你设定在游戏玩法中，1个苹果等于2个 橘子，那么以1个苹果开始游戏的玩家就与以2个橘子着手的玩家就保持平衡。

有时，玩家间的差异很大，无法进行直接比较。有些游戏不仅给予玩家不同起步资源和位置，还提供不同体验规则。有些玩家能够特别享有某些资源或技能。游戏常见的一个不对 称情况就是向玩家呈现不一致的目标。直接比较玩家的难度越大，游戏测试的工作量就越艰巨。

游戏策略的平衡性

若游戏具有多种获胜策略或路线，我们以“平衡性”形容某策略是否优于其他策略。

也许有人很好奇为什么要费心于此？若游戏顾及各种策略，但某策略比其他策略强大，利用最佳策略不就等于让玩家获得胜利？只要没有任何玩家具有不公平优势，游戏转变成“ 找到最佳策略便胜出”模式有何不可？

这里的问题是，只要找到优势策略，聪明的玩家就会忽略所有次佳策略。所有非优势策略组成要素的内容瞬间就会变得无关紧要。嵌入单一制胜策略的游戏本身并未存在任何问题 ，但在这种情况下，设计师应该移除次佳策略，让游戏变得更合理。若你融入次佳选择，这些就会变成错误决定，因为游戏只有一个解决方案。

若融入多个潜在获胜策略很有必要，那么这些策略富有平衡性会让游戏更有趣。而这些归根到底都在于游戏测试。在这种情况下，当玩家体验你的作品时，查看是否存在某策略的 运用频率超过其他策略的情况，哪种策略更倾向带来胜利。若游戏有若干道具供玩家购买，是否有哪些道具玩家会优先购买，而其他道具则鲜少有人问津？若玩家在每个回合都具 有行动选择，每次测试的赢家是否进行某操作的次数比其他玩家多？

单凭游戏测试无法证明某策略缺乏平衡性，但这清楚说明你需要就游戏的某些内容进行深入剖析。有时，玩家采取某策略是因为它非常显眼或简单，而非由于它是最佳选择。有些 玩家会回避那些过于复杂或需要技巧的内容，即使这些内容长久来看作用显著。

游戏物件的平衡性

在包含若干相似物件的机制中（游戏邦注：例如集换纸牌游戏的纸牌，角色扮演游戏的武器），我们以“平衡性”形容物件本身，尤其是不同物件是否具有相同成本/效益比例。

这种平衡性主要瞄准给予玩家若干物件选择的游戏类型。下面是几个例子：

* 集换纸牌游戏的纸牌。玩家基于所收集的系列纸牌创建牌组。选择添加哪些纸牌是游戏结果的关键，设计师试着让各纸牌保持平衡性。

* 某些战争游戏和即时策略游戏的道具。玩家能够在体验过程中购买道具，不同道具具有不同能力、移动率和战斗优势。设计者需试着让这些道具保持平衡性。

* 角色扮演游戏中的武器、道具和魔力等（不论是桌面，还是电脑/掌机内容）。玩家也许会购买这些内容应用于战争中，这些道具具有不同成本、统计值和能力。设计师需让这些 物件保持平衡性。

所有这些情况都要确保达到两个目标。首先就是防止游戏物件过于薄弱，相比其他物件变得微不足道。再次变成玩家的错误选择，因为他们很快就会发现自己得到或购买的物件缺 乏使用价值；因此物件完全是在浪费玩家的时间。

第二个目标是防止游戏物件过于强大。任何变成优势策略的游戏物件都会让其他物件在对比之下变得毫无用处。通常若你需选择制作过弱或过强物件，最好还是朝过弱靠拢。

若两个物件具有相同成本/效益比例，他们就具有平衡性。也就是说，你获得某物件的代价应同你从物件中得到的利益相称。成本和利益无需完全一致。但当比较两种不同物件时， 成本/收益比例应大致相同。

平衡游戏物件的方式：传递性、非传递性及独特性

我遇到3种平衡游戏物体的基本方式。首先就是所谓的传递关系。用更通俗的话说，就是成本曲线。这是平衡游戏物件最直接的方式。大体就是找到预期成本/收益比例。这也许呈 线性分布，也许呈曲线态势，完全取决于游戏，但游戏测试、实验和直觉能够帮你判断它们究竟属于什么关系。

下步就是将所有成本和利益简化至某些能够比较的数值。将物件的所有成本累加起来；同样合计所有收益。比较二者，看看成本是否创造合理的数值回馈。

此方式通常用于集换纸牌游戏。若游戏有既定成本曲线，那么通过既有混合效应创造新纸牌就简单得多。在《Magic: the Gathering》中，若你想要创造包含既有颜色、能量、韧 度和系列标准技能的新生物，其中已知某些成本，设计师便能够准确告诉你对应成本是多少。融入更多技能就会带来更多成本，降低成本就需要移除某些统计值或技能。

第二个方式就是游戏物件间的非传递关系，更通俗的说法是石头剪刀布关系。在这种情况下，成本和利益也许没有直接关系，但游戏物件本身存在联系：有些物件本身优于其他物 件，但依然比某些物件略低一等。游戏“石头剪子布”就是典型例子；三种出法都没绝对优势，因为每种出法都具有平衡关系，打败其他出法但又输给第三种出法。

这点也体现在某些策略游戏中。在很多即时策略游戏中，各道具间都存在某种非传递关系。例如，常见情况就是步兵比弓箭手强，弓箭手比飞行员强，飞行员比步兵强。游戏的很 大部分内容都是对照对手设定道具位置。

注意就如前个例子所述，传递性和非传递性关系能够结合起来。在典型即时策略游戏中，道具具有不同成本，所以脆弱弓箭手依然会被强劲飞行物打败。同类道具存在传递关系， 但不同类道具则存在非传递关系。

非传递关系能够通过矩阵和基本线性代数解决。例如，剪刀石头布的解决方案是你设想每种出法的比例与对方相当：那就会出现1：1：1。现在假设你稍微修改游戏，凭借石头胜出 能够得到3分，凭借布胜出能够得到2分，凭借剪刀胜出能够得到1分。现在的预期比例是多少？若你希望玩家按一定比例运用某道具，平衡性良好的非传递关系就是很好保障。

第三种平衡游戏物件的关系是让所有物件别具一格，能够进行直接比较。由于物件间无法进行正式数值比较，唯一的平衡方式就是进行额外测试。

这三种方式都存在某些联系。传递关系主要依靠设计师找到正确成本曲线。若你计算错误，游戏的所有物件都会出错；若你发现某块内容缺乏平衡性，你就需要调整所有内容。测 试完再创建传递关系要比提早设计简单得多。由于很多东西依赖于正确计算，我们通常要进行反复试验，因此会消耗很多时间。

非传递关系需要解决非常棘手的算术问题。另一缺点就是需要谨慎行事，否则就会给人翻版剪刀石头布的感觉（游戏邦注：这会让玩家丧失兴趣）——很多人觉得非传递关系不过 就是猜谜游戏，所有决定都不是基于策略而是靠运气和随机性。

“奇特”关系很难进行平衡，因为在这里你无法运用原本能够实现此目标的工具——数学运算。

3种常见游戏平衡技巧

通常我们能够通过3种方式平衡游戏：

* 运用数学运算。在游戏中创造传递或非传递关系，确保所有内容同成本匹配。

* 运用设计师直觉。调整游戏平衡性直到你“感觉不错”。

* 运用游戏测试。基于测试结果调整游戏（在测试中，老练玩家根据指示在游戏中探索，争取获胜）。

这些方式都有相关挑战性：

* 数学运算很难，而且会出现失误。若公式错误，所有游戏内容都会发生偏离，这不利于快速建模。某些奇特游戏技能或物件若过于罕见也许就无法进行数学运算，需要利用其他 平衡方式。

* 直觉常出现人为误差。这并不绝对；不同设计师对于游戏的最佳设计会有不同看法。这在大团队项目中尤其危险，其中某位设计师也许会在项目中离开，而另一设计师不知如何 接手。

* 游戏测试取决于测试者的质量。测试者无法发现游戏中的所有平衡问题；某些问题会沉寂几个月或几年都未被发现。更糟的是，有些测试者会有意不向你展示某些规则利用技巧 ，因为他们计划在游戏发行后将此运用于游戏体验中。

设计师要怎么做？尽自己所能，把握所有平衡技巧的利弊。作为游戏玩家，下次你碰到平衡性糟糕的游戏时，请体谅设计师要做到尽善尽美绝非易事。

更多游戏平衡技巧

下面是若干建议。

把握游戏的不同物件和机制及它们之间的关系。当然你应该在游戏设计初期就完成这些任务，但当你开始锁定细节内容时你很容易就会忘记把握大局。当你打算调整游戏内容时， 有两点需要注意：

1. 游戏的美学核心是什么？此调整是否能够支撑核心？

2. 着眼机制的相互关联性。若你调整某内容，需知晓其他内容也会受到影响。独立游戏元素鲜少出现在真空状态，调整某要素通常会带来涟漪效应。通过把握机制和物件间的关系 ，我们很容易预测机制调整的二级影响。

每次进行一个调整。我们之前就谈到这点，但这需要忍受重复性。若做出调整后某内容出现中断，你就无法获悉这是由哪次调整所引起的。

学会运用Excel。你可以采用任何电子表格程序，但微软的Excel无疑在游戏设计师中颇受欢迎。当我称电子表格在游戏设计中非常重要时，很多人都觉得我有些不可思议。下面是 些电子表格的应用体现：

* Excel让我们得以轻松记录和组织内容。罗列所有游戏物件和统计数据。就角色扮演游戏来说，罗列所有武器、道具和怪兽；就桌面战争游戏而言，罗列所有道具及其统计数据。 任何你将在指南参照图表中找到的内容也许最初都是在设计师的Excel表格中诞生。

* Excel非常适合记录任务和数据，这对包含众多机制和部件的复杂游戏来说作用很大。若你看到桌上布满涉及大量怪兽及其相关数据的文稿，其中也许还记录怪兽的美工制作是否 完成，怪兽数据是否已进行平衡或测试。

* 电子表格有助于搜集和编辑游戏数据。在各玩家拥有众多数据的运动游戏中，是否所有团队都具有平衡性？合计或平均各队的所有数据，你就能够把握各团队的优缺点。在融入 传递关系的游戏中，是否所有游戏物件都具有平衡性？在电子表格中合计所有成本和利益。

* 你可以通过电子表格运算模拟数据。通过生成随机数据，我们就能够获悉此类信息：一定范围物件的破坏频率，从而把握总体范围和结果分布。

* 电子表格能够帮你查看游戏调整的因果关系。通过基于特定你希望调整的数值创造公式， 你就能够调整某数值，然后查看其他相关数值会发生什么变化。例如，若你制作的是大 型多人在线RPG，你就能够通过Excel计算武器每秒带来的破坏性，然后立即获悉调整基础破坏、准确性或攻击速度将产生的变化。

运用“翻倍规则”。假设你知道游戏有某些数值过高，但你不知道此数值是多少。也许只是有些过高，或者有些不妥。无论是哪种情况，将其减半。同样，若你知道某数值过低， 无论低多少，将其翻倍。若你不是100%确定正确价值所在，将其翻倍或减半。

从表面数值来看，这听起来有些荒谬。若宝石成本的偏低程度只是10-20%，翻倍的激烈举措将产生什么影响？在实际操作中，其可行性体现在如下几方面。首先，你也许认为这只 是稍微偏离，完全错误；若你只进行微调，而数值需要翻倍，这需要你不断重复方能到达你原本需要达到的标准。

但翻倍规则存在一个更突出的优点。游戏设计是个发现过程。实际情况是，你并不知道平衡游戏的正确数值；若你知道，游戏早已得到平衡。若某游戏数值发生偏离，你就需要找 到正确数值，所采用的方式是调整数值，然后查看所出现的情况。通过进行大幅度调整，你就会看到此数值给游戏带来的影响（游戏邦注：也许这只需要小幅调整，但通过翻倍或 减半某数值，你将更深入了解自己的游戏）。

有时你会发现较大幅度调整游戏能够以预想不到的方式改变游戏机制，但此变化会让设计变得更杰出。

平衡首回合的优势。尤其在回合游戏中，玩家在开始时存在某细微优势（或劣势）的情况非常普遍。情况并非总是如此，但当出现暗此种情况时，你可以通过系列常见技巧进行弥 补：

* 替换初始玩家。例如在4人游戏中，你应在每个完整回合后将下回合的初始玩家替换为左边的用户。这样此回合优先的玩家就会在下回合最后开始。

* 给予劣势玩家额外资源。例如若游戏目标是在游戏结束时争取获得最高分，那么你要让玩家以不同积分开始游戏，让最后进行的玩家获得额外积分补偿。

* 降低发起玩家初期回合的效率。在纸牌游戏中，玩家通常在轮到自己时出4张牌。你可以进行调整，让初始玩家出一张牌，下位玩家出两张牌等，直到所有玩家都出4张牌。

* 对于非常简短的游戏，不妨设置系列游戏回合，让所有玩家都有优先机会。这在纸牌游戏中很常见，其中完整游戏体验通常经由多人之手。

在学习规则时将其写下。设计游戏的过程中总是会有成败。你将从二者中学到东西。当你发现游戏设计“法则”或新游戏平衡技巧时，将其记下，定期翻看笔记。遗憾的是，鲜有 设计师能够真正做到这点；因此，他们无法将自己的经验传递给其他设计师，他们有时会在许多作品中犯相同错误，因为他们忘记早前得到的教训。

平衡角色

在早前的设计师生涯中，我非常着迷于游戏平衡。“有趣游戏即平衡游戏，平衡游戏即有趣游戏”是我的真言。我知道我常因不满作品缺乏平衡性，建议即时进行修复而惹恼众多 前辈。

虽然我依然认为平衡性非常重要，是游戏设计师不可或缺的技能，但我现在的态度要温和许多，我知道有些作品虽然缺乏平衡性但依然非常有趣。我也发现有些作品之所以非常有 趣是因为它们故意融入不平衡因素。而且有些作品虽然极度缺乏平衡性但依然在市场中表现突出。这些都是罕见情况。但需注意的是本文所谈及的观点还是要以遵循游戏终极设计 目标为前提。这些技巧只是你的工具，而非主宰因素。

什么是用户界面？

通常，我们总是会将用户界面（UI）与软件应用联系在一起。这个术语指的是软件中与用户具有直接交互作用的内容。它包含着用户可以随时获取的一些选择，这些选择如何显示 于电脑屏幕上以及用户与电脑间的相互作用（通过鼠标/键盘，游戏手柄等）。一般来说，电子游戏的用户界面分为2个部分：输入界面（即玩家如何控制游戏）和输出界面（游戏 如何向玩家传达他们行动的结果以及游戏状态的其它方面）。

如果你制作的是非数字游戏？它们是否也拥有游戏界面？当然，特别因为这种游戏缺少电脑对于游戏规则的控制，你更需要把握好它们的游戏界面。如果玩家并不理解非数字游戏 规则，他们便会选择停止游戏。作为游戏设计者，你最不希望看到的便是你那精心雕琢的游戏机制和游戏体验因为界面问题而毁于一旦吧。

在非数字游戏中，用户界面是指游戏组件本身，它们既可以推动玩家与游戏进行互动（通过操控游戏组件）也可以用于接收反馈（通过观察游戏状态）。所以我们今天真正要讨论 的话题是关于设计最后的游戏组件。

用户界面设计

如何才能凸显你的用户界面？从两个方面进行分析：

容易使用。如果你已经知道了自己想要做什么，那么用户界面能否帮助你更加快速且轻松地完成预期任务？

容易学习。如果你是一款游戏的新玩家，你是否能够轻易地从用户界面获得相关信息，并了解自己能够在游戏中做些什么？

但是通常情况下我们很难同时权衡这两方面。举个例子来说，电脑上有一个特殊的“热键”设置（Shift/Art/Ctrl/Cmd组合键等）能够帮助我们更快速且更容易地执行一些普通任 务，如保存文件或者在不同应用之间做切换。但是如果热键是完成任务的唯一方法（就像一些早久的文字处理器缺少菜单选项），那么用户便很难在第一时间学习并了解该应用。

在桌面游戏的信息表达方面，你也常常能够看到这种权衡点。对于资深游戏玩家来说，图表，附录，关键词，特殊标志以及图标等能够帮助他们更好地了解游戏状态，但是对于那 些根本不了解这些标志的新手玩家来说，只会因此更加疑惑。你也可以用普通写法去描述这些内容，以此让新玩家能够对此一目了然，但是因此也会浪费那些已经掌握游戏规则的 玩家的时间，强迫他们反复地吸收自己已经掌握的内容。

有时候，你也可以同时包含这两方面内容。现代软件应用便同时包含了热键和菜单选项，有些甚至还有“初学者”模式，即隐藏了一些高级功能让菜单显得更加简单，并让用户更 容易了解软件。纸牌游戏《万智牌：旅法师对决》虽然包含了关键词，但是也通过插入式方法向那些有疑惑的玩家解释了这些关键词的意思。

好好考虑你的游戏机制以及玩家在遵循这些机制时需要做些什么。如何做更好地强调措辞表达而不会让新手玩家感到疑惑？或者如何做才能让资深玩家感受到更加流畅的游戏体验 而不再只是反复记录一些内容或执行一些自动步骤的体验。

2个可用性模式

计算机应用的可用性有两个相关概念：用户模式和程序模式。用户模式是指用户（也就是玩家）对于计算机运作的看法。而程序模式便是指软件如何正常运转。（在非数字游戏中 ，“程序模式”是指设计者制定好的真正游戏规则，而用户模式则是用户对于这些规则的理解。）

问题就在这里。程序模式永远是对的。而如果用户模式和程序模式相互一致，也就没有问题。但是如果两者出现了分歧，那么当玩家尝试着去做一些事并有所期待时，往往只能得 到相悖的结果。这种情况要是出现在电脑游戏中，将会挫败玩家的斗志，从而让评论者认为这只是一种“拙劣的游戏控制”。

在桌面游戏中，如果用户模式和“程序”模式相违背，玩家可能会因此违反游戏规则而错误地进行游戏。有时候这会让玩家感觉到自己正在进行一种低等的游戏体验，因为游戏的 某些方面已经失去了平衡。而有时候虽然玩家也会觉得游戏体验很棒，但是后来，当他们与其他玩家一起“正确”玩游戏时，他们之间便会出现关于规则的分歧。

改变用户模式

我们经常能够在游戏测试中遇到用户/程序模式不协调的情况。就像是：在每一个测试小组中，总是会有些玩家在第一次接触游戏时出现一些错误。这就是不符合“容易学习”规则 而造成的问题。

但是更严重的问题还是来自于违背“容易使用”规则的用户界面。就像是：一个或多个玩家总是会不小心违反游戏规则。你明确地向他们指明了要点，他们也相对地改正了自己的 行为。但是当再次面对相同问题时他们却会因为忘记，而一次又一次地犯下相同错误。然后反复向你道歉，最终让玩家变成了一个“愚蠢”的角色？这应该不是你想要看到的吧。

在这种情况下，最理想的解决方法便是改变用户模式。也就是你需要因此改变玩家的期望值或行动以匹配游戏中的“正确”模式。但是不幸的是，这通常很难实现。因为人类是习 惯性的动物。我们创建了与周遭世界相联系的心理模式，并牢牢依赖于这种模式。而改变模式是一个相对缓慢的过程，需要我们投入更多的努力，但是却很少人愿意在游戏中投入 这种努力。

为了在我的课程中讲授这点内容，我列举了战斗机的设计故事。很久以前，有个军队注意到一种特别的飞机引发飞行员意外弹射（游戏邦注：即飞行员弹射椅会随机激活危害飞行 员的安全）的频率远远高于其它类型的飞机。按照军用飞机的成本计算，这种情况的发生会引起高额的成本损失，所以军队便迅速召集了工程师以找出问题所在，但是最终却仍未 识别任何可能的机械或电力问题。最后，有人提出从意外发生弹射的飞行员所训练的飞机身上找问题。而结果也证明这是一个非常棒的主意！因为所有在训练飞机上接受实战培训 的飞行员所控制的节流阀和弹射椅都跟实战飞机上的设置完全相反。所以当这些飞行员在驾驶这种新飞机时，他们原来关于飞机操纵的心理模式已经牢牢根植于心中，新飞机的培 训内容也很难改变这种模式。

识别用户模式

好吧，既然我们无法改变用户模式，那么当你发现用户模式与游戏相互矛盾时，你就应该改变游戏界面以适应用户模式，或者因此触发一个完全不同的新用户模式。但是，你如何 能够第一时间掌握游戏的用户模式？

最快捷的方法便是主动询问。寻找一些正在玩一款与你的游戏类似的游戏的玩家。询问他们如何看待游戏的进程（或者他们将如何完成游戏任务，或者他们有何应对方法）。当你 多问一些人之后，很快就能够得到明确的一致意见了。

另外一个识别用户模式的简单方法便是进行游戏测试。观察玩家何时玩游戏，记录他们何时开始出错等。

最后，如果你的游戏模式仍然趋于矛盾，你就应该好好考虑是那一环出了问题。只有在一切条件都出于相互平衡的状态下，玩家才能顺畅地玩游戏。

这是谁的责任呢？

有时候你会感到好奇，为何很多人会把可用性问题归咎于游戏设计者。毕竟，如果你创造了一款优秀的游戏，并设定了合理的游戏规则，玩家就有必要好好阅读并遵守这些规则。 为何他们违背了游戏规则却变成了你的错？有些人真的很没有游戏天赋，或者说并未认真地玩游戏，而为何作为聪明的设计者你却需要为这些人的错误负责呢？

好吧，我需要澄清的是，首先，这并非玩家的错。他们也许是从别人那学习到如何玩游戏，或者他们处于一个容易分心的环境，所以很难一心一意地阅读游戏规则。他们可能根本 就未接触到游戏规则，因为他们可能购买的是二手游戏，而已经略过了规则环节。可能规则的陈述并不是使用他们所了解的第一语言等等。如此可以解释为何如此多聪明，理性的 玩家经常会违背规则的原因。所以千万不要贬低这些玩家的价值，你应该多投入点时间帮助他们更好地阅读游戏规则。

其次，很多可用性问题看似是用户（玩家）的错，但却往往都是用户界面引发的问题，但是却可以进行修改。如果你的游戏更加容易操作，玩家也不会容易犯错了。作为设计者， 你应该为你的游戏可用性负责，如此你将发现玩家会更加快速地掌握游戏，犯更少的错误，并且拥有更棒的游戏体验。

创建优秀的用户界面

既然我们知晓了如何识别糟糕的用户界面，我们又该如何创作出优秀的用户界面呢？一般来说，优秀的用户界面包含两方面内容：

符合用户的期待；

即时给予用户反馈信息。

如果游戏未符合用户的期待，那就是我们上述提到的用户模式与游戏模式出现了分歧。还有一种设计用户界面的方法：即时给予玩家反馈，让他们知道自己做的到底是对还是错（ 并且能够第一时间意识到自己做错了以及错误的原因）。

以下是从另一个角度去看待优秀用户界面：

让玩家更容易做对事；

让玩家难以做错事。

举个例子来说：假设你有一款拥有许多符号的桌面游戏。也许你只有一套标记去记录玩家的得分，并在棋盘周围设置分数轨道。也许游戏棋盘中有一张划分了不同区域的地图，而 玩家在不同区域都安插了自己的军队。也许这里还有一个可进行采购和销售的全球市场，并且拥有一个市价清单以区分不同类型的产品。

虽然我们总是很容易混淆不同游戏数位，但是如果每一个符号都拥有不同的大小和形状，并且每一个符号所处的空间都有与之相对应的形状，情况又是怎样？如此，我们便能够更 加明确地判断小符号必然行走在小规模的分数轨道上，星形产品标记必然归属于星形产品价格轨道，以此类推。

玩家要如何记得在每个轨道上调整不同产品的价值？在轨道右边的棋盘上明确写明规则总结能够帮助玩家更好地记忆。如何解决战斗问题？在军队位置中印上单位强度，统计值以 及能力信息，而余下规则也会总结于棋盘上或者参考卡片上，再或者可以通过游戏前玩家间相互告知的方法解决。

当你开始设计用户界面时，可以参考以下过程：

首先，制作一份任务清单，帮玩家理清游戏路线，让他们能够更加轻松地面对游戏任务。

其次，特别留意那些常见任务，即玩家会频繁遇见的任务。而因为复杂任务的出现频率较低，所以不用特别在意。

反复进行游戏测试。

颜色的使用

合理使用的话，颜色能够帮助你更好地向玩家传达信息。这是一种非常有效的方法：颜色无需占据额外的游戏组件空间，因为组件本身就存在着，你需要做的只是为其上色。以下 是游戏中颜色使用的一些小窍门：

人类的眼睛最容易捕捉到的两种颜色是红色和绿色，其次便是蓝色。所以这几种颜色总是较为突出，能够轻易地吸引人们的注意；但是如果你使用过分明亮的色彩则很容易造成玩 家的视觉疲劳。

但是不要单纯地依赖于颜色，因为在你的用户中肯定也不乏色盲者。除了使用不同颜色，你还可以通过改变颜色强度（例如黑白两色也能给你带来不一样的效果）或者使用不同形 状等方法去区分不同物体。

利用色彩的一致性。如果你在游戏中使用同一种颜色去描绘多种物体，那么就说明这些物体之间具有关联性。例如我玩过的桌面游戏中，有五种不同的资源，而每一种都有独自的 颜色；每一位玩家也拥有属于自己的颜色，并且玩家的颜色会与资源的颜色出现重合，但是相同颜色玩家和资源之间并不存在连系。如此设置会让玩家感到疑惑，他们会想当然地 认为一个颜色的玩家必然拥有同种颜色的资源，但是事实却并非如此。

更多用户界面设计技巧

排名不分先后：

如果可能的话，采取自动操作或清除那些不包含任何有趣决策的任务。在电子游戏中玩家每次的点击或键盘按压，或者在桌面游戏中的掷骰子或翻转卡片都需要受到一些有趣动机 的影响。如果玩家首先接收到的是一些维护任务而在后来才能感受到决策乐趣，你便需要思考如何做才能让简化这些无聊的流程了。

使用视觉隐喻。如此我们更能看清它们分别代表了什么。如果你的玩家控制的是一些代表人的角色，你可以使用一些人型棋子，总比使用木质方块好多了。不同的棋子会让玩家对 游戏拥有不同的看法。

同样地，如果你在游戏中使用图标去代表特定的能力，也尽可能地选择类似于其代表形象的图标。

与同类型游戏保持一致。在角色扮演游戏中，红心代表生命值，蓝色水滴代表魔力。为何要这么做？因为其它游戏就是这么做的，而你的玩家也会想当然地如此理解你的游戏。

不要想着“这个太晦涩了，我们可以在手册中详细解释。”记住，你的玩家不一定拥有手册，或者不一定会去看手册的内容。所以你需要尽可能地让用户界面足够一目了然，然玩 家根本不需要借助手册的帮助。

经验教训

创造一个优秀的用户界面是一种不同于核心系统设计的技巧，但是却是个值得我们深入学习的技巧。你需要记住，用户界面设计是一个非常广阔的领域，而我们在本篇文章中讨论 到的还只是一点皮毛。

原因

有些人可能会产生疑问，为什么要将更高质量成分组装至游戏中呢？游戏的主要内容是机制，游戏棋子只是机制的呈现方式而已。因而，所有内容的质量应当是相同的。撇开UI问 题不谈，为何不只是将以前使用过的原型称为最终项目呢？

对上述问题，我的回应如下：

首先，如果棋子算是规则的呈现形式的话，作为设计师的你也应当给予同样的重视，这样游戏的外在美才能够与其机制的内在美相符。

其次，你应当为自己的游戏感到自豪。就设计而言，棋子同规则一样重要。棋子告诉玩家的内容是，游戏设计师觉得游戏有着足够好的质量，所以应当拥有高质量的成分。打个比 方，如果你是个厨师，你正在制作一个花生黄油三明治，或许食客并不介意在纸盘子上享用，但是如果你想让顾客有更好感觉的话，找个质量较好的盘子来盛装是个不错的做法。

再次，如果你计划最终将你的游戏商业化和出售，那么成分的质量是顾客首先看到的东西。许多欧洲游戏在包装盒正面印上亮丽的游戏成分，以此来作为卖点。他们在向玩家暗示 ：“如果你购买了这款游戏，你就可以得到这些成分。”即便你不打算出售自己正在制作的这款游戏，那么熟悉这个过程对将来的项目也是个重要的实践。

最后，应当记住的是，游戏体验设计师的能力。如果你忽略了某项每个玩家都将看到的东西，他们会对你产生何种想法呢？是否暗示着你对自己的项目并没有足够的关心，不愿意 投入更多的精力？是否意味着你并不以自己的作品为傲？是否意味着你缺乏信心？如果你计划将这款游戏（游戏邦注：或其他游戏）添加到你的职业设计简历中，应当明白它会让 雇主产生何种想法。你或许会为工作面试打扮梳理，同样，你也应当在游戏发布之前对其装扮一番。

反向美学

有些人可能会进一步辩解。有些商业游戏特地制作较差的机制承载方式。《Kill Doctor Lucky》（游戏邦注：原版游戏发行商的其他游戏与其情况相似）的首个印刷产品中，有只 有单色且纸张很薄的卡片，只有简单的文字，毫无艺术感科研。游戏甚至没有棋子或骰子等最常见的成分，游戏装在薄薄的纸质信封中出售，规则就印在袋子上，没有单独打印出 来的用户手册。在数字领域，《Kingdom of Loathing》这款在线浏览器游戏的游戏艺术简单而且劣质。看起来开发商好似根本没有在这方面努力过，但是他们的游戏依然拥有数量 可观的玩家。为何我们在自己的游戏中不能仿效他们的做法呢？

我想要强调的是，这些游戏事实上拥有很高的制作价值。每款游戏都持续性地提供视觉美学，而且游戏所产生的强大冲击力与制作者和游戏机制的价值一致。

在《Kill Doctor Lucky》的案例中，James Ernest表示正是那些不必要的成分使游戏变得过于昂贵。如果你拥有的其他游戏中已经有骰子的话，为什么还要在这款游戏中花钱买呢 ？诚然，所用的卡片确实很容易坏，但是如果你不小心弄坏它们的话，可以出去再买一付游戏。游戏的价格比你在星巴克喝的摩卡拿铁还便宜。

《Kill Doctor Lucky》是款模仿其他产品的游戏。作为模仿产品，开发商故意选择了低质量的艺术风格，这样才能与其他注重视觉艺术细节的同类产品形成鲜明对比。

因而，如果在你制作的游戏中，低质量的游戏成分可以发挥作用，那么可以选择这种方式。但是即便是这种情况下，每种成分的质量和外观的制作也是需要投入精力的设计决定。 将来你可能会发现，降低成分的质量比制作游戏高质量成分所需的技能更多。

游戏组件的制作技巧

卡片印制：

1、以厚卡片纸为材料，而不是标准的打印用纸。

2、如果你不选择彩印的话，至少可以考虑将内容印制在有底色的卡片上，选择一个与游戏其他内容相配的颜色。

3、确保卡片在印出后能够让玩家识别。有时，卡片印制出的效果不及电脑屏幕上的显示效果。

4、在打印程序中使用圆角矩形来印制你的卡片，然后自己用剪刀细心地裁剪。或者，如果你有切角器的话（游戏邦注：通常打印店里有），可以节省你许多时间。圆角卡片拿起来 更加方便。

5、如果可以的话，将卡片过塑。这会让你的卡片不易损坏而且防水，但这样做需要一定的成本。有个较为廉价的方法，有些商店提供喷涂塑料外层的服务，这种方法可以让你的卡 片手感类似于过塑过的游戏卡片。在喷涂时要注意，不可让卡片表面变得凹凸不平。

6、如果可以实现的话，在卡片双面都印上内容。应当注意的是，背面与正面是相反的，背面左侧的内容与正面右侧的内容相同。

棋盘印制：

1、不要将棋盘印在卡纸上。这与多数你见过的游戏棋盘相比显得较为易损。用纸板或泡沫芯曾来印制棋盘。

2、如果你必须将纸板裁切到特定大小，先在一个角上预先测试裁剪。有些工具的裁剪会让棋盘的边缘显得很糟糕，应当特别注意。

3、将整个棋盘印制在单独一张纸上需要很高的成本。可以选择的成本较低的方法是，将整个大棋盘分解成数个标准印制尺寸的小棋盘，然后将它们拼接起来。

4、要想制作可折叠的棋盘，将两个小的棋盘放在一起，然后用带子连接起来，在连接处留下空隙。这样当棋盘摊开时，玩家不会看到带子。

特色骰子制作：

1、印制在胶粘标签上，将它们切成所需大小，然后将它们贴在普通骰子的各个面上。

2、在骰子每个面的末端留一点空间（游戏邦注：也就是说，所裁剪的胶粘标签要比骰子每个面的尺寸小）。会可以避免小部分纸张在每个面的边缘重叠。

3、如果使用的是标准骰子（游戏邦注：底色为白色，上面使用黑色凹点），即便你贴上标签，黑点可能也会透视出来。如果出现这种情况，先在骰子面上放上1到2层得空白粘性标 签，然后再黏上所需的标签。这样做可以减轻或杜绝透视效果。

4、如果你有更高要求的话，有些游戏制造商会出售只带有凹点的空白骰子。这些骰子是最理想的材料，因为你可以直接将标签黏上，无需担心标签会因重复使用而脱落。但是，这 样的材料寻找起来较为困难。

棋子的涂色：

1、如果你拥有大量未上色的木质棋子（游戏邦注：比如正方体棋子或类似象棋中卒子的棋子），而且需要用颜色来区分，最简单得方法就是在碗中装上清水并加入些许染料，将棋 子浸泡其中，然后风干。我建议将这个步骤分为两个阶段。首先，用某个棋子来测试所有的染料，看看染色之后的效果。有些颜色可能会比较接近，或者你需要通过控制浸泡时间 来调整颜色的浓淡程度，最好先进行测试，以免毁掉所有的棋子。然后，在你得出制作方法之后，将所有剩下的棋子进行处理。

2、你也可以用画笔来为木质棋子上色，但是这要消耗更多的时间，而且是个乏味单调的工作。

3、如果你使用的是塑料棋子，那么最简单的方法是咨询供应商，看看他们是否已经制作出不同颜色的棋子。自己为塑料棋子上色并不是件简单的事情。如果你只能自行寻找方式来 区分各个塑料棋子，那么可以考虑使用不同颜色的带子，将其黏在棋子上，这比自己为塑料棋子上色要简单。

4、如果你使用的是金属棋子而且需要涂色，那么油漆可能是你最好的选择。出售小型金属制品的商店可能也同样会出售油漆和其他涂料。应当注意的是，这种方法较为昂贵而且需 要耗费时间，但是如果你会使用金属棋子的话，相比成本已经不算是个问题。

规则的印制：

1、规则成就游戏，因此别忘了这个最重要的方面。至少要将规则印制在质量较高的纸上。

2、根据你所设计的游戏，考虑是否有必要将规则“主题化”。比如，有关火车的游戏规则可以像火车时刻表那样布局。有关运营餐厅的游戏的规则可以用塑料的餐厅菜单来装饰。 有关收集经典艺术作品的游戏，可以在规则的页面中加上某些艺术作品。

3、确保规则印制所使用的字体可以让玩家清楚阅读。不要使用过于卡通画的字体，标题可以使用这种方法，但是规则的正文最好不要使用这个方法。记住，玩家能够轻松阅读才是 最重要的。

4、多次确认规则内容中没有拼写、语法和语义错误。或许你之前已经做过这项工作，但是最好再重复检查，花这个时间是值得的。

所有的内容都属于设计决定

如果你只是将大量随便的成分拼装起来，这也算是你自己做出的决定。如果你亲自修理自己后院中的树木，这也算是决定。简单地说，你对游戏所做的所有事情都是你自己的决定 ，你作为设计师应当要对其负责。

那么，大胆地做决定吧，但是务必要谨慎。考虑每个成分是否符合整体视觉效果和玩法体验的策略美学。

相关拓展阅读：篇目14，篇目15，篇目16，篇目17，篇目18（本文由游戏邦编译，转载请注明来源，或咨询微信zhengjintiao）

In 2006 at GDC, game designer and academic Jesse Schell said that the most important skill of a designer is to listen:

Listen to your playtesters. They may not be professional designers and their suggestions may seem to make no sense. But if they react in a certain way to your game, it’s up to you to figure out why.

Listen to your game. Games often seem to take on a life of their own once they reach a certain complexity, and it’s more important to make a great game than to make the game that you originally intended.

Listen to yourself. Every time you follow your instincts as a designer, whether you’re right or wrong, your instincts get better. (This is, incidentally, why a 20-year industry veteran is going to be a better game designer than a beginning college freshman, no matter how much “natural talent” either one possesses. There are no shortcuts. This is also why I’m having you make so many games over this summer, to get you to a higher level as fast as possible.)

Today, we cover the first of these: listening to playtesters. Once you are at a certain point in your game, you will want to playtest with some new people – preferably, the people in your target market, the ones who are representative of those you ultimately want to be playing your game.

Playtesting with gamers is very different from playing with other game designers. Done right, the feedback you can get from players in your target audience is even more meaningful than getting feedback from game designers, because you are seeing firsthand how your game will be experienced by the very kinds of people who will eventually be playing the final version. However, it is a very different skill. Non-designer playtesters will give a different kind of feedback, and it takes a bit more effort to find the root cause of problems that are identified. You have to be much more observant.

Readings

No readings for today. As with last time, if you know of any relevant readings you have encountered before, post it as comments to this blog post, or on Twitter with the #GDCU tag.

Street Performers

Have you ever seen a street performer? This is a musician, magician, juggler, mime, or other person who is performing for an audience of passers-by. These people rely on donations from observers; they do not get any pay other than what these strangers on the street choose to give them. Because of this, they tend to be very good at pleasing a crowd – if they aren’t, they don’t get to eat.

During the act, the audience is obviously paying attention to the performer. But what is the performer paying attention to? Next time you see one of these people, don’t watch the act, but instead watch the performer. They aren’t concentrating on themselves or their act, the way the audience is (the performer knows their own act inside and out, after all). Instead, they are watching the audience. They are looking for interest and excitement in the crowd. If they
see a positive reaction or a negative one, they will adjust their act accordingly, on the fly. Maybe this particular crowd likes magic tricks with coins but not cards, or they seem to like blues more than jazz, orthey’re more excited by juggling pins than balls. The performer’s most important skill is being able to read the audience.

Note that they do not ever stop their act to ask whether people are having a good time. They know by observing. They don’t have to ask.

What Does This Have to do with Game Design?

When you are playtesting with non-designers, your role is similar to that of a street performer. Don’t simply ask your playtesters if your game is fun; they may not be able to tell you, and if they do, they may not give you an accurate or precise answer. Instead, watch your testers as they play, and take notes:

What is everyone’s body posture? Are they leaning forward with interest? Are they leaning back in boredom? Are they standing up from excitement?

Where are everyone’s eyes going? Are they scanning the board constantly? Are the players looking at each other? Are they looking at you? Or are they looking around at the rest of the room, or counting the dots on the ceiling tiles?

What kinds of moves are people making? Are they playing aggressively or defensively? Are players cooperating and negotiating, or are they backstabbing each other?

Are your testers playing the game by the correct rules, or are they playing the “wrong” way, breaking rules or forgetting restrictions accidentally? Do your testers ever get stuck and need to look something up (or ask a rules question), or are they following the game flow smoothly?

How do your observations compare to the design goals of your game? Is your game meeting its goals, or is it falling short?

Note that all of these things may vary during a single play session. You may find that certain parts of your game generate more engagement than others. Your goal during the playtest session is to observe these things.

Preparing for a Playtest Session with Non-Designers

People who are not fellow designers are sometimes (not always) less tolerant of extremely rough prototypes. A typical gamer, when handed a stack of hand- written index cards and instructed to move pennies around on a game board that’s hand-drawn on notebook paper, may be concentrating so much on the poor quality of components that they have trouble thinking about the game mechanics. You may get a lot of comments about missing art or board layout, which are a waste of your time – after all, at this stage you just want to get feedback on the play experience, not the final artwork. We haven’t even started talking about the appearance of the game yet!

If you are lucky enough to have some playtesters lined up who can handle a rough prototype, then you might not need to do anything. For everyone else, it may be worth a little bit of time at this point to create some components that, while not necessarily high-quality, are at least close enough to fake it.

As with your rough prototype, you do not want to put too much time into revising your components here. The more time you put in, the harder it will be for you (emotionally, at least) to make massive changes.How do you make a prototype that looks better than hand-drawn, without taking too much time? Here are a few quick tips:

Google image search is your friend. If you want art for some cards or a game board, type in some relevant search terms. Copy and paste. You can do this in minutes. Steal other people’s artwork liberally.

For basic components like pawns or tokens, use game bits from other existing games you might already own (if you do not already have a selection of these). It gives the game a slightly more professional look than using bottle caps or pennies or pieces of lint.

For cards, you can create nice-looking ones in a program like Powerpoint or Visio without too much trouble. Standard-size cards are 2 ? inches wide and 3 ? inches tall. On a standard 8.5×11 sheet of paper, you can fit eight cards in a 4×2 grid with landscape orientation, or nine cards in a 3×3 grid if you use portrait orientation. Print out on standard paper and just cut with scissors.

If you want your cards to be easier to shuffle and hold, use plastic card sleeves (normally sold in game and hobby shops to protect collectible cards like Magic: the Gathering cards). Insert a standard card of some kind (either a Magic card or just cards from a standard Poker deck) so that there are uniform card backs, then add your slip of paper in front.

For a game board, printing it out on one or more pieces of paper is sufficient at this stage. You can create a board in Powerpoint or even in something as simple as MS Paint, using basic lines to make squares, the text tool to write text or numbers on the board, and copying/pasting art from other sources where needed or desired.

You may find other tools that you like to use. Feel free to post them here!

Running a Playtest Session with Non-Designers

Since you are going to spend so much time taking notes and observing, you will probably find it easiest if you do not actually play the game. You may be able to take the role of a player when testing with other designers, and you’re obviously taking on the role of all players when solo testing, but in the kind of testing we’re talking about today you should avoid playing so that you can focus all of your attention on how your testers are interacting with the game and
with each other.

If you didn’t before, you should formally write out a set of rules now. Hand the rules and components to your testers, stand back, and get out of their way. Let them know that you are there merely as an observer, not as a player and not as a resource. Instruct them to pretend you are not there, and to proceed as if the designer of the game were not in the room.

Your playtesters will probably forget this often. They will run into a place in the rules that is unclear, and they’ll have to ask clarification from you. Do not answer immediately. Instead, first answer their question with a question of your own: “If I weren’t here, and you had to make a judgment call on your own, what would you think?” Their answer may be the correct one… or it may be incorrect but enlightening. Either way, it will tell you how players are likely to perceive your game by default. After your players answer you, then you may give them the answer they were seeking. But don’t lose the opportunity to get a valuable bit of information in the process.

Sometimes your playtesters may not ask you, and they’ll simply start playing “wrong.” Maybe each player is supposed to draw two cards on their turn, but they only draw one. Or they skip the first step of every turn. Or they forget to apply the effects of some tiles in play. Resist the temptation to stop them. You will find this excruciating. There are few things as painful as watching people play your game as it was not designed. And yet, this is likely how people would play if you released your game at this moment, and this is something that is important for you to see, so that you can clarify the rules and game components later.

There is one other useful aspect to letting people play the game “incorrectly.” Sometimes you will find, quite by accident, that the way your testers are playing is actually better than your original rules. Most people, even non-designers, have a strong instinct towards play. Sometimes, people will violate the rules of a game because at an instinctive level, they are playing in a way that they believe will be more fun.

Finding Non-Designer Playtesters

Here’s the good news: finding non-designer playtesters is much easier than finding other game designers. There are more of the former than the latter in the general population.

This is where friends, family, and colleagues can become useful. They are often easy to ask for a favor. For many of us, they are local and available. If you somehow know no one in your local area (maybe you just moved), consider this just one more incentive to get out there and meet people – as if you didn’t already want to.

Do keep in mind that the people that know you are far less likely to give strongly negative criticism. They may tell you it is the best game they ever played, even if it isn’t, because there is an interpersonal relationship at stake that is likely more important to them than the outcome of some game project. In other words, expect some of these people to be big stinking liars. This is where observing them closely comes in; it is up to you to figure out what parts of the game are actually fun for these people.

Homeplay

Your homeplay this past Monday was to arrange for a playtest session with other designers. You may have already performed this playtest, or you may have just scheduled it to take place over the weekend, but that playtest session should be concluded before next Monday, August 17, noon GMT.

In addition, over the weekend, you should arrange a playtest session with non-designers, to take place after the designer playtest. This session can take place at any time on or before next Thursday (August 20), but it should be arranged (that is, you should have made plans with specific people) on or before next Monday (August 17).

Time permitting, you may continue to run additional playtest sessions, either with designers or non-designers.

Feedback

Do you know of any great articles on running playtests? Do you have any favorite tools using a computer to generate quality game components quickly and easily? Post them in the comments on this blog, or on Twitter with the #GDCU tag.

When your game is playtested without you (or another of the game’s designers) being personally present to observe, it is called blindtesting. This is the subject we cover today.

Readings

No readings for today. As before, if you know of any relevant readings you have encountered, post it as comments to this blog post, or on Twitter with the #GDCU tag.

The Challenges with Blindtesting

As you might imagine, blindtesting has a lot of problems compared with a playtest that you run in person:

Without you there, any issue the players run into is a show-stopper that prevents them from finishing.

Perhaps worse, the players may interpret the rules incorrectly and play anyway. If they are unaware they are playing “wrong” your test results may be skewed, and the testers won’t even know it.

Feedback is highly variable; as you have no doubt seen by now, some playtest groups are better than others. This problem is made worse when you are not present and cannot ask targeted questions.

You cannot observe in real-time. The only information you get is what the group can report back to you in retrospect. The fidelity of information is much lower than when you are present.

Setting up a blindtest takes a bit more time. You cannot simply bring your prototype with you to a friend’s house and play right then. You have to find a way to get a copy of your game into the hands of your testers, and then you have to leave. Then you have to wait while your testers play your game, on their schedule, and then finally get back to you with some results. Even in the best case, blindtest results may take a day or two to get back to you, which is far more than an in-person playtest which you can conduct in a matter of minutes or hours.

Blindtesting is therefore limited in the type of information it can provide, and the schedule on which it can provide it.

Why Blindtesting?

If blindtesting is so limited, why bother with it at all? What use is it?

This is a technique we borrow from science. Awhile ago, some researchers noticed that the results of an experiment would be different if the researchers are in the room. Sometimes, test subjects would say what they thought the researchers wanted to hear rather than what they actually thought. Sometimes, the researchers would give subtle non-verbal cues that neither they nor the subjects would consciously notice, but that would bias the results of the test. For
example, if the experiment is a taste test between two leading soft drinks, if the researchers know which drink is which and they know which one they want the test subjects to pick, they might suddenly find that all of the test subjects are choosing the “right” drink… but only because the researchers are (accidentally) telling them what to choose!The solution to this is the so-called double-blind experiment, where neither the researchers nor the test subjects know what the “right” answer is. This eliminates many sources of accidental bias, making the results of an experiment more valid.

Playtests share a lot in common with science experiments. In both cases there is a hypothesis (“I think this game is fun”), an experiment is designed (building a prototype), the experiment is run (the playtest), results are analyzed. The purpose of both is to find out more information about the inner workings of the system that you are studying.

Blindtests, then, are the only way to get a true idea of what your game is like “in the wild” – that is, how players will react to it if they have just purchased it from a store and are playing it for the first time, without a designer present at their table to answer questions.

When to Blindtest?

Because you can get so little information from blindtesting, it is not suitable for an early test when your game is in a rough state. The testers would likely run into problems, be unable to continue, and you would have spent a lot of time waiting for something that you could have figured out much faster with an in-person playtest. Blindtesting is most suitable near the end of development, when you already have a high degree of confidence in your game.

The purpose of blindtesting is to catch the non-obvious problems that you may not be catching in your in-person playtests, because you accidentally bias the results of the test by helpfully being available to answer questions. Even if your playtesters never have to ask you anything, the very knowledge that you could can sometimes make people relaxed enough to get through the rules, where they might otherwise get flustered and give up. Or, you might say some key piece of information when introducing the players to the game (“this is an auction/bidding game”) that is not written anywhere and clarifies a lot by creating some preconceived notions in the minds of your testers. Without you present, you’ll see just how accurate your in-person playtests are, and you may catch some surprising errors that you did not notice before.

Who to Blindtest With?

Most board games require multiple players. For practical reasons, most blindtests done with professional games are done with regular game groups. Some companies keep a list of volunteer groups and put out calls to their private list for playtesters; they will then send out advance copies of their game in exchange for feedback. For our purposes, this is unhelpful, because most of you do not work at such a company and do not have a database of volunteers to call at a moment’s notice.

Ideally, your blindtest should be with people who are in the target audience for your game. If you’re making a children’s game, your blindtest should involve kids in your target age range (and perhaps their parents). If your game is made for people who are already avid Eurogame players, you’d do well to find a group that plays these kinds of games regularly. And so on.

There are a few ways to find blindtesters for your Design Project in this course:

Your social network of friends, family, and colleagues. These people may be local, or they may live in another city or even another country from you. Since you don’t have to be present, at least this time, geography is not a barrier.

Other people who are taking this course. If you already have a local playtest group that you’ve used before, you can put out a call for help on Twitter or the forums. Offer a blindtest exchange: you’ll blindtest their game if they will return the favor with yours.

As a last resort, you can look outside of this course for other discussion forums or other online hangouts for board game designers and/or playtesters, and see if there is a method for recruiting blindtesters.

How to Blindtest?

With in-person tests you can afford to be a little bit sloppy. Maybe you accidentally left some of your game components at home, or some of your rules are a little unclear and need clarification. It’s not ideal, but a playtest session that runs into problems can be salvaged when you are there. With blindtesting, you do not have this luxury, so you must be extra careful to make sure that your testers have everything they need to give your game a proper playtest. This includes:

A complete set of game components. Double and triple check to make sure that you have everything the players need, together, in one package.

A list of everything that your package should contain, so that the testers can verify for themselves that nothing was left out (and if it was, it will at least give them a clue of what they need to supply as replacements).

A complete set of rules describing how to play. (The components list can simply be part of the rules.)

A separate set of instructions on how to conduct the blindtest. Is there anything in particular you are looking for the players to do? Do you just want them to see if they can play through the game? Do you want to know if they find the game enjoyable? Do you want them to try to find rules exploits and imbalances?

A final set of instructions on what should be done on conclusion of the playtest. How should the testers contact you (phone, email, etc.)? What should they tell you when they contact you – if you don’t give a list of questions for them to answer, you will just get whatever they happen to feel like telling you, making your results a lot less focused than they could be. Give some thought to what information would be the most useful to have, what kinds of feedback are most important to you… and ask for it!

How do you get your package into the hands of the playtesters? If they are local to you, it is as simple as taking your playable prototype and handing it off. If your blindtesters are not local, this presents additional challenges. You have two options here.

First, you can mail your prototype to them through the postal service. Depending on where they are, this step alone can slow things down considerably (not to mention making it more expensive), so plan your schedule accordingly. If you want your prototype back, consider including a return package inside the main one, already addressed to you and with postage already paid.

Second, you can handle everything over email. Send documents that can be printed out and assembled to make a playable prototype, and include instructions on how to print everything. Do everything you can to reduce the amount of work that must be done at the playtesters’ end of things. After all, you are already asking for their time in the form of a playtest; asking for another hour or two to print and cut sheets of cards is adding insult to injury. Along the same
lines, try to keep the cost of materials down and availability high if you’re expecting your blindtesters to provide their own. For example, do not insist on printing on heavy card stock (which may require a special trip to a print shop) when printing on plain paper will do.

Contingency Planning

In the field, game companies do not rely on a single blindtest group, but several. Aside from the obvious reason that more tests give more data, there is also the problem that blindtest groups are unreliable. Without you in the same room, they may take awhile to organize a playtest, and they may take even longer to get back to you. Some groups may lose the components, or forget about their obligation, or they may simply be so busy with other things in their life that your game takes lower priority. Or maybe you’ll send your game through the post and it will get lost. In this course, when you set up a blindtest, you may find yourself in the frustrating situation of waiting for test results that are simply not coming… or at least, they may not arrive within the schedule you set for yourself.

You have three options for dealing with this potential hazard. It is up to you which method best fits your personal situation.

You can set up multiple blindtest groups. As a rule of thumb, three is a fairly safe number. That way, if one or two groups don’t show, you’ll at least have some results. (Note that if you are doing a “blindtest exchange” with other participants of this course, that means you’ll be testing three other projects, so make sure you have time for this.)

You can choose a blindtester that you know and trust to be reliable. If you are sending your game to a friend who is highly organized and always keeps their promises, you may have confidence that they will get back to you when they say they will.

You can cross your fingers and hope that something bad won’t happen to you. This third method is not recommended for professional projects.When veteran gamers or game designers are playing a game, if they are doing too well or too poorly, they will often comment on the game’s balance. This word is important, but I fear it is often overused. Like the word “fun,” there are different kinds of balance, and understanding what game balance is and why it ’s important is what we cover today.

Why are we only covering this now and not earlier (like, say, at the start of the Design Project)? As mentioned earlier, balancing the game is something that is best left until after you have a good set of core mechanics. Balancing a game that is simply not meeting its design goals is a waste of time, and when you change the core mechanics you’ll just have to balance the game again. So here we are, with a work-in-progress that has survived multiple rounds of playtesting, and it is time to take it to the next level.

What is Game Balance?

In a two-player game, saying it is “balanced” usually means that one player does not have an unfair advantage over the other. But we also hear the term used in relation to single-player games, where there is no opponent other than the game itself, and any “unfair advantage” the game may have could just be considered a challenge. And then we may talk of individual cards in a game like Magic: the Gathering as being “balanced” even when all players have access to that card, so it does not give an advantage to any individual. What’s going on here?

In my experience, when we talk of “game balance” we are generally talking about one of four things. Context usually makes it clear which one we are talking about:

1. In single-player games, we use “balance” to describe whether the challenge level is appropriate to the audience;

2. In multi-player games where there is asymmetry (that is, where players do not start with exactly equal positions and resources), we use “balance” to describe whether one starting position is easier to win with than another.

3. Within a game, if there are multiple strategies or paths to victory that can be followed within the game, we use “balance” to describe whether following one strategy is better or worse than following another.

4. Within a system that has several similar game objects (such as cards in a trading-card game, weapons in a role-playing game, and so on), we use “balance ” to describe the objects themselves, specifically whether different objects have the same cost/benefit ratio.

Let us examine each of these more closely, and then we will go over some practical techniques for balancing your game.

Balance in Single-Player Games

In single-player games, we use “balance” to describe whether the challenge level is appropriate to the audience.

Note that, by simply playing the game and getting experience with it, your audience will eventually become more skilled at the game. This is one reason why the later levels of video games are usually harder than the earlier levels. (Recall that another reason is so that the gameplay matches the dramatic tension in the narrative.) The change in difficulty over time in a single game has a name: we call it pacing.

There is one obvious problem here that we face as game designers: how do we know what an “appropriate” challenge level is? Sure, we can say that a logic/puzzle game for adults is probably going to be harder than a similar game for young children, but beyond that… how are we supposed to know what is too easy or too hard? The obvious answer: playtest!

There is another problem, however: not all players are exactly the same. Even within a narrow target audience, players fall along a bell curve, with a few that will be highly skilled and a few that are the opposite. In your playtests, how do you know where your testers fall on that bell curve? If you are just starting out, the ideal thing to do is to use lots and lots of playtesters. When you have dozens or hundreds of people giving feedback on your game, you can get a pretty good idea of what the overall ranges are. As you gain experience as a game designer, you will get a better feel for your audience, and you will need progressively fewer and fewer playtesters to give you the same good results. (If you’re starting out but you don’t have the time or resources to do lots of playtests, you can sometimes fake it if you have some idea of where your own playtesters fall on the curve. Do they consider themselves above-average or below-average skill level, compared to the other kinds of people you’re making your game for?)

Even if you have a pretty good idea of how to modify the difficulty of your game and where your target audience falls, what do you choose as your challenge level when the audience is diverse? No matter what you do, your game will be too hard for some people and too easy for others, so this appears to be a no-win situation. If you must choose a single level of challenge, a rule of thumb is to aim for the middle of the curve, as you will get the most people (the widest possible audience) that way. Another way around this is to provide support for those at the ends of the curve, using multiple difficulty levels, handicaps, or alternate rule sets to make things easier or harder.

Balance in Asymmetric Games

In multi-player games where there is asymmetry (that is, where players do not start with exactly equal positions and resources), we use “balance” to describe whether one starting position is easier to win with than another.

Truly symmetric games are rare. We think of classic games like Chess and Go as symmetric, since each player starts with the same set of pieces and plays by the same rules, but there is one asymmetry: one player goes first! If you modify Chess so that both players secretly write a move on a piece of paper and then the moves are performed simultaneously, it becomes fully symmetric (and plays very differently).

This brings up an interesting question: if your game is symmetric, do you need to worry about game balance at all? After all, both players start with exactly identical resources and starting positions and so on, so by definition no player can have an unfair advantage. This is true, but the designer must still consider other types of balance, particularly whether there is a dominant strategy. Simply making all players equal does not get you off the hook.

Even if your game is asymmetric, why bother balancing it? The simple answer is that it is a typical player expectation that a game will not give an automatic advantage or disadvantage to certain players, other things being equal. (You can play around with this. The card game The Great Dalmutti, for example, intentionally casts players in unequal roles as a way of showing how life isn’t fair; but that is part of the game, and the instructions and mechanics go to great lengths to set player expectations accordingly. But if your game is not breaking this rule with specific intent, you should be thinking about how to make it as balanced as possible.)

Asymmetric games are, naturally, harder to balance. The more asymmetric, the more carefully the game must be playtested carefully. One of the easiest ways to confirm this kind of balance is to find ways of relating each players’ resources to one another. If you determine that in gameplay, one Apple is always worth exactly two Oranges, then a player who starts the game with an Apple will be balanced against a player starting with two Oranges.

Sometimes, players are so different that direct comparisons are impossible. Some games not only give players different starting resources and positions, but also different rules to play by. Some players may have exclusive access to certain resources or abilities. One common asymmetry in games is to give players different and conflicting objectives (for example, one team’s objective is to survive for some number of turns and the other team’s objective is to eliminate the first team before that many turns). The more difficult it is to make direct comparisons between players, the more you will have to playtest to compensate.

Balance between Strategies in a Game

Within a game, if there are multiple strategies or paths to victory that can be followed within the game, we use “balance” to describe whether following one strategy is better or worse than following another.

One might wonder, why bother with this? If a game allows for multiple strategies but one is more powerful than the others, doesn’t exploiting the best strategy just equate to players trying to win? As long as no individual player has an unfair advantage, isn’t it okay for your game to simply be “whoever finds the most powerful strategy wins”?

The problem here is that, once a dominant strategy is discovered, astute players will ignore all suboptimal strategies. Everything in the game that is not part of the dominant strategy becomes extraneous noise. There is nothing inherently wrong with a game that has a single winning strategy, but in this case the suboptimal ones should be removed to make the game more streamlined. If you include options for players that are suboptimal, these become false decisions, because really there is only one decision (follow the dominant strategy).

If it is worth including several potential winning strategies in a game, then, it becomes much more interesting if those strategies are balanced. Again, much of this comes down to playtesting. In this case, when players are playing your game, make note of whether certain strategies seem to be used more often than others, and which ones seem to win. If several items are available for players to purchase in a game, is there one that seems to always get bought early, while others seem to be used rarely if ever? If players have a choice of actions each turn, does the winner of each playtest always seem to be the one that chose one particular action more often than everyone else?

Playtesting alone is not automatic proof that a particular strategy is unbalanced, but it should give you strong signals that certain aspects of the game need closer inspection. Sometimes, players will use  particular strategy because it is the most obvious or the easiest and not because it is the most optimal. Some players will avoid anything that seems too complicated or requires finesse, even if it is ultimately better in the long run.

Balance Between Game Objects

Within a system that has several similar game objects (such as cards in a trading-card game, weapons in a role-playing game, and so on), we use “balance” to describe the objects themselves, specifically whether different objects have the same cost/benefit ratio.

This kind of balance is specific to games that give players a choice between different game objects. Some examples:

* Cards in a trading-card game. Players build a deck with a set number of cards from their collections. The choice of which cards to add is one of the key factors in the game’s outcome, and designers try to make the cards balanced with one another.

* Units in some war games and real-time strategy games. Players have the ability to purchase units during play, and different kinds of units may have different abilities, movement rates and combat strengths. The designer will try to make the units balanced with one another.

* Weapons, items, magic spells, etc. in a role-playing game, either tabletop or computer/console. Players may purchase any of these for use in combat, and they have different costs and different stats and abilities. The designer will try to make these objects balanced with each other.

In all of these cases, there are two goals. The first is to prevent any game object from being so weak that it is useless in comparison with other objects. This again becomes a false choice for the player, because they might be able to gain or purchase a certain object but they will quickly find that it is not worth using; the object is therefore a waste of the player’s (and designer’s) time.

The second goal is to prevent a game object from being too powerful. Any single game object that becomes a dominant strategy makes all other objects in the game useless in comparison. In general, if you absolutely must choose between making an object too weak or too powerful, err on the side of making it too weak.

Two objects are balanced if they have the same cost/benefit ratio. That is, what you give up to gain access to an object (this includes explicit costs like in-game money or resources, and also opportunity costs like drawbacks, limitations, or exceptions to the object’s capabilities) should be in some proportion to the in-game benefits you get from the object. The costs and benefits do not have to be exactly the same (in fact, usually the benefits are greater, or else you would simply ignore the object). However, when comparing two different objects, the proportion of costs to benefits should be roughly the same for each.

Three Ways to Balance Game Objects: Transitive, Intransitive, and Fruity

I have encountered three general methods for balancing game objects. The first is technically referred to as a transitive relationship. In more colloquial (but still geeky) circles, it is called a cost curve. This is the most direct way to balance objects. The general idea is to find some desired proportion of costs to benefits. This may be a linear proportion (something twice as costly is exactly twice as powerful) or it may be curved in some way (perhaps there is a law of diminishing returns, where you have to pay progressively more for each additional bit of benefit; or perhaps there are increasing returns, where you essentially get a “bulk discount” for paying a lot at once). It all depends on your particular game, but playtesting, experimentation and instinct will help you to figure out what kind of relationship there should be.

The next step is to reduce every cost and every benefit to a single number that can be compared. Take all the costs of an object and add them together; also sum the benefits. Compare the two, and see if the object is giving the correct numerical benefit for the cost.

This method is often used in trading-card games. If the game has an established cost curve, it makes it much easier to create new cards with combinations of existing effects. In Magic: the Gathering, if you want to create a new creature with a given color, power, toughness, and set of standard abilities (say, a White 4/3 with Flying and First Strike), there are already several costs it can be, and designers working on this game (and sufficiently informed players) could tell you exactly what those equivalent costs are. Adding more abilities comes with an increase in cost, and decreasing the cost would necessitate a removal of stats or abilities.

The second method is an intransitive relationship between game objects, better known as a rock-paper-scissors relationship. In this case, there may not be a direct relationship between costs and benefits, but there is a relationship between the game objects themselves: some objects are inherently superior to others and inferior to still others. The game Rock-Paper-Scissors is the canonical example; none of the three throws is dominant, because each throw will
draw with itself, beat one of the other throws and lose to the third one.

This can be seen in some strategy games as well. In many real-time strategy games, there is some kind of intransitive relationship between units. For example, one common relationship is that infantry are strong against archers, archers are strong against flying units, and fliers are strong against infantry. Part of the game is managing your particular allocation and positioning of units (in real time) in comparison to your opponent.

Note that transitive and intransitive relationships can be combined, as in the previous example. In typical real-time strategy games, units also have different costs, so a weak (but cheap) archer may still be defeated by a strong (and expensive) flying unit. Within a single class of units, there may be transitive relationships, but the different classes have intransitive relationships with one another.

Intransitive relationships can actually be solved, using matrices and some basic linear algebra. For example, the solution to rock-paper-scissors is that you expect the proportion of each throw to be equal to the others: there should be a 1:1:1 ratio. Now, suppose you modify the game slightly, so that each win with Rock scores 3 points, a win with Paper scores 2 points, and a win with Scissors scores 1 point. What is the expected ratio now? (It turns out the ratio is not what you’d expect; with optimal play on both sides, you would see 1 Rock for every 3 Paper and every 2 Scissors. The math required to do this is outside the scope of this course.) If you are looking for players to use objects in a certain proportion (with some being more commonly used than others), a well-balanced intransitive relationship is a good way to guarantee this.

A third method of balancing game objects is to make each one so different and unique from the others, that direct comparisons are impossible. (I call this “ fruity” in the sense that the designer, and later the players, can only compare apples to oranges.) Since formal and numerical comparisons between objects cannot work, the only way to balance this is through excessive playtesting.

There are challenges associated with all three of these methods. For transitive relationships, everything relies on the designer finding the correct cost curve. If your math is wrong, it will be wrong for ever object in the game; if you find one thing that is unbalanced, you’ll probably have to change everything. Transitive relationships are much easier to develop in retrospect after playtesting, than developing them ahead of time. Since so much relies on getting the math right, it also tends to take a lot of trial-and-error and therefore a lot of time.

Intransitive relationships, as noted above, take some tricky math to solve. Another drawback is that, unless done very carefully, their presence can make the entire game feel like glorified Rock-Paper-Scissors, which some players find to be a turnoff – many have the perception that intransitive relationships are nothing but guessing games, where every decision is based not on strategy but on luck and randomness. (A full discussion of whether this is or is not the case is also outside the scope of this course.)

“Fruity” relationships are really hard to balance, because one of the most important tools in doing so – mathematics – is no longer available.

Three General Game Balance Techniques

In general, there are three ways to balance games:

* Use math. Create transitive or intransitive relationships in your game, and make sure that everything is in line with the cost.

* Use your instincts as a game designer. Change the balance in the game until it “feels right” to you.

* Use playtesting. Adjust the game based on the results of playtests, where the players are experienced gamers who have been instructed to play to exploit and win.

There are challenges with each of these ways:

* Math is hard, and it can be incorrect. If your formulas are wrong, everything in the game may be off a little bit, which is inconvenient for rapid prototypes. Some really strange abilities or game objects may not have any math to them if they are too unique, requiring other ways of balancing.

* Instinct is vulnerable to human error. It is also not absolute or reproducible; different designers may disagree on what is best for the game. This is particularly dangerous on large team projects, where one designer may leave in mid-project and another cannot take over (or rather, they can, but they will not be able to finish the game in the same way that the original designer would have).

* Playtesting relies on the quality of your testers. Testers may not find every balance issue with the game; some problems will go undiscovered for months or years (even after public release of the game). Worse, some testers may intentionally avoid showing you rules exploits, because they plan to use them after the game is released!

What is a designer to do? Do the best you can, and understand both the strengths and limitations of the balance techniques that you are using. And as a game player, the next time you run into a game that seems horribly unbalanced, have some appreciation for how difficult it can be to get things perfect.

More Game Balance Techniques

Here are a few other random bits of advice I’ve picked up, in no particular order.

Be aware of the different objects and systems in your game and their relationships. You should already have done this during your initial design of the game, of course, but it is easy to forget the big picture when you start focusing on small details. There are two things in particular that you should return to first, whenever you make changes to your game:

1. What is the core aesthetic of your game? Does this change support the core?

2. Look at the interconnections between systems. If you change one thing, you should know what other things will be affected. Individual game elements rarely exist in a vacuum, and changing one thing can have ripple effects throughout the game. By being aware of the relationships between systems and objects, it becomes easier to predict the second-order effects of a mechanics change.

Make one change at a time. We’ve said this before, but it bears repating. If something breaks after making a change, you know exactly why. If something breaks after making ten changes, you don’t know which change (or combination of changes) caused it.

Learn to love Excel. It can be any computer spreadsheet program, though Microsoft Excel is the most popular among game designers. Often, students look at me like I’m crazy when I suggest that a spreadsheet is useful in game design. (Like, aren’t those things only used by corporate finance dudes or something?) Here are some examples of how spreadsheets are used:

* Excel makes it easy to keep lists of things and organize them. List all of your game objects and their stats. In a role-playing game, list all weapons, items and monsters; in a tabletop war game, list all units and their stats. Anything that you’d find in a reference chart in the instructions (or a strategy guide) probably started off its life in a designer’s Excel sheet.

* Excel is great for keeping track of tasks and status, which is useful for a complicated game with lots of systems and components. If you’ve got a table with a couple hundred monsters and all their stats, it might also have an entry for whether the art for that monster is done, or whether the stats for that monster have been balanced or playtested yet.

* Spreadsheets are good for collecting and manipulating statistics in your game. In a sports game where each player has a list of stats, are all of the teams balanced with one another? Sum or average all of the stats on the team, and you can get some idea of the overall strengths and weaknesses of each team. In a game with transitive relationships, is each game object balanced? Add up the costs and benefits in a spreadsheet.

* You can use spreadsheets to run statistical simulations. By generating random numbers (in Excel you can use the RAND() function and press F9 to reroll), you can generate random die-rolls for things like damage within a range, many times, to see the overall range and distribution of outcomes. (Statisticians call this a “Monte Carlo” simulation, in case you were wondering.)

* Spreadsheets help you to see causes and effects of changes in the game. By creating formulas based on specific values that you want to change, you can change one value and see what happens to the other values that depend on that one. For example, if you’re working on a Massively-Multiplayer Online RPG, you could use Excel to compute the damage-per-second of a weapon and then instantly see how that changes when you modify the base damage, accuracy, or attack
speed.

Use the Rule of 2. Suppose you have some number in your game that you know is too high, but you don’t know how much. Maybe it’s just a little bit too high, or maybe it’s quite a bit off. In either case, cut it in half. Likewise, if you have a value that you know is too low, regardless of how much too low it is, double it. If you aren’t 100% sure of what the correct value is, double it or cut it in half. This is the “Rule of 2.”

At face value, this sounds rather ridiculous. If the cost of a gemstone is only 10 to 20 percent too low, what could be gained by taking the drastic measure of doubling it? In practice, there are some reasons why this works. First, you might think that it’s only slightly off, and you might be wrong; if you only make minor adjustments and the value really did need to be doubled, it will take you much iteration to get to where you needed to be in the first place.

There is a more powerful force at work, though, when applying the Rule of 2. Game design is a process of discovery. The fact is, you don’t know what the correct numbers are to balance your game; if you did, the game would be balanced already! If one of the values in your game is off, you need to discover what the correct value is, and you do this by changing the value and seeing what happens. By making a major adjustment, you will learn a great deal about the
effect of this value on the game. Maybe it did only need a minor adjustment, but by doubling or halving the value, you will learn so much more about your game.

Occasionally, you will also find that by making such a large change to your game, it changes the dynamics in a way that was unexpected but (accidentally) superior to your original design.

Balancing the first-turn advantage. In turn-based games in particular, it is common for there to be a very slight advantage (or disadvantage) to going first. This is not always the case, but when it is, there are a few common techniques for compensating:

* Rotate who the first player is. In a four-player game, for example, after each complete round (where every player has a turn), rotate the starting player to the left for the next round. In this way, the player who goes first on this round will go last on the next round. (When I was growing up, my game group used a pencil to mark the first player, so we dubbed this the “Pencil of Power” technique.)

* Give the disadvantaged players some extra resources. For example, if the objective of the game is to score the most points by the end of the game, give each player a different number of points to start the game, with the last player having slightly more points to compensate for the disadvantage of going last.

* Reduce the effectiveness of early turns for the first players. In a card game, maybe players typically draw four cards at the start of their turn. You could modify this so that the first player only gets to draw one card, the next player draws two, and so on until all players are drawing four.

* For very short games, play a series of games where each player gets to go first once. This is common with card games, where a complete game is played in a series of hands.

Write down your own rules as you learn them. As you design games, you will have successes and mistakes. You will learn from both (especially your mistakes). When you find a “law” of game design or a new game balance technique, record it and review your notes periodically. Tragically, very few designers actually do this; as a result, they cannot pass on their experience to other designers, and they sometimes end up making the same mistakes on multiple games because
they forget the lessons learned from earlier ones.

The Role of Balance

In my early days as a designer, I was very passionate about game balance. “A fun game is a balanced game, and a balanced game is a fun game” was my mantra. I’m sure I annoyed many of my seniors with my rantings on the imbalances in our games and why we needed to fix them immediately. Such is the privilege of youth.

While I still believe balance is important and a key skill for any game designer, I now take a more moderate line. I have seen some games that are fun in spite of being unbalanced. I’ve seen other games that are fun specifically because they are intentionally unbalanced. I have seen some games that have done astoundingly well in the marketplace, despite having egregious imbalances. These are rare and special cases, to be sure. But let this serve as a reminder to you that the techniques and concepts discussed today should never take priority over the ultimate design goals for your game. Let these techniques be your tools, not your master.

If you have made it to this point, your game is hopefully coming along nicely and you are approaching the final stages of design. You may still have temptations to mess around with the mechanics, especially given the short time period allotted for the Design Project, but at this point I want you to settle on something that is at least “good enough” so that you can experience the later stages of design.

Once your mechanics are complete and the game is playable, balanced, and meets your design goals, the last thing to do is figure out how to construct the final version. This is not simply a matter of drawing up some art for your cards and board and sending it off to the printer. There are some considerations to be made concerning the user interface of your game, and those considerations are what we will talk about today.

Readings / Viewings

Read the following:

Challenges for Game Designers, Chapter 16 (Creating a User Interface)

Cooperation and Engagement, a Google tech talk by game designer Matt Leacock. This video actually ties together a lot of the concepts we’ve talked about in this course, from difficulty levels and flow states to the iterative process to game narrative, and it should serve to solidify those concepts using the concrete example of Pandemic, one of the best-selling hobby games of last year. But what I really want you to pay attention to is how Matt presents his iterative work on the design of the game components themselves, such as how he determined the shape, orientation and color of the cards. The actual talk is only 30 minutes long, although there are an extra 20 minutes at the end from audience Q&A.

What is a User Interface?

Normally, we think of the term user interface (or UI) as it applies to software applications. This term refers to the parts of the software that interact directly with a human. It covers things like what options are available to the user at any given time, how those options are presented on the computer screen, as well as the physical interactions (mouse/keyboard, game pad, etc.). In general, with video games, the UI is divided into two parts: the input (that is, how the player gives commands to the game) and output (how the game communicates the results of those actions and other aspects of the game state to the player).

What if you’re making a non-digital game? Is there a UI? Of course there is – and if anything, it is more important to get it right, since you don’t have a computer automatically enforcing the game rules. If the players don’t understand the rules of a non-digital game, the only recourse is often to stop playing. As the game’s designer, the last thing you want is for your brilliant mechanics and carefully-crafted play experience to be ruined because of aninterface issue.

In non-digital games, the UI is the game components themselves, since they are both how you interact with the game (through manipulating the game bits) and receive feedback (by viewing the game state). So what we are really talking about today is designing your final components.

User Interface Design

What makes one UI better than another? We generally talk of two things:

Ease-of-use. If you already know what you want to do, how fast and easy is it to perform your desired task correctly?

Ease-of-learning. If you are new to the game, how easy is it to figure out what you are allowed to do and what information is available to you?

In practice, there is often a tradeoff between these two. For example, on computers, the presence of special “hotkeys” (Shift/Alt/Ctrl/Cmd key combinations and the like) saves time by making it fast and easy to perform common tasks like saving a file or switching between applications. But if these are the only way to perform that task (as is the case with some older word processors that lacked menus), it makes the applications difficult to learn for the first time.

In board games, you often see this tradeoff with how information is presented. Charts, tables, keywords, special symbols and icons – all of these make it much easier for an experienced player to get a quick summary of the game state, but they can be confusing and intimidating to the novice player who does not know what these things mean. The alternative, writing everything out in longhand, makes it much easier for a new player to see immediately what everything does… but it also makes the game take longer for players who already know the rules and do not need them repeated in full on every card.

Sometimes you can include both. Modern software applications include hotkeys and menu items, and some even have a “beginner” mode that hides advanced functionality to keep the menus simple, making the software much easier to learn. Card games like Magic: the Gathering include keywords, but then explain those keywords in parentheses for players who do not know what the keyword means.

Look at all the mechanics in your game, and what players must do in order to follow them. Are there any cases where your wording could be clearer for first- time players? Are there situations where experienced players of your game feel like they are doing excessive book-keeping or note-taking, or performing multiple automatic steps, where it would be possible to streamline the experience?

The Two Models of Usability

In usability for computer applications, there are two related concepts: the user model and the program model. The user model is how the user (i.e. the player) thinks that things should work. The program model is how the software actually works. (In non-digital games, you can think of the “program model” as the actual rules of the game as intended by the designer, and the user model is what the players think the rules are.)

Here’s the thing. The program model is always right. If the user model and program model match one another, there is no problem. If the two are different, the player is going to do something, they’ll expect one thing to happen, but another thing happens instead. With computer games, this leads to frustration, and reviewers will say the game has “poor play control” (often without fully understanding why).

In board games, if the player model and the “program” model are different, the players will just play the game incorrectly. Sometimes, this means the players will have a suboptimal experience, because some aspects of the game will feel unbalanced. Other times, the players will have a perfectly good time, but when they later play the game with other players who are playing the game the “right” way there will be rules arguments.

Changing the User Model

It is common to see a user/program model mismatch during playtesting. Here is what it looks like: with every playtest group, the players always do one particular thing wrong the first time around. This suggests an ease-of-learning problem.

A more serious case is an ease-of-use problem with the UI of your game. It looks like this: one or more players accidentally do something wrong in the rules. You point it out to them, and they correct their behavior. But then they forget, and they do it wrong again on the next turn. And the next. And the next. And your players apologize to you for continuing to get it wrong, and they feel like idiots.

In cases like this, it would be ideal to change the user model. That is, you’d like to change your players’ expectations or actions in order to match the “correct” model of the game itself. Unfortunately, in practice, this is effectively impossible to do. People are creatures of habit. We build up elaborate mental models of the world around us, and we rely on those models greatly. Changing a model is a slow process that requires great effort on the part of a person, and most people are not going to put that kind of effort into your game.

To illustrate this in my classroom courses, I tell the story of the design of a fighter jet. Once upon a time, the military was noticing that one particular type of aircraft had a much higher-than-average number of accidental pilot ejections (that is, the pilot’s ejection seat was activated when the pilot did not intend for that to happen). Given the cost of military aircraft, it gets very expensive when something like this happens, so they had a lot of engineers study the problem to figure out why the seat was ejecting, but no mechanical or electrical problems could be identified. Eventually, someone got the bright idea to look at the aircraft that the accidentally-ejected pilots had trained on. It turned out that in all cases, they had trained on an aircraft where the positions of the throttle and the ejection seat controls were reversed! So, when the pilots got in this new aircraft, they had already formed a mental model of where all the controls were, and no amount of training on the new aircraft could change it.

Identifying the User Model

Okay, so we can’t change the user model. That means if you find a mismatch between the user model and the game, you should change the game’s interface so that it either conforms to the user model, or change the interface so that it is different enough that it triggers a different user model. But how do you know what the user model is in the first place?

Thankfully, this is pretty easy to do. The easiest way is to ask. Find people who play games similar to the one you’re making. Set up a situation for them, and ask them how they think the game would work (or how they would accomplish some task, or whatever you’re trying to figure out) if they had to guess. Once you ask a few people, a clear consensus will emerge pretty quickly.

Another pretty easy way to identify the user model is to playtest. Watch when people are playing the game, and make note when they do something wrong.

Lastly, if your game’s model is nontrivial, it is probably wrong. Other things being equal, people will assume simplicity.

Whose Responsibility Is It, Anyway?

You might wonder, in some cases, if usability issues are really your problem as the game designer. After all, if you create a good game and you give a complete and correct set of rules, isn’t it the responsibility of the players to actually, you know, read the rules and follow them? If they play your game wrong, how is that your fault? Some people are just stupid or careless, and certainly the brilliant designer should not be held accountable for these people.
Right?

Well, first off, it may not be the player’s fault. They might have been taught by someone else. They might be in a distracting environment, so they can’t give the rules their undivided attention. They might not have the rules; maybe they purchased the game second-hand and the rules were missing. The language the rules were written in might not be their first language. There are any number of reasons why a perfectly intelligent and rational person might have
difficulty. So, don’t just write these people off as not worth your time.

Second, most usability failures feel like a mistake on the part of the user (player), but they are actually a UI issue that could be fixed. Consider: if your game were easier to use, it wouldn’t let the players make mistakes. As the designer, take responsibility for the usability of your game, and you will find that players are learning it faster, making fewer mistakes, and generally having a better time.

Building a Good UI

Now that we know how to identify a bad UI, how do you design a good one? In general, a good UI does two things:

It does what the user thinks it will do; and

It gives the user feedback so they know what it did.

If the game doesn’t do what the player thinks it will, that is a problem with the user model not matching the game model, as we’ve already discussed. But there is one other aspect to designing the UI: giving the player immediate feedback so that they know what they did is correct (and, in the unlikely event that they did something wrong, they will immediately see that it is wrong and understand why).

Here is another way of looking at what a good UI does:

Make it easy to do things correctly; and

Make it hard to do things the wrong way.

Here’s an example: suppose you have a board game with several kinds of tokens. Maybe you have one set of markers that keeps track of player score, using a scoring track around the edge of the board. Maybe the game board has a map divided into provinces, and players have military units that are placed in the provinces. Maybe there’s also a global market with goods for purchase and sale, and a separate track for each trade good that lists its current price.

It would be easy to get all these different game bits confused. But what if each token was a different size and shape, and each space on the board matched the shape of the token that was used there? All of a sudden, it becomes a lot easier to figure out that the small square tokens must go on the small squares of the scoring track, the star-shaped goods markers go on the star shapes of the trade good price tracks, and so on.

How will the players remember how to adjust the trade good values on each track? A rules summary printed on the board right next to the tracks makes it easy to remember. What about how combat is resolved? Unit strengths, stats and abilities can be printed on the military units themselves, and the remaining rules can either be summarized on the board or on a quick-reference card or other player aid given to each player at the start of the game.

As you go about designing the UI, here is a process you can follow:

First, make a list of tasks that players need to accomplish in the game. Make it easy to do those tasks.

Second, pay special attention to the most common tasks, the ones that players are doing over and over. Difficulty and complexity of a task should be in proportion to how rarely it is used.

Iterate through playtesting.

Use of Color

Color is a great way to convey information to players if done well. It is efficient: color takes up no additional space on a game component, because the component is already there; all you’re doing is coloring it. Here are a few quick-and-dirty tips for thinking about color use in your game:

The colors that normal human eyes detect most easily are red and green, followed by blue. These colors will tend to stand out more… which can be good for drawing attention, but bad for eye strain if you use flly-saturated bright colors.

Don’t rely on color alone; a nontrivial portion of your audience has some degree of colorblindness. Vary the intensity of colors as well (so that if, for example, photographed with a black-and-white camera, you would still see a difference), and use different shapes in addition to different colors. By having things differentiated in multiple ways (different shape, different color, etc.) it makes it really obvious that those things are distinct from each other.

Use color consistently. If you use one color for several things in a game, those things should be related. Some board games I’ve played, for example, have (say) five different resources, and each one has a color; but each player also has a color, and some player colors and resource colors are the same, even though there is no relationship between the green player and green resources. This kind of thing can confuse players who might think that a particular resource is owned by their opponent when it isn’t.

More UI Design Tips

In no particular order:

Automate or eliminate tasks that don’t involve interesting decisions, if possible. Every click or keypress in a video game, or die-roll or card flip in a board game, should involve the player doing something that is interesting to them. If the player first has to do a bunch of upkeep tasks just to have the privilege of making interesting decisions later, see what you can do to streamline the boring stuff.

Use visual metaphors. They make it obvious what something represents. If your players control a bunch of pieces that represent people, using people-shaped pawns is clearer than using wooden cubes. Compare the pawn images below. Each has a very different effect on how the player views it.

Likewise, if you use icons in the game to represent certain abilities, choose icons that look like the concept they’re representing (if you can).

Be consistent with similar games. In an RPG, red hearts probably mean life or hit points, while blue drops probably represent mana or magic power. Why? Because that’s how everyone else does it, and your players will assume by default that you do it that way too.

Don’t just say “well, this is confusing, so we’ll explain it in the manual.” Remember, your players may not have the manual and they may not read it. Try to make your UI intuitive enough that your game doesn’t even need a manual.

Lessons Learned

Giving your game a good UI is a skill that is separate from core systems design, but it is an important skill to learn. Keep in mind that, as with most things in this course, UI design is a huge field and we are only going to cover the very basics. There are entire courses (and even college majors) devoted specifically to UI, not to mention hundreds of books, and I encourage you to seek out these resources after this course is over.

Further Reading

There are many great books on UI design. If this topic interests you, I would recommend Donald Norman’s Design of Everyday Things, which gets into the details of how the design of something as simple as a door or a stove can go horribly wrong… with lessons that can be applied directly to games, both digital and non. Also, for ways to show game data to players in efficient and innovative ways, I would recommend any of Edward Tufte’s books: The Visual Display of Quantitative Information, Envisioning Information, and Visual Explanations.

If you are primarily interested in video games, there are so many great sources on computer UI that it would be hard to list them all here. If you have any personal favorites, leave as a comment on this blog post, or post on Twitter using #GDCU.

Homeplay

The ongoing homeplay from a week ago was to arrange for a blindtest session, which should be completed on or before this Thursday (August 27). Continue working on this if you have not completed it already.

Your other task, also before this Thursday, is to critically analyze your game with respect to user interface. Think about your playtests so far, and what rules your players have had trouble with. What kinds of components or player aids would make it easier for them to remember?

Come up with a user interface plan for the final version of your game. This plan should involve the following:

A complete list of all game components that will be included in the final game.

For each component, a detailed description of what you are planning to use. If you have, say, “one pawn to represent each player”, how many pawns are included? What colors will they be? What shapes? Will they be made of metal, plastic, wood, or something else?

If there are cards, describe a sample card. What information will be displayed on each card? Will the card be oriented as “portrait” or “landscape”? How will the information be laid out – where on te card will each item go? How will it be displayed – what colors, shapes, and keywords do you plan to use (if any)? If there are several kinds of cards, do this for each.

If there is a board, describe the layout of the board. As with cards, consider what information will be displayed on the board, how it is laid out, and how it is displayed.

If there are other components, give similar information to that listed here.

This list is mainly for your own reference, and the purpose is to make it as easy as possible for you to assemble your final game (which you will be doing this next week). The list also serves as a sanity check: do you have access to all the components you need? If you do not own some of them, think about how and where you plan to create or purchase them.

Post your UI plan to the forums no later than this Thursday (August 27), noon GMT.

By next Monday (August 31), read and respond to at least three other posts at the same level as you, giving preference to those that have not had any responses. By reading, it may give you some ideas to use on your own project. You may also be able to share some ideas you already have with others, helping them to improve their projects.

We are nearing the end of this adventure, so if you are still here, you deserve some congratulations.

At this point you have created a game. You have playtested your game multiple times, with multiple purposes (from fun to balance to usability). You have a list of materials that you need to assemble, and a list of things you must do to assemble them. All that is left in the Design Project is to complete it.

Readings / Viewings

None.

On Craftsmanship

One might wonder, why bother with assembling high-quality components for a game? The game is all about the mechanics, after all, and the game pieces are just a physical manifestation of the mechanics. Therefore, any pieces should be as good as any other. UI issues aside, why not just use the prototype you’ve been using and call that the final project… handwritten cards and all?

I have several responses to this.

First, if the pieces are a physical representation of the rules, you as the designer should give them the same care, so that the outer beauty of the game matches the inner beauty of the mechanics.

Second, you should take pride in your game. The physical pieces are as much a design statement as the rules. What the pieces say to a player is that the game designer felt that their game was high enough quality to deserve high-quality components. To use an analogy, if you are a chef and you’re making a simple peanut-butter sandwich, maybe you don’t mind eating off a flimsy paper plate; but if you’ve put together an elaborate nine-course gourmet dinner, find some
better-quality plates to serve it on.

Third, if you plan to eventually commercialize and sell your game, the quality of the components is one of the first things a prospective customer will see. Many Eurogames actually print a nice picture of the game components on the back of the box as a selling point. They are in essence saying, “if you buy this game, you will get these fine components.” Even if you aren’t planning on selling the game you’re making right now, going through that process is good practice for future projects.

Lastly, keep in mind that your game represents you as a designer. If you ignore the one thing that every player is going to see, what does that say about you? Does it suggest that you don’t care about your projects enough to put in some extra effort? Does it mean you don’t take pride in your own work? Does it mean you lack confidence? If you are planning to use this game (or another one) as part of your professional design portfolio, think about how it will appear to prospective schools or employers. For the same reason that you might dress up for a job interview, dress your game up before you release it.

An Anti-Craftsmanship Aesthetic

You might press this even further. Some commercial games were made with intentionally poor production values. The first printing of Kill Doctor Lucky (and the rest of the games from the original publisher) had cards printed in one color on flimsy paper with just simple text and no art. The game didn’t even include common components like pawns or dice, and it was sold in a thin paper envelope with the rules printed right on the bag – there wasn’t even a separate printed manual. In the digital realm, Kingdom of Loathing is an online browser game that uses badly-drawn stick figures for all of the game art. It ’s as if these people aren’t even trying, and yet their games see many players. Why not just do that with your own game?

I would argue that these games actually have very high production values. Each offers a consistent visual aesthetic and a strong impact that is consistent with the values of the creator and the game mechanics.

In the case of Kill Doctor Lucky, the whole point of the entire line of games, in fact James Ernest’s mission statement, was that games were getting too expensive because they included all these extraneous components. Why bother paying an extra dollar for two dice when you’ve probably got dozens of dice lying around from other games you own? And sure, the cards are flimsy… but if you accidentally ruin them, oh well, go out and buy the game again. The game cost you less than that mocha latte you had at Starbucks this morning.

With Kingdom of Loathing, the game is a parody of similar games. As a parody, the intentionally low-quality art style is a deliberate choice, standing in contrast to the focus on detailed visuals in other games. And any time that didn’t go into drawing stick figures went into the writing of the game, which is (frankly) of higher quality than many of the visually stunning games out there.

So, if you have a game where “low” production values make sense – maybe you’re making a game about living in a trailer park, or a game about magpies where the object is to build a nest out of the shiniest junk, or something – then by all means, craft your game accordingly. But even in this case (or I should say, especially in this case), make the quality and appearance of each component a deliberate design decision. You’ll find that it may take more skill to pull this off in a way that looks genuine than it would to just make a game with standard high-quality components.

Quick Tips

For printing cards:

Print on heavy card stock, not standard printer paper.

If you’re not printing in color, consider at least printing on colored card stock, choosing a color that matches the rest of your game.

Make sure the cards are readable when printed. Sometimes they don’t print out exactly as they look on a computer screen.

Use rounded rectangles to mark your cards in a print program, and then carefully cut them out on your own with scissors. Or, if you have a corner-cutter (available at most craft/hobby stores), use that and save yourself a lot of work. Rounded corners are gentler to hold; square corners can poke you uncomfortably.

If you want to get really fancy, get the cards laminated (this means cutting the corners of the lamination instead of the card itself). This will make the card virtually indestructible and waterproof, although it can be expensive. As a less expensive alternative, some hobby stores sell spray-on plastic coating that will give your cards a similar feel to standard plastic-coated playing cards. Take care to apply the spray evenly so that your cards don’t have lumps or irregularities.

Print cards double-sided if you can, with a standard card back. Note that the back is a mirror image of the front, so things that print on the left side of the back of the sheet will be printing over the right side of the front. Also, be very careful about double-sided printing, as even a minor offset on one side may make the entire sheet unusable. Try to get the two sides lined up exactly.

For printing a board:

Don’t just print on card stock alone. It feels flimsier than most game boards you’re used to. Try mounting it on flat cardboard, poster board, or foam core.

If you have to cut cardboard or foam core to a specific size, try a test cut in a corner first. Some tools will not cut cleanly, but instead will leave the entire edge torn and jagged and ugly.

Getting a large board printed on a single sheet of paper is expensive. Getting it printed on a vinyl banner is even more expensive. One low-cost alternative is to break up a large board on several standard sheets, then mount them on a firm backing. If you want to get fancier, instead of printing on normal paper, print on a full-sheet adhesive label. Then, you can just peel off the sheet and stick it on somewhere without having to worry about glue… but be careful when sticking it so that there are no creases.

To make a foldable board, put two smaller boards near each other and tape them together with clear tape (such as mailing tape). Leave a little bit of space between them where there is just tape (this is where it will fold). Once you mount the actual game board on top, you might not even notice the tape.

For making custom dice:

Print on adhesive labels, cut them to size, and stick them over the faces of existing dice.

Leave a little room at the end of each dice face (in other words, cut the adhesive labels a little smaller than the actual dimensions of the dice). This will avoid having little bits of paper sticking out around the edges.

For standard dice (white background, black recessed dots), the black dots may show through even after you put a label over them. If this is the case, put an extra layer or two of blank adhesive label over the face first, before applying the final label on the outside. This will reduce or eliminate the visual effect.

If you really want to get fancy, there are some game manufacturers that sell blank dice with recessed sides. These are ideal, because you can put adhesive stickers on them and not worry about the stickers rubbing off through repeated use. These can be hard to find, though.

Coloring your pieces:

If you have a lot of blank wooden pieces (such as cubes or pawns) that you want to differentiate by color, the easiest way is to fill a bowl with water and a little bit of food dye, then soak the pieces and let them dry. I suggest doing this in two stages. First, do a test on a single piece per color, to see what they’ll look like (some colors may not show up as well as others, or you may find you need to soak them for more or less time; better to find this out before you ruin your entire stock of pieces). Then, once you have something that works, repeat for all of the rest of the pieces at once.

You can also paint wooden pieces by hand, but it is far more time-consuming and tedious and the paint is a bit more expensive.

If you have plastic pieces, the easiest thing to do is check your supplier to see if they naturally come in different colors already. Doing this by hand is not easy. If you find you must differentiate plastic pieces by hand, consider using small adhesive bands or dots instead of trying to color the plastic
itself.

If you have metal pieces and need to color them, paint is probably your best option. The same hobby stores that sell metal miniatures will probably also sell paints and other materials for you to paint them. Note that this can get very expensive and time-consuming, but if you’re using metal parts you were probably not concerned about cost in the first place.

For printing your rules:

The rules are the game, so don’t neglect these! Print on good-quality paper at the very least.

Consider if it is appropriate to “theme” your rules according to your game. For example, a game about trains might have rules laid out like a train schedule. A game about running a restaurant might have rules that are inserted into a plastic-shielded restaurant menu. A game about collecting classical artwork might have some art pieces displayed in the pages of the rules.

Make sure the font of the rules is readable. Don’t get too cute with custom fonts – doing this for headings is fine, but for the main text of the rules, remember that your players actually need to read them.

And for the love of all that is holy, double- and triple-check your rules for spelling, grammar, and clarity of writing. You did this before, but do it again – this time it counts.

Also check your written rules to make sure they are correct. You’ve likely made a lot of changes to the mechanics of the game over the course of the project, and the last thing you’d want is to accidentally print out an old copy of the rules before you made several key changes!

Everything is a Design Decision

If you just throw together a bunch of random components, that is a decision you made. If you hand-carved each component out of the branches of a tree in your backyard, that is also a deliberate decision. In short, everything you do for your game is a decision that you, as the designer, are responsible for.

So, make your decisions… but make them with both eyes open. Consider each component and how it fits into the overall visual and tactile aesthetic of the play experience.

Now, get out there and build the final version of your game.