Atoms is an iPhone and iPad compatible turn based strategy game for for 1-4 players based on a game I played in the 1980s. It's a grid based board game similar in style to Reversi or Go. It was released it in November 2014 as a free, ad-supported download with one time in-app purchases to remove adverts and unlock all the game features.
This is a long one, so TL;DR:
- Call of Duty was built quicker
- Network multiplayer was a massive waste of time
- It released with critical bugs
- Cocos2D is nice, Xcode is not, Ads and IAPs are a pain
- Marketing is a mystery, if not actual witchcraft
- Publishers may or may not be evil (see above)
- It broke the UK top 100 downloads and has brought in less than £40
- I might rewrite it as a cross platform local multiplayer game
What Didn't Work
Atoms was developed over the course of, I think, about three years, which is a ridiculous length of time for such a simple game.
I had couple of false starts, once where I got sucked in to building a custom 2D game engine for it for a while before switching to Cocos2D, and once using straight procedural C instead of Objective-C (no, I don't know why either), and I didn't work on it at all in 2013 due to real life.
I made it more complicated than it really needed to be with some custom OpenGL rendering code (I'm so l33t) that, with hindsight, could probably have been implemented much more quickly in Cocos2D if slightly less efficiently. This code has now also shackled the game to Cocos2D 3.0 specifically and will eventually have to be rewritten if I'm ever to upgrade the core engine. There were other features too where I could likely have saved some time with no detriment to the final product.
By far the major development headache though was implementing network multiplayer. This was a core feature and one of the driving reasons for doing the remake in the first place; "Atoms is great as a party game, so make it network multiplayer!", went the reasoning. I had a local multiplayer version of the game working fairly well, but when it game to wiring in Game Centre turn based online mode it all fell apart. My code wasn't at all suited to this major refactoring and needed torn apart again. It would have been better to design for network multiplayer mode from the start, obviously, but this was my first go at this and I had no idea what I was doing.
When I got into it, I found the Game Centre API awkward to work with in that it's perfectly synchronously turn-based right up until it isn't and you have to throw out your code again and rewrite it again to cope with certain events coming in at any time during a match in a very non-synchronous - some might even say asynchronous - manner. The event data itself is also fairly useless as it doesn't tell you what's changed, just that something has happened, so you end up writing a ton of code to compare the received state with the current client state and take action appropriately. Knowing this now, I'd probably design the communication protocol differently if there ever was a next time, but I think there would still be cases where you'd need to compare state.
We don't talk about the stability of the Game Centre sandbox. You were there, man. You know.
To cap it off, practically no one has played Atoms in network multiplayer mode, so the whole Game Centre adventure was just a massive waste of time. I'm not sure why this is, but perhaps there's something in the immediacy of everyone shouting around the same device in a local multiplayer match that gets lost when you take it online and play it on the bus.
Another feature that I spent far too much time on was advertising. I'd decided to make the game free to download because it's inherently multiplayer and I thought it best that it got into the hands of as many players as possible. This meant making it ad-supported with IAPs to upgrade and remove the ads. I spent a whole month in 2014 trying mediation plugins for different networks, with varying degrees of success, and even the ones I settled on caused stability problems in the final release. IAPs were easier to add, but still required quite a lot of work to integrate with the user interface. Player analytics, another seeming "must-have" for a modern mobile game, is sort of in the same boat.
I found the advertising and IAP work soul destroying too; personally I detest ads in games and would much rather just charge (or pay) a couple of quid up front, but hey free is where the mobile business is at, right? I'll come back to this in another post, I think.
For marketing, I paid to have a press release written and distributed. It wasn't an eye-watering sum of money, but it was definitely eye-moistening. Looking back, I could have written the release copy myself and it's impossible to quantify, or indeed find, any benefits of having it "professionally" distributed. I don't feel like I got good value for money there. Perhaps the money would have been better spent on advertising? As it was, I had nothing spare for that.
I didn't do a whole lot of other marketing myself. I made a few posts on forums and social media (and thanks all for the shares), and got the game listed on a couple of preview sites, but really I didn't have time to find much in the way of press or enthusiast contacts. I was under no time pressure and could have held off releasing the game for another week or two to let me perhaps drum up some interest in those channels.
When I started working on Atoms, Game Centre and iOS were the obvious targets, but the world has changed in the intervening years. Unfortunately Atoms would be all but impossible to take cross platform in its current form. There's still a few bits of the C version in there actually, I guess I could reuse those but that would be the limit. Cross platform, as much as possible, will be the goal for any future games I make.
Atoms shipped with a couple of nasty bugs, one of which was a stupid off-by-one error that broke the IAP system and gave players some premium features for free. A good deal for them, but not so much for my business model! In my eagerness to get the game out the door, I'd disregarded advice about ironing out launch wrinkles like this by doing a staged release in the Canada or New Zealand stores before unleashing the game on the larger markets. A calmer head must prevail next time, because no one likes shipping critically bugged games.
What I'm Not Sure About
Close to the release date I was approached by a publisher interested in taking Atoms on, but in the end I turned the deal down. Mostly it was that the timing was wrong and I didn't have budget or mental energy to tackle the extra design and development work they were asking for, but there were other aspects where the heart won out over the head and I wasn't going to be mister super hard nosed business guy about it (I'm too nice for my own good sometimes, and I'm OK with that). The contract terms would have needed arguing out too but we didn't get to that. Finally, as this was my first real foray into iOS development, I kind of wanted to do it all myself just for the experience.
I'm still undecided about publisher or no. Maybe it would have been financially better to go with them, or maybe it would have been the same except I'd have half the profits and no control over my own game now and for the next five years. They do have knowledge, experience and influence and take care of a lot of crap (non development marketing work) though, so I'd definitely consider a publishing deal if one ever came up again.
What Did Work
Cocos2D is a great engine for 2D work on iOS. I found it very flexible and easy to use, and there's a large and active community built around it. Recently though, it's been moving more towards very tight integration with the SpriteBuilder tool. I'm not sure I like that. It's probably a moot point all the same as my future cross-platform intentions rule out using Cocos2D again.
Objective-C is a nice language to work in too. It has a much friendlier syntax than C++ with most of the performance, and with ARC enabled it's essentially garbage collected except faster. I wish it were more widely used.
Ditching Xcode for AppCode was a massive productivity boost. Sure, Xcode has features that are important for developing iOS apps, but these aren't generally required for games work which tends to be more code oriented. I find the Xcode code editor an unusable mess.
And, all other things be damned, the game is actually really fun to play!
Ah yes, the bit you've been waiting for. Hard numbers. Has Atoms bought me a solid gold Humvee?
To date, Atoms has been downloaded 956 times and has made a grand total of £48.39 revenue from adverts (£12.21) and in-app purchases (£36.18). While it's great (and it is) that nearly 1,000 people have played a little mobile game I made (and some of them have played it a lot), and properly amazing that it broke into the top 100 in a few categories in the UK on release week, I'll admit that it's mildly disappointing that more people didn't actually buy it.
I won't say it was never about the money because partly, obviously, it was. I never expected to get rich, but bringing in a few hundred or a thousand pounds didn't seem unrealistic. Maybe, if I'd charged £1.99 up front, or gone with a publisher, or had the right marketing...? Maybe I'm just a naive fool though.
I'm not sure. My current but ever changing thoughts are that, in exponentially decreasing likelihood, I'll rip the ads out of Atoms and lock down the free version to more of a shareware style demo, then remove the IAPs completely and make it a simple paid release, then think about rewriting it in Cocos2D-X (or something) as a cross-platform single player game, then think really really really hard about using that as a base to add a custom multiplayer backend that doesn't give me the same brainaches as Game Centre did.
That lot should keep me busy. I'd wager, though, that probably somewhere along the line I'll get sick of working on Atoms and thinking about Atoms and talking about Atoms and start on a new project that isn't Atoms. Atoms.
Atoms is available on the App Store now. Go on, nuke your friends!
[originally posted at: girv.net]