本文是于 2005 年时发表的文章，虽然距今已有三年以上的歷史，但绝对无损这篇文章的价值。同时，本文也与极具创意的优秀独立游戏作品《World of Goo》，有非常深的渊源以及关连性存在。
Kyle Gabler、Kyle Gray、Matt Kucic 与 Shalin Shodhan 是四位就读于卡内基美隆大学 (Carnegie Mellon University) 研究所的学生。在 1 个学期的时间内，他们仅仅凭藉着 4 个人的力量，完成了超过 50 个游戏的原型 (Prototype)！同时他们也设置了一个名为 Experimental Gameplay Project 的网站发表他们所制作的各款游戏原型；其中最受欢迎的游戏之一，就是由 Kyle Gabler 所制作的《Tower of Goo》，而这个游戏原型也正是《World of Goo》的前身作品！
为了达到 1 个学期之内完成 50 款游戏原型作品这项近似于不可理喻且不可思议的目标，他们将自己锁在房间内，遵循着以下三项规则进行开发工作：
- 每个游戏必须在 7 天以内完成。
- 每个游戏必须从头到尾以 1 人之力完成。
- 每个游戏必须立基于一般常见的主题，例如「重力」、「植物」或「群聚生物」等等。
7 天，1 人，以及 1 个主题，制作成为一个游戏原型作品。许多人好奇他们是如何在这么短的时间内完成一款游戏原型作品？又是如何能够维持上述规则与纪律，长达一整个学期之久？在此，四位作者共同将这段过程中所学习到的各种宝贵知识，包括正确以及不可行的尝试经验沈淀整理之后，分为准备、设计、开发以及游戏性四个项目，一一阐述如下：
准备：敏捷，是一种意向的状态
敏捷式原型开发 (Rapid Prototyping)，不只是前置开发时期的有用工具，同时也可以是一种生活方式。从思维层面出发，首先要使自己的心理状态合乎「敏捷」的原则，才能够真正成为一位敏捷式的原型开发者。首先，第一步就是要乐于拥抱失败的可能性。
优秀的原型开发者能够瞭解，失败是一件可以接受的事情！而那也正是建立原型的目标，所以请大胆地放手去做吧！万一最终真的失败了，也能够从其中的过程学习到某些具有价值的经验，并且唯有藉由拥抱失败的可能性，才有可能得到有所回报的实验结果。在 Gray 所制作的《Mime After Mime》与《A Mime to Kill》中，很大胆地只使用位置性音源 (Positional Audio) 做为游戏性 (Gameplay) 的来源；虽然这两个游戏是全然失败的作品，但也充分证明了仅有音源游戏性的游戏设计概念，是一项不可行的作法。
坚持实行极短的开发週期，是另外一项快速开发的诀窍。开发者们似乎会很自然地说：「嘿，既然我们在 1 週内完成了一个很棒的游戏，那么如果我们花费 2 週的时间进行开发，我们将会得到一个 2 倍优秀的游戏作品！」事实上，他们发现一般来说，任何游戏性都能够有效地在一週内完成原型建置；额外的投入时间，总是会倾向于产生功效递减的结果。举例来说，有些原型仅仅花费一个晚上的时间组装完成，另外有些原型则使用了额外的一两週时间，而令人意外的是，每个原型所花费的时间，与其最终获得的成功程度，并没有相互关连性存在。
在他们所制作出的成功游戏原型中，多数都是出自于特定的主题，他们曾经探索过的主题包括了「重力」、「弹簧」、「演化」、「声音」、「植物」与「平衡」等等。不知为何，当有限制存在的时候，反而会更易于产生创意。另外，与团队成员同时进行某个特定主题的原型开发，某种程度上也能够避免着力于太过显而易见的游戏性，迫使所有人都必须接受挑战，探索在这个主题下的所有游戏性的可能性。如果缺少了稳固明确的主题限制，游戏将会花费更多的时间创造，同时也会减损团队的方向目标，以及那种使他们能够挤压出最后一滴创造能力的友善竞争感。
每一位团队成员都必须能够独立面对并且负责游戏开发的所有面向，包含程式、美术、声音以及其他所有将成为最终成品的必需品。但是个人的才能并不代表一切，团队成员必须体认到对于这种形式的开发方式来说，「设计」才是至高无上的准则，而包括程式、美术与所有其他的东西在内，都只是为了服务最终的设计结果而存在。一位不具备这种思维的优秀工程师，将不会比完全瞭解这项关键要点的平庸工程师来得更为成功。
当团队建立完成后，他们就开始停止与其他成员一起工作。「啥？这样还算是团队吗？」听起来或许有些奇怪，但是四个人分头并进，同时开发四个游戏原型的「不协同合作」方式有许多益处，像是减少风险（四个成品中至少会有一、二个成功的结果）、友善竞争感、更广阔的主题探索（避免设计出与别人相同的游戏性），以及相互分享彼此所习得的知识。在每个原型开发週期的起始和最终阶段，团队合作是最具有价值的期间，而当进入开发期之后，与其他成员一起工作只会造成分心，而无法产生良好的正面效应。
设计：创意以及脑力激盪之谜
A great idea takes a split second to happen, but waiting for that lightning to strike can be excruciating.
Tower of Goo
一个伟大的点子或许能够在须臾间诞生，然而等待那个被闪电击中的时刻，却会使人备受痛苦与折磨。各位应该都听过「脑力激盪」(Brainstorming) 这项引导创意思考的团体活动吧！他们曾排定脑力激盪的会议，尝试过各种不同的创意发想方法，最后在他们开发出来的全部游戏里，没有任何一个作品是出自于团体脑力激盪议程所得出的成果，这实在是一项相当令人挫败且震惊的结论。经过许多次的研究后，他们终于发现了一个事实：「你就是无法为创意安排时程。」(You just cannot schedule creativity.) 你不能够说：「嘿，我们的计画是在 4:15 时开始脑力激盪，然后到了 5:00 我们就能得到 4 个超杀的绝妙点子，然后就可以开始动手了！」不过，脑力激盪至少能够使团队开始进行思考。
做为脑力激盪方式的替代方案，他们发现蒐集美术与音乐材料，特别有助于创造出具有情感的目标。以《Tower of Goo》为例，这个游戏背后的想法，源自于当 Gabler 听完了《Tango Apasionado》（电影《春光乍现》的主题曲）曲目后，在回家的路上，想像在某一个小镇里，当太阳下山时，镇上的每个人都扛起他们的桌子椅子或其他东西走出房子，为了某个神秘的理由，试图堆叠建立起一座高耸入云的巨塔，毫不停歇地向上攀升；然而这些居民并不是很称职的工程师，所以玩家必须协助他们建造这座高塔。
为了制作出令人喜爱的游戏，你必须先在脑海中想像玩家们会如何发出「哇！」的赞嘆声，然后依循此目标由后向前进行各项设计与开发。对于他们多数充满乐趣且获得成功的游戏作品，其实并不是令人感到意外的结果。在最佳的状况下，甚至在动手开始写任何一行程式码之前，就已经能够明确知道游戏点子是否稳固，因为他们已经事先在自己的脑袋中运行了模拟与实验的程序。没有任何游戏是偶然或者意外成功的；在见到成品之前，最终的成果早已昭然若揭。
开发：没有人知道你如何达成，也没有人会在乎
当你想出了绝妙的游戏点子后，接下来就是要在很短的时间内开发出游戏原型。首先，必须从核心机制 (Core Mechanic) 开始着手动工，建造出一个「玩具」；所谓的玩具，应该是核心机制减去任何游戏层面的实质目标或决定。不论该原型的核心机制是弹簧系统、生物群聚行为、重力机制或者其他系统，最多只会花费几个小时的时间就能够建构完毕。玩具并不存在赢或输的状态，只是一个有趣且可供玩耍的小玩意儿。先打造出玩具，能够让开发者及早确认核心游戏性的稳固性，并且找出设计层面的潜在问题。
在专案的进行过程中，他们所学到最重要的一课就是：「正确」的解决方案，通常不是最佳的解决方案。策略性地使用伪装的方法，能够节省你的时间与金钱，使你能够更快速地制作游戏。当你能够使用可预先制作的贴图，就不要设置复杂的光影系统；当你能够使用同样的效果蒙混过去时，就不要设置样式辨识系统以分析图画；当你能够延展点阵图达到相同且快速的效果时，就不要画出 Spline 曲线或者制作向量图形函式库。请大方而且经常性地进行伪装吧！
刚开始进行游戏原型开发时，每个人都会有种想要拯救所有东西的渴望：「只要再多花一点点时间与努力，一定能够把一个本来很糟糕的游戏，转变成一个很棒的游戏成品！」然而事实并非如此。以「弹簧」主题的游戏原型为例，起先是以一个非常精巧的弹簧系统做为出发点，结果到最后反而无法使这个核心机制转化成为一个优秀的游戏。对于原型开发者来说，必须要能够迅速辨认出已走入死路的游戏点子，然后断然地终止花费于其中的损失，继续朝着下个目标前进。比起花费时间试图拯救既存的程式码，保持开发时程的纪律与自发性更为珍贵。
如果原型的游戏性差劲透顶，就不会有復原的方法，即使放入了许多精美而丰富的内容物，也无法使游戏获得救赎。所有的美术、音乐以及衍生物内容，都无法使糟糕的游戏性最终转变成一个优秀的游戏，玩家很快就会发现在精美的图像与动人的旋律中，其实游戏本身并没有深厚的内涵，而不过是虚有其表而已。虽然如此，但游戏的整体美学仍然很重要；一个经过仔细琢磨的游戏，的确能够使一个好游戏变得更具可玩性，提供给玩家更好的游戏体验。
需要再次提醒的是，一位优秀的工程师未必能够成为一位优秀的敏捷原型开发者。「正确性」或「復用性」的解决方案通常不是敏捷原型开发者所追求的目标。面对每个问题与挑战，敏捷原型开发者必须要能够想出一堆解决方案，并且从中选择最快的方法。如果陷入了过度工程 (Over-Engineering) 的迷思当中，最终成果很容易产出一般性的工具或是技术展示程式，而非一个真正可玩的游戏。请记得：对于游戏原型的最终使用者们来说，他们从不会看见你的伟大工程技术，而且他们也不会在乎。
游戏性：官能领域中的「多汁」乐趣
复杂的东西未必具有乐趣。如果人类能够在几千年来，以各种不同的「球与平面」发展成各种球类运动来娱乐我们自己，那么游戏开发者或许在游戏乐趣的尝试上太过于努力了。想想《Tetris》、《Pac Man》以及其他的经典机台游戏，我们完全有可能使用基本的元素制造出丰富的游戏乐趣。透镜炫光、凹凸贴图以及其他新技术很不错，但它们并不能使游戏变得更加有趣。请先向你自己证明，以一个简单的游戏原型来说，你的核心机制的确具有价值存在；当你确信之后，就可以更进一步地装扮它，使它变得更加闪亮动人。
On A Rainy Day
在不断发想、制作以及发表原型作品的过程中，他们发现具有最高可重复游玩价值的游戏，是那些拥有某种创造或客制化层面的游戏，例如像是「用手和雨伞制造出一棵怪树」、「画出你的房子」、「建造你的高塔」或是「演化你的变异种族生物」等等游戏目标。只要提供给玩家独一无二的「所有权」感觉，就能够使他们满足而且想要获得更多的乐趣。实验并不意味着复杂。在这项计画的早期，他们所制作出来的游戏，往往远超过这些游戏应有的复杂度；不只是使用者介面令人困惑，而且按键对应至行动的方法也不够自然直觉。
对于以撰写程式为乐的人来说，请记得如果没有游戏性的目标，游戏原型就只是个「玩具」，而不是个「游戏」。所谓的游戏性目标，可以是任何东西，例如：在 X 时间内蒐集 Y 个元件，或是保持系统的稳定度，或是通过这个空间并且不触碰任何阻碍物体等等。而他们发现最佳的游戏目标，是如同《Tower of Goo》中与生俱来的游戏性，也就是不断地向上建造高塔而已。
最后，请记得让游戏看起来很「多汁」(Juicy)！「多汁」所代表的意思，就是游戏中接连不断而且丰富的「使用者回应」(User Feedback) 设计。当你碰触它的时候，多汁的游戏会跳动、摇动、喷射并且发出一点声响，让玩家感觉它像是活生生的，而且会对于你所做的每件事情做出回应。使用者回应是游戏中比较微小却非常关键的要素，能够让玩家感觉自己是真正掌控着游戏世界中的一举一动，并且藉由每次的互动行为，训练玩家逐渐熟悉游戏所制订的种种规则。
进行敏捷式的游戏原型开发，就像是孕育自己的小孩一样，或许未必每次都会有美好的结果，但你总是能够从每次的经验中学到些什么新的东西。无论如何，这些过程与结果通常都非常好玩！整理以上四项内容，可以归纳出下列纲要：
准备：敏捷，是一种意向的状态
- 拥抱失败的可能性——它会鼓励开创性的风险承担
- 坚持实行极短的开发週期（更多的时间不等于更好的品质）
- 限制创意能够使你渴求更多
- 召集优秀的团队成员以及一位客观的顾问——思维与才能同样重要
- 平行开发以获得最大化的成果
设计：创意以及脑力激盪之谜
- 正式的脑力激盪程序只有 0% 的成功率
- 聚集概念美术与音乐以创造情感化的目标
- 在你的脑袋中模拟——前置开发你的原型
开发：没有人知道你如何达成，也没有人会在乎
- 首先建立玩具
- 在可接受的情况下使用伪装
- 终止你的损失并且学习如何断然捨弃
- 着重于游戏内容物无法救赎差劲的设计
- 整体美学仍然重要——运用有益的美术、声音与音乐
- 没有人会在乎你的伟大的工程技术
游戏性：官能领域中的「多汁」乐趣
- 复杂未必代表乐趣
- 创造出所有权的感觉使玩家想要获得更多
- 实验并不意味着复杂
- 朝向具有良好定义的目标建置开发
- 让它多汁！
在游戏开发领域中，游戏原型究竟具有什么样的重要性？在投入庞大的资源与人力之前，如果可以预先进行游戏概念或者核心机制的原型开发，不仅能够早期验证游戏设计的良窳与否，更有机会大幅降低专案开发时期的风险，避免到了专案中后期时才发现「这种玩法根本不有趣」的残酷事实，而只能够将已完成的游戏机制整个砍掉，然后重新来过。由知名游戏制作人 Will Wright 所主导的游戏《Spore》，在开发时期中甚至制作了上百款游戏原型，用以验证游戏中的各项设计机制与表现细节。他们也很大方地在游戏的官方网站上公开其中数款游戏原型，让感兴趣的玩家自行下载。
Super Tummy Bubble
之前偶然从 Gamasutra 的档案库里翻出这篇数年前的好文章，我觉得自己实在是非常非常地幸运！由这四位作者共同发起的 Experimental Gameplay Project，竟然能够在短短的一个学期内，完成超过 50 款游戏原型。不仅要在极为紧迫的週期内，完成游戏原型的开发工作，同时又要兼顾忙碌的研究所课业，一般人可能在制作出几个作品后就会产生放弃的念头，他们却能够保持纪律持之以恆地进行这项专案，绝对是一项相当难能可贵的成就。如果我是教授游戏开发课程的教师，我一定也会很乐意依循着这样的模式与原则，指导学生们进行如此具有乐趣与学习效果的游戏原型开发专案！
对于身处程式设计领域的人来说，即使你不知道如何制作精美的图片、不懂得如何谱出美妙的音乐，但只要你的脑袋里装满了「做出来应该会很有趣」的游戏点子，不妨大胆地放手一试吧！「左手只是辅助，工具也只是辅助。」不论你熟悉的开发工具是 OGRE、SDL、Torque 或者自己打造的引擎，条条大路通罗马，这些工具全都能够协助我们到达游戏开发疆土中的美丽境界。而对于美术、设计或具有其他专业的人来说，即使你所擅长的技能并不是程式设计，但只要能够学习使用 Flash 以及简单的 ActionScript 语法，同样能够以简单的工具创造出令人赞嘆的游戏原型。
以前的我，总认为如果想要制作一款游戏作品，必定要经过非常缜密的规划与周全的设计，才能够真正开始着手动工：「一定要有一个非常棒的游戏引擎，一定要有一个前无古人后无来者的游戏点子，一定要有一份超级详尽的游戏设计文件，一定要……」有许许多多的先决条件存在，一定要满足了这些条件以后，才能真正开始动手撰写游戏。但是过度的顾虑与计画，最后反而成为理想实践道路上的最大阻碍。所以与其戒慎恐惧而迟迟不敢跨出一步，不如豪迈地向前跨出步伐，大方拥抱包括失败在内的一切未知性与可能性吧！
阅读完这篇文章以后，给了我很大的鼓舞与激励，我也已经下定决心，准备要开始动手尝试游戏原型的实验开发计画。你呢？Happy Prototyping！ ：）