Create the ultimate war machine in Battle Cruisers, an upcoming 2D real-time strategy game for Android, iOS and Windows. A distinctive, stylish game with a diabolical AI. Build your defences against enemy frigates and bombers. Reinforce your ship with shields and boosters. Out-maneuver your enemy with fighters and gunships. Launch a counter attack with artillery and hey, why not a nuke? When the sea levels rise, the world divides. People live on floating cities, fighting for precious land and waging war with immense floating fortresses: the Battle Cruisers.
By Felix Mann, age 27 and a half
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
In hindsight I think it was worth it, but it’s feature creep like this has endlessly pushed out our game release date.
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.
Big Manly Studios is located on Big Manly Beach, New Zealand. We are not a big company, nor a particularly manly company, but our previous name was already...