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