如何才能够形成优秀的故事呢？在告诉我们如何制作可以直接应用到游戏中的有用故事时，游戏设计师通常会特别提到三部作品。如果你感到好奇的话，我可以告诉你，这三部作 品是：亚里士多德编写的《诗学》；Joseph Campbell编写的《The Hero with a Thousand Faces》；Robert McKee编写的《Story: Substance, Structure, Style and the Principles of Screenwriting》。
1、Bob Bates编写的《Into the Woods: a Practical Guide to the Hero’s Journey》。这篇文章概述了Joseph Campbell的作品，因为后者与游戏设计相关。
2、John Sutherland编写的《What Every Game Developer Needs to Know about Story》。这篇文章概述了Robert McKee编撰的书籍《故事》（游戏邦注：这部书籍本身就是亚里 士多德的《诗学》的实用指导书籍），为游戏设计师总结出故事讲述的三位一体法。
3、《Understanding Comics》第2章和第3章。在你阅读这部分的内容时，要特别注意如何将这些内容运用到游戏中。Scott McCloud并不会直接告诉你，所以你需要自己找出主要 的内容。
《诗学》中还提出了甚为著名的故事三幕结构，从根本上将故事分割成3个部分。在首个部分中，发生的事情奠定了故事的背景。在第二部分中（也是最长的部分），主角努力在事 件发生时做出某些举动。在最后的部分中，最终解决了问题。（游戏邦注：作者听过更为形象的描述，第一幕，让英雄爬上树，第二幕，向他投掷石头，第三幕，把他从树上打下 来。）
在主角的问题上，这种因果规则更具约束性。当坏事发生在主角身上时，不可能是毫无缘由的。坏事应该是由角色能够为人所理解的举动而产生的，而事件应当是该举动必然发生 的结局。这会使得观众怜惜和同情英雄，因为我们可以看到人性的弱点，我们可以理解为何该角色之前会做出那样的举动，而且我们也看到了正是之前的举动导致了最后的事件。 这也就解释了为何亚里士多德非常讨论所谓的“解围事件”（游戏邦注：也就是说，主角身上的结局毫无缘由地转好，比如“在主角濒临死亡之时，忽然醒来，意识到所有的这些 都只是场噩梦，故事结束”）。在“解围”中，英雄并不会影响故事结局，主角丝毫无从控制故事。
我并不确定Robert McKee所编写过的电影剧本是否曾被真正拍摄成电影。多数时间，他负责教授电影剧本创作。如果你曾经从电影院中走出时感叹道“这个故事真得很棒”，那么 这个剧本便很有可能出自McKee某位学生之手。
从本质上来说，故事的内涵就是改变。每个场景都应该有改变发生，或者有某些意料之外的事情发生。如果角色在某个场景的开端和末尾的状态毫无改变，那么就表明你应当移除 这个场景。以如下方式考虑问题：如果你要将自己的生活转变成时长2个小时的电影，难道你会将这些宝贵的时间浪费在日复一日的循环性任务上吗？还是说你只会呈现那些让你的 生活发生重大改变的时刻，而让观众合理地假设这些改变期间的所有事情都按照常态发生？
另一个有趣的地方是，McKee讨论了“性格”和“特征”间的不同之处。当我们定义“性格”时，通常联想到的是表面化的数据，比如最喜欢的食物、血型和发色等。McKee将这些 内容称为“特征”。“性格”是定义角色本身的因素，比如“彰显角色性格的行为”或“她有很强大的道德感”等。McKee的说法是，只有当将某个角色放在对立矛盾的情形中时， 才能够体现出角色的性格。比如，我们或许会说某个人很“无私”，但是口说无凭，只有面对某些事件的选择才能体现出角色的性格，比如在着火的建筑物内是选择救助陌生人还 是自己逃生。
性格和特征在游戏中分别指代什么呢？首先，线性化故事通过过场动画（游戏邦注：而不是游戏玩法）可以更好地展现出角色的性格。为主角做出道德选择会让玩家感到甚为艰难 ，因为选择通常并不会导致现实世界中的变故。因为这只是游戏，玩家很安全，因而他们不会失去现实世界中的任何东西。因而，玩家所做的决定并不会反映出他们自己的性格， 因为他们的性格并没有收到考验。在现实世界中为好友挡子弹与在游戏世界中决定是否获取Light Side Points并非完全相同。在游戏中加入道德考验并非不可实现，但是那些选择 的所产生的情感后果很难真正被玩家感受到。，因为做出这些决定的是玩家而不是主角。因而，在玩家无法控制故事时呈现强大的性格也会更加容易。
Joseph Campbell花了大量的时间来研究深化、传说和英雄故事，寻找它们之间的相同和不同之处。他发现多数神话普遍采用某种结构，他将其称为“Monomyth”或“Hero’s Journey”（英雄之旅）。这是种具体的故事类型，因而所阐述的内容比McKee得故事描述更为具体。由于许多游戏将玩家视为英雄，所以了解以下内容也是很有用处的。
1、想想许多电子游戏中的主角，包括Master Chief、Samus Aran、Gordon Freeman和Chell等。通常情况下，你不会看到自己所控制角色的过多信息，你也听不到他们的许多话语 。这种情况的出现并非偶然。这是故意设置的，使玩家可以将他们自己的个性融入到角色之上。角色成为了玩家的延伸，你觉得自己与角色存在情感维系，因为二者已经融为一体 。
2、此外，你也会看到某些定义分明的强势角色，如Duke Nukem和Lara Croft。在这种情形中，我们迅速地识别出主角并非我们自身。为补偿这种感觉，角色们必须展现出强大的个 性。
4、再考虑下游戏中的敌人和对立角色。因为现实主义视觉能够产生外部感，高度细节化的敌人让玩家看起来非常陌生，而有着卡通化和或图标化感觉的敌人看起来会更加熟悉。视 频游戏《毁灭战士》中的怪物以现实主义风格绘制而成，让它们看起来更加像外星人，因而感觉起来更加危险。相反，《口袋妖怪》中的怪物更为卡通化，让它们看起来更加友好 ，这完全适合这款可以招募怪物将其转变成好友的游戏。在桌游中，我们希望接触的是那些有着图标化棋子（游戏邦注：如象棋中双方颜色不同的棋子）的游戏，这可以让玩家将 棋子视为自身的延伸，其他玩家的棋子也能够带来某种熟悉感。相对而言，有着高度细节化棋子（游戏邦注：带有深层次角色描述的现实主义风格小模型）让玩家将自己和角色区 分开来，而且也会导致玩家之间处在对立面上。
我想要让你注意的最后一个要点是McCloud的“blood in the gutter”概念（游戏邦注：书中66页到69页）。在书中描述了两个场景，其一是谋杀者将斧子挥向受害者，其二只是 展示了个尖叫声。受害者的死亡时间是何时呢？在这两个场景之间，正是你这个读者靠着自己的想象力杀死了他，而这个画面并没有真正呈现出来。
这便是所有故事讲述媒介中的暗示。Alfred Hitchcock是这方面的大师级人物。比如，在著名的《Psycho》中，事实上你并没有看到任何内容。有个人手上拿着刀做出刀割的动作 （游戏邦注：并没有呈现出任何受害者），另一个画面是妇人尖叫的声音（游戏邦注：并没有呈现受害者是她），如此反复并最终呈现流淌的血液（游戏邦注：此时谋杀者和受害 者画面都没有呈现出来）。
游戏设计师Ernest Adams在GDC 2006上做了个鼓舞人的演讲，题为“互动故事新愿景”。首先，他简单地总结了上文中描写的某些内容，然后进一步挑战我们所有的基本想法，随
2、Campbell的Hero’s Journey的效能仅限于英雄故事。那么，如果你的故事与英雄无关又会怎么样呢？而且，正如Campbell自己承认的那样，Monomyth并非模板，所以我们不能 将其用作构建故事的工具。
Ernest提出了另一个设计师的规则，他称之为“Ken Perlin原则”：互动故事中事件的成本必须与它的不可能性成比例关系。那么，“成本”的含义是什么呢？他解释道，每个作 者都有个“可信度预算”，如果发生了过多令人不可思议的事情，故事就会让人产生怀疑。故事中发生的所有不太可能发生的事件的总和不能超过某个特定的数量，否者便会引起 玩家的反感。（自然，某些游戏与其他游戏相比有较高的可信度预算，这与游戏所设置的场景有关。比如，在魔法世界中，在空气稀薄的高空中出现小鸡是稀松平常的事情，而在 现实主义现代化场景中，这种情况会被人当成是不恰当的设计。）
作为互动故事设计师，从本质上说你是在与玩家达成协定：如果你（也就是玩家）做出可信的行动，你就会得到可信的故事。这是很重要的，因为设计师和玩家共享可信度预算。 玩家必须接受故事所设置的场景。如果玩家采取与故事世界不相一致的举动时，他们得到的就是不可信的故事，而且过错并不在故事作者，而在玩家。如此，故事作者的目标并非 创造出在所有情况下都100%可信的故事，他们必须实现的是在玩家采取可信做法时呈现出可信的回应。
正如我们从Doug Church的《Formal Abstract Design Tools》中所看到的那样，玩家意向和叙事间存在某种平衡。但是，我们可以通过玩家和设计师间达成的“角色扮演”社交合 约来扩展。
* Noah Falstein的《A Point of View》。我们将故事叙述视角划分为“第一人称”或“第三人称”——我们也以此谈论视频游戏视角。因此我们很容易会认为二者存在关联性， 但其实并非如此。文章清楚阐述二者存在的差异。
* Chris Bateman的《Diversity in Game Narrative》。这主要概述游戏存在的各种故事结构。
* 《Challenges for Game Designers》第13章。
若我们想要添加决策因素，最明显的办法就是在线性故事中添加各种决策点。当玩家到达特定地点时，他们需决定怎么选择，然后故事就会沿某路线发展，直至到达另一选择点。 典型例子就是Sega Genesis的《梦幻之星III》；主角有两次在两位女孩中选择一位作为结婚对象的机会，这就带来4个分支路线，每个路线都有自己的故事和结局。
但分支故事存在一大缺点：成本很高。就两种选择而言，《梦幻之星 III》故事创作者就得编写4种故事。若是存在第三种选择，他们就得编写8种故事，而10种选择则需要1024种 故事！想想典型策略游戏玩家所做的决策数量，你会发现编写分支故事任务瞬间变得难以驾驭。
用Bateman的话说，这是自行分解的分支故事，允许玩家做决策，最终将全部内容压缩成若干命令事件。例如，在《Silent Hill》中，玩家享有若干选择， 或发展故事，或沿途呈 现某些额外故事元素，这些都会影响结局。但无论玩家有没有进行额外操作，有些事件他们无法回避。
Bateman用此形容分解成小块内容的故事，也许还有若干故事情节（游戏邦注：这些故事也许相互交错）同时进行。玩家选择以何种顺序进行，采用哪个路线。例子之一就是《魔兽 世界》，其中玩家能够选择任意关卡，体验不同故事元素。另一例子是《上古卷轴》系列，玩家能够基于自己的期望选择特定故事情节，玩家会沿途操作其他关卡或次要情节。这 些次要情节也许会给主要故事情节带来影响。
假设存在第二人称摄像头视角，它主要指玩家从正面观察主角。毋庸置疑，这会令多数游戏陷入混乱局面。最贴近的例子就是晦涩的掌机游戏《Robot Alchemic Drive》，其中玩 家控制人物角色（第三人称），而角色反过来会通过遥控装置控制庞大机器人（第二人称）。从此意义上看，机器人就是主角，游戏就是采用第二人称摄像头视角。
原型 & 固定模式
若故事和玩法的情节脉络保持协调和同步，我们能够得到更富戏剧色彩的体验。实际操作要困难许多；在许多游戏中，最困难的玩法通常发生在游戏中间，也就是敌人和挑战变得 更加困难，而你尚未找到新武器、新升级渠道的时候。随着玩家的日益强大和熟练，游戏的挑战性就会逐步降低，虽然此时故事的紧张度日益提高。我们能够基于大量的戏剧元素 和预兆判断游戏何时进入最终boss战斗，然后玩家挥舞宝剑几秒钟后便获得胜利（游戏邦注：这听起来有些虎头蛇尾，缺乏可信度）。
然后，你将会邀请一些好朋友，亲戚，知己等加入你的游戏。与它们分享你设计的游戏，并与他们一起游戏，接受他们的反馈。而这个步骤主要是衡量你的游戏是否有趣（游戏邦 注：如果游戏缺少乐趣，你便需要重新采纳另一个理念，或者修改当前的理念并再次尝试）。如果在一开始就察觉到游戏缺少乐趣，那么你最好尽快摒弃这一理念，不要再浪费时 间去尝试这些没有结果的无用功。游戏想法虽然廉价，但是执行力却非常可贵，所以适时的行动非常重要。
如果你在参加这个课程之前从未设计过一款完整的游戏，那么你就更应该仔细阅读这些限制因素。不论你是创造桌面（棋类）游戏，卡片游戏或者置放指示片游戏（这就意味着这 些游戏的物理元素中都必须包含有棋子，卡片以及置放指示片）。这些游戏不只要包含一个以上的这些元素，同时也需要包含一些额外元素（如骰子等）。你可以自己选择任何主 题，只要这个主题具有独创性，即不会侵犯任何现有的知识产权。简而言之，如果你的作品侵犯了他人的商标或版权，那么请你果断摒弃它。也许在你的职业生涯中将会遇到许多
我将列出两个对你有帮助的限制因素。首先，你并不是在创造一款智力问答游戏，或者其它需要依赖于大量内容的游戏，如《打破沙锅问底》（游戏邦注：一种问答游戏），《看 图说词》，《Apples to Apples》（一款英文字配对游戏）或者《大脑测试》等。这些游戏的目的都是将玩家的视线限制在一个层面上；即你必须回答出足够的智力问答才能够获 得卡片，而这时候你便缺少足够的时间去体验游戏机制。卡片交换游戏（如《万智牌：旅法师对决》以及《宠物小精灵TCG》）也属于这类型的游戏，因为它们都要求玩家花大把的 时间去收集更多卡片。
其次，在很多游戏形式中你并不能使用“掷骰与移动”游戏机制。如此有几点原因。首先，这种机制的使用频率实在太过于频繁。而且《大富翁》已经是这类型游戏的最佳代表了 ，所以你便很难摆脱对于这款游戏的模仿了。就像《Chutes & Ladders》等多数游戏都把“掷骰与移动”当成游戏的核心元素。其次，游戏机制在每一个回合中都能为玩家做出重 要的决策，而玩家自己却不行。如果一款游戏蓄意地区分了玩家与游戏结果，那么玩家将会认为游戏不再有趣而不愿意继续玩游戏。
设计一款带有很多嵌入式叙述框，能够让玩家在游戏中进行交流的游戏。在桌面游戏中，你不得不思考如何做才能通过玩家的行动去描述一个故事，以及如何整合叙述内容和游戏 机制。如果你对角色扮演游戏或者其它以讲故事为核心的游戏感兴趣，那么这一点都很适合。创造一款针对于2名以上玩家的纯粹合作式桌面游戏，而游戏中任何一名玩家的胜负都 由团队所决定。这其实是一种挑战，因为当玩家并不能相互对立竞争时，游戏就必须提供一种完全相反的系统。合作式游戏存在的一个问题便是较有技巧的玩家总是能够指挥其余 玩家（尽管这是一种需要所有人共同配合的游戏），从而导致出现MDA Aesthetic模式，即玩家会因为不满其他玩家的命令或指挥而对游戏感到厌烦。而如果你对游戏的社交性感兴 趣的话，这点便是不错的选择。
但是相对的，也有很多人更喜欢制作电子游戏。我想提醒你们的是，在制作电子游戏的过程中，你必须将大量的时间用于游戏美工和编程过程中，所以如果你真心想要学习游戏设 计，最好选择那种能够让你投入更多时间于设计中的游戏。不论你设计的是硬纸板游戏还是编码游戏，游戏设计的原则和概念都是关于游戏，所以如果你掌握了电子游戏的设计技 巧，你便可以将其运用于桌面游戏的制作中。
也有些人喜欢创造桌面角色扮演游戏。我想提醒你的是，我们总是很难去评估角色扮演游戏的设计，因为有技巧的游戏管理员和玩家总是能够挽救一款糟糕的系统（但是毫无经验 的玩家也可以摧毁一个非常优秀的系统）。如此导致我们更难去评估游戏测试，所以先尝试桌面游戏便是个很好的选择。在过去几年里，桌面游戏与角色扮演游戏之间的界限变得 越来越模糊了，如侧重于叙述的桌面游戏《Android》以及侧重于游戏机制的角色扮演游戏《D&D 4th Edition》。
也许你们在现实世界中还有一些其它的限制因素。也许你会为了避免不必要的开支而不愿意花钱去创造游戏原型。也许你住在一个偏远的地区，缺少足够的原型材料，只能用仅有 的材料去创造你的游戏。也许你没有太多时间专注于游戏中，所以你只能够设计一款较短的游戏（以便你能够在短时间内完成游戏测试和迭代）。如果你在现实生活中找到一些对 你的游戏有影响的限制因素，你应该真正把它当成这个项目中非常重要的一部分。设计者不应该抱怨资源不足，相反地，他们应该利用所拥有的一切资源努力制作出最棒的游戏。
对桌游而言，可用性更为重要，因为没有电脑来对玩家的输入做出回应。如果你误解了《大富翁》中房屋的用处，将其建设在Community Chest上，游戏并不会阻拦你这么做。通过 观察尝试玩游戏的玩家，你可以学到许多有关如何设计各种游戏的东西，使得游戏更容易使用。
如果某种类型的玩法存在会导致玩家忽略游戏中多数有趣选择，那么有趣的游戏便会迅速变得枯燥乏味。如果胜利的战略只有1种，而胜利的关键是哪个玩家能够更好地使用这种战 略，那么其趣味性就不如那些有多种胜利途径的游戏。比如，如果某个玩家存在明显的优势，那么让其他玩家感受到游戏并非不公平就变得很重要了。该类型测试的目标是找到游 戏中的不平衡之处，这样设计师才能够进行修正。
2、一旦你知道拥有某些东西，你就需要加固机制。对整款游戏进行设计，确保所有的细节都被顾及到。测试游戏中的“漏洞”。（游戏邦注：应当注意的是，漏洞测试贯穿软件项 目的整个开发过程，项目完成度越高测试越频繁。但是，非数字化游戏的“反漏洞”更加容易，而“漏洞”的存在可能会中止测试进程，所以在开发过程早期制定一套完整的规则 很重要。）
4、当游戏能够运转并且平衡后，到末期你就要更多地考虑游戏的可用性。改变可用性并不会改变机制，发生改变的仅仅是那些机制呈现给玩家的方式而已。这个重要的步骤往往被 忽略。游戏的习得只能靠其他玩家教授（游戏邦注：即自己阅读规则的对立面），这便是你需要在项目中避免出现的可用性错误。此刻你可能还需要进行额外的专注测试，确保游 戏的主题和视觉元素能够吸引目标用户。
比如，考虑以下4 X 4格子一字棋的规则：
(3) 背景：绘制4 X 4的正方形方格。
背景：绘制4 X 4的正方形方格。选择先行动的玩家，指定其使用“X”标志。另一个玩家使用“O”标志。
“死路”指游戏到达无法继续进展下去的状态，但此刻游戏依然没有结束。想想上文中我们修改过的4X4一字棋规则。假设两个玩家画满了棋盘上所有的格子，但没有人获胜。这种 情况下，游戏无法进展下去，因为规则要求玩家必须在空白的格子上画标志。现在没有空白的格子，因而玩家无法继续按回合进展下去。但是游戏依然没有结束，因为两名玩家都 没有获胜。在这种情况下，就必须添加新的规则（游戏邦注：比如，在完结条目中添加，如果玩家无法继续行动且没有人获得胜利，那么游戏结果就是平局）。
是否存在某个可以很容易地赢得游戏的战略。努力找到它。相比被测试者发现（游戏邦注：更糟糕的情况是，在游戏发布后被玩家发现）来说，自己发现并修正产生的尴尬要少得 多。在你自己制作的游戏中找到清晰度和优势规则缺陷往往较难，毕竟你曾努力将游戏设计得毫无问题。但是，在这方面做些努力，你可能会在早期便找到和修正某些错误（游戏 邦注：从长期来看，这会节省设计师大量时间，也就有更多的时间重复审视游戏设计的其他部分）。
我想，真正发生的事情就是，游戏的创造是个学习的过程。你或许对游戏如何终结有自己的想法，但是最终版本可能与你最初的愿景有很大的差别。发生这种改变的原因在于，刚 开始你对自己的游戏并不十分了解。你有某些基础想法，但是你并没有真正明白机制的互动形式以及动态和美学的情况。在测试过程中，你对游戏系统的运转方式有更深的了解。 随着你逐渐学习和了解，你就更能够预测改变会对系统产生怎样的影响。
常规玩家（例如，好友和家人，或者甚至是陌生人）在此的作用非常有限。通过观察他们，你就能够判断他们是否玩得愉快，你的作品是否达到设计目标。但若游戏存在问题，玩 家就无法向你提供有用信息，他们所呈现的反馈无非就是“好极了”或“糟透了”。此时作为设计师的你就需要发现和解决问题。因此，设计师可以在必要时候借助常规玩家，但 他们的作用非常有限。
若你刚好在其他游戏公司任职过，那你定认识某些曾共事过的设计师。在这种情况下，寻找熟练测试者就非常简单。这里的难点是专业设计师通常忙于自己的工作，无法腾出时间 帮你。你需要配合他们的时间。同时要提供某些有价值的东西作为交换。从根本来说，你其实是在寻求专业游戏设计顾问的帮助。你的同事也许有在别处兼职，每小时能挣40-250 美元（游戏邦注：这取决于他们的经验和项目性质）。若他们免费为你腾时间，那么你将来务必也在他们的项目中付出同等的时间。至少你得心存感恩。
若你无法从论坛上找到同地区的其他人士，最后一招就是将你的作品发布到网站上，在论坛上征求测试人员。其他设计师也许也面临相同困境。同样，若他人愿意查看你的作品， 提供反馈信息，你也要给予相同反馈，测试他们的作品。当你以此形式测试他人作品时，确保向其说明如何组装可玩模型。以此形式进行游戏测试的最简单方式是单独测试彼此的 作品。另一选择就是网上碰面，即时进行远程体验。
* 当测试者发现漏洞时，你的职责不是替游戏辩护或陈述测试者的错误之处。首先，即使测试者“错了”，其他玩家也许也会犯相同“错误”。其次，测试者也许是对的——他们 以全新视角查看你的游戏，通常不会存在什么偏见。
* 不是所有玩家都表现得体。有时他们会发表某些关于游戏的可憎言论。有时他们会嘲弄你的游戏，或因某设计问题而斥责你。记住无论他们如何表达，这些内容仍是非常有用的 信息。
* 听到“你的游戏糟透了，这是我玩过最糟糕的游戏，或更进一步，你糟透了，你简直就是多余之人”这样的言论，而依然能够真诚地答道：“你帮我发现游戏存在的某些糟糕漏 洞，非常感谢”，这需要设计师境界高深。让自己在现实生活中变成意志坚强之人，能够互相交换角色，应该是游戏设计师的长期目标之一。你无需立即做到这点。我也没做到。 但我之前曾看到某杰出设计师就是以这种姿态和别人相互测试游戏，这令我意识到自己还有很长的路要走。
* 在向其他玩家呈现游戏时，确保自己清楚把握规则，这样你无需进行查阅。试着对着镜子向自己解释所有规则，确保自己能够做到这点。这能够节省时间（游戏邦注：这样你只 需花几分钟而非半小时就能将规则解释清楚）。
* 尽快结束游戏测试。若经过半小时体验你就已收集到所有潜在有用信息，那么就此打住。记住进行测试的目的是发现问题，而不是“体验游戏”。若你无法从中发现问题，那你 就是浪费大家的时间。
* 记住进行游戏测试的目的很多。查看游戏是否有趣？期望获胜？发现规则存在的漏洞？我们会以相应方式进行体验。我们习惯以自己的风格体验游戏，这令我们容易忘记其实还 有其他体验方式。确保牢记游戏测试的目标。
Up until this point, we have talked about games from a purely ludological viewpoint. That is, we have looked at games as a system of rules, with the implicit assumption that the rules are the game, and that a narrative of any kind is just window dressing. (Any word with the root lud- or ludo- is referring to games; the root is Latin for play. We use words like ludology and ludography and ludic because everything sounds more distinguished if you say it in Latin.)
But this is not entirely true. As mentioned when we talked about kinds of decisions, some player choices may have absolutely no meaning within the game system and yet they are still meaningful because they are emotionally charged.
Those of you who play tabletop Role-Playing Games are probably more keenly aware of this. Think of the most interesting play session you’ve ever had. You’re probably not thinking of a die roll, or an interesting strategic decision that a player made in combat. You’re remembering something dramatic, emotional. You remember the story, not the die-rolling.
What makes for good stories? Game designers often reference three works in particular that tell us how to make useful stories that apply directly to games. If you’re curious, these works are: Poetics, by Aristotle; The Hero with a Thousand Faces, by Joseph Campbell; Story: Substance, Structure, Style and the Principles of Screenwriting, by Robert McKee.
Today we will look at these works and their effect on game design. We will build up a set of guidelines for how to tell a good story within a game. And then, at the end, we will tear it all down again.
As I’ve been out of town and offline since early Friday morning, I have not had time to validate new user accounts for the forums, read email, moderate comments on this blog, etc.
I will catch up on these things later today, or tomorrow morning at the latest, after I have fully recovered from a nearly-sleepless (in a good way) weekend. I’ll say this: playtesting your games with skilled game designers is very different from playtesting with typical gamers.
Here are some new kinds of fun that were proposed from last time:
“Servant”: opposite of a griefer, someone who gets pleasure out of making sure other people have a good time. (I would actually call this something else, like “Party Host”… and yes, it makes sense that this would be valuable to a hunter-gatherer. You are showing value to your tribe. I understand that Disney has identified this as a customer archetype, usually associated with the mom in the family.)
“Maker”: someone who gets joy out of constructing and building things. (The example given was user-generated content for video games, but you sometimes see this in standalone board games as well, like Settlers of Catan. Certainly, building and construction are useful to survival, even if all you’re making is a tool or a crude hut.)
Read the following:
Into the Woods: a Practical Guide to the Hero’s Journey by Bob Bates. This article summarizes Joseph Campbell’s work, as it is relevant to game design.
What Every Game Developer Needs to Know about Story, by John Sutherland. This article summarizes the book Story by Robert McKee (which itself is essentially a practical guide to Aristotle’s Poetics), rounding out the Holy Trinity of storytelling for game designers.
Understanding Comics, Chapters 2 and 3, if you have a copy of that book. As you read, pay particular attention to how any of this might apply to games. Scott McCloud isn’t going to come out and say it, so you will have to connect the dots yourself.
A lot of words were different in Aristotle’s time than how we use them today. Poetics is not about poetry, but about how to write tragedy. Tragedy, as Aristotle used the term, did not mean “a story with a sad ending” but rather a story that is serious and lifelike – a story devoid of the supernatural or fantastical (which he referred to as comedy).
However, one thing that hasn’t changed in all this time is that there is still a lot of really bad writing.
Aristotle may not have been the first to notice, but he was certainly one of the first to actually do something about it. He wrote about how to write a decent story. If a lot of his advice sounds familiar, it is because it is often repeated in writing classes, even at the elementary school level – although Aristotle may or may not be credited for the idea in any given class.
For example, have you ever heard that stories should have a beginning, a middle, and an end? That was from Poetics. It is a reminder that there are different parts to a story, and that the writer should be aware of how it all fits together.
Poetics also defined what is known as the three-Act structure for stories, basically a division of a story into three parts. In the first part, something happens to set the events of the story in motion. In the second part (which tends to be the longest), the protagonist tries to deal with the events as they happen. In the final part, a resolution is reached. (I’ve heard it described thus: in the first act, get the hero up a tree; in the second act, throw rocks at him; in the third act, get him down.)
One important thing that Aristotle really hammered on is that each scene should follow the previous ones with a logical cause-and-effect relationship. Weak writing goes like this: “X happens, then Y happens, then Z happens.” Stronger writing is more like this: “X happens, and because of that Y happens, and because of that Z happens.”
This cause-and-effect rule is even more restrictive when it comes to the protagonist. When bad things happen to the main character, it should not be random; it should be caused by that character’s understandable human action, and it should follow as a plausible and inevitable effect of that action. This makes the audience pity and empathize with the hero, because we can see the human weakness, we can understand why the character did what he did, and yet we also
see that it causes his undoing. This explains why Aristotle really hated what was called deus ex machina (that is, an ending where everything is suddenly made better through no fault of the main character – for example, “…and just as the main character was about to die, he woke up, and realized it was all just a bad dream, The End”). In a deus ex machina, the hero is not the cause of the ending. The main character is not in control of the story.
Applying this to games, it becomes clear why it is sometimes so frustrating when, for example, a character in a video game dies during a cut scene. The one time the player doesn’t have any choice – the one time when the main character is not in control – is the one time when the plot advances.
Lastly, it is worth mentioning that Aristotle defined a stage play as being comprised of six elements. We have similar elements in games with a strong story component:
Plot. The narrative that describes what actually happens.
Theme. What does it all mean? Why does it happen?
Character. As in, a single role within the story.
Diction. The dialogue, and also the actor’s delivery of that dialogue.
Rhythm. This does include “rhythm” in the sense of music, but also the natural rhythm of human speech.
Spectacle. This is what Aristotle called the “eye candy” or special effects of his day. He often complained that too many plays contained all spectacle and nothing else – sound familiar?
I’m not sure if Robert McKee ever actually wrote a screenplay that was made into a movie. Mostly, he teaches screenwriting. If you’ve ever come out of a movie saying “wow, that was a really great story,” the screenplay was probably written by one of McKee’s students. (I would love to be considered the “McKee of games” some day. Note to my former students: go out there and make me look good!)
Story is essentially a re-telling of Poetics, but made specific to screenwriting for movies. I found Story to also be a lot more accessible to read; it is written in a conversational style (not to mention that it is written in contemporary English and not ancient Greek). To paraphrase a few of the many lessons from McKee’s book:
Story is not about formulas, it is about forms. You do not create a story by following a template. However, by understanding the common links between different stories, you can make one that is unique. (I would add that the same is true for everything in this course.)
All stories have this form:
The protagonist has a goal, which is created by an inciting incident.
The protagonist tries to reach the goal, but a gap (that is, some kind of obstacle, not necessarily a literal gap) opens up and prevents the immediate achievement of the goal.
The protagonist attempts to cross the gap. Either the gap widens and they are unable to cross, or they do cross the gap but a new gap appears.
This cycle of gap-crossing continues until the protagonist either finally completes the goal, or is prevented from completing the goal in an irreversible manner.
In a typical three-Act structure, there are two reversals (new gaps) that happen between the Acts.
Stories are, at their heart, about change. Every scene should change something, or have something unexpected happen. If a scene has the characters in the same state at the end as it was in the beginning, that’s a sign that you should remove that scene. Think of it this way – if you were to convert your life into a two-hour movie, would you waste any screen time on your day-to-day maintenance tasks? Or would you only show the times when something big changes in your life, and allow the audience to assume that things are carrying on normally in between?
Notice how nicely this dovetails with games. Games are about decision-making, which causes a change to the game state. Games rely on having an uncertain outcome, and it is only at the very end that a goal is attained or lost in an irreversible manner. It is not surprising, then, that some games have very strong emergent stories that arise from a particular play experience.
Another interesting thing McKee talks about is the difference between what he calls character and characterization. The things we normally think of when we define a “character” are superficial data: favorite food, blood type, hair color, and so on. McKee calls these characterization. Character is what defines the person – used in the sense of “this activity builds character” or “she has a strong moral character.” What McKee says is that character can only be revealed by putting a person in opposition. For example, we may say that someone is “selfless”… but until they’re in a burning building and have to make the choice between trying to save a total stranger or saving themselves, it’s all just talk.
What is the implication of character and characterization in games? First, that linear stories have the best opportunity to show character through cut scenes, not gameplay. Having the player make moral choices for the main character is hard, because the choices often don’t involve real consequences. Because this is play (“only a game,” the “Magic Circle”), the player is safe, and therefore has nothing in their own real world to lose. The player is therefore not making choices that reflect their own character, because their character is not being tested by extreme opposition. Taking a bullet for a
friend in the real world is not quite the same as deciding in a menu whether or not to gain Light Side Points. It is certainly not impossible to embed moral dilemmas in a game, but it is a lot harder to make the emotional consequences of those choices felt by the player, because the player is making those decisions and not the protagonist. It is therefore much easier to show strong character when the player is not in control of the story.
But of course, that also makes it less interactive and thus less like a game. And this is one reason why storytelling in games is hard.
Joseph Campbell spent a lot of his time studying myths, legends, and hero stories, and finding the similarities and differences between them. He found that most myths follow a common structure, which he called the Monomyth or the Hero’s Journey. It is a specific kind of story and therefore more specific than McKee’s story description. Because many games put the player in the role of a hero, this is obviously useful to know.
The Hero’s Journey goes something like this:
The hero starts off a commoner in a common world, and this “normal” world is established.
The hero receives a call to adventure.
The hero may decide to follow the call, or to ignore it. In the latter case, new events then force the hero to follow the call anyway.
The hero starts their journey and encounters the first barrier. There is often a guardian that must be overcome to proceed.
The hero then moves through the barrier into a new, darker world. They follow a trail of trials, each more difficult than the last. Along the way, the hero grows – not just in the “experience points” and “levels” sense, but in the “coming of age” sense. The hero becomes a better person. They become, well, a real hero.
Eventually, the hero encounters the final evil, and is able to overcome it.
The hero claims the prize.
The hero starts returning to their world. Along the way they encounter the final barrier.
Finally, the hero returns to their common world. The world may be the same, but the hero has changed.
You may recognize this structure in many hero stories, and Campbell’s book goes into detail about why each of these things happens, what it symbolizes, and what it says about our values as a society. In short, hero stories are about what a particular culture sees as the ideal set of ethics and values, and the hero character embodies and demonstrates these things.
Now, you might be tempted to use this as a formula. Get a list of archetypes with a checkbox next to each, and presto, you now have a suitable story! Unfortunately, it’s not that easy. As McKee says, stories (and hero stories are included in this) are not about formulas, but forms. The purpose here is not to follow the Monomyth blindly.
What use is it, then, if we cannot use this to make a story? I think the most important thing to take from this is to be aware of what the common story forms are, so that you call follow each step or not as appropriate to your own story. But, it is important to do so deliberately and not just “because Campbell said so.” Note that not all games follow this structure – especially games where you play an anti-hero.
Bob Bates comments on the structure in his article:
When writing, start with a core premise or vision first. Choose a hero and villain that embody your premise.
Show the hero’s common world, then disrupt that world through an inciting incident. This is typically what happens at the beginning of a game.
Enter the “woods” – the game itself.
“Encountering the evil” is essentially a description of a boss fight – suggesting why we see so many boss fights in games!
“Claiming the prize” can be thought of as the hero realizing the Premise of your story. It does not have to be finding a literal “prize” like a bag of gold or a princess or an ancient magical artifact.
During the game, the hero character should grow. Again, it is easy for us as designers to fall into the trap of only having the main character “grow” in terms of power level (and it is convenient that the player is growing in their skill at the game as they play). Still, it can often make a better story if the hero’s character grows during the story as well. They don’t have to start out as a god. It can be more interesting if they start out as a peasant and become a god. Remember, it’s the hero that must grow, not just the player.
Understanding Comics doesn’t say a lot about telling stories in Chapters 2 and 3, but it does give some useful advice on creating strong characters and
On pages 44-45, McCloud notes that art styles can vary between iconic (like a smiley face) and photo-realistic, with many potential steps in between. He points out that the more iconic something is, the more we project ourselves onto it; the more detailed and realistic, the more we see it as something other than ourselves. (Taking it back to Koster, we can say that this is because our brains are wonderful pattern-recognition machines, and we will fill in the blanks with what we already know from the vast library of patterns we’ve built up.)
What are the implications of this in games?
Consider the main characters in many video games – Master Chief, Samus Aran, Gordon Freeman, Chell. You do not typically see your own character much at all, nor do you hear them speak much. This is not an accident. It is done deliberately to allow the player to project their own personality onto the character. The character becomes an extension of you as the player, and you feel an emotional connection to the character specifically because they are not very well defined.
On the other hand, you can also have a strong character that is very defined – Duke Nukem or Lara Croft, for example. In this case, we immediately recognize the main character as not ourselves. To compensate, they must show a strong personality.
In general, then, I would say that you can go one of two ways with the main character. Make it iconic and do not define its personality (to allow the player to create one for themselves), or make it realistic and define its as a very strong character. Any other combination makes it harder for the player to connect emotionally with their avatar.
Also, consider the enemies and opposition within the game. Since realistic visuals impart a sense of otherness, enemies that are highly detailed will seem very alien, while enemies that are cartoony or iconic feel more familiar. The monsters in the video game DOOM are drawn in a realistic style, making them seem more alien and thus more dangerous. By contrast, the monsters in Pokemon are cartoonized, making them seem more friendly, which is fitting for a game where you can recruit enemies and turn them into allies. In board games, we would expect that games with iconic tokens (like colored pawns) that represent players make the pawn into an extension of the player (a sense of familiarity), and also that other players’ pawns have a sense of the familiar – it promotes togetherness. By contrast, games with highly detailed tokens (realistic miniatures, or detailed art or photographs of player characters with in- depth character descriptions) gives a sense of separation between player and character, and also would cause players to regard each other as pposition.
This also has applications when dealing with environments. If the environment (whether a 3d computer level or a 2d physical game board) is photorealistic, it is a reminder to the player that this is an other world. This is more suitable for games that wish to make the players feel like they are in an exotic or unsettling location. For example, suspense and horror games would do well to include highly photorealistic environments.
Another point that McCloud makes (on page 38) is that we are made to use tools, and we see those as an extension of ourselves. Our sense of self extends not just to our own bodies, but to everything under direct control. As he points out, when you are in a car accident, you are more likely to say “hey, they hit me” than “their car hit my car.” It becomes personal.
What does this have to do with games?
For video games, a console controller (or mouse/keyboard) becomes an extension of the human body. The player thinks of the controller as part of themselves. This explains why play control and a good user interface is so important for video games – if you have trouble figuring out how to use the controller, it is just as frustrating as if you tried to pick something up with your hands but your hands didn’t respond.
For both video games and tabletop games, the avatar (that is, the representation of the player within the game) acts as an extension of the player as well. As with an auto accident, if your opponent lands on your pawn and sends it back to start, you are likely to say “hey, they just sent me backwards.” As a designer, be aware of the player’s emotional attachment to their avatar within the game.
The last thing I’d like to draw your attention to is McCloud’s concept of the “blood in the gutter” (pages 66-69). In the book, there are two panels, one with a murderer swinging an axe at a victim and then the next that just shows a scream. When did the guy die? Between the panels… and it was you as the reader, with your imagination, that killed him. Nothing was actually shown.
This has implications in all other kinds of storytelling media. Alfred Hitchcock was a master of not showing anything. As an example, in the famous Psycho shower scene, you actually never see anything. There is one shot of a guy making a stabbing motion with a knife (but not showing any victim), juxtaposed with another shot of a woman screaming (but not showing her being stabbed), back and forth, and eventually a shot of fake blood running down a drain (without showing either the murderer or victim).
How do we apply this to telling stories in games?
Some storytellers have a strong desire to give evey last technical detail of how everything works and every last bit of backstory in their fantasy world. But this is not necessary. Players will fill in the blanks on their own. You don’t actually have to tell them anything.
In fact, it is often more effective if you don’t! A player’s imagination is infinitely more vivid than the artwork in your game.
Think of the player as an active participant in your story. They will be thinking about it anyway; write a story that rewards them for using their imaginations.
This also has an economic advantage. We tend to pour a lot of money into detailed art and long, drawn-out cut scenes, but if we economize and show less, the net effect can actually be more powerful if we do it right.
In other words… less can be more. Finding the balance between “enough information to understand what is going on” and “not so much information that nothing is left to the imagination” is one of the trickiest jobs of a story writer, and is another reason why storytelling in games is hard.
Think of some examples of stories you’ve seen (from games or otherwise) where there was too little information, or too much, and the story suffered from it. Think of other examples where you were not told everything, but was fine, and the audience was able to still have an enjoyable experience.
Game designer Ernest Adams gave an inspiring talk at GDC 2006 called “A New Vision for Interactive Stories.” First he briefly summarized much of what I have written above, and then he proceeded to challenge all of our basic assumptions, and then he tried to take things one step beyond. What follows are my notes and personal commentary from the session.
Aristotle’s Poetics is great, but never forget that it was written for stage plays and not games. Stories may have a beginning, middle and end… but in games, they can often have multiple beginnings, and middles, and ends. The three-Act structure works great for a two or three hour play (or movie), but is not necessarily appropriate for a 30-minute board game, a month-long RPG campaign, or a 100-hour console game.
Campbell’s Hero’s Journey is limited to hero stories. What if your story isn’t about a hero? Also, as Campbell admits, the Monomyth is not a template, so we cannot use it as a tool to build our stories.
McKee’s Story is focused on screenplays, so it may or may not be applicable to every game. Games are a different medium than movies. While there are some similarities, it is important to be aware of the differences, so any advice on screenwriting must be used with caution when applied to games.
So, if none of this stuff is useful, are we back to square one? (I don’t think so. We still have to start somewhere, and starting by studying what makes a great story in other media is still a useful starting point. We will get into the unique forms of interactive stories this Thursday.)
Adams then stated three assumptions that we often make when trying to tell stories in games:
The “holy grail” of interactive stories is a complete sandbox, a “Holodeck,” a perfect world simulation that responds believably to all player input.Interactive stories aren’t games.
When a player is involved in an interactive narrative, they should be thinking about story and not game mechanics.
He then challenges these assumptions.
First, what could be wrong with having a perfect world simulation? There is always the practical reason that it would be infinitely expensive. And then there ’s the argument from Koster that we already have one of those, it’s called the Real World, and it’s not always fun. But mostly, the problem here is that even in the most “open-world” games, players do not get their enjoyment from complete freedom… but rather, from having freedom within a constrained environment.
Ernest proposed a rule from another designer, which her referred to as “Ken Perlin’s Law”: the cost of an event in an interactive story must be directly proportional to its improbability. What does he mean by “cost”? He explains that every writer has a “credibility budget” – and if too many incredible things happen, you violate suspension of disbelief. The cumulative sum of all improbable things that happen during your story need to not exceed a certain amount, or the players will call foul. (Naturally, some games have a higher credibility budget than others, based on their setting – chickens appearing out of thin air may be mundane in a high-magic world, but would be considered out of place in a realistic modern-day setting.)
As a designer of an interactive story, you are essentially making a pact with the player: if you (the player) act believably, you will get a believable story. This is important – both the designer and the player share the credibility budget. The player must accept the premise of the story as part of stepping into the Magic Circle to play. If the player acts in a manner that is inconsistent with the world of the story, and gets an unbelievable story back, that is not the fault of the story writer; it is the fault of the player. As such, it is not the goal of the story writer to create a 100% believable story
in all instances; it must merely respond believably to a player who acts in a believable manner.
As we saw from Doug Church’s Formal Abstract Design Tools, there is a balance between player intentionality and narrative. However, we can extend this through the social contract of “role-playing” (in the sense of actually playing a role, not crawling through dungeons) between the player and the designer.
Of course, in order for the player to accept this contract, they must be aware of the rules of the game, and they must agree to play by those rules. In this sense, the rules are an important component of the game, but the interactive story and game are also linked together in a way that makes the experience both game and story.
A way to merge games and stories. That is what many of us are looking for, is it not?
Aristotle, Campbell and McKee provide some of the most often-cited advice for storytellers in general, so it is natural that we apply their advice to games. For those of you who are primarily interested in this aspect of games, I would highly recommend reading their books on your own time (after this course is complete, of course). You can find them here: Aristotle, Campbell, McKee. I provide these links for convenience only; they are not required for this course.
In games, identification between the player and their characters, avatars, tokens and so on is a common way to get players to be emotionally engaged with the game. As you are designing a game, think about this and how else you can get emotional investment from players.
Remember that there is a difference between the embedded narrative that the story writer creates, and the emergent narrative that arises from gameplay. Think about which is more important in each game that you make, and how you can make it stronger.
Last time, we learned some basic linear storytelling principles, as told to us by people that worked with books, plays, and movies. And this is fine and good for games that have a linear story. Many video games work this way, where the story is essentially told as a movie broken up into small parts, and the player has to complete each section of the game to see the next bit of movie. I do not mean this in any kind of derogative way; many popular games work like this, and many players find these games quite compelling. Even personally, I have had times when I would be messing about in the subscreens optimizing my adventuring party, only to have my wife call from acros the room: “stop doing that and go fight the next boss so you can advance the plot, already!”
However, not all games are like this. As we’ve seen, player decisions are the core of what makes a game. Some games have a strong narrative intertwined with gameplay. For these games, it would make sense for player decisions to not only affect the mechanical outcome of the game, but to affect the narrative as well.
For some game designers, a true “interactive story” is something of the Holy Grail of games. In reality, we often fall short of giving the player the feeling that they are actually the starring role in a compelling story of their own creation. How have we told interactive stories in the past, and how can we make better ones in the future? It’s largely an unsolved problem, but we can at least cover the basics of what is already known, and that is our focus today.
Note that most board games do not have strong embedded narrative, so this entire discussion is mostly relevant to video game narrative, as well as tabletop RPGs. However, some modern board games are in fact attempting to combine the tabletop board game experience with that of the RPG, including story elements that the players must interact with as part of the gameplay.
I will be at SIGGRAPH all next week. While I will make every effort to post on time, I may not be able to respond quickly to email and I may be slow in validating blog comments or new forum accounts, so please be patient. Naturally, if you are attending there yourself, feel free to say hello in person – I’ ll be speaking on Monday morning about the results of the Global Game Jam.
Read the following:
* A Point of View, by Noah Falstein. We talk of the point of view of a story as “first person” or “third person” – and we also talk of the point of view of a video game in similar terms (First Person shooter, Third Person stealth, etc.). It is easy to assume that the two are equivalent, but they are not. This article makes the differences clear.
* Diversity in Game Narrative, by Chris Bateman. This is a brief overview of the different kinds of story structures encountered in games.
* Challenges for Game Designers, Chapter 13 (Designing a Game to Tell a Story). This short chapter covers today’s topic and can also serve as a review of some topics from last time.
Kinds of Stories
We can roughly classify different stories by their overall structure. The structure is determined by what kinds of choices are available to the player, how open or constrained those choices are, and what effect those choices have on both the ongoing story and the final ending. Each structure has its advantages and disadvantages, which we will discuss below.
Linear stories are the traditional narrative, with some gameplay elements thrown in that do not affect the story. In this case, the story and gameplay must be separate entities, because the story has no choices and the gameplay must include decision-making of some kind (else it is just a story and not a game). They can be thematically linked, and the story may influence gameplay (perhaps when a certain pre-scripted story element happens, it causes a new gameplay effect to come into play), but the gameplay cannot influence the story because there is only one story.
Linear stories have one major advantage over all other story structures: it is easy to apply traditional storytelling techniques, which have been developed over thousands of years. Such a story can have a powerful emotional impact – witness that we still talk of Floyd’s death in Planetfall and Aerith’s death in Final Fantasy 7 as key moments in the history of game narrative… even though neither events was under player control.
Linear stories have the obvious disadvantage that, due to a lack of decisions, they are not very game-like. As stated above, there is a natural barrier between linear stories and game mechanics, which limits the effect the story can have.
The first and most obvious thing to do to a linear story, f we want to add decisions, is to add choice points at various places. When the player reaches a certain point, they decide what to do, and then the story goes down one of several continuing paths until another choice point is reached. An example is the old-school Phantasy Star III for Sega Genesis; twice in the game, the main character is given a choice of which of two girls to marry (and then the storycontinues to the next generation of characters), leading to a total of four branches, each with its own story and its own ending.
Branching stories have the advantage of being interactive. If you include a sufficiently large number of choices and your choices cover all of the things that a player would want to do, the game can respond believably to any number of player decisions. At first, this would appear to be the ultimate solution to game narrative since it can handle just about anything.
However, there is one major drawback of using a branching story: it is expensive! With only two choices (which is not very many), the story writers of Phantasy Star III still needed to write four stories. A third choice would have had them writing eight stories, and including a mere ten choices would require writing 1024 stories! Consider the number of decisions you make as a player in a typical strategy game, and you’ll see that the amount of work to write a branching story can quickly explode into something unmanageable.
To make things worse, note that a player that goes through the game once will never even see the vast majority of content. It requires multiple replays just to see every path through the story… and even then, the player must decide which is the “real” story and which are the alternate timelines that didn’t actually happen. (If the developers ever make a sequel to the game, they must deal with this problem as well.)
This is Bateman’s word for a branching story that collapses in on itself, allowing the player to make choices but then collapsing all of them eventually into several mandatory events. In Silent Hill, for example, there are several choices the player can make that may advance the story or reveal some additional story elements along the way, and these will influence the ending. However, there are certain events that the player is forced to encounter no matter what else they have or haven’t done.
Parallel paths solve the problem of branching narrative by keeping the advantage of player decisions while still keeping the total amount of story manageable. So, at first, this would appear to be the ultimate story structure.
As you might guess, there is still a problem: since the player is forced into certain events, the entire plot arc is now essentially linear again. We have lost the player’s feeling that they are directing the story, because no matter what they do there will be certain parts of the story that are the same no matter what.
One potential solution is to have the player decisions alter the game’s ending. The player may still encounter the same plot arc, but the final outcome is determined by the choices the player made. Unfortunately, that means the relationship between cause and effect can be easily lost – the player’s decisions are (by definition) not seen until the very end, and it is often unclear what the player did to cause a certain ending.
And, we still have the problem that the player must replay through the entire game multiple times just to see all the endings.
This is Bateman’s term to describe stories that are divided into small pieces, perhaps with several plot arcs going on at once that may or may not intersect. The player then chooses which paths to follow and in what order. One example of this is World of Warcraft, where the player can accept any of several quests to advance different elements of the story. Another example are the Elder Scrolls series of games (like Morrowind and Oblivion), where the player may follow certain storylines based on how they want to advance their character, and the player may find other quests or subplots that they choose to pursue (or not) along the way, and these subplots may or may not have their own effects on the main plot line.
The advantage of a threaded narrative is that it is extremely expressive. You can have multiple storylines happening concurrently, as with nonlinear films like Pulp Fiction or Love, Actually (except, unlike those movies, have the plot lines advance according to player intent).
Also, the story may have multiple beginnings and middles and endings, but the player has access to all of them and can advance any combination of them in any order, so we have finally solved the problem of forced replays. The player can see everything there is to see with a single play-through, if they are thorough enough.
As you might guess, there is still a problem here. First, since some events may affect others, testing out all possible paths through the story can get even more complicated than with a branching narrative. (For programming geeks, a branching story with two choices per choice point is O(N^2), while a threaded narrative is potentially O(N!). Yes, factorial.)
Writing a threaded narrative is hard, because events can happen in any order, leading to the potential for the player to do things in an order that doesn’t make sense (for example, perhaps they are given a quest to assassinate a rival leader in the middle of a war, before the war actually breaks out, or after the war is concluded). The story writer must be careful to allow access to certain story events only when it would make sense to do so. Keeping track of all the variables that determine when a story event is or isn’t active can get very complicated very quickly.
Lastly, a threaded narrative runs the risk of confusing the player, if there are too many concurrent plots happening at a single time and the player does not immediately see the relationships between them. This is also a danger with books and movies that try to tell several stories at once.
Dynamic Object-Oriented Narrative
This last structure is Bateman’s term that, as far as I can tell, he invented to describe the game Fa?ade (which you should absolutely download and play if you have not yet seen it). The idea is that there are several mini-stories, each with potentially several entry points and exit points. A single mini-story’ s exit point may lead to a final ending, or to another mini-story. The mini-stories may be thought of as “chapters” in a book or “acts” in a play (except that you may not “read” all of the chapters or may read them in a different order, depending on the choices you make and how you exit each chapter).
This kind of story has the advantages of parallel paths, but without a linear story arc. Each mini-story has its own choices, and the overall collection of mini-stories itself acts like a larger branching or parallel path story. Each individual mini-story is self-contained, which reduces the required time to write the complete story.
This kind of story has two disadvantages. The first is that there’s still the forced-replay problem: a player must play many times to see all of the story paths (which is perhaps why Fa?ade needs to last about ten or twenty minutes, and not ten or twenty hours). It is also a highly experimental structure, so we do not yet have enough games to really analyze what does and doesn’t work in this form. Fa?ade itself took a couple of guys with PhDs in Computer Science to develop, so this is not the kind of story structure that is easily accessible to a traditional story writer.
Points of View
The camera in video games is generally either first-person or third-person.
A first-person view means the camera is, essentially, glued to the main character’s forehead looking forward. The player sees what the character sees. This can lead to a greater sense of connection with the main character, because the player is inside the character’s head, so to speak. The disadvantage is that this is not truly a first-person view, because a typical human’s peripheral vision is wider than the screen (and a typical human can turn their head faster than a typical first-person video game camera), which can break immersion at times for players who are not used to the limitations.
In a third-person camera view, the player is instead looking at the main character, usually from a behind-the-shoulder perspective so that you usually see the character’s backside. This gives a wider view of the area and is more realistic in terms of giving the player the visual information that the character would have. Of course, by looking at the main character all the time, it brings a sense of otherness – you can’t look at your own backside without the aid of mirrors, so this camera view is a reminder that the main character is not you.
Combining this with McCloud’s point on icons versus realism (from last time), we might guess that a first-person character is closer to an icon and tends to do better as a “blank slate” character that the player can project their own personality onto, while a third-person character that is drawn realistically should have strong characterization.
A second-person camera view, if it existed, would involve the camera that spends the entire time looking at the main character from the front. Needless to say, this would be confusing in the vast majority of games. The closest I’ve seen is an obscure console title, Robot Alchemic Drive, where you control a human character (in third person) that is in turn controlling a giant robot by remote control (in second person). To the extent that the robot is the main character, this game uses a second-person camera for control.
We also use the words “first person” and “third person” when discussing literature. There, it works a bit differently.
A first-person story is when the story is told from the narrator’s own point of view. The main character is addressing the reader directly, telling you a story of what happened to them.
A third-person story, which is more common, is when the story is told from an outside perspective (much like a typical movie camera, where the view just represents a “fly on the wall” and not an actual character’s viewpoint). This may be “third-person omniscient” where the reader can see things that happen and even hear several characters’ thoughts, or “third-person limited” where some information (such as character thoughts) is concealed from the reader.
A rare kind of story in literature is that of second-person, where the story is told from the reader’s point of view. This kind of story is rare because it is very hard to write in a way that is believable.
You might be realizing about this time that almost every game narrative is told in second person. This is the case whenever the player is controlling the main character, which is most of the time.
And this is another reason why storytelling in games is so hard.
Sometimes, the overall plot arc of the game is fixed and linear, but there are a number of characters (specifically, “non-player characters,” referred to as NPCs) that the player can interact with. In video games, where interpersonal relationships must be quantified, there are two common ways to treat NPCs and their relations with the player.
A “flag” in this context is just a binary (yes-or-no) value. An action did or did not happen. The player did or did not talk to a certain NPC, and if they did, they either did or did not choose a particular conversation path. As a result, certain new NPCs or conversation options may appear or disappear.
The advantage of flags is that it is very simple to do. Everything either happens or it doesn’t, making the logic that drives the characters pretty easy to follow. It’s also easy to implement in code; programmers can do binary logic easily.
The disadvantage is that there is not a lot of depth to these characters, if there is only black and white and no shades of gray in between. You can add more complexity by combining binary values (“only make Aragorn appear if Frodo chose to travel to the Prancing Pony and he successfully avoided capture by the Ringwraith and he puts on the Ring”) but at this point it can get complex to follow, reducing the benefit of simplicity mentioned earlier.
Instead of a yes/no dichotomy, use numeric values to measure things like how strongly a character feels affection or hatred towards another character. If you have to decide whether an NPC behaves in a certain way, check to see if its affinity value is past a certain threshold value. (In tabletop RPGs, it is common to also add a die-roll to the mix, so that things may or may not happen based partly on chance.)
The advantage of an affinity system is that it is still fairly simple, it can handle more complexity than a flag system, and it is much more expressive.
However, you must be careful with affinity systems. There is a danger of having a very muddy system (where the player can’t tell why a character behaved in a certain way), especially if several affinity variables or a random die-roll are included in determining the outcome. In short, it is hard to get this kind of system to “feel right” without a lot of playtesting.
Some games include a conversation system, where the player is given a choice of things to say, and then the NPC they’re talking to responds.
Conversation systems can be thought of in the same way as game narrative systems. A conversation can be:
* Linear. I walk up to an NPC and choose the “Talk” command. They tell me something. That is all.
* Branching. I initiate a conversation. The NPC says something, and I am then given a choice of responses. Based on my response, the NPC may say something else and then give me a brand new set of responses.
* Parallel. I initiate a conversation. The NPC says something, and I am given a choice of responses, then they respond, and so on. There are several combinations of responses that can get me to the same outcomes, however.
* Threaded. I initiate a conversation, and am given a set of different ways to begin. The NPC responds to what I say, and each action I take within the conversation may open up new paths of conversation and close older, no-longer relevant conversation threads.
* Dynamic. I go through a branching or parallel conversation. Depending on the outcome, I proceed to a new conversation (or a new area of exploration within the current conversation).Writing dialogue in each of these methods is proportional in difficulty to writing a story of each form.
Writing Good Characters
Some characters in stories are “round” – they have many facets to them, a deep character with many layers, and are highly detailed and developed over the course of the story.
Other characters are “flat” (or “shallow”) – they are very simple, don’t have a very deep personality (at least, not that the audience can see), and do not develop or change much (if at all).
Normally if we say a character is “flat” it sounds a bit derogatory. Are flat characters always bad in stories? I don’t think so; not all characters need to be complicated, deep, or well-defined. Even in Shakespearean plays, some minor characters are flat (I’m looking at you, Rosencrantz and Guildenstern), but the main protagonist and villain at least should be round.
A rule of thumb is that a character should develop over time as we seen them through the story. As a corollary, minor characters with very little “screen time” can be flat since they don’t have much time to develop anyway; the characters who we see the most often (generally the main characters) should develop a great deal. A flat protagonist is probably not a good idea if you are trying to make a strong character.
Archetypes versus Stereotypes
Here’s a question I was once asked in a job interview: describe the terms “archetype” and “stereotype” and the difference between them.
McKee says that story is about forms, not formulas. Archetypes are forms; stereotypes are formulas.
“Villain” is an archetype. The Snidely Whiplash-esque, mustache-twirling, top-hat-and-black-cape-wearing, purely-mean-for-its-own-sake bad guy is a stereotype.
Archetypes are useful. They allow us to tell a story with believable characters that fit familiar forms. Stereotypes are overused, and typically make a story less believable because the audience has seen these same characters before from other stories, so they do not seem unique. Generally, avoid stereotypes, unless there is very good reason (such as if your story is a parody that is making fun of a particular character stereotype).
You might have seen this before in a grade school literature class. The idea is that stories start with a small amount of exposition to set the tone, then they have rising action where things get more intense, then they reach some kind of climax (a final battle or confrontation, etc.), then there is falling action and resolution at the end as the story reaches its conclusion.
Note that this is not just true for story, but for gameplay as well. Games have exposition (we call it the “opening cinematic” and “tutorial level”), rising action (most of the game), climax (final boss fight), falling action (occasionally some post-fight sequence like a timed escape from the building before it blows up), and resolution (end cinematic).
You get a more dramatic experience if the dramatic arcs of story and gameplay are aligned and in synch with each other. This is a lot harder than it first appears; in many games, the most difficult part of gameplay occurs somewhere in the middle of the game, when the enemies and challenges are getting harder but you haven’t yet found new weapons and abilities to power yourself up to compensate. As the player gets more powerful and better at playing, the challenge of a game often decreases over time, even as the intensity of the story is increasing. You can tell these games when the final boss fight is introduced with this high amount of drama and foreboding, and then the player wins after swinging their sword around for a few seconds – it feels anticlimactic and not very believable.
In short, as you balance your game, pay attention to the story and whether the story drama is proportional to the dramatic moments in gameplay.
It’s Still a Game
Remember that, as a game designer, you are still making a game and not a story. In most cases, the story should not preclude gameplay. At the very least, you should be extremely careful when you are tempted to make a concession in gameplay for the sake of the story, or when you plan to overload the player with non-interactive story bits.
When writing the narrative for a game, return frequently to your core aesthetic – your overall vision of the optimal experience your game will offer – and make sure that the story supports it!
There are lots of ways to take a traditional linear story and make it more interactive. All of these have advantages and drawbacks. If the Holy Grail of a full interactive story is even achievable, we have still not discovered how.
But we should keep trying, and exploring the various non-linear story forms that are uniquely suited to games.
You made a game on the first day of this course. It took you all of 15 minutes. It probably wasn’t very good. At this point, with your current understanding of flow states, feedback loops and kinds of decisions, you can probably isolate the reasons why it wasn’t very good.
You made a few other games after that one. You might be proud of some of them, and embarrassed of others. Looking back, you might find one that you were proud of that you now realize could have been better. Or maybe not.
At any rate, you know how to make games.
So, let’s make a good game. You have all the knowledge and theory you need.
We will spend the next month making a game. If you’re a student, that may sound like an incredibly long time to you, and you will be surprised at how fast it flies by. If you’re a little more experienced, it may sound like an unreasonably short time, but I promise you will manage. Do not fear; we will take things one step at a time, through the entire process. You will not have to complete everything all at once. (Nor should you. That is not how games are made.)
Read the following:
Challenges for Game Designers, Chapter 11 (Targeting a Market). We have discussed the importance designing for the player (as opposed to the designer) earlier in this course. This chapter goes into more detail, giving some considerations when designing a game for target-demographic or mass-market appeal.
Design Project: an Overview
In my classroom courses, I call this a portfolio project – a game that will ultimately go into the student’s game design portfolio as a way of showing their skill at game design. You may consider doing this as well, depending on your situation and your career goals.
The purpose of the Design Project is to gain some experience in taking a game through the entire process from concept to completion. Because of this, do not simply start with an existing design (such as an earlier game you created in this course, or an idea you’ve had floating around in your head for awhile). You have plenty of time – the entire rest of your life! – to take your existing projects further. For now, get some practice at all of the stages of designing a game.
As you might guess from the syllabus, the process we will follow is going to go something like this:
First, generate some core ideas for games. These do not have to be fleshed out in any meaningful way, they are just “seeds” that can serve as starting points. You will choose one to serve as the basis for your Design Project.
Next, you will create the core mechanics of the game. The game does not yet have to be complete with all details fleshed out, but it does have to be at the point where you can start playing it with yourself (even if you have to make up a lot of the rules as you go along). You’ll play your own game in private, working on it until the point where you have a complete set of rules.
After that you will bring in some close friends, family, confidantes, or other participants of this course. Share your project with them, play the game with them, and get feedback. The key here is to figure out if the core of the game is fun at all (if it is not, you can start over with one of your other ideas or else modify your current one and try again). If it doesn’t start out feeling like there is some magical fun quality to the play, that feeling is unlikely to materialize later – it is far better to abandon an idea early and try again than to waste a large amount of time on something that is just not going to work. Ideas are cheap, implementation is expensive; act accordingly.
When you have the core of the game working and it is meeting its design goals, it will be time to get into the details. Make sure the game can be played to completion, without the designer being present to answer questions or make on-the-fly rulings. Get to the point where the game has a complete set of rules, with no dead-ends or holes that cause the game to stop when the players can’t figure out what happens next. You’ll playtest with new players who have not seen the game before, and observe them from a distance to see what they do.
Once you are confident that your game is solid, you’ll explore “blindtesting” – a playtest where you are not present at all. You’ll give your game to some other people who will agree to test it and provide feedback. This most closely simulates actual market conditions, where a person buying a game does not have direct contact with the game’s designer, and they must figure out how to play it for themselves.
After all of the details are complete in your game, it is time to tweak the small things. Make sure the game is balanced – that is, that there are no strategy exploits that are too powerful, and that all players feel like they have a reasonable chance of success.
Lastly, as the game nears completion and the mechanics become solidified, you’ll consider the “user interface” of your game – the visual design of the physical components that will make the game as pleasant, easy to learn and easy to play as possible.
Once everything is set, you’ll spend a short amount oftime on the craft of the physical components, making the artwork and assembling the components in their final form.
Keep in mind that game design is an iterative process, and that at any point in the process you may find a reason to return to earlier steps to redo something. This is fine, and it is to be expected. This is also the reason why it is better to kill an idea early than to abandon it late. If you find that you have to start over from scratch, you’ll have more time remaiing if you start over in the first week (as opposed to restarting the project in the last week).
Recall from Level 4 that there are many ways to start conceiving of ideas. Start with core aesthetics, or a core mechanic. Start with materials from other sources. Start with a narrative. And so on.
Today, start generating some ideas. Look in the world around you. What systems do you see that would make great games? Carry a notebook with you wherever you go in the next few days, and write down every idea that occurs to you, no matter how silly it may seem.
The more you generate ideas, the easier it gets.
Design Project Constraints
I could leave this entire project open-ended, but in order to get you started I’m going to give you some constraints. Remember, constraints are your friends.
If you’ve never designed a complete game before this course, follow this set of constraints. Create a board game, card game, or tile-laying game (that is, it must either have a board, cards, or tiles as physical components). It may have more than one of these components, and it may involve additional components beyond these (such as dice or pawns). You may choose any theme you want, as long as it is original – do not use an existing IP (intellectual property). In short, if your work would violate someone else’s trademark or copyright, don’t do it. You will undoubtedly work with other people’s IP at various points in your own career; take the opportunity now to do something original with your own IP.
I’m going to place two more restrictions to help you. First, you may not make a trivia game, or any other game that relies on large amounts of content (such as Trivial Pursuit, Pictionary, Apples to Apples, or Cranium). This is purely for the purpose of keeping your scope limited; if you have to generate 250 cards with unique trivia questions on them, it will leave you far less time for playtesting the game mechanics. I would put Trading Card Games (like Magic: the Gathering and Pokemon TCG) in this category as well, since it requires so much time to create a large number of cards.
Second, you may not use “roll-and-move” mechanics in any form. Do not throw dice and then move a pawn around the track. Do not use a spinner or a teetotum or card draws or any other random-number-generating device to determine what a player does on their turn. There are several reasons for this prohibition. First, the mechanic is highly overused, and it is practically impossible for you to make a game that will not feel like a clone of Monopoly, Trouble, Sorry!,
Chutes & Ladders, or any of the other myriad games that rely on this as their core mechanic. Second, the mechanic essentially makes the key decision each turn for the player, so the game is making interesting decisions but the player is not. By divorcing player intentionality from the game’s outcome, you usually end up with a game that is not particularly fun to play (no matter how fun it is to design).
If you have designed one or more complete games before but still do not feel like you are a strong game designer, follow this set of constraints. Follow all of the Green Circle constraints above. In addition, add one of the following constraints. This is your choice, based entirely on your area of interest within game design:
Design your game such that it has a strong embedded narrative that is interactive in some way. You will have to think of ways to tell a story through the player actions of a board game, and how to integrate narrative and game mechanics. If you are interested primarily in RPGs or other forms of storytelling, do this.Create a purely cooperative board game for two or more players, so that everyone wins or loses as a team. This is challenging for several reasons. The game must provide systems that are the opposition, since the players do not provide opposition to each other. Cooperative games generally have a problem where a single skilled player can direct all of the other players (since everyone is cooperating, after all), leading to an MDA Aesthetic where most of the players are bored because they are just being told what to do by another player. If you are interested in the social dynamics of games, choose this.
Make a two-player head-to-head game with asymmetry: the players start with unequal resources, positions, capabilities, and so on… and yet they are balanced even though they are quite different. These games are not so hard to design the core rules for, but they are very difficult to balance. If you are interested in the technical and mathematical side of game design and game balance, try this.
Create a game to teach any topic that is normally taught at the high school (pre-college) level. It is up to you whether to teach a narrow, specific fact or a broad concept. The challenge here, of course, is to start with a fun game and not have the focus on education get in the way of that. If you’re interested in “serious games” (games that have a purpose other than pure entertainment), then do this project.
If you have designed multiple games professionally and you consider yourself highly experienced, follow this set of constraints. Ignore everything above. You must create a board game that uses a “roll-and-move” mechanic as the primary gameplay activity. But make it good.
This mechanic is highly overused in games. It also creates a separation between the player’s decisions and the actions that the player takes on the board. It is therefore extremely challenging to design a game that uses this mechanic in a way that feels fresh, original, and compelling. But I’m sure if you have reached this point in your career, you are up to the challenge.
What If I Don’t Want To Make a Board Game?
Some of you expressed a strong interest in board games and are excited to get started. Don’t let me keep you. Realize that you are in the lucky minority.
Some of you are still more interested in making video games. I’ll remind you that the vast majority of your time making a video game will be spent creating art assets and writing programming code, and if you want to learn game design then you should choose an activity where the bulk of your time is spent designing the game. The principles and concepts of game design are mostly the same, whether you work in cardboard or code, so if you’ve got the skills to design video games you should be able to use those same skills to make a board game.
Some of you expressed interest in creating tabletop role-playing games. I’ll remind you that evaluating the design of an RPG is tricky, since a sufficiently skilled GM and players can salvage a weak system (or, sufficiently inexperienced players can ruin a perfectly good system). This will make playtesting far more difficult to evaluate, so you will find it useful to practice on a board game project first. Note that the line between board game and RPG has blurred in the past few years, given narrative-heavy board games like Android and mechanics-heavy RPGs like D&D 4th Edition.
Some of you might have additional real-world constraints. You might be on a budget, and so you can’t spend more than a certain amount of money on your prototype. You might live in a remote location where prototyping materials are scarce, and you’ll have to make do with what you have. You might have less time than usual to devote to your project, in which case you’ll need to design a game that has a short play time (so that you can playtest and iterate more
frequently in less time). If you have constraints from your life that affect this project, consider those to be part of the project. A designer should not complain that they lack the resources to make the game they want; rather, they should find a way to make the best game possible with the resources they have.
I ask three things of you:
Start generating ideas for your Design Project now, based on the constraints above. As I mentioned earlier, keep them in a notebook or some other place where they will not get lost, and that you keep with you constantly so that you can write down your ideas as you think of them.
By Wednesday, August 5, noon GMT: look over your ideas and post your three favorites on the forum. Note that this is a day earlier than usual, in order to give time for feedback.
By Thursday, August 6, noon GMT: read the posts of two other people at your same skill level, and provide constructive comments on their ideas. If you posted in Blue Square or Black Diamond, also critique three others at a skill level below yours. If you see posts with no responses, reply to those first, so that everyone can have at least some feedback.
You may also use Twitter (with the #GDCU tag) to ask for immediate feedback of ideas as they occur to you.
At this point you have some ideas, and you have some feedback. As with many things in life and in game design, you could sit here forever contemplating which is the best choice… but at some point you’ll need to start working towards your goal. Choose a direction and go with it, even if it might not be the best one. Trust that you will be able to use the iterative process to fix any mistakes you make along the way.
Today I’d like to cover the general concept of playtesting. As we will see, there are many different kinds of playtesting, and it is important to be able to differentiate between them in order to get maximum value from our time.
There are no readings for today, other than this blog post. Take the time that you would have spend reading, and use it to work on your Design Project.
Different Kinds of Playtesting
The word “playtesting,” like the word “game,” is overused and can mean different things to different people. In general, the term covers any activity where you are playing a game in progress for the purpose of improving it. But different playtests may have different goals, and it is important to know what your goals are before you do anything.
I’ll be playing a bit fast and loose with terminology here, so in this case the concepts are more important than the labels I’m giving them.
Bug Testing (or Quality Assurance)
The purpose of QA is to find errors in the game’s behavior relative to its design. “Fun” does not enter the equation. If the designer says that the game should do one thing and it actually does another (even if what the game is doing may be superior), that is a bug that needs to be identified.
Normally, we think of bug testing as specific to video games. Board games do have a corresponding kind of testing, where the purpose is to find holes in the rules and dead ends in gameplay – gaps in the game that the designer did not cover.
In a focus test, you bring together players that are part of the target audience’s demographic in order to determine how well a game serves their needs. This is normally done for marketing purposes, but if game designers are involved it can also help to make the game more enjoyable for that particular demographic.
In a usability test, players are given specific tasks to accomplish in an attempt to see whether they understand how to control the game. This is done frequently in the greater software industry to make sure that a piece of software is easy to learn and easy to use. Video games can take advantage of this as well, and results from a usability test can be used to either change the controls or modify the early levels to teach those controls more effectively.
In board games, usability is doubly important, because there is no computer to respond to player input for you. If you misunderstand how houses work in Monopoly and place them on Community Chest spaces, the game will not stop you. By observing players who are trying to play your game, you can learn a lot about how to design the various game bits so that they are easy and intuitive to use.
A fun game can quickly become boring if some kind of play exploit exists that lets a player bypass most of the interesting choices in the game. If only one strategy can win and it is just a matter of which player follows that strategy the best, it is not as interesting as if there are multiple paths to victory. Likewise, if one player has a clear advantage over the others, it is important to identify that so that players do not feel the game is being unfair. The purpose of this kind of test is to identify imbalances in the game so that the designer can fix them.
A game can be usable, balanced and functional and still be uninteresting. That elusive “fun factor” may be hard to design intentionally, but when people are playing the game it is pretty obvious whether they are having fun or not. Certain aspects of the game may be more fun than others, so it is also important to figure out what parts of the game need to stay the same… not just what to change.
All of these forms of testing have some elements in common. Best practices are similar if not identical. All are important to the success of a project. So why make a distinction?
The reason is that each is appropriate at different stages of completion in a project. Each kind of testing has different goals, and you need to know what your goal is before you can achieve it.
Order of Effects
When should you do which kind of playtesting? What order do you do them in? A lot depends on your particular project, so some of this will be up to your judgment as the designer. However, there are some rules of thumb.
Very early on in the project, you need to make sure your project will meet its design goals (usually the “design goal” is to make a game that’s fun to play). Testing for fun is necessary to make sure you do not spend a lot of time building on the wrong foundation. If you are making a game for a specific market, focus testing may be involved at an early stage as well, simply to ask the target audience if a game with a particular concept sounds interesting to them at all.
Once you know that you have something, you need to solidify the mechanics. Design the whole game, making sure that all the details are taken care of. Test for “bugs.” (Note that bug testing in software projects is often done continually throughout the project, increasing in intensity toward the end. Non- digital games are easier to “debug” though, and a “bug” can stop a playtest in its tracks, so it is important for us to have a complete set of rules early in the process.)
Once the game is fun and the design is complete, gradually shift from testing for fun to testing for game balance. Make sure that all the numeric values and player abilities are where you want them to be.
When the game is working and balanced, towards the end, you’ll want to think more about the usability of the game. When you change usability you are not changing any mechanics, merely the way those mechanics are presented visually to the players. This is an important step that is often neglected. If you’ve ever encountered a game that you could only learn by being taught by another player (as opposed to reading the rules yourself), that is the kind of usability failure you want to avoid in your own projects. You may also do additional focus testing at this time, to make sure that the theme and visual elements of the game appeal to the target audience.
As I said, these are just guidelines. If it is incredibly important that your game be well received by a particular demographic, for example, you may be doing focus testing throughout the project at all stages. Do not let this order of things be your master.
Different Kinds of Playtesters
As there are different kinds of testing, there are also different kinds of testers. Each kind of tester has their own strengths and weaknesses, and some are more important for some kinds of testing than others.
Yourself. You are your own most valuable playtester. Do not forget your ability to play your game on your own. You know your game better than anyone.
Other game designers. If you are lucky enough to personally know some other skilled game designers, you can get some very useful testing done through them. They are able to critically analyze your game and propose design solutions. (If you do not know any professional designers, perhaps you can at least make contact with other participants of this course.)
Close friends, family, and confidantes. People close to you who are willing to provide their time to test your game are very useful. They are approachable and can make themselves available as a favor to you. Take good care of them, and do not abuse their kindness. Note that these people may not fall into any of the other categories, so while they are good for early tests, they may not be appropriate in more focused testing for bugs or balance since they may not know what to look for.
Experienced gamers. Skilled game players are great at finding exploits and dominant strategies in a game, and are appropriate for balance testing.
Complete strangers. People in your target audience are appropriate for focus testing and usability testing, and they are absolutely critical when testing for fun. Finding them can be tricky, though, because it is not in most of our natures to just walk up to someone we’ve never met and ask them to play a game. We will talk more about this in the coming weeks.
Order of Familiarity
In general, you will want to go through testers in order from more to less familiar. Test with yourself first, then with close friends, then with acquaintances that are useful (because they are designers, gamers, or part of the target market), and then with strangers.
If you show your work to other people too early, it will likely be in such a rough state with multiple design flaws and holes in the rules that it will waste their time and frustrate them, and you want to treat your playtesters better than that. Also, if you start playtesting with strangers too early in the process, you may not get useful feedback – if your game prototype is in a rough state with only crude art and components, for example, the playtesters may be so busy commenting on the poor quality of the pieces that they will not be able to concentrate on the gameplay.
At this point you might be tempted to just do all of the playtesting by yourself, so that you don’t need to rely on other people or keep track of them. In practice, the designer eventually gets too close to their own project and is so familiar with the game’s systems that they can miss some really obvious flaws. If you keep the same set of playtesters for long enough, they will suffer from this problem as well. You need to bring in fresh sets of eyes to look at your game on a continuing basis throughout the project.
Playing By Yourself
In the early part of playtesting, when you are playing the game on your own, here are some things you should be looking for:
Does the game meet your design goals?
Is it fun, at least for you? While you are not the ideal playtester to judge effectiveness most of the time, if you are not having fun then most other people will probably not either.
Are there any holes in the rules?
A “hole” is a situation where the rules simply do not say how to proceed. For example, perhaps one of your rules is that a player’s army can attack another player’s army, but you don’t yet have rules for resolving the attack. What happens in this case? In practice, what happens is that the players sit around and wait while the designer figures out what to do!
As an example, consider these rules for Tic-Tac-Toe played on a 4×4 grid:
Objective: Get a straight line of symbols.
Setup: Draw a 4×4 square grid.
Progression of play: On your turn, place your symbol (“X” or “O”) on an empty square.
Resolution: If either player on their turn has a set of four of their symbol in a straight line (across, down, or diagonally), they win.
If you try to play this game just following the rules, you’ll quickly realize that you can’t even start – nowhere does it say which player is X or O, or who takes the first turn! To fix this, you would add a situation to handle this. For example:
Setup: Draw a 4×4 square grid. Choose a player to go first, who is assigned the symbol “X”. The other player is given the symbol “O”.
Are there any dead ends?
A “dead end” is a game state where there is no way to proceed further, but the game is not resolved. Consider our revised 4×4 Tic-Tac-Toe rules above. Suppose that both players fill up all squares on the board without anyone winning. At this point the game cannot proceed, because the rules say a player must place their symbol on an empty square. There is no empty square, so the player cannot take a turn. But there is also no resolution, because neither player has won. In this case, a new rule would have to be added (such as: in the resolution, if neither player can make a legal move and no one has won, then the game ends in a tie).
Are any of the rules unclear?
It is natural for us to assume things that are in our head, to the point that we often forget to write them down in our rules. Try to look at your rules and see if there is anything you are assuming that your players might not.
Are there any really obvious rules exploits?
Is there a single strategy that wins the game easily? Try to find it. It’s much less embarrassing if you find and fix it yourself, as opposed to having it discovered by your playtesters (or worse, your players after you release the game). Clarity and exploits are often hard to find in your own game; you tried to design this game to not have any problems, after all. Still, make an honest effort, and sometimes you will be rewarded by finding and fixing errors early (which saves a lot of time in the long run, leaving you more time to iterate on other parts of your design).
You might think that looking for exploits is something to do later in the project when balancing the game. Sometimes it is. It is a matter of degree. If an exploit is so powerful and so obvious that it prevents your playtests from giving you real information about your game, fix it now.
Solo Test Difficulties
There are a few things that are hard to test alone:
Realtime multiplayer games, such as games where you must slap a card or say an answer faster than your opponent.
Hidden information games, where each player has information that only they know and that is important to keep secret from the opponent.
Trading, negotiation, and auction games, where each player must place a value on an item, and different players may value things differently (and especially when players can artificially extort high prices or drive up the cost of an item at auction just to make their opponent pay more).
For the latter two, it is possible to play anyway, by simply limiting your actions to what you think you would do if you were in each player’s situation, knowing only what they would reasonably know. Some people find this more difficult than others.
The simplest answer here is, for the purposes of this project, to not use mechanics that you can’t test yourself. The alternative is to bring in another player or two early on in this case only, after you take things as far as you can on your own.
Let It Grow
Experienced designers often talk of a game “making itself” – as if the game has a life of its own, and the designer is merely guiding it rather than creating it. On the surface, this seems strange because really, the game is just sitting there and doing nothing unless the designer is playing it or changing it. What’s going on here?
I think that what is really happening is that the creation of a game is a learning process. You may have some idea of where you want your game to end up, but the final version may be very different from what you originally envisioned. The reason why it changes is that at the beginning, you don’t know very much about your game. You have some basic ideas, but you don’t actually know how the mechanics will interact, or what the actual dynamics and aesthetics will be.
As you playtest, you learn more about how your game’s systems are working. As you learn, you become more able to predict the effects that changes will have on the system.
Right now, though, you don’t have that experience… at least not with this game. Playtesting on your own is your first act of discovery. As you discover, it may seem as though your game wants to grow in a new direction, as if it has a life of its own. If you feel that, go ahead and listen to your game. See where the process of discovery takes you.
As the designer, it is an important skill to be able to playtest your own creations (which you’ve already done at least once). It is also important to be able to set up conditions for other people to playtest your games, so that you can get useful information from the precious time you have (which we will cover over the next week).
There is another side to playtesting: the ability to playtest other people’s games and provide quality feedback. This is a skill in and of itself, and a surprisingly rare one to find. This scarcity makes it a valuable skill. Personally, I have received many freelance opportunities through colleagues, simply because they know that I am good at finding the flaws in their designs. This is what we cover today: the ability to critically analyze a fellow designer’s work-in-progress.
Read the following: “Giving Criticism – the good, the bad, and the ugly!”
This may not be a class on giving constructive criticism, but it is something I’m going to ask everyone to be doing. Far too often in classes, students are asked to give peer feedback and review, and yet not given the tools to do so in a useful way. I think many teachers either take the stance that simply giving feedback enough times will make people better at it (“practice makes perfect”) or else that feedback techniques should be taught in some other class (“I can’t waste precious class time on that”).
This article may not be particularly comprehensive, but it is short, and after doing a Google search for “constructive criticism” it is the one that I found that fits best with the advice I give in my classes.
The Time Barter System
At Protospiel, an annual gathering of non-digital game designers, participants are encouraged to give as much playtesting time as they take. For example, if your prototype takes two hours of play and discussion and it requires four players (other than yourself), a single playtest consumes eight person-hours of time; in exchange for that playtest, you are then expected to playtest other people’s prototypes for eight hours of your own time. This system prevents there from being an extreme shortage (or surplus) of testers relative to games, and it gives people incentive to respect each other’s time.
Notice that this means you tend to spend far more time playing other people’s games than you do playing your own. You could even say that, given the time difference, the ability to be a good playtester is more important than being able to design your own games.
Keep this in mind as you proceed through the rest of this course. You will be consuming large amounts of other people’s time as you iterate through your own designs. Accordingly, treat your testers with respect. (It wouldn’t be out of the question to give them food or some other compensation, as well, if it is in your means to provide.)
If you are in a group, playtesting with other designers should be relatively easy. Just meet up with your fellow designers. Keep in mind that you should be giving more of your time to other people’s games than your own.
Next Steps After Solo Testing
At this point in the project, you should have a playable prototype of your game, and a set of rules. You should have playtested on your own at least once, identified any really obvious problems, and iterated on your design. You should continue to do this until your design is at a point where you are confident that you can play all the way through without having to make major changes.
Once you reach that point, your goal shifts from “make this game work” to “make sure the core mechanics are fun” (or whatever your design goal happens to be, if not “fun”). Who would make the best playtesters to help with this?
Normal players (such as friends and family, or even complete strangers) are marginally useful here. By watching them, you can determine if they are having a good time and if your game is meeting its design goals. However, if there is a problem, a typical gamer will not be able to give you useful feedback other than “it’s great” or “it sucks.” It will be up to you as the designer to identify and fix the problems. Therefore, normal testers can be used if necessary, but their usefulness is limited.
Far better is to playtest with other game designers. Game designers can also let you know if the game is fun, and they can offer suggestions on where the problem points are and what can be changed to make your game better. You can often have wonderful discussion following the play of the game, on the design of your game and sometimes on game design in general. These kinds of discussions are important, and your game can get better much faster with them.
Finding Designer Playtesters
There are a few places to find other game designers.
If you are lucky enough to already work at a game company (or know someone who does), you probably already know some designers who you work with regularly. In this case, finding skilled testers is the easy part. The difficulty is that professional designers are often busy with work, and simply do not have the time to help you. You must work around their schedules. Also be prepared to offer something of value in exchange. You are essentially asking for a professional game design consult. Your colleague could spend the same amount of time freelancing and make anywhere from US$40 to $250 an hour, depending on their experience and the nature of the project. (I get those figures from personal experience and what I can piece together from what my colleagues say on the subject.) If you are asking for their time for free, be prepared to give a comparable amount of your own time to their projects in the future. At least be prepared to be extremely grateful.
What if you don’t know any professional designers? Perhaps you signed up for this course in a group with your friends. This is where that group of yours will come in handy. Get in touch with your friends, and arrange a time to meet in the near future for a playtest session. Play through each of your games.
If you took this course alone and don’t know anyone else, the next best thing is to check the forums. The bottom section of forums, “Local Communities,” was set up specifically so that you could find other people in your local area. If you are not yet registered on the forums (but you did sign up for the course ahead of time), do that now – just be sure to sign up with the same email address that you registered with for the course (or at least drop enough clues in your forum account info to let me figure it out on my own). Arrange through the forums to meet at a neutral location. Who knows, this may be the start of a long-term professional relationship.
If you’re having trouble finding others in your area on the forums, as a last resort, post your work on the course wiki and beg on the forums for playtesters. There may be other people in similar situations. Again, if others are willing to take a look at your work and provide feedback, return the favor and playtest their work. When playtesting another’s work in this way, be sure to give them instructions for assembling a playable prototype. The easiest way to playtest in this way is to solo test each others’ games. Another option is to arrange a meeting over the internet (using a chat tool such as IRC or
Skype) and attempt to play remotely in real time (some games are easier to do in this way than others).
Being a Great Designer
As other people playtest your game, keep in mind the following:
* Your game is not perfect. If your game were perfect, you wouldn’t need to playtest.
* There will be problems. The goal of playtesting is to find and eliminate those problems. If all your playtest did was confirm that your game is perfect, you have just wasted your own time and everyone else’s.
* It is far better to identify problems in a small playtest, than for them to be found after the game is printed and ships to millions of players.
* If one of your playtesters finds a major problem in your game, they have given you a great gift. Do not be hostile or defensive; be gracious.
* When a problem is identified by a playtester, your goal is not to verbally defend your game or to explain why the playtester is wrong. First, even if your playtester is “wrong,” it probably means a lot of other players will also be “wrong” in the same way, and you can’t ship yourself in a game box in order to explain your Grand Vision to everyone. Second, the playtester is probably right – they are seeing your game through fresh eyes, and are more likely to have an unbiased view of the game.
* If your playtesters do identify problems, the correct response is to write the issue down in your notebook… and then discuss your design goals with the playtesters so that you can get some ideas of how to preserve your goals while changing the game.
* Not all people are tactful. Sometimes people will say things about your game (or even about you, personally) that are downright hateful. Sometimes people will make fun of your game, or will taunt or berate you for a problem with your design. Keep in mind that, no matter how it is delivered, this is still extremely useful content.
* It takes a strong person to hear a statement like “your game sucks, it is the worst game I’ve ever played, and by extension you suck and you are nothing better than a waste of space” and to genuinely reply: “You have just helped me identify some major flaws in my game. Thank you.” Getting to the point in your life where you are emotionally strong enough to have an exchange like this should be one of your long-term goals as a game designer. You do not have to
be like this right now. I’m not. But I have seen an exchange like this before from a great designer, and it made me realize how far I have to go.
* If it sounds like I’m repeating myself here, it’s because I’ve seen this go horribly wrong so many times, that I think it is worth repeating.Running a Great Playtest SessionIf you want your playtesters to keep coming back for your future designs, be as respectful of their time as possible. Here are some things to consider:
* Before you show your game to other players, make sure the rules are fresh in your mind so that you do not need to look them up. Try explaining all of the rules to yourself in the mirror to make sure you can do it. This will save time, if it only takes you a couple minutes to explain rather than half an hour.
* If you already know there are problems (and you just don’t have the solutions) or if you have specific design goals other than “make a fun game,” let your playtesters know this up front. It will help them to be more aware of potential solutions.
* End your playtest as soon as you can. If you have received as much useful information as you are likely to after a half hour of play, stop there (even if the full game would last three hours). Remember that the purpose of the playtest is to identify problems, not to “play games.” If you’re not identifying problems, you are wasting everyone’s time.
* Bring your playtest notebook and take good notes. You will forget everything that takes place, no matter how obvious your playtest results seem at the time, so make sure you write down every piece of information that you don’t want to lose.
Being a Great Playtester
Here are some of the things you should keep in mind when testing other people’s games:
* When testing, give the designer and the game your undivided attention. You would want others to extend the same courtesy to your game, after all.
* Don’t leave in the middle of a test. Aside from being rude, it can throw off the results (not all games can gracefully handle it when a player leaves). At minimum, if you know you have limited time or that you may get called away in mid-game, let others know this up front so they can handle it accordingly.
* Be as detailed as possible. Don’t just say that the game is “fun” or “boring,” try to analyze why. You should have enough of a background at this point to give meaningful feedback. Make use of your design skills!
* Allow some time after the game for discussion with the other testers and the designer. Talk about your play experience, and how it was related to the mechanics.
* Remember that there are many possible playtest goals. Are you playing to see if the game is fun? Are you playing to win? Are you playing to find holes in the rules? Play accordingly. We are so used to playing games in our own personal style, that it can be difficult to remember that there are other ways to play. Keep the goals of the playtest in mind.
* Be polite. Attack the game mercilessly, but do not attack the designer.
Continue working on your game from last time. If your game is not already at the point where it is ready for playtesting with other designers, continue testing on your own until you are at that point.
You have two additional tasks.
First, before Thursday, August 13, noon GMT, arrange a playtest session with other designers. The session itself should take place on or before next Monday (August 20).
Second, playtest other people’s games. Keep track of the number of person-hours spent in the playtest of your own game (not including yourself), and give at least that many hours of your own time towards helping your fellow participants.
Do you know of any great articles on giving constructive criticism, or playtesting games as a designer? Post them in the comments on this blog, or on Twitter with the #GDCU tag.