Island Invasion – A Short Post-Mortem
Island Invasion has been out for two weeks now, and I have planned to do a bit of writing about the game’s development over the coming weeks. I always find it fascinating reading about the development of other indie games, and sharing this knowledge is vital amongst indies in my opinion.
I want to cover a few things:
- Some brief facts about the game
- How I settled on the concept and scope
- Lessons learnt from development
- What’s next
- Final thoughts
Some brief facts about the game
All facts accurate as of 22/12/2018
- Genre: Strategy
- Engine: Unity
- Platforms: PC (Steam)
- Development length: 7 months from start to release, working on the game part time, averaging 10 hours per week
- Total cost: ~£3000
- Team size: 3 – myself, contractor for 2D art and logo, contractor for music and sound
- Revenue expectations: low: £500, medium: £1500, high: £3000 (break even)
How I settled on the concept and scope
I’ve been making games in my spare time for around 10 years now, and as the years go by I get more and more agitated that I haven’t made much progress towards doing this for a living. Learning is one thing, making a business out of your passion is another completely.
With that in mind, and with tens of dumped projects behind me, I set myself the target of releasing a commercial game this year – something people could buy, play, and most importantly enjoy.
In this market, I believe focusing on a specific genre is important. There are more game developers and games released than ever, so standing out is increasingly difficult. Curveball Games is all about strategy and simulation games, genres that have brought me so much joy over the years, and in my opinion have a lot to give in terms of innovation and exploration.
In terms of scope, as previously mentioned, I have a fairly large backlog of unfinished projects. Why are they unfinished? The most common reason is “it’s too big to finish”. As someone with a full time job, as well as other commitments we all have as adults, my most valuable resource is time. The projects I’ve worked on before have got to a well-developed “prototype” stage, then stayed there, because the road ahead is just too far in the distance, and by the time I’ve reached the end, it may not have been the best route anyway. A few of these prototypes did just end up being poor concepts, but each one was a learning experience that helped towards working out the scope for my first commercial game.
Having a year to make a game is a very good way of controlling scope, so long as you know what you can do in a year. My strengths are as a programmer, and so I overloaded that as best I could. I settled on a simple, low-poly style, most heavily influenced by the excellent Kingdoms and Castles (above). For most of my projects I’ve used 3D modelling in Blender, so I know how to create basic structures, fauna and such. Given I have at best intermediate modelling skills, I also settled on a game with non-living entities, as animating and rigging things like animals is a skill I don’t have much experience in.
I settled on a tower defense game, as the scope is easy to control, and the gameplay blueprint is simple to follow – enemies follow a path, you stop them getting to the end by placing towers. Programming a tower defense game is pretty simple too, and I’d done weapon and target management, enemy movement, and a simple game state in previous prototypes for games. Still I wanted to make it more than “just a tower defense game”, so I took some ideas from other games to make it more unique. Maps are (and later, waves) procedurally generated, firstly because I’m a programmer, and hand-designing these things well takes a lot of time, and secondly because I wasn’t planning on having a story or level-based game – I wanted something arcadey. Playing the same level over and over is boring, so this solvs that problem neatly. The other major sell is the ability to control the path the enemies take by placing “blockers” in the water. This was actually lifted from a game called X-Morph Defense, in which you can collapse buildings onto the enemy path to force them down longer routes.
This gave a good overall scope for the game. That said, some things were cut as they complicated the game or otherwise added too much development work:
- A number of other “utility buildings”, such as scrap processing plants that would increase your earnings per enemy destroyed
- Having multiple paths to select from in the level, and being able to choose one you liked – this was replaced with a simple algorithm that just selected the longest path from all those possible
- Enemies attacking towers and buildings as they moved past, meaning you had to maintain and repair towers – this was my favourite planned feature, and opened up the likes of repair towers and shields, but was simply too much complexity with everything else going on in game
- Along the lines of the above, having a command center that you placed and defended on the sea, which had a route planned towards it – code still exists for flying enemies to dive bomb it!
- Customisable settings for play sessions, such as changing the sea level to add/ lose land mass to build on
- Weather effects that buffed or debuffed the towers and provided other effects – rain could limit tower range for example, or lightning could rain down and deal damage to enemies
It’s important to cut these when you need to to keep things in scope. Some may still make the light of day in post-release content, but to get the game finished, they were removed without remorse!
Lessons learnt from development
There were a number of new experiences this time around, which I would never have had if I’d kept on making unfinished prototypes. I want to share a few tips that some other aspiring game developers may find helpful one day, which leads me nicely to my first lesson:
- Listen to advice. Many years ago, when I first started having a go at making games, I had dreams of running a small studio creating Game Of The Year contenders. So what did I do? I started writing massive games. Anything I’d heard about how you should start small and control scope was quickly dismissed, because “I’m a programmer don’t you know and actually I’m pretty good”. Firstly, it doesn’t matter how good you are, if you can’t make a game, it’s not good enough, especially if you want to do it for a living. Yes, there exist Eric Barone’s and Toby Fox’s (Stardew Valley and Undertale, respectively), but they’re the 1%. Don’t think your first game will make you an instant success. Listen to the advice that’s out there, my favourite being “start small”.
- Plan around your strengths. I’m a programmer, so while Island Invasion isn’t particularly fancy on the eye, it’s got some fairly neat gameplay elements that help it stand out. I can’t compete with other games in the genre, such as Frostpunk or Northgard, both of which have much larger budgets than me. But I can work with what I’ve got and design the game around my strengths. For the bits I’m not so good at, I planned a budget to have other, much more experienced people do a much better job.
- Get art and music done sooner. I hired two freelancers to work on the 2D art and sound design respectively, both of whom did a fantastic job and deserve a shoutout here: Matthew Walker on audio, and Tom Waterhouse on 2D. This is no reflection on them, but I left their work a little late in development. Fortunately this didn’t cause me too much of a problem, but it did lead to some unnecessary headaches running up to launch. In particular, I didn’t have a store page set up until 2 weeks to release, because the 2D work wasn’t ready yet. The problem was exacerbated by my “complete the game by the end of the year” deadline, which I’ll discuss in the next point, but is easily avoided if you plan this stuff near the start of development rather than near the end. Music and art is vital to the game, particularly in marketing, which you want to be doing much more than 2 weeks before release. Again, it’s worth saying this was my fault – both Tom and Matt did great work and you should check them out!
- Have a deadline. It’s easy to just go and work on a game, but if you want to sell it, you need a deadline. A deadline helps in a number of ways, but for me its biggest impact was on scope control. Knowing I had to get the game done by the end of the year allowed me to focus on the essentials, with a “stretch board” for anything that was a nice to have. Just remember, releasing the game is the first step! Post release content can be added afterwards, if need be (that said, don’t release a half finished game). Knowing what a reasonable deadline is depends on experience, and for me was drawn from both professional and hobby projects I’d completed (or not). Set a deadline and stick to it. That said…
- Have a balance. I played volleyball to keep fit and socialise, try to play a variety of games when I can, and have a happy social life. Burning yourself out working constantly on your game is not a good idea. A healthy social life and at least a decent level of fitness is also important, and actually helps me with motivation more too, given I have to balance priorities. I’ve read a fair few devlogs and post-mortems where the developers get burnt out and lose loads of money on their “dream project”. This one’s a bit more of a personal mantra for me, but I think it was really important in getting the game done and staying sane!
- Have realistic expectations. A small game like Island Invasion isn’t going to allow me to quit my job and make games full time. It’s likely my next 3 or 4 games won’t either. But I knew that when I started out. What did I want from Island Invasion? A game that kicked things off for Curveball Games, my portfolio, but most importantly the experience of making a game from start to finish. Before you start your next game, ask yourself, “what do I want to get out of this, realistically?”
- Don’t rush anything. I didn’t spend much time on the 3D art, and so while the models you see in Island Invasion aren’t bad, they could, in my opinion, have been a lot better. Investing time in all the little things is important, however good or bad you are at them. And if it takes you 2 days to make a model that a professional could do in an hour, so what? It’s worth the investment, particularly if, like me, you have an income that’s not dependent on the game you’re making. For my next game I’ll be spending much more time on the bits I’m not so good at. Patience is a skill that anyone can learn.
- Know people. I don’t like the term networking, but knowing a few local freelancers, or knowing friends who knew local freelancers, made sourcing art and music much easier. Also, meeting those freelancers in person for me is vital – not only do you get an idea for their professionalism, but it helps build a more personal relationship, which makes communication so much easier. I’ve worked for big and small companies, and it always saddens me how quickly managers and executives lose sight of the people working for them in the pursuit of larger profits. The indie game dev scene is a particularly friendly and helpful scene, so get down to your local games hub or participate in a game jam – you never know who you’ll meet!
- Learn. There’s a great quote, attributed to Einstein (disputed), that states that the definition of insanity is “doing the same thing over and over again and expecting different results”. I’d created plenty of prototypes, constantly wondering why I couldn’t finish them. So I tried something I didn’t really like or want to do: go small. Along the way I’ve picked up plenty of tips, and learnt from mistakes that won’t be repeated in game #2. Furthermore, I’ll be strengthening my knowledge of some of the newer features in Unity, and practicing some 3D modelling. Learning is such a vital tool. It’s also worth learning outside of your domain; this year I’ve done a bit of personal development too, my favourite book on the matter this year being The 7 Habits Of Highly Effective People (which if you’ve read you’ll understand why I’m preaching about learning so much!).
Here are a few more that I’ll list which I’ve learnt over years of development experience, not on this project, but leave the details out, simply as the post is getting quite long!
- Build a “core” codebase, for common code you’re likely to share amongst games (e.g. options screens, resource loading, common utility functions…)
- Use version control, and if it’s Git, consider Git LFS
- Set up a company, and separate your personal and business finances
- Keep a board of some sort (for me Trello, others are available) to manage your workload, and especially any ideas you have (keep these separate to avoid scope creep!)
- Don’t forget about marketing – it’s vital
- Have others test the game before you launch it
- Pick a good game name, or at the very least one that isn’t already taken/ trademarked
A few people have asked me if I have game number 2 scoped out yet. I have a few ideas, but nothing concrete. First I plan to take a break over Christmas, though inevitably I’ll end up doing something game dev related. I’d like to learn about Unity’s newest features and whether or not I could or should use them, as well as do some more 3D modelling and texturing practice. I plan to start scoping and designing game 2 around March or April.
I want to write a few more blogs like this over the coming weeks, focusing more on the technical side of Island Invasion. As a programmer I feel I’m best placed to talk about technical things, so I’ll go over how I approach designing and managing the codebase, as well as some neat little tricks and design patterns I used.
As for Island Invasion, I’m hoping to release at least one “major” update in the new year, which will be “special powers” which can be activated each once per wave. These will be things like artillery barrages to lay down a siege on those pesky Dreadnoughts! There are a few small bugs to fix too.
I’m happy with how Island Invasion has turned out. I didn’t expect it to be a world-beater, and I don’t expect it to make a profit. That said, it’s steadily selling on Steam to hit the “low” revenue estimate of £500 I set. It’s been more pleasing to see two positive reviews from people I don’t know, one of whom seems to be getting a lot of playtime from the game! The best part has been the reception from friends and strangers alike. Overall, for me it’s been a successful project for what I aimed to achieve.
Here’s to the next one!