Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Building an iOS Hit: Phase 1
View All     RSS
March 1, 2021
arrowPress Releases
March 1, 2021
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Building an iOS Hit: Phase 1


February 1, 2012 Article Start Previous Page 3 of 3
 

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.


Article Start Previous Page 3 of 3

Related Jobs

Gameforge AG
Gameforge AG — Karlsruhe, Germany
[02.26.21]

Senior Game Designer
Gameforge AG
Gameforge AG — Karlsruhe, Germany
[02.26.21]

Lead* Game Design
Insomniac Games
Insomniac Games — Burbank, California, United States
[02.25.21]

Narrative System Designer
Sucker Punch Productions
Sucker Punch Productions — Bellevue, Washington, United States
[02.25.21]

Combat Designer





Loading Comments

loader image