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