[In the first installment in a new series, experienced iOS developer Jeremy Alessi takes us through the prototyping, production, and launch of his new game friendly.fire -- and shares statistics on how its launch went. He'll be back to update Gamasutra readers on the game's performance every 30 days. ]

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 Crash for Cash) 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.