5 Tricks to Help You Finish Your Indie Game
March 1st, 2015
By Peter Robinson
Building an entire game can be a daunting task for a small group of developers. You don’t have to work on your game for very long before you realize that you’re in over your head. Most indie developers quit at this point – typically to pursue a new game idea. Stubborn developers press on, sometimes developing their game for years. This is what happened to my team when we made Pirate Code, our strategy pirate game. Although the process was painful, I came out on the other side a wiser developer. Here’s my 5 tips to help you finish your game. They can be applied whether you’re just starting on a new project or you’ve been buried in one for years.
1. The Only Make One Principle
You’re excited! You just came up with an awesome game idea and it’s time to sit down and flush out the design. You decide on 8 character classes and 3 factions that they can join. You’ll need types of weapons too – maybe 6 with subclasses for each! Six months later you’ve made the factions and the most of the character classes but you haven’t even started on the weapons. Having never actually played your game, you’ve grown to hate it. You quit.
What went wrong? You should have only made one. One hero with one weapon. Factions could happen later. I learned this from Pirate Code. Our original design called for 35 unique ships belonging to 7 categories. It took us literally years to make only 20 ships in 4 categories but what’s really the point? Are you more likely to buy a pirate game with 5 ships, 20 ships or 100 ships? The actual number of ship doesn’t matter. I should have made one ship, writing the code to support more ships in the future. Later as time allowed I could have added a second ship and later a third. I’m sure I would have ended with fewer ships but the game probably wouldn’t have hurt much for it and it would have been finished much sooner.
So practically speaking you should design your game knowing that you want more than one character class, but starting with just one. At no time in the process will you ever formally decide how many the final game will have. The only thing you will ever decide is if you want to add one more. Maybe once you have two character classes you’ll realize that the game would be more fun with three. Once you create that third class you’ll be happy and stop. If you had originally planned 8 then you would have wasted time building character classes you don’t need.
2. Make a Shorter Game
This is really just another dimension of the same problem in number one and the same solution applies. Say when you design your game you choose to have 8 levels (forest, ice, lava, underwater, etc.) But why? Only make one level and then add more as you need them. Pirate Code has 5 chapters and 38 islands. Looking back I can’t explain why. I should have added islands and chapters as I needed them, but instead I drew a world map, peppered it with islands, divided it into sections and picked an arbitrary number of chapters. Only later did I actually decide what the islands were even named or what happened in the story. I paid dearly for designing it this way. Don’t make the same mistake!
So just build that forest level. Plan on more, obviously, but you might finish your forest level and realize that the game feels complete. You can save the lava level for the expansion pack!
3. Use Combinations
As an indie developer, you are vastly outgunned when competing with the big game companies. You’ll just have to be smarter. So say you have two character classes, an elf and dwarf. You also have two weapons, bows and axes. Elves use bows and dwarves use axes (you saw it in a movie). Now the player has two options! Good job! But you can do better if you use combinations. Make the weapons separate from the classes and you suddenly get 4 options. There’s two advantages to this. First, every time you add a new character class you increase the number of combinations more dramatically. Second, when you decide to add a human you won’t have to add a new weapon – so adding something new takes less work! You must think creatively to do this in some circumstances and it doesn’t always apply. Maybe you really want to keep the weapons unique to each class. That’s fine. But consider the possibilities ahead of time and use other combinations to get more game for less work.
4. Build Procedural Levels
I wrote a whole post about this and I encourage you to take a look if you’re interested. Procedural levels are randomly generated levels. They add replay value and they make your life easier since you don’t actually have to design the levels – just the algorithm that generates them. Besides the benefit to replay value, this fits in with the rest of the advice I’ve given you. Say you’re making your forest level. In keeping with the Only Make One principle, you decide to make just one kind of tree. Later, you decide you want to add pine trees to give a little variety to your forest. Without procedural levels you’ll have to add the pine tree, fire up the level editor and manually place them throughout the forest. Depending on the size of your level you might spend days or even weeks doing this. Spending two weeks putting trees in a forest is a great way to kill your desire to finish your game.
Instead, use procedurally generated levels and you’ll have that pine tree worked into your forest in a matter of hours! Your players get more game and you get less development time. Everybody wins!
5. Add Features in Order of Importance
The final tip is to plan carefully your next move. Add one thing at a time as you need them. I’ve explained that no matter what you’re building, you want to start by Only Making One while planning to make more later. So in our example you’ve made one level with one tree type and one hero with one weapon to fight one kind of enemy. You now have a complete game which you can hand over to beta testers. We call this the Minimum Viable Product or MVP for short. This is the very simplest form of your game possible. Inevitably, your playtesters will be under impressed because there’s not much to your game. What you want to know is what they complain about. They might come back and ask for more enemies. Using combinations you create wings or legs for your single enemy type. Then you create a second enemy type with more life that can use the same legs or wings. Your testers love it but wish they had a way to do more damage to those new stronger enemies. You give them the battle axe. They love the axe but wish they could get something for killing enemies. You add one kind of treasure and everyone is happy. They still have ideas and so do you but at this point the game is super fun. You package it up and release it and save the rest for future updates.
What just happened there is called Agile Design. In fact, it was about as agile as you can get. You may think that this is how all games are made but really, it’s not. Most big game companies must have at least some sort of timeline in order to function. They have a lot of employees and they need to make sure everyone has something to do. Their marketing departments need to know when the game will be done and a hard release date needs to be set. You don’t have these restraints as an indie developer and you’d be foolish not to play to your strengths. Be agile. Build a Minimum Viable Product and then iteratively add features.
Sounds good, but this is the real world
One of the most popular indie game of all time is Minecraft. It was made by a single developer and was eventually sold to Microsoft for 2.5 Billion dollars. Minecraft perfectly follows these 5 tricks – perhaps one explanation for why it still only has one boss. I can’t promise that your game will be as successful as Minecraft but if you follow these tips you will have a much better chance of finishing your game and you’ll have fun while you do it. Good luck!