I am very pleased to announce my latest project: a place for indie game developers to work together in a collaborative and supportive environment. Developers can rent a desk inside an open plan office, and benefit from being surrounded by other game developers and creative technology professionals. The project, called Rocketdesk, also aims to encourage further collaboration between developers in the Guildford, Surrey, UK area. We plan to host various user groups, networking meets, professional presentations and more!

Rocketdesk can be found at the Surrey Technology Centre, located in the Surrey Research Park; home to well-known game development studios such as Lionhead and 22Cans. It is aimed at solo indie developers and small teams, and provides a cost effective and comfortable way to get started in the work of independent software development. It is also suitable for long-term solo developers, like freelance programmers or designers, who want to avoid working from home in isolation.

The idea for Rocketdesk came from a personal requirement. I have recently moved back to Guildford, and was interested in meeting other local developers and making some new connections. After a chance meeting in a pub, I got to know a local indie dev who was kind enough to let me work on one of his spare desks in his new office for a few months. The experience was fantastic, and made me want to seek out further collaboration. I also met a bunch of other devs who were in the same situation; i.e. working from home, wanting to meet other folk in games and work in a productive and professional environment.

After getting together with my long term colleague and friend, Neil Johnston, we decided to form Rocketdesk to meet this need. He was already planning a co-working space in the Guildford area, so when the opportunity came up to turn the idea into reality we both jumped at the chance.

We’ve been lucky enough to have forged a relationship with the excellent people at Surrey Research Park, who are just as excited about building this new opportunity. The early feedback from devs has also been positive. Now, as we move towards the launch phase, I’m hoping that developers will see the value in a project like this and join us.

If you’re a developer who would like more information about co-working at Rocketdesk or attending some of our games industry-focused events, then please take a look at the Rocketdesk website: www.rocketdesk.co.uk

Thanks for reading!

My “flagship” game is called Capitals Quizzer. It’s a trivia game about geography, primarily learning the capital cities of countries. I call it the flagship game because it still gets downloaded much more than anything else I’ve built, even many years after it initially launched. In some ways it’s quite frustrating as I can’t seem to build anything new with the same traction of Capitals, but I guess I can’t really complain!

Over the years I’ve tried to keep Capitals current and relevant, with several major updates and rewrites. The original game was written in Objective-C and Cocoa, but that only worked on the iPhone. So the first rewrite was into a C++ library called Cocos2d-x. That allowed me to port to game to all manner of other platforms. However, I’ve kind of fallen behind in the Cocos world - the Capitals codebase is a major version behind the library and it would take quite a bit of time to bring it up to date. As a one man band, I need to be careful where I spend my time.

A problem emerged: I wanted to put the game onto the new Apple TV, but the old version of Cocos2d-x I was using doesn’t support it. You can’t blame Cocos - it was built many years before tvOS was a twinkle in Apple’s eye. I considered writing tvOS support into Cocos, but I think it would probably be a big pain and ultimately not that useful for the open source community given how behind the curve I am with that library. They’ve all moved onto bigger and better things by now.

Recently I’ve been writing a lot of stuff in Unity, which is pretty great. All of my latest games (Safe Cracker, Worldly, various prototypes for console) have been written in Unity, and I’m enjoying it a lot. So I made the decision a couple of weeks ago to completely rewrite Capitals Quizzer in Unity. They had already built Apple TV support into an early test version of their editor, so it would be all good. This will be the third rewrite of Capitals, and hopefully the last! :-)

Fortunately I was able to build on a strong existing foundation from Worldly. Much of the quiz data processing and UI flow was taken from Worldly and adapted. Of course I already had most of the artwork ready to go too - it just took a few small tweaks and some repackaging to make the original Cocos art suitable for Unity.

The data in Capitals was previously packed into quite dense XML files. These would be stored in a different way inside Unity, so I needed to regenerate all the data from the spreadsheets again. I was able to take the information from my Google Sheets readsheets and easily process it in Coda using the user-friendly regular expressions search and replace. None of this was a massive pain, but it took some time.

It took about 5 days to build Capitals into something you could play. I guess you could consider that an alpha, or content complete, version. The main struggle was getting the quiz state animations to fade in/out at the right time, but when I discovered how to use parameters properly on the Animator component then I was able to work around that.

The next week was spent getting tvOS platform stuff together. I rewrote a lot of the IAP systems to work with tvOS instead of iOS, and removed some of the things that aren’t supported (i.e. Mobile stuff, like sending text messages or popping up native alert boxes). Also, building proper widescreen support in took some time - the original game was playable in portrait mode on mobile.

The biggest thing was moving from a touchscreen-based UI to a controller-based UI. Or, more accurately, making one UI in Unity which would support both styles. When using a touchscreen you don’t need to worry too much about button placement or interactivity. As long as it looks like it should be tapped and is physically big enough for a finger to hit then you’re good to go. However, with controller-based UI you need to think about things a bit more. On tvOS the user swipes up/down/left/right on the remote to move between buttons, and clicks the remote to select. This is much closer to a console style environment than a touchscreen. It meant that I needed to build new features into my buttons if I wanted them to work correctly.

The first, most obvious thing to try was a colour change. I initially wanted all the buttons to get a bit lighter when they received selection focus. The downside of this is that I had to make all the buttons darker so that the highlight would be obvious enough. On non-highlightable platforms (touch screens) this would result in dark, dull looking buttons. Not ideal. Of course I could try and detect whether you’re running on a touchscreen and make adjustments that way, but what about platforms with both highlight (controller) support AND touchscreen support? Windows 8 introduced that, and I’d need a solution which would work for everything.

Then I tried changing the button image. I tried about a million different methods to see which one screamed “selected”, and eventually came up with a new design with dark bands on the edges. This process was much harder than I imagined and took longer than I anticipated. It’s easy to get one button appearing selected when positioned in a row of unselected buttons, but when you’ve only got two buttons it’s quite difficult to instantly message to the user which one is highlighted.

It still didn’t feel right though, so I ended up adding animations to each button so they got a bit bigger when you highlighted them, then shrunk to normal size when the focus moved away. Finally the buttons felt right and I could move on to fixing other button bugs. The remaining issues were things like being able to highlight offscreen buttons (they weren’t being disabled properly when offscreen), and tightly controlling the flow between buttons when swiping around the place.

Adding support for the rest of tvOS was pretty easy. Both Unity and Apple did a great job with the platform, and made it a joy to work on. I was able to ship the brand new version of Capitals Quizzer in time for the Apple TV launch, and everything seems to be working great. There are a few little bugs to fix now, so that’s priority number one, then I will start to roll out this brand new Unity version to smartphones and desktop platforms. After that I’m planning some new game modes and exciting new features, so watch this space!

Thanks for reading, and if you want to play Capitals Quizzer on tvOS then please download it here. Download links for other platforms are on the Capitals Quizzer website.

This is part three of a blog post series about how we built the world map for geography quiz game Worldly. If you haven’t read part 1 or 2 then please check them out here and here.

Our world map visual design had been created in a really nice series of concept art, and we had the technology implemented to display vector art on-screen. Now we had to build the map to final quality, and optimise it for mobile platforms.

To create the final SVG (vector) file, we used an editor called Inkscape. The vectored world map I created earlier in the process was used as a base, and we added detail to make the barebones map visually interesting. Here’s an illustration of what we started with, and the final map (with all detail and data):

Each section of detail was split up, and created on a separate layer. If you look at this zoomed in screenshot of the British Isles, you’ll see some of the detail we built in.

The main landmass is pinkish in colour, and then there are darker coloured cliffs on the southern edges. Each of the landmasses has a brighter pink highlight layer on the northern and eastern edges, and there are red country dividers for nations which share land borders. Finally, there is a wide shoreline layer which is coloured yellow. Applying this level of detail to the entire world, with all of it’s tiny intricacies and island clusters, took ages!

Each country shape was created and labelled in a very specific way. We built systems to preserve the naming of the shapes in the SVG file so that the game code could sort the layers and highlight specific areas by name. However, there are some weird oddities in the real world that we had to deal with:

• Quite a few countries have multiple, disconnected land masses. Think about the continental USA and Alaska/Hawaii. Or Indonesia, with it’s multiple islands. We needed to build a system which took multiple shapes and then merged them into one single country definition.
  

• Some countries are just too big. For example, Russia and Canada are both crazy large and we encountered issues fitting them both on-screen. The problem was that the camera would zoom all the way out into space to fit these countries onto a tiny mobile screen, but that would basically be asking the game to draw the entire globe each frame. That would cause performance issues.

The way we got around this last issue was to have special “zoom areas”, which overruled the country bounding box to control where the camera would zoom to. That way we were able to pick out on the main parts of the country (like southern Canada, or western Russia) and fix these issues. It also came in handy in other places, like excluding Hawaii and Alaska when zooming into the USA.

Here is a screenshot of the Russian zoom override zone (coloured in yellow):

• Another problem: some countries are just too small. This is especially true for some tiny South Pacific islands. We couldn’t really use our polygon budget to render these tiny little islands at high detail, so unfortunately they were to become approximations of their true shapes. I eventually compromised with a medium level of detail, and clamping the camera at a maximum zoom level so that the player never gets too close. It’s not ideal, but it’s the best I could do in the time available (we had a tight deadline on this project!).
  

When it came to optimisation, we had a couple of major concerns: performance, and memory. Fortunately with vector art, these two things are somewhat connected. Generally, if we could cut down on the number of points in our vector art then our performance would increase, and our memory usage would fall.

Once the world map was more or less complete in terms of visuals, we then went to work in making it optimal for performance. Here’s a nice illustration of how I did some tests to discover the best way of rendering the cliffs:

The image demonstrates four techniques which we tried to optimise the cliffs. The first (left-hand) column shows the “normal” rendering mode. This basically involved creating the cliff by duplicating the pink land mass and then shifting it down and left a bit. The top image is how it appears in-game, and the bottom image is with the land mass made semi-transparent so you can see what the cliffs are doing underneath. In the left column there is a lot of wasted detail underneath the land mass - look at all those points which are completely obscured by the pink land mass on top of it.

The second column, “Hidden sides simplified”, was an attempt to keep the in-game visuals identical looking but just remove some of these hidden points. You can see the result on the bottom image - there are definitely fewer nodes.

The third column, “Some sides removed”, shows a more aggressive optimisation technique. We actually removed some of the cliffs from the east side of the British isles. Obviously this doesn’t look as nice, but it did cut down on the number of points drastically.

The fourth column, “Subtracted”, was a quick experiment to show what happens when you simply subtract the land mass from the cliffs. You might think that this would be more efficient, but it actually resulted in the most number of points.

In practice we ended up using a combination of the method 2 and 3, depending on which type of landmass we were optimising. If we’re looking at Australia we can’t be too aggressive at removing the eastern coasts as you’d lose the illusion of depth when the camera zooms in close. If it’s a tiny island you can get away with removing more cliffs, as the viewer still catches the entire shape of the country in one glance and the illusion of depth is preserved.

The only other major concern with memory usage came when we tried to run the game on the lower-end Windows Phones. Those devices have a hard memory limit, and if you go above it then the game will crash. We ended up creating a special cut-down version of the world map (without shorelines and other erroneous detail) to work well on those low-end devices.

The final map ended up looking pretty nice, here are some shots of the full vector mesh:

…and some in-game screenshots too:

If you’ve enjoyed this blog post, please consider downloading Worldly and seeing the game in action! Here are the direct download links:

• iPhone/iPad
  
• Windows Phone 8
  
• BlackBerry
  

Thanks for reading!

This is part two of a blog post series about how we built the world map for geography quiz game Worldly. If you haven’t read part 1 then please check it out here.

I’d decided that we were going with vector art for the Worldly map (as opposed to bitmaps). The next phase was to build a basic map with the gameplay data in it. Making it stylish could wait - first of all the game needed to work in a prototype form. I started off by deciding on a mapping projection (of which there are many) and gathering some existing maps as reference. I ended up choosing a particular map for it’s aesthetics and clarity, as it was high resolution and detailed enough for my purposes. It also had a really nice shape to it - I’m less concerned with topographical accuracy at this point and more interested in readability and aesthetics. It needed to be familiar to people, as that’s the kind of projection which will be most suitable for a quiz game.

There was only one problem with the map I eventually chose: it was old. Really old. It was created when the Soviet Union was still up and running! Obviously the structure of the world’s countries borders has changed a lot since then, so I knew I had some work to do. The first big task was to fire up Photoshop and make a horrible zombie amalgamation of lots of different world maps, using my favourite Soviet map as a base. Accuracy was important at this phase; it took a long time to match up individual map positions and make it all fit together.

Once that was sorted, I began to “trace” the details of the maps into a new vector image. Everything was done by hand, and it took around two weeks for this basic landscape to come together. Every country was outlined individually, using as few points as possible to minimise the amount of strain on the poor little mobile processors which would eventually be tasked to render this thing.

It was important to make each country line up exactly with it’s neighbour (to avoid z-fighting in the final game), so I outlined neighbouring countries at a larger than real size and then subtracted them from their neighbours to get things perfect. This usually added several extra points to the map, so that required extra cleanup by hand. This was a very long process and I learned to be extremely patient!

Once the basic map was in place, it was time for software tests to get it in the game. I started off writing my own SVG importer and triangulation routines, and had some success in getting the countries to render as polygons. However, it looked like this would be a LOT of work. Luckily, I was able to license some existing software to do all the heavy lifting for me, meaning that a whole big chunk of the technology required for Worldly was already written. Awesome stuff. I spent a long time tweaking and testing this tech, but it more or less came together as I would have hoped.

Whilst I was playing around with code and getting things to render, my artists, Will and Ben, were concepting the visual style of the game. Given the vague brief of “it has to be ‘vectory’” and “needs to look different to everything else on the market”, the guys came up with some incredible work which is among some of the most distinctive I’ve seen recently.

We went from this incredible mood board…

…to some cool early designs for Sir Maxwell Worldly…

…to excellent menu designs (some of which were unfortunately cut from the final game)…

…and amazing map concepts…

…all of which looked great! Now it came down to me to get the in-game map looking like it did in the concept images. Aieeee!

Stay tuned for part 3: implementation and optimisation!

Hello everybody! I thought I’d write a quick blog post on one of the more interesting things I’ve worked on recently: the cool scrollable world map in my latest release: Worldly.

Worldly is an educational geography game where the player is guided around the globe by Sir Maxwell Worldly, explorer extraordinaire! The main play area of the game takes place on a stylised map of the world, and has the camera zooming into a particular part of the globe (i.e. France) and the player trying to correctly identify which part of the map they are looking at.

The concept of the game came from an idea of an expansion to Capitals Quizzer, another geography quiz game I built a few years ago now. Capitals Quizzer focused on the less tangible visual data (capital cities, currencies, flags), but I always wanted to build a game with a focus on the mapping side of things. When you’re looking at a map it’s much easier to get things across graphically, and it’s an entirely new area of geography which I hadn’t explored yet. Worldly was to be that game. If you haven’t tried it yet, you can download the game here.

So the world map was to be the main draw of the game. It would be the area you’d spend the most time looking at, and it was also the area of the game which I’d spend the most time working on. It had several interesting requirements:

• Lots of data! The map needed several “layers” which could be toggled on and off depending on the game mode. This meant that country borders, regional borders, city locations, seas and oceans, and others could be available to the game without having to reload a bunch of assets or process expensive amounts of data.
  
• Needed to zoom. The game camera would be zooming in and out as the user travels the globe with Maxwell Worldly. That means that the tech needed to go from a really, really zoomed out view (i.e. putting all of Russia on-screen), to a really, really zoomed in view (i.e. one individual city). Importantly, it had to do this smoothly and without different layers of detail jumping in at any point.
  
• Had to be stylised. I didn’t want to take an existing traditional map or satellite view, as Worldly was to be a fun and upbeat game. Boring static maps are pretty much the opposite of where I was hoping to take the game. I worked with an artist to build up a really interesting stylised look to the map, and we designed the rest of the game to fit that interesting colour palette too.
  

So before the project even started there was quite a strict set of guidelines which needed to be adhered to. I knew I would have to explore several different methods of map rendering before I found the one which would work. The first to try was a tiled bitmap approach, like (the old style) Google Maps. This basically involves getting a whole bunch of square tiles, and drawing them side-by-side to form a map. When you zoom in the system will subdivide these tiles into smaller, higher resolution versions which are then streamed in.

One big advantage of this system are that you can have different graphics to represent different levels of detail. So as you zoom in, suddenly roads and forests and other detail will appear. When you zoom out the system swaps in more simplified graphics to make everything more readable. The downside of a system like this is that you need a lot of tiles (growing the size of a downloadable app in terms of disk space), and you need to carefully manage how you load those tiles into memory. If you don’t pre-load enough data then there will be pauses as the system catches up. If you load too much then you’ll run out of memory and everything will explode. This was a particular worry with Worldly as we’re targeting several different mobile platforms that have varied (and transient) memory limits.

It was for these reasons that I ended up throwing away the bitmap approach, and looking at vectors. Vectors are mathematically representations of lines and shapes, and are made up of points and handles rather than lots of little pixels (like bitmaps). For Worldly, using vectors would have several advantages. Firstly, vector graphics remain sharp, even when zooming in and out at extreme sizes. This would mean that I could load a single map file into memory, and then not have to worry about loading additional data as the game was being played. Also, vector files are smaller (in terms of storage space) than bitmaps, so the downloadable file size would be more manageable.

Choosing vectors meant that we were under quite a few limitations in terms of art. Firstly, there couldn’t be too much detail. Rendering vectors is quite heavy on processing, so the simpler our map the better. Secondly, we couldn’t really use much in the way of textures. Things were (more or less) going to be drawn as flat colours. This influenced our colour palette and the overall style of the game. However, despite these limitations it was clear that using vectors was the way to go for Worldly!

Coming up in the second part of this blog post: how we designed and built the world map, and then implemented it in the game.

Hi everybody! It’s been a little while since I last wrote a blog post, so I thought I’d ease back into it with a stats post. It’s a bit self-indulgent, but I hope you’ll find it interesting.

I started my own video games company, Supergonk, back in 2011. Supergonk primarily makes mobile games, and the company consists of, well, me. I work with some really talented contractors every so often, and those guys handle the things I can’t do very well, like art and audio. Apart from that, I handle everything else (coding, design, biz, publishing, etc.)

I’ve published a whole bunch of games now, some quite basic and suited to mobile (Capitals Quizzer), and some which are much more traditionally gamey (Safe Cracker). These games have launched on 5 platforms so far; both mobile and desktop. I still find this pretty mad, as less than 3 years ago I had barely written any C++ at all. Fast forward to now, and I’m actually verging on being an almost competent programmer! (almost)

Learning how to actually code to a decent level was a pretty massive change in my life. Prior to creating Supergonk, I worked in a PR role in a console studio (no programming). Whilst it’s true that I’ve got a technical background (in web development and hobbyist game dev), I had never worked as a programmer before. The closest I came was secretly helping to port a copy of Geometry Wars to the Nintendo DS whilst working at Bizarre Creations, which (in a roundabout way) eventually led to the release of Geometry Wars: Galaxies on Wii and NDS.

Anyway, learning to program properly was a big deal for me. After that, the next biggest thing to learn was how the mobile games industry worked. More specifically, it was learning how to release “little and often". I had come from the console world, where we worked away for 2 or 3 or 4 years on a game before finally submitting it at the end of the process and starting all over again. Mobile is completely different - you’re encouraged to release new versions (as updates) frequently. This is a huge change in mindset, as you basically want to keep the game always playable, and only make incremental changes as you go.

This morning I counted up how many times I have actually released a binary (i.e. a new version of a game). If you look at all the games across all platforms, the number is 237! That’s two-hundred-and-thirty-seven times I’ve tested, packaged and released a game since Supergonk was started. On average that is roughly 5 and a half releases every single month!! Out of those 237 releases, 166 were required to pass some kind of certification process before being released. I haven’t counted the number of times I’ve failed cert either, as I prefer not to think about that. :-)

The breakdown of released versions by platform is as follows:

• iOS App Store: 97
• Mac App Store: 19
• Google Play: 71
• Amazon App Store: 15
• Windows Phone 8: 1
• BlackBerry World: 22
• Samsung Apps: 12

The next thing I looked at is how many times those apps have been downloaded from each of those app stores. Unfortunately I can’t break down the individual App Stores numbers for this article as this data can’t be published online (it breaks the T&Cs of the individual stores). Generally though, if you add all the platforms together, you get over 5.5 million downloads in about 3 years, which is pretty incredible considering it’s basically just me making this stuff. I won’t share sales data in this post, but let’s say it’s in the realms of a small business. Supergonk can pay for itself pretty comfortably, but it’s not a money-printing machine or anything like that. I’d like to grow the business and hire some more people, but it’s still quite a scary financial proposition at the moment. As such, I’m spending a lot of time right now trying to improve that profitability so I can grow the team. What that means in real terms is in-app updates (especially to Capitals), and putting my games out on desktop platforms (Safe Cracker on Windows, I’m looking at you).

Anyway, I hope you’ve enjoyed this blog post. It’s interesting to talk about these numbers, and fun to compare my game’s performance against each other. I’ve dropped the full data below; hit me up on LinkedIn if you want to discuss further. Thanks for reading!

This is part two of a blog post series on creating the mobile game Safe Cracker. If you haven’t read part one, you can do so here.

The team was working to complete Safe Cracker throughout November and December. We had no real release strategy initially - we just worked on it as quickly as we could. We knew the quality bar we wanted to hit, so it became an intense slog to get the game where it needed to be. As things came together, I came to realise that launching before Christmas had suddenly became achievable.

Every year Apple shutdown the developer publishing tool, iTunesConnect, for the holidays. Even the brilliant people at Apple can’t work every single day of the year! The company is very good at messaging the dates of this shutdown to devs ahead of time, so we suddenly had a deadline. If we wanted Safe Cracker to launch in time for Christmas then we NEEDED to meet that date. We killed ourselves to get the game done before iTunes Connect holiday shutdown.

As the deadline drew closer I began to slightly panic that things wouldn’t be done in time. I had been slack in getting a decent brief to our composer, and as such he was suffering the knock-on and the work was coming in hot. It was time to make contingency plans. I actually submitted a version of the game with slightly unpolished SFX in order to hit the deadline. I knew that it could take a couple of weeks to pass through submission, so this build would be our backup if things didn’t come together in time. Fortunately, this build was approved by Apple and held offline as our backup. At least we had something to release for Christmas now, even if we couldn’t pull the final SFX together in time.

I’m incredibly fortunate in the people I work with. Neil, the Safe Cracker Audio Designer, is not a man to miss an opportunity. I had left him in a bad situation by not providing enough time and information, but he didn’t let this beat him. Poor Neil pulled out all the stops and stayed up crazy late for several nights in a row to work on the game’s sound effects! We worked together to finish the game, and were able to submit the proper version to iTunesConnect in time to be approved before shutdown. Woo!!

Even though the game was finished and approved, the work of an independent developer is never done. In the old days when I worked in console development the studio would celebrate and we would all have a few weeks off to recuperate. Not so when you’re also responsible for the publishing side of things! I went straight into building a press release to announce the game, and also pull together the release assets: screenshots, gameplay breakdown document, video trailer, etc. A note for other devs who might be reading: don’t underestimate now long this can take. It’s a major undertaking which can be just as difficult as mastering a game!

Once the assets were created, I paid for a press release service to supplement my own mail blast to my existing PR list. I don’t think the paid-for service was massively worth it and I’m not going to bother using them again, but it was an interesting experiment. I then leaned on contacts in specialist press for coverage, calling in as many favours as I could. Unfortunately, if I’m honest, it didn’t work very well; I think industry has changed a lot since my days of AAA. Either Safe Cracker didn’t appeal to the (hardcore) specialist press en-masse, or there has been a big change in how games press cover mobile games. I suspect it’s a bit of both.

Not to be deterred, I hassled Apple with information about the game. It took several attempts to get through to my contacts at Apple, but eventually I was able to chat to them directly and explain why Safe Cracker was worthy of their attention. Their internal teams reviewed the game, and eventually it was featured in the “Best New Games” category over Christmas. This was a fantastic achievement, and something that I’m really proud of.

I’m a little surprised that the specialist press were so unreceptive to the game, but I think it’s indicative of a growing negative attitude toward mobile in general from those guys. That said, it didn’t make a big difference for Safe Cracker. The Apple feature spot more than made up for the snub, and to be honest it has made me re-evaluate my marketing priorities for the future. The world is changing, and it pays to stay impartial and go with the tide on things like this.

I worked over Christmas to create the game’s first level pack, released in mid January. It actually doubled the size of the game, with another 64 levels. I was able to build all the new levels and associated mechanics inside of two weeks, which was a bit mental to say the least. I also took the chance to localise the game into several new languages, including Mandarin Chinese. Over the next few weeks the Android version launched with mixed results, but that’s for another blog post…

Safe Cracker was downloaded over 350,000 times in it’s first month. It was also played over 1,000,000 times in that period. It’s stats for number of sessions per user and session length all break industry averages. Since then the game has broken one million downloads overall across all platforms, and has been the fastest growing game I’ve built so far. Usually I find myself being hyper critical of the games I build, only seeing the faults. However, I’m really proud of Safe Cracker. I think it achieved most of the things I set out to do, and it’s performance has been decent.

In the months since Safe Cracker launched I’ve been pulled onto another urgent project; a geography quiz title called Worldly. However, that game is now pretty much finished, so I’m really looking forward to getting back to Safe Cracker. It’ll be nice to optimise the game, bring it to new platforms, and perhaps even grow the game in unexpected ways. Thanks for reading this post, and if you haven’t tried Safe Cracker yet then you can download it from here.

If you’re a regular reader of my blog, you’ll know that I’ve been working on a physics puzzle game for the past few months. That game is called Safe Cracker, and it was released on iOS just before Christmas. It’s rolling out to Android as I write this, and other platforms are planned too. So far it has been played over 2 million times, which I’m pretty happy with considering it has been available for only about 2 months.

The development process of Safe Cracker was long and fragmented. It actually started as a demo written by myself and a friend. We wrote it to learn the game development platform Unity; we didn’t intend on making a proper game for commercial release! However, as the ideas came together it became obvious that the game design was a good one, so we continued to work on it. You can read about this early development time in a couple of blog posts here and here.

The game was built in several stages: the initial prototype, a longer, more intense second phase, and then the longest and most difficult final push.

1. Prototype phase

The prototype was built over the course of a few weekends in Portsmouth. The two of us built the game in several hack-a-thon sessions, fuelled mainly by beer and pizza. Safe Cracker was originally conceived as a version of Peggle which could be rotated 360 degrees. We quickly realised the similarities between rotating the level and spinning the lock on a bank vault, and the rest of the theming really wrote itself.

The first versions were grey and industrial in appearance. Our first concept was heavy metal, with yellow/black hazard lines and brushed metal everything. It looked pretty nice as a style, but I’m extremely glad we evolved into the more colourful design later on. 

In terms of gameplay, the first version was basic: you’d spin the level and control the path of a ball as it bounced around inside. The aim is to collide the ball with various switches around the level, activating them. Originally the plan was for the player to activate the switches as fast as they could, beating a level timer which we set for each level. However, this felt quite dry and not as deep as we’d like. During the prototype I added “star switches”: special switches which had to be activated in a certain time before they expired. This was great as it allowed us to implement the timer in a more interesting way, as well as rate the player’s performance at the end (did they get all three stars?). It also had a great effect on the players intentions as they play the game - most people beeline for the stars and work out the most efficient route between them.

Actually the prototype stars were slightly different to the final game. Initially each star had it’s own timer, so you’d have to get the first star within a certain time and then the second would become available. It was too complex, so I ended up simplifying it down to one timer for all three stars. This not only made the UI and mechanics simpler, but also gave the player more choice about how they wished to complete the level rather than the designer imposing it onto them from above. More strategies is always a good thing. 

After building the prototype there was some disruption in our personal lives, so we basically did nothing on Safe Cracker for several months. It became clear that my partner couldn’t continue to work on the game (he emigrated!), so I made plans to finish the game on my own.

2. Second development phase

The second stage of development was about a month long, and was basically just me hacking about on the thing. I build a new UI system, finished off the 64 levels to final quality, built multiple game modes (standard and time attack), power ups, achievements and leaderboards, etc. etc. I also decided that the game should be freemium, so I spent a while integrating in-app purchases and advertisements. Finally, I spent an awfully long time tweaking the physics and controls until it felt perfect. That actually meant adding several control schemes, but I’m largely happy with how it turned out. 

It was an incredibly productive time. That said, I did lose some time due to not knowing Unity well enough. I’d write a system, then go back and rewrite parts of it several times to be more efficient. Nowadays I know the best way to approach things, but back then I was still new to it all.

3. The long final push

I knew that the game still looked a bit shoddy. The brushed metal artwork wasn’t particularly attractive, and didn’t appeal to a mass-market audience. I brought an excellent artist on board (one of the chaps I had previously worked with on Tiny Invaders) and he immediately improved the game 1000%. He introduced the characters of the thief and Nano, and stylised the whole game as a steampunk kind of fantasy world. The artist and I worked together intensively for several months to polish Safe Cracker to a very high level, and both of us killed ourselves to make the game as great as we could.

We also bought in an excellent composer, again the same guy I had worked with on Tiny Invaders. The composer created an absolutely incredible musical score for the game. However, I knew this guy was excellent and I wanted to push him further. I asked him to create all the sound effects for the game as well; an area he had never worked in before. As I expected, he knocked it out of the park with amazing voices for both characters, as well as suitable ambient noises. It pays to have a single person controlling the entire audio scape, and I’m glad that we were able to push for this. 

Eventually the entire game was finished, and we launched just in time for Christmas.  Look out for the next part of this blog post: the release strategy. 

Supergonk is the name of the company I publish my games through. So far it has largely just been an empty container; I’ve preferred to let the games themselves do the talking. You could be the biggest fan of Capitals Quizzer (my flagship game), and likely have never even heard of Supergonk. This was all by design - I didn’t want the company to be the focus of my first range of mobile games. It was all about the games.

As the business has grown, the need for a more well-defined company profile has arisen. This is largely because I’m dealing with many partners across the world, and it’s a good idea to project a positive image when interacting with new people. It’s also where customers look to when they need tech support, so it’s important that the company looks the part to the general public.

This week I decided to rebrand Supergonk, and actually turn it into something I didn’t mind talking about as a separate entity from the games. As such, I present the new Supergonk logo:

The logo is designed to be simple and flexible. You can put it on any coloured background, in most situations, and it’ll still look ok. This is important, as I’ve got a couple of games in the pipeline which are very different from Supergonk’s existing portfolio. It was vital to me that the logo was able to adapt to a variety of artistic styles.

There’s also a new Supergonk website. You can see it at www.supergonk.co.uk. I’ve included product information and FAQs on each of the pages in an effort to help gamers out before they email for help. If their question can be answered without having to go to the trouble of drafting an email then all the better. There are also more obvious links to download the games, which I hope will improve conversions.

I’d love to know what you think of this redesign. Thanks for reading!