Tech Dev Blog #9: Soft Launch Post-Mortem
We are mad. Completely and totally mad. If I’ve got one take-away from what we’ve done over the last few years and what we’re in the process of releasing now, that’d be it.
Let me explain…
This isn’t going to be a full post-mortem – that’ll come later. The game has only released on one platform and in one region, so we don’t have the full perspective on how it’s gone just yet. But what I can talk about a bit is the project itself, the insane push to get it out in time, and what I’ve learnt in the process.
Two years ago we began creating a game called TownCraft. The idea was to take a genre we love (city-builders), shake it up a bit, make it more personal, and aim it squarely at a platform I love gaming on – the iPad. We kept the code cross-platform and always planned around hitting iPhone, desktop and a bunch of other platforms as well… but the whole game idea came out of wanting a game like this for me to play on my iPad.
Well, we have that now. There’s niggling issues, some graphical quirks that I’m desperate to fix as soon as humanly possible, and a ton of work to be done for our iPhone, desktop and international releases, but the fact remains: the game I want to play, I can now play.
I’ve been in software development for about 8 years professionally, and for years before that as a hobby. So I’m rather used to the way in which the progress of projects ramps up from small amounts of work to the insane crunch time horror stories you hear about with big studios. And yet the scale on which it was true for TownCraft still blows my mind.
The last third of the code (in terms of lines) was built in the final three odd months – and the reason was that months before this we’d paid money and agreed to show our game at PAX Australia. It seemed like a fair idea – and it gave us a hard deadline and no choice but to hit it, as the submission we’d signed said that we had to have a game out by the time the actual expo rolled around.
By the end we knew we’d have to drop a few features in order to get the release out – no localisation, no iPhone version (yet) and a few other minor things were going to have to be pushed back to post-release patches. For this reason, we decided to make our PAX Australia launch a “soft” one – a limited release within the Australia/New Zealand regions only, just enough to qualify as a real release, but still give us time to learn from the relatively small market of our home country and ensure we weren’t making any serious mistakes before the international release (planned for some weeks from now).
Needless to say, this made the final chunk of beta testing and debugging absolutely frantic. It probably wouldn’t have been possible at all if it wasn’t for a local AAA studio going under suddenly and a few of the ultra-talented, industry-experienced friends of ours suddenly finding themselves with the time to help us haul TownCraft across the finish line.
Because, did I mention… this is our first game?
So, here comes my big list of completely un-shocking learnings from the final few months. I’m noting these now for my own benefit more than anything else, and quite frankly I don’t expect a single thing in here to surprise anyone who’s shipped a single game, application or product at all – or even come close. But here goes…
1) Lock down the structure of your code early.
No matter how simple the change seems, if it involves moving functions, classes or anything – especially if it uses callbacks or any fancy memory stuff… don’t do it. Even if it means some work-arounds or hacks left in the code, just mark them as FIXME with as much description as you can stomach… because you do NOT want to spend your last few weeks of beta testing figuring out why a null pointer exception magically appeared where once something was stable as a rock.
2) Prioritise your bug-list as granularly as you can manage.
Mercifully, this is something we DID do right – and doing it did remind me of how important this is. As we got closer and closer to the “point of no return – SUBMIT BUILD TO APPLE NOW!” point I was able to answer bug reports or questions by beta testers really simply – that if it wasn’t categorised as causing crashes or seriously interfering with gameplay in some way, it was going on the medium/low/cosmetic post-release bug list.
It did mean that, despite some memory leaks still existing in the 1.0 release, and a number of other cosmetic and low-priority bugs, we’ve generally had a stable game, with only one or two crashes being found by players since release – not bad for a game whose engine is built in-house, entirely in C++, desperately rushed out the door in the final months, with the majority of the work over the two years being done by one or two people – neither of them full-time.
3) Sanity-check the existence and validity of your game assets, automatically if you can.
TownCraft clocks in at about 135mb, and most of those are small textures and XML files. As we got towards the end, we found ourselves replacing more and more textures as the artists were in crunch time just as much as we were.
One of the best things I ever did was, after one or two beta builds magically developing crashes, have our game loader check every asset at load-time. Even if it wasn’t going to pre-cache the texture, it at least ensured the thing existed. This meant less time was spent dealing with magical crashes due to a missing or incorrectly named replacement UI element, sprite or sound.
4) Create a release-build checklist.
Doesn’t matter if it only contains two items – just do it. Our 1.0 release went fine, but during the bleary tiredness of submitting our 1.0.1 patch on the busy, tiring weekend of the PAX Australia exhibition (and our launch day) I made a stupid mistake – and forgot to hash out the ‘TESTMODE’ #define… so for the next week our customers will see cheat/debug options at the menu which is worse than no use to them – it could stuff up their games if they start mashing them.
Now I have a checklist, this, no matter how tired I am, is unlikely to re-occur.
And now for an adjunct to that…
4a) Don’t release builds while over-tired.
No matter how urgent a release seems, it can wait until you’ve had a good night’s sleep, let your team-members vet what you’re doing and make sure you’re not about to do something painfully embarrassing.
5) Check your paperwork, and note down any you put off.
We very nearly missed our release deadline for PAX Australia, and the reason wasn’t code, debugging or catastrophic crashes turning up at the last minute.
The reason was that we completely and totally forgot to register for GST (a requirement for Australian companies about to sell products on the iOS App Store) until we were about to tap the big red button to go live.
Fortunately, the process was automated and so only delayed our release by a few hours, but it could just as easily have been something which took a week to sort out, meaning no release at PAX as we’d been planning for six months.
6) Be honest with your customers.
So far, we’ve replied to every email from each customer who’s sent one, and we plan to continue this as long as it remains possible to do so. We’ve attempted to respond to every criticism carefully and honestly, being thankful (because we are) for their feedback and being sure to let them know this.
If they found a bug, we’ve confirmed it, and let them know how high it was on a priority list.
Fortunately, so far this has worked for us, and despite teething issues, reviews (both published and person ones to us by email) have been touchingly positive.
When we made our mistake with the 1.0.2 release, we blogged about it as soon as we realised. We’ve gone out of our way to inform anyone who’s contacted us about it, so they can avoid it impairing their experience with our game.
In general, I’m pleased with how our soft launch in Australia has gone. It’s by no means over yet, as reviews have just started, but we’re getting there. It’s given us more confidence in our product, as we ready ourselves for the international release. While I’m sure that, like every game with even a modicum of complexity, we will encounter issues once a larger number of people get their hands on our game, this soft launch has given us first-hand experience of dealing with releases, bugs and, most importantly, reactions from customers.
And now: on to the rest of the world!