Monday, 28 July 2014

Coolant Crisis - From agile teamwork to lone-wolf game development

TL;DR: Made a game. On my own. Here it is

My day-job is developing web applications, usually as part of a team. I've done it for a while. Long enough to notice that the project or company may change, but the work is often the same. I challenged myself to do something different. I made a game. For mobiles. Entirely on my own. Here's what happened.

The Challenge

I'd never made a mobile game before. I didn't want it to show. I challenged myself to make something that was:
  1. Not a direct clone of another idea.
  2. A decent piece of engineering that doesn't look like "my first game."
  3. Enjoyable by people people who are not my friends.
Hoping to emulate the great tradition of classic games created entirely by one person I opted to do absolutely everything myself - with all the freedoms and restrictions that entails.

The Game

I needed ideas. I wrote some down. They were mostly puzzlers like the ones I enjoyed as a kid. My favourite idea was titled "Space Junk". In charge of a giant space magnet, you'd suck up pieces of flying flotsam before they'd burn up in the atmosphere. When three-of-a-kind match they'd disappear.

I gave a quick-and-dirty version to my sister to test. Pieces of flotsam fell from the top, the magnet grabbed them at the bottom. My sister practically cried with boredom.

It is quite easy to come up with an idea; it's hard to make one that's fun.

The game was dull because there was no drama. It was just a chore. I changed the junk into nuclear fuel rods, which explode when left outside of a coolant tank - which slowly leaks. Coolant Crisis! was born!

With an idea in my head, I moved on to the design..

The Design

..That's a lie actually. Like most programmers I jumped in to the code, then reworked everything several times. Working in a team, somebody would probably have nailed all the designs and UX first. Let's pretend I did..

Making something that looked "proper" required a lot of time. My first version was definitively 8-bit, but the nuclear connection drew me toward the Cold War, the 1960s, and something more analogue.

I put on my designer hat and sat down for the first of several long nights with Photoshop.

The evolution of the game graphics - the initial concept, the first version and the reworked current version. 

The Code

Although I said I'd do everything myself, I didn't include building my own mobile phone with home-made transistors and a USB wind farm. By the same token I opted for a good game framework..

I settled quickly on LibGDX, and I'm glad I did. The game is written in Java from whence it can be made to run on Android, Desktop, and can also be coerced onto iOS and Javascript.

LibGDX handles many of the scenarios that a novice mobile developer wouldn't think of - such as pausing the game when a phone call is received. You can build a simple game within a couple of hours.

There are a few differences for a web developer embarking on game development. It is hard to implement a model-view pattern. Instead it's more typical to work with independent actors that have their own act() and draw() methods, which slot nicely into LibGDX's scene graph.

As a web developer, there's usually little concern about perturbing memory, either on the server or client. However, to keep a game running smoothly, you need to keep the memory stable - avoiding new instances in the render loop, and relying on object pools, or (gasp!) reusable static members.

You also have to learn that unlike the browser environment, OpenGL gives you very few visuals for free (except for that ubiquitous teapot) - everything else you have to make yourself. For the most part in a 2D game it is just a case of placing bitmaps on a screen. The water needed a custom OpenGL shader. Other effects; explosions and bubbles were produced with LibGDX's particle system.

Developing the essence of the game didn't take very long and I won't dwell on it here. I created a simple model to manage the pile of blocks, created my "actors" - blocks, water, explosion effects, and they came together relatively quickly. But the game wasn't finished..

The Screens

There's a surprising amount of work to be done on all those other screens that I never thought much about as a player. Depending on the game, you might need quite a few. Apart from the mandatory menu screen, there's a level chooser, game won and lost screens, as well as an instruction manual. Subsequently there are screens for settings, stats, sharing on social media, rating the app, and so forth. 

All these screens are largely bespoke; with few exceptions games seldom use standard UI widgets, which brutally break that sense of fiction that players enjoy. For a web developer, it is a bit of a culture shock to find yourself without CSS, or even any usable fonts. However, such a blank slate almost demands you to come up with something different, which was kind of exciting.

Here's the result of many hours spent trawling the web for inspiration, toiling in Photoshop, then finally coding. It was a lot of work:

There is a lot of work beyond the actual game screen. The buttons and controls are very loosely based on the IBM 1401 Digital Computer, first produced in 1959.  The headings are based on Dymo embossed labels.

The Testing

A few friends tested an alpha version and gave me tons of feedback.

Whereas a web programmer usually deals with nice snapshots of data at given instants, the time element inherent in animation creates many transient bugs. What happens when other blocks are falling or in the process of being destroyed? Although the total development to that point had taken about a month of evenings, it was easily another month before I was confident that everything had been fixed.

While my testers tested, I spent many enjoyable hours in GarageBand, preparing some theme music for the game.

When a friend of mine told me that he had been playing Coolant Crisis! into the night I knew that something was going right. Time for a production release!

The First 100 Users

I built it. They didn't come.
From this point on, things became less easy. The era of "build it and they shall come" - if that ever existed - certainly didn't apply. The Google Play store currently hosts about 1.3 million apps. My little app became the newest fish in a very big sea.

Usually distribution is very much somebody else's problem. In this case, it was still all up to me.

I checked to see how my game ranked for certain searches. It was disheartening. It sucked. I wrote a good description, but came nowhere near the top 100 for the majority of queries I imagined players might request. Coolant Crisis! even ranked #15 in a search for its own name.

It came as no surprise then that organic growth did not materialise. I decided to jump-start the game with some paid promotion. I used AppBrain's pay-per-install advertising service and got a hundred users playing the game within a few days. But there was a problem...

The UX Fail

.. there was a discrepancy between my loyal testers - who played to the end - and my unknown installers  - who typically didn't get past the first level.

But why couldn't they pass Level 1 when it was so easy? Loyalty aside, my hunch was that they didn't understand the controls - which required double tapping. I had already unconsciously acknowledged the problem; the manual explained double tapping IN CAPS. Explaining why a message needed caps in an developer planning meeting would probably have resulted in a change of heart much sooner..

I remember the good days, when the games I bought came in a box, often with a manual, which I would read on the way home.  Those days have passed - certainly for mobile apps. There is no interval between the shop and powering up the PC at home - the app is in your hands in seconds. People don't spend time reading your words.

I tried everything I could to make double-tapping ever more obvious. I made the user manual interactive, then added custom help message if no double-taps were detected. It didn't make any difference.

I realised why a bunch of mobile games use clunky up-down-left-right buttons - there's no room for doubt.

In the end I did the sensible thing and changed the control method completely. I eliminated double taps and added little markers indicating where blocks could be placed. People started to play past the first level.

As to how things will pan out now, it's too early to tell. A trickle of people are finding the game, and it has been played in unlikely places all around the world. I'm into marketing now, and it's an eye opener. In a couple of months I will post an update on what happened next in the life of Coolant Crisis.

The End?

There is something great about having created a finished product from scratch, even better one that you can hold in your hands (kinda) and has downloaded entirely out of your own brain.

Working in a team is usually great - and you can achieve so much more; yet there's supreme satisfaction in building something all of your own. There's lots to do; a solo indie developer has to wear a lot of different hats - designer, programmer, tester, composer, marketer, trilby. I learned a lot.

But is it finished? A personal labour of love is difficult to let go. Especially when there are so many parts that aren't perfect. Maybe in a few months I'll have a new obsession, but for now I've got some new ideas to try out.

So did I meet any of my objectives? Judge for yourself:
Click here to download Coolant Crisis from the Google Play Store

1 comment:

  1. Interesting post! I had pretty much the same experiences with my libGDX game "True Fool Durak". Especially the part of it taking one additional month to fix all the remaining kinks that one can probably only find with a more than a handful of testers. And the part about controls that are clear to yourself but not to others. I had like five different UI variations until my beta testers found the UI to be clear. The part about marketing being hard, particularly if you have to do it yourself, also rings true :P.

    If you plan to write another blog post about your game I'd be interested in your experiences with the intertistials.

    As a remark, I noticed in the screenshots and on my tablet that the font is a bit blurry and has some minor visual glitches. I hade a similar problem in my game. I suppose you use a viewport. In the beginning I initialized my viewport like so: ExtendViewport(640f, 480f, cam). Then I simply doubled the resolution to ExtendViewport(1280f, 960f, cam). I had to double all my assets in size of course. In any case, the font become much sharper and lost its visual glitches. Also, setting filterMin: MipMapLinearLinear can improve the font rendering but at the cost of slightly worse performance on smaller devices.