作者:Jeremy Alessi
自App Store于2008年诞生以来,我便已经开始制作iPhone游戏。2009年夏天,随着iOS 3.0的发布,如《Eliminate Pro》等游戏开始通过苹果IAP系统推出微交易系统,并且游戏的侧重点也从原先的获取关注转变为争取用户留存率。
2009年末我创造了游戏《Crash for Cash》。这款游戏获取了较大的关注,并多次占据了App Store排行榜第一的位置,共获得了超过100万的下载量。除此之外,这款游戏的广告收益也不容小觑;但是因为它专注于获取更多玩家的关注,所以到最后真正留在游戏中的玩家数量非常少。
那时候我知道自己应该努力做得更好,因为整个市场一直在不断变化,如果你不能激发玩家尝试更多游戏内容的欲望,那你的游戏便不大可能取得成功。所以我便开始努力创造一款侧重于提高用户留存率的游戏。终于,经过了一年多的努力,我在2011年圣诞前夕发布了《friendly.fire》这款游戏。
现在《friendly.fire》已在App Store上架一个多月了。但是我们不得不接受的一个坏消息是,这款游戏并未取得较大的反响。而好消息便是,我们已经预料到会出现这个问题。
我们的开发团队已经开始讨论新的游戏开发阶段,即我们的目标并不是完成并推出游戏,而是持续完善游戏,直到最终创造出一款真正热门的游戏。

动工开发《friendly.fire》
在阐述游戏开发进程之前我认为有必要先解释清楚为何我们要创造《friendly.fire》这款游戏,以及Friendly Dots这个品牌的来源。正如我之前所说的,我们着眼于这些游戏的一大动机便是创造以提高用户留存率为目标的游戏,并改变App Store中传统的排名上升/下降规律。
我记得几年前读过一篇关于NewToy和《Words with Friends》的文章,它主要是陈述为何这款游戏的用户留存率会远远高于App Store中的其它竞争者。我同样也意识到,已经身为人夫和人父的我很少有机会再与好友一起玩一些传统游戏,但是我却愿意与他们共同分享《Words with Friends》。
我非常喜欢App Store,并且多年来我一直奉行2分钟的手机游戏设计理论(就像游戏《Words with Friends》中所体现的),但是现在我却发现自己失去了游戏的最大乐趣,也就是与好友一起娱乐。这时候我才真正领悟到,我不只想要创造出具有娱乐性的游戏,同时我也希望能够与好友们一起游戏——并且我能够通过创造出任何支持玩家如此操作的机制。
这时候我刚刚构想出《Friendly Dots》的游戏理念。创造这款游戏的大前提是我们希望创造出能够“随时与好友分享”的游戏。
一开始我们想出了几个基于回合制的游戏理念。我们也创造了一些游戏原型,以帮助我们能够在任何时候更好地理解游戏,但是说实话,这些理念我都不是很满意。
作为一名游戏玩家,在过去两年里我一直非常喜欢《愤怒的小鸟》,《Minecraft》以及《Words with Friends》。而作为一名游戏开发者,我希望能够结合自己所喜欢的游戏体验创造出一些真正优秀的内容。我真心喜欢的是那些能够允许我与好友一起建造、破坏并分享所有内容的游戏。
团队结构
我是一名综合型游戏开发者,已经独立创造了许多游戏,这些游戏包含3D模型,2D游戏界面,程序设计,数据库,音效等等。但是我知道《friendly.fire》早期的游戏概念太过复杂,仅凭我一人之力是难以完成的。
游戏特别需要一个健全的后台服务器技术为支持。过去,我曾经创造了一些包含简单的PHP/MySQL后台的游戏,但是我知道,自己想超越这些技术局限性。幸运的是,我在2010年末认识了另外一名当地的程序设计员Jon Nadal。他在《friendly.fire》的技术创造过程中他给予了非常有利的支持。
我向他描述了《Crash for Cash》的相关流量数据(dApps注:它在最高峰时期每天都有超过3万名的新用户)。在经过一系列的调查研究之后,Jon想出了一个涉及MongoDB和node.js的解决方法。在某些测试中,结合这些技术能够帮助我们每秒钟处理2万多个请求。Jon以及他所带来的技术帮助我们明确了《Friendly Dots》的核心。我们需要一个非常快速的服务器解决方案,而Jon帮我们做到了这一点。
而另外一个能够帮助我们实现这一理念的方法却完全无关技术。我们希望得到一个真正懂得“社交”的人的帮助,并且这是完全不同于Facebook或Twitter意义上的概念,而是指“社交性”的真实属性。我们要求的是一个擅长交朋友并且能够完全代表整个社区的人。John McIsaac在过去某些项目的开发中给我提供了一些帮助,并且他总是能够深刻地洞察自己每天所看到的不同人。所以他便是我们在创造《Friendly Dots》最合适的人选,因为这款游戏是关于玩家如何与好友分享经验,而这就是John最关注的内容。
明确了所需要的技术并获得了合适的社区管理者,我便开始进行游戏设计与编程。作为一个充满想象力的游戏开发者,我的硬盘驱动器中拥有许多原型代码和资产。尽管大多数这些内容从未显露身手,但是我也会不时将早前的组件结合在一起,创造出一些有帮助的新内容。在《friendly.fire》中,我将Games Demystified一篇关于《愤怒的小鸟》博文中的一些代码与动态的2D砖块建造代码结合在一起。
制作原型
第一个原型针对的是iPad平台,并且突出了城堡和两个弹弓,一个在左一个在右。玩家在一系列回合中前进着,包括建造,射击以及修复阶段,并且他们还不断尝试着击毁其他玩家的城堡。
总的来说,这个游戏理念是有价值的。但是不管怎样,必须确保原型的建造组件是有效的。它们都是一些具有动态的组件,特别是基于自由的创造性建立起来的组件,但是结果却导致用户更有可能意外地击毁自己的堡垒。
我们认为“自由建造”功能即使安插在其它游戏(具有友好属性)中也会非常有趣。意识到这个问题,我们便重新开始设计游戏的进程。这次我们创造了一个更加精确的回合制结构,并设置一次只能够出现一座城堡。除此之外我们也在建造阶段用一个网格系统和铺砖系统取代了自由建造功能。
曾经有人建议将排除游戏中的物理原理,但是我却不打算这么做。我对物理机制很着迷,所以我决定在射击阶段始终保持物理引擎的运转,尽管我心里清楚,建造阶段最好不要使用这种物理引擎。我脑中唯一留存的疑惑是,如果游戏中所有内容都是关于网格中的砖块,那么玩家还会觉得游戏有趣并从中感受到活力吗?
所以我必须先处理网格和砖块系统。因为我非常喜欢物理;所以我讨厌没有任何目的性地改变系统,我希望克服这一过程;我同样也想知道这么做是否有效。当然了,最后证明这么做是对的,但是我在游戏中所采取的编程方法却总是基于建造阶段与发射阶段的过度而在2D与3D空间之间转变着,并且必须确保在这个过程不会出现任何缝隙。
我收集了各种书籍,包含如何从空间中的某个矩形中心获取像素,或者通过像素明确空间中的一点。从我个人的角度来说,使用Unity便能够轻松得到答案,但是我却花了好几天的时间去获得一些更有塑造性的结果,以备将来的不时之需。
当确定了网格和砖块系统都足够合理之时,我便开始创造不同类型的砖块。我知道,单纯基于网格的游戏并不会具有活力。而解决方法便是突出不同的砖块类型。如果砖块本身就具有多元化的动态属性,那么游戏也将会非常有趣,并且能够让玩家感受到创造性。
第一个砖块类型可以是典型的木材板条箱,石材或者钢制的砖块。但是直到我们设置了橡胶砖块——就像是《飞天老爷车》中的“橡皮”一样,能够加快落下的导弹速度,这时游戏才真正变得有趣起来。随后游戏中开始出现一些真正的策略,即使是由钢材砖块组合而成的最坚固的堡垒也会被快速弹跳的橡胶劈成两半。
这时候,基本的游戏流程进展顺畅,但是却只能在单一设备中的“通过第N个游戏”模式中进行,两个好友玩家可以反复地传递iPhone或iPad相互玩游戏。游戏中只包含建造模式和射击模式。
在早前就发现的一个问题是不论谁建造了一座堡垒,他都希望知道射击手会如何摧毁自己的堡垒。所以即时重放便成为了一种必要的功能,但是这时候我们便需要考虑快速发射系统是否会成为阻碍这种功能的难题。例如,在《愤怒的小鸟》中,小鸟跳上弹弓并发射出去这个过程中将会出现延迟。事实上,这种延迟时间更长,摄像机镜头会在小鸟发射后再慢慢移回弹弓上,除非你能够彻底缩短这种延迟过程。
对于《friendly.fire》来说,我们能从《愤怒的小鸟》吸取的第一个教训便是摄像镜头的移动。对于我来说,这种延迟是完全不必要的,如此将会大大影响游戏整体的进行。除此之外,我们的首个基于网格的原型就像是一种消耗战,在此每个玩家拥有100个炮弹,而用光了所有炮弹的玩家便算失败了。所以为了让游戏继续下去,并测试玩家的意志力,我们设置了速射弹弓。玩家可以在《friendly.fire》中按照自己的想法快速发射炮弹。
最后,我们顺利地执行了即时重放系统。而炮弹储存在服务器中,就像最初始位置,发射向量以及时标。多亏了Nvidia PhysX在单一平台上的决定性作用,我们才得以顺利执行即时重放系统。
老实讲,我们也仍然面对着射击,测试以及即时重放模式的细微偏差,但是即时重放系统本身具有决定性作用,并且大多数情况下这一系统都能够合理地执行完成。这就是我想创造的“完美”游戏,而从整体来看,它是基于我们所认可的游戏玩法而进行的。
在将原型整合进服务器版本前我们还需要的最后组件是测试模式。在像《Words with Friends》等游戏中,玩家呈现于黑板上的答案都会伴随一个静态值。游戏依赖于基本的语言和数学技能组合,并且极具有活力,但是比起物理模拟游戏来说它更需要玩家的预见性。
《Words with Friends》等游戏的玩家使用基本的语言和数学知识进行游戏,《friendly.fire》的玩家则是根据基本的物理原理玩游戏。而不同之处就在于我们总是能够轻易地识别出写在黑板上的单词;但是射击一个物理砖块城堡则会出现更多不同的结果。因此测试模式便允许建造者能够尝试不同的尺寸建造自己的堡垒,以观察它对于弹弓的袭击是如何做出反应。
云端服务
当原型能够有效运行时,我们可以明确有效的目标用户。尽管我们最初瞄准的是iPhone用户,但为了让我们自己的服务器技术派上用场,我们避开了一些iOS服务。关于这一点有若干原因。
最重要的一点是我们想跨平台运行游戏。例如,苹果Game Center中有一种非常棒的回合制附加组件,但是因为它会将我们局限于Game Center和iPhone平台,所以我们最终放弃了这一组件。除此之外,选择使用专属社交网站也难以让我们与玩家建立起直接的联系。
虽然这种论断仍然备受争议(就像是如今当我们很容易获得所有人的资料,你又何需大费周章地在数据库中搜索)所以我们便打算在此赌一把。毕竟,即使是Zynga这样的巨头公司也会有人质疑其真正价值,因为该公司始终无法摆脱对Facebook的依赖。
所以,作为独立游戏开发者,我们应该为自己拥有足够的独立性感到骄傲。这也意味着我们不需要偏重任何一个平台和社交网站。
大多数情况下,我们的服务器框架运行都算成功。我们使用的是亚马逊网络服务(Amazon Web Services),并且在圣诞节App Store停止更新期间我们也已经多次更新并完善了游戏内容。
当游戏发布后,我们即时地将其推向了App Store,刚好赶在圣诞假期App Store停工之前。这是苹果一年中唯一一次停止运行App Store,这可以让一些幸运的开发者得以在这段时间不断完善自己刚刚发布的游戏。我认为这就是最佳的发行时间了。
为了迎接即将而来的假期热潮,我们启动了亚马逊网络服务,并花费一大笔钱手动增减服务器的数量(从而更好地承载世界各地数百万人同时在线)。在游戏发布后,我们始终观察着游戏下载量和使用率,并认为我们毕竟还未取得成功,所以应该适当地缩小服务器的规模。Jon在服务器结构的出色表现让我们能够更加轻松地改变这些服务器规模。
这时候,我真的开始感受到游戏处于当前阶段是没有足够成本能够提供如此服务。但是我同样也发现,帮助我们更好地管理游戏后台的唯一方法便是坚持走这条路。如果我们采取其它捷径,我们便有可能面对完全不同的问题,从而不可能帮助我们更好地掌握自己的命运。尽管从短期发展来看,这种决策不会给我们带来较明显的成效,但是我坚信,这种策略所支持的是长远的发展目标。
不甚理想的数据
现在,是时候阐述一些较为窘困的事实了。虽然我成功销售了几款iPhone游戏,撰写了一些文章以及一本专著,并从iPhone游戏开发中赚的了不少的报酬,并开始尝试一些一些更大,更棒且更酷的内容……但是说实话,《friendly.fire》在刚发行的第一个月真的遭遇惨败。
《Crash for Cash》一天便达到了超过3万次的下载量,并在如此高潮后仍然能够争取到每天2000名的新用户,与此相比之下,2年后的《friendly.fire》花了三周的时间才获得2000名用户。更糟糕的是,在2000多次的下载中,只有150个玩家真正如游戏所愿,注册接受与好友进行手机间传递的玩法。更更糟糕的是,在这150名玩家中,有42名玩家并未与其他玩家在游戏中进行互动。所以老实地讲,现在的这款游戏看来真的糟糕透了!
早期的完善
在面对早期如此糟糕的成绩时,我们最好的下场便是“卷铺盖走人”,但是这却不是一个真正的好方法,或者说这么做对于那些愿意不断玩我们游戏的玩家来说是不负责任的表现。既然我们已经了解到了这些早期参数,我们就应该对其加以利用,并想办法做出改变。其中一个改变便是主菜单。起初,我们将“通过N个游戏”的选项摆在首位,然后是“在线游戏”按钮,因为“在线游戏”是更加复杂的选项。
但是事实上,“通过N个游戏”模式并非游戏真正涉及的内容。除此之外,“在线”这个单词也会颇有点让玩家生畏。所以在我们最新发布的版本中颠倒了按钮的顺序,并将“在线游戏”重新命名为“与好友一起游戏。”
做出调整后的游戏促使玩家的数量翻三番,更多玩家愿意注册游戏,并加入手机对战的游戏玩法。起初的按钮设置导致只有4.8%的玩家愿意注册并“在线”玩游戏。但是通过改变语言表达方式和按钮位置,玩家数量一下子窜升到13%。
毫无疑问,这些小小的参数能够证明一个道理——细节决定成败。尽管我们最初的选择也没有错,我们最初使用的语言也非常清楚,但是改变选项的顺序并让语言变得更加“亲切”便能够为我们争取到更大的利益。因此,在短短的三天时间内我们的玩家规模便迅速增长了50%。
未来方向?
不论是《friendly.fire》还是《Friendly Dots》,我们都在实践“完成游戏后进行迭代”的方法。我们明确了主要的策略,并且从未改变它。我们一开始的目标只是单纯地制作游戏,并赶在假期之前推出游戏,并不断引进新内容而最终推动游戏的微交易。
在整个开发过程中,我反复地提醒团队成员虽然我希望游戏能够马上流行起来,但如果结果不甚如意,我们也无需担心,因为我们制作的是关于用户留存率而不是争取关注度的游戏。在游戏测试过程中我们发现玩家真的喜欢我们的游戏。在App Store上拥有5颗星的评级也证明了那些陌生的玩家并不讨厌我们的游戏。根据相关参数,我们发现游戏存在的最大问题便是糟糕的用户界面,它导致玩家不能够真正理解游戏设置。
在新发布的1.02版本中,我们稍许改进了用户界面,并开始添加可定制内容,并因为额外内容而成功调整了被破坏的服务器设置。我们计划在下个月引进完全修正的用户界面,积分系统,背景选择以及IAP机制。
从某种意义上来说,我们创造《friendly.fire》的目标是为玩家创造轻松的游戏设计体验。当你在为好友创建关卡时,你便是游戏设计师。我也发现了很多时候当我真正在为好友设计关卡时,我更关注的是游戏的乐趣而不是挑战。如果一直这么想,我们便能够实现出更多的可能性。(来源:游戏邦)