作者：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》的相关流量数据（游戏邦注：它在最高峰时期每天都有超过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》的目标是为玩家创造轻松的游戏设计体验。当你在为好友创建关卡时，你便是游戏设计师。我也发现了很多时候当我真正在为好友设计关卡时，我更关注的是游戏的乐趣而不是挑战。如果一直这么想，我们便能够实现出更多的可能性。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Building an iOS Hit: Phase 1

by Jeremy Alessi

I’ve been developing iPhone games since the App Store’s inception in 2008. Along the way, there have been a variety of trends as the market evolved. Initially, almost anything would sell. People were simply ecstatic to pay 99 cents for a game.

After six months or so, the competition began heating up, and titles such as iShoot gained popularity by using traditional shareware marketing techniques. At that point, the App Store was all about pop. It was a game to see who could get the most attention on day one via price or slick marketing in order to rise to the top of the charts.

During the summer of 2009, with the release of iOS 3.0, games such as Eliminate Pro began to use Apple’s new in-app purchase system for microtransactions, and so began the transition from getting attention to gaining retention.

At the end of 2009, I created an okay game called Crash for Cash. This title was good at getting attention, and it rose to several number one spots on the App Store and garnered more than 1 million downloads. The advertising revenue from the title was impressive, but it was based on getting attention; a fairly small percentage of players were actually retained.

I knew at that point in my development career that I’d need to do better, because the market was changing, and if you couldn’t keep players interested for more than a few rounds, success would be impossible. I set out on a quest to create a great game that would have retention. This little journey lasted for over a year before resulting in friendly.fire, which was unveiled just before Christmas 2011.

Now we’re in the beginning of 2012, and friendly.fire has been on the App Store for about a month. The bad news is that the game isn’t doing so hot. The good news is that the bad news was always part of the plan.

Our team has now entered into a new phase of development where our goal isn’t to get our game done and out the door, but rather to make continual documentable improvements until we have a hit on our hands. In addition, we’ll be sharing our experience with Gamasutra readers over the course of the next few months as part of a series. In this series we will document the tiniest changes and the exact percentage gains these changes netted us.

Enter the Development of friendly.fire

Before we begin reporting our progress it’s important to understand exactly why we created friendly.fire, and the overarching brand Friendly Dots. As I described above, a big motivator for us was to create something with retention and to break away from the typical pop/fall mechanics of the App Store.

I remember reading an article a couple of years ago about NewToy and Words with Friends. This article stated that the game’s retention rate was far higher than that of other games on the App Store. I also realized that as a busy husband and father I really wasn’t getting to play traditional games with my friends anymore — but I was playing Words with Friends with them.

I was already enamored with the App Store, and I had been employing the two minute game design theory of mobile games (with titles like Words with Friends) for years, but until this point I was missing my favorite part of playing games: my friends! That’s when I knew that I not only wanted to create a game with retention, but that I wanted to play games with my friends again — and I could do it with any game mechanic.

This is when I came up with Friendly Dots. The whole premise of this new label is that we can create any game and call it “friendly.whatever”. We added some simple characters to the mix (conveniently called the friendly dots, or friendlies) and we were on our way.

In the beginning we had several games on the table that could potentially receive the turn-based treatment. We created a few prototypes that will probably see the light of day at some point, but in truth I wasn’t excited about any of them.

As a gamer, I had been in love with Angry Birds, Minecraft, and Words with Friends for the last two years. As a developer, I wanted to challenge myself to come up with something that combined my favorite gameplay experiences. Some people don’t think it’s prudent to disclose your influences so blatantly, but in this case I think it’s very obvious. The game I wanted to play was one that would allow me to build, destroy, and share it all… with my friends.

The Team

I’m a competent all-around game developer. I’ve developed many games solo — games that involve 3D modeling, 2D sprites, programming, databases, music, and more. However, I knew early on that the concept of friendly.fire was too big to tackle as a one-man band.

Specifically, the game (upon success) would require a robust backend server technology. In the past I had created several games that included simple PHP/MySQL backends, but I knew that I wanted to go beyond the limits of those technologies. Luckily, in late 2010 I was introduced to another local programmer, Jon Nadal, who had a better handle on the technology that friendly.fire needed to tick.

I described to him the amount of traffic I saw with Crash for Cash (in excess of 30,000 new users a day at its peak). After doing some research he came back with a solution involving MongoDB and node.js. In some tests, the combination of these technologies had been able to handle as many as 20,000 requests per second and beyond. Jon and the technology he brought to the table solidified a core necessity of the Friendly Dots plan. We needed a super fast server solution and now we had it.

The other component necessary to pull the concept off really had nothing to do with technology. We needed someone who understood “social”, and not in the Facebook and Twitter sense of the word, but in the truest nature of the term. We needed someone who got people and could represent the community at large. John McIsaac had helped me with several projects in the past, and he always had a good read on the basic everyday person. He was a natural fit for Friendly Dots, because at its core, the label is about friends sharing experiences, which is always paramount in John’s mind.

With our technology in place and a community manager lined up, I headed up the game design and programming. As a developer with an active imagination, I have mountains of prototype code and assets on my hard drive. Most of it doesn’t see the light of day, but every now and then I’ll pull a few old components together to create something cool. With friendly.fire I combined some code from a Games Demystified article on Angry Birds (which never saw the light) with some dynamic 2D physics-enabled building block code (which is now its own product, called friendly.physics).

The Prototype

The first prototype was made for the iPad, and it featured two castles and two slingshots, one of each of the left and again on the right. Players progressed in a series of turns including build, fire, and repair phases, as they attempted to knock down each other’s castles.

Overall, the concept definitely had merit. However, the building component of the prototype needed work. The pieces were all dynamic, which was great in terms of the creative freedom one had when building, but as a consequence users were more likely to accidentally knock their own fortress down.

We deemed the “free building” feature as fun for another game (friendly.physics). Realizing this was a problem, we went back to the whiteboard and redesigned the game’s flow. This time, we created a more rigid turn based structure in which only one castle would appear at a time. We also replaced the free build feature with a grid and tile system for the build phase.

There was talk of actually excluding physics altogether from the game but I wouldn’t have it. As a physics junkie, I was determined to keep the physics engine running during the fire phase, even though I knew the build phase was better off without it. The only question that remained in my mind was whether the game would still be fun and feel dynamic if all the parts were just blocks on a grid.

The first thing I tackled from that point was the grid and tile system. Since I am such a physics junkie. I hate programming discreet snapped systems with no motion, so I wanted to get that part over with — and I also wanted to see if it would work. In the end, of course, it did work, but the way in which I programmed it the game would have to translate between 2D and 3D space upon transitioning from the build phase to the fire phase, and it would have to look seamless.

The little library I knocked up included a lot of functionality for getting a pixel within the center of a rectangle from a point in space, or getting a point in space from a pixel. This wasn’t too terribly difficult with Unity at my side, but it took me a few days to get something I felt was flexible enough for the future.

Once the grid and tile system was reasonable, I began creating various block types. I knew that with the game now on a grid that it would be far less dynamic. The cure, of course, would be cool block types. If the blocks themselves had very dynamic properties, the game could still be interesting, and allow players to feel creative.

The first block types were typical wood crates, and stone and steel varieties. Things didn’t really get interesting until I introduced the rubber block, which actually worked more like “flubber”, greatly accelerating any projectiles that made contact with it. Instantly, the game began to have some real strategy, because even the sturdiest-looking fortress composed of steel blocks could be cut in half by a rubber ricochet.

At this point, the basic gameplay flow was working pretty well, but it was only working in “Pass ‘N Play” mode on a single device, where two friends could pass an iPhone or iPad back and forth. The game consisted only of build and fire modes.

One issue identified really early on was that whoever built a fort really wanted to see how the shooter attempted to take it down. Instant replay became a necessary feature, but we were worried that our quick firing system would be a problem. For example, in Angry Birds, there’s a delay between firing as the birds jump into the slingshot to reload. This delay is even furthered by the fact that unless you’re completely zoomed out, the camera slowly scrolls back to the slingshot after firing.

With friendly.fire the first thing on the chopping block from the Angry Birds formula was the camera scrolling. To me, this was always an unnecessary impediment, which slowed the game down too much. Furthermore, our first grid-based prototype played out like a war of attrition, in which each player had 100 shots. The player who used all 100 first lost. To go along with this, and test the player’s willpower, we included a rapid-fire slingshot. Players can fire as fast as they want in friendly.fire.

In the end, our instant replay system ended up being very simple. Shots are stored on the server as an initial position, a launch vector, and a timestamp (the actual frame in the simulation in which the shot was fired). Due to the fact that Nvidia PhysX is deterministic within a single platform, this system worked.

To be honest, we are still encountering slight differences between fire, test, and instant replay modes, but the instant replays themselves are deterministic and most of the time our instant replays play out in a plausible manner. This is one area of the game that I really want to get perfect (for side-by-side pixel-perfect comparisons) but I feel that overall it does what we wanted in terms of gameplay satisfaction.

The final necessary component for our prototype before moving into our server-enabled version was a test mode. With a game such as Words with Friends, the solution a player presents on the board has a very static value associated with it. If I lay down the word “zee” starting on the triple letter score, I’m getting 32 points and I know it even before I lay the word down. The game builds upon the basic skill sets of language and mathematics, and it’s dynamic to be sure, but it is much more predictable than a physics simulation.

Just like a Words with Friends player uses basic language and mathematics to play, a friendly.fire player uses basic physics principles (established by any child with a set of building blocks) to play. The difference is that the outcome of a word placed upon a board is fairly easy to spot. The outcome of someone shooting a fully physics-enabled block castle has many more outcomes (essentially infinite). The test mode thus allows the builder to try their own fortress on for size to see how it reacts to a barrage of slingshot pellets.

The Cloud

With the prototype working well it was time for us to hook everyone’s favorite buzzword into our client. Although we were starting with an iPhone client, we chose to avoid a number of services that could assist us in favor of rolling our own server technology. The reasons for this decision are numerous.

Paramount amongst them was that we wanted to go cross-platform. Apple, for example, has a very nice turn-based add-on for Game Center, but we avoided it because it would limit us to Game Center and the iPhone. Furthermore, choosing to use anyone else’s social network exclusively puts us out of direct contact with our players.

While the relevancy of this argument is debatable (like it’s pretty easy to reach anyone these days, do you really need to reach them through your own database?) we decided to err on the side of caution. After all, even Zynga’s value comes into question because of that company’s dependency on Facebook.

So, I suppose being independent developers, we pride ourselves on being as independent as possible. That meant we needed to be cross-platform and social network agnostic.

For the most part, our server architecture has been a resounding success. We used Amazon Web Services (who doesn’t, right?) and since our Christmas preview we’ve made it through several updates and several scale changes.

When we launched the game, we made it onto the App Store just in time for the holiday shutdown. This is the only time of year when Apple halts processing, giving lucky developers a little more time on the new list.

The saying “I love it when a plan comes together” from the A-Team pretty much describes my reaction when we got approved in time for the holidays. We really couldn’t have timed the release of the game any better.

The downfall is that in preparation for the holiday rush, we cranked up our Amazon Web Services to use some large instance servers that ended up costing me a pretty penny. After release, we looked at the download numbers and the game usage, and determined that although it was a good idea to prepare for success, we simply weren’t there yet, so we scaled our servers down. Jon did an excellent job with the server architecture, which allowed us to manage these scale changes with relative ease.

At this point, I’m certainly feeling the pinch of paying for a service that the game doesn’t really need at its current success level. However, I’m also keenly aware that the only way for us to become accustomed to managing our own backend is to actually walk that road. If we had taken the easy way out, then we’d be dealing with completely separate issues that would in no way prepare us for to control our own destiny. Although this decision hasn’t netted us much in the short term, I firmly believe in the long-term strategy that this tactic supports.

Early Numbers

Now it is time for the embarrassing part of the report. After having successfully marketed several iPhone games, writing several articles, and a book… After having earned hundreds of thousands of dollars from iPhone development… After setting out to make something bigger, better, and just plain cooler than anything I think I’ve done before… the first month of friendly.fire has been a resounding flop.

Where Crash for Cash peaked at over 30,000 downloads a day and still manages to collect 2,000 new users a day, over two years later, friendly.fire took three weeks to collect 2,000 users. Worse still, of the 2,000+ total downloads, only 150 of them actually registered to play mobile-to-mobile, as the game was intended. Worse still, of those 150 users, 42 are not involved in a game with another user. To put it bluntly, we suck right now!

Early Improvements

Of course, in the face of this early “suckage”, we could just pack up and go home –but that wouldn’t be very fun, or friendly to the users who are really into our game and play it constantly. We have already taken these early metrics, applied them practically, and changed things. One such early example is our main menu. Initially, we put our “Pass ‘N Play” option first, followed by a “Play Online” button. The reasoning (however boneheaded) was that “Play Online” was a more complex option.

In truth, though, the “Pass ‘N Play” game mode is really not what the game is about. Furthermore the word “Online” can sound intimidating. So, with our latest release we reversed the order of the buttons and also renamed the “Play Online” button to “Play with a Friend”.

This nearly tripled the percentage of players who chose to register and take part in the mobile-to-mobile gameplay. The initial button combination resulted in 4.8 percent of players registering to play “Online”. By changing the language and button position we jumped to 13 percent.

These tiny metrics prove without a doubt that the devil is in the details. Our options were exactly the same, and our language was crystal clear initially, but changing the order of our options and making the language more “friendly” but simultaneously more vague netted us a huge gain. As a result, we saw a 50 percent increase in the size of our player pool in three days.

Where To?

With friendly.fire, and Friendly Dots overall, we’re using the “get it out and iterate” approach. We certainly have an overarching strategy, and that hasn’t really changed. Our goal from the beginning was make the game, sneak it out just in time for the holidays, and then begin introducing content that would eventually lead the way to microtransactions.

Throughout the entire development period, I told my team members (and myself) repeatedly that I hoped the game would pop right away, but that if it didn’t, we shouldn’t worry, because the game was about retention, not attention. Our test sessions have proven to us that people really like our game. The fact that the game maintains a 5-star App Store rating has proven to us that strangers don’t hate our game. Our metrics have proven to us that our interface is horrible, and that players may not fully comprehend our game.

With the release of version 1.02, we made minor improvements to the interface, began adding customizable content, and successfully navigated a breaking server change due to the additional content. In the coming month, we plan to introduce a completely overhauled interface, a credit system, background options, and in-app purchasing.

In some sense, our real goal with friendly.fire is to provide a lightweight experience of game design for players. When you build a level for a friend, you are the game designer. I know that many times already I’ve chosen to design levels for my friends not based on challenge, but based fun. Thinking along those lines opens up a whole slew of new possibilities, of course.(source:Gamasutra)