Indie Post Mortem - Captain Kaon – Part One

Gather round and let me tell you the tale of how I quit my QA job of 12 years to make an indie game all by myself, because I’m slightly mad, or stupid….probably both.

In some ways Captain Kaon has been a fantastic success, I set out to make a game of my own and I actually finished it. Making games is all I’ve wanted to do since I was 8, making my own game has always been the dream, one that’d I’d started to think I would never achieve. Now I’ve done it, I’ve actually bloody done it.

But it was only a limited success. Reviews have been mixed, I got a couple of sevens, which is great for a first game. But I also got some low scores from people who just didn’t like it. On top of this the sales have been poor. However, with all of life’s setbacks, as long as you learn things along the way you’ll have a better chance of success next time.

I tried to keep this short, which hasn’t really worked out, it’s hard to distil four years down into one blog post. In part one of my post mortem I’m going to talk about the development of Captain Kaon, the highs and lows of making the game itself.

Project Choice and Approach

What went well.

There’s a style of shooter that I played when I was a kid that had a tilt and thrust flight mechanic. It started out with Gravitar and Thrust in the ‘80’s but the version I really enjoyed was Gravity Force 2 on the Amiga. My original plan was to make a mobile app so you could sit down with your mates and shoot each other. This then evolved into a single player game with a series of missions. Because it was a game that I loved as a kid, I was passionate and enthusiastic about working on it, I had lots of drive to get it done.

I also chose to do this type of game because it had a relatively small scope and fitted easily into my skillset. I didn’t want to spend a long time on my first project, I wanted to focus on getting through all the steps involved and essentially use it as a learning experience that I could build on. There wouldn’t any characters that needed drawing and animating, it was just spaceships shooting each other and mechanical objects. This was a fairly sensible beginning.

What didn’t.

The game started out small and grew organically, as I had cool new ideas I would throw each of them in. But this meant I didn’t have an organised plan of where I was going with the game. As it grew in size, so did the scope. Before long my 6-12 month project had been going for 2 years and I was still a long way off finishing it. By not having a plan and creating the game organically it meant development was nebulous and I underestimated just how long it would take. In the end Captain Kaon took 4 years and most of my money. It was not the quick first project I had envisioned.

But it wasn’t just time that was a problem. In the end I had chosen my project poorly. It has been very difficult generating interest in a Thrust re-make, most people just don’t remember it. With some people it would remind them of another game, like Jetman or Scramble. I thought the lack of other tilt/thrust games was a gap in the market, in fact it was a lack of interest. Every few years someone makes a tilt and thrust style game, but they general don’t sell well. Had I done some basic research to begin with I would have realised I had made a mistake. By the time I got around to doing this I was too far along to stop.

Lessons learnt

For my next project I need to make sure I’m starting with a solid concept that has appeal. This is easy enough to do. I’ve been speaking with friends and former industry colleagues about my new ideas and gauging their reactions. This has really helped me narrow them down to one cool idea that I know will jump out at people. I’ve already started on the prototype, and this time I’m really confident it can be a success.

Gameplay

What went well

I managed to do a really good job of recreating the basic tilt and thrust gameplay of old, and even had a few cool ideas to modernise it. I changed the gun from a fixed forward fire to a turret, this way you can manoeuvre the gunship into a hover and use it as a firing platform, you wouldn’t have to tilt towards the ground to shoot something. However the basic second-to-second gameplay can still be tricky, you have to split your attention between maintaining a stable flight and shooting your enemies. This means keeping one eye on your ship and the other looking around for threats.  When I was at Rezzed I was able to get some first-hand feedback from players, several described the game as being like patting your head and rubbing your belly at the same time.

The game was challenging, but a little too challenging, so I made a few changes to help make it more accessible. I added an air brake and snuck in a subtle bit of flight assist that varies the turn speed so that it will turn towards up faster and is then slower turning away from up. This made the gunship easier to fly and you were less likely to crash. I also gave the player the ability to dodge sideways and avoid incoming fire. So far this seems to have made the game more fun.

This was also the first time I’ve ever created a proper game Ai. Previously I had only made simple bad guys that would move back and forth, nothing with a state machine in or anything like that. I went through seven different versions until I arrived at the release version. This was a lot of work and head scratching, but it’s a great stepping stone for future projects.

What didn’t

Ultimately my Ai wasn’t good enough and didn’t fit in with the level design. This problem ties back in to the organic way the game was made and the lack of a structured plan. Good Ai is one of the core ways in which a game is fun. If you balance it in the right way you provide and opponent that is interesting, challenging, and ultimately fun.

I wanted an Ai that would flank the player, but I’d already designed the levels and they didn’t have the routes to allow this. I was able to go back and make some changes to the level design, but I don’t think it was enough. There’s only so much you can do when you go back and modify something.

I had the Ai signal each other when they spotted the player, but this had the effect of them suddenly arriving as a swarm and hammering the player. I had wanted them to be aggressive and hunt down the player, it seemed to me that I had achieved this, but I ran out of time for a thorough playtest. The reviewed version was at best just decent and several reviewers complained about the Ai behaviour.

I also had a problem with the basic gameplay not being intuitive. Too many people expected to play it like a normal twin-stick shooter where you push the stick in the direction you want to go. Some people would adapt and figure out the tilt and thrust mechanics, others just kept crashing and would get frustrated. This can make the game a little polarising. I could have spotted this earlier with better playtesting.

For a long time I had kept a version on my phone so I always had it with me. Whenever I was talking to someone about the game I could pull it out and show people, it was great for getting feedback but didn’t give me a full playtest. When I decided not to release on android I stopped updating it, by this stage I was also pretty clear on what I was doing and didn’t think I needed it. This wasn’t enough playtesting, I should have bribed some friends with an evening of beer and pizza to get some solid playtesting done. Part of the reason why I hadn’t done this was because I went with the idea that if I liked playing the game, so would other people. This idea is dangerously naïve, lots of people like niche things that most other people don’t.

It wasn’t just the second-to-second gameplay that had problems, but the minute-to-minute level design. I had some good levels in the game, but the overall quality is inconsistent. Some of the levels could be a bit of a chore, I’ve had to do a lot of post-release work getting these levels better. I’d tried to create plenty of variation in the things you had to do to complete a mission, but some of my design decisions weren’t great. I stuck with the original Thrust concept of picking things up and carrying them around, but in some places I don’t think I’ve used it effectively. There are places where you have to pick up energy units and drop them on things to power them, this is ok. But there are places where you have to find things, pick them up, and bring them back to your base. This could be a bit too much back tracking and was made worse by the weight of the object slowing you down.

Beyond the missions themselves there is the campaign that provides the hour-to-hour gameplay. When I was trying to figure out how to insert the ship and weapon unlocks into a linear series of levels I struck upon the idea of having the levels assigned to regions in a campaign. This would essentially work the same way as the campaign in the original Syndicate, complete the mission and unlock the region. Each region would be worth resources and each mission would cost resources to attempt. It seemed like a good idea at the time and whilst the campaign mode I made isn’t bad, it’s a bit shallow. Essentially there is a step missing. You win the mission and get resources, you spend the resources attempting another mission. It’s like a fruit machine, money goes in, money comes out. It should have been set up so that you spend resources on ships and weapons and then use these ships and weapons on the missions to gain more resources. This would have been a more interesting way of handling the campaign, and if I can find the time/money I may go back and attempt this as a version 1.1.

Lessons Learnt

I need to actually plan and think about my gameplay more from the start, if the basic gameplay doesn’t look good on paper, it probably won’t be once I’ve made it into a game. I need to make sure I have a clear idea of how the gameplay will be compelling and I also need to avoid chucking in shallow features late on.

On future games I’m not going to rely on whether or not I enjoy a game, I’m going to drag as many friends as I can in front of it so that I can get it playtested.

Art

What went well

For the art I went back to the pixel art I used to do on my Amiga as a kid, and I managed to do a pretty good job of nailing this style. When I took the game to Rezzed there were several people who commented on it reminding them of Amiga games.

I also had the opportunity to learn how to animate using a bone animation system, which was a great new skill for me to learn. I used the Gamemaker engine which has incorporated the Spine animation system. I was able to add lots of cool features with a greatly reduced art overhead. At the time I switched over I had been trying to create a robot that would walk along on two legs, I’d spent two weeks drawing sprites over and again just trying to get a good walk animation. Once I switched to Spine I had a much better animation and it only took a couple of hours.

Inevitably there were times when I needed art I wasn’t capable of, usually I was able to find a way around this. But in the end I needed a really cool piece of PR/cover art and everything I tried to do myself was terrible. For this I found a freelancer and she did an awesome piece of art. This art work has been useful in a number of places where I needed something special, and it was especially useful when I went to Rezzed. I printed it on the back of some T-Shirts and on some badges that I gave away.

What didn’t

Whilst my pixel art was good, it wasn’t great. Perhaps I’m a little out of practice after 20 years, or perhaps I was never that good to begin with. With the modern colour palette I made art that is far more vibrant than it could have looked on the original system and this has led to screens that are just too busy. There’s so much going on visually that it can overload your eyeballs.

I think part of the problem is that each element was created in isolation, drawn in Photoshop on its own. When looked at this way, each object could seem quite bare. I always felt the need to cram in lots of detail. I should have looked at them more once they were in-game and considered them as part of the whole. I think this was a problem caused by my lack of any formal art training, I’ve learnt this as I went along, instead of learning things the right way.

I’ve also recently realised that I made a mistake with my gunships. I drew them similar to the original Thrust gunship, which was a triangle, but with added detail. The problem is they look too ‘top down’ and this doesn’t communicate the gameplay well, it confuses it. The tilt and thrust gameplay is side on and the art needs to communicate this. Oddly, when I drew the sprites for the Ai, they were all side on. I realised it was different and inconstant but for some reason the light bulb in my head didn’t go off. Instead of thinking about the gameplay and making something right I was too fixated on reproducing Thrust.

Lessons Learnt

It seems obvious to say that it’s important to communicate the rules of your gameplay with your art, it’s not so much of a lesson as a ‘well duh’. But I knew that I should do this and still managed to overlook it. By making this mistake I will be more alive to it in the future, instead of my art being something that is attached to a game object it’s going to be something through which the game object communicates with the player.

I’ve also got to improve my basic art skills, especially in the area of lighting and colour schemes. This is going to be tricky, I have several books for learning art, but learning from a book is not the most effective way to do something. Ideally I would find a course, but at the moment I have neither the time nor the money.

Conclusion

My worst case scenario has always been the achievement of making the game. This is something I’ve wanted to do since I was a kid and by this standard I’m calling Captain Kaon a success. In time the sales may pick up and I might get enough of an income from it that I can do another game. But in the meantime I have plenty of lessons I can carry forward and I’ve become a much better developer after working on this project.