Battlecruisers is a small 2D RTS game made with Unity that we (Peter and I) hope to release on IPad, Android and PC.  We have worked on Battlecruisers part-time for three and a half years, and hope to release it this year. This is the pre-release post mortem about what went well and some of the challenges we faced.

How it all started

Three and a half years ago my mate Peter mentioned this game idea he’d been playing with, but it wasn’t going anywhere because he needed a dev.  Like most devs I’d always dreamed about making a game, and so Peter found his dev.

What went well

1. Dev Designer Combo

Like most devs I’m not the best at artwork.  Having a designer to fine tune UIs, add effects and provide music is amazing.  Having a dev and a designer is infinitely better (fact) than having two devs or two designers.  Take an early version of the loadout screen before Peter had any input:

And a more recent version after Peter’s magic:

Yes I would have cleaned up my early version, but there is no way I would have gotten anywhere near to what Peter was able to accomplish.

2. Realistic Expectations

One of the first things I did was look at indie game post mortems to try and learn from others.  I looked at 33 post mortems and quickly realised a few things:

Games take a long time to make

13 of the 33 post mortems gave the advice of limiting scope.  Some of these devs had been working on games for 5 years full time.  For many devs this was the first game they’d managed to complete, with many previous incomplete attempts.  So we aimed at making a small game, that would take a year, perhaps two (and here we are, three and a half years later).

Games don’t make money

Or at least, 99% of games aren’t profitable.  From the 33 post mortems I read, I think only one was wildly successful (Super Meat Boy).  A few sounded like they perhaps broke even or made a bit of money, but the vast majority simply lost money. Putting in up to five years of full time work and having no money to show for it was understandably soul destroying for many of these devs.  Hence we decided to not expect to make any money, and not quit our jobs to work on the game full time.  This meant there was no pressure to make any money, and we could simply make a game we’re proud of.

3. User testing

The most repeated piece of advice from the aforementioned post mortems (13 of 33) was extensive user testing with real users.  So that’s what we did.  Grab a friend, force them to play the game and see where they struggle.

Watching a real user test is so much better than having a friend try the game by themselves and give you feedback afterwards.  Many opportunities for improvement they don’t even notice!  As an example, we used to have this fantastic custom navigation wheel control, that lets you navigate around the screen beautifully.  Peter designed it, I spent weeks implementing it, and both Peter and I used it heavily when playing the game.  But we noticed that real users never used it, despite it being shoved down their throats in the tutorial.  Real users would fall back to pinch zooming and swiping (which we’d added from earlier user feedback), like they’ve been taught by the touchscreen world.  So we got rid of our navigation control.

4. Unit testing and test scenes

A challenge of any coding project is ensuring you don’t break things.  One way for this is to just play the game, and see if everything works.  However, this is time consuming and only checks what you played.  Perhaps you’ve introduced a whole heap of bugs that you didn’t cover in your playtest.

Instead we have 1350 unit tests and over 200 test scenes.  The unit tests cover code correctness, but don’t cover a lot of Unity related and visual aspects.  That’s where the 200 test scenes come in.  Each test scene tests one particular thing, be it aircraft patrol movement or the artillery barrel firing.  Every so often I go through every single test scene to check if everything still works.  This way I cover all aspects of the game, instead of just what my random playtest happens to cover.

Challenges

1. Working remote and babies

I live in the US whereas Peter lives in New Zealand, so all our communication is online. This makes collaborating a lot harder.  It would be so much easier to share ideas and avoid miscommunications if we were working in the same physical place.

Additionally Peter decided to have a baby putting him more or less out of the picture for 6 months.  This was hard for me and the game, as design work stalled.  (I guess the sleep deprivation was hard for Peter too, but as it was child number two he should have known better.)  I ended up working on coding tasks that were insignificant compared to the design tasks that needed to be done, demoralising me.  Eventually I stopped working on Battlecruisers altogether for a month or two.  But the baby started sleeping, so Peter started sleeping, so Peter could once again do design work, and the game was back on track.

2. Scope and the pain of cutting

We quickly realised that our little game was taking longer than we thought.  To have any chance of completing this game before our grandchildren were born we had to cut features.  Two of the biggest features we cut early on were multiplayer and a Borderlands style procedurally generated infinite loot system.  We knew these were the right logical decisions to make, but it’s still hard to cut your game down from the perfect idealistic dream you have in your head.

3. Feature Creep

This has really been a constant game (struggle) between Peter and myself.  On one end of the spectrum is Peter, an endlessly optimistic guy who wants to add every feature under the sun.  His advice to me as the dev is to just keep pressing the “Make it work” button until it works, easy.  On the other end of the spectrum is the dev, me, who just wants to get the game finished in our lifetimes.  

One example of this feature creep happened with our skies.  Our skies used to have:

1. Single orthographic camera
2. Sky background
3. Some clouds

And it looked half decent:

But one day Peter tells me:

“I read about this cool parallax thing that we have to add to add to our skies.  Here’s an article with the code, it’s really easy and will be really fast.”

So I give it a shot, and 3 months later we have our new skies (which to be fair are way cooler).  As well as our original 3 sky features we ended up adding:

4. A perspective camera for the parallax effect
5. 4 layers of mist
6. 1 layer of fog
7. A moon
8. The ability to change the colour of all clouds, mist and fog
9. The ability to change cloud height and orientation

In hindsight I think it was worth it, but it’s feature creep like this has endlessly pushed out our game release date.

Conclusion

I am so happy to be on this game making journey with my mate Peter.  Already Battlecruisers is my proudest accomplishment, ahead of my 6 year university degree and my Karate brown belt.  If you’ve always dreamed of making a game I would highly recommend you try, it is hugely rewarding.  Just keep your scope small and know in advance that you’ll be sacrificing a lot of (all) your free time for a long time.