[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 Gamasutra 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

The new version, with "Play Online" changed to "Play With a Friend", and buttons reordered

Version 1.03, with no in-progress games

Version 1.03, with games in progress

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:

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, becausethe 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 beginning of the tutorial

The fort-building mechanic explained

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".