作者：Eric Zimmerman

需求和乐趣

设计是一种发现问题的有效途径。当设计研究贯穿于设计实践中时，它便能够超越任何特殊的设计范围约束而提出更重要的问题。当设计研究与设计过程整合在一起时，我们便能够从设计行为中直接挖掘出一些全新且难以意料到的问题。我将在本篇文章中列举出最近我曾参与的3个游戏项目（游戏邦注：《SISSYFIGHT 2000》，《LOOP》以及《乐高Junkbot》）并阐述迭代设计过程这一研究设计方法论。

我们总是能够在游戏创造过程中获得一定的研究模式。Brenda Laurel在其著作的简介中明确区分了“出于需求”的设计与“出于乐趣”的设计之间的区别。如果从设计的性质来看，游戏设计更倾向于创造有趣的体验而不是为了满足物质需求。尽管我们也能够为了某些特殊目的创造并玩游戏（如为了运动，为了与别人交流或者为了学习一个主题），但是总体看来，我们玩游戏都是看重它的乐趣本质。

作为一种“出于乐趣”的设计，游戏的迭代过程并不是基于外端的变化，而是关于游戏内部及其本身的发展。正是这种特质让我们能够在设计过程中获得最棒的设计研究案例。随着游戏的发展（即通过各种迭代过程），它将重新定义自身的形式以及它所提供的体验。通过游戏设计本身的迭代，我们便能够从中挖掘出更多新的问题。

迭代

迭代设计是基于原型，测试，分析以及完善这一整个循环过程的设计方法论。在迭代设计中，设计系统的迭代是一种传达项目信息并推动项目发展的研究形式，同时也是一种连续版本或者说是设计执行的迭代过程。

测试，分析，完善。并不断重复。因为我们不能预测到观察者/用户/玩家等的游戏体验，所以我们只能够根据不断发展的原型体验而做出迭代过程中的设计决策。测试原型，进行修正，并在此测试游戏项目。通过这一方法，游戏项目将在设计师，设计过程以及测试用户之间的互动中不断发展着。

在游戏中，迭代设计就意味着进行游戏测试。在完成整个设计和开发过程后，人们便可以玩你的游戏了。你可以亲自玩游戏，让团队中的其他成员玩游戏，让办公室的其他人玩游戏，甚至让任何拜访办公室的人玩游戏。你可以根据目标用户组建一个测试小组，并吸引更多人去帮你玩游戏。在不同人的游戏过程中，你可以在旁边进行观察，然后提出问题，根据他们的反应调整你的设计并再次进行测试。

这种设计过程的迭代完全不同于典型的零售游戏开发过程。通常情况下，在电子或掌机游戏设计过程的开始阶段游戏设计师将明确一个完整的理念，并撰写一份详细的设计文件（游戏邦注：尽可能罗列出游戏中的每一个细节）。但是往往地，最终游戏总是会背离设计师最初的构想。而迭代设计过程不仅能够合理罗列出开发所需要的各种资源，同时也能够创造出一个更有活力且非常成功的最终产品。

案例分析1：《SiSSYFiGHT 2000》

摘要：《SiSSYFiGHT 2000》是一款多人在线游戏，玩家能够在游戏中创造一个女学生并为了占领操场而与3至6名玩家进行竞争。在每个回合中玩家都能够从6种行动中做出一个选择，包括戏弄，闲谈，退缩甚至是舔棒棒糖。而玩家行动的结果也将取决于其他玩家所作出的决定——从而创造出一种有序的社交游戏玩法。《SiSSYFiGHT 2000》同时也是一个充满活力的在线游戏社区。我们能够在www.sissyfight.com上玩这款游戏。

1999年夏天，我加入了Word.com并开始帮助他们创造第一款游戏。一开始我们的任务是鉴定项目的游戏价值：这个抽象的理念将在游戏设计中体现出来。我们所创造的游戏价值列表包括面向更广阔的非玩家用户进行设计；设置较低的技术障碍；让玩家能够更容易学习并玩游戏，但同时也不会抛弃游戏的深度和复杂性；游戏玩法具有社交性；最后，所有内容都必须符合Word.com的文化。

这些游戏价值可以说是一系列头脑风暴会议的重要参数，同时也散布着一些电脑游戏和非电脑游戏元素。最终，我们便明确了游戏理念，即一些小女孩在操场上进行社交斗争。考虑到几乎任何一款游戏都具有某种形式的斗争，我们便决定以一种全新的方式去表达这种斗争。技术和制作限制使我们将游戏定义为回合制游戏——尽管游戏中也会参杂即时聊天功能。

当我们逐渐规划出这些形式与概念问题时，我们也发现初始原型开始现出雏形了。我们在纸上写下了《SiSSYFiGHT》的最初版本。我设计了每个玩家能够执行的一些基本行动，同时作为程序员，我还“处理”了每个回合的行动以及游戏如何向玩家传达结果，并将得分记录在一张纸上。

设计第一个原型要求我们以战略思维去思考如何快速执行一个可游戏版本，并以一种合理的方式去处理项目中的主要不确定因素。你是否能够为你的电子游戏创造一个纸上版本？你是否能够设计一个简短版本的游戏并让它在最终版本中持续更长时间？你能否利用少数玩家去测试一款多人游戏的交互模式？

在迭代设计过程中，不管何时你都要仔细思考如何才能够前进到下一个原型。这时候你就必须从一个更大的层面去看待这一问题：更大的概念，技术和设计问题将从整体上推动着项目的发展。确保你的设计不会超越迭代研究。时刻观察测试者所做出的各种评估，留给他们更多自由的游戏空间，通过测试更好地调整你的游戏，并勇于接受那些与自己预期相违背的事实。

项目小组将继续创造纸上原型，并不断追求合作和竞争（将成为最终游戏玩法和核心内容）之间的平衡。我们也将不断完善游戏的基本规则——玩家每个回合所采取的行动以及因此所促成的结果。这些规则将被转化为最初数字原型的细则：基于IRC（游戏邦注：一种通过网络的即时聊天方式）的文本版本，我们将以“热座”的形式面对着同一台电脑轮流玩游戏。尽早构造文本原型，我们便无需过多地担忧执行互动性，图像和视频美感以及其它游戏元素而更好地专注于游戏逻辑的复杂性了。

当我们正通过文本迭代方式测试游戏玩法的同时，我们也开始在Director上进行最终版本的编程工作，并且我们为IRC原型所创造的核心游戏逻辑也将被再次用于Director代码中进行迭代。项目的图像设计师也开始创造游戏的图像语言并绘制出合理的屏幕布局。这些早期的图像草稿（在整个开发过程中将会进行多次修改）将被整合进Director版本的游戏中，且《SISSYFiGHT》作为一款多人在线游戏的初期迭代也逐渐成形——主要受到著名艺术家Henry Darger的界外艺术和复古游戏图像的影响。

当我们完成了网络版本时，整个开发团队将尝试着玩这款游戏。随着我们的游戏不断得到完善，Word.com的其他员工便可以加入游戏的测试行列。当游戏变得更加稳定时，我们在下班时间前往好友所在的网络公司让他们帮我们玩游戏。所有的这些测试和反馈能够帮助我们更好地调整游戏的逻辑，图像美感以及游戏界面。而最终证明我们此时所面临的最大挑战在于玩家行动与游戏结果之间的关系：因为每个回合的结果将取决于每个玩家的行动，如此便导致早期版本的游戏会带给玩家一种挫败感。而只有通过不断地进行修正并与测试者进行各种对话，我们才能确保每个回合的结果能够有效地传达游戏的发展。

当我们完成了游戏服务器的架构时，我们便可以面向那些需要邀请码的测试者社区发布游戏，让他们帮助我们进行公开测试。虽然作为正式测试我们需要明确一定的时间段，但是最终我们也让测试者能够在任何时候上网帮我们测试游戏。除此之外我们也让测试者能够以最简单的方式与我们取得联系，并让他们将漏洞以邮件的方式告知我们。

通过这些小群组测试者的帮助，我们便能够创造出更强大的游戏模式。举个例子来说吧，就像在很多多人游戏中，防御位置总是比进攻更具有优势，如此便很容易导致游戏竞争的停滞不前。为了解决这一问题，我们调整了游戏逻辑而阻止这种失衡的游戏玩法：即让玩家只能在每一行中“退缩”两次，从而降低了防御者的优势。当我们的游戏最终发行时，那些忠实的测试者自然成为了游戏的核心玩家，同时他们也不断鼓励其他新玩家加入这个社交空间。

在《SiSSYFiGHT 2000》案例中，关于测试和原型的迭代设计循环都非常成功，因为我们总是能够在每个阶段清晰地阐明我们想要测试的内容以及测试方法。我们使用了书面和在线问卷调查方式。在每次测试后我们都仔细询问了测试者的想法。我们不仅会仔细思考如何在每个游戏版本中整合图像，视频，游戏设计以及早期版本中的技术元素，同时我们也总是积极地为游戏的最终体验模式铺设基础。

案例分析2：《LOOP》

摘要：《LOOP》是一款单人游戏，玩家将使用鼠标去抓取到处飞行的不同颜色的蝴蝶。玩家必须把相同或不同颜色的蝴蝶抓到圈子中（圈子中的蝴蝶越多，玩家便能够获得越高的分数）。为了完成关卡玩家必须在日落前努力抓取一定数量的蝴蝶。游戏中包含3种不同品种的蝴蝶以及多种害虫——它们都具有不同的作用。《LOOP》是gameLab旗下的作品，我们能够在Shockwave.com找到这款游戏。

最初的原型总是很丑陋。游戏原型不会强调美感或者叙述内容：它们更加强调游戏规则，即与玩家互动相关联的游戏内部逻辑。虽然图像，视频和故事对于游戏来说非常重要，但是游戏设计中的主要不确定因素以及原型应该解决的问题才是更加重要的规则和游戏元素。

明确这一问题的另一种方法是问自己什么是游戏活动？而不是游戏关于什么，玩家在游戏中的不同时刻在做些什么。事实上所有游戏都拥有一个核心机制，玩家将穿梭于游戏设计系统中并反复执行一种或一系列行动。游戏原型将帮助我们理解什么是游戏的核心机制以及怎么做才能让这一行动随着时间的流逝变得有意义。明确游戏的核心机制是什么将引导着你创造第一个游戏原型，并进一步执行一系列迭代。最理想的情况是你能够在最初原型中塑造这一核心机制并开始在游戏过程中进行测试。

之所以会创造《LOOP》这款游戏是因为gameLab希望在游戏中植入一种新的核心机制。一般情况下玩家与电子游戏的互动方式并不多：玩家只能通过鼠标或键盘去传达自己的想法，而游戏则是借由屏幕和扬声器向玩家呈现发展。所以为了进一步干预玩家的输入行为，我们决定抛弃指向-点击或点击-拖曳鼠标互动而利用较为广泛且灵活的手势控制。

第一个原型只能测试这一核心迭代，并允许玩家进行连线。而我们的下一步则是创造一个程序以检测闭合圈子并添加一些新的目标，让这些目标被抓到圈子中时能够自动收缩并消失。

基于不同玩家，每个原型的参数也不同。就像玩家可以决定画线的长度以及曲线的细节，同时也能够明确目标的数量和自己的速度与行为等变量。当我们在玩游戏时总是能够获得一些不同的参数，从中观察到它们是如何影响游戏体验，并进一步调整规则以适应不同的游戏玩法。这一程序方法，即将可行的游戏设计工具整合到游戏原型中是一种包含且能够加速迭代设计的技术策略。以下是一种游戏编辑器代码样本：

– LOOP SCORES
score_same=0,5,10,20,40,80,150,250,350,500,700,1000,1400,1900,2500,3100,380
0,4600,5500,7000
score_different=0,0,30,75,200,500
score_badloop=-20
– # of caught butterflies for each level of loop sound effect
loop_sound_num=1,4,6,8,10
– BONUSES
– butterfly-borne bonus (x2):
bonus_lifetime=60
– leaf-blown bonus (longer, moretime, freeze, flock):
freebonus_speedlimit=15
bonus_freeze_duration=4
bonus_flock_duration=12
– HAZARDS
snail_speedlimit=1.2
killerbee_speedlimit=12, killerbee_attackrate=3,killerbee_stingduration=6
beetle_speedlimit=3, beetle_fighttime=4, beetle_aborttime=10,
beetle_effectradius=300
stinkbug_speedlimit=2, stinkbug_tag_radius=40,
stinkbug_effect_duration=10, stinkbug_effect_radius=300
spider_speedlimit=9, spider_climblimit=22,spider_stingduration=6,spider_loop_length=5

随着蝴蝶的出现，关于游戏总体结构以及胜利和失败情境的争议也相继浮现出来。是否需要为了分布蝴蝶而清空屏幕中的其它内容或者玩家只能抓取一定量的蝴蝶？是应该让蝴蝶慢慢填满屏幕还是始终保持稳定的数量？这里是否存在某种类型的时间压力元素？是否存在一些需要玩家谨慎对待的关卡或者玩家将始终平稳进行游戏直至遭遇失败？这些来自我们核心机制原型的基本问题只能通过我们不断试验并游戏才能最终获得解决。

当我们明确了游戏代码后，我们将在运行的同时使用文本文件中的那些可调节游戏参数。这些参数将控制着包括游戏生物的行为，一个圈子中不同数量的蝴蝶所代表的不同分数以及游戏难度变化等内容。因此，游戏设计师既要关注于完善游戏变量与关卡设计，同时也需要重视其它程序（游戏邦注：包括屏幕转场，帮助功能，高分系统以及发布站点的整合）的建造与维护。

《LOOP》的测试模式与《SiSSYFiGHT》类似，即超越游戏创造者的范围而进一步涵括更加广泛的玩家群体。在开发《LOOP》的过程中gameLab建立了“gameLab Rats”，即我们的官方测试“俱乐部”，希望以此推动游戏的测试过程的发展并接收到更多有益的反馈。《LOOP》最终从一个关于鼠标控制的简单理念变成了我们所预想的灵活互动游戏。

案例分析3：《乐高Junkbot》

摘要：《乐高Junkbot》是一款单人游戏，玩家将帮助机器人Junkbot清理整个工厂中的垃圾桶。玩家并不能直接控制Junkbot，相反地他们只能够使用鼠标去移动屏幕上的乐高砖块并重新构造自己的游戏环境，建造阶梯和桥梁帮助Junkbot前往它想要到达的地方。各种有益及有害的目标和机器人为游戏添加了更多多样性及复杂度，从而为玩家创造出了60个关卡内容。玩家可以使用各种不同的方法去解决Junkbot在关卡中所遇到的问题，并且游戏结构也鼓励玩家回到最初的关卡并使用不同方法去解决问题。

创造《乐高Junkbot》的理念是来自于gameLab的客户端LEGO.com。LEGO想要面向8至12岁男生（但同时也能够赢得成人玩家的喜欢）而创造一款砖块建造类游戏。但是设计问题所面临的挑战是现实世界的乐高游戏已经非常受欢迎了，我们很难再创造出像这种塑料砖块游戏一样的高潮。所以我们便需要考虑如何将乐高游戏植入数字游戏中？

我们首先需要做的便是购买一套乐高砖块并尝试着玩这种游戏，以此分析并理解游戏的微妙设置。然后，与大多数gameLab项目一样，我们将通过识别项目的游戏价值而开始进行设计。这些价值将明确乐高游戏所需要的材料及其体验特性，同时也将揭示乐高游戏原理——包括像模块性，开放式建造，设计创造性，多种解决问题的方法，富于想象的游戏玩法以及工程原理等。将这些价值作为我们的约束参数，我们通过头脑风暴获得了一些重要的游戏理念。

一开始我们所选择的LEGO游戏理念是LEGOman（这时候还未出现Junkbot角色及故事情节），它将通过移动砖块而间接帮助角色在游戏环境中移动。首个游戏原型是关于核心迭代理念的最简单核心迭代理念：玩家可以使用鼠标去拖曳屏幕上的砖块；游戏中只有一个能够自动移动的主角；玩家能够在游戏中碰触到目标旗帜；玩家需要在游戏中避开滚轮。

我们尝试地玩了这个游戏原型，结果发现它一点都不有趣。因为gameLab总是会在不同游戏项目中尝试着创造一些新的游戏玩法，所以我们总是会发现一些初始原型其实一点乐趣都没有。如果是在迭代设计过程的早期阶段发现这一问题，我们便能够果断地抛弃这一设计而重新开始创造一些新内容；从失败的原型中吸取教训；或者我们也可以进一步挖掘失败的原因并做出合理的修改。最终我们选择了最后一种方法，即我们在游戏中添加了不同的元素，完善了游戏迭代，扩展了关卡的可能性，并设置了新的特殊砖块和机器人障碍。

每一个新元素都能够解决早前原型体验的缺陷，如一个接一个移动砖块过于单调，所以我们便通过执行代码让玩家能够堆叠砖块并分组移动。我们需要在屏幕上垂直地移动主角，于是我们便添加了扇形砖块，使得它能够吹动Junkbot向上漂浮。鉴于游戏障碍都过于明确，我们便植入一些能够即时响应Junkbot的机器人障碍。随着这些互动装饰进一步完善了游戏（让游戏变得更加有趣），Junkbot角色及其故事情节也开始慢慢形成了。

在这个过程中我们使用了关卡编辑器——一种能够帮助游戏设计师创造并保存关卡的图像设计工具。这一编辑器让设计师能够试验不同游戏元素和关卡设计，调整游戏体验，并规划下一个原型迭代的功能。

我们继续在gameLab Rats中进行游戏测试。通过网络形式收集并核对关于每个关卡的难度和乐趣的测试数据。而这时候我们真正关心的是目标用户是否能够理解游戏的砖块建造核心机制。于是我们便拜访了一所小学的电脑教室，让学生们尝试着去玩我们的游戏。这一测试非常重要，并也证实了我们的担忧：大多测试者不能理解基本的游戏理念，如如何使用砖块为Junkbot建造一个阶梯。这一次测试直接影响了这款游戏的设计，随后我们降低了游戏的学习曲线，并设计了一些较为易懂的初始关卡。

关于迭代测试的经验法则是我们应该注重观察而不是引导。尽管对于设计师来说很难做到不干涉测试者的鼠标，但是比起告诉测试者如何玩游戏，安静地观察他们的行动能够帮助你设计出更加成功的游戏内容。迭代设计的一部分内容便是学会如何倾听。

结论

迭代设计既是一种基于过程的设计方法论，也是一种设计研究形式。在这三个案例分析中我们可以发现每个设计过程中都会出现一些新的问题，这些问题并不属于初始调查的组成部分，但是我们能够在游戏迭代和设计过程中解决它们。

设计游戏也是在建造一系列规则。但是游戏设计的目的并不是让玩家去体验这些规则——而是让玩家去体验游戏。如此看来游戏设计便存在一个二阶设计问题，即设计师只能间接地通过他们所创造的游戏规则系统去创造游戏内容。游戏源于规则是因为这些规则是玩家所创造的，包括各种行为模式，情感，社交互动以及意义等。如此看来迭代设计过程更加重要。我们很难预先撰写出规则和游戏迭代过程的微妙之处，这就要求我们必须通过测试和建造原型去寻求这种即兴的平衡。

迭代过程原不只适用于游戏领域。规则和游戏只是用于形容结构和体验的游戏设计术语：设计师创造了某种类型的结构（游戏邦注：如一种字型，一个建筑，一辆车等），然后读者，参观者或者乘客将体验它：面对，探索，逗留并操纵系统——使用它，玩它并因此而感到愉快。游戏成为了迭代设计的鲜明例子，但是其它设计领域也同样能够从中获利。

迭代设计中总是会涵括一些设计师，用户，创造者以及玩家。这是一种再创造的设计过程。通过迭代设计，设计师能够创造出一种系统并尝试它。他们也变成了这一过程的参与者，并且他们这么做主要是为了批评自己的创造，分解它并重新完善它。在这些调查和试验的程序中我们能够获得一种特殊的研究形式。贯穿游戏设计的迭代过程能够帮助我们解答那些困惑已久的问题，并因此推动它成为一种非常强大且极其重要的设计研究形式。

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

Play as Research: The Iterative Design Process

Eric Zimmerman

July 8, 2003

Needs and Pleasures

Design is a way to ask questions. Design research, when it occurs through the practice of design itself, is a way to ask larger questions beyond the limited scope of a particular design problem. When design research is integrated into the design process, new and unexpected questions emerge directly from the act of design. This chapter outlines one such research design methodology — the iterative design process — using three recent game projects with which I have been involved (SiSSYFiGHT 2000, LOOP , and LEGO Junkbot).

The creation of games is particularly well-suited to provide a model of research through design. In this book’s introduction, Brenda Laurel makes a distinction between the notion of designing “for needs” and designing “for delight.” {see Laurel , Introduction}While all forms of design partake of both of these categories in some measure, game design is particularly skewed toward the creation of delightful experience, rather then the fulfillment of utilitarian needs. Although it is true that we can create and play games for a particular function (for exercise, to meet people, to learn about a topic), by and large, games are played for the intrinsic pleasures they provide.

As a form of designed “delight,” the process of interacting with a game is not a means to an outside end, but an end in and of itself. It is this curious quality of games that makes them wonderful case studies for design research through the process of design. As a game evolves (through the iterative process outlined below), it defines and redefines its own form and the experiences it can provide for players. Through the iterative play of design itself, entirely new questions can come into being.

Iteration Iteration

Iterative design is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a work in progress. In iterative design, interaction with the designed system is used as a form of research for informing and evolving a project, as successive versions, or iterations of a design are implemented.

{zimmerman.chapter.01}

Test; analyze; refine. And repeat. Because the experience of a viewer/user/player/etc cannot ever be completely predicted, in an iterative process design decisions are based on the experience of the prototype in progress. The prototype is tested, revisions are made, and the project is tested once more. In this way, the project develops through an ongoing dialogue between the designers, the design, and the testing audience.

In the case of games, iterative design means playtesting. Throughout the entire process of design and development, your game is played. You play it. The rest of the development team plays it. Other people in the office play it. People visiting your office play it. You organize groups of testers that match your target audience. You have as many people as possible play the game. In each case, you observe them, ask them questions, then adjust your design and playtest again.

This iterative process of design is radically different than typical retail game development. More often than not, at the start of the design process for a computer or console title, a game designer will think up a finished concept and then write an exhaustive design document that outlines every possible aspect of the game in minute detail. Invariably, the final game never resembles the carefully conceived original. A more iterative design process, on the other hand, will not only streamline development resources, but will also result in a more robust and successful final product.

Case Study 1: SiSSYFiGHT 2000

Summary: SiSSYFiGHT 2000 is a multiplayer online game in which players create a schoolgirl avatar and then vie with 3-6 players for dominance of the playground. Each turn a player selects one of six actions to take, ranging from teasing and tattling to cowering and licking a lolly. The outcome of an action is dependent on other players’ decisions, making for highly social gameplay. SiSSYFiGHT 2000 is also a robust online community. You can play the game at www.sissyfight.com.

In the summer of 1999, I was hired by Word.com to help them create their first game. We initially worked to identify the project’s play values: the abstract principles that the game design would embody. The list of play values we created included designing for a broad audience of non-gamers; a low technology barrier; a game that was easy to learn and play but deep and complex; gameplay that was intrinsically social; and finally, something that was in line with the smart and ironic Word.com sensibility.

These play values were the parameters for a series of brainstorming sessions, interspersed with group play of computer and non-computer games. Eventually, a game concept emerged: little girls in social conflict on a playground. While every game embodies some kind of conflict, we were drawn towards modeling a conflict that we hadn’t seen depicted previously in a game. Technology and production limitations meant that the game would be turn-based, although it could involve real-time chat.

Once these basic formal and conceptual questions had begun to be mapped out, the shape of the initial prototype became clear. The very first version of SiSSYFiGHT was played with post-it-notes around a conference table. I designed a handful of basic actions each player could take, and acting as the program, I “processed” the actions each turn and reported the results back to the players, keeping score on a piece of paper.

Designing a first prototype requires strategic thinking about how to most quickly implement a playable version that can begin to address the project’s chief uncertainties in a meaningful way. Can you create a paper version of your digital game? Can you design a short version of a game that will last much longer in its final form? Can you test the interaction pattern of a massively multiplayer game with just a handful of players?

In the iterative design process, the most detailed thinking you need at any moment is that which will get you to your next prototype. It is, of course, important to understand the big picture as well: the larger conceptual, technical, and design questions that drive the project as a whole. Just be sure not to let your design get ahead of your iterative research. Keep your eye on the prize, but leave room for play in your design, for the potential to change as you learn from your playtesting, accepting the fact that some of your assumptions will undoubtedly be wrong.

The project team continued to develop the paper prototype, seeking the balance between cooperation and competition that would become the heart of the final gameplay. We refined the base ruleset — the actions a player can take each turn and the outcomes that result. These rules were turned into a spec for the first digital prototype: a text-only version on IRC, which we played hotseat-style, taking turns sitting at the same computer. Constructing that early, text-only prototype allowed us to focus on the complexities of the game logic without worrying about implementing interactivity, visual and audio aesthetics, and other aspects of the game.

While we tested gameplay via the text-only iteration, programming for the final version began in Director, and the core game logic we had developed for the IRC prototype was recycled into the Director code with little alteration. Parallel to the game design, the project’s visual designers had begun to develop the graphic language of the game and chart out possible screen layouts. These early drafts of the visuals (revised many times over the course of the entire development) were dropped into the Director version of the game, and the first rough-hewn iteration of SiSSYFiGHT as a multiplayer online game took shape, inspired by Henry Darger’s outsider art and retro game graphics.

{zimmerman.chapter.02}

As soon as the web version was playable, the development team played it. And as our ugly duckling grew more refined, the rest of the Word.com staff were roped into testing as well. As the game grew more stable, we descended on our friends’ dot-com companies after the workday had ended, sitting them down cold in front of the game and letting them play. All of this testing and feedback helped us refine the game logic, visual aesthetics, and interface. The biggest challenge turned out to be clearly articulating the relationship between player action and game outcome: because the results of every turn are interdependent on each player’s actions, early versions of the game felt frustratingly arbitrary. Only through many design revisions and dialogue with our testers did we manage to structure the results of each turn to unambiguously communicate what had happened that round and why.

When the server infrastructure was completed, we launched the game to an invite-only beta-tester community that slowly grew in the weeks leading up to public release. Certain time slots were scheduled as official testing events, but our beta users could come online anytime and play. We made it very easy for the beta testers to contact us and email in bug reports.

Even with this small sample of a few dozen participants, larger play patterns emerged. For example, as with many multiplayer games, it was highly advantageous to play defensively, leading to standstill matches. In response, we tweaked the game logic to discourage this play style: any player that “cowered” twice in a row was penalized for acting like a chicken! When the game did launch, our loyal beta testers became the core of the game community, easing new players into the game’s social space.

{zimmerman.chapter.03}

{zimmerman.chapter.04}

{zimmerman.chapter.05}

In the case of SiSSYFiGHT 2000, the testing and prototyping cycle of iterative design was successful because at each stage, we clarified exactly what we wanted to test and how. We used written and online questionnaires. We debriefed after each testing session. And we strategized about how each version of the game would incorporate the visual, audio, game design, and technical elements of the previous versions, while also laying a foundation for the final form of the experience.

Case Study 2: LOOP

Summary: LOOP is a singleplayer game in which the player uses the mouse to catch flittering, colored butterflies. The player draws loops around groups of butterflies of the same color, or of groups in which each butterfly is a different color (the more butterflies in a loop, the more points). To finish a level, the player must capture a certain number of butterflies before the sun sets. The game includes three species of butterflies and a variety of hazardous bugs, all with different behaviors. LOOP was created by gameLab and is available for play at Shockwave.com.

Initial prototypes are usually quite ugly. Game prototypes do not emphasize aesthetics or narrative content: they emphasize the game rules, which manifest as the internal logic of the game, tied to the player’s interaction. Visuals, audio, and story are important aspects of a game, but the core uncertainties of game design, the questions that a prototype should address, lie in the more fundamental elements of rules and play.

Another way of framing this problem is to ask, What is the activity of the game? Rather than asking what the game is about, ask what the player is actually doing from moment to moment as they play. Virtually all games have a core mechanic, an action or set of actions that players will repeat over and over as they move through the designed system of a game. The prototype should help you understand what this core mechanic is and how the activity becomes meaningful over time. Asking questions about your game’s core mechanic can guide the creation of your first prototype, as well as successive iterations. Ideally, initial prototypes model this core mechanic and begin to test it through play.

LOOP grew out of a desire at gameLab to invent a new core mechanic. There are ultimately not very many ways to interact with a computer game: the player can express herself through the mouse and keyboard, and the game can express itself through the screen and speakers. Deciding to intervene on the level of player input, we had a notion to cast aside point-and-click or click-and-drag mouse interaction in favor of sweeping, fluid gestures.

The first prototype tested only this core interaction, allowing the player to draw lines, but nothing else. Our next step was to have the program detect a closed loop and add objects that would shrink and disappear when caught in a loop.

{zimmerman.chapter.06}

{zimmerman.chapter.07}

{zimmerman.chapter.08}

Each of these prototypes had parameters adjustable by the person playing the game. The length of line and detail on the curve could be tweaked, as well as the number of objects, their speed and behavior, and several other variables. As we played the game, we could try out different parameters and immediately see how they affected the experience, adjusting the rules to arrive at a different sort of play. This programming approach, building accessible game design tools into a game prototype, is a technical strategy that incorporates and facilitates iterative design. A sample of the game editor code follows:

– LOOP SCORES
score_same=0,5,10,20,40,80,150,250,350,500,700,1000,1400,1900,2500,3100,380
0,4600,5500,7000
score_different=0,0,30,75,200,500
score_badloop=-20
– # of caught butterflies for each level of loop sound effect
loop_sound_num=1,4,6,8,10
– BONUSES
– butterfly-borne bonus (x2):
bonus_lifetime=60
– leaf-blown bonus (longer, moretime, freeze, flock):
freebonus_speedlimit=15
bonus_freeze_duration=4
bonus_flock_duration=12
– HAZARDS
snail_speedlimit=1.2
killerbee_speedlimit=12, killerbee_attackrate=3,killerbee_stingduration=6
beetle_speedlimit=3, beetle_fighttime=4, beetle_aborttime=10,
beetle_effectradius=300
stinkbug_speedlimit=2, stinkbug_tag_radius=40,
stinkbug_effect_duration=10, stinkbug_effect_radius=300
spider_speedlimit=9, spider_climblimit=22,spider_stingduration=6,spider_loop_length=5

As the butterfly content of the game emerged, so did debate about the game’s overall structure and victory and loss conditions. Did the entire screen need to be cleared of butterflies or did the player just have to catch a certain number of them? Did the butterflies gradually fill up the screen or did their number remain constant? Was there some kind of time-pressure element? Were there discreet levels or did the game just go on until the loss conditions were met? These fundamental questions, which grew out of our core mechanic prototyping, were only answered by actually trying out possibilities and coming to conclusions through play.

As the game code solidified, the many adjustable parameters of the game were placed in a text file that was read into the application when it ran. These parameters controlled everything from the behavior of game creatures to points scored for different numbers of butterflies in a loop to the progression of the game’s escalating difficulty. Thus the game designers could focus on refining game variables and designing levels, while the rest of the program — screen transitions and help functionality, the high score system and integration with the host site — was under construction.

{zimmerman.chapter.09}

{zimmerman.chapter.10}

{zimmerman.chapter.11}

LOOP followed a testing pattern similar to that of SiSSYFiGHT, moving outward from the game creators to include a larger circle of players. During the development of LOOP , gameLab created the gameLab Rats, our official playtesting “club,” to facilitate the process of testing and feedback. In the end, LOOP managed to achieve the fluid interaction we had first envisioned, an entire game evolving from a simple idea about mouse control. That is the power of iterative design.

Case Study 3: LEGO Junkbot

Summary: LEGO Junkbot is a singleplayer game in which the player helps the robot character Junkbot empty trash cans throughout a factory. The player doesn’t control Junkbot directly but instead uses the mouse to move LEGO bricks around the screen, deconstructing and reconstructing his environment brick by brick, building stairways and bridges that help Junkbot get where he needs to go. A variety of helpful and hazardous objects and robots add variety and complication to the game’s 60 levels. Junkbot levels can be solved in multiple ways and the game structure encourages players to go back to previously solved levels and complete them using a different method.

The conceptual starting point for the creation of LEGO Junkbot came from gameLab’s client, LEGO.com. LEGO wanted a game about brick construction with a target audience of 8-12 year-old boys that that could also be played and enjoyed by adults. The challenge of the design problem was that real-world LEGO play was the referent. Yet in no way could we ever hope to recreate the sublime interactivity of plastic LEGO bricks. How could we translate LEGO play into a digital game?

Our first step was to purchase and play with a whole mess of LEGO bricks, as a way of analyzing and understanding their subtleties. Then, as with most gameLab projects, we began to design by identifying the project’s play values. These values, which embodied the material and experiential qualities of LEGO as well as the cultural ethos of the LEGO play philosophy, included concepts like modularity, open-ended construction, design creativity, multiple-solution problem-solving, imaginative play, and engineering. Using these play values as our limiting parameters, we brainstormed a number of game concepts.

The concept LEGO selected was called LEGOman (the character and storyline of Junkbot had not yet emerged) and it centered around moving bricks to indirectly help a character move through an environment. The first playable prototype was the simplest possible iteration of the core interactive idea: the player could use the mouse to drag bricks on the screen; there was a single, autonomously-moving protagonist character; there were goal flags to touch; and there were rolling wheel hazards to avoid.

{zimmerman.chapter.12}

{zimmerman.chapter.13}

We played that first prototype. And it was not very fun. Because gameLab projects often try to invent new forms of gameplay, we sometimes find that our initial prototypes are just not that enjoyable to play. At such an early juncture in the iterative design process, we could have scrapped the design altogether and started fresh, building on insights learned from the unsuccessful prototype, or we could dig in and push on through. We chose the latter. Gradually we added elements to the game, refining the interaction, expanding the level possibilities, putting in new kinds of special bricks and robot hazards.

Each new element addressed something that was lacking in the experience of the previous prototype: it was monotonous to move bricks one by one, so we implemented code that let players stack bricks and move them as a group. We needed a way to move the main character vertically on the screen, so we added fan bricks, which float Junkbot upwards. The game obstacles all felt too deterministic, so we introduced robot hazards that responded to Junkbot in real time. And as these interactive embellishments deepened the game (which was actually becoming fun to play), the character and storyline of Junkbot emerged.

Throughout the process, we utilized a level editor, a visual design tool that let the game designers create and save levels. The editor allowed them to experiment with game elements and level designs, refining the overall experience and planning features for the next iteration of the prototype.

{zimmerman.chapter.14}

Playtesting continued with the gameLab Rats, using a web-based form to collect and collate testing data about the difficulty and enjoyment of each level. However, our main concern was whether the basic brick-construction core mechanic would be understood by our target audience, so we visited an elementary school computer classroom, sat kids down in front of the game, and let them play cold. This testing was invaluable, and confirmed our fears: too many of the testers had trouble picking up basic game concepts, such as how to make a stairway for Junkbot out of bricks. This testing directly influenced the design of the game, and we slowed down the overall learning curve, designing the first several game levels to more clearly communicate the essential interactive ideas.

{zimmerman.chapter.15}

{zimmerman.chapter.16}

{zimmerman.chapter.17}

A good rule of thumb for iterative testing is to err on the side of observation rather than guidance. While it may be difficult to keep your hands off the tester’s mouse, instead sit back and see what your audience actually does, rather than telling them how it is supposed to work. What you observe can sometimes be painful to watch, but it will help you design more successful play. Part of iterative design is simply learning how to listen.

Conclusions

Iterative design is a process-based design methodology, but it is also a form of design research. In each of these three case studies, new questions emerged out of the very process of design, questions that were not part of the initial investigation but were nevertheless addressed through iterative play and design.

To design a game is to construct a set of rules. But the point of game design is not to have players experience rules — it is to have players experience play. Game design is therefore a second-order design problem, in which designers craft play, but only indirectly, through the systems of rules that game designers create. Play arises out of the rules as they are inhabited and enacted by players, creating emergent patterns of behavior, sensation, social exchange, and meaning. Thus the necessity of the iterative design process. The delicate interaction of rule and play is something too subtle and too complex to script out in advance, requiring the improvisational balancing that only testing and prototyping can provide.

The principles of the iterative process are clearly applicable beyond the limited domain of games. Rules and play are just game design terms for structure and experience: a designer creates some kind of structure (a typeface, a building, a car), and a reader, visitor, or car passenger experiences it: encountering, exploring, dwelling in, and manipulating the system — using it, playing with it, delighting in it. Games provide particularly clear examples of iterative design, but any design field can benefit from such an approach.

In iterative design, there is a blending of designer and user, of creator and player. It is a process of design through the reinvention of play. Through iterative design, designers create systems and play with them. They become participants, but do so in order to critique their creations, to bend them, break them, and re-fashion them into something new. And in these procedures of investigation and experimentation, a special form of research takes place. The process of iteration, of design through play, is a way of discovering the answers to questions you didn’t even know were there. And that makes it a powerful and important form of design research.(source:ericzimmerman)