《How to Prototype a Game in Under 7 Days》:如何在七天内完成游戏原型

>>>  創業先鋒 眾人拾柴火焰高  >>> 簡體     傳統

prototype
(图片来源:www.refreshaustin.org)

原文出处:How to Prototype a Game in Under 7 Days: Tips and Tricks from 4 Grad Students Who Made Over 50 Games in 1 Semester

本文是於 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 款游戏原型作品这项近似於不可理喻且不可思议的目标,他们将自己锁在房间内,遵循着以下三项规则进行开发工作:

  1. 每个游戏必须在 7 天以内完成。

  2. 每个游戏必须从头到尾以 1 人之力完成。

  3. 每个游戏必须立基於一般常见的主题,例如「重力」、「植物」或「群聚生物」等等。

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
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
On A Rainy Day

在不断发想、制作以及发表原型作品的过程中,他们发现具有最高可重复游玩价值的游戏,是那些拥有某种创造或客制化层面的游戏,例如像是「用手和雨伞制造出一棵怪树」、「画出你的房子」、「建造你的高塔」或是「演化你的变异种族生物」等等游戏目标。只要提供给玩家独一无二的「所有权」感觉,就能够使他们满足而且想要获得更多的乐趣。实验并不意味着复杂。在这项计画的早期,他们所制作出来的游戏,往往远超过这些游戏应有的复杂度;不只是使用者介面令人困惑,而且按键对应至行动的方法也不够自然直觉。

对於以撰写程式为乐的人来说,请记得如果没有游戏性的目标,游戏原型就只是个「玩具」,而不是个「游戏」。所谓的游戏性目标,可以是任何东西,例如:在 X 时间内蒐集 Y 个元件,或是保持系统的稳定度,或是通过这个空间并且不触碰任何阻碍物体等等。而他们发现最佳的游戏目标,是如同《Tower of Goo》中与生俱来的游戏性,也就是不断地向上建造高塔而已。

最後,请记得让游戏看起来很「多汁」(Juicy)!「多汁」所代表的意思,就是游戏中接连不断而且丰富的「使用者回应」(User Feedback) 设计。当你碰触它的时候,多汁的游戏会跳动、摇动、喷射并且发出一点声响,让玩家感觉它像是活生生的,而且会对於你所做的每件事情做出回应。使用者回应是游戏中比较微小却非常关键的要素,能够让玩家感觉自己是真正掌控着游戏世界中的一举一动,并且藉由每次的互动行为,训练玩家逐渐熟悉游戏所制订的种种规则。

进行敏捷式的游戏原型开发,就像是孕育自己的小孩一样,或许未必每次都会有美好的结果,但你总是能够从每次的经验中学到些什麽新的东西。无论如何,这些过程与结果通常都非常好玩!整理以上四项内容,可以归纳出下列纲要:

准备:敏捷,是一种意向的状态

  • 拥抱失败的可能性——它会鼓励开创性的风险承担

  • 坚持实行极短的开发周期(更多的时间不等於更好的品质)

  • 限制创意能够使你渴求更多

  • 召集优秀的团队成员以及一位客观的顾问——思维与才能同样重要

  • 平行开发以获得最大化的成果

设计:创意以及脑力激荡之谜

  • 正式的脑力激荡程序只有 0% 的成功率

  • 聚集概念美术与音乐以创造情感化的目标

  • 在你的脑袋中模拟——前置开发你的原型

开发:没有人知道你如何达成,也没有人会在乎

  • 首先建立玩具

  • 在可接受的情况下使用伪装

  • 终止你的损失并且学习如何断然舍弃

  • 着重於游戏内容物无法救赎差劲的设计

  • 整体美学仍然重要——运用有益的美术、声音与音乐

  • 没有人会在乎你的伟大的工程技术

游戏性:官能领域中的「多汁」乐趣

  • 复杂未必代表乐趣

  • 创造出所有权的感觉使玩家想要获得更多

  • 实验并不意味着复杂

  • 朝向具有良好定义的目标建置开发

  • 让它多汁!

在游戏开发领域中,游戏原型究竟具有什麽样的重要性?在投入庞大的资源与人力之前,如果可以预先进行游戏概念或者核心机制的原型开发,不仅能够早期验证游戏设计的良窳与否,更有机会大幅降低专案开发时期的风险,避免到了专案中後期时才发现「这种玩法根本不有趣」的残酷事实,而只能够将已完成的游戏机制整个砍掉,然後重新来过。由知名游戏制作人 Will Wright 所主导的游戏《Spore》,在开发时期中甚至制作了上百款游戏原型,用以验证游戏中的各项设计机制与表现细节。他们也很大方地在游戏的官方网站上公开其中数款游戏原型,让感兴趣的玩家自行下载。

super-tummy-bubble
Super Tummy Bubble

之前偶然从 Gamasutra 的档案库里翻出这篇数年前的好文章,我觉得自己实在是非常非常地幸运!由这四位作者共同发起的 Experimental Gameplay Project,竟然能够在短短的一个学期内,完成超过 50 款游戏原型。不仅要在极为紧迫的周期内,完成游戏原型的开发工作,同时又要兼顾忙碌的研究所课业,一般人可能在制作出几个作品後就会产生放弃的念头,他们却能够保持纪律持之以恒地进行这项专案,绝对是一项相当难能可贵的成就。如果我是教授游戏开发课程的教师,我一定也会很乐意依循着这样的模式与原则,指导学生们进行如此具有乐趣与学习效果的游戏原型开发专案!

对於身处程式设计领域的人来说,即使你不知道如何制作精美的图片、不懂得如何谱出美妙的音乐,但只要你的脑袋里装满了「做出来应该会很有趣」的游戏点子,不妨大胆地放手一试吧!「左手只是辅助,工具也只是辅助。」不论你熟悉的开发工具是 OGRE、SDL、Torque 或者自己打造的引擎,条条大路通罗马,这些工具全都能够协助我们到达游戏开发疆土中的美丽境界。而对於美术、设计或具有其他专业的人来说,即使你所擅长的技能并不是程式设计,但只要能够学习使用 Flash 以及简单的 ActionScript 语法,同样能够以简单的工具创造出令人赞叹的游戏原型。

以前的我,总认为如果想要制作一款游戏作品,必定要经过非常缜密的规划与周全的设计,才能够真正开始着手动工:「一定要有一个非常棒的游戏引擎,一定要有一个前无古人後无来者的游戏点子,一定要有一份超级详尽的游戏设计文件,一定要……」有许许多多的先决条件存在,一定要满足了这些条件以後,才能真正开始动手撰写游戏。但是过度的顾虑与计画,最後反而成为理想实践道路上的最大阻碍。所以与其戒慎恐惧而迟迟不敢跨出一步,不如豪迈地向前跨出步伐,大方拥抱包括失败在内的一切未知性与可能性吧!

阅读完这篇文章以後,给了我很大的鼓舞与激励,我也已经下定决心,准备要开始动手尝试游戏原型的实验开发计画。你呢?Happy Prototyping! :)


猴子灵药 [Monkey Potion] 2015-08-25 16:41:49

[新一篇] 《World of Goo》:歡迎來到「咕」世界!

[舊一篇] 遊戲產業新門派(一):Casual Game
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表