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

开发者分享《friendly.fire》更新内容的经历

作者:Jeremy Alessi

上个月我们完成了功能齐全的《friendly.fire》,但其运作效果不尽人意。入驻App Store的首个月,游戏只有约150位的注册用户,各方面的表现都非常糟糕:下载量、下载用户&注册用户的转换率,以及注册用户&留存用户的转换率。

虽然之前的文章内容主要围绕《friendly.fire》背后的故事,但我们也有谈到游戏发行之后的一个重要变更。通过调整2个按键的顺序,变更若干游戏语法,我们顺利将游戏的注册用户翻了3倍。

我们撰写本系列文章及在《friendly.fire》中采用此开发模式的一个主要目的是,查看细微变化能够给用户数量涨幅带来什么影响。

在游戏发行的第2个月,我们推出3个《friendly.fire》更新内容。在这些更新中,我们积累众多有关异步社区游戏什么内容可行,什么不可行的宝贵经验。本月我们获得显著发展,但同时也犯下若干可能带来严重危害性的错误。

版本1.03

就如我们头个月在Gamasutra公布的报告,版本1.03通过了App Store的审核。我们上个月的一个主要关注点是,UI表现糟糕。版本1.03的《friendly.fire》就次糟糕UI做出了系列完善。

这是截至目前的进展情况:

菜单原始版本 from gamasutra.com

菜单原始版本 from gamasutra.com

新版本 from gamasutra.com

新版本 from gamasutra.com

没有发展元素的Version 1.03 from gamasutra.com

没有发展元素的Version 1.03 from gamasutra.com

融入发展元素的Version 1.03 from gamasutra.com

融入发展元素的Version 1.03 from gamasutra.com

就如我们之前所说的,我们调整了在线体验按键和本地体验按键的顺序。此外,我们还将“Play Online”改变成“Play with a Friend”。这一细微调整将我们的用户注册率由4.8%提高至13%。

从版本1.03开始,我们将转而采用强制注册模式。因此现在注册过程将出现在上述游戏主页面之前。有趣的是,单切换至强制注册模式就将我们的下载&注册用户转换率提高至20%。进一步观察后,我们发现,我们的工具不支持Unicode,因此很多外国注册用户无法顺利注册游戏。

添加游戏分类列表对UI来说非常重要,这提高游戏体验的整体质量。在版本1.03之前,我们只向用户呈现冗长的常玩游戏列表;这些游戏贴有“轮到他们”、“轮到你”或“你胜出”之类的标签。我们还清除许多多余的页面,同时将原本有些含糊不清的元素划分到更明确的页面中,旨在清楚呈现预期的功能元素。

总之,版本1.03极大提高UI的质量。就游戏本身来说,其最大的添加内容是全新的背景元素。我们有提出融入不同背景元素和定制好友的理念,但直到这一版本,我们才顺利将其落到实处。所以游除戏UI变得更突出外,游戏本身也呈现更丰富的内容——这方便我们在App Store列表中发布新截图。

说到截图,我们在版本1.03中添加的一个杰出功能是页面分享功能。随着游戏融入背景和角色定制元素,用户创造性开始在游戏中发挥更大作用。

在某测试会议中,我们曾试图改造影片场景,看看其他玩家能否猜出我们创建了什么内容。最终,这个构思未能实现,因为角色定制选项非常有限。但这给我们带来更多的可能性空间,我们得以植入各式各样的社交页面分享功能,包括Facebook、Twitter和邮件选项。

毫无疑问,版本1.03的诞生令我们颇为兴奋。但内容发行后,在下载应用时我非常震惊,发现游戏竟然还是早期的内容,我以为自己有将其替换成修正版本。显然,我将同个版本上传2次。

因此,很多版本1.03的功能并没有出现在游戏中。我给游戏设计了新的App Store图标,但一下载完应用,图标又变回旧的样式。很多UI强化功能也不见了。但最糟的是,这个版本同我们的开发服务器绑定。这意味着用户无法访问他们的应用,新用户无法同老用户连接。

幸运的是,通过切换域名绑定我们很快就解决了这个问题。糟糕的是,我们需要手动挪动约10位玩家(游戏邦注:他们登陆错误的服务器)。我们曾考虑将应用移除App Store,但经过短暂考虑后,我们决定充分发挥这一版本——这最终非常成功,相对此项目本身目而言。凭借版本1.03,我们将自己的用户基础扩大了300%,尽管这一版本依然存在很多磕磕碰碰。

版本1.04

总体而言,版本1.04是修复1.03的补丁。事实上,这原本就是版本1.03应该呈现的内容。版本1.04的有趣之处在于,出于某些原因,它没有出现在新发行内容名单中。

苹果的政策有时有些不透明。App Store最初的策略是,在新列表中发布游戏,无论内容是全新作品,还是只是更新内容。这非常不错,因为它让在旧作品中添加新内容的开发者从中获得回馈。

2009年末,苹果改变这一政策,因为这遭到大家的滥用。但出乎我意料的是,当我们推出《friendly.fire》1.01版本时,游戏重新出现在新作品名单中。版本1.02和1.03也一样,双双重新出现在新发行内容名单中。

就这点来说,我确信苹果已恢复其原有政策,将更新内容呈现在新作品列表中。但当版本1.04问世时,令我们失望的是,我们并没有在新内容列表中占有一席之地。这极大降低作品的曝光度。但版本1.04促使我们的注册用户增加到1000多人(游戏邦注:虽然版本1.03到0.04的用户增加比例并不显著)。

版本1.05

虽然我们的用户基础相比作品发行头个月增加了近10倍,但我们非常清楚,其中也存在些许问题。就如我在之前的文章中提到的,这款游戏涉及留存率,但若无法引起用户注意,我们就不能留住它们。所有游戏都存在瀑布效应:

* 查看游戏的用户人数

* 下载游戏的用户人数

* 注册游戏的用户人数

* 在线体验的用户人数

* 享受游戏的用户人数

* 返回游戏的用户人数

到版本1.04,《friendly.fire》几乎在各个方面都出现问题。我们在App Store丧失曝光度;我们从未获得过大量的下载量。多数用户依然不确定游戏的机制。唯一值得高兴的是,看过游戏,进行下载,且享受其中的用户持续重返游戏之中。

看到核心玩家在体验游戏2个月后依然频繁重返游戏让我们重拾信心。这充分说明,游戏的核心机制非常稳固。正因为如此,我们开始逐步创造此瀑布效应,辨别自己的瓶颈。我们应对的首个瓶颈是,解决玩家对于创建机制的误解。

由于《friendly.fire》采用iPhone常见的机制,因此我们从一开始就没有在指南上花功夫。我们认为用户现在都清楚如何使用弹弓及在网格中陈列方块。

我们完全错了。

有一种说法是,成功的游戏应包含90%的熟悉元素和10%的新鲜元素。在我们眼中,弹弓和网格机制属于90%的熟悉元素。而玩家需要在其中进行转换则属于突出游戏的10%新鲜元素。显然,我们的比例至少是80/20,因为随机分布的堡垒数量非常惊人。

要解决这一问题,我们在版本1.05中引入指南元素。这一新添加的内容指导玩家如何运用弹弓,其采用的方式让玩家射击若干未受保护的圆点状好友。然后它接着创建旨在告知玩家如何在网格中移动方块的构建页面,促使他们面临包含好友的挑战。然后,玩家需要炮击刚刚创建的堡垒。最后,我们向玩家呈现包含各式各样方格类型的画面,这样他们就能够试验和查看各方块的不同物理属性。

指南开始 from gamasutra.com

指南开始 from gamasutra.com

解释堡垒创建机制 from gamasutra.com

解释堡垒创建机制 from gamasutra.com

添加指南令我们的一个关键参数获得提高。注册用户&在线体验用户的转换率由65%提升至85%左右。

目前情况

到版本1.05,我们就已呈现自己的所有核心体验。但虽然我们逐步将注册用户数量提升了10倍,但游戏依然算不上是一款iOS热作。

值得高兴的是,现在我们的UI具有流动性,玩家真正理解游戏的玩法机制。坏消息是,很多用户似乎对游戏并不感兴趣,我们的下载数量非常低,我们在App Store丧失曝光度——促使我们不得不转投他处提高自己的曝光度。

幸运的是,早在《friendly.fire》之前,我恰好开发过几款颇受欢迎的游戏。因此,我采取的第一个举措就是利用我之前的iPhone游戏作品宣传这款游戏。截至目前,一切都进展得非常顺利——但我之前的作品相比《friendly.fire》本身,从中受益更大。

一个典型例子就是,免费呈现由《friendly.fire》“赞助”的《Skyline Blade》游戏。这给这款游戏带来25万次的下载量。起初,《friendly.fire》的运作也非常顺利,因为当《Skyline Blade》采用免费模式后,游戏的日下载量从几乎为零提高至400次。

但游戏的发展趋势并未因此实现同步。随着《Skyline Blade》下载量由1万次提高到2万次,再到4万次,《friendly.fire》则从400次下降到200次,再到100次。事实证明,游戏下载量激增更多是由于《friendly.fire》转投免费模式,而非《Skyline Blade》对于《friendly.fire》的大肆宣传。

借助Admob

除在我之前所有游戏的App Store页面上宣传《friendly.fire》外,我们还发起3个Admob广告活动。一个是美国国内的广告活动,一个是支撑Norfolk游戏开发的本地广告活动,最后一个是内部广告活动,在我之前的作品中宣传《friendly.fire》。

这些活动的结果非常有趣。我们发现,全国范围内的工作室内部广告活动获得3.89%的点击率,本地外部广告有0.41%的点击率,但全国外部广告只有0.01%的点击率。我们可以做出此推断,在看到有关《friendly.fire》的宣传内容后,玩家更可能点击广告。

遗憾的是,工作室内部广告点击用户&注册用户的转换率只有10%(游戏邦组:自发起此广告活动以来)。

最后,我们的主要目标是创建自己的用户基础,然后才是争取获得丰厚营收,因此要实现此目标,游戏商业模式的转变要比开展广告活动有效得多。

screenshot from gamasutra.com

screenshot from gamasutra.com

总结

就游戏过去在App Store所取得的成绩来看,《friendly.fire》显然很难达到其应有的高度。到版本1.06,游戏所能进行的改变无非就是系列调整和润色,从而实现我们的原始目标。

到目前的第3个月,我们已拥有众多选择,但我们多半会选择重新改造《Friendly Dots》和《friendly.fire》。从一开始我们就选择此美学、角色和“friendly”品牌,以期能够扩大自己的用户覆盖范围。我们发现众多用户——大到40岁的中年男子,小到3岁的小女孩,都非常喜欢《friendly.fire》。但现在令我们困惑的是,我们希望掳获“所有用户”的目标导致多数人觉得游戏似乎瞄准“他人”而设计。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Making an iOS Hit: Phase 2

by Jeremy Alessi

[Jeremy Alessi has been developing iOS games since the inception of the platform -- and his latest effort, friendly.dots, takes into account shifts in the market and all the lessons he's learned. As he strives to make the game a hit on the App Store, he's writing a monthly column for Gamastura about the data he's collecting and the resultant changes in the game. You can find the first installment here.]

Last month we left off with friendly.fire functional, but not doing so hot. After its first month on the App Store, it had only collected around 150 registered users and it was failing in all regards: the number of downloads, the conversion of downloads to registered users, and the conversion of registered users into retained players.

While the prior article was primarily concerned with the back story behind friendly.fire, we did cover one significant post-release change in the game. By switching the order of two buttons and changing some wording, we nearly tripled the number of users who registered for the game.

One of the primary reasons for this series of articles and for the approach we’re taking to the development of friendly.fire is to monitor percentage gains enabled by small changes.

During the second month of release, we released three updates for friendly.fire. Within each of these updates there were valuable lessons for what to do and what not to do with an asynchronous, community-based title. We made some huge gains this month, but we also made some potentially disastrous blunders.

Version 1.03

Just as our first month report was published on Gamasutra, version 1.03 was approved for distribution on the App Store. One of our prime concerns last month was that our UI just wasn’t doing the job. Version 1.03 of friendly.fire addressed our initially clumsy UI with a variety of improvements.

Here’s the progression thus far:

The original version of the menu

As stated in last story, we switched the order of our play online button and our local play button. In addition we changed the wording from “Play Online” to “Play with a Friend”. This minor adjustment changed our registration rate from 4.8 percent to 13 percent.

Beginning with version 1.03, we actually switched to a mandatory registration. The registration process thus now occurs before the primary title screen pictured above. Interestingly enough, switching to mandatory registration only increased our conversion from download to registered user to 20 percent. Upon further inspection, we found that our implementation lacked Unicode support, thus many of the foreign language downloads we saw were unable to actually register for the game.

The addition of a categorized game list is an important feature of the UI that has improved the overall quality of the experience. Prior to 1.03, we simply gave the user a long list of their active games; the games were labeled as either “their turn”, “your turn”, or “you won”. We also cleaned out a number of redundant screens, while at the same time dividing up some of our more confusing elements into more clearly defined screens to clarify the intended functionality.

Overall, version 1.03 represented a vast UI improvement. In terms of the game itself, the only major addition was new backgrounds. We had developed the concept of different backgrounds and customization for the friendlies, but we weren’t able to execute on them until this version. So in addition to the UI looking fresh, the game also finally had some variety — which was great for posting new screenshots in our App Store listing.

Speaking of screenshots, one of the features added to version 1.03 that I thought was neat was a screen-sharing feature. With the addition of backgrounds and character customization, user creativity was starting to play a larger part in the game.

During one testing session, we began recreating scenes from movies and seeing if the other player could guess what we had made. Ultimately, this concept fell short, because the character customization options were so limited. Nevertheless, it opened the door for great future potential and we managed to implement a variety of social screen-sharing features, including Facebook, Twitter, and email options.

Needless to say, we were very excited by version 1.03. Upon release, though, I was shocked when I downloaded the app and found that it was an earlier development build that I had thought I had replaced with the correct version. Apparently, I must have accidentally uploaded the same development build twice (or there was a database error).

As a consequence, a number of features in version 1.03 were not present. We created a new icon that was visible in the App Store, but as soon as the app downloaded, it reverted back to the old icon. A number of UI enhancements were lost, too. But worst of all, the build connected to our development server! This meant that users would not be able to access their accounts, and that new users would not be able to connect with old users.

Luckily, switching domain pointers quickly resolved this issue. The worst of it was that we had to manually move over about 10 users who got registered with the wrong server. We briefly considered simply pulling the app from the App Store, but by thinking quickly we managed to capitalize on the release — which was ultimately very successful, relative to this project. We managed to grow our player base by 300 percent with version 1.03, despite the release hiccups.

Version 1.04

By and large, version 1.04 was a patch to fix version 1.03. In fact, it was exactly what version 1.03 was supposed to be. The interesting part about version 1.04 was that for some reason it was never placed in the new release list.

Apple’s policies can sometimes be very gray. The App Store originally began with a policy of posting games in the new list whether they were new or simply updated. This was great, as it rewarded developers for adding new features to older apps.

In late 2009, Apple changed this policy because it was being abused (people just submitted update after update to maintain visibility, whether new features were added or not). Much to my surprise, though, when version 1.01 of friendly.fire was released, it landed back in the new list. Version 1.02 and 1.03 shared the same fate, both landing back in the new release list.

Based on this, I thought for sure that Apple had reverted to its original policy of putting updates in the new list. When version 1.04 hit, though, it was disappointing to see that it did not earn a spot in the new list (despite having a variety of new features over 1.03.) This decreased its visibility tremendously. Nevertheless, version 1.04 took us to beyond 1,000 registered users, although there were no noticeable percentage gains from 1.03 to 1.04.

Version 1.05

Although our player base had increased nearly 10x from our first month, we were well aware that not all was well. As stated in the original article, this game was about retention, but without getting a player’s attention, there is no way retention is going to happen. With any game, there is a cascading effect:

* number of people see game

* number of people download game

* number of people who register

* number of people who play online

* number of people enjoy game

* number of people who return

By version 1.04, friendly.fire had problems in almost every one of these areas. We lost visibility in the App Store; we never had a lot of downloads. Most people were still unsure of the game’s mechanics (a typical fortress from a new player consisted of just the random palette of blocks they were dealt). The one bright spot was that the people who saw the game, downloaded it, and enjoyed it were also returning to it regularly.

Seeing certain key players return to the game over and over even after they had been playing for two months is what gave us hope. This aspect, over any other, demonstrated that the core of the game was solid. With that in mind, we began working up the cascade and identifying bottlenecks. The first bottleneck we chose to tackle was players’ misunderstanding of the build mechanics.

Because friendly.fire uses mechanics that we considered ubiquitous on the iPhone, we did not invest in a tutorial from the outset. We figured that people knew how to use a slingshot and arrange tiles in a grid by now.

We were wrong.

There’s a saying that a successful game is 90 percent familiar and 10 percent unfamiliar. In our eyes, the slingshot and grid system were the 90 percent. The fact that players had to transition between them was the 10 percent that differentiated this game. Apparently, we must have landed at at least 80/20, because the number of randomly-arranged fortresses was alarming.

To combat this, version 1.05 introduced a tutorial. This new addition walks players through use of the slingshot by letting them shoot some unprotected friendly dots. Then it moves on to a build screen that shows players how to move blocks in the grid and challenges them to protect the friendlies. Next, players are tasked with firing upon the fort they just built. Finally, we give players a scene with a variety of block types so they can experiment and see what the various physical properties of each block are.

The addition of the tutorial increased a key statistic in our cascading hierarchy. The conversion rate between registration and playing online moved from around 65 percent to around 85 percent.

Now What

As of version 1.05, we have delivered our full core experience. However, though we have managed to drive a tenfold increase in player registrations month over month, we are still a long way from creating an iOS hit.

The good news is that now our UI flows, and players comprehend the gameplay mechanics. The bad news is that a large population of players seems uninterested in the game, our download numbers are low, and we have lost visibility on the App Store — causing us to look elsewhere for discoverability.

Luckily, I happened to have developed a few popular games prior to friendly.fire. One of the first steps, therefore, was to use my old portfolio of iPhone games to advertise. So far, this has worked out pretty well — but more so for the old games than for friendly.fire itself.

One such instance was a free release of Skyline Blade “sponsored” by friendly.fire. This netted about a quarter of a million downloads in a week for Skyline Blade. Initially, things were looking good for friendly.fire as well. The game went from next to no downloads to around 400 a day when Skyline Blade went free.

However, the trendlines for the games proved not to be synchronized. As Skyline Blade increased downloads from 10k to 20k to 40k day over day, friendly.fire moved from 400 to 200 to 100. As it turned out a price drop to free on friendly.fire was far more responsible for the download spike than the blurb about friendly.fire on Skyline Blade.

Enter Admob

In addition to advertising with blurbs about friendly.fire on all the App Store pages of my older portfolio, we also ran three Admob campaigns. One was a national campaign for the U.S., another was a local campaign to support Norfolk game development, and the last was a house ad campaign appearing within my older titles that had blurbs about friendly.fire.

The results of these campaigns were very interesting. We saw a 3.87 percent click through rate (CTR) on the national house ads, a 0.41 percent CTR on the local external ads, but only a 0.01 percent CTR for national external ads. It seems reasonable to assume that players are more likely to click on the ads after seeing a blurb about friendly.fire.

Unfortunately, the conversion from a house ad click to a registered user is only 10 percent since the ads have been running.

Finally, with our primary goal being to build our player base before worrying about revenues, the spike created by fluctuating from paid to free on the app store has been far more effective than advertising (at least with Admob).

Conclusion

Having witnessed successful App Store climbs in the past, it is difficult to watch friendly.fire struggle to gain the traction it deserves. Moving onto version 1.06, there isn’t much to add with the exception of a few tweaks and polish points for this game to meet our original expectations.

Moving into our third month, we have a number of options on the table, but it’s looking likely that we will in fact re-brand Friendly Dots and friendly.fire. At the outset we chose the aesthetics, characters, and “friendly” branding so that we might reach ubiquitous status. After all, we have seen everyone — from 3 year old girls to 40 year old men — enjoy friendly.fire. However, we are now questioning whether our effort to grab “everyone” has resulted in most people feeling as if the game is actually just for “everyone else”.(Source:gamasutra


上一篇:

下一篇: