如何在7天内快速完成游戏原型设计

2020-07-15 10:40 独孤残云阅读(592) 评论(0) 编辑收藏举报

原文链接：如何在7天内快速完成游戏原型设计

作者：Shalin Shodhan、Matt Kucic、Kyle Gray、Kyle Gabler

　　这是一个疯狂的游戏创意：用一大堆的纳豆似的黏黏球搭成一座高塔，越高越好。这些坏笑着的黑球一个踩着另一个地往上爬，直到抵达收集管口。这是一场小球与大球的斗争——如果你的塔堆得不够稳，它就会因地心引力而倒塌。《黏黏之塔》这款游戏在一个月内破天荒地超过了10万个下载，被某杂志封为”当月网络最佳游戏“。这些貌不惊人的小黏球因此登上G4电视频道、进入GDC大会的“Experimental Gameplay Workshop ”。其实《黏黏之塔》只是我们制作的50多个游戏中的一个，而这50多个游戏也只是我们在卡内基梅隆大学娱乐技术中心进行的娱乐游戏项目的一部分。

《黏黏之塔》的月下载量破10万大关(from gamasutra)

这50多个游戏都是1个人用仅仅1周的时间完成的。

2005年的春天，我们萌生了一个念头：发现并且快速原型化尽可能多的新型游戏玩法。四个大学生组成的项目小组运应而生。我们在房间里“闭关修炼“了一个学期。以下是我们的“修炼法则“：

1、每一款游戏的制作必须在7天以内。

2、每一款游戏只能由一个人独立完成。

3、每一款游戏都必须围绕共同的主题，如“重力”、“植物”、“群体”等等。

随着项目的运作，网站的流量水涨船高，吸引了游戏杂志和业内专家学者的目光，他们纷纷向我们求真相、求秘诀。

在此我们就把经验公之于众。根据下文提出的技巧、诀窍和例子，我们将探讨哪些方法管用，哪些方法无效。此外，我们还会告诉你如何养成制作原型的心态、如何组成有效的团队、如何在不确定时起步新构想。但愿我们的这些经过考验的指导能或多或少给你带来一点启发！

为了便于浏览阅读，所有的技巧和诀窍都规纳为四个部分：计划、设计、开发和常规玩法。

1、计划：速度是一种心态

快速原型在制作前期不止是一种实用工具，更是一种生活方式！以下我们来谈谈如何像个快速原型达人一样计划和思考。

从容接受失败的可能——鼓励接纳创意的风险

我们所谓的麻烦制造者就是”风险“。可以说，因为害怕失败，所以诞生了保守的电影改编或授权游戏。这就好比，你总是习惯性地选择麦当劳，而不是寻街窜巷地寻找新餐馆——因为众所周知的品牌总是比那些虽然可能供应美味食品的不知名小店更保险。

快速原型的达人应该明白失败没什么大不了！制作原型很大程度上就是为了找出失败的地方。如果你失败了，意味着你将吸取更多经验教训。所以，从容地接受失败的可能性，有益的实验探索才成为可能。

Gray：“《Mime After Mime》和《A Mime to Kill》是两款只有声音线索而没有图像线索的游戏。尽管它们都是大败笔，但整个团队由此证实了纯声音玩法的失败。我可以大方地承认，这是我的‘杰作’。因为我从整个项目中积累了经验，以后我可以大胆地冒险，因为我所冒的险都指向成功的方向。”

从容接受《Mime After Mime》和《A Mime to Kill》的失败(from gamasutra)

缩短开发周期（时间不等于质量！）

短短数天足矣。你理所当然地认为：“如果用一周的时间可以开发一款好游戏，那么，如果我们花了两周，游戏就应该好上加好！“当然，这不是真相。我们发现，通常情况下，1周的时间足够有效地完成任何游戏想法的原型。开发时间与成品效果成反比。例如有些原型的制作只需要1个晚上，而有些则需要耗费1周。我们惊讶地发现，开发时间与游戏的最终成功没有必然联系。

《Attack of the Killer Swarm》与《Suburban Brawl》对比图(from gamasutra)

如上对比图所示，《Attack of the Killer Swarm》（左）只用了一天时间就拼凑出来了，出乎意料地成为项目中得分最高的游戏之一。《Suburban Brawl》（右）多费了一个星期的精力去制作，结果却使游戏更加繁琐了；如果没有巨型杀手机器人（另一个时间和设计浪费），这款游戏也许会更有趣。

限制创意范围

我们最成功的游戏带有特定的主题，如“玩具”、“重力”、“群体”或“以女性休闲玩家为目标人群”。不知为何，当存在这种限制性条件时，创意反而更容易了。

另外，整个团队的人同时围绕一个特定的主题展开原型制作，一方面，我们可以保证避免撞上相同的玩法机制；另一方面，我们积极地探索所有游戏玩法的可能性，几乎涉猎了所有游戏主题。

在项目即将结束之际，我们抛开这种模式，结果被狠狠地教训了。所以我们得出的经验是：如果没有可靠的主题限制，游戏的制作时间将更漫长、方向更加摇摆不定，最终损害团体合作。“我们是密不可分的整体”这种感觉被冲淡了，甚至更惨，把激发创意和技艺的友好竞争的心态也毁掉了。

我们探索过的主题有“重力”、“弹簧”、“声音”、“掠食者和猎物”、“致瘾性游戏”、“绘图”、“指数增长”、“植物”、“平衡”等等等。

《Gravity Head》是一款克服重力头送玫瑰的游戏(from gamasutra)

组织一支优秀的团队加一名目标顾问——心态和才能同等重要

团队的各名成员必须对游戏开发的方方面面都感到舒心顺意。每个人都各自负责自己的编程、美工、音效等所有最终成品元素。这个各人才能的体现，但才能不等于一切。理想情况下，每个人都有必须带着设计本身是至高无上的理解参与开发工作——因为其他一切，从美术到引擎，都是服务于最终设计。欠缺这种心态的优秀工程师并不会比深谙此道的平庸工程师成功多少。

项目顾问Jesse Schell曾提到：“我总是痴迷于生成新游戏创意的过程，所以自然而然地，当 Shalin、Matt和 Kyles提议这个项目时，我心花怒放。抱着从中学到实用的游戏设计经验，我把这个项目当作在创意过程中同步进行控制性实验的尝试机会。作为学院顾问，我努力确保团队尝试若干不同的技术、从错误中吸取教训、避免固守无效的设计想法、找到个人最理想的创意途径。

我也对优化游戏提出建议，但基本上我只是旁观者。我有点儿像园丁——只是负责一点洒水和除草的工作，花朵怎么长完全靠自己。正如本文所示，这支队伍能够得出非常有用的结论，最终制作出一些非常棒的游戏！如何升级创意过程仍然有待进一步探索，卡内基梅隆娱乐技术中心打算继续开展这个项目。”

我们的团队，永远的游戏组合(from gamasutra)

同步开发

组成一支团队后，然后呢？我们不再孤军奋战了，但也不是并肩作战！也许听起来有点奇怪，但非合作的团队形式使我们受益匪浅：

1、风险消减：因为我们同时制作四个游戏原型，所以我们不怕冒险，至少有一两款非常可能成功吧！

2、友好竞争：“各人自扫门前雪”的合作确实对大家都好，跟资本主义的成长一个道理！

3、更广的主题探索：四个人的心思都放在同一个主题上，迫使我们深入探究各个主题。如果我们做的游戏都是一个模子出来的，那也太讽刺了吧！所以我们就不得不探索其他创意范围，避免“撞车”。

4、共享和关注：虽然我们并不共享代码（非必要条件），但我们发现分享概念和理解累积的知识非常有好处。比如，如果成员之一发现了展现弹簧系统的有效方法，所有人都能从共享中受益。

数周下来，我们还发现，团队合作在开发过程的初期效益最高——团队合作能够促进提炼和比较游戏创意。一旦开发进入正轨，因为各个成员都全心全意地投入到自己的工作中，大家就不会再受到其他成员的干扰。在周期的末尾，我们会回归团队，齐聚一堂直到友好竞争的最后一秒在晨光中消逝。以下是团队合作效益的曲线图。

value of working together(from gamasutra)

2、设计：创意与集体讨论的神话

绝妙的想法往往迸发在一瞬间，但等待灵感的火花闪现是一段很折磨的过程。世界上不存在能挤出创意的力量，但至少我们可以培养自己的创意精神。

常规的集体讨论，成功率为0

我们非常努力——我们真的希望集体讨论这种东西能管用！我们按时举行“头脑风暴”会议，我们在白板上尝试了不同的色彩标记和便利贴，我们甚至利用激发性短语，如”蓝天“，以帮助跳出框架进行创造性思考。但最终，我们制作的所有游戏，没有一款归功于大家团团围坐一起的集体讨论。

为什么？我们非常震惊，但经过多次研究发现，创意是没法规划的。你不能说：“嘿，4：15 是我们的头脑风暴时间，5：00我们将诞生4个了不起的游戏创意！”

但头脑风暴也非全无希望，组织妥善的集体讨论对话可以给你（至少）两个合理的指望。第一，让所有人都开动脑筋。之后，可能是开车回家、或者是冲凉、或者是遛狗的时候，头脑中灵光一现，伟大的游戏创意诞生了（游戏邦注：当然，也可能什么也没发生）。据我们所知，神秘的大脑通常是在你不怎么抱幻想的时候才积极地运转。

第二，当具体的问题摆在大家眼下时，头脑风暴式的会谈就能看出效果了。例如，“怎么改进这一点？”和“随便想点什么吧！”二者相比，显然前者更有探讨价值。又如，已知一个半成品的游戏创意，让团队的其他成员在集体讨论中继续充实它，往往能取得良好的效果。相对于创作者，人们通常更胜任批判者，对吧？

利用概念艺术和音乐激发情绪目标

除了集体讨论，我们发现带着个人意识去收集艺术和音乐也是卓有成效的方法。有人曾评论许多游戏，如《Gravity Head》和《On a Rainy Day》等创造了一种强烈的感性氛围，且具有强大的情绪激发能力。这绝非偶然。在许多情况下，声轨和初期美工创造了一种混合性感觉，这种感觉决定了之后的游戏玩法设定、剧情和最终美术风格。

Gabler：“走回家后，我正在欣赏Astor Piazzolla的《热情探戈》的开头时，突然冒出了《黏黏之塔》的创意。在我模糊的想像中，日落的天空下有一座塔，人们从自己的房子里拖出椅子、桌子和所有可以堆成高塔的东西，集合到市中心。我确实不知道为什么，但他们就是一心想往上爬、爬、爬——但他们不是合格的工程师，所以你得帮他们一把。游戏的最终原型更加活泼。我把最终音乐换成了Piazzolla的《自由探戈》，这一曲比前一曲的节奏更快。但最初的情绪基本上渲染完了整个游戏。”

在探戈音乐的氛围中，小人们奋力攀高……(from gamasutra)

脑内模拟——原型前期的原型

这太容易了！你要做的就是想象一下你的游戏玩家叫道：“哇！”然后继续填充空白的地方，即想象玩家为什么喜欢你的游戏？他们的感觉如何？游戏怎么让他们产生那种感觉？

我们最成功的游戏，好玩是理所当然的——在最理想的情况下，还没完成代码，我们就知道它肯定有趣，因为我们已经提前对游戏进行了想象性实验。反之亦然。从来没有什么游戏能够超脱我们的想象，突然地或出乎意料地就成功了。我们总是先知先觉。（游戏邦注：但不幸的是，这种先知先觉不能让我们坚持对半成品的创意深究。）

在头脑中模拟确实能简化最终原型的开发。因为你知道你将做什么，你不必浪费时间进行反复的测试性和错误性“设计决定”。

团队成员之一承认：“一周的头三四天，我们像傻子似地围坐着看O-Zone组合的音乐视频，巴望得到‘灵感’，或者在懒人沙发上东倒西歪地听着音乐，一边在脑中模拟游戏画面，这些都不算稀奇。最后，大约周四或周五，我痛苦了，因为我还是没法在周一交差，所以我就从所有想法中选了最强烈的那个，不管是什么，努力把它扩充至像个有趣的游戏就是了。然后，我彻夜不眠了若干天，把它的代码敲进电脑、画出精美的图案。对我而言，（我认为其实是我们四个）花在制作前期的时间毫无疑问，比实际开发的时间更有价值。”

《On a Rainy Day》的早期原型画稿——脑内模拟的实用参考(from gamasutra)

3、开发：没人知道、没人关心你怎么做

首先构建“玩具”

从核心机制开始。无论是弹簧系统、群体活动、引力还是其他等等，绝对不需要数小时来展示基本的游戏主题。所谓的“玩具”应该是游戏的核心机制减去所有目标或决断。没有输赢的差别，纯粹到是一款有趣的游戏。

Gabler:“《Super Tummy Bubble》的‘玩具’就是一堆悬浮在小容器中的泡泡。猛按这些泡泡一会儿之后，我彻底沉浸于戳泡泡的满足感之中，所以，是时候敲定其他游戏设定了。在此，游戏的特点就是寄生着不同虫子的泡泡、”爆“的概念、”链“的概念、计分器等等。”

《Super Tummy Bubble》——玩具（左）与最终原型（右）的对比(from gamasutra)

如果可以，那就蒙混过关吧

这个项目告诉我们最重要的一课是，“改正”法通常不是最佳解决方案。从战略上讲，蒙混可以节省时间和资金；可以使游戏运转得更快；可以让你的牙长得更白（你不会因为通宵加班而不刷牙了）。所以，自由随意地混吧！当简单的投影和光照纹理凑效（《Darwin Hill》）时，就不要使用复杂的光影效果。如果你可以用相同的效果来制作（《Suburban Brawl》），就不要设置复杂的图形识别系统来分析玩家的绘图。如果粗制的位图能够更快更容易地达到相同的效果（《黏黏之塔》），就不要画曲线或自创矢量图案库。我们发现这同样是一条不可思议的生活法则。懒人们，记下吧。

《Darwin Hill》、《Suburban Brawl》和《黏黏之塔》——都参与”造假“，但却没人注意到这一点(from gamasutra)

避免不必要的损失

项目运转之初，大家都力求圆满——耗费更多时间和精力确保一款糟糕的游戏能变成天才的杰作。例如，我们制作了一个弹簧系统，你可以挤压它、伸展它、摆弄它，但它就是没有长成一款吸引人的游戏。最初的弹簧系统不过数小时的时间就完成了，但之后它疯狂地吞噬了一整个星期的时间——不断地编码再编码，为的就是最终能把这个系统折腾成一款游戏。

你必须对走进死胡同的游戏创意保持先知先觉，然后尽可能减少自己的损失，不要在一个想法上死磕。正如我们所发现的，顺其自然远比大费周章地改写已有的代码更有价值。只要灵感在，就不怕返工回头。

Kucic：“我的‘土豆’是一个由 Flash做成的完美的软体模拟系统。美中不足的是，我没办法让它变得有趣。它让我头疼，浪费了一星期却毫无进展。你得知道什么时候坚持什么时候放弃。”

Matt的得意小土豆(from gamasutra)

再好的主题也不能挽救差劲的游戏

玩家远比你所想象的聪明，如果你耍花招，群从雪亮的目光绝不会放过你。如果游戏玩法太烂，那游戏就基本无药可救了——什么美工、音乐、周边搭卖全都无效。就像使用3D动画来掩饰拙笨的玩法机制，怎么可能逃过玩家的法眼？

Gray: “《Spin to Win》的玩法就在于转动鼠标来旋转圈圈——其实就是旋转唱片。为了掩饰无趣的事实，我大量使用《家有仙妻》似的风格和音乐扩充游戏的主题。但无论我怎么打磨这款游戏，它就是成不了发光的金子。尽管我对它寄予厚望，它还是很快沦为我们的网站上最令人讨厌的游戏。”

《Spin to Win》外表华丽，玩法拙劣(from gamasutra)

合理利用美术设计、音效和音乐

这点其实有悖于我们最初的一个假想。我们曾认为美术设计和音效对游戏本身不能起多大的作用，但我们错了！外部效果惊艳的游戏确实比内部代码上乘但外部设计粗陋的游戏更加引人注目。你要记住的是，优化美术设计仍然不能挽救失败的整体设计，但它确实能让原本不错的游戏锦上添花。这不是说你需要梦幻般华美的画面或高超的立体音效，而是，你可以把一切合理的元素组合成紧密联系的整体。记住，甚至“蹩脚”也可能通过合理使用其他元素而实现美学上的成功。

未发布的原型——美术设计没必要搞得那么精致(from gamasutra)

玩家不关心你的代码

出色的工程师未必就是杰出的原型师。我们往往不能单纯地指望用“正确的”或“可重复利用”的解决方案来对付一次性的代码。对于任何问题，你应该想出尽可能多的解决方案，以达到兵来将挡、水来土淹的效果，也就是要快！终端用户从来就不看你伟大的代码，并且他们从来就不关心。

Shodhan：“过分的代码设计，往往沦为平庸的工具或技术演示。这好比一个摇滚巨星自顾自地沉浸在自己非凡的技艺之中，毫不理会台下的听众早已昏昏欲睡！对于”进化“主题，我编了一个通过杂交祖辈树种来实现进化的3D效果。这其中运用了大量先进的技术，但和游戏性没有半点关系！”

《Evolution Trees》——技术不能增加乐趣(from gamasutra)

4、常规玩法：乐趣的感性课程

除了煞费苦心地学成快速原型，我们还要突破一些常规玩法。以下列举了一些增加游戏“乐趣”的经验。

复杂未必有趣

数千年以来，各种各样的“球体与平面”的变体游戏就已经满足了人们自娱自乐的需要，而今，我们大概在新奇的电子游戏领域里努力过头了。人类完全有可能从最基本的几何体中收获乐趣，想想《俄罗斯方块》、《吃豆人》和其他经典的街机游戏。正如《罗密欧与朱丽叶》的爱情故事原型总是被反复翻用，这些游戏的机制如此经典，所以数十年以来我们乐些不疲。镜头光晕、凹凸贴图、摄相机等新技术虽然效果惊人，但并没有使游戏更加有趣。如果你能让自己坚信核心机制只是一个简单的原型，那么你一定可以把游戏原型做得很好。

创造一种拥有的感觉

在非常偶然的情况下，我们发现能重复玩的游戏通常带有某些自创或自定义特征。例如，“用手臂和伞做一棵吓人的树”、“我画我家”，又或者“自成一塔”、再或者“独家变形物种进化”。显然，你可以在许多游戏的自定义头像、自定义手机铃声和“展现独特的自我”似的广告营销中发现这种众所周知的现象。所以，紧跟潮流走吧！让玩家产生一种拥有的感觉，从而成为游戏的“回头客”。

《Darwin Hill》——所有人都是独一无二的(from gamasutra)

“实验性”不等于“复杂性”

在项目早期，我们所做的许多游戏都太过复杂。不仅UI令人迷惑不解，而且动作输入也很别扭。除非我们可以在玩家搞清游戏之前就缩减玩家的摸索时间，否则玩家就可能大受打击，再也不会玩这款游戏，甚至再也不光顾我们的网站。所幸，我们发现游戏可以具有实验性，且仍然通俗易懂。

Shodhan: “我的第一个回合游戏《Spaceball Munc》是一个3D版的老式“大猩猩”游戏——玩家指定一个角度和一个力度，一只猩猩据此向另一只猩猩投掷香蕉。现在这款游戏不仅是3D的，而且还有弧形视角和球面力场。所以玩家就要兼顾两个角度和一个力度。当然，现在它不是回合制游戏了，所以你得控制连续性系统的同时，必须击中所有移动中的物品。以下截图是关于物品被抛掷后的变化过程。

《Spaceball Munch》——捉摸不透的玩法？(from gamasutra)

朝着明确的目标前进

令人难堪的是，明确的目标总是容易被遗忘。如果没有玩法目标，原型就只是个玩具，称不上真正意义上的游戏。出于某些原因，人们看似享受失败的感觉。什么形式都可以看作目标——如“在某时间段内收集到多少多少工具”、或“保持系统稳定”、或“安然越过某空间”，但要找到一个不让人觉得突兀的目标（如时限），谈何容易？最佳目标是游戏玩法的固有部分，如《黏黏之塔》的隐藏目标就是单纯地”搭建“。

《黏黏之塔》——达到目标，超越目标！(from gamasutra)

游戏的“活力”

有“活力”的游戏就好像，当你触及它们时，会弹起、扭动并发出一点声响。有活力的游戏如有生命，能对你的所做所为做出反应——最小的用户输入换取最多的回应。它让玩家感到对游戏世界的掌控感，从而训练他们逐渐学会每一条游戏规则。

有些活力四射的例子你大概有所耳闻：

《 Alien Hominid 》：UFO坠毁在FBI门口之后发生的FBI与ET之间的战斗，邪恶的血肉横飞。

《超级马里奥》：在一个充满金币的空间里上蹦下跳，金光闪闪啊。

《弹球盘》：控制不断涌出的球体。

《 Super Puzzle Fighter II Turbo》：一款日式卡通风格的益智方块游戏。

这些充满“活力”的游戏让玩家爱不释手(from gamasutra)

后记

实验游戏玩法项目小组的合作令人热血沸腾。我们希望下次你尝试新事物时，我们的小技巧能够派上用场。也许眼下你正在做的小事也有可能变成惊天神作呢。叫上些朋友或者单枪匹马，着手制作游戏原型吧！你会让自己都感到出乎意料。

我们的项目顾问指出：“快速原型非常像十月怀胎，没人敢担保肚子里的孩子一定是人中龙凤，但你总是能从中得到新收获和许多乐趣！”

最后，享受快速原型的乐趣！

游戏邦注：原文发表于2005年10月26日，所涉数据及时间均以当时为准。（本文为游戏邦/gamerboom.com编译，如需转载请联系：游戏邦）

How to Prototype a Game in Under 7 Days

by Shalin Shodhan, Matt Kucic, Kyle Gray, Kyle Gabler

Here’s a crazy game idea: Drag trash-talkin’ gobs of goo to build a giant tower higher and higher. They squirm and giggle and climb upward over the backs of their brothers, but be careful! A constant battle against gravity, if you build a tower that’s too unstable, it will all fall down. “Tower of Goo” was downloaded over 100,000 times within months of hitting the net, it was dubbed “Internet Game of the Month” in one magazine, it was demoed on G4 and at the Experimental Gameplay Workshop at GDC, and it was one of over fifty games we made as a part of the Experimental Gameplay Project at Carnegie Mellon’s Entertainment Technology Center.
And like the rest of them, it was made in under a week, by one person.

The project started in Spring 2005 with the goal of discovering and rapidly prototyping as many new forms of gameplay as possible. A team of four grad students, we locked ourselves in a room for a semester with three rules:

“Tower of Goo” was downloaded over 100,000 times within months of hitting the net.

1. Each game must be made in less than seven days,

2. Each game must be made by exactly one person,

3. Each game must be based around a common theme i.e. “gravity”, “vegetation”, “swarms”, etc.

As the project progressed, we were amazed and thrilled with the onslaught of web traffic, with the attention from gaming magazines, and with industry professionals and academics all asking the same questions, “How are you making these games so quickly?” and “How can we do it too?”

We lay it all out here. Through the following tips, tricks, and examples, we will discuss the methods that worked and those that didn’t. We will show you how to slip into a rapid prototyping state of mind, how to set up an effective team, and where to start if you’ve thought about making something new, but weren’t sure how. We hope these well-tested guidelines come in useful for you and your next project, big or small!

For easy browsing, all tips and tricks are organized into four sections: Setup, Design, Development, and General Gameplay. Enjoy!

1. Setup: Rapid is a State of Mind

Rapid prototyping is more than just a useful tool in pre-production – it can be a way of life! This section will show how to set up and begin thinking like a rapid prototyper.

Embrace the Possibility of Failure – it Encourages Creative Risk Taking

It’s all about that little trouble-maker we call “risk”. Fear of failure, as far as we can tell, is the reason why movie licenses and double digit franchise games keep getting made. It’s like always choosing to go to McDonalds instead of an unexplored new restaurant – always safer to rely on a well-known adequate option rather than take that risky plunge into the unknown but potentially delicious.

A good rapid prototyper would realize that failure is ok! That’s what prototyping is for, so go crazy! If you fail, there will be dozens more, and chances are, you’ll learn something anyway. By embracing the possibility of failure, rewarding experimentation becomes possible.

Mr. Gray: “Mime After Mime” and “A Mime to Kill” were two games I made that attempted gameplay using only positional audio cues with no visuals. Although they were utter failures, the whole team was thrilled to take such a bold risk to prove the failure of audio-only gameplay, and I could point with pride to my hideous creations. As I gathered experience throughout the project, I was able to take more directed risks that lead to successful games.”

Enforce Short Development Cycles (More Time != More Quality)

You only need a few days. It seems like a natural and comforting thing to say, “Hey we made a great game in one week. Therefore, if we spend TWO weeks, it will be TWICE as good!” Of course this isn’t the case. We found that generally any gameplay idea can be prototyped effectively in less than one week. Extra slop time tends to yield diminishing returns. Some prototypes, for instance, took just a single evening to throw together, while others got an extra week or two of love. Surprisingly, we found that there was no correlation between time spent in development and how successful the game ultimately turned out.

Constrain Creativity to Make You Want it Even More

Our most successful games grew out of specific themes or “toys”, like “gravity” or “swarming” or “make a game targeted towards a predominantly female casual gamer demographic”. Somehow, it became easier to be creative when there were restrictions in place.

Additionally, with a team of people all simultaneously generating prototypes around a particular theme, there was some guarantee we would avoid attacking the same obvious gameplay mechanics. Instead, we were challenged to explore and really suck the theme dry for all possible gameplay uses.

We moved away from this model towards the end of the project, ultimately to our detriment. Without solid thematic constraints, the games took longer to create, had less direction, and group unity deteriorated. There was less a feeling of “we’re all in it together”, and even worse, we lost the sense of friendly competition that was responsible for squeezing out those extra drops of creativity and finesse.

Some of the themes we explored were: “gravity”, “springs”, “evolution”, “sound”, “predator and prey”, “addictive games”, “drawing”, “exponential growth”, “vegetation”, “balance”, and a few others individually.

Gather a Kickass Team and an Objective Advisor – Mindset is as Important as Talent

Each member of the team had to be comfortable with all aspects of game development. Everyone was responsible for their own programming, art, sound, and everything else that went into the final product. But talent wasn’t everything. Ideally, it was important for everyone to approach this style of development with the understanding that design is paramount – everything else from art to engineering exists only to serve the final design. A great engineer without this mindset would likely be less successful than a mediocre engineer who fully understands this point.

A word from Jesse Schell, project advisor: “I am always fascinated by the creative process for generating new game ideas, and so naturally I was thrilled when Shalin, Matt, and the Kyles proposed this project. I looked at it as an opportunity to try side-by-side controlled experiments in creativity, hoping there would be useful game design lessons learned. As faculty advisor, I tried to make sure that the team tried several different techniques, that the team was learning from their mistakes, that no one dwelled too long on an idea that wasn’t working out, and that each individual was finding their optimal creative process.

“I gave suggestions along the way about how to improve the games as well, but mostly I tried to stay out of the way. I felt a bit like a gardener — I did a little watering and weeding, but the flowering was all up to them. As this paper shows, the team was able to make some very useful conclusions – and ended up with some good games to boot! There is still more to learn about optimizing the creative process, and the Carnegie Mellon Entertainment Technology Center plans to continue this project.”

Develop in Parallel for Maximum Splatter

So once we assembled our team, what did we do? We stop working with each other! It might sound odd, but the benefits of not collaborating were too great to ignore:

Risk Mitigation – By developing four prototypes simultaneously, we could make risky design decisions with the comfort that at least one or two were likely to be successful

Friendly Competition – Everyone benefited from being kept on their toes. Like capitalism!

Wider Thematic Exploration – Four minds all focused on the same theme forced us to plumb the depths of each topic. How embarrassing it would be if we all made the same game! This forced us into some rewarding creative realms and allowed us to avoid obvious points of attack.

Sharing and Caring – Though we didn’t share code (by choice, not requirement), we found it helpful to share concepts and understanding into a cumulative pool of knowledge. If one team member, for instance, discovered an effective way to represent spring systems, everyone would benefit.

As the weeks wore on, we found that having the team work together was most valuable at the beginnings and ends of each cycle. In the beginning of each cycle, the team was useful for helping to solidify and compare ideas. Once we hit development, we found each other to be more of a distraction than anything else – as each person was fully immersed in their own efforts. By the end of each cycle, we would all return to the room and work together until the wee hours of the morning for that last-minute extra taste of competition. A graph of this phenomenon might look something like this:

2. Design: Creativity and the Myth of Brainstorming

A great idea takes a split second to happen, but waiting for that lightning to strike can be excruciating. There’s no such thing as forcing a great idea to squirt out, but this section should help cultivate your creative juices.

Formal Brainstorming Has a 0% Success Rate

We tried hard – boy we really wanted brainstorming to work! We scheduled “brainstorm meetings”, and “powwows”, we tried different color markers on whiteboards and oversized post-it notes, we even used motivational phrases like “blue sky” to help with our “out of the box thinking.” But in the end, out of all the games we created, not a single one was the result of sitting down as a group for a brainstorm session.

Why not? This was all very shocking to us, but after much investigation, it appears that you just cannot schedule creativity. You cannot say, “Hey everybody let’s meet for a brainstormer at 4:15, and by 5:00 we’ll have 4 kick-ass game ideas ready to hit the ground running!”

But it’s not hopeless. There are still (at least) two reasonable things you can expect from a well-conducted brainstorm session. The first, of course, is that it gets everybody thinking. And then sometime later, maybe on the drive home, or in the shower, or while taking Poopy for a walk, a brilliant idea will erupt in your head. Or maybe not. But as far as we can tell, your mysterious brain does a lot of thinking when you least expect it.

The second way we found brainstorming to be useful was when there was something concrete to talk about. For example, “How can we improve this?” as opposed to “Hey let’s come up with something arbitrary!” Given a half-formed game idea, for instance, it was moderately helpful to run it by the rest of the group to flesh it out.

Everyone is a better critic than a creator, right?

Gather Concept Art and Music to Create an Emotional Target

As an alternative to brainstorming, we found that gathering art and music with some personal significance was particularly fruitful. People have commented that many of the games like “Gravity Head” or “On a Rainy Day” create a strong mood and have strong emotional appeal. It’s no accident. In these and many other cases, the soundtrack and initial art created a combined feeling that drove much of the gameplay decisions, story, and final art.

Mr. Gabler: “The idea behind “Tower of Goo” came up while I was listening to (for some reason) the opening to Astor Piazzolla’s “Tango Apasionado” after walking home, and had this drizzly vision of a town at sunset where everyone was leaving their houses, carrying out chairs, tables, and anything they could to build a giant tower in the center of their city. I didn’t know why exactly, but they wanted to climb up and up and up – but they weren’t very good civil engineers so you had to help them. The final prototype ended up a little more cheery, and I replaced the final music with Piazzolla’s more upbeat “Libertango”, but here’s a case where an initial emotional target basically wrote the entire game.”

Simulate in Your Head – Pre-Prototype the Prototype

It’s really easy! All you have to do is imagine your game audience saying, “Wow!” And then just work backward and fill in the blanks. What’s making them enjoy your game? What emotion are they feeling? What is happening in the game to make them feel that way?

For each of our most successful games, it was never a surprise when they ended up being fun to play – in the best cases, we knew before touching a line of code that the idea was solid, because we had run a simulation of the game as a little thought experiment beforehand. The reverse is also true. There was no game that accidentally or unexpectedly became successful. We always knew ahead of time. (Unfortunately this didn’t keep us from pursuing half-baked ideas.)

Simulating in your head also makes the development of the final prototype really easy. Since you will know exactly what you will be making, you won’t waste time making expensive trial and error “design decisions” by noodling around in code.

One team member admits: “It wasn’t unusual to blow the first 3 or 4 days of the week just fooling around watching O-Zone music videos for “inspiration” or propped upside down in a bean bag listening to music and filling my head with blood occasionally running some crappy brain simulations. Finally Thursday or Friday would roll around and I’d panic because I still had no idea what to turn in for Monday, so I’d take the strongest of the ideas and tweak it based on whatever the obsession of the week was until it felt like a fun game, then stay awake for the next few days typing it all into a computer and drawing beautiful pictures. For me, (and I think all of us) the days spent in “pre-production” were unquestionably more valuable that the days spent in actual development.”

3. Development: Nobody Knows How You Made it, and Nobody Cares

Once you come up with a great idea, here are some tricks to whip up a little demo in no time!

Build the Toy First

Start with the core mechanic. Whether spring systems, swarm behavior, gravity, etc, it never took more than a few hours to get the basic theme up and running. This “toy” should be the core mechanic of the game minus any goals or decisions. There is no win or lose state, just a fun thing to play with.

Mr. Gabler: “With “Super Tummy Bubble”, the “toy” was just a bunch of bubbles suspended in a little container. After playing with the toy and flinging bubbles around for a while, I got it tuned to a point where sticking my fingers in bubbles felt really satisfying, so it was time to slap on some gameplay. Gameplay features in this case were bubbles of different parasite types, a concept of “popping”, a concept of “chains”, score counters, etc.”

If You Can Get Away With it, Fake it

This is arguably one of the most important lessons of the project. Often the “correct” solution is not the best solution. Strategically faking it will save you time and money; it will make your game faster, and your teeth whiter. Fake it liberally and often! Don’t set up complicated lighting and shadowing when a simple drop shadow and baked textures will be just as effective (“Darwin Hill”). Don’t set up a complicated pattern recognition system for analyzing a user’s drawings when you can fudge it with the same effect (“Suburban Brawl”). Don’t draw splines or create your own vector art library when quickie stretched bitmaps give same effect faster and easier (“Tower of Goo”). This rule is also a fantastic general lesson for life, we have found. Slackers, take note.

Cut Your Losses and “Learn When to Shoot Your Baby in the Crib”

At the beginning of the project there was a desire to salvage everything – a little more time and effort and surely a crappy game would become a work of genius! One such doomed prototype began as a beautiful spring system that squished and stretched and made you want to grab it and pull it all over the place, but it just wasn’t become a compelling game. The original spring system mechanic took just a few hours to create, but then it flared and consumed an additional wasted week of coding and re-coding in a sad attempt to force the mechanic into becoming a game.

It’s important to quickly recognize dead-end game ideas, cut your losses and move on. As we found, spontaneity is more valuable than time spent trying to salvage existing code. You can always come back if lighting strikes at a later time.

Mr. Kucic: “My “Potato” ended up being a perfectly simulated soft body system built in Flash. The only problem was that it was in no way fun. It caused more headaches than death metal, wasted a week, and it didn’t even really move. You’ve got to know when to hold ‘em and know when to fold ‘em.”

Heavy Theming Will Not Salvage Bad Design (or “You Can’t Polish a Turd”)

We found that game players are smarter than you think, and they can tell when you’re pulling a fast one on them. If the gameplay is horrible, there is no recovery – all the art, music, and product tie-ins in the world won’t make it a great game. Like taking a stale gameplay mechanic and slapping the latest 3D animated movie characters on it, nobody will be fooled.

Mr. Gray: “With “Spin to Win”, the ‘gameplay’ was to rotate your mouse to spin multiple circles – literally disc spinning. To hide the fact that it wasn’t fun, I heavily themed the game with a ’60s Bewitched art style and music. But no matter how much I polished the game, it still wouldn’t shine. Despite all the extra love, it quickly became one of the site’s most hated games.”

But Overall Aesthetic Matters! Apply a Healthy Spread of Art, Sound, and Music

This is actually counter to one of our original hypotheses. We didn’t think art or sound would make any difference at all, but we were wrong! Playing with a well-polished game actually feels better in your hands than playing the exact same code but with careless art and poor sound. It is important to make the following distinction though – polishing the aesthetic (as in the above section) will still not salvage bad design, but it does have the power to make a good game even more playable. This does not mean that you need fancy graphics or surround sound. It does mean that you can benefit from pulling everything together into a tight cohesive compositional package. Remember, even “crappy” can be a tight winning aesthetic if you frame it the right way.

Nobody Cares About Your Great Engineering

Again, it’s worth noting that a great engineer does not necessarily make a great prototyper. “Correct” or “reusable” solutions are often not what we look for in quick throwaway code. For every problem, you should be able to come up with a large handful of solutions and be prepared to pick the one that gets the job done – fast. The end user will never see your great engineering, and they don’t care.

Mr. Shodhan: “By over-engineering, it’s easy to end up with generic tools or technology demos that never translate into something playable. This can be likened to a rock star executing a technically brilliant but entirely self-indulgent guitar solo that leaves the audience yawning! For the “evolution” round, I made a program with subdivision surfaces and a cell shaded look for evolving 3D models by cross breeding ancestry trees. There was a lot of cool technology, but it had absolutely no gameplay!”

4. General Gameplay: Sensual Lessons in Juicy Fun

In addition to learning the hard way about rapid prototyping, we also stumbled over some general gameplay guidelines. The following are a collection of some that significantly add to that “fun” experience.

Complexity is Not Necessary for Fun

If mankind can entertain itself for literally thousands of years with variations on the theme of “ball and a flat surface”, we might be trying too hard with some of this new-fangled video game stuff. It’s entirely possible to have fun with basic primitives, think Tetris, Pac-Man, and any classic arcade game. Like the Romeo and Juliet love story archetype, these games had mechanics so good we’re still reusing them again and again decades later. Lens flares, bump mapping, camera bloom, and other amazing new technologies are nice, but won’t make your game more fun. Prove to yourself that your core mechanic is worthwhile with a simple prototype. Once you’re convinced, then you can make it pretty.

Create a Sense of Ownership to Keep ‘em Crawling Back for More

We discovered quite accidentally that the games with the greatest replay value were the ones that had some sort of creation or customization aspect. For instance, “make a creepy tree out of hands and umbrellas”, or “draw your own house”, or “build your own tower”, or “evolve your own race of mutated creatures”. Apparently this is a well-known phenomenon and has something to do with all those create-a-face features common in many recent games, and customizable cell-phone ring tones, and those “be different, express yourself like everyone else” advertising campaigns. So jump on the bandwagon! Create a sense of ownership to keep ‘em crawling back for more.

“Experimental” Does Not Mean “Complex”

Early in the project, many of the games we made were far more complicated then they should have been. Not only was the UI confusing, but the ways in which keys mapped to actions were not natural or intuitive. Unless we could minimize the confusion time before the “oh I get it” moment, we knew we risked that players would get frustrated and never play the game again and possibly never come back to our site. Luckily, we found it was possible to be “experimental”, and still be easy to understand.

Mr. Shodhan: “My first round game “Spaceball Munch” was a 3D version of the old “Gorillas” game where you specify an angle and a velocity at which one gorilla throws a banana at another. Not only were you now in 3D, but there was arc ball camera rotation and the game was on a spherical field. So there were two angles and a velocity to worry about. Oh, and it was no longer a discrete turn-based game but you controlled a continuous stream of particles and had to hit all these moving objects. Here is a screen shot of the gratuitous variable wastage.”

Build Toward a Well Defined Goal

A well defined goal was embarrassingly easy to forget about. Without a gameplay goal, a prototype is just a toy – not a game. For some reason, people seem to enjoy having the opportunity to fail. A goal can be anything – like “collect x number widgets in a x amount of time,” or “keep the system stable,” or “traverse a space without touching anything bad,” but it was difficult finding a goal that didn’t feel a little tacked on, (like anything involving a “time limit”). The best goals, we found, were an innate part of the gameplay like in “Tower of Goo,” where the implicit goal was to simply “build up”.

“Tower of Goo” – building toward a goal… and beyond!

Make it Juicy!

“Juice” was our wet little term for constant and bountiful user feedback. A juicy game element will bounce and wiggle and squirt and make a little noise when you touch it. A juicy game feels alive and responds to everything you do – tons of cascading action and response for minimal user input. It makes the player feel powerful and in control of the world, and it coaches them through the rules of the game by constantly letting them know on a per-interaction basis how they are doing.
Some juicy examples you may have experienced might include:

Alien Hominid – enemies exploding and flinging blood to an almost unjustified extent

Mario Bros. – bouncing through a room full of coins, blinging with satisfaction

Pachinko – a never-ending gush of balls all under your control

Super Puzzle Fighter II Turbo – animation and sprites abound on multiple chains

Juice feel sgreat!You can’t keep your hands out of it.

Final Thoughts

The Experimental Gameplay Project team was a thrill to work with. We hope that the next time you try something new or a little crazy these tips and tricks come in useful for you. Who knows, that little idea you had this morning could be the next big thing. Pull some friends together, or go solo, but try and prototype it! You might surprise yourself.

Our objective advisor kindly pointed out, “Rapid prototyping can be a lot like conceiving a child. No one expects a winner every time, but you always walk away having learned something new, and it’s usually a lot of fun!”

Happy prototyping!

Handy Cut-Out List!

Setup: Rapid is a State of Mind