Banana Breakers: Indie Dev Learnings

Before trying a more ambitious game on mobile, I wanted to do a series of smaller experiments to learn a little more about the app submission / marketing process. I’ve got a few apps out already, but those were mostly hobby-fun-tinkering projects and not built with *serious face* revenue in mind. Experiment is probably the wrong word, since good little children who paid attention in science class know that a good experiment is designed to test a specific hypothesis, whereas with these first few games I’m mostly taking stabs in the dark to see what I can learn. What I’m hoping to learn, though:

• What tech should I build my games with?
• What platforms should I support?
• How can I get some exposure without spending too much?
• Which third-party ad/analytics providers should I use?

My first game, Banana Breakers, has been pretty helpful so far.

1. What Tech Should I Build My Games With?

I’ve been working on Banana Breakers (link to game site) on and off for probably four years, but in terms of actual complexity it’s a really simple game. I originally prototyped it in Flash a few years back (just the core mechanic of 4/5/6 words hidden in a grid), but it was Too Damn Hard. It was such an easy prototype, though, that any time some shiny new technology came out I would re-implement it to test out that tech. I have a Haxe version. I built an Enyo (javascript) version a few years back when I got a Touch Pad. I built a native iOS version using RubyMotion when that came out last year. When my friends at Spaceport.io needed beta testers, I re-built it once again in Flash–but this time thinking of it as a mobile app. Eventually I ran into technical problems with Spaceport (they didn’t have 3rd-party code support yet), so I switched over to Adobe Air. When I heard about Futile (a 2d plug-in for Unity) and Loom, I almost built new versions… I may have a problem.

Banana Breakers was also a departure from my earlier games in that it would be free, but with ads and the ability to buy more coins. I also wanted to support incentivized video as a way to get more coins without paying, as those always converted fairly well back in my Facebook days. Finding a tech that supports all of those (well) turned out to be more challenging than I thought.

Adobe Air and Unity both support native extensions, but Air’s implementation is god awful. I lost an entire week just trying to get the “Hello World” of native extensions to compile with my setup before saying “screw it” and just going with off-the-shelf ANEs (some of which I had to buy). Because I needed so much 3rd-party support, I crossed Unity off my list pretty early in the development process. They have even fewer native extensions than Adobe Air, and at the time they were still charging for the iOS and Android plugins. Even now, the free indie license requires you to use a Unity splash screen and doesn’t come with access to native extensions. I could probably get over the splash screen, but the lack of extensions would probably limit Unity to only paid-download games for me.

So what tech did I end up going with? For Android and Kindle Fire, I used Adobe AIR (since I already had an AS3 version ready to go). I could have re-written using Starling to get better performance, but at that point I was ready to release something and get some data. I wasn’t happy with the performance of AIR on iOS, so I converted everything to bitmaps and build a native iOS version using RubyMotion. I’ll do another post later about how I’m using RM to build games, but for now my tech stack is pretty much RubyMotion and Photoshop (with some custom scripts to help speed up UI development). And it’s a lot of fun. I don’t know if it’s the right choice (iOS only), but so far I’m really happy with it.

2. What Platforms Should I Target?

There’s two ways to think about this:

1) Supporting multiple platforms is expensive and only worth it for a successful game.
2) It’s easier to be a big fish in a small pond–targeting less successful platforms might be a way to get traction/cheaper users/less competition.

My original thought was pretty much #2, assuming I could settle on a tech that was cross platform. In practice, Banana Breakers has pretty much made me change course entirely back to #1. Even though I originally built the game to be cross-platform, the amount of work needed to set up in-app-purchases, ads, and other native “touches” turned out to be pretty nontrivial (especially when you throw in device testing). At least for me, building a game cross-platform means it will take probably twice as long to build… and at this point I’d rather make more games.

I’ve also been disappointed with download numbers on both Kindle and Android. For Kindle, it seems as though free games don’t even appear in the “new games” section of the app store. That makes sense in hindsight (their marketing engine is designed entirely around promoting things that cost money), but it was still a bit of a shock. Android was slightly better (3-4 downloads a day), but nowhere near the 500-1000 downloads I got while on the “new games” sections of iTunes. Having a game out on multiple platforms would also mean (theoretically) that my marketing efforts would need to be split between the platforms. Realistically, though, I’ve been focusing all my efforts on the iOS version and completely ignoring the Android versions.

If I have a game that is a monster success, I’ll consider looking at other platforms. For now, though, the decision to go iOS-only for future games is an easy one. If anything, I’d consider doing desktop-PC on top of iOS before I would consider doing android or kindle. If I were to do a native version for any other platform (Windows Phone 8 is tempting, since I’m one of the few users), I would just do a native build for each platform.

3. How Can I Get Some Exposure Without Spending Too Much?

Distribution is probably the single biggest hurdle to making a living as an indie developer right now. I’m nowhere near figuring out, but I can run through what I’ve tried so far:

1) Release the game. Free. I got ~500 downloads just for releasing the game on iOS.

2) Review site blitz. Free (ish). ??? downloads. I sent out ( slash-filled-out-contact forms) somewhere in the neighborhood of 150 emails to various mobile review sites. The vast majority of them did not respond, and those that did were offering paid reviews. I got a nice write-up from JayIsGames (they’ve written up some of my flash games in the past as well), but nothing else. So far this seems like a giant waste of time, though I’m sure bigger sites do create a nice download bump. I think it’s worth to build relationships with sites that aren’t too scuzzy, but at this point I think efforts spent on this type of PR would be better spent doing blog posts and engaging on twitter / forums.

3) Gnome Escape. $250, ~200 downloads? I’ve read a lot about how shady pay-for-review sites. Gnome Escape was on one of the giant lists of publishers to contact for reviews, though, so I gave them a look. They say all the right words–authentic reviews, etc… but ultimately it’s just incentivized installs (with incentivized reviews on top of the incentivized install). I got a nice bump of 50-60 people a day for a few days (along with several who monetized) and some good reviews, but most of the reviews were spam-bot level in quality (just regurgitating my app description). My thinking was that 200-250 users for $250 is about $1 a user and not too bad… They delivered what they offered, but I don’t think I would use the service again.

4) AppFlood. $250 each, cancelled. Just to get a sense for how they worked, I dropped $250 into my AppFlood account and set about driving some paid installs. To get any sort of volume in the US, I would’ve had to up my bid to the $3-$4 range, and there’s absolutely no way Banana Breakers could recoup that. I want to try ChartBoost later (they have a lot more volume), but so far these seem pretty overpriced.

5) Free App Magic. $1000, ~8000 installs. The last thing I wanted to try was some way to get burst downloads (and hopefully make it onto the charts). There are tons of free-app-a-day apps that promote an app or two a day, but most of the big US ones cost thousands for a feature. I set out to find a slightly smaller one with a more reasonable intro rate, and FAM definitely fit the bill. The intro rate I got is probably not repeatable (I took the place of a game that cancelled at the last minute), but the results were great. They estimated that they drove ~4k installs, while the other 4k were organics from hitting the top ten in word games in the UK (most of their traffic is UK). The game stayed on the charts for a few days, but is now slowly dropping out. The 25-30 installs per day I’m getting now (a week+ after the promotion) is slightly better than the 5-10 I was getting before the promotion, but I’m not sure how permanent that will be. I consider this to be the only successful bit of marketing I’ve done (twelve and a half cents-per-user would be a phenomenal rate for a better-performing game, and if I could get similar CPIs at other daily download sites they’d be worth the higher fees).

(UPDATE) 6) My Chartboost campaign was finally approved and I was able to run $250 through it very quickly, even at bids of $0.50 for US installs. I’m not sure how many installs are available at this price (I would guess that as you start trying to drive more volume the price would have to go up), but as an initial test Chartboost is another promising way to get users at a good price.

My original goal was to only spend $1k on marketing Banana Breakers, so at this point I’m $300-$400 over. It doesn’t perform well enough to keep spending, but hopefully I can take some of that knowledge on to better-performing games.

4. Which third-party ad/analytics providers should I use?

This has probably been the biggest shock with releasing a game. At Crowdstar we had an entire dedicated Business Intelligence department, a massive Vertica database to warehouse game event data, and dedicated analysts to help sift through the data. I’d always heard good things about Flurry’s event tracking, but from my point of view the data is sorely lacking. The install, retention, and session charts are pretty good… but there’s no easy way to hook it up to purchase data. And it’s not realtime. The data they provide seem like an okay way to track your installs and active users, but I don’t see how anyone could take specific in-game actions based on this granularity of data. I wanted to go entirely server-free for Banana Breakers (mostly because I’m cheap, and nothing wipes out meager indie game profits like server fees), but for future games I’m thinking I’ll roll my own. Helios (by the Heroku guys) looks strong, but doesn’t do exaaactly what I want. I’m leaning towards a super-simple redis-backed logging system with built in a/b testing, but it’s also tempting to abstract a little more and see if I can come up with a generic service for the things I want to do.

Ads have been a little better. Banana Breakers has interstitials (AppFlood & ChartBoost), banners (Flurry and AdMob), and incentivized videos (HyprMX and AdColony). So far ChartBoost is the clear winner–interstitials are blowing all the other formats out of the water. Banners are probably not worth having in the game. While their annoyance might drive players to upgrade, the game would have to be a total smash hit for the ad banners to pay for the extra time it took to make home screen layouts that support banners. I’ve been really surprised at how poorly the incentivized videos have done. I’m guessing that means either (a) most users don’t know they’re there or (b) the word puzzles aren’t hard enough to warrant users needing extra coins (which would also lead to low coin sales). Once I throw in in-app-purchases, the graph looks more like this:

So ads are actually outperforming coin sales by about 3:1. The numbers here aren’t huge (~$51 so far for coin sales, ~$136 for ads), but I think the trends are still pretty useful. If I’d had a back-end server set up, I would be able to tweak what portion of each type of ads go to each provider (home brew mediation). I’ll hopefully get that set up for future games.

Overall the budget for Banana Breakers was about $2600 + dev time, so it’s unlikely at that point I’ll make back the development costs, but it’s been a fun game to work on.