|
直到此刻，我们之前一直单纯从游戏理论的观点来讨论游戏。也就是，我们将游戏视为规则系统，含蓄地假设规则就是游戏，叙事之类的元素只是装饰而已。 但是，这种想法并非完全正确。正如我们在讨论决定类别时提到的那样，有些玩家选择可能根本在游戏系统中毫无意义，但是它们仍然是有意义的选择，因为这些选择充满了个人 情感。 玩过桌面角色扮演游戏的人可能更容易意识到这一点。想象那些你曾经历过的有趣游戏过程。你可能想不起某次造成角色死亡的投掷，或者某个玩家在战斗中做出的有趣战略决策 。你能够回想起的是某些充满戏剧性和充满情感的时刻。你铭记在心的是故事，而并非死亡投掷。 如何才能够形成优秀的故事呢？在告诉我们如何制作可以直接应用到游戏中的有用故事时，游戏设计师通常会特别提到三部作品。如果你感到好奇的话，我可以告诉你，这三部作 品是：亚里士多德编写的《诗学》；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并不会直接告诉你，所以你需要自己找出主要 的内容。 亚里士多德  aristotle(from hhs-english-iv.wikispaces.com)
在亚里士多德的年代里，许多词语的用法与我们现在使用的方法并不相同。《诗学》所探讨的并非诗歌，而是编写悲剧的方法。亚里士多德所谓的“悲剧”，指的并不是“有着悲 惨结局的故事”，而是栩栩如生的故事，即不含超自然或空想内容的故事（游戏邦注：他将这种类型的故事称为“喜剧”）。 然而，数千年来从未改变的事实是，确实存在许多质量较差的文章。 亚里士多德可能不是第一个注意到这种情况的人，但他肯定是第一个对此情况采取做法的人。他就如何编写得体的故事编撰了一本书。如果你觉得他的许多建议似曾相识，这也不 足为怪，因为这些内容在写作课堂上不断重复，甚至包括小学的写作课。 比如，你可曾听说过故事应当要有开头、中间和结局？这种说法便来源于《诗学》。这提醒了我们，故事中有各种不同的部分，作者应当注意如何将这些内容妥善地搭配起来。 《诗学》中还提出了甚为著名的故事三幕结构，从根本上将故事分割成3个部分。在首个部分中，发生的事情奠定了故事的背景。在第二部分中（也是最长的部分），主角努力在事 件发生时做出某些举动。在最后的部分中，最终解决了问题。（游戏邦注：作者听过更为形象的描述，第一幕，让英雄爬上树，第二幕，向他投掷石头，第三幕，把他从树上打下 来。） 亚里士多德强调的重点在于，每幕与前幕都存在逻辑上的因果关系。较差的作品的样子是：“X发生，然后Y发生，然后Z发生。”较强大的作品应该是：“X发生，正因为此而发生Y ，从而触发Z的发生。” 在主角的问题上，这种因果规则更具约束性。当坏事发生在主角身上时，不可能是毫无缘由的。坏事应该是由角色能够为人所理解的举动而产生的，而事件应当是该举动必然发生 的结局。这会使得观众怜惜和同情英雄，因为我们可以看到人性的弱点，我们可以理解为何该角色之前会做出那样的举动，而且我们也看到了正是之前的举动导致了最后的事件。 这也就解释了为何亚里士多德非常讨论所谓的“解围事件”（游戏邦注：也就是说，主角身上的结局毫无缘由地转好，比如“在主角濒临死亡之时，忽然醒来，意识到所有的这些 都只是场噩梦，故事结束”）。在“解围”中，英雄并不会影响故事结局，主角丝毫无从控制故事。 将这种理论运用到游戏中，我们就很容易理解为何有时发现电子游戏中的角色在过场动画中死亡会让人产生挫败感。因为玩家无法做出选择，此时主角不受玩家控制，而情节就这 样发展下去。 最后，亚里士多德所定义的舞台剧由6个元素组成，提及这点还是有一定价值的。在故事成分强大的游戏中，会出现类似的6种元素： 1、情节。描述所发生事件的内容。 2、主题。事件的涵义？事件发生的原因？ 3、角色。故事中所涉及的人物。 4、措辞。对话，也包括演员在表演中的口头对话。 5、节奏。包括音乐中的“节奏”，也包括人类话语的自然节奏。 6、宏伟场景。这便是亚里士多德所称的“视觉奖励”或者他那个时代的特效。他经常抱怨，许多戏剧只包含宏伟场景，除此之外毫无内涵。你是否觉得这种感觉似曾相识？ McKee 我并不确定Robert McKee所编写过的电影剧本是否曾被真正拍摄成电影。多数时间，他负责教授电影剧本创作。如果你曾经从电影院中走出时感叹道“这个故事真得很棒”，那么 这个剧本便很有可能出自McKee某位学生之手。  robert-mckee-story-seminar(from writersstore.com)
从本质上来说，《故事》重述了《诗学》的内容，但是更具体化地关注电影剧本创作。我觉得《故事》阅读起来更加容易，书籍以口语化的风格来编写（游戏邦注：而且，这部书 籍使用的是现代英语，而不是古希腊语）。以下是本人意译的部分McKee所著书籍中的内容： 对故事来说，重要的不是公式，而是形式。你并非根据某个模板来创作故事。而是，通过对不同故事间普遍联系的理解，创作出独特的故事。（游戏邦注：作者补充称，这种想法 同样可以用于该过程所涉的全部做法。） 所有的故事都有如下形式： 1、主角有个目标，这个目标来源于某个激励性事件。 2、主角努力去实现目标，但是遇到了沟壑（游戏邦注：各种各样的障碍，并不一定是字面意义上的沟壑），所以无法马上实现目标。 3、主角尝试跨过沟壑。所遇到的情况不是沟壑变宽使他们难以跨越，就是他们在跨越沟壑后发现有个新的沟壑。 4、这种沟壑跨越循环不断持续，直到主角最终完成目标，或者某种因素导致主角永远无法完成目标。 5、在典型的三幕结构中，在幕与幕之间会产生两个新的沟壑。 从本质上来说，故事的内涵就是改变。每个场景都应该有改变发生，或者有某些意料之外的事情发生。如果角色在某个场景的开端和末尾的状态毫无改变，那么就表明你应当移除 这个场景。以如下方式考虑问题：如果你要将自己的生活转变成时长2个小时的电影，难道你会将这些宝贵的时间浪费在日复一日的循环性任务上吗？还是说你只会呈现那些让你的 生活发生重大改变的时刻，而让观众合理地假设这些改变期间的所有事情都按照常态发生？ 你会注意到，上述情况与游戏极为吻合。游戏中需要玩家做出决定，导致游戏状态发生改变。游戏都有个结局，最后角色的目标要么实现要么因某种无法扭转的因素而无法完成。 因而，有些游戏根据玩家的体验来编造强大且自然发生的故事也就不足为奇了。 另一个有趣的地方是，McKee讨论了“性格”和“特征”间的不同之处。当我们定义“性格”时，通常联想到的是表面化的数据，比如最喜欢的食物、血型和发色等。McKee将这些 内容称为“特征”。“性格”是定义角色本身的因素，比如“彰显角色性格的行为”或“她有很强大的道德感”等。McKee的说法是，只有当将某个角色放在对立矛盾的情形中时， 才能够体现出角色的性格。比如，我们或许会说某个人很“无私”，但是口说无凭，只有面对某些事件的选择才能体现出角色的性格，比如在着火的建筑物内是选择救助陌生人还 是自己逃生。 性格和特征在游戏中分别指代什么呢？首先，线性化故事通过过场动画（游戏邦注：而不是游戏玩法）可以更好地展现出角色的性格。为主角做出道德选择会让玩家感到甚为艰难 ，因为选择通常并不会导致现实世界中的变故。因为这只是游戏，玩家很安全，因而他们不会失去现实世界中的任何东西。因而，玩家所做的决定并不会反映出他们自己的性格， 因为他们的性格并没有收到考验。在现实世界中为好友挡子弹与在游戏世界中决定是否获取Light Side Points并非完全相同。在游戏中加入道德考验并非不可实现，但是那些选择 的所产生的情感后果很难真正被玩家感受到。，因为做出这些决定的是玩家而不是主角。因而，在玩家无法控制故事时呈现强大的性格也会更加容易。 但是，这也会让游戏失去部分互动性，游戏性就此减弱。而这正是为何游戏中的故事讲述较为困难的原因之一。 Joseph Campbell Joseph Campbell花了大量的时间来研究深化、传说和英雄故事，寻找它们之间的相同和不同之处。他发现多数神话普遍采用某种结构，他将其称为“Monomyth”或“Hero’s Journey”（英雄之旅）。这是种具体的故事类型，因而所阐述的内容比McKee得故事描述更为具体。由于许多游戏将玩家视为英雄，所以了解以下内容也是很有用处的。  hero’s journey(from vajrakrishna.wordpress.com)
Hero’s Journey的流程如下： 1、英雄开始时只是普通世界中的平民，而且这个“普通的”世界正常运转。 2、英雄听到了冒险的号召。 3、英雄可以决定听从这个号召，也可能会忽略。但是如果出现后者这种情况，就会发生新的事件逼迫英雄听从号召。 4、英雄开始他们的征程，遇到了首个障碍。通常情况下，英雄需要克服这个障碍才能够继续前进。 5、随后，英雄越过障碍，进入一个更为黑暗的新世界。他们历经考验，而且考验一个比一个艰难。在这个过程中，英雄逐渐成长。增加的不仅仅是“经验值”和“等级”，还有“ 成熟度”。英雄自身得到升华，他们变得更强，成为了真正的英雄。 6、最后，英雄遇见了最终的邪恶之事，而且解决了这个问题。 7、英雄获得了奖励。 8、英雄开始回到他们自己的世界。在这个过程中他们遇到了最终的障碍。 9、最后，英雄回到了之前的普通世界。世界或许并没有发生变化，但是英雄已经有所改变。 你或许会发现，这种结构出现在许多英雄故事中，而Campbell所著书籍细节化地阐述了上述情况发生的缘由、其中的内涵以及与社会价值观的关系。简单地说，英雄故事讲述的是 某种文化所认可的理想道德和价值观，英雄的性格中潜藏和展现了这些东西。 现在，你或许正打算将此用作开发的公式。不幸的是，事情并非如此简单。正如McKee所述，故事（游戏邦注：包括英雄故事）并非公式，而是形式。这篇文章的目标就是让你不盲 目地遵从Monomyth法则。 那么，如果我们不能用上述理论来编写故事，那么它有何种用处呢？我觉得，最重要的事情是掌握故事的普遍形式，这样你就可以选择那些对自己所编写故事适合的做法。但是， 重点在于，需要谨慎地思考，“Campbell如是说”这个理由远远不够。应当注意的是，并非所有的游戏都采用这种结构，尤其是那些你在其中扮演反派角色的游戏。 Bob Bates在他的文章中对结构发表如下评论： 1、在编写故事时，先确立核心前提或愿景。选择一个合适的英雄。 2、展现英雄所生存的普通世界，然后通过某个刺激性事件破坏这个世界。游戏开始时通常都会发生这种事情。 3、进入“森林”，也就是游戏本身。 4、“遭遇邪恶之事”是对BOSS战的本质性描述，这也是为何我们在游戏中遇到如此多BOSS战的原因。 5、“获得奖励”可以视为英雄意识到你为故事设置的前提。并不一定要获得真正意义的“奖励”，比如一袋金币、一个公主或者一件古老的魔法物品。 6、在游戏过程中，英雄角色应该能够成长。我们作为设计师，很容易陷入主角只在能力层次上有所提升的困境。然而，如果英雄的性格也能够在故事发生期间获得成长，这将会使 故事的质量有所提升。英雄没必要一开始就是完美的。如果他们刚开始是个农夫，随后通过故事成为圣人，这样的故事会更加有趣。记住，英雄也必须获得成长，不仅仅是玩家。 Scott McCloud 《Understanding Comics》在第2章和第3章中有关故事讲述的内容并不多，但是却在创建强大角色和戏剧化时刻方面提供了许多有用的建议。 在44页和45页上，McCloud断言图表和现实主义照片的艺术形式存在不同之处。他指出，东西越图标化，我们越能够将自己融入其中，越细节化和现实化，我们越会将其与自身区分 开来。（游戏邦注：这是因为人类的大脑是很棒的样式识别机器，我们能够在空白处填上我们看到的样式，与其他我们已经识别的样式区分开来。） 游戏中如何呈现上述理论呢？ 1、想想许多电子游戏中的主角，包括Master Chief、Samus Aran、Gordon Freeman和Chell等。通常情况下，你不会看到自己所控制角色的过多信息，你也听不到他们的许多话语 。这种情况的出现并非偶然。这是故意设置的，使玩家可以将他们自己的个性融入到角色之上。角色成为了玩家的延伸，你觉得自己与角色存在情感维系，因为二者已经融为一体 。 2、此外，你也会看到某些定义分明的强势角色，如Duke Nukem和Lara Croft。在这种情形中，我们迅速地识别出主角并非我们自身。为补偿这种感觉，角色们必须展现出强大的个 性。 3、总的来说，我觉得主角的设计可以选择上述两种做法之一。将其图标化而不定义其个性（游戏邦注：让玩家可以创建出蕴含自己个性的角色），或者将其现实化，赋予角色强大 的性格。二者任何形式的结合都将使得玩家更难与他们的化身和角色产生情感维系。 4、再考虑下游戏中的敌人和对立角色。因为现实主义视觉能够产生外部感，高度细节化的敌人让玩家看起来非常陌生，而有着卡通化和或图标化感觉的敌人看起来会更加熟悉。视 频游戏《毁灭战士》中的怪物以现实主义风格绘制而成，让它们看起来更加像外星人，因而感觉起来更加危险。相反，《口袋妖怪》中的怪物更为卡通化，让它们看起来更加友好 ，这完全适合这款可以招募怪物将其转变成好友的游戏。在桌游中，我们希望接触的是那些有着图标化棋子（游戏邦注：如象棋中双方颜色不同的棋子）的游戏，这可以让玩家将 棋子视为自身的延伸，其他玩家的棋子也能够带来某种熟悉感。相对而言，有着高度细节化棋子（游戏邦注：带有深层次角色描述的现实主义风格小模型）让玩家将自己和角色区 分开来，而且也会导致玩家之间处在对立面上。 5、在环境的处理上也会看到上述理论。如果环境（游戏邦注：包括电脑中的3D环境和桌游的2D实体游戏环境）采用现实主义手法，就在不断提醒玩家这是个游戏世界。这种做法更 适合那些想要让玩家感受到自己进入某个新世界的游戏。比如，高质量的现实主义环境能够提升悬疑和恐怖游戏的质量。 McCloud提出的又一个看法是我们会使用工具，我们也会将这些工具视为自我的延伸。我们的自我延伸感并不仅仅局限于身体，还可以是处于直接控制下的所有东西。正如他指出的 那样，当你身处车祸现场时，你更有可能说的是“他们撞了我”，而不是“他们的汽车撞了我的汽车”。 这与游戏有何关系呢？ 1、对于电子游戏而言，主机控制器（游戏邦注：还有鼠标和键盘）成了人类身体的扩展。玩家将控制器视为自身的一部分。这也就解释了为何玩法控制以及良好的用户界面对电子 游戏的重要性，如果你不知道要如何通过控制器来玩游戏，那种挫败感不亚于你想要用手捡起东西时发现自己的手不听使唤。 2、对于电子游戏和桌游二者来说，虚拟形象（游戏邦注：也就是玩家在游戏中的化身）也扮演着玩家的扩展。就像在汽车事故中那样，如果你的对手吃掉了你的棋子将其送回起点 ，你很可能会说“他们刚刚让我退会起点”。作为设计师，应当注意玩家与游戏中化身的情感链接。 我想要让你注意的最后一个要点是McCloud的“blood in the gutter”概念（游戏邦注：书中66页到69页）。在书中描述了两个场景，其一是谋杀者将斧子挥向受害者，其二只是 展示了个尖叫声。受害者的死亡时间是何时呢？在这两个场景之间，正是你这个读者靠着自己的想象力杀死了他，而这个画面并没有真正呈现出来。 这便是所有故事讲述媒介中的暗示。Alfred Hitchcock是这方面的大师级人物。比如，在著名的《Psycho》中，事实上你并没有看到任何内容。有个人手上拿着刀做出刀割的动作 （游戏邦注：并没有呈现出任何受害者），另一个画面是妇人尖叫的声音（游戏邦注：并没有呈现受害者是她），如此反复并最终呈现流淌的血液（游戏邦注：此时谋杀者和受害 者画面都没有呈现出来）。 我们要如何将这种方式运用到游戏的故事讲述中呢？ 1、某些故事讲述者有强烈的欲望说出所有发生事件的技术性细节和奇幻世界的背景故事。但是并没有必要这么做。玩家会自行填满空白之处。事实上，你并不需要告诉他们所有的 事情。 2、事实上，如果你不告诉所有细节的话，有时候效果会更好。玩家的想象力无疑比游戏中的艺术作品更为鲜活。 3、将玩家视为故事中的积极参与者。你所编写的故事要对他们使用想象力予以奖励。 4、该做法还存在经济上的好处。我们总是想将大量的资金投入细节化的艺术以及时间更长的过场动画中，但是如果我们采用更为经济的做法，展示较少的内容，做法恰当的话我们 可以取得更好的效果。 5、换句话说，少可能转变成多。对于故事编写者来说，找到“理解所发生事件的足够信息”和“给想象力的发挥留下空间”是最具技巧性的工作，这也是游戏故事讲述较为困难的 又一个原因。 6、想想你看过的某些故事（游戏邦注：包括游戏和其他故事），研究过少或过多的信息对故事所产生的影响。再想想那些保留部分信息的故事，用户或许会获得更为愉悦的体验。 Ernest Adams  ernest_adams(from paulhazel.com)
游戏设计师Ernest Adams在GDC 2006上做了个鼓舞人的演讲，题为“互动故事新愿景”。首先，他简单地总结了上文中描写的某些内容，然后进一步挑战我们所有的基本想法，随
后他尝试取得进一步的发展。以下是我的记录以及部分个人见解： 1、亚里士多德的《诗学》很不错，但不要忘记了，这部书籍针对的是戏剧而不是游戏。故事可能确实包含开始、发展和结局三个部分，但是在游戏中，故事通常包含多个开始、发 展和结局。三幕结构对2到3小时的戏剧和电影确实有效，但是并不一定适合30分钟的桌游、玩时长达1个月的RPG竞赛或100个小时的主机游戏。 2、Campbell的Hero’s Journey的效能仅限于英雄故事。那么，如果你的故事与英雄无关又会怎么样呢？而且，正如Campbell自己承认的那样，Monomyth并非模板，所以我们不能 将其用作构建故事的工具。 3、McKee的《故事》关注的是电影剧本，因而它或许并不适合于所有游戏。游戏是种与电影不同的媒介。尽管二者间存在某些共同之处，但是了解差异性也是很重要的，因而任何 有关电影剧本创作的建议在用到游戏设计中时都应当小心谨慎。 那么，如果上述这些书籍都无法起到作用的话，难道我们就毫无收获吗？（我不这么认为。我们仍然需要有个起点，而以学习其他媒介中形成优秀故事的元素作为起点确实不错。
） 随后，Adams阐述了我们在讲述游戏中故事时经常做的3个假设： 1、互动故事的“圣杯”是个完整的沙盒，这是个完美的模拟世界，对玩家的所有输入都能够做出令人相信的回应。 2、互动故事并非游戏。 3、当玩家被包含到互动叙事时，他们应当考虑的是故事而不是游戏机制。 接下来，他向着3个假设发起挑战： 首先，呈现完美的模拟世界可能产生何种坏处呢？实践性的原因总是存在的，因为这样做势必要花费大量资金。还有来自Koster的论据，我们已经拥有了一个现实世界，而且并非
总是充满乐趣。但是多数情况下，关键的问题在于，即便在最为“开放世界”的游戏中，玩家并非从完全自由中获得快乐，他们的快乐源于在被限制的环境中拥有自由。 Ernest提出了另一个设计师的规则，他称之为“Ken Perlin原则”：互动故事中事件的成本必须与它的不可能性成比例关系。那么，“成本”的含义是什么呢？他解释道，每个作 者都有个“可信度预算”，如果发生了过多令人不可思议的事情，故事就会让人产生怀疑。故事中发生的所有不太可能发生的事件的总和不能超过某个特定的数量，否者便会引起 玩家的反感。（自然，某些游戏与其他游戏相比有较高的可信度预算，这与游戏所设置的场景有关。比如，在魔法世界中，在空气稀薄的高空中出现小鸡是稀松平常的事情，而在 现实主义现代化场景中，这种情况会被人当成是不恰当的设计。） 作为互动故事设计师，从本质上说你是在与玩家达成协定：如果你（也就是玩家）做出可信的行动，你就会得到可信的故事。这是很重要的，因为设计师和玩家共享可信度预算。 玩家必须接受故事所设置的场景。如果玩家采取与故事世界不相一致的举动时，他们得到的就是不可信的故事，而且过错并不在故事作者，而在玩家。如此，故事作者的目标并非 创造出在所有情况下都100%可信的故事，他们必须实现的是在玩家采取可信做法时呈现出可信的回应。 正如我们从Doug Church的《Formal Abstract Design Tools》中所看到的那样，玩家意向和叙事间存在某种平衡。但是，我们可以通过玩家和设计师间达成的“角色扮演”社交合 约来扩展。 当然，为了让玩家能够接受这个合约，他们必须了解游戏的规则，而且他们必须同意在这些规则之下玩游戏。如此说来，规则是游戏中的重要成分，但是互动故事和游戏也通过某 种方式联系起来，让玩家获得游戏和故事的双重体验。 融合游戏和故事的方法，这难道不是我们苦苦追寻的吗？ 总结 亚里士多德、Campbell和McKee为故事讲述者提供了许多经常被引用的建议，因而我们将他们的建议应用到游戏中是很自然的事情。对于那些对游戏这个层面特别感兴趣的人，我强 烈推荐你自行阅读他们的书籍。 在游戏中，玩家及其角色和化身的识别是让玩家与游戏间产生情感维系的常用方法。在你设计游戏时，考虑这部分的内容，想想你还可以采取哪些做法加大玩家对游戏的情感投入 。 记住，故事作者构建的故事情节同来源于游戏玩法的自然发生的故事间有所不同。在制作每款游戏时，想想哪个部分更加重要，你可以如何对该部分进行加强。 对某些游戏设计师而言，真正的“互动故事”是游戏的必杀技。事实上，我们常常无法带给玩家这样的感觉：在自己创造的有趣故事中，他们是主角。我们过去如何叙述互动故事 ，未来要如何创造更优质的故事内容？这是尚待解决的问题，但我们至少可以谈论某些众所周知的基本要素，这就是我们今天的主题。  Planetfall from en.wikipedia.org
多数棋盘游戏都缺乏稳固的嵌入式叙述故事，所以本文主要讨论视频游戏及桌面RPG游戏的故事叙述。但有些现代棋盘游戏试图将桌面棋盘游戏体验同RPG模式结合起来，包括玩家 互动玩法中的故事元素。 推荐读物 * Noah Falstein的《A Point of View》。我们将故事叙述视角划分为“第一人称”或“第三人称”——我们也以此谈论视频游戏视角。因此我们很容易会认为二者存在关联性， 但其实并非如此。文章清楚阐述二者存在的差异。 * Chris Bateman的《Diversity in Game Narrative》。这主要概述游戏存在的各种故事结构。 * 《Challenges for Game Designers》第13章。 我们可以简单就游戏整体结构划分故事内容。故事结构由玩家享有的各种选择、选择的开放性或局限性及这些选择给故事带来的影响决定。每种结构都有利弊，下文我们将进行讨 论。  storylinear from gamedesignconcepts.wordpress.com
线性模式 线性故事是传统的故事叙述模式，其包含某些不会影响故事的玩法元素。在这种情况下，故事和玩法属于独立体，因为故事没有选择，而玩法通常包含某种决策过程（游戏邦注： 否则这就是故事，而不是游戏）。他们可以在主题上有所联系，故事可以影响玩法，但玩法无法影响故事，因为故事只有一个。 线性故事相比其他故事结构存在一大优点：能够轻松采用已有数千年历史的传统故事叙述方法。这类故事存在强烈情感冲击——我们依然将《堕落星球》的Floyd之死及《最终幻想 7》的Aerith之死作为游戏故事叙述发展史中的关键时刻，虽然这些事件都不在玩家的控制之中。 线性故事由于缺乏决策元素存在明显弊端，其游戏色彩并不突出。就如上面说到的，线性故事和游戏机制存在天然屏障，这会限制故事的效果。
 storybranching from gamedesignconcepts.wordpress.com
分支型 若我们想要添加决策因素，最明显的办法就是在线性故事中添加各种决策点。当玩家到达特定地点时，他们需决定怎么选择，然后故事就会沿某路线发展，直至到达另一选择点。 典型例子就是Sega Genesis的《梦幻之星III》；主角有两次在两位女孩中选择一位作为结婚对象的机会，这就带来4个分支路线，每个路线都有自己的故事和结局。 分支故事的优点是具有互动性。若开发者设置众多选择，覆盖玩家的所有期望，游戏就能够有效回应所有玩家决策。乍看之下，这似乎是游戏叙述的最终解决方案，因为这能够应 对所有问题。 但分支故事存在一大缺点：成本很高。就两种选择而言，《梦幻之星 III》故事创作者就得编写4种故事。若是存在第三种选择，他们就得编写8种故事，而10种选择则需要1024种 故事！想想典型策略游戏玩家所做的决策数量，你会发现编写分支故事任务瞬间变得难以驾驭。 更糟的是，只玩一次的玩家就无法浏览所有游戏内容。要查看所有游戏发展路线需进行多次重复体验，即使如此，玩家还需判断哪个是真正的故事，哪些是没有发生的额外故事情 节。  storyparallel from gamedesignconcepts.wordpress.com
平行型 用Bateman的话说，这是自行分解的分支故事，允许玩家做决策，最终将全部内容压缩成若干命令事件。例如，在《Silent Hill》中，玩家享有若干选择， 或发展故事，或沿途呈 现某些额外故事元素，这些都会影响结局。但无论玩家有没有进行额外操作，有些事件他们无法回避。 平行路线通过保持玩家决策及控制故事数量解决分支模式叙述存在的问题。所以，乍看之下这似乎是最根本的故事结构。 也许你早猜到，此模式依然存在一个问题：由于玩家被迫面对某些事件，整个故事情节就变成线性模式。游戏丧失玩家主导感觉，因为无论他们进行什么操作，某些故事内容依然 会出现。 一个潜在解决方法是，让玩家决策改变游戏结局。玩家依然会遇到同样的故事情节，但最终结果由玩家所做决策决定。遗憾的是，因果关系将很快丧失——玩家决策只有到尾声阶 段才会显露出来，玩家对特定结局所造成的影响通常非常模糊。 此外，此结构还存在这样的问题：玩家需反复体验整款游戏数次才能获悉所有结局。
 storythreaded from gamedesignconcepts.wordpress.com
交错型 Bateman用此形容分解成小块内容的故事，也许还有若干故事情节（游戏邦注：这些故事也许相互交错）同时进行。玩家选择以何种顺序进行，采用哪个路线。例子之一就是《魔兽 世界》，其中玩家能够选择任意关卡，体验不同故事元素。另一例子是《上古卷轴》系列，玩家能够基于自己的期望选择特定故事情节，玩家会沿途操作其他关卡或次要情节。这 些次要情节也许会给主要故事情节带来影响。 交错叙述故事的优点是富有表达性。设计师可以选择让各种故事情节同时发生，就像《黑色追缉令》和《真爱至上》之类的非线性电影。 此外，故事也许还会有各种开端、主体和结局，但玩家能够接触所有内容，能够以任何顺序体验任何内容组合，所以强制性重复体验问题便迎刃而解。若玩家足够心思缜密，只要 通过一次体验就能够浏览所有游戏内容。 这依然存在一个问题。由于某些事件会影响其他事件，通过故事查看各种可能路线的过程要比分支叙述模式复杂许多。 编写交错内容也颇有难度，事件能够以任何顺序发生，因此就存在玩家以不合理顺序操作内容的可能。故事创作者需确保玩家所访问的故事事件富有意义。追踪故事内容活跃性的 决定变量就会立即变得非常复杂。 最后，交错故事存在混淆玩家的危险，若同时存在过多个并行情节，玩家就无法立即辨别它们之间的关系。这也是书籍、电影试图同时讲述多个故事所面临的风险。
 storydynamic from gamedesignconcepts.wordpress.com
面向对象的动态叙述 此术语源自Bateman对《Façade》的描述。意思是游戏存在若干迷你故事，每个故事都有特定进入点和退出点。单个迷你故事的退出点会引出最终结局，或另一迷你故事。迷你故事 可看作是书籍的“章节”，戏剧的“幕”。 这类故事有平行模式的优点，但缺乏先线性故事的特色。每个迷你故事都有自己的选择，整个迷你故事集合就像是更大分支或平行故事。每个迷你故事都有独立性，这能够减少编 写完整故事所需的时间。 这类游戏存在两个弊端。首先，这类故事依然存在强制重复体验问题：玩家需体验游戏数次方能获悉所有故事路线。这也是试验中的故事结构，目前这类游戏数量不多，不足以让 我们分析其利弊。《Façade》是由若干计算机博士共同完成，所以这不是传统故事创作者能够轻松驾驭的故事结构类型。 视角剖析 视频游戏的摄像头或第一人称，或第三人称。 摄像头视角 第一人称是指摄像头置于主角的额头前。玩家所见即角色所见。这促使玩家觉得自己同角色的联系更密切，因为可以这么说，玩家就处在角色的头部里面。此模式的缺点是，这不 是真正的第一人称视角，因为人类的周边视觉要比屏幕宽许多，有时这会损害玩家的沉浸性，因为他们不习惯此处视野的局限性。 而在第三人称摄像头视角中，玩家看着主角，通常从角色背后切入，这样你就能够看到角色的背部。这让玩家得以更广泛地浏览游戏空间，向玩家提供的角色视觉信息更逼真。当 然通过保持注视角色，玩家会感受到他者性——没有镜子的帮助，我们无法看到自己的背部，所以摄像头视角提醒我们主角不是自己。 将此同麦克劳德的图标&现实主义理论结合起来，我们会发现第一人称角色更接近图标，更像是个“白板”角色，其中玩家能够将自己的个性影射到上面，而逼真的第三人称角色就 有强烈的特征描述。 假设存在第二人称摄像头视角，它主要指玩家从正面观察主角。毋庸置疑，这会令多数游戏陷入混乱局面。最贴近的例子就是晦涩的掌机游戏《Robot Alchemic Drive》，其中玩 家控制人物角色（第三人称），而角色反过来会通过遥控装置控制庞大机器人（第二人称）。从此意义上看，机器人就是主角，游戏就是采用第二人称摄像头视角。 故事视角 谈论文学时，我们也会使用“第一人称”和“第三人称”。这存在不同之处。 第一人称故事是指叙述者以自己的角度叙述故事。主角直接面对读者，告诉读者自己所遭遇的事件。 第三人称故事更常见，是指故事以旁观者角度切入。这也许是“第三人称全知视角”，其中读者能够看到发生的所有事件，甚至读出多个角色的想法，而在“第三人称局限角度” 中，有些信息则不为玩家所知。 文学中鲜有的故事类型是第二人称模式，这里的故事从读者视角切入。这类故事非常少见，因为以可信角度编写此故事颇具难度。 你也许会发现此刻几乎所有游戏叙述都基于第二人称。这就是玩家控制角色会出现的情况，这种情形很常见。 这也是故事叙述颇具难度的另一原因。 互动角色 有时游戏的整个故事脉络已确定，呈线性模式，但依然存在若干供玩家进行互动的角色。在视频游戏中，人际关系通常需要量化，NPC同玩家的关系有两种常见模式。 标记 此背景下的“标记”具有二元值。某活动或发生，或未发生。玩家同某NPC或交谈，或没有交谈，若他们有进行交谈，他们或选择，或没有选择某沟通路线。因此，特定新NPC或者 沟通选择，或出现，或消失。 标记的优点是操作简单。所有情况或发生，或没有发生，这简化玩家的操作逻辑。这同时也非常容易在代码中落实；程序员能够轻松制作二元逻辑。 缺点是若这些角色非黑即白，中间没有灰色元素，便缺乏足够深度。设计师可以通过结合二元值提高复杂性，但此时操作会变得非常复杂，丧失之前提到的简单性优点。 亲密性 亲密性不是基于是/否二分法，而是通过数值测量角色对另一角色的喜爱或厌恶程度。若你需要判断某NPC是否以特定方式表现，不妨查看其亲和力值是否超越特定界限值。 亲密性机制的优点是其依然保持简单，比标记机制更能应对复杂内容，更富有表达性。 但开发者需谨慎使用亲密机制。他们得到的也许是非常模糊的机制，尤其是当亲密变量或随机摇骰机制参与决定最终结果。总之，我们很难在未进行广泛测试的情况下，“准确把
握”此机制。 角色对话 有些游戏包含对话机制，角色具有话语选择权，所瞄准的NPC会给出相应回应。 我们可以通过相同方式思考游戏叙述机制。对话可以是： * 线性模式。我走进NPC，选择“交谈”指令。它们告知我某些情况。 * 分支型。我发起对话。NPC陈述某事，我随后享有系列回应选择。根据我的回应，NPC也许会陈述其他内容，给我全新的系列选择。 * 平行型。我发起对话。NPC陈述某事，我享有系列回应选择，然后它们做出相应回应。但我可以通过若干回应组合得到相同结果。 * 交错型。我发起对话，可通过各种方式开始谈话。NPC做出相应回应，我在对话中采用的每个行动都会开启新的对话路线，关闭不相关的对话主题。 * 动态型：我同时经历分支或平行对话。我基于结果继续新对话。各模式下的对话编写难度同对应故事编写难度成正比。 构造优质角色 有些故事角色非常“丰满”——它们有很多层面，深刻的角色通常富有层次，非常精细，会随故事的发展而发展。 有些角色则非常“单调”。单调角色是否总是不好？其实不然；不是所有角色都要复杂、深刻或定义清楚。即便是在莎士比亚的戏剧中，也有某些非常单调的次要角色，但主要正 反角色要非常丰富。 一般原则认为，角色需随故事的发展而发展。因此，“放映时间”较少的次要角色需保持单调，因为它们的发展时间很短；常见角色需要富于变化。若你希望创造强烈角色，设计 单调主人公不是个好主意。 原型 & 固定模式 我曾在采访中被问道：能否描述“原型”和“固定模式”及二者的差异。 McKee认为故事主要涉及模式，而非公式。原型是模式，而固定模式是公式。 “恶棍”是原型，而Snidely Whiplash样式，留小胡子，戴高顶帽，穿黑斗篷，自私自利的坏家伙则是固定模式。  Snidely Whiplash from gamedesignconcepts.wordpress.com
原型作用很大。它让我们得以基于符合熟悉模式的可信角色叙述故事。固定模式则使用过度，通常会让故事缺乏可信度，因为用户之前已从其他故事中看到类似角色，除非此设计 有非常充分的理由。 Freytag的三角模式 这也许曾出现在你小学语文课堂中。其理念是故事通过少量描述奠定基调，然后逐步融入上升动作，内容开始变得日益强烈，接着就达到高潮，然后随着尾声阶段的到来，故事开 始融入下降动作和解决方案。 这不仅适合故事叙述，玩法亦是如此。游戏包含陈述内容、上升、高潮、下降和解决方案。 若故事和玩法的情节脉络保持协调和同步，我们能够得到更富戏剧色彩的体验。实际操作要困难许多；在许多游戏中，最困难的玩法通常发生在游戏中间，也就是敌人和挑战变得 更加困难，而你尚未找到新武器、新升级渠道的时候。随着玩家的日益强大和熟练，游戏的挑战性就会逐步降低，虽然此时故事的紧张度日益提高。我们能够基于大量的戏剧元素 和预兆判断游戏何时进入最终boss战斗，然后玩家挥舞宝剑几秒钟后便获得胜利（游戏邦注：这听起来有些虎头蛇尾，缺乏可信度）。 总之，设计师需在平衡游戏的过程中留心故事内容，及故事戏剧情是否适合玩法的戏剧化时刻。 游戏依然是主导 记住，作为游戏设计师，你的主要任务依然是制作游戏，而非故事内容。在多数情况下，故事要能够兼容玩法。至少，你要在通过牺牲玩法成全故事发展时保持谨慎，或是当你计 划向玩家呈现过多非互动故事内容。 创作者在撰写故事叙述内容时要时常回归到根本美学效果，确保故事能够支撑游戏的美学画面。 所学经验 让传统线性故事融入更多互动元素的方法很多。各种方法都有其利弊。 我们应不断进行尝试，探索各种适合游戏的非线性故事叙述模式。 设计项目：概述 我称之为“文件夹项目”，是指学生们能够将自己创造的游戏装进游戏设计的文件夹中，去展示他们的游戏设计才能。根据你所处的情境和职业目标，也许你会愿意这么做。 这个游戏设计项目的宗旨是帮助学生在形成概念到完成游戏整个过程中获得相关经验，因为这并不是基于任何现有的设计创意（如你之前在这个课程中创造的游戏，或者你脑海中 所形成的想法）。你有很多时间，甚至余下的整个生命都可以用来开发游戏！所以你可以尽情地去拓展你的项目。而现在，你所需要做的便是开始设计游戏。 过程 根据教学大纲的内容，整个项目的过程如下： 首先，创造核心游戏理念。即使是任何有意义的方法也很难实现这种理念，可以说，它们只是游戏创造前阶段的“种子”。你必须选择一种游戏理念作为你在设计项目中的基本内 容。 其次，你将创造游戏的核心机制。即使你已经完成了所有的细节内容，也不能算是彻底完成了游戏，除非你已经可以开始亲自体验游戏了（虽然你还需要补充一些游戏规则）。你 将要亲自玩自己的游戏，并反复进行游戏直到完成一系列游戏规则。 然后，你将会邀请一些好朋友，亲戚，知己等加入你的游戏。与它们分享你设计的游戏，并与他们一起游戏，接受他们的反馈。而这个步骤主要是衡量你的游戏是否有趣（游戏邦 注：如果游戏缺少乐趣，你便需要重新采纳另一个理念，或者修改当前的理念并再次尝试）。如果在一开始就察觉到游戏缺少乐趣，那么你最好尽快摒弃这一理念，不要再浪费时 间去尝试这些没有结果的无用功。游戏想法虽然廉价，但是执行力却非常可贵，所以适时的行动非常重要。 当你拥有了游戏核心并且与你的设计目标相一致时，你便可以开始探索游戏细节了。确保你带给玩家的游戏体验是完整的，而且无需设计者在旁边进行解说或控制。确保游戏拥有 一套完整的规则，即使玩家不知道下一步该怎么做也不会因此陷进一个死胡同中。你应该让一些从未看过游戏的新玩家去测试游戏，并观察他们怎么做。 如果你对自己的游戏非常有自信，那么你便可以使用“盲测”，即设计者不出现在测试现场的游戏测试。你可以要求一些同意帮助你进行测试的人去玩游戏，并给予你反馈意见。 这就像是现实中的市场状况，即当玩家购买了一款游戏但是却不能与游戏设计者直接沟通时，他们便不得不以自己的理解去玩游戏。 当你完成了游戏中的所有细节后，你便需要开始完善一些小漏洞。确保游戏的平衡，即合理设置游戏中的各种策略，并且让所有玩家都有赢得胜利的同等机会。 最后，当游戏几乎大功告成而游戏机制也趋于稳定时，你便需要考虑游戏的“用户界面”问题，即那些能够让游戏更加亲近玩家，让玩家更容易了解游戏的视觉设计因素。 一旦所有工作都完成后，你便需要花点时间去检查所有物理元素，按照游戏的最终状态进行最后的校对和完善。 你必须牢记，游戏设计是一个迭代过程，所以你随时都有可能需要回到之前的阶段而重新开始一些工作。这样做并没有什么不好，而且这也是为何你需要尽早扼杀那些没有价值的 理念的原因。如果你是在第一周就意识到需要重新开始设计，那么一切都不算太迟。 创意生成 “课程4”中便提到了许多关于构思创意的方法。可以从核心美学，核心机制，材料或者其它资源以及各种叙述中寻找灵感。 如果你能够想出更多游戏理念，你便越能够越轻松地设计出优秀的游戏。 设计项目的限制因素 当然了，我可以毫无保留地向你们公开整个设计项目，但是为了鼓励你们开始创造游戏，我决定列出一些限制因素。你们需要记住，限制因素也是你最亲密的朋友。 如果你在参加这个课程之前从未设计过一款完整的游戏，那么你就更应该仔细阅读这些限制因素。不论你是创造桌面（棋类）游戏，卡片游戏或者置放指示片游戏（这就意味着这 些游戏的物理元素中都必须包含有棋子，卡片以及置放指示片）。这些游戏不只要包含一个以上的这些元素，同时也需要包含一些额外元素（如骰子等）。你可以自己选择任何主 题，只要这个主题具有独创性，即不会侵犯任何现有的知识产权。简而言之，如果你的作品侵犯了他人的商标或版权，那么请你果断摒弃它。也许在你的职业生涯中将会遇到许多
涉及别人知识产权的情况，但现在你应该趁此机会创造出属于自己的知识产权。  playtests_game_prototype(from mapandcounters.blogspot.com)
我将列出两个对你有帮助的限制因素。首先，你并不是在创造一款智力问答游戏，或者其它需要依赖于大量内容的游戏，如《打破沙锅问底》（游戏邦注：一种问答游戏），《看 图说词》，《Apples to Apples》（一款英文字配对游戏）或者《大脑测试》等。这些游戏的目的都是将玩家的视线限制在一个层面上；即你必须回答出足够的智力问答才能够获 得卡片，而这时候你便缺少足够的时间去体验游戏机制。卡片交换游戏（如《万智牌：旅法师对决》以及《宠物小精灵TCG》）也属于这类型的游戏，因为它们都要求玩家花大把的 时间去收集更多卡片。 其次，在很多游戏形式中你并不能使用“掷骰与移动”游戏机制。如此有几点原因。首先，这种机制的使用频率实在太过于频繁。而且《大富翁》已经是这类型游戏的最佳代表了 ，所以你便很难摆脱对于这款游戏的模仿了。就像《Chutes & Ladders》等多数游戏都把“掷骰与移动”当成游戏的核心元素。其次，游戏机制在每一个回合中都能为玩家做出重 要的决策，而玩家自己却不行。如果一款游戏蓄意地区分了玩家与游戏结果，那么玩家将会认为游戏不再有趣而不愿意继续玩游戏。 如果你已经设计出了一些成品游戏但是却仍未察觉到自己是名优秀的游戏设计者，那么你便可以参考这些限制因素。以下的一些限制因素也将会对你有所帮助，这是关于你所关心 的游戏设计领域中的一些选择： 设计一款带有很多嵌入式叙述框，能够让玩家在游戏中进行交流的游戏。在桌面游戏中，你不得不思考如何做才能通过玩家的行动去描述一个故事，以及如何整合叙述内容和游戏 机制。如果你对角色扮演游戏或者其它以讲故事为核心的游戏感兴趣，那么这一点都很适合。创造一款针对于2名以上玩家的纯粹合作式桌面游戏，而游戏中任何一名玩家的胜负都 由团队所决定。这其实是一种挑战，因为当玩家并不能相互对立竞争时，游戏就必须提供一种完全相反的系统。合作式游戏存在的一个问题便是较有技巧的玩家总是能够指挥其余 玩家（尽管这是一种需要所有人共同配合的游戏），从而导致出现MDA Aesthetic模式，即玩家会因为不满其他玩家的命令或指挥而对游戏感到厌烦。而如果你对游戏的社交性感兴 趣的话，这点便是不错的选择。 制作不对称的双人玩家对抗游戏：在游戏的一开始玩家便拥有不平等的资源，地位，能力等等，但是尽管他们拥有如此多的不同，也不会破坏游戏的平衡性。虽然我们不难去设计 这些游戏的核心规则，但是如何保持这些规则的平衡便是一个很难的任务。如果你对游戏设计和游戏平衡的技巧和衡量感兴趣，那就尝试着去做看看吧。 创造一款能够教授中学水平任何课程知识的游戏。你自己决定是要设置一些特定内容或者一些广泛的内容。但是关于这种类型游戏的挑战就在于，玩家都希望尝试一款有趣的游戏 而不是以教育为题材的游戏。如果你对一些“严肃游戏”（游戏邦注：即一些带有目的性而非纯粹出于娱乐的游戏）感兴趣，那么你便可以尝试这种游戏。 如果你已经设计了许多具有专业水平的游戏，而你也认为自己是一名非常有经验的游戏设计者，那么你便可以参考以下限制因素。忽视上述内容。你必须将“掷骰和移动”机制当 成主要的游戏活动而创造出你的桌面游戏。并不断完善它。 很多游戏都在使用这种机制。它能够区分出玩家在游戏中的决策与行动，因此对于那些希望游戏能够带有一种新鲜感或创造性的游戏设计者来说真的是一个非常大的挑战。但是我 敢保证，如果你能够做好这一点，你便能够成功地应对各种挑战。 如果我并不想要制作桌面游戏那该怎么办？ 对于那些喜欢桌面游戏并非常乐意着手制作这类型游戏的人来说，他们真的非常幸运。 但是相对的，也有很多人更喜欢制作电子游戏。我想提醒你们的是，在制作电子游戏的过程中，你必须将大量的时间用于游戏美工和编程过程中，所以如果你真心想要学习游戏设 计，最好选择那种能够让你投入更多时间于设计中的游戏。不论你设计的是硬纸板游戏还是编码游戏，游戏设计的原则和概念都是关于游戏，所以如果你掌握了电子游戏的设计技 巧，你便可以将其运用于桌面游戏的制作中。 也有些人喜欢创造桌面角色扮演游戏。我想提醒你的是，我们总是很难去评估角色扮演游戏的设计，因为有技巧的游戏管理员和玩家总是能够挽救一款糟糕的系统（但是毫无经验 的玩家也可以摧毁一个非常优秀的系统）。如此导致我们更难去评估游戏测试，所以先尝试桌面游戏便是个很好的选择。在过去几年里，桌面游戏与角色扮演游戏之间的界限变得 越来越模糊了，如侧重于叙述的桌面游戏《Android》以及侧重于游戏机制的角色扮演游戏《D&D 4th Edition》。 也许你们在现实世界中还有一些其它的限制因素。也许你会为了避免不必要的开支而不愿意花钱去创造游戏原型。也许你住在一个偏远的地区，缺少足够的原型材料，只能用仅有 的材料去创造你的游戏。也许你没有太多时间专注于游戏中，所以你只能够设计一款较短的游戏（以便你能够在短时间内完成游戏测试和迭代）。如果你在现实生活中找到一些对 你的游戏有影响的限制因素，你应该真正把它当成这个项目中非常重要的一部分。设计者不应该抱怨资源不足，相反地，他们应该利用所拥有的一切资源努力制作出最棒的游戏。 不同种类的测试 “测试”和“游戏”一样被过度使用，对不同的人来说有着不同的含义。总体而言，这个术语涵盖了所有你在开发过程中为实现提升游戏质量的目标而玩游戏的行为。但是，不同 的测试或许有不同的目标，在开始行动之前先了解目标是很重要的。  playtesting(from pluto.kuri.mu)
漏洞测试（游戏邦注：也称为“质量保证”） 质量保证的目标是找到设计方面的游戏行为错误。这个过程无需考虑“趣味性”。如果设计师表示游戏应当有某种表现，但事实上游戏的表现与之不同（游戏邦注：即便游戏目前 的做法更好），这便是需要识别到的漏洞。 通常情况下，我们认为漏洞测试专属于电子游戏。其实，桌游也存在相应类型的测试，其目标在于找到规则中的漏洞和游戏玩法中的迷失之地，也就是游戏中设计师未曾考虑到的 缺陷。 集中测试 在集中测试中，你可以聚集目标用户群体中的部分玩家，看看游戏在满足用户需求方面的表现如何。通常情况下是出于营销目标而采用这种测试，但是此类测试若能将游戏设计师 容纳其中，那么也可以让游戏更受目标群体欢迎。 可用性测试 在可用性测试中，玩家需要完成具体的任务，目标在于查看他们是否能够理解如何控制游戏。软件行业经常使用这种测试，以确保软件易于学习和使用。电子游戏也可以利用这种 测试，易用性测试的结果可以用来改变控制，或者修改早期关卡来更有效地教授游戏的控制方式。 对桌游而言，可用性更为重要，因为没有电脑来对玩家的输入做出回应。如果你误解了《大富翁》中房屋的用处，将其建设在Community Chest上，游戏并不会阻拦你这么做。通过 观察尝试玩游戏的玩家，你可以学到许多有关如何设计各种游戏的东西，使得游戏更容易使用。  boardgame playtesting(from boardgamegeek.com)
平衡测试 如果某种类型的玩法存在会导致玩家忽略游戏中多数有趣选择，那么有趣的游戏便会迅速变得枯燥乏味。如果胜利的战略只有1种，而胜利的关键是哪个玩家能够更好地使用这种战 略，那么其趣味性就不如那些有多种胜利途径的游戏。比如，如果某个玩家存在明显的优势，那么让其他玩家感受到游戏并非不公平就变得很重要了。该类型测试的目标是找到游 戏中的不平衡之处，这样设计师才能够进行修正。 趣味性测试 可用、平衡和功能丰富的游戏仍然有可能不有趣。这种难以捉摸的“趣味性因素”可能难以有意地进行设计，但是当人们在玩游戏时，是否有趣就显而易见了。游戏的某些层面可 能比其他层面更为有趣，因而弄清楚游戏的哪些部分需要保持不变也是很重要的。 所有这些测试的形式有些共有的元素。尽管不能说是完全相同，但是这些测试的最好的方法也颇为相似。所有测试对项目的成功都很重要。那么，为什么要进行区分呢？ 原因在于，每种测试适用于项目的不同阶段。每种测试有着不同的目标，只有先了解目标，才有可能实现。 顺序 你应当在何时采用何种类型的测试呢？你要以何种顺序来安排测试呢？这取决于你的项目，因而顺序的确定与你作为设计师的判断力之间有所关联。但是，以下提供了某些经验法 则： 1、在项目早期，你需要确保项目能够实现设计目标（游戏邦注：“设计目标”通常是制作一款有趣的游戏）。趣味性测试是必要的，这可以确保你不在错误的方向上花费大量的时 间。如果你制作的游戏是针对某个特定的市场，那么集中测试可能也应当在早期阶段进行，询问目标玩家某概念的游戏对他们来说是否有趣。 2、一旦你知道拥有某些东西，你就需要加固机制。对整款游戏进行设计，确保所有的细节都被顾及到。测试游戏中的“漏洞”。（游戏邦注：应当注意的是，漏洞测试贯穿软件项 目的整个开发过程，项目完成度越高测试越频繁。但是，非数字化游戏的“反漏洞”更加容易，而“漏洞”的存在可能会中止测试进程，所以在开发过程早期制定一套完整的规则 很重要。） 3、一旦游戏变得有缺且设计完成后，测试就要逐渐从趣味性测试转变成游戏平衡测试。确保所有数值和玩家能力与你的设计一致。 4、当游戏能够运转并且平衡后，到末期你就要更多地考虑游戏的可用性。改变可用性并不会改变机制，发生改变的仅仅是那些机制呈现给玩家的方式而已。这个重要的步骤往往被 忽略。游戏的习得只能靠其他玩家教授（游戏邦注：即自己阅读规则的对立面），这便是你需要在项目中避免出现的可用性错误。此刻你可能还需要进行额外的专注测试，确保游 戏的主题和视觉元素能够吸引目标用户。 正如我上文说过的那样，这些只是经验之谈。如果你的游戏被特定群体玩家所接受这个层面特别重要，那么就要在项目开发的所有阶段进行集中测试。无需恪守这个测试顺序。 不同种类的测试者 因为测试分为不同种类，所以自然也会有不同种类的测试者。每种测试者都有其优点和缺点，而有些测试者对于某些类型的测试格外重要。 1、自己。你自己就是最有价值的测试者。不要忘却你自己体验游戏的能力。你对自己游戏的了解比任何人都要透彻。 2、其他游戏设计师。如果你足够幸运，认识其他技术娴熟的游戏设计师，那么你可以通过他们来开展某些有意义的测试。他们会批判性地分析你的游戏，并提出设计解决方案。 3、好友和家人。愿意花时间来测试你的游戏的亲密人士也很有用。他们较为容易接近。热心听从他们的意见，不要浪费他们的善意之举。应当注意的是，并不是所有类型的测试都 适合使用这部分人。尽管他们是早期测试的优秀测试者，但是可能并不适合漏洞或平衡性等更细节的测试，因为他们可能并不知道如何去寻找其中的不足之处。 4、经验丰富的游戏玩家。经验丰富的游戏玩家精于寻找游戏中的优势战略，适合进行平衡测试。 5、陌生人。目标群体中的人适合进行专注测试和可用性测试，而且他们在趣味性测试方面也非常重要。但是，寻找测试者需要某些技巧，我们不能就这样走上街头随便找个不认识 的人，让你玩玩游戏。我们将在将来的课程中深入探讨这个问题。  playtest(from ign.com)
亲疏度顺序 通常来说，测试者的亲疏度安排顺序是从较为亲密到较为疏远。首先进行自我测试，然后召集好友，然后是能提供意见的熟人（游戏邦注：包括设计师、玩家或属于目标市场的人 ），最后是陌生人。 如果你过早地将自己的作品展现给他人，游戏中存在的大量设计缺陷和规则漏洞可能会浪费他们的时间并且令其产生挫败感，你应当要善待测试者。而且，如果你过早地使用陌生 人测试者，可能无法得到有价值的反馈。比如，如果你的游戏原型只有粗糙的艺术和游戏成分，测试者可能会更多地抱怨图像的质量，而没有将注意力集中在游戏玩法上。 在这个阶段，你只需要进行自我测试，这样你就不需要依靠其他人或者对他们的意见进行跟踪。从实践上来说，设计师最终会因为过于熟悉自己的项目和系统而忽略某些显而易见 的问题。如果你使用某个种类测试者的时间过长，那么也会出现同样的问题。在项目测试过程中，你需要引入新鲜的观点来审视游戏。 自我测试 在测试早期，当你自行玩游戏时，以下是某些你应当注意的地方： 1、你的游戏是否与设计目标相符？ 是否有趣？虽然多数情况下你自己并非判断有效性的理想测试者，但是如果你自己都体会不到乐趣，那么其他人或许也体会不到。 2、规则是否存在漏洞？ “漏洞”指的是规则没有说明如何进展的情境。比如，可能你制定的规则是玩家的军队可以攻击其他玩家的军队，但是你没有制定如何化解攻击的规则。这种情况下会发生什么事 情呢？实际操作中所发生的事情就是，玩家只能做着等待设计师决定采取何种措施！ 比如，考虑以下4 X 4格子一字棋的规则： (1) 玩家：2 (2) 目标：将标志连成一线。 (3) 背景：绘制4 X 4的正方形方格。 (4) 游戏过程：玩家在回合内在空白格子内画上自己的标志。 (5) 完结：任意在回合内将自己的标志连成一线（游戏邦注：包括横、竖和斜线）的玩家获得胜利。 如果你尝试自遵循这些规则来玩游戏，那么你会很快意识到游戏无法开始，没有规则指明玩家将使用何种标志或者哪个玩家先行动。为解决这个问题，你可以添加某个条件。比如 ： 背景：绘制4 X 4的正方形方格。选择先行动的玩家，指定其使用“X”标志。另一个玩家使用“O”标志。 3、是否出现死路？ “死路”指游戏到达无法继续进展下去的状态，但此刻游戏依然没有结束。想想上文中我们修改过的4X4一字棋规则。假设两个玩家画满了棋盘上所有的格子，但没有人获胜。这种 情况下，游戏无法进展下去，因为规则要求玩家必须在空白的格子上画标志。现在没有空白的格子，因而玩家无法继续按回合进展下去。但是游戏依然没有结束，因为两名玩家都 没有获胜。在这种情况下，就必须添加新的规则（游戏邦注：比如，在完结条目中添加，如果玩家无法继续行动且没有人获得胜利，那么游戏结果就是平局）。 4、是否有不清楚的规则？ 在脑中假设规则却没有将其写下来，这对我们来说是很自然的情况。尽力审查规则，看看自己是否假定了某些玩家意识不到的东西。 5、是否存在明显的优势规则？ 是否存在某个可以很容易地赢得游戏的战略。努力找到它。相比被测试者发现（游戏邦注：更糟糕的情况是，在游戏发布后被玩家发现）来说，自己发现并修正产生的尴尬要少得 多。在你自己制作的游戏中找到清晰度和优势规则缺陷往往较难，毕竟你曾努力将游戏设计得毫无问题。但是，在这方面做些努力，你可能会在早期便找到和修正某些错误（游戏 邦注：从长期来看，这会节省设计师大量时间，也就有更多的时间重复审视游戏设计的其他部分）。 你或许会认为，寻找优势规则是项目后期游戏平衡时需要做的工作。有时确实是这样的，这取决于优势的程度。如果优势过于明显而且很显然已经有碍于你从测试中获得真实信息 ，那么就要马上纠正。 独自测试难点 以下是某些难以独自进行测试的东西： 1、即时多人游戏，比如那些你需要比对手更快地打出卡片或说出答案的游戏。 2、隐藏信息游戏，每个玩家拥有的信息只有自己知晓，而且向对手保密很重要的游戏。 3、贸易、谈判和拍卖游戏，在此类游戏中每个玩家都必须对某件道具出价，不同玩家对物品的价值判断可能并不相同。 对于后面两个，有某些方法可以进行测试，比如将自己的行动限制在当你处在每个玩家的境地下可能采取的做法，这样就可以知道玩家可能有的想法。有些人会觉得这种测试较为 困难。 最简单的解决方案就是，不要使用无法自行测试的机制。另一种方法是在这种情况下增加1或2个玩家进行测试。 让游戏获得发展 经验丰富的设计师往往会说游戏可以“自行成长”，就像游戏自己拥有生命，设计师只是在引导而不是创造。从表面上看，这听起来似乎很奇怪，但是实际上，如果设计师不玩或 改变游戏，游戏也只是待在那里而已。这里在发生什么事呢？ 我想，真正发生的事情就是，游戏的创造是个学习的过程。你或许对游戏如何终结有自己的想法，但是最终版本可能与你最初的愿景有很大的差别。发生这种改变的原因在于，刚 开始你对自己的游戏并不十分了解。你有某些基础想法，但是你并没有真正明白机制的互动形式以及动态和美学的情况。在测试过程中，你对游戏系统的运转方式有更深的了解。 随着你逐渐学习和了解，你就更能够预测改变会对系统产生怎样的影响。 但是，现在你没有这种经验，至少在这款游戏的经验方面仍有所欠缺。自行测试是你的首个发现之举。在你发现的过程中，好似游戏想要往某个新方向发展，好似游戏有自己的生 命。如果你感觉到这一点，那么听从游戏的想法。看看这样的发现会给你带来何种结果。 游戏测试还有另外一面：懂得测试他人的游戏，提供高质量的反馈信息。这本身就是项技能，而且非常罕见。稀缺性令此技能变得弥足珍贵。我们今天的话题是：懂得批判分析设 计师同伴的半成品。 时间交换机制 非数字游戏设计师年度大会Protospiel鼓励参与者腾出尽可能多的测试时间。若原型的体验和讨论需要2个小时，那你就需要4个玩家（游戏邦注：除你自己外），每人平均需投入8 小时；作为此测试的交换条件，你得腾出8小时测试其他人的原型。此机制有效避免出现测试人员匮乏的情况，促使大家互相尊重彼此的时间。 注意这意味着你将投入更多时间测试他人的作品。可以这么说，从时间分配的差异度来看，成为优秀测试者要比设计自己的作品重要。  playtest from gamasutra.com
反复更新内容需消耗他人大量时间，因此要尊重你的测试人员。 若你基于团队运作，携手其他设计师展开游戏测试就相对简单得多，因为这只需要同你的设计师伙伴碰面。记住：你在他人作品中投入的时间要比在自己的作品多。 独立测试之后的操作 在项目此阶段，游戏的可玩模型应已成形，再来就是系列规则。开发者要自己测试至少1次，找出所有显著问题，更新设计。开发者应不断进行调整，直到自己能够完整体验整款游 戏，无需做出较大改变。 到达此阶段后，你的目标就会从“运作内容”转变成“确保核心机制富有趣味”。谁是协助开发者实现此目标的最佳测试人员？ 常规玩家（例如，好友和家人，或者甚至是陌生人）在此的作用非常有限。通过观察他们，你就能够判断他们是否玩得愉快，你的作品是否达到设计目标。但若游戏存在问题，玩 家就无法向你提供有用信息，他们所呈现的反馈无非就是“好极了”或“糟透了”。此时作为设计师的你就需要发现和解决问题。因此，设计师可以在必要时候借助常规玩家，但 他们的作用非常有限。 更好的方式是携手其游戏设计师进行测试。游戏设计师能够让你知晓游戏是否有趣，他们能够就所存在问题及如何调整提供自己的意见。你们随后可以进行精彩讨论，探讨这款游 戏的设计，或是一般游戏设计。这些讨论非常重要，通过他们你的作品能够更快得到完善。 寻找设计师测试者 独立开发者可以在某些地方找到其他游戏设计师。 若你刚好在其他游戏公司任职过，那你定认识某些曾共事过的设计师。在这种情况下，寻找熟练测试者就非常简单。这里的难点是专业设计师通常忙于自己的工作，无法腾出时间 帮你。你需要配合他们的时间。同时要提供某些有价值的东西作为交换。从根本来说，你其实是在寻求专业游戏设计顾问的帮助。你的同事也许有在别处兼职，每小时能挣40-250 美元（游戏邦注：这取决于他们的经验和项目性质）。若他们免费为你腾时间，那么你将来务必也在他们的项目中付出同等的时间。至少你得心存感恩。 如果你不认识任何专业设计师怎么办？联系你的朋友，安排近期碰面，商讨游戏测试。让他们完整体验你的所有作品。  game forum from freelancer.com
若你没什么朋友，最好浏览论坛。论坛底部有个专门的“本地社区”，这样你就能够找到同地区的其他人士。若你尚未注册论坛，那就立即注册（游戏邦注：通过论坛安排折中碰 面地点）。这也许会变成长久专业合作关系。 若你无法从论坛上找到同地区的其他人士，最后一招就是将你的作品发布到网站上，在论坛上征求测试人员。其他设计师也许也面临相同困境。同样，若他人愿意查看你的作品， 提供反馈信息，你也要给予相同反馈，测试他们的作品。当你以此形式测试他人作品时，确保向其说明如何组装可玩模型。以此形式进行游戏测试的最简单方式是单独测试彼此的 作品。另一选择就是网上碰面，即时进行远程体验。 成为杰出设计师 当他人测试你的作品时，请牢记下面几点： * 你的作品并不完美。若游戏非常完美，你就无需进行测试。 * 游戏定存在问题。测试目的是发现和消除这些问题。若你进行测试只是要确定游戏完美无瑕，那你就是浪费自己和他人的时间。 * 通过小型测试发现问题要比在游戏发行后才发现漏洞好很多。 * 若某测试者在你的游戏中发现较大问题，这将是你收获的最好礼物。不要怀有敌意或存在抵制情绪；而是应该心存感激。 * 当测试者发现漏洞时，你的职责不是替游戏辩护或陈述测试者的错误之处。首先，即使测试者“错了”，其他玩家也许也会犯相同“错误”。其次，测试者也许是对的——他们 以全新视角查看你的游戏，通常不会存在什么偏见。 * 若测试者发现问题，正确的做法应是在笔记本中将问题记下，然后同测试者讨论你的目标，这样你就知道如何在坚持目标的前提下做出相应调整。 * 不是所有玩家都表现得体。有时他们会发表某些关于游戏的可憎言论。有时他们会嘲弄你的游戏，或因某设计问题而斥责你。记住无论他们如何表达，这些内容仍是非常有用的 信息。 * 听到“你的游戏糟透了，这是我玩过最糟糕的游戏，或更进一步，你糟透了，你简直就是多余之人”这样的言论，而依然能够真诚地答道：“你帮我发现游戏存在的某些糟糕漏 洞，非常感谢”，这需要设计师境界高深。让自己在现实生活中变成意志坚强之人，能够互相交换角色，应该是游戏设计师的长期目标之一。你无需立即做到这点。我也没做到。 但我之前曾看到某杰出设计师就是以这种姿态和别人相互测试游戏，这令我意识到自己还有很长的路要走。 进行优质的游戏测试 若你希望测试者未来能够继续帮你测试游戏，你就得尽量尊重他们的时间。下面是些你需要考虑的事项： * 在向其他玩家呈现游戏时，确保自己清楚把握规则，这样你无需进行查阅。试着对着镜子向自己解释所有规则，确保自己能够做到这点。这能够节省时间（游戏邦注：这样你只 需花几分钟而非半小时就能将规则解释清楚）。 * 若你已知晓其中存在问题，或若你有除“制作有趣游戏”外的特定游戏目标，预先告知测试者。这将帮助你们更明确地把握潜在解决方案。 * 尽快结束游戏测试。若经过半小时体验你就已收集到所有潜在有用信息，那么就此打住。记住进行测试的目的是发现问题，而不是“体验游戏”。若你无法从中发现问题，那你 就是浪费大家的时间。 * 携带你的测试手册，做好笔记。你很容易忘记当时所发生的情况，不论当时你的测试结果多么明显，所以确保自己记下所有你不想遗漏的信息。 成为杰出测试者 测试他人作品时，有几点需铭记于心： * 进行测试时，保证自己全心对待设计师和游戏。你定也希望他人能够以此态度对待你的游戏。 * 不要在测试中途离开。这除很不礼貌外，还可能让你错过某些结果。至少，若你知道自己时间有限，或中途需要离开，预先告知他人，这样他们就能够采取相应对策。 * 尽可能详尽。不要说游戏“有趣”或“无聊”，试着分析其中原因。此时你需有游戏背景方能给出有意义的反馈信息。充分利用你的设计技能！ * 体验完游戏后，腾出时间同其他测试者和设计师讨论。探讨自己的体验过程及其同游戏机制的关系。 * 记住进行游戏测试的目的很多。查看游戏是否有趣？期望获胜？发现规则存在的漏洞？我们会以相应方式进行体验。我们习惯以自己的风格体验游戏，这令我们容易忘记其实还 有其他体验方式。确保牢记游戏测试的目标。 * 保持有礼貌。你可以犀利批评游戏，但不要对设计师进行人身攻击。 相关拓展阅读：篇目9，篇目10，篇目11，篇目12，篇目13（本文由游戏邦编译，转载请注明来源，或微信咨询zhengjintiao） 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. Course Announcements 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. Mini-Challenge Results 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.) Readings 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. Aristotle 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? McKee 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 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. Scott McCloud 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
dramatic moments. 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. Ernest Adams 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? Lessons Learned 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. Course Announcements 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. Readings 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 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. Branching 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.) Parallel Paths 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. Threaded 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. Camera Views 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. Story Views 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. Interactive Characters 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. Flags 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. Affinity 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. Character Conversations 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). Freytag’s Triangle 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! Lessons Learned 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.) Readings 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. The Process 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). Idea Generation 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. Homeplay 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. Readings There are no readings for today, other than this blog post. Take the time that you would have spend reading, and use it to work on your Design Project. Different Kinds of Playtesting The word “playtesting,” like the word “game,” is overused and can mean different things to different people. In general, the term covers any activity where you are playing a game in progress for the purpose of improving it. But different playtests may have different goals, and it is important to know what your goals are before you do anything. I’ll be playing a bit fast and loose with terminology here, so in this case the concepts are more important than the labels I’m giving them. Bug Testing (or Quality Assurance) The purpose of QA is to find errors in the game’s behavior relative to its design. “Fun” does not enter the equation. If the designer says that the game should do one thing and it actually does another (even if what the game is doing may be superior), that is a bug that needs to be identified. Normally, we think of bug testing as specific to video games. Board games do have a corresponding kind of testing, where the purpose is to find holes in the rules and dead ends in gameplay – gaps in the game that the designer did not cover. Focus Testing In a focus test, you bring together players that are part of the target audience’s demographic in order to determine how well a game serves their needs. This is normally done for marketing purposes, but if game designers are involved it can also help to make the game more enjoyable for that particular demographic. Usability Testing In a usability test, players are given specific tasks to accomplish in an attempt to see whether they understand how to control the game. This is done frequently in the greater software industry to make sure that a piece of software is easy to learn and easy to use. Video games can take advantage of this as well, and results from a usability test can be used to either change the controls or modify the early levels to teach those controls more effectively. In board games, usability is doubly important, because there is no computer to respond to player input for you. If you misunderstand how houses work in Monopoly and place them on Community Chest spaces, the game will not stop you. By observing players who are trying to play your game, you can learn a lot about how to design the various game bits so that they are easy and intuitive to use. Balance Testing A fun game can quickly become boring if some kind of play exploit exists that lets a player bypass most of the interesting choices in the game. If only one strategy can win and it is just a matter of which player follows that strategy the best, it is not as interesting as if there are multiple paths to victory. Likewise, if one player has a clear advantage over the others, it is important to identify that so that players do not feel the game is being unfair. The purpose of this kind of test is to identify imbalances in the game so that the designer can fix them. Fun Testing A game can be usable, balanced and functional and still be uninteresting. That elusive “fun factor” may be hard to design intentionally, but when people are playing the game it is pretty obvious whether they are having fun or not. Certain aspects of the game may be more fun than others, so it is also important to figure out what parts of the game need to stay the same… not just what to change. All of these forms of testing have some elements in common. Best practices are similar if not identical. All are important to the success of a project. So why make a distinction? The reason is that each is appropriate at different stages of completion in a project. Each kind of testing has different goals, and you need to know what your goal is before you can achieve it. Order of Effects When should you do which kind of playtesting? What order do you do them in? A lot depends on your particular project, so some of this will be up to your judgment as the designer. However, there are some rules of thumb. Very early on in the project, you need to make sure your project will meet its design goals (usually the “design goal” is to make a game that’s fun to play). Testing for fun is necessary to make sure you do not spend a lot of time building on the wrong foundation. If you are making a game for a specific market, focus testing may be involved at an early stage as well, simply to ask the target audience if a game with a particular concept sounds interesting to them at all. Once you know that you have something, you need to solidify the mechanics. Design the whole game, making sure that all the details are taken care of. Test for “bugs.” (Note that bug testing in software projects is often done continually throughout the project, increasing in intensity toward the end. Non- digital games are easier to “debug” though, and a “bug” can stop a playtest in its tracks, so it is important for us to have a complete set of rules early in the process.) Once the game is fun and the design is complete, gradually shift from testing for fun to testing for game balance. Make sure that all the numeric values and player abilities are where you want them to be. When the game is working and balanced, towards the end, you’ll want to think more about the usability of the game. When you change usability you are not changing any mechanics, merely the way those mechanics are presented visually to the players. This is an important step that is often neglected. If you’ve ever encountered a game that you could only learn by being taught by another player (as opposed to reading the rules yourself), that is the kind of usability failure you want to avoid in your own projects. You may also do additional focus testing at this time, to make sure that the theme and visual elements of the game appeal to the target audience. As I said, these are just guidelines. If it is incredibly important that your game be well received by a particular demographic, for example, you may be doing focus testing throughout the project at all stages. Do not let this order of things be your master. Different Kinds of Playtesters As there are different kinds of testing, there are also different kinds of testers. Each kind of tester has their own strengths and weaknesses, and some are more important for some kinds of testing than others. Yourself. You are your own most valuable playtester. Do not forget your ability to play your game on your own. You know your game better than anyone. Other game designers. If you are lucky enough to personally know some other skilled game designers, you can get some very useful testing done through them. They are able to critically analyze your game and propose design solutions. (If you do not know any professional designers, perhaps you can at least make contact with other participants of this course.) Close friends, family, and confidantes. People close to you who are willing to provide their time to test your game are very useful. They are approachable and can make themselves available as a favor to you. Take good care of them, and do not abuse their kindness. Note that these people may not fall into any of the other categories, so while they are good for early tests, they may not be appropriate in more focused testing for bugs or balance since they may not know what to look for. Experienced gamers. Skilled game players are great at finding exploits and dominant strategies in a game, and are appropriate for balance testing. Complete strangers. People in your target audience are appropriate for focus testing and usability testing, and they are absolutely critical when testing for fun. Finding them can be tricky, though, because it is not in most of our natures to just walk up to someone we’ve never met and ask them to play a game. We will talk more about this in the coming weeks. Order of Familiarity In general, you will want to go through testers in order from more to less familiar. Test with yourself first, then with close friends, then with acquaintances that are useful (because they are designers, gamers, or part of the target market), and then with strangers. If you show your work to other people too early, it will likely be in such a rough state with multiple design flaws and holes in the rules that it will waste their time and frustrate them, and you want to treat your playtesters better than that. Also, if you start playtesting with strangers too early in the process, you may not get useful feedback – if your game prototype is in a rough state with only crude art and components, for example, the playtesters may be so busy commenting on the poor quality of the pieces that they will not be able to concentrate on the gameplay. At this point you might be tempted to just do all of the playtesting by yourself, so that you don’t need to rely on other people or keep track of them. In practice, the designer eventually gets too close to their own project and is so familiar with the game’s systems that they can miss some really obvious flaws. If you keep the same set of playtesters for long enough, they will suffer from this problem as well. You need to bring in fresh sets of eyes to look at your game on a continuing basis throughout the project. Playing By Yourself In the early part of playtesting, when you are playing the game on your own, here are some things you should be looking for: Does the game meet your design goals? Is it fun, at least for you? While you are not the ideal playtester to judge effectiveness most of the time, if you are not having fun then most other people will probably not either. Are there any holes in the rules? A “hole” is a situation where the rules simply do not say how to proceed. For example, perhaps one of your rules is that a player’s army can attack another player’s army, but you don’t yet have rules for resolving the attack. What happens in this case? In practice, what happens is that the players sit around and wait while the designer figures out what to do! As an example, consider these rules for Tic-Tac-Toe played on a 4×4 grid: Players: 2 Objective: Get a straight line of symbols. Setup: Draw a 4×4 square grid. Progression of play: On your turn, place your symbol (“X” or “O”) on an empty square. Resolution: If either player on their turn has a set of four of their symbol in a straight line (across, down, or diagonally), they win. If you try to play this game just following the rules, you’ll quickly realize that you can’t even start – nowhere does it say which player is X or O, or who takes the first turn! To fix this, you would add a situation to handle this. For example: Setup: Draw a 4×4 square grid. Choose a player to go first, who is assigned the symbol “X”. The other player is given the symbol “O”. Are there any dead ends? A “dead end” is a game state where there is no way to proceed further, but the game is not resolved. Consider our revised 4×4 Tic-Tac-Toe rules above. Suppose that both players fill up all squares on the board without anyone winning. At this point the game cannot proceed, because the rules say a player must place their symbol on an empty square. There is no empty square, so the player cannot take a turn. But there is also no resolution, because neither player has won. In this case, a new rule would have to be added (such as: in the resolution, if neither player can make a legal move and no one has won, then the game ends in a tie). Are any of the rules unclear? It is natural for us to assume things that are in our head, to the point that we often forget to write them down in our rules. Try to look at your rules and see if there is anything you are assuming that your players might not. Are there any really obvious rules exploits? Is there a single strategy that wins the game easily? Try to find it. It’s much less embarrassing if you find and fix it yourself, as opposed to having it discovered by your playtesters (or worse, your players after you release the game). Clarity and exploits are often hard to find in your own game; you tried to design this game to not have any problems, after all. Still, make an honest effort, and sometimes you will be rewarded by finding and fixing errors early (which saves a lot of time in the long run, leaving you more time to iterate on other parts of your design). You might think that looking for exploits is something to do later in the project when balancing the game. Sometimes it is. It is a matter of degree. If an exploit is so powerful and so obvious that it prevents your playtests from giving you real information about your game, fix it now. Solo Test Difficulties There are a few things that are hard to test alone: Realtime multiplayer games, such as games where you must slap a card or say an answer faster than your opponent. Hidden information games, where each player has information that only they know and that is important to keep secret from the opponent. Trading, negotiation, and auction games, where each player must place a value on an item, and different players may value things differently (and especially when players can artificially extort high prices or drive up the cost of an item at auction just to make their opponent pay more). For the latter two, it is possible to play anyway, by simply limiting your actions to what you think you would do if you were in each player’s situation, knowing only what they would reasonably know. Some people find this more difficult than others. The simplest answer here is, for the purposes of this project, to not use mechanics that you can’t test yourself. The alternative is to bring in another player or two early on in this case only, after you take things as far as you can on your own. Let It Grow Experienced designers often talk of a game “making itself” – as if the game has a life of its own, and the designer is merely guiding it rather than creating it. On the surface, this seems strange because really, the game is just sitting there and doing nothing unless the designer is playing it or changing it. What’s going on here? I think that what is really happening is that the creation of a game is a learning process. You may have some idea of where you want your game to end up, but the final version may be very different from what you originally envisioned. The reason why it changes is that at the beginning, you don’t know very much about your game. You have some basic ideas, but you don’t actually know how the mechanics will interact, or what the actual dynamics and aesthetics will be.
As you playtest, you learn more about how your game’s systems are working. As you learn, you become more able to predict the effects that changes will have on the system. Right now, though, you don’t have that experience… at least not with this game. Playtesting on your own is your first act of discovery. As you discover, it may seem as though your game wants to grow in a new direction, as if it has a life of its own. If you feel that, go ahead and listen to your game. See where the process of discovery takes you. 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. Readings 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. Homeplay 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. Feedback 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.
| 
IP卡
狗仔卡
发表于 2015-1-5 22:11:24
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
楼主
