文/Jeremy Alessi
[在新系列的第一部分中,iOS 开发老手 Jeremy Alessi 将带我们了解他的新游戏 friendly.fire 的原型设计、制作以及发布,并分享其发布过程的统计数据。他将每三十天与 Gamasutra 读者分享游戏的最新战报。]
我自 2008 年 App Store 开张时就开始开发 iPhone 游戏了。随着市场的发展,一路上产生过各种趋势。最初,几乎所有游戏都有人买。人们完全乐意以每款 99 美分的价格购买游戏。
竞争经过半年左右开始升温,iShoot 等游戏通过传统共享软件营销策略夺得市场。当时的 App Store 简直快要爆炸,这是一场通过价格或营销手段跻身排行榜的眼球争夺战。
2009 年夏,iOS 3.0 发布,Eliminate Pro 等游戏开始使用 Apple 新的应用内订购系统处理微交易,并开始由吸引注意向提高持有率过渡。
2009 年末,我开发了一款还不错的游戏 Crash for Cash。这款游戏能吸引用户注意,数次夺得 App Store 排名首位,总下载次数超过 100 万。广告收入很高,但前提是有吸引力,而实际上只留住了很少一部分玩家。
我知道以我当时的开发生涯,还需要更加努力,因为市场在变,如果不能保持玩家多玩几个回合的兴趣,将不可能取得成功。于是我踏上了开发高保持度大作的征程。历时超过一年,friendly.fire 终于开发完成,并在 2011 年圣诞节前发布。
现在我们处于 2012 年的开端,friendly.fire 已经在 App Store 上架约一个月。坏消息是游戏并不如想象中的热门。好消息是坏消息总在意料之内。
我们的团队已经进入新的开发阶段,目标不是完成或发布游戏,而是不断加以积极改进,直到它成为热门游戏。同时,我们也将以系列博文的形式,与 Gamasutra 读者分享接下来几个月的实战经验。我们将记载每一处细节变更,及其所带来的确切净增长率。
开发friendly.fire
在公布进展之前,重要的是了解设计 friendly.fire 及其外围品牌 Friendly Dots 的具体原因。如前文所述,一大缘由便是要开发具有保持度的产品,挣脱 App Store 典型升降机制。
我记得数年前读到过一篇文章,讲的是 NewToy 及 Words with Friends游戏。文章说这款游戏的保持率远高于 App Store 上的其他游戏。当时的我还是一名忙于家庭事务的的丈夫与父亲,也发现自己不再与朋友玩传统游戏了——而是一起玩 Words with Friends。
我迷上了 App Store,并运用手机游戏的两分钟设计理论(如 Crash for Cash 等游戏)数年,但我一直漏掉了游戏中我最喜欢的部分:朋友!这时我才知道,不仅要开发高保持度的游戏,还要满足与朋友一起玩的需求——而且在各种游戏机制中都能实现。
于是我提出了 Friendly Dots 的构想。这一全新商标的初衷是可以用“friendly.任意后缀”的名字开发任何类型的游戏。在模板名字中(可以称呼为 friendly dots 或者 friendlies)加上简单的后缀就可以发布。

最初我们有几款游戏的构想,可以按回合制游戏的形式加工。我们制作了几款原型实测,但实际上都没能提起我的兴致。
作为一名玩家,我这两年间曾喜欢过 Angry Birds、Minecraft 以及 Words with Friends。作为一名开发者,我希望挑战自我,构思出集优秀体验之大成的游戏。有人认为如此招摇地表达自己的影响并不明智,但在这一特例当中,我认为情况很容易看透。我想玩的是可以与朋友一起战斗、分享快乐的游戏。
团队
我是一名够格的全能游戏开发者。我独自开发过很多游戏——要求 3D 建模、2D 贴图、编程、数据库、音乐等等技能的游戏。不过我很早就发觉,friendly.fire 的理念对单人团队而言很难应付。
尤其是作为(以成功为目标的)游戏,它需要强大的后端服务器技术。过去我曾开发的几款游戏中用到了简单的 PHP/MySQL 后台,但我知道需要超脱这些技术的限制。所幸 2010 年末,我认识了本地的程序员 Jon Nadal,他对 friendly.fire 运作所需的技术更为了解。
我向他介绍了 Crash for Cash 的流量(高峰时每日新增用户超过三万)。进行了一些研究后,他给出了 MongoDB 与 node.js 解决方案。测试过程中,这两种技术的组合得以应付每秒两万余次的请求。Jon 和他提出的技术巩固了 Friendly Dots 的核心需求。我们需要超快的服务器方案,现在终于有了。
实现构想所需的另一大部件实际上与技术无关。我们需要有人能理解“社交”的概念,不是 Facebook 或 Twitter 层面的理解,而是这一词汇的真正本质。我们需要熟悉社交玩家,且能代表社区整体的人。John McIsaac 过去曾帮我搞过几个项目,他总能很好地了解普通玩家的方方面面。他天生适合在 Friendly Dots 工作,因为这个商标的核心就是朋友间分享体验,而这始终是 John 关注的焦点。
技术就绪,社区经理也已经归队,于是我开始游戏的设计与程序编写。作为想象力丰富的开发者,我的硬盘里有大量原型代码与资源。其中大多数没有发布过,但我会时不时把一些旧的部件整合到一起,制作出很酷的效果。friendly.fire 中就融合了 Angry Birds 游戏揭秘文章中的一些代码(从未发布过)以及一些动态 2D 物理特性建筑的代码段(现在作为独立的产品,名为 friendly.physics)。
原型
首个原型产品以 iPad 为平台,包括两座城堡与两个弹弓,左右各一个。玩家在包括建造、开火以及修理等一系列回合中尝试毁掉对方的城堡。
游戏的概念大体上得以实现。不过,原型的建筑物部件需要改进。各块都是动态的,虽然提供了建造时的创意自由,却容易导致玩家无意间损毁自己的堡垒。
在另一款游戏 friendly.physics 中,我们将“自由建造”的功能作为乐趣所在。意识到这个问题后,我们返回白板阶段,重新设计了游戏的流程。这次我们制定了更接近于回合游戏的架构,一次只显示一座城堡。我们还将自由建造功能换成了建造阶段的网格平铺系统。
当时有人提出移除物理特性,但我没有同意。作为物理迷,我决心在开火阶段也保持物理引擎运转,尽管更适合在建造阶段使用。我心中仅存的问题是,若各部件只是网格中的区块,游戏是否还能保持有趣与活力。
我由此解决的第一个问题就是网格与平铺系统。因为我就是这样的物理迷。我讨厌编写没有运动的简单捕捉系统,所以我想有所超越——还想看看实际效果。最后,当然有效果,但我的思路让建造阶段与开火阶段的切换 不得不在 2D 与 3D 空间之间转换,而且要有无缝的视觉效果。
我采用的开发库提供了不少二维像素与三维空间点相互转换的功能。我用 Unity 开发并不觉得很难,但还是花了几天才完成了未来可变通的原型。
网格与平铺系统做得可以接受之后,我开始开发各种类型的块。我知道现在游戏处于网格中,很没活力。当然只能通过设计够酷的块类型来解决。如果块本身具有动态属性,则游戏仍然会有趣,玩家将感到创意十足。
首先准备的块类型是典型的木箱、石头以及各种钢材。但直到橡胶块的引入,才变得有意思起来。它们就像弹力泥,可以加速击向它的任何物体。游戏突然有了真正的战略性,因为即使是看起来非常坚固的堡垒也可能被橡胶跳弹切成两半。
这样游戏的基本流程便没什么问题了,但这只能满足单台设备轮流着玩(“Pass and Play”模式)——两人来回递 iPhone 或 iPad。游戏也只有建造与开火模式。
很早发现了一项问题是,建造堡垒的人都希望知道射手会如何尝试打倒他。即时重来也便成为必备功能,但我们担心快速开火系统会引发问题。例如,Angry Birds 中射击后到小鸟跳上弹弓之间有延迟。如果没有缩小画面,镜头会在射击后慢慢移向弹弓,延迟甚至有所增加。

friendly.fire 受 Angry Birds 理念影响的第一处便是镜头滑动。对我而言,这种阻碍完全没必要,它会严重减慢游戏的进行。此外,我们最初的网格原型就像是消耗战,每位玩家有 100 次射击机会,先用光者为输。与之呼应,也为测试玩家的毅力,我们加入了迅速开火的弹弓。玩家可以在 friendly.fire 中任意快速开火。
最后我们的即时重玩系统变得非常简单。射击以初始位置、方向以及时间戳(模拟开火的实际所在帧)存储在服务端。由于 Nvidia PhysX 在单个平台具有确定性,这个系统运作正常。
说实话,我们仍然面对着开火、测试以及即时重玩模式的细微差别,但即时重玩本身也很固定,大多数时候也表现可靠。这也是我希望完善的部分(达到每一像素都完全一样),但我觉得就游戏满意度而言已经足够。
与服务端接轨的原型最后需要的部件是测试模式。Words with Friends 等游戏的方案是让台上的玩家与静态值相关联。如果我要在三个字母的位置填“Zee”,则即使我还没填也知道自己会得 32 分。游戏根据语言与数学的基本技能开发,虽然动态性强,但比物理模拟更加可预测。
就像 Words with Friends 玩家用基本语言与数学闯关一样,friendly.fire 玩家用基本的物理原理(任何孩童都能通过积木建立的概念)闯关。不同之处在于单词非常容易推断,而射击完全具备物理特性的城堡会出现很多不同结果(基本上有无限种可能)。因此玩家可以通过测试模式检查其堡垒被一连串弹弓子弹击中的效果。

原型正常运作之后,就应该让客户端充满大家喜欢的行业技术了。尽管我们以 iPhone 客户端起步,却选择了避免使用有助于利用自己服务器的技术的一系列服务。如此决策的原因很多。
其中最主要的因素是我们想做到跨平台。例如 Apple 有非常优秀的基于关卡的 Game Center 插件,但我们没有采用,因为它会限制我们只用 Game Center 及 iPhone。此外,选择使用其他社交网络也会将我们置于与玩家直接沟通的机会之外。
当然这一论据的关联性是有争议的(就像联系别人很方便,但真的需要通过自己的数据库吗?)我们决定谨慎行事。至少连 Zynga 的价值也因为其对 Facebook 的依赖而挂上问号。
所以我希望成为独立开发者,我们为尽可能独立而自豪。这意味着需要跨平台与对社交网络不表态。
以常规情况而论,我们的服务器架构已经取得突出成就。我们采用了 Amazon 提供的网络服务(大家都在用,对吧?),自圣诞节预览版以来,我们已经数次部署更新,并完成了一些规模变更。
发布游戏时,我们刚好赶在 App Store 放假前搞定。这是每年 Apple 唯一一次停止处理发布,运气好的开发商会因此在新应用列表中多呆一会儿。
《通天奇兵》(The A-Team)中的名言“我喜欢任务完成的时刻”(“I love it when a plan comes together”)恰到好处地描述了游戏及时通过审核后我的反应。没有比这更好的发布时机了。
不足之处是为了赶在节前发布,我们通过 Amazon Web 服务分发了一些大型实例,消耗了不少费用。发布后,我们追踪下载量与游戏使用量,决定尽管应该为成功考虑,但我们还没有成功,所以我们缩小了服务器规模。Jon 对服务器架构掌握自如,让我们相对轻松地完成了规模变动。
从这点而论,我完全感觉到了为游戏当前成功级别所不需要的服务承担代价的痛苦。不过我也深知,只有这样才能习惯管理自己的后端。如果我们先走容易的路,则将面临完全分离的问题,让我们难以控制自己的命运。尽管这一决定在短期没有让我们受困太多,我坚信从长期的战略角度来看,这种策略会有所帮助。
早期数据
现在到本篇报告最尴尬的部分了。成功营销数款 iPhone 游戏、撰写数篇文章以及一本书后;通过 iPhone 开发赚得数万美元之后;着手开发比以前更大、更棒,或者只是更酷的作品之后;friendly.fire 的第一个月一败涂地。
在 Crash for Cash 高峰期取得每天三万次下载的成绩、两年后还能每天吸引两千名新用户的市场,friendly.fire 花了三个月才达到两千人的用户总量。更糟糕的是,在总计两千多次下载中,只有 150 名用户真正按设计意图注册了对战服务。最糟糕的是,这 150 名用户中,有 42 人没有与其他玩家对阵。坦率地讲,我们麻烦了!
早期改进
当然,在这早期困境面前,我们可以打包回家——但那样很没意思,对入戏并坚持玩的玩家也不友好。我们已经完成早期设计,付诸实践,并进行了调整。其中一例便是主菜单。最初“轮流玩”选项处在第一位,下面才是“联机玩”。理由(有点傻)是“联机玩”更为复杂。

实际上,“轮流”模式与游戏并不相关。此外“联机”一词听上去也有点吓人。所以在最新版中,我们调换了按钮的顺序,“联机玩”也改成了“与朋友一起玩”。

这项变更几乎让选择注册加入联机游戏的玩家所占百分比增加了两倍。最初的按钮组合让 4.8% 的玩家选择了“联机”。语言及按钮位置改动后这一数字一跃至 13%。

这些小修改无疑证明了弱点出在细节上。选项完全一样,语言最初也很透明,但更改选项顺序,并让语言更“友好”但含糊之后,却取得了巨大增长。结果三天内我们的玩家池扩大了一半。
展望
friendly.fire 以及整个 Friendly Dots 项目采用了不断改进(“get it out and iterate”)的方案。当然我们也有外围策略,但没能改变现实。我们最初的目标是开发出游戏并赶在节日发布,然后开始引入微交易形式的内容。
整个开发过程当中,我反复告诉队友(以及我自己)我希望游戏立刻就上架,但即使没有,也不要担心,因为游戏是关于保持度的,而非关注度。我们的测试已经证明人们喜欢我们的游戏。游戏在 App Store 保持了五颗星评分的事实也证明了陌生人并不讨厌我们的游戏。我们的改动已经证明了界面糟糕,玩家可能没有完全理解我们的游戏。
1.02 版本将对界面做出细微改进,开始加入可自定义的内容,并为额外的内容安排较大的服务器调整。在接下来的一个月内,我们计划对界面进行彻底革新,并引入积分系统、背景选项以及应用内订购。
在某些层面上,我们对 friendly.fire 的真实目的是为玩家提供轻量级的游戏设计体验。为朋友设计关卡的玩家,简直就是一名游戏设计师。我知道自己很多次为朋友设计关卡,并非为了挑战,而是为了乐趣。从这些思路展开去想,游戏中当然存在大量的潜在价值。