成功与失败 老外分享游戏迭代开发经验

在这篇文章中，我将讨论一种可在小型独特项目中反复使用的游戏创造方法，并描述我们的工作室Mobile Pie在使用这种方法设计iPhone和iPod touch游戏《B-Boy Brawl: Breakin’ Fingers》过程中遇到的成功与失败。

我会讨论我们最初基于传统线性电子游戏设计的方法及其演变过程，失败让我们看清了遇到的问题，知道如何制造出有趣且功能齐全的核心游戏机制，并将这个过程成功应用于其他游戏的开发中。

在讨论电子游戏设计时，我将用上Ian Bogost的单元操作理论，这个理论指出，电子游戏由营造表达某种意图的整体系统的单元操作构建而成。我们可以做出如下假设，我们用于构建完整系统或电子游戏的方法必须以彻底理解这些单元操作如何互相产生作用以实现预想结果为前提。

当然，将现有系统解构并重新构建较为容易也更为便捷。然而，如果我们想要构建与现有系统不尽相同的全新系统，那么我们就必须选择能够相互配合营造预想目标的正确的单元操作（注：以及设计元素），但是这些选择有一定的技巧并且有时并不符合逻辑性。

我建议，开发者必须通过重复性开发过程来创造、测试和润色独特的系统，观察系统的反馈，分离那些有碍于预想目标的元素，将它们替代成那些更为适合的元素，重复这个过程直到实现令人满意的结局。

以上推荐的过程似乎已为许多老练的电子游戏设计从业者所熟知，尤其是那些经验丰富的Agile方法使用者。但是，本篇文章将着重通过总结我们自身项目中的成功和失败来得出每个阶段的最佳做法和不同项目间方法使用的差别。

迭代开发的背景

长久以来，数字化内容传播都被认为能够将行业从巨额经费和实体零售瓶颈中解救出来。尽管游戏概念和开发硬件限制可能阻碍到某些开发行为，但PC和苹果App Store二者都能够让小型开发团队自由开发商业化的独特游戏，涌现出类似于《Zen Bound》和《World of Goo》的有趣游戏体验以及成千上万个失败作品。

随着电子游戏生产成本增长并且收益逐渐减少，所有新游戏的开发都会面临更大的金融风险。为使游戏市场规范发展，发行商和工作室已经很少再为不知是否有效的设计元素开绿灯。开发者的关注点从设计的创新性转变为注重游戏收益，这种做法正逐渐侵蚀电子游戏体验并且会影响用户对游戏的信心。

巨额预算和微薄利润也带来了一种严格的微管理文化，主要体现在紧凑的项目开发日程安排，以及对“计划性设计”方式的高度依赖，它将市场营销意图和风险规避设计手法融为一体，使游戏创意性与商业性合二为一。

虽然大型游戏发行公司可能更喜欢采取上述方式，小型独立开发商却因发布某些吸引眼球但与商业化游戏差异过大的游戏而损失惨重。

这些失败部分归咎于开发方法，业界过于信赖大型工作室的产品开发思想体系。依我在Mobile Pie的经验来看，将优秀的游戏想法在设计初期便交由小型团队负责会让他们处于危险的境地，因为时间安排会让游戏的质量大打折扣。

#p#

开发的演变

迭代设计开发方法起源于创造《B-Boy Brawl: Breaking Fingers》的设计过程。

《B-Boy Brawl》的灵感来源于一系列YouTube上的视频，视频中的人们把手指当做手臂和腿，在一块小区域再现霹雳舞般的动作。视频最初的目标在于教人们如何重现动作，但是当我们讨论起这个概念时，我们形成了一个目标，并催生出了一款游戏。

通过这些早期的讨论，我们决定游戏要保持某些非常独特的设计想法：

1、传授移动方式。用户可以用来学习并记住每个独特的移动方式。

2、炫丽的游戏玩法。游戏让非游戏玩家看起来很有趣。

3、易用性。用户可以简单地学会游戏，无需过多的指导。

4、可适应性。允许用户自由地以不同的方法来做出相同的移动。

这些想法并没有记录下来，但是已经成为游戏项目不可改变的必要元素。我们在执行项目的开发中，这些想法限制了游戏的设计，但我们在无意间修改了设计以及开发手段。

在开发过程中，我发现这些想法中某些内容与其他想法有直接的冲突。从表面上来看，我们或许会发现易用性正与用户需要学习移动方式之间有所冲突。而且，以上两个想法和可适应性有着更深层次的冲突。某个相对合适的机制似乎能提高游戏的易用性，但在测试中我们发现与之相左的方法反而更好。

#p#

预想的模型

最早我规划了两个游戏原型的概念：其一以按键来显示用户手指应该放置的位置并以逐渐减少的圆圈来显示时间；其二用HUD来显示节拍以及当前、过去和即将到来的移动。

在这两个原型的基础上，我们猜想用户会如何同这两种方式互动。我们考虑到在游戏中添加按键的方法会让游戏显得约定俗成且单调，这会破坏炫丽游戏玩法和可适应性这两个想法。

但是，更为重要的是我们没有考虑以下问题：在向用户传播所需信息方面，这两种方法的有效性如何以及用户将会如何解读这些信息。我们只顾着考虑用户想要的东西，而忽视了用户可以使用的东西。

#p#

《B-Boy Brawl》早期的样式

我们通过讨论和文件撰写来修改设计想法，最终构建了游戏的最初原型，现有的两个条状物方向不同，一个显示的是节拍，另一个显示移动。玩过游戏原型之后，开发团队对他们的劳动成果感到非常高兴。游戏像我们预想和计划的那样发展，当时我们能够断言，尽管游戏还略显粗糙，但是人们会喜欢这款游戏。

我们马上将原型提交给我们的同行，以听取他们的意见。我们知道游戏并不完美，但是肯定不会很差。看到游戏测试结果，我们感到很震惊。在这个阶段，有些人能够理解游戏机制并乐在其中，但有些用户甚至都不能明白游戏基本架构，两类用户的反应差距悬殊。

公司团队负责设计和执行整个系统，因而能够理解游戏的各项功能和机制、信息呈现的方式和形式、所呈现信息的内容，以及如何理解信息以做出正确的动作并获得丰富的体验。

我们从测试用户处获得各种反馈，有些用户的意见还会有一定的冲突。有些人对游戏大加抱怨，因为他们无法理解游戏玩法。还有些人声称，应该制定教程，音乐拍子应该慢些，失败的条件应该更宽松些，而且他们不知道下一步要把手指放在何处，拍子应该显得更为形象化。

#p#

“润色”后的游戏

我们收集众人的反馈，包括他们口头阐述的反馈和我们从他们的游戏过程中观察到的内容。我们构建起全新的原型，再次将上述想法融入其中，让新用户来体验并收集更多的可用反馈，不断重复这个过程直到我们拥有精致的原型。完成这个过程后，多数用户都能够在教程的辅助下明白游戏机制。

现在回想起来，这个成功也预示着更大的失败，在这些设计润色的过程中，我们通过削弱某些内容来提高游戏的可用性。随后，又有针对屏幕图像的反馈意见，声称这会让用户感到眼花缭乱。我们没有让游戏变得更具易用性，反倒使它变得更为复杂。

我们将游戏提供给发行商或其他愿意与我们合作解决营销和认证问题的人，我们发现在此等情况下游戏完全不具有易用性，我们创造出了个复杂的系统，只有通过超长的教程才能够解释清楚。

#p#

设计方案的最终版本

意识到这个问题后，我们召开会议讨论项目未来的发展。在一个小时的时间里，我们就发现了问题的根源所在并制定出了解决方案。我们曲解了测试用户的反馈，解决的只是游戏所存在问题的表象而不是原因。用户想要的东西（注：即某些细微的改变）和他们真正需要的东西（注：更容易理解的核心机制）是完全不同的东西。

解决方案很简单，即重新根据基于按键的原型来构建游戏，摒弃我们自己强加在游戏上的设计限制，也就是那些设计想法。

按键系统通过已经确立的按键图解来向玩家传达所需的动作，即按动或触摸。同时，利用封闭式的圆圈来显示时间。这些元素是让电子游戏和用户间产生预想互动的关键元素。

现在，用户已经不需要学习他们在游戏中用到的移动，核心机制让玩家跟随游戏节奏即可。这种做法弱化了游戏体验对旁观者的影响，却大大提升了产品的易用性和用户获得的游戏趣味性。

我们使用新引擎从头开始创建全新的原型，尽量避免之前犯下的错误。现在，我们不将想法强加在产品之上，而是构建、测试、解释上述解决方案，不断测试和重新构建，根据用户的反馈来进行游戏设计。

通过测试找到问题所在后，我们提出了一个解决方案并使用问题追踪软件进行记录。随后，我们将这种方法用于新的架构中，并对其进行测试。

在原型开发过程中，这个方案不断演变并且变得更为精致，随后便用来构建和改善内容，产生极具趣味性且易用性良好的产品。

对这些过程的理解使我细致分析了开发过程的行为，将它们进行分解并组织成设计方法，使得其他人也可以将优秀的想法在有限的预算和时间框架内转别成优良的游戏体验。

#p#

迭代设计开发方法的成型

这是种有着更为完整、精致并包容所有过程的框架，来源于Mobile Pie成员的经验和工作方法，并结合了Agile方法论。但是，不可将其视为电子游戏设计的权威方法。

这种设计很大程度上由产品本身推动，而不是使产品受到限制。因而，设计师的目标会更为明确。这种独特的效果使得这种方法适宜小团队，如精品独立工作室或学生团队，在毫无外界压力的情况下，他们可以在短期内制造出产品。

下图显示迭代设计开发的各个阶段的流程。

该过程起始是独特的高层次概念，随后团队成员进行讨论，罗列出原型中的功能。然后团队密切配合制作出最初的原型，最好能够使用游戏目标平台上的目标技术。

我建议不必过于拘泥于开发文件，团队成员间的口头交流能够更迅速地构建起原型，当然，这取决于团队成员的投入程度、可信度和民主作风。

一旦最初的原型确立，迭代设计过程就可以进入“原型调整阶段”。该阶段的每个循环都可以视为类似SCRUM Sprint的方法。

该阶段的测试过程和反馈的提炼是创造有效迭代的关键。你可以选择将玩家分组测试产品，也可以选择将游戏提供给同龄人或其他你偶遇的人进行测试。

重点在于，脑中不要有明确的精致度量，你应该观察用户及其行为以及他们所说的话。这是因为度量会让你对系统的功能问题产生预设的想法，但依我的经验来看，你作为系统的构建者，根本不可能预测到系统中的哪些元素会产生阻碍作用。

对测试中所得反馈的理解是种很高深的技能，其内容足以再写一篇文章来阐述。但是从常识上来看，倾听的能力以及对电子游戏功能的理解是非常宝贵的技能。

一旦整个团队同意原型能够发挥其功能时，就必须考虑设计和添加额外的内容了。这个阶段时间的长短和复杂性取决于项目的类别。

内容设计并执行之后，便进入了“内容调整阶段”。根据项目类型的差异，这个阶段与“原型调整阶段”相比时间可能较长也可能较短，但是所使用的原则与上述相同，即考察内容在核心机制下的功能如何。除非确为必要之举，否则不要对游戏玩法做过多的改变。

这个阶段过后，产品就处于可供测试的状态，应该进行QA来修补漏洞，随后就可以发布了。

#p#

迭代设计过程中的项目管理

这个方法可用于开发高质量游戏，但是由于其独特的效能，如果能够对项目进行恰当的管理，开发时间和成本都可以得到控制。

使用这种方法的风险在于，每个调整阶段所需的时间不确定。调整阶段的每个循环所耗费的时长并不确定，而且迭代的次数也没有限定。

但是，为对产品开发的时间和成本进行控制，就必须在项目开始前商定循环的次数和时间。

但是，包括内容开发等其他阶段都可以使用传统的模式进行控制。通过严格设定每个迭代阶段的时间框架，项目主管可以牢牢把控项目的整体开发时间和成本。

迭代开发过程的适用范围和适用性

尽管这种方法的目标用户是开发独特电子游戏的小型团队，但也可以用来提升大型主流电子游戏的体验的质量。在较为大型的项目中，重点可能会有所改变，可能应该更加关注内容。

这种方法还可以被小型团队用来创造大型项目游戏概念的样本，他们可以从内容迭代阶段的测试中获得反馈，改善未来内容的设计。

这种方法也可能用来改善多种产品的质量，但是需要根据团队的类型和预想的结果进行些许改变。

结论

迭代设计开发可以让小型但富有天赋的团队找到正确的方法，以开发出独特且富有创意的产品。

在开发循环中，它有着相对较大的自由度和灵活性。它还鼓励团队成员间在项目开始之处便开展合作，这意味着团队成为整体，而不是成员独立完成各个人物。

这个过程在Mobile Pie开发大量产品的过程中得到调整，还包含了学术性的设计理论和Agile项目管理理论。

我希望这种方法能够对那些与我们情况相似的开发商有所帮助，他们可以调整并讨论游戏内容，使这种方法进一步演变成为更有效的游戏开发方法。