Wednesday, June 17, 2009

Lessons learned from Castle Conflict - marketing and design

Castle Conflict is not doing poorly. It is not making me Flight Control levels of money, but it certainly is not leaving me penniless either. I think the app has been alive long enough, and I've heard enough from the users, that I can begin to draw some conclusions.

First off, Castle Conflicts marketing campaign has not done a lot for the game. It has been reviewed on many websites, appeared on many websites, been cracked on many sites, even received a couple of youtube videos. They haven't been without value - I've recieved small boosts from such websites. For example, around the time of the apps first review, the app was getting about 15 sales a day, but the following day, it had 27. At that point, it was easy to measure that the review had given the app a boost of about 10 sales a day. It was not a particularly great review, but it still helped a bit. I cannot measure if we would have got more sales if we were better reviewed, but it seems likely to me.

Unfortunately, the first release was full of design problems, which I will get to shortly, and we did not get a lot of great reviews off the bat.

Another avenue of advertising that did next to nothing was facebook ads. We got plenty of impressions (49K in a single day), but very few turn to clicks (11), which is to be expected. However, those 11 clicks were made on a day when the game had only 17 sales, so the chances that each click became a purchase is highly unlucky. Cutting the facebook ad dropped sales to 14, and the game had been on a downward trend at that point, so it can't even be said with certainty that cutting the facebook ad had anything to do with that.

Luckily for us, about a week and a half after our game went live, we received one of those dreamt of e-mails from apple. It was so exciting that I didn't even believe it at first. "To Broken Kings, we at apple really love your game and want to promote it..." That doesn't happen to just anyone, and we quickly provided the assets requested. Our sales jumped from 11 on a Monday to 1.2K on the Tuesday. They dropped to about 880 a day and settled there for a week (until the app dropped a page in the 'New and Noteworthy' and 'What We're Playing' pages). We put it on sale and it managed to hover at about 700 sales on page two, and on page three it's getting between 2 and 3 hundred sales a day.

The app has been reviewed on many sites since that time but it's a little less clear how much of an effect those have had. The sales data has not changed overly much since apple started promoting us, other than when it moves down a page, so it's clear the reviews have yet to do anything stunning for us. On that note, we haven't taken advantage of any paid advertising opportunities other than facebook, so hopefully in the next blog entry we will have something to say about that.

In short:
Facebook ads - not effective
Having your game reviewed on an app website - Remotely effective (perhaps more on a good review)
Getting featured by Apple - Highly effective, highly recommended


We made two mistakes, one when developing Castle Conflict, and then one after when we sold Castle Conflict. They were:

1) Releasing the game with a single level, and
2) Charging $1.99

Releaseing the game with a single level
The first mistake was a design mistake - we released the game with only a single level. This is not a mistake immmediately, but you have to know that your game is a single level game before you release it as a single level game. I was looking at Flight Control when I made the decision that a single level would be enough for Castle Conflict, but I failed to notice two key differences:
1) In flight control, you are driven to keep playing because you get a new high score at the end. The game always goes until you lose, but you will usually think, "Oh, I could have done better!". As such, it inherently drives players to play again.
2) In flight control, the only person you have to beat is yourself. In that sense, it does not rely on an ai remaining interesting, as Castle Conflict does.

As I've mentioned before, this game was inspired by and largely based off of Medieval Clash. Medieval Clash was a free gamemaker game that I played in my youth when I was still fiddling around with gamemaker in my free time. Like this game, it had only one level, with the challenge being adjusted based on the users settings (difficulty, how fast the trees grow, etc). We mimicked that, because it had worked so well (for us) when playing Medieval Clash.

To push players along, however, we checked how well they did and, if it was rather well, we would suggest to the player, "Why not advance to the next difficulty?". In an update we released (that just went live yesterday after 18 days in the queue), we made this pop up no matter how well the player did, as long as they won. Otherwise, players wouldn't know why to play again. What would be different? My statistics from Pinch have revealed that not everyone visits the settings page, so many people play the game a couple times on easy, and if they are not good at it, they won't see the point in continuing.

Players NEED motivation. There are several things that can motivate a player: growth, advancement, beating a score are notable ones that I have uncovered. Castle Conflict did none of those things. Each game starts on a clean slate, so there is no growth. The game does not score you. It may advance you, but only if you do well. Without this, the player will be lost in the game after playing it once. We had assumed - wrongfully - that the player would want to play again because of the gameplay alone. That was what had driven us to play Medieval Clash again and again in the first place, why shouldn't it work on our end users? We were, of course, a lot more passionate about the game (enough so to make a game based off of it) then we could fairly expect an average user to be.

There was one other difference between our app and Medieval Clash, however. The settings for Medieval Clash were on the title page, whereas our settings are hidden away on a settings page. This was essential because the iPhone screen has less space than a computer screen, but it makes the customisability aspect of the game less obvious.

Charging $1.99
We thought (and still think) that Castle Conflict was a fun game. We thought that players would most definitely get their moneys worth from it. And we had worked hard - skipping sleep, working around other responsibilities, taking no leisure time (other than one afternoon when we were far ahead) to get it out there. We figured, if we weren't getting a dollar a sale, it hadn't been worth it. So we priced the app at $1.99, so that after Apples cut of 30%, we'd still have $1.39.

This was pride, and it led us to make a bad decision. Our game may be worth $1.99 on an online game website, it may even be worth more, but on the iPhone, games that provide hours of entertainment often sell for $0.99. As such, any game that costs more must have an obvious reason for costing more. If not, players will get upset that they are paying more and not getting more - and we received several reviews, both in itunes and out of, saying that the app would be great if it had cost $0.99, but wasn't worth it for $1.99. A lesson for any developer hoping to take something from our experience is - unless your game has some really obvious boost above other games (being 3D, being more like a console game experience, etc.), it's probably better to just charge $0.99, and prevent anyone from complaining about the price (as this will hurt your sales).

We noticed this, but even after apple promoted us, we didn't change our price. Our app hit #48 by the Friday after we were promoted it, and if we had put it on sale that weekend, we may have cracked the top 25 with all the additional sales we could have gotten at half the price. But we didn't, until the app started sliding off the charts. when it was in position #98, in a panic to prevent it from falling off the top 50, we put it on sale at $0.99, and it pushed the app back up to #80 - but we missed the opportunity to really have the app go far. Of course, we could not have known how much of a hit our sales would take when apple moved our app down a page in the featured apps, but it still hurts to think about where we could have been.

I was going to talk a little bit more about some design things I think have worked that other games have done, but I think I shall leave that as a future blog entry.

Final Note: We got another youtube review, and it was quite nice:

Wednesday, June 10, 2009

Population Control Teaser

Population Control is an interesting project. I actually started it while still in college, as my final project for my artificial intelligence class. It quickly became my favorite project from college, and during the day where we introduce ourselves to industry, I had it running on my computer the entire time to show off.

I always had fun tinkering with it, and most people I've shown it to think that it is actually a game that could make money. Of course, people I know are biased in my favour, so that doesn't make them right - but I loved the game idea enough, and had enough fun playing it, so I decided to give it a shot.

This project has become a joint collaboration with Robots and Pencils, a small company run by the same guy I helped teach iPhone Dev School with recently, Michael Sikorsky, as well as his wife, Camille, who is doing the art.

This is what the game looked like originally, when I programmed it in college, complete with programmer art. You may even recognise the sheep from this game as being what I selected as my avatar on blogspot. While the game may have been solid, it definitely lacked the art necessary to crack it in todays market. Luckily, Camille seems to be a genius at making animals cute, and what we currently have looks something like the screenshots below:

We are hoping to have the game at a state where we can begin a distributor hunt very soon. Hopefully in that time, I will have a chance to discuss some of the behind the scenes details of the game in this blog.

Friday, June 5, 2009

Pinch Media Update

I have previously discussed Pinch Media and piracy, and I would like to take a moment to commend Pinch Media for a move they made recently.

Now, Pinch Media actually allows you to filter your data by how many users are real users, and how many users are pirates. I don't know yet how accurate this data is but the numbers that they have so far line up with what I have been finding on my own.

Their system is not entirely without limitations, however - for example, you cannot compare how many pirates have performed each action vs. how many paid users have. It is not yet a perfect system, but it is definitely a nice system.

This, of course, comes as Castle Conflicts first update should be coming near to propagating to the app store. In the update, I had included code that detected if a cracked version of Castle Conflict was run and - if so - actually supplied a SEPARATE application id, so that I could compare stats. I will probably be taking this code out with my following update, unless I find the observations in behaviour in-game of pirates vs. non-pirates striking.

However, Pinch Media does reveal a few interesting pieces of data with this new update:

1) Of Castle Conflicts users, currently about 47% (6510) are pirated - meaning that we just recently cracked the halfway mark of paid vs nonpaid.

2) However, only 35% of all game sessions were by pirates - non-pirated users play the game roughly twice as much as pirated users do! (My states corroborate an increase in usage by paid users - before we started receiving more sales, when we had many pirates, our usage stats indicated that users were running the app approximately 3.12 sessions each. However, that number has since gone up to roughly 4.61 sessions per user (63,831 sessions over 13, 847 total users)

3) Users spend more time playing when they didn't pirate the app - there is not a hugely significant number, and it is hard to judge overall as these numbers fluctuate from day to day, but on a normal day, a paid user runs the app approximately 17+ minutes (with the longest average session to date being 33 minutes), but a cracked user on averate runs it 15 minutes (with the longest average session to date being 24 minutes).

Thursday, June 4, 2009

Windows on Mac - A Mixed Bag

I do most of my work on a 13" macbook.

It's not a high end mac; it's actually quite close to being the bottom of the spectrum of this years models. But its specs matched the Windows machine I was working on at the time, and the reason I was buying it was for iPhone Development. A friend of mine had recently built an iPhone app on lesser specs, so I figured that the cheap bet was the safe way to go for doing indie development.

Shortly after I got my Mac, I used BootCamp to install windows on it. I was surprised by how wonderfully Windows ran on the mac. The aforementioned Windows machine was literally a piece of junk ... typing into firefox's URL bar often resulted in a bit of lag before the text appeared. This was partially due to the machine being used for over a year without a lot of cleanup, but it was still painful to use as a development machine.

On the mac book, when I clicked 'My Computer', a window popped up named 'My Computer' in less than a tenth of a second, as opposed to the Dell, where it usually takes 3-4 seconds. It was, quite honestly, for a geek like me - a breathtaking experience. I was running Windows...and it worked. WELL.

Even Visual Studio loads in under five seconds, where on the Dell it could take upwards of two minutes, without any project being loaded on it.

(This is, of course, the spoiled part of our age - that two minutes can seem like a long time to wait for something to happen).

There are two downsides to the Mac I've since uncovered though. One is that any game I am developing runs at choppy frame rates that I can't reproduce in other places (the games get roughly 60 fps on the Dell). I don't know if this is a graphics card problem, or a driver problem, or a 'your code is inconsistent' problem, but it does make working on games a little more problematic.

The other problem is that for the past week, with little to no warning, Windows has occasionally BlueScreened because of a driver failure, then shut itself down. When this happens, it will usually happen again shortly after starting up again.

Windows did recently update, and it hasn't happened since, so I am hoping that perhaps the update fixed it ... but we shall see.

So; Windows on a Mac: Mixed Bag. Windows runs way better than it has on any machine I've used recently (including a clean install of Vista on an HP TouchSmart), and I am still spending more time being productive, even with the Blue Screens. But the slowdown when running games is a bit of a pain.