游戏设计的艺术：一本透镜的书——第七章 游戏通过迭代改良
转自天之虹的博客：http://blog.sina.com.cn/jackiechueng
感谢天之虹的无私奉献
Word版可到本人的资源中下载
第七章 游戏通过迭代改良
选择一个创意
当进行完一次苦中作乐的头脑风暴会议后，在你面前就有了一份极长的创意清单了。这时往往是很多设计师栽倒的地方。他们有着太多想要的创意，却不确定该挑选哪些。或者是他们有着很多普普通通的创意，但没有哪个是吸引人的，这也使得他们不确定该挑哪个。于是他们就在这个问题上困惑很久，在优柔寡断中含含糊糊不清不楚，期盼着只要他们多等一会，“对头的创意”就会突然变得清晰起来。
但其实当你挑选出一个创意并决定把它做出来时，一些魔法般的事情就会随之发生了。正如Steinbeck在《Mice and Men》中所说的，“计划才是真实存在的东西”。一旦你做出了内部决定说“没错，我就要做这个”的时候，你之前漏掉的缺点和好处都会突然变得明显起来。这就像翻一枚硬币来做决定那样——当硬币掉下来时，你会突然知道什么才是你真正想要的。在我们决定之前和决定之后，有某些东西在我们内心里促使我们以不同的方式去思考。因此，好好利用人类天性的这种怪癖，对你的设计做出突然的决定，承诺坚持这个决定，然后马上开始思考你所作出的这个选择的一系列后果。
但假如当你靠这种突然决定来让你明白到你做出了一个错误的选择，那该怎么办呢？答案是很简单的：当你意识到这是错误的时候，准备好把它推翻重来就好了。很多人觉得这样很困难——当他们做出一个设计决策时，他们要放弃它是很不舒服的。对你来说，你是不能承担这种多愁善感的。创意不像好的瓷器，它们只是像纸杯那样——制造出来是很便宜的，当其中一个上面有破洞时，那就换另一个好了。
有的人对这种仓猝决定然后再突然反悔的做法感到相当不安。但这是完全利用你决策制定的力量的最有效的方法，而游戏设计完全是一个决策制定的过程——你需要尽可能快地做出尽可能是最好的决策，而这种有点古怪的行为正是达成这点的方法。越快定下一个创意比推到以后再去决定总是更好的，如此你能快得多地得到一个好的决定，而不是在那边吞噬着你的时间地不断考虑各种潜在的替代方案。只要别对你的决定产生感情，随时准备好在它不合用的时候推倒重来就好了。
那如何挑选出这个创意呢？从某种程度上说，答案是“最好靠猜”。如果希望更具分析策略一点的话，那你需要在培育一个种子创意时考虑到众多的因素。值得切记的一点是，在你选择一个种子创意之前，你应该先考虑这个创意要变成怎么样。
八个滤镜
你最终成型的设计最终必须要通过八道考验及或者说是八个滤镜。只有当它通过了所有滤镜后，这个设计才是“足够好的”。无论何时，一旦它通不过某个考验，那你就必须修改这个设计，然后重新再跑一次所有的八个滤镜了，因为修改会让它能通过某个滤镜，但同时也使得它通不过另一个滤镜。从某种意义上说，设计过程主要是由陈述问题、得到一个初始的创意，以及找一种方法来让它通过所有八个滤镜这三部分组成的。
这八个滤镜是：
滤镜#1：美感上的剌激：这是所有滤镜中最针对个人的一个。作为设计师，你要问一下自己这个游戏是否让你“感觉对头”，假如的确对头，那它就通过这道考验了。假如感觉不对头，那就需要修改某些东西。你内在的感受是很重要的。这些感受不一定总是对的，但其他的滤镜会帮你把一切平衡过来。
关键问题：“这个游戏感觉对头吗？”
滤镜#2：受众的统计数据：你的游戏是有着看目标受众的。他们可能是一个年龄区间，或者某种性别，又或者是某类与众不同的受众（例如“高尔夫球的狂热者”）。你必须考虑这份设计是否符合你瞄准的受众的各种统计数据。受众的统计一会在第8章进行更详细地讨论。
关键问题：“目标受众会足够喜欢这个游戏吗？”
滤镜#3：体验设计：在应用这个滤镜时，把你所知道的能用来创造一种出色的体验的所有东西都考虑进去，包括美感、兴趣曲线、共鸣的主题、游戏平衡，以及其他更多的东西。这本书里很多透镜都是关于体验设计的——当通过这重滤镜后，你的游戏一定是经得起众多透镜的考验了。
关键问题：“这是一个良好设计的游戏吗？”
滤镜#4：创新：假如你在设计一个新游戏，那明显需要在游戏里有一些新的东西，一些玩家从来没见过的东西。你的游戏是否新颖是一个主观的问题，但也是一个非常重要的问题。
关键问题：“这个游戏足够新颖吗？”
滤镜#5：商业和市场营销：游戏行业始终是一门商业，那些想把游戏卖出去的设计师必须考虑到这点事实，然后把商业整合到游戏设计里面。这引申出很多问题。例如，主题和故事会吸引消费者吗？游戏容易解释，以致于能通过看包装盒就能理解这是一个什么游戏吗？消费者基于这个类型会希望这个游戏里有什么样的特点？这个游戏中各种特性和市场上同类游戏相比如何呢？这个游戏的制作成本会不会大到使得它赚不到钱？零售商会愿意销售这个游戏吗？对这些问题以及其他类似问题的答案会影响到你的设计。讽刺的是，当你把设计用这重滤镜审核时，当初驱动最初的设计的那个创新想法可能变得完全站不住脚。这点我们会在第29章详细讨论。
关键问题：“这个游戏能卖得火吗？”
滤镜#6：技术角度：在你把游戏做出来之前，游戏创意仅仅是一个创意，而且光是创意是不需要受到可行性和实用性的约束的。要通过这重滤镜，你必须回答一个问题：“我们打算如何做出这个游戏呢？”问题的答案在于技术上的限制，技术上是否允许这个创意如它原本设想地那样制作出来呢？新手的设计师通常都会对技术强加给设计的限制感到失落。不过技术角度的滤镜往往也能让游戏向着新的方向发展，因为在运用这个滤镜的过程中，你可能意识到一些本来没设想到且技术支持的特性。这个滤镜的运用过程中出现的各种创意是特别珍贵的，因为你能很确定它们是可行的。关于技术和工程方面的问题我们会在第26章更详细地讨论。
关键问题：“这个游戏在技术上有可能做出来吗？”
滤镜#7：社会/社区角度：有时候，一个游戏光是有趣是不够的。一些设计目标可能需要一种强力的社会成分，或者是形成一个围绕着游戏的兴盛的社区。你的游戏中的设计会对这些方面带来很强的影响。这方面我们会在第21章和22章详细讨论。
关键问题：“这个游戏满足我们社会上和社区上的目标吗？”
滤镜#8：游戏测试：一旦游戏开发到可玩的程度时，你必须运用这个游戏测试的滤镜，它可以说是所有滤镜中最重要的。你所想的游戏过程会是一种情况，实际上玩起来可能是另一种情况，而当你看到目标受众在玩的时候或许又是另一种情况。你应该让游戏尽快到达一种可玩的阶段，因为当你真正看到游戏在运行时，那些必须做出的重大修改会马上变得明显起来。这个滤镜的运用除了能对游戏进行修改以外，它往往还会修改和调整其他滤镜，因为在这个运用过程中你开始对游戏各个机制以及目标受众的心理有了更多的了解了。游戏测试过程会在第25章详细过论到。
关键问题：“参与游戏测试的人足够喜欢这个游戏码？”
在设计的过程中，有时候你可能发现要修改其中一个滤镜——可能原本你是面向某种受众的（比方说18〜35岁的男性），但当你设计时无意中发现它更适合另一种受众（比方说大于50岁的女性）。在你设计的约束条件允许的情况下，修改滤镜是可以的。重要的一点是通过修改各个滤镜或者修改你的设计，最终能找到一种方法，让设计能通过所有八个滤镜。
你还需要在游戏剩余的设计过程和开发过程中不断地使用这些滤镜。当你在挑选一个最初的创意的过程中，你应该评估一下哪个创意能最容易塑形到可以经受得起这种八滤镜的严酷考验。这种八滤镜的观点是在评估游戏时非常有用的，因此让我们把它变成我们的第13个透镜。
透镜#13：八滤镜的透镜
在使用这个透镜时，你要考虑到你的设计必领满足的众多约束。只有当它无需再进行修改地通过了所有八个滤镜时，你才能声称你的设计是最终成型的。
问一下自己以下的问题：
l 这个游戏感觉对头吗？
l 目标受众足够喜欢这个游戏吗？
l 这是一个良好设计的游戏吗？
l 这个游戏足够新颖吗？
l 这个游戏会卖得火吗？
l 这个游戏在技术上有可能做出来吗？
l 这个游戏满足我们社会上和社区上的目标吗？
l 参与游戏测试的人足够喜欢这个游戏吗？
在某些情况下，可能还会有着更多的透镜。例如一个教育类游戏还需要问一些诸如“这个游戏教会了我们预想要教的东西了吗？”的问题，假如你的游戏还需要更多的滤镜，那就别漏掉它们。
循环的规则
在我们整个第6章和本章前面的部分都是关于“1. 想出一个创意”的详细解释，这看起来可能会把人吓一跳。但创意本身就是设计的根源，而它们的产生过程又是如此神秘和近乎魔法般的，所以花了这么多篇幅在这步上讨论也没什么好惊讶的。
到了设计流程的这一步时，我们已经考虑过众多的创意并挑选出其中一个了，如今该是时候移到下一步了：“2. 尝试做一下”。而很多设计师和开发者都只是这么去做——急忙地开始尝试做他们的游戏。假如你的游戏是很简单的，比方说是一个卡牌游戏、桌面游戏，或者是非常简单的电脑游戏，那你有着大量的时间去一遍又一遍地测试和修改直到它变得很棒的，你也理应这样去做。
但假如你无法在一两个小时里把你的游戏做成一个可运作的原型那该怎么办呢？假如你的游戏需要数个月的美术和程序工作才能看到，从而才能让你可以去尝试做一下，那又该怎么办呢？如果情况是这样（如今很多最新的视频游戏设计都是这样），那你需要在这一点上很谨慎地进行。游戏设计和开发的过程肯定是迭代或者不断循环的。你不可能精确地计划出要花多少次循环才能让你的游戏通过所有八个滤镜且变得“足够好”。也正是这点使得游戏开发变得难以置信地极具风险——你在不确定的情况下不断打赌你的游戏能在一个固定的预算内通过所有八个滤镜。
很多人今天依然在用的一种很天真的策略是在这个阶段上开始把游戏涂涂凑凑，以求能得到最棒的结果。有时候这种方法会凑效。但当它失效时，你就会因此陷入极可怕的混乱里了。一方面你不得不发布一个你觉得不够好的游戏，另一方面还要承受接下来的开发过程的费用。而往往是这些额外的时时间和费用已经足以使得项目完全无利可图了。
事实上，这个问题对所有的软件项目都是共通的。软件项目都很复杂，复杂到很难预测它们要花多长时间才能做完并找出和修正所有一定会在开发过程中出现的bug。除了这些以外，首当其冲地是游戏还多了一重负担——需要变得有趣——游戏开发者比起非游戏类软件开发者多了一大堆后者不需要在意的滤镜。
这里真正的问题在于“循环的规则”。
循环的规则：你检验和改良游戏的次数越多，你的游戏也会变得越好。
循环的规则不是一种透镜，因为它不是一种观点和视角——它是一个绝对的真理。没有一个例外能越过循环的规则。你可能在你的事业生涯中会尝试让这个观点不合理，你会说服自己说：“这次这个设计是很棒的，我们不需要检验和改良”。又或者“我们真的别无选择，我们只能希望它变得最棒了”。但每每这样做，最终遭受苦果的都是你自己。电脑游戏里最可怕的一点是它用来检验和调整系统的时间和金钱都比传统游戏多得多。这意味着电脑游戏开发者只能选择去循环尽可能少的次数，而这点偏偏又是有着可怕的风险的。
假如你真的开始着手一个游戏的设计了，这个游戏也打算囊括漫长的“检验和改良”循环，那你需要回答以下的两个问题：
l 循环问题1：我如何能让每次循环有价值？
l 循环问题2：我如何能尽可能快地完成一次循环？
在过去的40多年里，软件工程领域里的人已经对这个问题思考过很多次了，他们也提出了一些有用的技术。
软件工程的简短历史
发现危险-瀑布模型-停止使用
在20世纪60年代，那时候软件开发还是相对崭新的行业，当时的领域里是没什么正规流程的方法的。程序员只是对他们开发的时间进行最准确的猜测，然后就着手编码了。通常猜测是错误的，结果很多软件项目也因为超出预算而悲惨地结束掉。到了20世纪70年代，一些开发者（通常都是在非技术管理者的吩咐下）为了对这种不可预期的过程引入秩序，他们尝试去采用软件开发里的“瀑布模型”，这是软件开发采用的有秩序的7步流程。它大体上看起来是如下图那样的：
系统需求→软件需求→分析→程序设计→编码→测试→运营
这的确看起来很吸引！七个有秩序的步骤，且当每一个完成时，没有漏掉任何东西地移到下一步——“瀑布”这个名字正是意味着不需要任何迭代，因为瀑布一般都是不会往山上流的。
瀑布模型有着一个不错的特征：它鼓励了开发者在开始编码之前花更多的时间在计划和设计上。但除此之外它是完全没有意义的，因为它违反了“循环的规则”。管理者觉得它极其吸引，但程序员明白这是荒谬的——软件太过复杂了，用这样一种线性流程是不可行的。甚至书写论文建立了这套体系的Winston Royce也不赞成以这种想法来看待瀑布模型。有趣的一点是，他原本的论文是强调了迭代的重要性的，而且强调了在需要时可用回到前面的步骤里。他甚至从来没用过“瀑布”这个词！但在各个学校和企业里都以这种线性方法来教授。整套模型看起来在当初被一群没有实际做过真正的系统开发的人痴心妄想地打着如意算盘去错误散播。
Barry Boehm的福音
而后在1986年，Barry Boehm提出了一个不同的模型，它的基础是更接近真实软件开发实际发生的情况的。这个图看起来让人觉得有点可怕，整个开发过程是从图的中间开始的而后顺时针地向外盘旋，一遍又一遍地通过四个象限（如图7.3）。
他的模型有着不少复杂的细节，但我们不需要把全部都过一遍。在他的模型里基本上有三个想法是很棒的，它们分别是：风险评估、原型制作和循环迭代。简单来说，螺旋模型建议你按照以下的方法来做：
1. 提出一个基础设计
2. 找出设计中最大的风险
3. 建立出各种原型来减轻这些风险
4. 测试和检验这些原型
5. 基于你已经了解的提出一个更详细的设计
6. 回到步骤2
基本上你会不断重复这个循环直到系统最终完成。它轻易地打败了破布模型，因为它完全就是吻合循环的规则的。而且它回答了我们前面看的的两个问题：
1. 循环问题1：我如何能让每次循环有价值？——螺旋模型的答案：评估你的风险且进一步减轻它。
2. 循环问题2：我如何能尽可能快地完成一次循环？——螺旋模型的答案：建立很多粗略的原型。
螺旋模型有着众多的衍生物，它们可能都是值得你去研究的。尽管这些衍生物都有着不同的地方，但是它们的核心里都包含着风险评估和原型制作。
风险评估和原型制作
案例：Prisoners ofBubbleville
假设你和你的团队决定要做一个关于跳伞降落到城市里的视频游戏。你用基本四元组的方式简要地描述出你的设计：
Prisoners of Bubbleville——设计摘要
故事：你是一只叫做“Smiley”的会跳伞的猫。Bubbleville里的好人都披一个邪恶的巫师困在了各自家里。你必须找到一种方法来打败巫师，通过不断地跳伞降落到城市里，滑进烟囱里探访一个个市民，从他们那里得到如何制止巫师的线索。
机制：当你跳伞降落到城市的过程中，你需要尽量去抓住各种从城市里升起的魔法泡泡，借用这些泡泡的能里来射出光线，反击那些试图摧毀泡泡和撕破你的降落伞的邪恶秃鹰。与此同时，你还必须导航到城市里的多个目标建筑中的其中一个里。
美感：卡通外观和整体感觉。
技术：利用第三方引擎的多平台3D主机游戏。
其中一种你能采用的方法是马上开始做这个游戏。开始编写代码、设计详细的关卡、对角色制作动画，然后等待所有这些聚到一起，看看它们到底能变成什么。但这种做法会是极其危险的。假如这是一个历时18个月的项目，那可能至少要6个月才能让你有一个可玩的版本。倘若你到那时候才明白你的游戏创意是没趣的，那该怎么办呢？或者是到那时候才知道这个游戏引擎是无法完成你的目的的，那又该怎么办呢？到那时候你会陷入真正的麻烦里。你已经在整个项目周期中走了1/3的路了，而此时才完成了仅仅一次的循环！
而另一种方法，也是最正确的方法是和你的团队坐下来一起做一次风险分析。这意味着你要列出所有有可能危害到项目的事项。对前面那个游戏来说，例如像以下的列表：
Prisoners of Bubbleville——风险清单：
风险#1：收集泡泡和射击秃鹰的机制可能不如想象的那么有趣。
风险#2：游戏引擎可能无法同时绘制整座城市以及所有的泡泡和秃鹰。
风险#3：我们当时所想的是需要做30间不同的房子来做出整个游戏——要制作这么多不同的室内场景和角色动画可能会超出我们预算的时间。
风险#4：我们不确定大家是否喜欢这些角色和故事。
风险#5：可能有一定的几率，发行商会坚持让我们把游戏的主题改成迎合夏季的一步新电影，最终题材可能甚至会颠倒过来。
事实上，你可能有着更多的风险，，但只是作为例子来说我们就考虑到这里就好了。那现在我们来看看我们该如何处理这些风险呢？当然你也可以交叉双手来祈祷这些事情不会发生，但你也可以做更聪明的事情：减轻风险。这里的思路在于尽可能早地降低或者去除风险，通常采用的方法是建立规模较小的原型。让我们来看看以上每个风险可以如何去减轻：
Prisoners of Bubbleville——风险减轻：
风险#1：收集泡泡和射击秃鹰的机制可能不如想象的那么有趣。
——游戏机制通常都是抽象的，而且可以用一种更简单的形式试玩。你可以让一个程序员把这个游戏机制做成一个非常抽象的版本，它可能是2D的，用一些简单的几何形状来替代运动的角色。你可能只需要一两周的时间就有了一个可运作的游戏了，然后你可以马上开始回答它是否有趣的问题了。假如看起来真的没趣，那你得对这个简单的原型进行多次的快速修改，直到它变得有趣起来，而后才开始着手精致的3D版本。在这个过程中你能更快地做多次循环，明智地去利用“循环的规则”的优势。你可能会拒绝这种方法，觉得以后要丟掉这个玩家看不到的2D原型版本的代码是很浪费的。但从长远来说，你是节省了时间的，因为你更早就为正确的游戏编码了，而不是为一个不对头的游戏在进行无穷无尽的编码和重编。
风险#2：游戏引擎可能无法同时绘制整座城市以及所有的泡泡和秃鹰。
——假如你等待所有最终的美术资源来回答这个问题，那你只会把自己置身于一个可怕的情形里：一旦游戏引擎无法处理，你就不得不让美术人员把这些资源进行重调以适应游戏引擎，或者让程序员花额外的时间去找出更有效率地渲染图形的方法（或者更大可能是把这两种方法都用上）。为了减轻这重风险，你需要马上建立一个快速原型，它的唯一用途只是把接近数量的对象都同时显示在屏幕上，看看引擎是否能处理这么多的实体。这个原型里是没有任何玩法的，它只是用来检验技术上的限制。假如它能处理，那当然很好！否则你就得在美术开始动工之前马上找出一种解决方案了。同样，这个原型是会抛弃的。
风险#3：我们当时所想的是需要做30间不同的房子来做出整个游戏——要制作这么多不同的室内场景和角色动画可能会超出我们预算的时间。
——假如你到了开发的中途才意识到你没有足够的资源去完成所有的美术工作，那你就死定了。你只要让一个美术人员做出一个房子和一个运动的角色就能马上知道它要花多长时间了，假如它花的成本比你能承受的要大，那就马上改变你的设计——或许你能用更少的房子，或许你能重用一部分的室内场景和角色。
风险#4：我们不确定大家是否喜欢这些角色和故事。
——如果你真的很在意这点，那你绝对不能等到所有的角色和故事都放到游戏的时候才去回答这个问题。对这点我们能做什么样的原型呢？这是一种美术类的原型，它可能不是在电脑上的，只是一种公告板。你要让你的美术人员绘制一些概念图，或者做一些角色和设定的测试渲染图。制作一些故事板来向大家展示整个故事是如何进展的。一旦你有了这些资源以后，你可以开始把它们展示给人们看（更好地是把它们展示给你的目标受众看），在看的过程中评估他们的反应，找出哪些是他们喜欢的，哪些是他们不喜欢的，以及为什么这样。可能他们喜欢主角的外观，但不喜欢他的姿态。可能他们觉得坏人让游戏很刺激，但故事本身很无聊。你可以完全不依赖于游戏地找出大部分的答案。每当你这么做一次并作出一次修改时，你就完成了又一次的循环，并且向着更棒的游戏又迈进一步了。
风险#5：可能有一定的几率，发行商会坚持让我们把游戏的主题改成迎合夏季的一部新电影，最终题材可能甚至会颠倒过来。
——这个风险可能听起来很荒谬，但这种事情是时常发生的。假如它在项目的中期发生，那后果是极可怕的。但你也不能无视这类情况——你必须慎重考虑每一个可能威胁到你的项目的风险。在这种情况下原型能帮上忙吗？很可能无能为力。为了减轻这个风险，你应该靠近管理层来尽快地得到决定，或者你应该做一个能更容易重定位到某部电影上的游戏。你可能甚至要提出做两个不同的游戏的计划——这里关键的思路在于你需要马上考虑这个风险，当下立即行动去确保它不会让你的游戏陷入危险里面。
风险评估和风险减轻是一种很有用的视角，它成为我们的第14个透镜：
透镜#14：风险减轻的透镜
在使用这个透镜时，停止去正面思考，开始慎重地考虑会对你的游戏带来可怕的结果的事情。
问一下自己以下的问题：
l 有哪些因素会阻碍这个游戏变得优秀？
l 如何能阻止这些因素的发生？
风险管理是很难的。这意味着你必须直面那些你竭力想避开的问题，并且马上地解决它们。然而一旦你规定自己这么做以后，你就能经历更多次的循环了，而且更有用的是它能让你的游戏最终变得更好。我们都有着各种诱惑促使我们忽略这些潜在的问题，只是把精力花在游戏里那些你觉得最有信心的部分上，你必须抵挡这些诱惑，全身心地关注于那些会把你的游戏置入危境之中的问题。
高效能原型制作的8个技巧
众所周知，快速的原型制作对高质游戏开发是至关重要的。以下的这些技巧能有助于为你的游戏做出最棒且最有用的原型。
原型制作技巧#1：回答一个问题
每一个原型都应该为了回答一个问题而设计，有时候会为了回答多个问题而设计。你应该能清晰地陈述出这些问题。假如你做不到这样，那你的原型就真的很危险了，它很可能只是一项浪费时间的无用功，而不是它本该成为的能节省时间的一次试验。一个原型可能会回答类似以下的问题：
l 从技术角度来看，在我们的一个场景里能支持多少运动的角色？
l 我们核心的游戏玩法有趣吗？它能长时间保持有趣吗？
l 从美感上来说，我们的角色和背景设定互相符合吗？
l 这个游戏需要多大一个关卡？
你要抵制住把你的原型做得过份精致的诱惑，把注意力只放在回答好关键的问题上，点到即止则可。
原型制作技巧#2：忘掉质量
任何一类游戏开发者都有着一个共同特征：他们对自己做出来的东西都很自豪。于是自然而然地，很多人觉得做出一个“快捷简陋”的原型是和他们的理念完全格格不入的。结果美术人员会把大部分的时间都花在前期的概念草图上，程序员会把过多的时间花在把一段必定丟弃的代码打造成合乎优雅的软件工程理念的工作上。当制作原型时，唯一要关心的是它能不能回答你设定的问题。即使最终出来的原型几乎不能算作是作品，看起来很粗糙简陋，只要能越快做到这点就越好。事实上，对你的原型进行精心打磨可能甚至会让事情变得更糟。相比于精心打磨过的原型，那些看起来粗糙简陋的原型会更容易让玩家测试人员（和其他同事）发现其中的问题。又因为你的目标是马上找出问题以便于尽早解决问题，而一个精心打磨的原型实际上会隐藏了真正的问题，这样会破坏了你的初衷，从而把你哄骗到一种安全的错误感觉里。
你是绕不开循环的规则的。倘若你能越快地建立出原型来回答你的问题，那即使它看起来很糟，结果也会变得越好。
原型制作技巧#3：别对它太依恋
在《人月神话》里FredBrooks陈述了很有名的一点：“只要计划好要抛弃它，无论如何你都会做到的。”他在这里的意思是无论你喜不喜欢它，你系统的第一个版本都不会成为一个成品，它实际上只是在你用“正确的”方式做出你的系统前必须要抛弃的一个原型。不过事实上，你可能会抛弃很多很多的原型。缺乏经验的开发者通常会在这个过程上度过一段艰辛的时光——这让他们感觉自己像是失败了。在你进入原型制作的工作时，你头脑里要时刻记住，你在原型里所做的一切都是临时的——唯一关键的是回答你的问题。你要把每一次原型都看作是一次学习的机会，就像是为做出“真正的”系统在练习那样。当然，你也不会抛弃所有的东西，你会留下各处真正能用的部分，把它们组合起来来让其他部分变得更棒。这个过程可能会很痛苦。正如设计师Nicole Epps曾经说到的：“你必须学会如何去抹灭你的胎儿。”
原型制作技巧#4：对你的原型区分优先级
当你做出了风险清单后，你可能意识到你需要做出多个原型来减轻你面临的所有风险。在原型制作前你要做的一件事是对它们设定优先级，如此你才能第一时间面对最大的风险。你还应该考虑它们各自的依赖性——假如某个原型的结果有可能使得其他原型变得无意义，那这个“处于上游的”原型无疑是你最高的优先级。
原型制作技巧#5：高效地并行开发原型
得到更多的循环的一种极好的方法是同时开发多于一个的原型。当系统工程师在制作原型来回答技术上的问题时，美术人员也能做一些美术原型，游戏脚本人员也能做一些玩法上的原型。设立多个小型独立的原型能帮你更快地回答更多问题。
原型制作技巧#6：原型不是非得电子版的
你的目标是尽可能有用且频繁地完成循环。因此，假如无需软件也能做到的话，为什么不尝试一下呢？如果你很聪明，你完全可以把你那奇特的视频游戏创意构造成一个简单的桌面游戏原型，或者是我们经常提到的“纸上原型”。为什么要这样做呢？因为做一个桌面游戏是很快的，而且通常能捕捉到相同的游戏玩法。这能让你更快地发现问题——原型制作中大部分的过程都是和寻找问题以及寻求如何修正问题相关的，因此纸上的原型制作的确能节省很多的时间。假如你的游戏是回合形式的，那做起来就更容易了。《卡通城在线》的回合制战斗系统是以一个简单的桌面游戏来原型化的，这让我们对各类攻击和各种连锁做了仔细的平衡。我们还在纸上和白板上去跟踪生命值的走向，一遍又一遍地玩这个原型，不断地增减各种规则，直到游戏看起来足够平衡时才开始尝试为它编码。
即使是即时游戏也能用纸上原型玩起来。这类游戏其中一部分是可以转化为基于回合的模式，且依然能把握住其游戏玩法的。对其他的游戏来说，你也可以近似即时地去玩。而达成这点的最好办法是让其他人来帮你。我们来看两个例子：
俄罗斯方块：纸上原型
假如说你想做一个罗斯方块的纸上原型。那你可以剪出一些小的卡片块，把它们堆成一堆。让某个人随机地从中抽取，然后沿着纸板（用一张硬皮纸在上面绘制出边框）让它们滑下来，当你抓住它们时，你可以旋转它们。至于消除一行就需要发挥你的想象力了，或者是停止游戏，用一把剪刀来砍去那一行的卡片块。这可能不是完美的俄罗斯方块体验，但它已经足够接近了，足以让你看看是否具备了各种合适的形状，也足以让你一定程度感觉到这些方块该下落有多快。并且完成这整套的东西只需要看5分钟左右就可以了。
毀灭战士：纸上原型
有可能为一个第一人称射击游戏做一个纸上的原型吗？当然可以！只是你需要不同的人去扮演AI角色和其他玩家而已。在一大张的图纸上画出地图，用小片的纸块来代表不同的玩家和怪物。你需要用一个人去控制每个玩家，用一个人去控制每个怪物。你还可以设定一些基于回合的规则，定下如何移动和如何射击，或者甚至是用一个节拍器来控制！在网上是很容易找到免费的节拍器的。你可以把节拍器设置为每隔5秒钟跳一次，在规则上制定在每一跳的时候可以把纸块移动一平方。当视线触及时，你可以对其他玩家或者怪物进行射击，但每一跳只能射击一次。这样玩起来会感觉很慢，但这的确是一件好事，因为它让你有时间去思考在你玩游戏的过程中什么是有效的，哪些东西是无效的。你可以很好地感觉到你的地图应该有多大，走廊和各个房间的形状该是怎样才能让游戏有趣，你的各种武器的属性该是什么样的，以及其他的东西——你能在更快的时间里完成所有这些事情！
原型制作技巧#7：挑选一个“快速循环”的游戏引擎
软件开发的传统方法在某种程度上就像烤面包那样：
1. 编写代码
2. 编译和连接
3. 运行游戏
4. 去到游戏里你想测试的部分
5. 再回到步骤1
假如你不喜欢烤出来的面包（也就是你的测试结果），唯一的一种选择是重新开始整个过程。这使得整个流程非常长，尤其是对大型的游戏来说。通过选择一种有着对头的脚本系统的引擎，你能在游戏运行过程中对代码进行修改。这让所有事情变得更像在用黏土进行创作——你可以不断地修改做出来的作品：
1. 运行游戏
2. 去到游欢里你想测试的部分
3. 测试一下
4. 编写代码
5. 回到步骤3
通过在系统运行过程中进行重现编码，你能在每天进行更多的循环，并且游戏的质量也会相应提升。我曾经在过去用过Scheme、Smalltalk和Python这几种语言来完成这件事（我还是Panda3D的忠实Fans：www.panda3d.com），但其实任何一个迟约束的语言都能完成这项任务。假如你担心这些语言会运行太慢，那你大可以用多于一种语言去编写你游戏中的代码：对于那些不需要太多修改的底层部分，用速度较快但静态的语言去编写（例如Assembly或者C，而对于上层部分则用较慢但可以动态修改的语言去写。这可能需要一定的技术工作才能实现，但最终一定会值得的，因为它让你利用了循环的规则的优势。
原型制作技巧#8：先创造玩具
回顾我们在第3章里讲述的内容，我们阐明了玩具和游戏间的不同。玩具因为它们本身的原因，玩起来是很有趣的。而游戏有着很多目标和一次围绕着问题解决过程的丰富体验。但尽管如此，我们永远不该忘记很多游戏是在玩具的基础上做出来的。一个球是一个玩具，但一个篮球就是一个游戏了。一个会跑会跳的角色是一个玩具，但大金刚就是一个游戏了。你需要确保这个玩具在你围绕它设计出一个游戏之前，它是玩起来很有趣的。当你真正做出这个玩具时，你可能发现你惊讶于构成它的乐趣成分，从而产生出这个游戏的一整套新的创意。
游戏设计师David Jones说到在他设计游戏《疯狂小旅鼠》（Lemmings）时，他的团队是完全遵照这个方法来制作的。他们觉得做一个有着很多小生物四处游荡地做着各种不同的事情的小世界是很有趣的。他们不确定这样的游戏会是怎么样的，但这个世界听起来很有趣，于是他们就着手做了。当他们实际地在玩这个“玩具”时，他们开始慎重地讨论该围绕着这个玩具构造一个什么样的游戏。Jones引用了《GTA》的开发这个相似的例子来说明：“GTA并不是设计成我们看到的GTA那样的。它只是设计成一个媒介，一个鲜活逼真的玩起来有趣的城市。”当这个“媒介”开发完成时，整个团队都觉得它是一个很有趣的玩具，结果就必须为它做出一个游戏了。他们意识到整座城市就像一个迷宫那样，于是他们从一些他们认为不错的游戏里借用了迷宫的游戏机制。Jones解释道：“GTA的设计来源于吃豆人。那些小点也就是小人。我自己是在小小的黄色汽车里的，而吃豆人里的幽灵也就是GTA里的警察。”
当你先做出了玩具，然后再提出整个游戏，这样你能从根本上提升整个游戏的质量，因为这样使得它在两个层面上都是有趣的。进一步而言，假如你所设计的玩法是基于玩具中最有趣的部分的，那这两个层面将会以尽可能最强力的方式互相支持。游戏设计师通常都会忘记考虑玩具这一重视角。为了帮助我们记忆，我们把它做成了第15个透镜。
透镜#15：玩具的透镜
在使用这个透镜时，停止思考你的游戏进去玩的时候有没有趣，而是开始思考拿着它来玩有没有趣。
问一下自己以下的问题：
l 假如我的游戏没有任何的目标，它从根本上还有趣吗？假如这样是没趣的，那如何能改变它呢？
l 当人们看到我的游戏时，他们会在了解到要做什么之前想去和它交互吗？假如不是这样，如何能改变它呢？
有两种方法可以利用玩具的透镜。一种方法是把它用在已有的游戏上，用它来确定出如何添加更多像玩具那样的特性——换句话说，是让它如何变得更加平易近人，如何让它在操纵时更有乐趣。而第二种方法，也是最勇敢的方法，是在你还没想到要做一个什么样的游戏之前先发明和做出新的玩具。假如你是受计划的限制，这样做是很有风险的——但假如你不受限制，那这会是一个很好的“探矿杖”，能帮你设计出其他情况下无法想出来的很精彩的游戏。
让循环变成回路
当你做出了多个原型以后，剩下所有的工作只是对它们进行测试了，然后基于你了解到的再次开始整个过程。我们重新回顾一下之前我们谈到过的非正式的过程：
非正式的循环：
1. 想出一个创意。
2. 尝试做一下。
3. 不断修改和测试，直到看起来不错为止。
如今我们让它变得更正式一点，正式的循环是这样的：
1. 陈述出问题。
2. 对一些可能的解决方案进行头脑风暴。
3. 选择一种解决方案。
4. 列出使用这种解决方案的各种风险。
5. 建立各种原型来减轻这些风险。
6. 测试这些原型。假如你觉得足够好了，那就停止。
7. 陈述出你想要解决的新的问题，然后回到第2步。
在每一轮的原型制作过程中，你都会发现自己会更详细地陈述出各种问题。例如假设你被任命去开发一个竞速游戏——但这个游戏必须有一些新颖和有趣的地方。以下总结了整个过程可能会如何经历各个循环。
循环1：“新型竞速游戏”
l 问题陈述：提出一种新类型的竞速游戏
l 解决方案：在水底的潜水竞速（把鱼雷也用上！）
l 风险：
Ø 不太确定水底竞速赛道外观会是怎样的
Ø 这可能感觉还不够创新
Ø 技术上可能不足以处理所有的水特效
l 原型：
Ø 美术人员着手设计水底赛道的概念图
Ø 设计师对各种理解的新效果（各种潜水艇会从水里冒出来飞行，发射追踪导弹、深水炸弹，玩家要竞速通过一片布雷区）进行原型制作（利用纸上原型且参考一个已有的赛车竞速游戏）
Ø 程序员测试一些简单的水特效
l 结果：
Ø 假如在水里有一个“色彩鲜明的路径”，那水底赛道看起来还可以。水底隧道也是很酷的！这样那些飞速前进的潜水艇会沿着轨道在水里出没！
Ø 假如潜水艇都很快并且容易操作的话，那早期的几个原型看起来都挺有趣的。这必然要把它做成是“潜水艇竞速”了，所以我们需要找一种方法来限制他们停留在空中的时间。我们做了一次玩家测试，明显发现这个游戏必须支持联网的多人游戏。
Ø 一部分的水特效是比较容易做的。水花飞溅的效果看起来很棒，水底的泡泡也是。让整个屏幕都像在水里那样摇曳会占用太多的CPU，而且在一定程度上会分散了玩家的注意力。
循环2：“潜水艇竞速”游戏
l 新问题的陈述：设计一个潜水艇会飞起来的“潜水艇竞速”游戏。
l 详细的问题陈述：
Ø 不确定“潜水艇竞速”看起来是怎么样的。我们需要确定潜水艇和赛道的外观。
Ø 需要找一种方法来平衡游戏，使得潜水艇在水里和水外都有合理的时间分布。
Ø 需要找出如何支持联网多人游戏的方法。
l 风险：
Ø 假如潜水艇竞速看起来“太卡通化”了，那它们会让很多年纪较大的玩家望而却步的。假如它看起来太写实了，那在这类玩法上看起来又会显得很无聊。
Ø 在我们弄清楚要在水里和水外花费多长时间前我们不可能去设计任何关卡，也不能为场景做任何美术资源。
Ø 这个团队从来没试过为竞速游戏做联网的多人游戏功能。我们完全不确定是否能否做到。
l 原型：
Ø 美术人员需要绘画各种不同类型的潜水艇，它们要用多种不同的风格表现：例如卡通的、现实的、超现实的，甚至是活生生的生物的潜水艇。整个团对会对此投票，我们也会非正式地调查目标受众里的部分成员。
Ø 程序员和设计师会一起去做一个非常粗糙的原型，让他们能体验和感受到该在水里和水外花费多长的时间，以及达成这个时间分配的各种不同的机制。
Ø 程序员会为多人联网做一个粗略的框架让它能处理这类游戏所需要的所有类型的消患。
l 结果：
Ø 所有人都喜欢“恐龙潜水艇”的设计。这在团队成员和潜在的受众成员间都有着强烈的一致程度，他们都认为“会游泳的恐龙”在外观上和感觉上都是很符合这个游戏的。
Ø 在多次实验以后，明显发现对大多数的关卡来说，60%的时间应该花在水底，20%的时间花在空中，而另外20%的时间需要接近水面，在接近水面时玩家能积蓄好力量，以让它们飞到水面上利用速度上的优势。
Ø 前期的联网实验证明了竞速在多人游戏上基本是没什么问题的，但假如我们避免用一些速射机枪的话，那多人部分会更容易实现。
循环3：“飞速恐龙”游戏
l 问题陈述：设计一个“飞速恐龙”游戏，让恐龙在水底和水上竞速。
l 详细的问题陈述：
Ø 我们需要确定计划表上能否排上各种恐龙所需要的所有动画的制作时间。
Ø 我们需要为这个游戏开发数量“合适”的关卡。
Ø 我们要定出这个游戏用到的所有提升能力的方式。
Ø 我们需要确定这个游戏要支持的所有武器（并且由于联网方面的约束，避免使用速射机枪类武器）。
你可以注意到问题的陈述是如何逐步发展和如何在每轮里变得更加具体的。你还能注意到假如不这样做会让多少棘手的问题突然冒出来。如果团队没有这么早就尝试过所有不同的角色设计，那会怎么样呢？如果游戏里三个关卡已经设计和建模完成了，此时才注意到要防止玩家在空中待太长时间的问题，那会怎么样呢？如果机枪系统已经编码完成了，并且整套玩法机制都围绕着它，此时所有人才意识到它会破坏了联网方面的代码，那会怎么样呢？这些问题都因为有着这些早期的循环而得以快速地定位出来。你看起来这里只有两个完整的循环和第三个循环的开端，但其实只因为它很聪明地利用了并行开发，实际上原本应该是六个设计循环的。
你还能注意到整个团队是如何参与到重要的设计决策里的。单靠设计师是无法做到这点的，大部分的设计都要经过技术和美感上的验证。
多少才是足够呢？
你可能很想知道在一个游戏完成前到底需要多少个循环。这是一个很难回答的问题，也正是这个问题使得游戏开发过程很难计划。循环的规则暗示了越多的循环总能让你的游戏变得越好。因此正如谚语所说的：“工作是永远不会完成的——有也只是放弃”。确保你已经经历了足够的循环的很重要的一点是，在你花光了整个开发的预算前你对做出来的游戏感到自信了。
那当你站在第一个循环的开端时，有没有可能较准确地估出什么时候能有一个成品的高质量的游戏呢？恐怕不能，这完全是不可能的。经验丰富的设计师在经历一段时间以后会猜测出更接近的结果，但大部分游戏的发布都比它们原本承诺的时间要晚，或者是以低于原本承诺的质量来发布，这实际上都证明了是没有任何办法能知道具体时间的。为什么会这样呢？因为在第一个循环的开始时，你是完全不知道你将要做出什么的！只有在每一个循环时你才会更明确知道你的游戏实际会是怎么样，而此时才能让你更准确地估算出时间。
游戏设计师Mark Cerny曾经为游戏设计和游戏开发描述了一个称为“The Method”的系统。毫不惊讶地，这个系统是卖成了迭代和风险减轻的。但“The Method”在Cerny所叫的“预制作”和“制作”（这两个词是引自好莱坞的）间还做了有趣的区别。他说到在你完成了游戏中两个可发布的关卡，且完成了所有必须的功能前，你都是处于预制作阶段的。换句话说，直到你有了两个完全成品的关卡前，你依然在不断定义整个游戏的基础设计。一旦你到达这个魔法般的节点时，你就进入制作期了。这意味着你已经对游戏到底是什么样的有了足够的了解了，你能较确定地计划出开发的剩余部分了。Cerny指出达到这个点上通常已经投入30%的预算了。也就是说，假如你花了100万美金才达到这点，那很可能你要再花230万美金才能真正完成这个游戏。这是一个很好的准则，并且它很实际地给予你一种更准确的方式来计划好游戏的真正发售日期。事实上，这个问题还是无可避免的——“The Method”只是让你能尽可能现实地尽快预测出时间而已。
这里描述到的迭代原理可能听起来对游戏设计来说很特殊，但诚然不是这样的。渐进的演进发展的开发从来都是任何一种设计的关键。
至今为止我们已经讨论过游戏该做成怎么样了，现在让我们来看看我们是为谁制作游戏的。