让玩家测试游戏和让其他设计师测试游戏大为不同。如果做的好的话，你便能够从目标用户中获得有帮助的反馈信息，而不是游戏设计师单纯的建议，因为你能够第一时间了解那 些愿意尝试游戏最后版本的玩家们此时对于游戏的看法。这是一种完全不同的技巧。因为游戏测试者并非专业设计师，所以能够给出不一样的反馈意见，而你也必须更努力地从中 找出问题的根本原因。所以在这个过程中你要保持高度的洞察力。
显然，在街头表演过程中，观众的目光始终在艺人身上，那么这些表演者的目光又在哪里呢？下一次当你看表演的时候，认真地去观察这些表演者，你会发现，比起关注于自己或 者表演，他们更加专注于观众的反应。他们的目光一直在人群中追寻着兴奋点，不论看到观众的反应是肯定还是否定，他们都会适当地做出调整。也许观众更喜欢硬币魔术而非纸 牌魔术，或者更喜欢蓝调而不是爵士乐，又或者是更喜欢玩杂耍。所以对于表演者来说，最重要的技巧便是读懂观众的心思。
如果不是设计师，我们便很难忍受粗糙的游戏原型。特别是游戏玩家，如果他们收到一叠手写的索引卡片，并且卡片要求他们在一张笔记本纸做成的游戏棋盘上移动便士，如此， 他们可能会更多地关注于游戏组件的质量而非游戏机制吧。而这时你可能会得到很多关于美术设计或棋盘布局的评论，但是此时这些内容对你来说真的没什么价值，因为你更迫切 地希望了解玩家们的游戏体验，毕竟这个阶段我们还不用去讨论游戏的最终外观！
在现阶段，你可以将游戏棋盘印刷在1张或多张纸上。你也可以在PPT或者其它简单的工具，如MS Paint（画图工具，可以用它创建简单或者精美的图画）中的基线绘制方形，使用 文字工具编写棋盘中的文本或数字，或者你也可以复制并粘帖其它图像。
但是测试者经常忘记这点，就像是他们在游戏中遇到一些不明白之处，就会转过头向你咨询。而这时候你不应该立刻做出回答。你应该先问他们一个问题：“如果我不在这里，而 你需要自己做出判断，你会怎么做？”而不管他们的回答是否正确，都会让他们领悟过来。并且不管玩家做出何种选择，你都能够从中了解他们是如何理解你的游戏。而在玩家回 答了你的问题后，你便可以告知他们想要的答案。但是绝不要放弃如此这种可获得有价值信息的机会。
有时候你的测试者根本不会咨询你，而是径直前进，并因此陷入了游戏“误区”。也许本来每个玩家每一回合应该抓取2张牌，但是他们却只抓了1张。或者他们在每个回合开始时 都略过了第一步。或者他们忽略了游戏中某些道具的作用。这时候你一定要克制住那种想制止他们的冲动。虽然这种感受很不妙，没有什么比看玩家违背设计初衷而继续玩游戏还 折磨人了，但因为游戏发行后可能还有玩家继续这么做，所以对你来说意识到这点非常重要，因为你可以在测试后对规则和组件做出修改。
这是项我们从科学领域借鉴的技术。之前，某些研究人员注意到，调查者是否同测试者在同一个地方会影响实验结果。有时，测试者所说的内容是调查者想听的，而并不是他们自 己心中所想的。有时，调查者会提供微妙的非语言线索，而他们自己和测试者都没有意识到这一点，但是这会使测试结果产生偏差。比如，假设进行的是两种软饮料的口感测试实 验，如果调查者知道两份饮料的对应品牌而且他们希望测试者选择哪个品牌，他们可能会发现所有的测试者都选择了“正确的”饮品，原因只是调查者不经意间向他们传递了要做 出哪个选择的信息！
盲测的目标是找到你在亲自测试中可能无法发现的潜在问题。在亲自测试中，即便游戏测试者无需询问你任何问题，你对游戏的了解有时也会让人们轻松地通过某些规则（而这些 规则在盲测时或许会让他们感到困惑甚至放弃游戏）。或者，你可能会在向玩家介绍游戏时说出某些并没有在游戏中提供的关键信息片段（游戏邦注：比如“这是款拍卖/竞标游戏 ”），这种情况可能会让测试者脑中产生某些先入为主的观念。如果你不在场，你就会发现亲自测试结果的准确性有问题，你或许可以找到之前没有注意到的某些漏洞。
其次，你可以通过电子邮件来递交所有的东西。发送可以打印和组合成可玩游戏原型的文件，包括如何打印这些东西的指导文件。尽你所能地减少游戏测试者的工作量。毕竟，你 已经让他们花费时间来帮你测试游戏，不可再让他们花上几个小时的时间来打印和组建游戏原型。同时，如果你期望盲测者能够提供最真实的反馈，那么就要确保材料打印的成本 较低，同时可用性很高。比如，如果用普通纸张打印即可，就无需要求使用硬卡片纸（游戏邦注：因为这可能会让测试者再花时间跑趟印刷店）。
在现实情况中，游戏公司绝不会只有单个盲测群体，通常都会准备数个后备军。除了更多的测试者可以提供更多数据这个显而易见的原因外，还有个原因是盲测群体并不可靠。因 为你不在场，他们可能只花一点点时间来做测试，而反馈时间可能会拖延得更久。有些群体可能会遗失部分游戏组件，或者忘记了他们的任务，或者很可能因为生活中的其他事情 而将你的游戏放在一边。你邮寄的游戏原型也有可能遗失而无法被测试者拿到。在盲测的这个阶段，你可能会发现自己处在非常令人懊恼的境地，测试结果迟迟不来，或者没有在 计划内的时间内获得反馈信息。
在双人游戏中，“平衡”通常指所有家都不具有任何不公平优势。但此词也也出现于单人游戏中，其中游戏玩家未面临任何除游戏本身外的对手，游戏可能存在的“不公平优势” 可以视作挑战。我们也许会说《Magic: the Gathering》的个人纸牌具有“平衡性”，即使是在所有玩家都能接触这些纸牌的情况下，这样任何个人都未存在任何有利条件。这里 出现什么情况？
但这依然存在另一问题：不是所有玩家都一样。即便就小范围的目标用户而言，他们依然呈钟型曲线分布，有些玩家非常老练，而有些则相反。在进行游戏测试时，你如何知晓玩 家分布在钟型曲线的何处？若你只是涉猎测试，最理想的方式是覆盖大面积的测试者。当你获得大量用户的反馈信息时，你就能够大致知晓总体分布。随着设计经验的增多，你对 用户的了解就会越多，此时你只需通过少量用户便能得到同等有效信息。
即便你清楚如何调整游戏难度，目标用户置身何处，面对用户多元化的情况，你如何选择游戏挑战水平？无论你采取什么措施，游戏总是在某些人看来太难，而在某些人看来太简 单，所以你将处于必输局面。若你必须选择某种水平的关卡，根据概测法，你通常会瞄准曲线的中间部分，因为这样你能够囊括最多用户。另一方式通过提供多种难度水平、障碍 或系列规则组简化或强化内容，从而起到支持两端用户的目的。
若融入多个潜在获胜策略很有必要，那么这些策略富有平衡性会让游戏更有趣。而这些归根到底都在于游戏测试。在这种情况下，当玩家体验你的作品时，查看是否存在某策略的 运用频率超过其他策略的情况，哪种策略更倾向带来胜利。若游戏有若干道具供玩家购买，是否有哪些道具玩家会优先购买，而其他道具则鲜少有人问津？若玩家在每个回合都具 有行动选择，每次测试的赢家是否进行某操作的次数比其他玩家多？
* 角色扮演游戏中的武器、道具和魔力等（不论是桌面，还是电脑/掌机内容）。玩家也许会购买这些内容应用于战争中，这些道具具有不同成本、统计值和能力。设计师需让这些 物件保持平衡性。
此方式通常用于集换纸牌游戏。若游戏有既定成本曲线，那么通过既有混合效应创造新纸牌就简单得多。在《Magic: the Gathering》中，若你想要创造包含既有颜色、能量、韧 度和系列标准技能的新生物，其中已知某些成本，设计师便能够准确告诉你对应成本是多少。融入更多技能就会带来更多成本，降低成本就需要移除某些统计值或技能。
* 数学运算很难，而且会出现失误。若公式错误，所有游戏内容都会发生偏离，这不利于快速建模。某些奇特游戏技能或物件若过于罕见也许就无法进行数学运算，需要利用其他 平衡方式。
* 直觉常出现人为误差。这并不绝对；不同设计师对于游戏的最佳设计会有不同看法。这在大团队项目中尤其危险，其中某位设计师也许会在项目中离开，而另一设计师不知如何 接手。
* 游戏测试取决于测试者的质量。测试者无法发现游戏中的所有平衡问题；某些问题会沉寂几个月或几年都未被发现。更糟的是，有些测试者会有意不向你展示某些规则利用技巧 ，因为他们计划在游戏发行后将此运用于游戏体验中。
2. 着眼机制的相互关联性。若你调整某内容，需知晓其他内容也会受到影响。独立游戏元素鲜少出现在真空状态，调整某要素通常会带来涟漪效应。通过把握机制和物件间的关系 ，我们很容易预测机制调整的二级影响。
* Excel让我们得以轻松记录和组织内容。罗列所有游戏物件和统计数据。就角色扮演游戏来说，罗列所有武器、道具和怪兽；就桌面战争游戏而言，罗列所有道具及其统计数据。 任何你将在指南参照图表中找到的内容也许最初都是在设计师的Excel表格中诞生。
* Excel非常适合记录任务和数据，这对包含众多机制和部件的复杂游戏来说作用很大。若你看到桌上布满涉及大量怪兽及其相关数据的文稿，其中也许还记录怪兽的美工制作是否 完成，怪兽数据是否已进行平衡或测试。
* 电子表格有助于搜集和编辑游戏数据。在各玩家拥有众多数据的运动游戏中，是否所有团队都具有平衡性？合计或平均各队的所有数据，你就能够把握各团队的优缺点。在融入 传递关系的游戏中，是否所有游戏物件都具有平衡性？在电子表格中合计所有成本和利益。
* 电子表格能够帮你查看游戏调整的因果关系。通过基于特定你希望调整的数值创造公式， 你就能够调整某数值，然后查看其他相关数值会发生什么变化。例如，若你制作的是大 型多人在线RPG，你就能够通过Excel计算武器每秒带来的破坏性，然后立即获悉调整基础破坏、准确性或攻击速度将产生的变化。
但翻倍规则存在一个更突出的优点。游戏设计是个发现过程。实际情况是，你并不知道平衡游戏的正确数值；若你知道，游戏早已得到平衡。若某游戏数值发生偏离，你就需要找 到正确数值，所采用的方式是调整数值，然后查看所出现的情况。通过进行大幅度调整，你就会看到此数值给游戏带来的影响（游戏邦注：也许这只需要小幅调整，但通过翻倍或 减半某数值，你将更深入了解自己的游戏）。
虽然我依然认为平衡性非常重要，是游戏设计师不可或缺的技能，但我现在的态度要温和许多，我知道有些作品虽然缺乏平衡性但依然非常有趣。我也发现有些作品之所以非常有 趣是因为它们故意融入不平衡因素。而且有些作品虽然极度缺乏平衡性但依然在市场中表现突出。这些都是罕见情况。但需注意的是本文所谈及的观点还是要以遵循游戏终极设计 目标为前提。这些技巧只是你的工具，而非主宰因素。
通常，我们总是会将用户界面（UI）与软件应用联系在一起。这个术语指的是软件中与用户具有直接交互作用的内容。它包含着用户可以随时获取的一些选择，这些选择如何显示 于电脑屏幕上以及用户与电脑间的相互作用（通过鼠标/键盘，游戏手柄等）。一般来说，电子游戏的用户界面分为2个部分：输入界面（即玩家如何控制游戏）和输出界面（游戏 如何向玩家传达他们行动的结果以及游戏状态的其它方面）。
在桌面游戏的信息表达方面，你也常常能够看到这种权衡点。对于资深游戏玩家来说，图表，附录，关键词，特殊标志以及图标等能够帮助他们更好地了解游戏状态，但是对于那 些根本不了解这些标志的新手玩家来说，只会因此更加疑惑。你也可以用普通写法去描述这些内容，以此让新玩家能够对此一目了然，但是因此也会浪费那些已经掌握游戏规则的 玩家的时间，强迫他们反复地吸收自己已经掌握的内容。
在这种情况下，最理想的解决方法便是改变用户模式。也就是你需要因此改变玩家的期望值或行动以匹配游戏中的“正确”模式。但是不幸的是，这通常很难实现。因为人类是习 惯性的动物。我们创建了与周遭世界相联系的心理模式，并牢牢依赖于这种模式。而改变模式是一个相对缓慢的过程，需要我们投入更多的努力，但是却很少人愿意在游戏中投入 这种努力。
为了在我的课程中讲授这点内容，我列举了战斗机的设计故事。很久以前，有个军队注意到一种特别的飞机引发飞行员意外弹射（游戏邦注：即飞行员弹射椅会随机激活危害飞行 员的安全）的频率远远高于其它类型的飞机。按照军用飞机的成本计算，这种情况的发生会引起高额的成本损失，所以军队便迅速召集了工程师以找出问题所在，但是最终却仍未 识别任何可能的机械或电力问题。最后，有人提出从意外发生弹射的飞行员所训练的飞机身上找问题。而结果也证明这是一个非常棒的主意！因为所有在训练飞机上接受实战培训 的飞行员所控制的节流阀和弹射椅都跟实战飞机上的设置完全相反。所以当这些飞行员在驾驶这种新飞机时，他们原来关于飞机操纵的心理模式已经牢牢根植于心中，新飞机的培 训内容也很难改变这种模式。
好吧，我需要澄清的是，首先，这并非玩家的错。他们也许是从别人那学习到如何玩游戏，或者他们处于一个容易分心的环境，所以很难一心一意地阅读游戏规则。他们可能根本 就未接触到游戏规则，因为他们可能购买的是二手游戏，而已经略过了规则环节。可能规则的陈述并不是使用他们所了解的第一语言等等。如此可以解释为何如此多聪明，理性的 玩家经常会违背规则的原因。所以千万不要贬低这些玩家的价值，你应该多投入点时间帮助他们更好地阅读游戏规则。
利用色彩的一致性。如果你在游戏中使用同一种颜色去描绘多种物体，那么就说明这些物体之间具有关联性。例如我玩过的桌面游戏中，有五种不同的资源，而每一种都有独自的 颜色；每一位玩家也拥有属于自己的颜色，并且玩家的颜色会与资源的颜色出现重合，但是相同颜色玩家和资源之间并不存在连系。如此设置会让玩家感到疑惑，他们会想当然地 认为一个颜色的玩家必然拥有同种颜色的资源，但是事实却并非如此。
最后，应当记住的是，游戏体验设计师的能力。如果你忽略了某项每个玩家都将看到的东西，他们会对你产生何种想法呢？是否暗示着你对自己的项目并没有足够的关心，不愿意 投入更多的精力？是否意味着你并不以自己的作品为傲？是否意味着你缺乏信心？如果你计划将这款游戏（游戏邦注：或其他游戏）添加到你的职业设计简历中，应当明白它会让 雇主产生何种想法。你或许会为工作面试打扮梳理，同样，你也应当在游戏发布之前对其装扮一番。
有些人可能会进一步辩解。有些商业游戏特地制作较差的机制承载方式。《Kill Doctor Lucky》（游戏邦注：原版游戏发行商的其他游戏与其情况相似）的首个印刷产品中，有只 有单色且纸张很薄的卡片，只有简单的文字，毫无艺术感科研。游戏甚至没有棋子或骰子等最常见的成分，游戏装在薄薄的纸质信封中出售，规则就印在袋子上，没有单独打印出 来的用户手册。在数字领域，《Kingdom of Loathing》这款在线浏览器游戏的游戏艺术简单而且劣质。看起来开发商好似根本没有在这方面努力过，但是他们的游戏依然拥有数量 可观的玩家。为何我们在自己的游戏中不能仿效他们的做法呢？
在《Kill Doctor Lucky》的案例中，James Ernest表示正是那些不必要的成分使游戏变得过于昂贵。如果你拥有的其他游戏中已经有骰子的话，为什么还要在这款游戏中花钱买呢 ？诚然，所用的卡片确实很容易坏，但是如果你不小心弄坏它们的话，可以出去再买一付游戏。游戏的价格比你在星巴克喝的摩卡拿铁还便宜。
《Kill Doctor Lucky》是款模仿其他产品的游戏。作为模仿产品，开发商故意选择了低质量的艺术风格，这样才能与其他注重视觉艺术细节的同类产品形成鲜明对比。
1、如果你拥有大量未上色的木质棋子（游戏邦注：比如正方体棋子或类似象棋中卒子的棋子），而且需要用颜色来区分，最简单得方法就是在碗中装上清水并加入些许染料，将棋 子浸泡其中，然后风干。我建议将这个步骤分为两个阶段。首先，用某个棋子来测试所有的染料，看看染色之后的效果。有些颜色可能会比较接近，或者你需要通过控制浸泡时间 来调整颜色的浓淡程度，最好先进行测试，以免毁掉所有的棋子。然后，在你得出制作方法之后，将所有剩下的棋子进行处理。
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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
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.