游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

热门游戏《Casey’s Contraptions》设计分析报告

发布时间:2011-06-24 12:10:03 Tags:,,

作者:Miguel Ángel Friginal, Noel Llopis

制作成功iOS游戏并非想象中那样简单。在这篇事后分析报告中,开发者Noel Llopis和Miguel Ángel Friginal解析如何制作出简单且设计精巧的休闲游戏并让其位列榜单第二位。以下是游戏邦编译的相关内容:

《Casey’s Contraptions》这款iOS游戏出自我们二人之手。经验丰富的Noel从事该行业已有十数年,4年前转型为独立开发者,凭借iOS系统微交易游戏《Flower Garden》获得成功。Miguel在成为网页开发者之前,曾在广告行业做过几年图形设计。他制作的首款纸上角色扮演游戏面世已将近20年,但《Casey’s Contraptions》是其发行的首个电子游戏。

数年前,我们通过Twitter相识,随后在某次360iDev大会上见面。先前我们并没有合作的计划,但后来我们在Game Jam活动(游戏邦注:参加者在有限的时间内做出一款游戏)中配合制作游戏,这为我们在未来项目中的合作奠定了基础。我们知道自己的下个项目会以iOS为目标,因为不管从用户还是开发者的角度出发,我们都很喜欢这个平台,而且这个平台有可能让独立开发者取得成功。尽管如此,开发新游戏并非简单的事情。

虽然我们有大量可供选择的想法,但敲定具体游戏想法往往是件非常困难的事情。我们想要的东西需满足三个要求:游戏要在本质上富有创意性,不再将破坏作为主要的可玩性元素;游戏应该让我们对开发充满激情;游戏必须有在iOS应用商店上获得可观盈利的潜力。不过,做游戏可比说要难得多!

我们依次为每个游戏想法构建原型,尽管许多想法都不差,但并没有完全合适的主题。在制作出7到8个不同原型后,我们最终定下的概念是制作基于物理学的鲁布·戈德堡式奇妙装置来解决不同的谜题。游戏的核心机制类似某些经典游戏,比如《The Incredible Machine》,但其强调的是对各种创意性解决方案的探索,而并非找寻每个谜题的唯一正确答案。游戏设计围绕与经典游戏的共同点展开,在iOS触摸界面上重新架构整个框架。

我们两人在项目中各占一半,没有任何外部投资或发行商支持。Miguel辞去全职工作来做《Casey’s Contraptions》美工部分的内容,Noel负责编程。设计是种合作性行为,我们两人在游戏中的投入几乎相同,包括规则设计、游戏感觉和关卡制作等各个方面。凭借我们的个人能力和专业技能,在网站、服务器后端和公共关系等方面也有所投入。本文并非真正的事后报告,更像是发布后的分析。现在的游戏更像服务而不是产品,尤其是iOS和Facebook游戏。开发和发布只是开端而已。如果所有事态进展顺利,数月内我们还会总结更多有关《Casey’s Contraptions》的内容。

正确的做法

1、强大的主题和风格

其实,《Casey’s Contraptions》最初想法中并不包含Casey!原型只关注游戏中的奇妙装置制作和物理模拟。这种想法的潜力很大,但缺乏某些让它脱颖而出的东西。游戏需要更多个性化内容。

Pre-Casey level goals(from gamasutra.com)

出现Casey之前的关卡目标(from gamasutra.com)

集思广益之后,我们迅速萌生出让一个聪明的8岁小孩来建造这些奇妙装置的想法。这不仅为游戏添加了最缺乏的个性化内容,而且还对其他开发进程有所帮助。我们想做的不是由滑轮、杠杆和其他工业化道具组成的物理游戏,道具主要是Casey可以拿到的玩具和家用产品,比如妹妹的玩偶、纸飞机或他自己的遥控卡车等。

加入 Casey之后的关卡目标(from gamasutra.com)

加入 Casey之后的关卡目标(from gamasutra.com)

选择将玩具作为游戏道具会对关卡设计和关卡目标产生影响。最初,我们想将关卡任务制作成Casey需要在现实生活中处理的问题,比如收拾玩具或弄破气球。不久之后,我们产生制作“娱乐”关卡的想法,场景和目标完全虚构,就像Casey有可能在娱乐时间中想象出的那样,比如从坠落于丛林中的热气球中解救出探险者。

原形目标-- 捅破汽球(from gamasutra.com)

原形目标-- 捅破汽球(from gamasutra.com)

角色Casey的出现也明确了美术设计的方向。我们想要制作出对各类用户都存在吸引力的作品,从幼龄儿童到成年休闲游戏玩家。在设计期间,Miguel对各种艺术做了充分调查,包括现代卡通网络风格动画、漫画、华纳兄弟公司作品等。最后我们决定结合《Calvin & Hobbes》(游戏邦注:美国漫画作品)和上世纪50年代的Hanna-Barbera动画,采用强有力的轮廓和纯色调,让各个年龄段的人都觉得此类视觉效果极为舒适。我们可以在游戏中所有道具、地点和用户界面中使用这种独特的风格,为用户提供统一且独特的视觉效果。

Casey形象演变(from gamasutra.com)

Casey形象演变(from gamasutra.com)

2、社交功能

制作东西很有趣,制作东西并且与他人分享会使趣味性翻倍。自开发之初,我们就想让《Casey’s Contraptions》充满社交体验。这不像某些你玩过后就抛弃的游戏,你可以在游戏过程中与朋友分享内容。

由于《Casey’s Contraptions》的核心机制是全物理模拟,因而多数谜题都可能有非常独特、奇怪或出乎意料之外的解决方案。即便在游戏发布数周后,有些人解决某些关卡谜题的做法仍令我们瞠目结舌,采用的道具组合方式是我们在开发过程中从未想到的。这些解决方案非常独特而且看起来相当有趣,所以它们是与朋友分享的绝佳素材。

带着这种想法,我们在游戏开发伊始便设计分享功能。你通过每个关卡后,只需点击一个按键就可以与所有朋友分享你的解决方案(游戏邦注:近期更新中,游戏默认在分数提高后自动提交解决方案)。同样,你也可以看到朋友的解决方案。在通关界面上点击任意解决方案可以看到全屏视图,你可以重放并观看整个解决方案的内容。

除共享解决方案外,游戏中还有关卡编辑器,玩家可以拖放物品自行制作奇妙装置。游戏中所有预设关卡都是用相同的关卡编辑器制作而成。最初,玩家可以通过邮件来分享这些关卡。在首次游戏更新中,我们还添加了通过网站公开分享的功能,使玩家可以轻易获得数百个新关卡。我们担心只有少数玩家会花时间来自行制作奇妙装置,这是多数带有关卡编辑器的游戏中普遍存在的问题。但那些玩家才是真正投入到游戏中的人,他们会毅然决然地向外界和朋友推广游戏。

3、重复开发

《Casey’s Contraptions》的重复开发彻底且充满随意性。重复开发的周期很短,每次重复开发旨在完全呈现我们当时认为最重要的功能。

我们并没有进行过真正的任务预估,也从未硬性规定重复开发的时间,通常都在1周半至3周之间。最重要的是,每次重复开发之前我们都会先根据当时掌握的所有知识来决定好接下来要做的事情。比如,在我们还未想出游戏中应该含有的道具之前,不会草率制作项目。我们在维基网上有个可采纳道具列表,在开发过程中随时可以将想到的新道具添加进去,每次重复开发之初我们只要决定在游戏中添加哪些新道具即可。

重复开发时所掌握的内容有助于我们做出好决策,比如“目前游戏中多数物品很容易倒塌,我们需要增加更多有支撑力的道具。”或“磁铁很有趣,但我们需要更多金属道具让它更有用。”这种思维方式可用于方方面面,从关卡制作到菜单和功能等。回首过往,可以说我们在项目早期根本不可能做出重复开发时的那种决策。

Caseys Contraptions(from gamasutra.com)

Caseys Contraptions(from gamasutra.com)

4、强势发布

发布后不到24小时,《Casey’s Contraptions》便上升至美国及其他二十多个不同国家的付费应用排行榜前十位。发布1天后,在美国应用商店中跃居第二,首个周末销售量甚为可观。强势发布并非完全出于运气成分,这是我们提前数月制定计划和努力工作带来的成果(游戏邦注:当然也需要一定的运气)。我们想让游戏获得用户的关注,但iOS游戏短暂的开发周期使得我们只有极短的时间来做这件事。

首先,我们在游戏发布前6周便向外界宣告游戏的研发,当时开发仅完成25%。在接下来的1个多月里,我们不断在Twitter和博客上发表游戏相关内容,时常展示工作进程或截图。在GDC期间展示游戏算是个里程碑之举。我们不仅让许多开发者来玩游戏并提出宝贵的反馈意见,在此期间还面见某些游戏媒体,这使我们后来有机会开展预演。推广的最后阶段在苹果审核游戏期间展开。我们决定将发布日期定在提交游戏3周之后,这样才有足够的时间来处理所有公共关系事宜,比如制作视频和媒体包以及联系媒体经销商等。在发布前数周时间里,我们也在博客上公示游戏各方面有趣的内容。

正因为我们在发布前所做的这些事,所以《Casey’s Contraptions》才足以幸运地吸引了苹果的注意力,发布当天公司在全球“每周iPad游戏”上重点推荐这款游戏。我们为媒体提供了足够的时间来介绍游戏,因而发布之日出现了众多积极评论,帮助游戏突出重围。

最初我们预想的游戏售价为4.99美元,但我们最终决定将价格下调至2.99美元。事实证明这是个正确的决定,游戏迅速上升至排行榜前10位。iOS榜单各游戏间的销售额相差甚大,前5位游戏销售额的增长幅度远高于那些只差数位的游戏。

看看今日的App Store,短时间内制作完成的小型游戏要想真正获得成功并上升至榜单前列显然变得更为困难。App Store上各类应用总数已超过50万,每天发布的游戏有上百款,你只有脱颖而出方能获得用户关注。多数成功实现目标的游戏都需要开发者投入大量的时间和精力,而且产品要有很高的价值。App Store淘金热已经过去了。

5、足够的开发时间

从项目开始到发布,《Casey’s Contraptions》开发用时8个月。以iOS游戏标准来看,这似乎是个很长的时间,但越来越多的成功iOS游戏都需要历经如此长期的开发。我们最初计划在圣诞节发布游戏。计划的诞生并没有经过任何缜密的评估,我们只是觉得自己能在圣诞节之前完成游戏,很显然这个想法是错误的。游戏开发花了这么长时间并不是什么坏事。事实上,我们浪费的时间不多,游戏本身的确需要这么长的时间才能成熟并获得今日的成功。如果我们当时选择提前发布游戏,那么这可能会是个糟糕的产品。

在《Casey’s Contraptions》之类的游戏中,最难的事情在于如何制作出有趣的关卡。有了足够的开发时间,而且从一开始就有行之有效的游戏编辑器,我们在开发期间制作出大量关卡。看看那些我们早期制作的关卡,难度过高而且也不是那么有趣。数月之后,我们便知道如何制作优良关卡和合适的难度。

足够的开发时间让我们可以在有些东西无法发挥作用之时从根本上改变游戏设计。比如,最早每个关卡有三个不同的目标供玩家实现。根据你达成的目标数目颁发铜牌、银牌或金牌。但我们很快发现玩家显然对游戏的三个目标感到极为困惑。

我们将关卡改变成单个目标,但为了使游戏在“解决”关卡谜题之外具有再玩性,我们增加了星星这个可选项,你可以使用游戏内任何道具触碰星星来收集。第一个星星很容易得到,第二个稍微难些,而第三个则需要玩家开动脑筋才能获得。

这极大地改善了游戏质量,但随后我们发现多数玩家想在首次通关时拿到三颗星,他们顽固地不断玩同一个关卡直到取得三颗星,或者因挫折感而退出游戏。这令我们再次改变星星的设计。现在获得星星的难度与关卡的整体难度有关,玩家在早期关卡中可以很容易地获得三颗星星。我们对这个最终设计感到非常满意,如果项目匆匆制成就不会有如此成果。

我们还在后期留下足够的时间来使游戏更为完善。完善游戏并非为改善游戏设计,其目的在于提升游戏的第一印象。在决定性的前数秒里,游戏的动画、音效和粒子效果都显得非常重要。对手机平台游戏而言,完善显得更为重要。如果你的游戏无法在短时间内吸引玩家,他们完全可能将注意力转向其他事物。

错误的做法

1、没有同时发布iPhone版本

《Casey’s Contraptions》最初的原型以iPhone为平台,但游戏当时显现出的组装奇妙装置的趣味性需要更大的屏幕空间。很显然,iPad自然就成了游戏的平台。设备的大屏幕可以显示精细的图形,让玩家能够自然直接操控道具。因而,iPad特别适合《Casey’s Contraptions》。

然而,尽管iPad用户数量众多(游戏邦注:目前已有1400万人在使用),iPhone和iPod Touch却是无可置疑的App Store之王,用户数量达到1.85亿。尤其对依靠社交成分作为卖点的游戏而言,有大量同时玩游戏、分享解决方案和传送关卡的玩家格外重要。我们确实已经在iPad榜单上名列前茅,但大部分iOS用户仍然无法购买游戏。

为何我们不等iPhone版本制作完成后再发布游戏呢?原因在于我们急于让游戏进驻市场。我们当时也不知道强势发布会对服务器带来何种规模的冲击力,因而首先发布iPad版本似乎是个可行的做法。事后我们觉得同时发布两个版本或许会更好,或者版本发布时间相差不多,最多1到2周。

为弥补这个错误决定,我们计划以如下方式发布iPhone版本:iPhone版本将与含有许多新内容的游戏更新同期面世,已经购买游戏的玩家可以免费获得,我们将尝试重现iPad上的强势发布。该想法的目的在于让每个已经购买游戏的人同所有的iPhone新玩家一起玩游戏,如此游戏才能拥有大量用户,这对游戏来说至关重要。

Caseys Contraptions (from gamasutra.com)

Caseys Contraptions (from gamasutra.com)

2、争议过多

我们两人组成了堪称完美的团队,尽管二人有互补的专长,有些内容仍存在争议。我们似乎也总是从两个不同的方向来看待问题,比如美学和可用性、表现力和可玩性、简化和兴趣、独特和大众化等。这确实是件很棒的事情,《Casey’s Contraptions》的成功绝大部分归因于我们个性和技术的互补。但是,这有时也会带来麻烦。我们两个都是非常顽固的人,需要花很长时间来磨合不同的观点。在游戏开发期间,有时我们花在观点辩论上的时间比真正执行的时间更多。

尽管这些争议并未真正影响到我们的开发进程,但解决这些问题确实非常困难,使得项目费时超过预期时间。这是我们首次合作开发重大项目,因而解决此类问题变得更为艰难。现在我们已经完成了首个项目的制作,希望能够在未来更妥善地处理类似的情况。

3、不必要的返工

返工是创意性过程中必须经历的阶段。在文本或音乐创作中,所有内容一步到位几乎是不可能的事情。游戏开发更是如此,因为各部分间的互动非常多。精准预测最终得出的产品很难,即便你可以做到,在设计出完整版本之前通常你也无法看到具体的内容。

开发者需要反复修改游戏中每屏和每个道具的艺术、行为、音效或布局。毫无疑问,每次修改都能让它们有所改善。但是,我们游戏中某些部分的修改次数过多。大部分是些UI,比如现在为人所诟的通关界面以及游戏内菜单的外观和位置,我们起码重新设计了6到7次。

我们坚信,设计不能只考虑单方面内容。如果你想要得到最好的产品,就不能只根据某些用户界面(游戏邦注:游戏其他部分也是如此)的功能来做决定,随后执行方案并以些许图形来修饰。制作和图形设计两者都会影响到用户界面的功能。如此循环数次之后,你就会得到从功能性和设计角度来看都非常强大的设计。

如果循环修改次数过多或此类修改无法生成具体的设计样式,开发者只是在兜圈,问题随即就会产生。导致此类问题的缘由通常是因为我们对某些细节不甚清晰,或者我们遗忘了某些具体功能致使设计返工在所难免。测试玩家反馈让我们意识到,有一屏玩起来并不像我们设计时那样有足够的清晰度,这使我们返工制作。如果要想让游戏尽量充满吸引力,在需要时返工制作通常都是个正确的选择。

比如,Casey会在每个关卡开始时解释你需要实现的目标。这个场景看似足够简单易懂,但在我们的早期版本中,Casey的说明挡住了关卡的视图。测试者抱怨称,不在提及的同时看到相关道具便很难记住需要做的事情,因而在最终设计中将Casey的话语放置在屏幕底部,目标道具用标记物圈出来。

我们可以通过重新制作某个UI或在小范围内改动游戏来解决这个问题,而不必返工制作每个关卡。在设计开始时,我们并没有立即开始设计屏幕中的场景或完全利用所有图形元素来仿制其他场景,而是先用简单的盒子和按键来规划屏幕,执行基本功能。随后我们转向真正的布局制作并添加图形元素,执行某些新功能和动画,重复制作直到布局完成。在开发过程最后1/3阶段,我们已经能够熟练使用这种方法,我们也会在未来的项目制作中使用上述方式。

4、单元测试不足

Noel热衷于单元测试和测试驱动开发。这些技术在以往的项目开发中非常有效,因而我们肯定也会在《Casey’s Contraptions》的开发中用上。我们的目标不在于开展覆盖率100%的单元测试或者通过测试驱动开发来编写每一行代码,而是只编写那些对项目有益的测试。测试的通常是大量其他代码挂靠的代码(游戏道具管理)、复杂的代码(工具盒互动)或易于受到破坏的代码(绳索操控)。

最后,我们真正进行的单元测试并不如预期的那么多。在开发过程中,物体连接之类东西的代码复杂且未经过测试,这时不时给我们带来麻烦。我们察觉到这些问题并意图增加测试,却已为时过晚,因为某些此类代码挂靠的是不适宜进行单元测试的API,如UIKit和Box2d。

我们本应该在这些问题显现之前花时间编写测试,在修正漏洞和增加新功能的过程中缓慢重构代码。但我们并没有这么做,心里总是想“只要几个月时间就可以发布游戏了”,所以决定跳过此步骤。在随后的开发中,这个错误的决定让我们付出惨重的代价。甚至在游戏发布时还有些不是很完善的东西,我们知道那里存在漏洞,但在提交审核前数周前我们仍不敢去动那部分内容。

我们已经开始制作《Casey’s Contraptions》的更新版本和iPhone版本,因而会在短期内继续处理这些代码。我们会对开发期间再次遇到的代码进行单元测试。

5、固定价格模式

在开发过程中,我们对价格模式反复商讨多次。考虑到《Flower Garden》以及App Store上其他含有微交易的免费游戏成功时间已较长,因而决定《Casey’s Contraptions》将采用固定价格模型。我们认为用户可能对传统固定价格模型的偏好甚于微交易系统。我们也看到这种模型对《愤怒的小鸟》和《割绳子》等同类iPad游戏的有效性,所以模仿它们应该是个合理的做法。

不幸的是,从经济收入的角度来看,这似乎是个错误的决定。在最初的强势发布之后,《Casey’s Contraptions》于数周内在排行榜上急速下滑,从而导致盈利迅速减少。虽然游戏还位于iPad游戏排行榜前百位,但每天的盈利非常少。

微交易游戏不但在传统游戏开发群体中名声不好,而且开发起来也比单次购买的固定价格游戏要难得多。你不仅需要设置健全完善的服务功能,还需要平衡游戏内经济、奖励节奏和购买费用。保守估计,这可能需要增加至少1个月的时间才能完成。

或许我们可以转变为销售新关卡或场景的传统定价游戏。这执行起来就简单多了,但可能不会对盈利产生很大的推动作用。通常只有2%至5%的玩家会购买额外的内容,所以微交易游戏才需要设计无限的商品(游戏邦注:游戏内置货币和肥料等)或需要庞大的用户基础。因为我们游戏中可购买东西的数量较少而且有限,所以需要吸引大量玩家才能使盈利情况有所改变。

我们希望iPhone版本的发布能让更多新玩家对《Casey’s Contraptions》产生兴趣,刺激这两个平台上的用户付费,使游戏在排行榜上待的时间更长。如果未出现转机,我们可能会考虑改变价格模式。

Caseys Contraptions (from gamasutra.com)

Caseys Contraptions (from gamasutra.com)

结论

对于《Casey’s Contraptions》的开发和首次发布,我们感到特别高兴。我们成功地创造出独特的游戏,其创意性既受到公众的广泛认同也能产生盈利。你看到这篇文章时,首个免费更新应该已经发布。更新的内容包括你可以通过网站与所有人分享奇妙装置以及浏览公开的奇妙装置,这应该会极大提升游戏的流行度。更新中还增加了某些用户最迫切需要的功能,比如多人模式,家长可在此模式下与孩子一起玩游戏。

《Casey’s Contraptions》不像传统零售游戏,我们的故事还远未结束。我们在未来几个月的做法会推动游戏获得长期成功。(本文为游戏邦/gamerboom.com编译,如需转载请联系:游戏邦)

Postmortem: Llopis and Friginal’s Casey’s Contraptions

Miguel Ángel Friginal, Noel Llopis

Creating a successful iOS game isn’t as simple as it looks, and in this postmortem, developers Noel Llopis and Miguel Ángel Friginal explore what it takes to create an easy-to-play, well-designed casual game and take it to number two on the charts.

Casey’s Contraptions is an iOS game created by the two of us, Noel Llopis and Miguel Ángel Friginal. Noel, an industry veteran for over a decade, turned indie over four years ago and found success with microtransaction-based Flower Garden on iOS. Miguel worked as a graphic designer in the advertising industry for years before becoming a web developer. Casey’s Contraptions is his first published video game, although his first paper role playing game came out almost 20 years ago.

We met through Twitter several years ago, and then finally in person at a 360iDev conference. Even thought we didn’t plan it that way, we ended up working together during a game jam, and that set us in the path to collaborate in a future project. We knew we wanted to target iOS for our next project because we love the platform from a user and a developer point of view, and because it’s a platform where it’s possible for indies to succeed financially. Beyond that, starting a new game is never easy.
Even though we have page after page of possible ideas, settling on a specific game idea is always very hard. We wanted something that met three requirements: The game had to be creative in nature as opposed to using destruction as the main gameplay element, it had to be something we were excited about, and it had to be something with the potential to sell reasonably well on the iOS App Store. Easier said than done!

We prototyped game idea after game idea, and even though a lot of them were not bad, none were a complete standout. Eventually, after seven or eight different prototypes, we settled on the concept of creating physics-based, Rube Goldberg-like contraptions to solve different puzzles. At its core, the game has similar mechanics to some classic games like The Incredible Machine, but with an emphasis on exploration of creative solutions rather than finding the one right answer to each puzzle, designed around sharing, and built from the ground up for a touch interface on iOS.

We structured this project as a pure 50-50 partnership, and without any external funding or publishers. Miguel quit his full time job (as a web programmer no less!) to do the art for Casey’s Contraptions, and Noel took care of the programming. Design was a fully collaborative activity, where we both contributed equal amounts to everything from the rules, the feel of the game, or level creation. Everything else we split up based on our strengths and expertise: web site, server back end, PR, etc. This is not a true postmortem, but more of a post-launch analysis. Games today, and especially iOS and Facebook games, are becoming more of a service rather than a product. Development and launch are only the beginning of the story. If all goes well, we’ll have a lot more to say about Casey’s Contraptions in a few months.

What Went Right

1. Strong Theme and Style

Casey’s Contraptions started life without Casey! The initial prototype focused only on the creation of contraptions and the physics simulation behind it. It showed a lot of potential, but it was missing something to make it stand out. It needed more personality.

After some brainstorming, we quickly zeroed-in the idea of a smart eight year old building the contraptions. Not only did that add the much-needed personality to the game, but it also focused the rest of the development. Instead of doing a physics game with generic pulleys and levers and other industrial-looking items, we naturally went with toys and household items Casey could have access to: His sister’s doll, paper planes, or his RC truck.

The choice of toys as game items not only influenced the level design, but also the goal of the levels. At the beginning we were thinking of doing levels to accomplish tasks Casey would have to deal with in real life, such as putting toys away or popping a balloon. After a while, the idea of “playtime” levels came up, where the setting and the goal were completely imaginary (rescue explorers from a jungle in their hot air balloon) just as Casey would have imagined during his playtime sessions.

The character of Casey also helped anchor the art direction. We were aiming for something that would appeal to a very wide range of people, from the very young to adult casual gamers. Although Miguel looked into everything from a most modern Cartoon Network style to manga, to crazier Warner Bros., we ended up settling with a mix of Calvin & Hobbes and something out of a ’50s Hanna-Barbera show, with strong outlines and solid colors, to make people of all ages feel comfortable with the visuals. We were able to carry this distinct style to all the items, locations, and user interface in the game, which gave it a very consistent and unique look.

2. Social Features

Creating something is fun, but creating something and being able to share it with people is twice as much fun. We wanted to make Casey’s Contraptions a very social experience from the start. Not something that you played through and put away, but something you could share with friends along the way.

Since Casey’s Contraptions uses a full physics simulation at its core, it’s possible to come up with very unique, chaotic, and often unexpected solutions to most puzzles. Weeks after launch, we’re still amazed at how some people are solving some levels, coming up with item combinations we never thought about during development. Since these solutions are very unique and fun to watch, they were a perfect candidate to share with friends.

With that in mind, we designed the game with sharing from the start. After you complete each level, you can share your solution with all your friends just with the tap of a button (and, in the latest update, the default is to autosubmit a solution if you improved your score). Your friends’ solutions are equally accessible, as cropped thumbnails in the level completion screen, and tapping on any of them will bring up a full-screen view, so you can even replay and watch the full solution.

In addition to sharing solutions, we also included a level editor to allow players to create their own contraptions from scratch. This was the same level editor we used to create all the levels in the game. Nothing like eating your own dog food to make something solid and usable. Initially, players were able to share these levels through email, and, in the first update, we also added the ability to share them publicly through a web site (http://shared.caseyscontraptions.com), effectively giving players access to hundreds of new levels. As it’s the case with most games that include level editors, we were aware that only a small minority of players would take the time to create their own contraptions. But it’s also those players that are really devoted to the game, and take it upon themselves to spread the word about your game and champion it to all their friends.

3. Iterative Development

For Casey’s Contraptions we used a very stripped down and relaxed form of iterative development. We had short iterations and in each iteration we aimed to fully implement what we considered the most important features at the time.

We didn’t do any real estimating of tasks (other than, “yeah, we think we can do that in about two weeks”), and we didn’t set a hard-limit on the iteration (they varied naturally between one and a half and three weeks). The most important concept is that at the beginning of each iteration we would make decisions about what to work on next, and those decisions were made with all the knowledge leading up to that point. For example, we didn’t start the project by coming up with the full list of items we were going to have in the game. Instead, we had a list on the wiki of possible items (to which we would add more whenever we thought of a new one during development), and we only decided which new items to add to the game at the beginning of each iteration.

That allowed us to make good decisions based on what we had learned so far: “Most objects we have so far fall down. We need more items that add forces upwards”, or “The magnet is fun, but we need more metal items to make it more useful”. This mentality applied to everything: From level creation, to menus, features, etc. Looking back, we can say there’s no way we would have made the same decisions early in the project than we did as we went along.

4. Strong Launch

In less than 24 hours after launch, Casey’s Contraptions worked its way up to the top 10 paid apps in the U.S. and in over 20 different countries. A day later, it reached the number 2 overall spot in the U.S. and had great initial weekend sales. This strong launch wasn’t just pure luck. It was something we planned months in advance and worked hard to achieve (although we did need a dash of good luck). We wanted to build awareness and buzz around the game, but given the short development cycle for iOS games, we would have to do it in a shortened scale.

We started out by announcing the game more than six months before release (25 percent of the way into development). During the following months, we continued talking about the game on Twitter and our blogs, often showing work in progress or outtakes. The next big milestone was showing the game around at GDC. Not only did we get a lot of other developers to play it and give us invaluable feedback on it, but we also met with some of the game press, and that resulted in some very nice previews afterwards. The final push came as soon as we submitted the game to Apple for review. We decided to set a fixed release date three weeks after the submission, which would give us enough time to do all the PR work: creating a video, putting together a media packet, contacting media outlets, etc. In the weeks leading up to the launch, we also stepped up our blogging of different interesting aspects of the game.

As a result of everything we had done up to that point, we were very lucky that Casey’s Contraptions attracted Apple’s attention, and they featured it prominently on launch day as iPad Game of the Week worldwide. We had given the press enough time with the game, so a lot of very positive game reviews came in right around launch day, helping get the word out for the game.

Even though we had been originally thinking of pricing the game at $4.99, we decided to shoot for volume instead and priced it at $2.99. That turned out to be the right decision and immediately put us on the top 10. Sales on iOS charts follow a sharp, exponential drop off, so being in the top 5 represents a huge increase in sales over just a few positions down the chart.

Looking at the App Store today, it’s apparent that it’s becoming harder for small, quick games to be really successful and top the charts. With over half a million different apps on the App Store, and hundreds of games released every day, you really need to stand out from the rest to be noticed. Most of the games that manage to do that are ones that required significant time and effort investment and have good production values. The App Store gold rush is over.

5. Enough Development Time

From start until launch, Casey’s Contraptions was in development for eight months. That seems like a long time by iOS standards, although more and more successful iOS games are starting to take that long. Our initial plan was to ship the game by Christmas. It wasn’t based on any rigorous estimating, just an off-the-cuff estimate. It just “felt” like we could be done by then. Obviously we were wrong. Taking the amount of time that we did was a very positive thing. We didn’t really waste much time, it’s just that the game needed that amount of time to mature and get to where it is today. If we had chosen to ship it earlier, the final product would have suffered significantly.

One of the hardest things in a game like Casey’s Contraptions is making interesting levels. Having this amount of development time, with a working game editor since the very beginning, allowed us to make a lot of levels along the way. Looking back at a lot of the early levels we made, they were laughably hard and not that interesting. After several months, were able to develop a sense about what made good levels and what the appropriate difficulty was.

Having enough time allowed us to make fairly fundamental changes to the game design when something wasn’t working. For instance, initially each level had three different goals you could achieve. Depending on the number of goals you accomplished, you earned a bronze, silver, or gold medal. It quickly became apparent that players were extremely confused by the three goals and weren’t able to keep them straight.

We changed levels to have a single goal, but since we still wanted to have some replayability beyond “solving” a level, we added optional stars you could collect by touching them with any item in the game. The first star would be very easy to get, the second one a bit harder, and the third one would require some serious thinking.

That was a huge improvement, but then we discovered that most players expected to get all three stars in their first playthrough, and would stubbornly keep playing the same level until they got them all or quit in frustration. That prompted us to change the stars yet again. This time the difficulty of getting them was tied to the overall level difficulty, so players could easily get all three stars in the early levels. We’re very happy with the final design, and we would not have gotten there if the project had been rushed.

We also gave ourselves sufficient time at the end for polish and style. Polish isn’t going to make the game design any better, but it’s going to contribute a huge amount to first impressions. Every animation, sound, and particle effect becomes really important in those crucial first few seconds with the game. On a mobile platform, polish becomes even more crucial. If your game doesn’t immediately engage the player, there are lots of other things they can shift their attention to.

What Went Wrong

1. No Simultaneous iPhone Launch

The initial prototype of Casey’s Contraptions was running on an iPhone. While it showed a lot of promise and it was fun to assemble contraptions even that early on, it was clearly begging for more screen space. The iPad was the obvious platform of choice. Its large screen can display very nicely detailed graphics, and allows for very natural, direct manipulation of items. It was a perfect fit for Casey’s Contraptions.

Even so, while there are a lot of iPads out there (14 million), the iPhone and iPod Touch are the undisputed kings of the App Store (about 185 million devices). Especially for a game that relies on the social component, getting a critical mass of users playing at the same time, sharing solutions, and sending levels is very important. We definitely stormed up the iPad charts, but that still left the majority of iOS users not being able to purchase our game.

Why didn’t we wait until we had the iPhone version to launch? No particularly good reason other than we were itching to get the game out. We also had no idea what kind of impact a strong launch would have on our servers, so the idea of an iPad-first launch seemed like the way to go. In hindsight, we would have been better off waiting to launch both versions at the same time (or almost the same time, maybe a week or two apart at most).

To make up for this, we’re planning on making the iPhone release a second launch of sorts: we’ll make the iPhone version coincide with a new game update that includes a lot of new content (for free for people who already bought it), and we’ll try to repeat the same strong launch we had on the iPad. The idea is to get everybody who’s already bought the game playing again, along with all the new iPhone players, and create that critical mass.

2. Butting Heads Too Much

We make the perfect two person team: we have complementary specialties, but we also have a lot of overlapping skills. We also seem to always approach things from opposite ends: aesthetics vs. usability, performance vs. gameplay, simplicity vs. interest, uniqueness vs. familiarity, or tea vs. coffee. That is actually a really good thing and the success of Casey’s Contraptions was in no small part due to our combination of personalities and skills. There is, however, such a thing as too much of a good thing. We are both very stubborn and it will take a lot to convince us to see things in a different way. There were some times during development that we spent more time debating one point than actually implementing it.

The fact that we’re working remotely didn’t really affect most of our day-to-day development, but it definitely made hashing out these situations significantly harder, dragging them out for far longer than they should have. This was also the first time we were working together on a significant project, so it made resolving those situations more difficult. Now that we’ve gone through this first project, we’ll hopefully be better equipped to handle similar situations in the future.

3. Unnecessary Rework

Rework is a necessary part of a creative process. You’re unlikely to get everything right in the first draft of a text or a music composition. That’s even more so the case for game development, because there are so many parts interacting with each other. Not only is it hard to predict the exact final outcome, but even if you could, you often don’t know exactly what you want until you’ve seen one version of it.

Just about every screen and every item in the game went through several revisions of art, behavior, sounds, or layout. There’s no doubt that every revision made them better. However, we had a few parts of the game that we had to revise a few too many times. This was mostly in some of the UI screens, like the now infamous “level completed” screen, or the look and positioning of the in-game menu, which we must have gone through at least six or seven complete redesigns.

We believe that design doesn’t just flow one way. If you want the best final product, you can’t just decide on the functionality of some user interface (or any part of the game for that matter), implement it, and then give it a pretty face with some graphics. Both the implementation and the graphic design will actually feed back into the functionality of the UI. Once you go around this cycle a few times, you can zero in on a very strong design, both from a functional and a design point of view.

The problem comes when you go around that loop too many times, or when the loop doesn’t converge into a particular design, but keeps shifting around. That was often caused because we were fuzzy on some of the details, or when we were forgetting about some particular feature that had to be reworked into the design. Some other times feedback from our testers made us realize that a screen wasn’t clear enough as we had designed it and caused us to rework it. As tempting as it was to push through and call it good enough since it was already completely done, it was always the right decision to go back and re-work things as needed.

For example, at the beginning of each level Casey explains what goal you need to achieve. This screen seemed straightforward enough, except that the version we had early on was blocking the view of the level while it was up. Our testers complained it was hard to remember what you had to do without seeing the items it was referring to at the same time, so the final design shows Casey’s dialog along the bottom of the screen, and the goal items are even circled with a marker.

We can alleviate this problem by iterating on particular pieces of UI or the game in smaller cycles, without taking each one to completion. Instead of starting by completely implementing a screen, or completely creating a perfect mock up with all the graphic elements, we need to start by laying out a screen with simple boxes and buttons and implement the basic functionality. Then we can make a first pass at a real layout and some graphical element, implement some of the new functionality and animations suggested by that, and continue iterating until it’s done. We got much better about this in the last third of development, and it’s something we want to carry forward to future projects.

4. Not Enough Unit-Testing

Noel is a big fan of unit testing and test-driven development (TDD). Those are some techniques we used in past projects to very good effect and something we definitely wanted to carry into Casey’s Contraptions as well. The goal was never to have 100 percent unit-test coverage or write every single line of code through TDD, but to write only the tests that would benefit the project. That usually meant some code that a lot of other code relied on (the game item management), or something complicated (toolbox interaction), or something prone to breaking (rope manipulation).

In the end, we slipped to the side of not having as many unit tests as we would have liked. Some things like object attachments kept repeatedly giving me headaches during development because of the complicated, untested code. By the time we noticed those problems and wanted to start adding tests, it was too late because some of that code relied on non-unit test friendly APIs like UIKit or Box2d.

We should have taken the time when those problems started appearing to start writing some tests and slowly refactor the code as we fixed the bugs and added new features. Instead, since we seemed to be constantly “just a few months away from shipping”, we decided to skip that and definitely paid the price later on. We even shipped with a few off edge cases that we knew were buggy but we didn’t dare fix weeks before submission.

We’re already working on updates and an iPhone version of Casey’s Contraptions, so we’ll continue dealing with that code for quite a while to come. We’ll slowly introduce unit tests in areas of the code that we need to revisit during this time.

5. Fixed Price Model

The pricing model is something we went back and forth about several times during development. In spite the long-term success of Flower Garden and other free games with microtransactions on the App Store, we chose to go with a fixed-price model for Casey’s Contraptions. We thought our audience would appreciate a traditional fixed-price model better than a microtransaction-based one. We also figured it was a model that was working well for other similar iPad games such as Angry Birds or Cut the Rope, so it made sense to follow their lead on that.

Unfortunately it seems that might have been the wrong decision from a financial point of view. After a really strong initial launch, Casey’s Contraptions dropped down the charts very rapidly after just a few weeks. Since revenue follows a very sharp exponential drop off, even being in the top 100 iPad games means very little revenue per day, and points to a very thin “tail” to the sales curve.

In spite of the bad reputation microtransaction games have in traditional game development circles, they’re a lot harder to develop than single-purchase, fixed-price games. Not only do you need to implement very robust server features, but you need to finely balance the in-game economy, the pace of rewards, and the cost of new purchases. Our optimistic estimate was that it would add at least a full month to the development time (and given how our estimates were, it probably meant two months for real).

A possible alternative would be to have a traditionally-priced game, but offer new levels or locations as extra purchases. This would have been a lot simpler to implement, but it probably wouldn’t have made much difference in revenue. Usually, only about between 2 and 5 percent of the players buy any extra content, so for microtransactions to really pay off, they need to be unlimited (in-game currency, fertilizer, etc), or have a very large user base. With a small, fixed amount of possible things to buy, we would need to rely on having lots of players to make much of a difference.

We’re hoping releasing the iPhone version will generate lots of renewed interest in Casey’s Contraptions, spur lots of sales on both platforms, and hopefully increase the long-term chart staying power. If that’s not the case, we can always consider the possibility of experimenting by changing the pricing model in the future.

Conclusion

We’re extremely happy with the development of Casey’s Contraptions and with the initial launch. We managed to create a unique game around creativity that was very well received critically and from a sales point of view. The first free update should be available by the time you read this. It adds the ability to share contraptions with everybody through the web site, as well as browsing public contraptions, which should increase the popularity of that feature quite a bit. It also adds some of the most-requested features, such as multiple player profiles for all the parents playing Casey’s Contraptions with their children out there.

Unlike a traditional retail game though, the story is far from over. What we do in the next few months will have a very significant impact on the long-term success of the game. (Source: Gamasutra)


上一篇:

下一篇: