Ok folks, let me bring you up to speed. I run a mobile game development company called Supergonk. I make quiz games on various topics - things like “guess the capital city” or “how well do you know the Bible?”.

My first game, Capitals Quizzer, initially launched on iPhone only, and was slow to start. I continued to improve it by adding iPad support, more game modes, improved graphics and sound, etc. Despite the game being free-to-play, it struggled to achieve many downloads until one important update: localisation. As soon as the game was available in non-English languages, it skyrocketed. The game reached #1 in free apps in several territories, including Germany, France and Spain. 

Since those humble beginnings Capitals has continued to receive many updates. It’s now available in nine languages, has thirty-four game modes, and is quite a nice package now. Over 14 million game sessions have been played, with many millions of unique users downloading the game. Capitals has been rewritten several times, and it’s technology has gone on to spawn five other quiz games.

These games all share a common code base, and are now available not only on iOS but on a variety of Android stores too. I also recently launched a version for the new Blackberry Z10, with Q10 support arriving soon as well. Oh and the Mac OSX version is almost ready to go now. I’m currently juggling 36 different SKUs; in other words when a new version is ready to be released I need to re-build and package the games 36 times and upload it to all the different web portals.

Doing all of this is a LOT of effort. I’ve spent about a year and a half getting the games onto all these platforms; it’s a serious endeavour. The real cost of multi platform development isn’t just getting the thing running in the first place, but also all the ongoing maintenance. The platform holders all do billing in different ways, and require a lot of hoops to be jumped through before they become viable for business. Sorting out the financial side of things isn’t trivial - it’s a big job. There’s also silly things, like screenshots. Each platform/web portal requires their own screenshots in their own resolutions, in all the languages they support. For all my games on all platforms we’re looking at almost 1,000 screenshots to maintain. It’s mental.

HOWEVER, the burning question is: was it all worth it from a financial perspective? Was it worth spending months and months building support for all these other phones, when I could have just made more games for iOS? Let’s find out…

——-

Part 1: Creation

iOS: this was the first platform I built for, and the easiest to work with. All the tools are very well made, everything makes sense, and there’s lots of support if you need it. There are also a lot of third party libraries to do things like analytics, advertising and other monetisation. Easily the best platform to work with, by some margin.

Android: Quite a pain to write for if I’m honest. There are lots of annoying language quirks (like having to support both C++ and Java, and bridge communications between them), lots of hardware issues (like infinite numbers of screen resolutions, file size limits, varying memory limits, etc.) and the pain of multiple marketplaces. I decided to support only three: Google Play, Amazon App Store and Samsung Apps. Each store requires it’s own unique version, with unique integration code and permissions. Here’s the mini breakdown of each store:

• Google Play: They have a pretty terrible code and web portal, although it does seem to be gradually improving. There are lots of mad “gotchas” to watch out for; for example Google rolled out a massively complex and error prone IAP (in-app purchase) system for version 2, only to ditch the entire thing and basically start again for version 3 a few months later. That wouldn’t be so bad, but the two versions have different feature sets, so you need to support both if you want to cover all bases. Arghhh! Even with all this stuff integrated properly, about 1/3 of the time the user’s purchase will just fail for no apparent reason. That’s potentially a third of your revenue down the toilet. Double arghhh!!!

• Amazon App Store: The best of the Android stores. I would say that it even rivals the iOS setup. Their code is simple and works well, and integration was a breeze. They are currently in the business of matching Apple feature-for-feature, which is great. Amazon is the developer’s friend on Android for sure. 

• Samsung Apps: Their code is fine and integrates well, and their web portal is fine once you get past the initial confusion. I would say this is an easier store to support than Google Play, but not as nice as Amazon. One highlight is that they send you videos of your app should you fail submission for any reason. That’s a really nice touch and extremely helpful in diagnosing any issues. 

BlackBerry 10: A really nice platform, and great to work with. The company is also great at interacting with devs. I had a few issues getting the tools up and running and also getting my first batch of apps approved, but this was pre-launch and to be expected with early software. Overall, BB10 was great to work with. 

Mac App Store: I haven’t actually launched on OSX yet so can’t talk to the submission process, but integration was an absolute cinch if you’ve already got an iOS build. For my IAP and GameCenter integration I changed two (just two) lines of code between iOS and Mac App Store. It really is that trivial. Awesome stuff. 

——-

Part 2: Performance

In my mind there’s only two metrics worth considering here: downloads and revenue. For the following data I’ve combined all six of my games into one total. First up, downloads. This is the number of downloads (as reported by the app stores, not active installs) for each platform in the last month (from 7th April 2013->7th May 2013).

• iOS: 66,103
• Google Play: 18,623
• Amazon App Store: 2,292
• Samsung Apps: 2,919
• BlackBerry 10: 872

I’m seeing almost three times as many downloads on iOS than all the Android platforms combined. Whilst this isn’t strictly a fair test (the games have been available for longer on iOS and had a longer period to establish themselves), it’s still pretty conclusive. A lot more people are playing my games on iOS than Android. Unfortunately, BlackBerry 10 barely even registers.

Now onto revenue. I’ve combined all types of income (direct purchases and all forms of advertising) and normalised it to $100. The real numbers are much larger than this, but doing this normalisation gives a good way to compare the app stores.

• iOS: $100.00
• Google Play: $7.30
• Amazon App Store: $1.39
• Samsung Apps: $0.99
• BlackBerry 10: $0.00

So for every 100 bucks made on iOS, I’m seeing less than ten dollars from all Android marketplaces combined. To put that another way, I’m making ten times as much money on iOS as on Android. Considering there are only 3 times as many users on iOS I think it’s fair to conclude that Apple are a lot better at getting people to buy stuff on their platform.

As for BlackBerry 10, I haven’t made a single cent on that platform yet. Not one person of the 872 who have played have decided to spend any money, and advertising is a no-go on the platform as no mediators currently provide an easy-to-integrate SDK. Ouch. :-(

——-

Part 3: Conclusion

To answer the question of “was it worth going multi platform?” is a difficult one. The answer will be different for every developer. For me it’s been a great learning experience; I’ve enjoyed improving my programming skills and learning how to build a really complex set of systems from the ground up. It’s given me a great deal of knowledge in an area where I didn’t previously have it.

I’ve also gained an appreciation for just how long it takes to do what many indie devs call “the little things”, like managing business relationships and taking screenshots. I think I’ve about reached the limit of what one person can manage successfully on their own - in order to grow the business any further would require more full-time hands, and that’s a whole other decision to make.

In terms of profitability, no. It hasn’t been worth it. So far Android has failed to live up to it’s promises of being a viable platform to grow a business on. It simply doesn’t make enough money to justify the time it takes to support the platform, at least for a small developer like Supergonk. BlackBerry 10 is non-existent in terms of creating revenue, although it’s still brand-new so we can cut it a little slack. Will it grow in the future? Well they’ll have to do something pretty major in my opinion…

Anyway, if we’re talking in pure business terms then I almost certainly would have been better off concentrating on iOS and iOS alone. I’m lucky that my iOS revenue has been able to “carry” the other platforms, but many devs don’t have that luxury.

So for me it’s been fun. I’m a much better developer now than when I started this whole multi-platform experiment. Should YOU take your games onto every mobile platform under the sun? Well, that’ll depend entirely on what you want to get from it I suppose. Just don’t hope for endless riches… that certainly hasn’t been my experience.

——-

Part 4: The Future

This single month snapshot doesn’t tell the entire story. Generally Android is growing, whilst iOS has (for me) reached a peak. The momentum is certainly with Android at this stage - I think it’s still got a lot of growth in it. Here’s a graph of the last six months of downloads on Android:

Notice the green trend line - it’s definitely going up. Hopefully it’ll continue to climb over the next few months. That said, it might just be because the apps are relatively new on the platform and it’s just establishing itself. Perhaps it’ll flatten out from this point onwards. Who can tell?

Now let’s compare it to the same graph for iOS:

That said, my iOS downloads have looked like that for years now - it’s very stable. It tends to always track downwards ever so slightly, and then spike back up again when something big happens (like a new version getting released, or the game getting featured). Still, iOS would have to drop majorly, in a way I’ve never seen before, to be comparable to Android revenue. Personally I don’t think that’s going to happen. In my experience iOS is still the cash cow and I see no reason for that to change in the near future.

Will these trends continue? It’s really hard to say. Perhaps I’ll do another update in another 6 months and we can see…

Thanks for reading! If you want to give my games a try, visit supergonk.co.uk.

A little while ago I wrote a document outlining a cool idea for a new racing game. At the time I was thinking of where the PGR franchise might go next, given that the original developers (and my previous employer) Bizarre Creations was now defunct. My thought was that it would be interesting to go into the near future, taking the same kind of street racing but making it a bit more interesting with the addition of high technology.

I dug this document after seeing the adjustable airbrake things on the new Pagani Huayra. These flaps could be seen as the forerunner to technology I thought would be cool to use in this game (check out the Ferrari FZ65 in the doc below).

Have a look at the document and let me know what you think. Cool or crap? Personally I’d love to play this game, but then I would ‘cos I wrote it. Apologies it’s a bit text heavy, but there are some terrible sketches at the bottom. :-)

Near-Future Racing Outline

Premise

Thirty years from now, racing will have radically reinvented itself. Organised race sport has moved into the cities, providing the spectacle of Monaco every single weekend. Strict rules have been relaxed to provide maximum thrill for the huge crowds. Super secretive car manufacturers unveil their latest concept cars on the starting grid, and their drivers are some of the biggest celebrities on the planet.

You are a rookie driver on the city racing circuit. Join a team (Ferrari, Lotus, BMW) and drive their latest and greatest concept cars to victory. Tour the world of the future and race through both familiar cityscapes as well as newly developed districts. Drive your advanced vehicles to their limits, and become the greatest driver in the world.

Timeline

• The present: Formula 1 is increasingly moving to cities, and is proving more popular than bespoke circuits.
• 5 years from now: Most of the F1 season takes place in city circuits
• 10 years from now: Radical rule changes lead to more street-based cars, with varied specs and capabilities. The era of all cars looking the same is over.
• 15 years from now: New racing leagues break away from F1, creating business rivalries and a change of attitude: entertainment is king.
• 30 years from now: The sport is almost unrecognisable from today, with various high-powered street cars racing around closed-off city circuits.

Gameplay

This game sits firmly between arcade and simulation. It has a detailed handling model and relatively realistic physics, but is set in a world of near-future fantasy. It can be summarised as “street racing in the year 2040”. All of the racing is grounded in reality (no rocket cars, no driving up walls, no powerups), and the game should catapult the player into a believable near-future world.

Tracks

Location examples: London, New York, Shanghai, Delhi, Moscow, Los Angeles, Honolulu, Dubai, Johannesburg, Sydney, Seoul, Monaco, Tokyo.

The world’s most glamorous cities (and the best up-and-comings), all expanded and enhanced with the projected advances in architecture and technology over the next 30 years.

YES: next-generation skyscrapers; steel & glass, unusual shapes and designs, incredibly tall. Next generation roadways, realistically integrated into the existing street systems. New bridges and tunnels added. New high-capacity highways, possibly stacked on top of existing roads. Huge new elevated flyovers, drive-through “lobbies” of the largest commercial buildings and hotels. Extensive integration of new public transport systems (used to provide visual wow moments - trains flying past, passenger VTOLs overhead). Tracks are dressed with next-gen racification such as lasers, projections, very large banners, and video walls.

NO: loop-the-loops, corkscrews, or other unrealistic track configurations. Also no to spaceports or nuclear missile silos or any other unbelievable city construct.

Ideas for London Circuit:

The race starts alongside the River Thames at Westminster. Another London Eye wheel has been built next to the existing one. An elegant and futuristic double-decker bridge stretches over the river by the Houses of Parliament. Most noticeably, a huge new maglev train system has been built running along the river (it’s a high-speed link to the new Estuary Airport). As cars line up on the starting grid a train flies past at 400mph, blowing dust & paper over the racers. Enormous video walls dominate the riverside skyscrapers, advertising whatever technological marvel is an essential purchase this month. At one point the track dives underground into a new tube station unloading area (taxi rank?), with the platforms/tube trains visible through clear perspex walls.

Ideas for Honolulu (Hawaii) Circuit:

The race starts along the famous Waikiki beach. Immediately visible are several huge new hotel skyscrapers, some with completely transparent fronts to provide the best view of the beach. To avoid ruining the view the city planners haven’t widened the beach road, but instead built a completely new underground layer below it. There are several on-ramps to transfer between the levels, and when taken at speed these will propel race cars into the air. The track goes through the (expanded) Honolulu Airport, and onto one of the closed off runways. However, the rest of the airport is still open - it would be economic suicide to close all the runways during race weekend! As such, there are huge airliners landing and taking off during the race. Next-gen passenger VTOLs land right next to the track, ferrying their important passengers to their spectator positions. The track also visits Pearl Harbour (still home of the US Pacific Fleet of the future), where the racers get to glimpse the most advanced aircraft carriers, cruisers, and destroyers in the world.

Ideas for Los Angeles Circuit:

In 2040 the LA city authority have finally realised that they need to build public transport, after their road traffic problem became unmanageable. Virtually every highway now houses at least one active Maglev track in the central reservation, and in many cases the actual path of the roadway has been compromised as a result. This makes LA a technically demanding course to drive, with roads dodging between train stations, helipads, pedestrianised zones, and new bus routes and shelters. The car isn’t king in LA anymore, but it has made the downtown area a much more interesting race track as a result.

Ideas for Monaco Circuit:

Built around the roads of the legendary Formula 1 circuit, this track is still the jewel in the crown of the racing world. The Monaco road planners are less concerned with practicality, and lean more toward providing a spectacle to the race-going public. Large sections of the harbour are now filled with the latest playboy craze: floating casinos. These stunning buildings are built in the style of the grand casinos of old, but using cutting-edge materials to give them a neo-contemporary feel. Huge next-gen pleasure boats sit in the harbour, with private helicopters and VTOLs constantly landing and taking off from their decks. The most noticeable addition to Monaco is a vast new bridge over the harbour, built for high-speed traffic to bypass the inadequate cobbled streets of the city itself. The bridge is a spectacle in it’s own right though; it is built entirely from transparent material! Driving over the bridge is experience enough as you peer down into the water below, but racing at 250mph across it is something else entirely…

Ideas for San Francisco Circuit:

There is always a need for traffic to cross the San Francisco bay from the city to Oakland. At present the two bridges - the Golden Gate and the Bay Bridge - are constantly choked with traffic. Perhaps in the future there has been a breakthrough in materials technology, and now it is possible for tunnels to be laid down on the seabed underneath the bay. This would solve many of the cities traffic problems (multiple new, high-speed roadways) as well as providing an amazing area to race in. The materials themselves could even be translucent (like a scaled up version of the walkways you see at aquariums), revealing the shadows of boats on the surface above. You’d catch glimpses of the silhouette of the Golden Gate bridge from beneath the waves, and then blast out onto the surface and double back to cross over the famous landmark itself.

Driving Experience

An organised sport, with huge fanbase and international appeal. Everything is believable and grounded in reality.

YES: player joins a race team (manufacturer or corporate sponsored), season-based racing format (and single player career mode). Each race is a huge cultural event for that city/area. Driving model is realistic, but exaggerated to account for future technology. “Powerups” can be utilised in certain cars, i.e. advanced KERS (Kinetic Energy Recovery System) in the BMW E3. However, these “powerups” are always technology-based, grounded, and believable.

NO: destroying opponents, fatalities, smack talk between racers, projectile weaponry.

Cars

Manufacturer examples: Ferrari, Lamborghini, Mercedes, BMW, Lotus, Bugatti, Maserati, Pagani, Koenigsegg, Lamborghini.

Imagine the next generation of cutting-edge concept cars; the vehicles our children will dream about. They should be realistic (no rockets or jet engines), insanely desirable, and have a clear development path from present day production vehicles.

YES: KERS devices, advanced wings/spoilers, electric or hydrogen powered engines, airbrakes, next-generation airbag systems (internal and external?), computer-assisted steering & braking, next-generation ABS systems, next-gen cooling systems (and associated big intake valves), coloured carbon fibre, movable parts (to assist high-speed driving or cornering), super-strong transparent materials (“bubble” domes?), advanced hazard detection on windshield, detailed paint jobs and liveries.

NO: flying cars, jet engines, driving upside down, unbelievable acceleration/braking/top speeds, energy shields, missiles or offensive weaponry.

Car idea: Ferrari FZ65

The grandchild of the Ferrari FXX project, this angular and aggressive-looking race car was built for the track. It’s front scoops and tiny headlights are reminiscent of the FXX, as is the boxy rear section. The most striking addition to the car is a comprehensive computer-controlled airbrake system. 55 movable panels slide away from the bodywork independently; all helping the car to corner. Under heavy braking (i.e. at the end of a straight) all of the panels automatically flip open, giving huge braking capacity and making the car look like a giant red puffer fish! As this car is driven around the track there is an audible CLICK CLICK CLICK as the flaps deploy and retract under instruction from the computer. The entire surface of the car appeals to move and ripple, and in bright sunshine the reflections give it a beautiful glimmering appearance.

Car idea: Lotus Esperante

A logical progression from popular two-seater sports cars like the Exige, the Esperante improves on the classic design with an automated spoiler system. When the vehicle drives over a certain speed the onboard computer unfolds an additional two rear-spoilers. These flaps curl open like an exotic plant, taking 1.5 seconds to fully deploy. Once open, the spoilers provide additional down force for cornering as well as an impressive visual spectacle. The most talented drivers will take manual control of the spoiler system, constantly opening and closing the flaps to achieve grip through corners, whilst minimising drag on the straights.

Car idea: BMW E3

The latest and greatest electric car from the master engineers at BMW. Not only does the E3 boast the most efficient drive on the circuit, it also recycles spent braking energy in it’s next-generation KERS system. This impressive speed boost can take an experienced driver from middle of the pack into pole position. The only downside of this impressively high-tech system is the amount of heat generated, leading to large and distinctive air intake fans on the front of the vehicle. The KERS battery is charged under braking, but drivers must manually activate the enormous cooling fans several seconds in advance to achieve an optimal boost.

Car idea: Bugatti Uberon

Desperate to get back to their world-beating glory days of the Veyron, Bugatti have spent recent years in private testing away from the race circuit. The result of this extensive R&D period is the B7 internal combustion engine; perhaps the pinnacle of fossil fuel based engine design. It’s also one of the noisiest and most powerful machines on the planet. The Uberon is built entirely around this engine, and has the greatest top speed of any road car in existence (326mph). It looks the part too, with huge fuel tanks and thunderous exhausts protruding from it’s streamlined bodywork.

Car idea: Lamborghini Cavallo

Resembling the stealth fighters of yesteryear more than a sportscar of 2040, the Cavallo is the ultimate example of style and speed in one well-engineered package. New for this year’s model is a complete carbon-fibre bodywork, coloured in the traditional Lamborghini yellow. The angular faces and sharp edges make this vehicle look both intimidating and hugely capable in the right hands. Advanced manufacturing techniques have allowed the entire bodywork and frame to be created from one solid piece of carbon fibre, ensuring superior strength as well as a visual appearance which is sure to turn heads.

-It’s easy to get caught up in making the BEST IDEA EVER.

—The problem is that everybody has a different version of the best idea ever.

—-Your own view will change over time too.

——In the process of making that idea you’ll work intimately with it, and see it’s flaws exposed.

——-It will no longer be the best idea ever. To most people it probably never was in the first place.

Every creative person follows the above process, and every creative person experiences that point when they lose faith in what they are doing. They lose motivation simply as a result of working intimately with their own projects.

It’s a hump, and a pretty big one to get over. I know lots of extremely talented people who really suffer with this mid-project lack of faith, and it often leads them to make bad decisions. Some drastically change their project and perhaps lose what made it interesting in the first place. Others go round in circles, softening all the sharp corners and losing the edginess which they once had. Worse still, many abandon the project completely - “the next one will be better” they say…

Of course when they get to the next project they run into the same problems, and the process repeats. How many creative people do you know with a string of unfinished projects behind them?

People in this situation start to look inwardly. I should know - I’ve done it myself a thousand times. Why can’t I make the best idea ever? It must be me who is faulty. Other people have made the best idea ever - why can’t I? The cycle continues… The only thing that can possibly break it is a change of mindset. 

Being able to finish a project isn’t anything to do with the project itself. It’s to do with the mindset of the person who is making it. That person needs to have the confidence, discipline and determination to work within boundaries and finish the damn thing. Forget the idea of making the BEST IDEA EVER - that’s a fools errand. Get it done, get it shipped, and then use what you learned on the next thing. 

The best movie directors, musicians, game developers or comic book artists all have one thing in common: they’ve finished a lot of projects. They might not be 100% proud of some of their earlier work when compared directly against their best stuff, but they understand that it was all part of the process to get where they are today. 

So, you persevere and finally finish your project. You might not have confidence in it just yet, but at least you have the finished project. People can watch your movie/listen to your music/play your game/read your comic, and feedback can be gathered. Talk to them, and see what they thought of it. There will ALWAYS be things to tweak and areas to improve. It will probably turn out that this one wasn’t the best idea ever. Maybe no idea, in the history of man, has been the best idea ever. But your idea is finished, and people are using it. That’s amazing.

You’ll have improved your skills and gained lots of knowledge en-route, which means that your next project will be even better. Practice makes perfect, and through working hard and stubbornly you’ve had a lot more practice than those who abandon their projects or go around in circles. 

Remember, it’s impossible to be the best with your early attempts. Don’t get disheartened and don’t give up. Stay positive, and ship the damn thing!!

The video games industry could learn an awful lot from this guy…

As we continue to diversify as a medium, we need storytellers to point us in the right direction. The classic argument has been “only 18-34 year old males buy console games, so that’s all we can cater for”. That doesn’t hold up today - with new devices and digital distribution our demographic has already changed. Now is the time to act on stuff like this. 

This is the third and final part of a multi-part blog post. It’s about a crazy event of human endurance: a two-man team attempting to make a complete video game in three days. If you haven’t yet read the first two parts, check them out here: Part 1 and Part 2.

Day 3 - Time for polish

The third day was split into two. The morning consisted of us finishing the gameplay. All the levels went in, all the models, and a lot of the textures. The game was now just about playable from beginning to end, and the scope of it all was pretty much defined. Even though there was still hours of tweaking we could have done at this stage, we decided to move on once again. It was time for polish - and they always say that the last 10% of development takes 90% of the time. Never has a truer word been said in my experience.

I went back to Inkscape and drew out a whole bunch of textures for the models. Adrian refined the collision meshes and updated the scripts, making the physics work wayyy better. I tweaked it further to limit the maximum ball velocity, and finally our physics problems were solved. No more super elastic balls bouncing through walls and out of the play area. Woo!

As for audio, we browsed free music and sfx websites while we worked. Either of us would shout out if we heard something that we thought matched the game. Within a couple of hours we had our audio assets picked out. 

I scripted level transitions and a basic front end (the “outside” of the safe), whilst Adrian built the audio system and worked on the dynamic lighting and end sequence. We even had time to try out an iPad build of the game, with hacked in touchscreen controls and crappy mobile shaders. As cool as this was, we really had to focus on one type of platform so we picked the desktops (our PC and Mac). Mobile platforms would have to wait, for now…

The third night was the toughest time ever, and the only time we really stopped bouncing off one another. This was mainly due to extreme tiredness, but also perhaps the come down from 2 solid days of drinking Monster Energy. I don’t think either of us said a word between the hours of 3 and 4am. However, by the end of the third day we had an *almost* finished game. Only a few hours left…

Day 4 - Are we still alive?

Thursday morning was the final furlong. We agreed to stop working at lunchtime, and that’s exactly what we did. Desperate tweaking took place, and bug fixes thrown in, until the game was as finished as we had the energy to make it. Victory was ours.

We collapsed on the sofa to do a play through. Both of us played the whole thing through with no problems, and despite the tiredness I don’t think I could have been happier with our (almost) superhuman accomplishments. We did it - we made a whole game in just over three days. So. Freakin’. Awesome. 

The game itself is actually really fun. When we started this little experiment I had viewed it more as a task to learn Unity. I hadn’t imagined that we’d actually get a fun game out the other end of it, and when we did it was a really pleasant surprise. I think it goes to show that you don’t need to spend hours in design meetings agonising over every detail of a game before it is built. Sometimes it’s enough to roll up your sleeves and get on with it. As long as the team isn’t too precious over any particular idea, you can organically throw things together and it works out.

One of the reasons I wanted to blog about this event in such detail was because this is pretty much the first time I’ve experienced this kind of ease of development. Not only is Unity a fantastic tool (and I suggest you check it out if you haven’t already), but working with Adrian was a real pleasure too. Everything fell into place really easily, and we made exactly what was in our heads - even though it was way out of our comfort zone.

So what happens next with Safe Cracker? Well, we’ll probably do another crazy game jam at some point and get it to “release” quality. Not that we couldn’t chuck it out now, but it wouldn’t meet the high standards that we both set ourselves. Could it be a proper commercial release? Possibly, although that’ll probably depend on whether we decide to find the cash for a Unity release license. Will it make the money back? We’ll have to discuss it…

What did we learn from this whole experience? Well, for me it was a great validation of the huge need to constantly push forward. We didn’t know where we were going or how we would get there, but by making a series of smart decisions and working really hard we ended up with a final product we can be proud of. For me, it doesn’t matter whether you’re an expert or a novice - working hard and not getting caught up on the details is all that matters. We had never used Unity before, but after building a game with it I think we can both say we’re pretty competent now. All in a few days!

I hope you’ve enjoyed this blog post, and (with a bit of luck) you’ll be able to play Safe Cracker very soon! Thanks for reading.

This is part 2 of a multi-part blog post. It’s about a crazy event of human endurance: a two-man team attempting to make a complete video game in three days. If you haven’t yet read part 1, click here.

Day 2 - Defining the gameplay

8:30am, and time to get working again. After day 1 we had a basic idea gameplay idea: our game would consist of little bouncy balls moving around inside of a giant rotating disc. The disc would be the inside of a bank safe, and your bouncy balls would be little tiny explosives you had dropped in to blow the locks. The balls would always fall with gravity (i.e. toward the bottom of the screen), and you had to rotate the safe around to make the balls go where you want them to go. However, it’s not that easy - as they are bouncy little buggers!

So first task of the day was to quickly drop some “switches” onto the disc. I wrote some basic logic for them to get activated when the ball passed over them. They were simply bright red planes at this point, and they swapped to bright green when they collided with the ball. The idea was that the player would have to bounce the ball around the disc and activate all the switches to complete the level. 

At that point Adrian came up with just the coolest idea: the balls were “elastic explosives”, and you had to drop them into each of the locks on the safe to blow them up. The “locks” were actually little compartments around the outside of the disc. There were 18 locks in his Maya mesh, so we had 18 levels to make. Again we didn’t really discuss this much - it was a cool idea so we both instantly agreed to do it. At no point during the game jam did we really stop and think; both of us were simply rip-roaring toward the finish line at a breakneck pace. 

This is where the game really started to come together. These tiny perimeter compartments were placed around the hexagonal safe mesh. They had little doors sealing them off from the central area. When all of the switches for that level were activated, the door would drop down and the player would have to drop the ball inside the lock. When the ball was in there the door closed up again, and the next level started. All of the balls of the previous levels would stay in the compartments, so by the time you reached the last level you had 18 balls bouncing around, ready to explode. 

As you can imagine, there was virtually no time to actually “design” levels. I quickly scribbled down 18 basic patterns (a process I had learned from designing many of the levels in Tiny Invaders), and that was pretty much it. We briefly discussed loads of game mechanics, but quickly ruled most of them out due to time constraints. The only one which would stay would be the “bouncer” - a circular rebounder which would be more at home on a pinball table. 

By the end of the second day we had a few levels complete and playable. There were loads of physics problems (the ball bouncing through gaps), and generally the whole thing “looked” pretty ropey, but we had the beginnings of a game. Again we called it a night at some ridiculous early morning hour, with bloodshot eyes and headaches. 

A good buddy of mine, Adrian, lost his game dev job recently in yet another big round of UK layoffs. Obviously I don’t need to say that this totally sucks. On the plus side, this meant that he had a few spare days last week in between interviewing at new studios. We decided it would be a good idea to spend this productively together, and a plan was formulated to do a little game jam… Could we make an entire game in a (very) short space of time? Was there enough beer/muffins/Monster Energy drinks in the world to fuel such a rampage?

There was one requirement: we wanted to use Unity, as both of us wanted to get some experience under our belt with the technology. Oh and we had to have it done in three or four days. This was a pretty big challenge, as before our game jam we literally hadn’t used Unity at all. Could we go from complete novices to having a fully fledged game in just a few days? Well, there’s one way to find out…

Day 1 - Can anybody write C#?!

I drove to Adrian’s apartment and set up my computer on his coffee table. It was midday on Monday before we had Unity installed and open. First things first, lets do “something” with it. We both dragged out a cube and randomly clicked on check boxes until things happened. He figured out physics and shaders, and I managed to set up a basic C# script. We didn’t really have any goal at this point, aside from learning how to whack stuff together in Unity. The first hour of our game jam was extremely experimental - the two of us going off in different directions to investigate certain features, and shouting across the room when we got stuff working. It’s a testament to Unity that people can come fresh to the tool and just start making stuff without really knowing what they are doing…

Ok, we’ve got some transparent spheres colliding against a box. We can make a game out of that, surely? Time for a race! Who could make a basic game of Pong first? We cracked open a beer and started frantically tapping away on our keyboards. My Pong arena was long and thin, powered by all sorts of poorly-written scripts that hadn’t had the time to mature properly in their author’s brain. Adrian’s arena was a more traditional shape and powered by some awesome physics effects (which I promptly stole for my game too!). Within about 10 minutes we both had a bouncing ball, moving bats, and the beginnings of a game. Awesome!

Well aware of the ridiculous time constraints we had put on ourselves, we decided to push on with “the big idea”. We walked across the road to a supermarket to grab some lunch, and by the end of the 10 minute walk we pretty much had our game design. Neither of us were too precious about it - we simply didn’t have the time to think it through completely. This one would develop organically as we built it; Christ knows whether it would work out or not.

This is kind of how the conversation went:

• “We should do something that works on keyboards as well as touch screens”
• “Neither of us are artists, so something that uses simple UI art would probably be more achievable”
• “Ermm.. We just learned how to do physics. We could do something with that?”
• “What about a Peggle style game?”
• “Yeah! But what about instead of directing the initial ball launch you rotate the entire level around its centre, like a big disc?”
• “Yeah, like cracking a safe!”

…and thus, Safe Cracker was born! The idea would be this: you are a master bank robber, trying to break into the most secure vault in the world. You must peer inside the mechanism of the safe, and activate all the switches to pass each layer of security. Only the most skilful and determined robbers will be able to beat the game and access the treasures within!

It’s true that the concept was very high level at this point, and only existed in our heads. We had about 3 days to turn it from idea to reality… Back to work!

Believe it or not, we didn’t really know whether the game would be 2d or 3d at this stage. We actually diverged almost immediately - I booted up Inkscape and started scribbling some ideas in 2d, whereas he booted up Maya and created a 3d play area for the ball to run around in. It was such a weird process… we ended up using my 2d concept art as a basis for texturing his 3d meshes. Believe it or not, it kind of worked out in the end!

We knew that we had to get something playable by the end of the day to maintain our momentum. In a fury of bad scripting, bad modelling, and bad texturing we ended up with a rotating 3d disc, and a little ball inside of it. The disc had little walls built into its interior which the ball collided with too. It wasn’t really a game at this stage, but at least it’s something. By about 4am we called it a night and hit the sack. Well, I slept on the sofa I had been sat on all day, but whatever!

Stay tuned for part 2…

This update is all about learning to write code for all platforms, sticking to self-enforced deadlines, and not getting too caught up in the details…

My last blog post had one underlying theme to it: I had been striving to increase the audience of my quiz games through features and polish. I picked topics which I knew would have a wide appeal, I localised the games into as many languages as possible, and I provided many different ways to play the game. The hope was that there would be something there for everyone.

There has been one major thing missing from this strategy though; something pretty major. Unless you owned an iOS device (iPhone/iPad/iPod), you couldn’t play the games. They simply weren’t written for Android, Windows Phone, Blackberry, PC or Mac. Given my aim of becoming as appealing to as many people as possible, I obviously wanted to try and fix this. The more people playing the game, regardless of platform, the more happy customers and ultimately more revenue.

Doing this hasn’t been a small job. Unfortunately I had chosen to write the original versions of the game in Objective-C, a language which is (by and large) only used on Apple platforms. Generally speaking, if you want something cross-platform then your best bet is to write it in C++ - one of the most popular languages in the world. Whilst I had some experience with C++, writing little demos and side projects is a lot different to porting (what has become) quite a sophisticated set of systems. This has been a huge learning process for me, and I still feel like I’m getting my head around some of the more (frankly ridiculous) quirks of the language…

I decided early on that I would stand on the shoulders of giants, and made use of some excellent libraries and tools (most of which are either open source or extremely low cost). For any indie devs who are in the same boat, here’s a short list of the stuff I use: Cocos2d-x, CocosBuilder, ParticleDesigner, TexturePacker, Audacity, Inkscape, Acorn, Coda 2, Namechanger, Cornerstone, Google Docs.

As with so many things in life, I decided a gradual change would be smoother than an all-out re-write. Every web developer worth their salt knows the tragedy of the great Netscape re-write, and I find it’s always in the back of my mind when I come to situations like this. Many programmers are keen to write code for the sake of writing code (it’s their passion), but that’s not what motivates me. I like seeing the finished product - the person playing my game with a smile on their face. For me the code is a means to an end, and I treat it as such.

The quiz engine had been built in a modular fashion, so the quiz logic was separate to UI layout stuff which was separate to the leaderboard/achievements stuff, and so on. This was a good move, as it meant I could take each Objective-C module and re-write it into C++ without too much trouble. The first thing to change was the quiz logic stuff, i.e. loading the questions from an XML file, setting up the data structures, efficiently shuffling all the questions and finding randomly generated answers (without any duplicates), handling the question timer, etc. etc.

Many developers would wait until they had re-written the whole thing before shipping the updated project, but I was constantly worried that if I went too deep down the rabbit hole I would lose perspective. It’s very easy to get lost in a world of coding horribleness, and think “well if I just re-write this bit then this other part will be slightly nicer, but then that’ll lead to this other problem here, and…”. You get the idea. I wanted to avoid this at all costs; especially since I’ve developed a weird kind of “anti-launch anxiety” - if I don’t ship a game every month or so I start getting all nervous and worried that it’s all taking too freakin’ long…

So my solution to this issue was simply to integrate the re-written modules as completely as I could into the existing game, and ship them to the public bit by bit. I used the less popular games as a live testbed, and shipped them first. I used in-built analytics and my own knowledge of the systems to detect any faults that might have slipped in, and crowd-sourced any less trackable issues via user reviews and star ratings. When I was fully convinced that a particular part of the game was working correctly I would push it to prime time, i.e. throw the updates into Capitals Quizzer and put some real numbers behind it. I’d only do this when I was absolutely confident in the product though - you don’t want to push crappy code to an install base of 2.5 million!

The main advantage of this is that I always had a shippable game. I could always pick it up and have a play; very rarely did I find myself in a position where everything was broken and it wouldn’t even compile. It’s been a great tactic, as the complete re-write has ended up taking many months to finish. I’ve been able to keep shipping games (and keeping public interest high), without losing motivation or becoming distracted from the overall aim.

When it came to building the Android version, I was struggling to write some of the more complex stuff such as advertising and in-app purchase. This is actually one of the most complicated parts of the games, as the banner adverts are mediated to maximise eCPM, interstitials are only shown in a sensible fashion (I don’t want to spam users with ads, so I apply some logic to this and try to make it not too terrible), video adverts are incentivised (so if you watch a movie you get a free game mode), etc. The in-app purchase is difficult because there’s an entire storefront behind it, with all the different user flows that go with it (what if the user cancels half-way through a transaction? Does your game deal with that situation properly? What if the product prices don’t download correctly? Then what? Huh huh huh?).

All of that, mixed with the fact that Android is a pain in the ass with this kind of stuff, i.e. I’ve had to write three different IAP mechanisms, so far, for each of the different stores (Google Play, Amazon App Store, Samsung Apps) and intelligently swap between each depending on which “sub-version” you’re running. A nuisance…

So my solution to this was to basically sack it off, and make a new game. It sounds counter-intuitive, but I planned to make an entirely new, simplified quiz game which cut things down to a bare minimum in terms of complexity. I could integrate my sparkly new Android stuff in a situation which wasn’t too complicated, and ship it to customers quickly and test it in the field. This new game turned into Guess The Flag (iOS, Android), and I’m actually really happy with it. I shipped it simultaneously on iOS and Android, and it actually runs on the Mac as well (although I haven’t shipped that version yet). The game is polished and fun to play, and is already pretty popular. Overall it’s been a triumph of technique, and a good example of how to tackle problems from a different angle.

I’m pleased to say that the entire re-write is now done - more or less everything is in C++. The audio, graphics, input, interface layout, particles, achievements/leaderboards, banner/video/popup advertising, in-app purchase, analytics, localisation, dynamic layout and resource loading, etc. is all working great. The new versions of existing quiz games (with sexy new graphics) are in submission with Apple, and Android versions are on the way. They are generally much better too; I hope people enjoy playing them as much as I’ve enjoyed developing them.

The last few months have been incredibly enlightening for me. After shipping Tiny Invaders and watching it’s performance on the App Store, I’ve had the time to evaluate it’s pros and cons and figure out how to get ahead in this emerging industry. One of the insights is this: you need a metric butt-tonne of people downloading your game to be successful. Now that sounds pretty obvious, but it’s how you achieve that metric butt-tonne that is the important bit…

At Hogrocket we worked really hard for almost a year to finish up Tiny Invaders and ship it on iPhone and iPad. We spent a lot of time doing PR around the game, and generally I was really happy with the results of that. We had magazine interviews, developer movie featurettes, App Store feature spots around the world, making-of videos, celebrities tweeting about the game; hell we were even on stage at the Apple iPhone 4S keynote! Amazing stuff!

However, it didn’t do enough. Our game, like many others on the store, had an impressive first two weeks and then nosedived into obscurity. Despite some interesting promotions over the last few months (with another starting today, watch this space), we haven’t been able to reignite the thousands-of-downloads per day volume that we need to successfully monetize the game. It’s a shame as Tiny Invaders is still getting some great App Store reviews (lots of 5 stars), but just not the volume that we need. After our experiences, I do find myself nodding along when reading articles like this one: “Mobile Games Marketing Doesn’t Work At All”.

Luckily, I’ve had two horses in the race for a while now. My other company is called Supergonk, and it originally started as an outlet for my personal projects. Since then it has grown into my bread and butter. Supergonk currently publishes mobile quiz games, the most successful of which is called Capitals Quizzer. It’s a fun and effective way of learning the capital cities of the world, as well as their flags, currencies, famous landmarks, and regions.

Supergonk is doing tremendous volume in comparison, and making a reasonable profit too. It’s had absolutely zero PR of any kind whatsoever. I’ve used a different strategy (freemium), and it’s worked much more effectively. Not only that, but it’s been incredibly consistent over the past couple of years. Right now Supergonk is doing between 2,000-4,000 downloads a day at the moment, and enough of those customers are choosing to pay to make it viable for me. Overall the titles have been downloaded over 2.4 million times around the world!

I actually launched Capitals as a completely free-to-play game with no monetization in it at all. I built the game up bit by bit, adding new game modes and naturally growing the monetization into the app alongside new features. Nowadays players can play a large chunk of the game for free, and if they like it they can pay to unlock other modes. You can purchase other game modes individually, or buy them all at a discount.

Even those who don’t wish to pay (approximately 97%) are monetized through a combination of banner adverts (which are surprisingly effective), fullscreen interstitial adverts (not so much) and incentivised video advertisements. I’m always playing with new ways of passive monetization like this, whilst constantly trying to stay on the right side of the line when it comes to annoying your users. A difficult task, make no mistake.

Localisation has been a big thing for Capitals. The game is now available in English, Spanish, Portuguese, Italian, French, Japanese, Chinese, Arabic and German. Every time a new language was added, the daily downloads went up. All of this localisation increased the app’s reach, and likewise the profits went up. It grew organically, and has previously reached #1 in the free apps category in Germany, Switzerland and Spain (and #2 in Italy). All of this without spending any money at all on user acquisition. I’m very happy with that!

I’ve really treated these games “as a service”, constantly tweaking and updating them based on the feedback from user reviews. Capitals has been entirely rewritten twice since it first launched. The “quiz engine” backend was generalised and extended, and that became the base for the newer quiz games (Bible Quizzer, Presidents Quizzer and Space Quizzer). Recently I’ve rewritten the whole thing in C++ and will be launching an Android version in the coming months. Depending on it’s success it might make it’s way to Blackberry/WebOS/Windows Phone too. I dream of one day putting a version onto Facebook too, but we’ll see…

Here are the daily downloads of all the Supergonk games over the last year. As you can see, it’s pretty consistent:

Almost everything I’ve done with the Supergonk games has been to increase it’s audience. I haven’t bothered with PR or anything like that, and (to my surprise) it hasn’t made any difference. I was lucky enough to identify early on that achieving large volume was absolutely key to surviving in the mobile space. Making your game free is the first stage. There are two important things to do beyond that: keep growing your audience (with things like localisation, more platforms, etc.) and keep building your game (add more features and content, fix the bugs and annoyances, and constantly strive to make it better through consecutive updates).

These Supergonk games are mature products now, and have quite a sophisticated network of statistical analysis and passive monetization behind them. From my limited experience it seems like doing this kind of thing is much more important than the traditional “AAA” PR we tried with Hogrocket.

Keep working smart, and ship new versions often! That’s the path I’m taking with Supergonk, and it seems to be working out pretty well so far…

Thanks again for joining me for part four of this exploration into the life of Hogrocket; from inception of the company right through to the release of our first game: Tiny Invaders. If you haven’t read the first three parts of this series you can do so here, here and here.

We were a few months in, and team Hogrocket had pretty much finished our first game, Tiny Invaders, by this point. We’d taken the original prototype, a game based around steam trains moving around tracks and collecting sheep, and worked with a talented team of artists to turn it into an epic story of microscopic alien invasion. All in all we were on the right path to launch. However, before we took that giant step we had to ensure the product was solid. Was the gameplay good enough? How was the difficulty curve? Were there any bugs we hadn’t found in our own testing? We were self-publishing Tiny Invaders, and couldn’t rely on a publisher to track down these issues for us. It was time to put on our testing hats.

We needed feedback, and lots of it. The team had already reached the point where we had lost objectivity on it… we’d been working on Tiny Invaders for too many months to realise whether it was too hard or too easy. We were all super class A hackers at the game; how could we tell whether it was accessible to first-time players? There was only one answer: get a bunch of new players to give it a try.

We decided to hit the road and do a massive tour of the country. It coincided nicely with the Develop Conference in Brighton, allowing us to try the game with our fellow game developers. We also hit a couple of house parties in the home counties, and travelled to Cambridge for a bit of additional testing. Good times were had, and lots of objective usability testing was achieved. The youngest person to play the game was five, and the eldest were in their late 50’s. We found a whole bunch of issues that were quickly fixed, and redesigned part of our tutorial based on player feedback. All in all it was a great thing to do.

If you’re thinking of running your own usability roadshow, be careful. It’s all too easy to become impatient with first time gamers, especially when they don’t play the game exactly as you intended. It’s very tempting to say “Oh give it here” and show them how to solve a puzzle, or proceed in a menu. DON’T DO THIS! The entire reason you’re doing this test is to try and achieve an unbiased view of somebody playing your game with no external involvement. Even the fact that you are there with them will naturally bias your view, but as an indie with limited budget we have to take this on the chin. However, that means that you have to be even MORE concerned with running these usability tests correctly.

You must remain silent - let first impressions and difficulties shine through naturally. Make sure you choose a variety of different types of people: gamers and non-gamers, male and female, young and old, etc. Oh and while it’s useful to have other game designers play your game, don’t rely on them for particularly constructive feedback. In our experience you’ll find that designers naturally try to change your design to their own vision rather than comment on what’s in front of them. Of course there are times when this is incredibly useful (i.e. when you are brainstorming), and times when it is less so (i.e. when you’re trying to ship a game)!

This is lesson number 4 for indie game devs: Play test your game a lot, with a variety of people and a variety of devices.

Once we were convinced that we had done enough testing and iterated on the feedback sufficiently, we finally took the decision to…

…ship the damn thing! We bundled up the final version of the game and sent it off to Apple for approvals. Meanwhile we penciled in a worldwide launch date of September 1st, and started working with key press behind the scenes to build some pre-launch buzz. We also started courting Apple as much as possible, sending them builds of the game and sharing plans for our PR push. Luckily enough this paid off for us, and Apple chose to feature Tiny Invaders in several App Store spots at launch. This was unexpected but certainly helped our sales, and overall had a very positive effect on downloads.

We took quite a strange approach with our pre-launch marketing. The intention was to not tell the world about our game AT ALL until it was available to buy. We didn’t see the point in doing any PR to the public when they were unable to actually buy the game. After all, the App Store is impulsive. People buy their games in the heat of the moment - it’s incredibly unlikely that people will plan a purchase ahead of time. Pre-orders are simply non-existent, and that’s the main driver of pre-launch marketing in the console world (where our experience was).

That said, we weren’t staying silent. We were talking to the public about our company and generally building the profile of Hogrocket: blog posts/guest posts/podcasts all helped contribute to some really positive momentum behind us. We were also working hard behind the scenes with key press to queue up coverage for the launch date of September 1st. We were lucky enough to have good relationships with several main players, and this led to a decent amount of exposure for Tiny Invaders at launch.

We also ran a large private beta test, not only for testing the game (remember that we had already done our big test roadshow) but also to generate interest and play time with some additional members of the press and industry friends.

At launch we did a whole bunch of things: an official website, poster art release, a mail shot to 800+ industry/press contacts/followers, promo codes to key press, a launch trailer on YouTube, guest posts to various websites, a release of the soundtrack, and a few other things too. The idea was to take over as much of the core mobile press as we could for a day, and get as much exposure as possible.

However, doing PR for your game doesn’t end when it launches like it did in the console world. Nowadays we can update the game at any time, adding new features and content. We quickly added iPad support, iOS 5 native Twitter support, and also localised the game into three more languages (French, German and Italian). We visited a few events across the UK, and did even more PR to try and push the game into more people’s hands.

Overall the feedback was good:

…and that leads us on to our fifth and final lesson: “Find what makes you unique, and talk about it. If nobody knows about your game, they won’t play it”.

We’ve always focused on our story here at Hogrocket and I think that resonates with people. Being made redundant from our previous employer (Bizarre Creations) and deciding to form our own company has been quite a journey and hopefully pretty compelling for people to join in on. We were the console guys making a fresh start in mobile; that was our USP. The press and community that followed this journey deserved a great game from us in return for the positivity and belief shown toward us. We delivered on this as much we could to give ourselves as big an impact as possible when Tiny Invaders finally hit the virtual shelves.

In Summary

If you’ve been following all four parts of this series of blog posts you’ll remember each of these key points to remember:

I hope you have enjoyed reading these posts, and that it has given you lots of insight into how we run Hogrocket and make our games. If you haven’t played Tiny Invaders yet you can download it today for free! Feel free to let me know what you think of the game or these blog posts in the comments section below. Speak to you soon!