Being a hobbyist indie game developer is fun. You get the chance to use your own logic and imagination to literally dictate the rules of a world that you’re going to transport your potential users into.
You can take pride in knowing that you wrote the rules for how absolutely everything in that world works, and you get to transform your ideas and dreams into tangible products for people to enjoy, which make their lives somewhat better.
However, being a hobbyist developer also means that you have to be able to take responsibility for every single aspect of development. This is especially true for solo indie developers because there will be nobody to hold your hand through the process and show you where you are going wrong.
This means mistakes should be avoided at all costs. Game development takes a lot of time (albeit it’s usually worth every second!), so you definitely don’t want to unknowingly make mistakes that will end up wasting your time and making the process longer.
So without further ado, here are some mistakes that any indie developer should try to avoid when making games. These are some very important and fundamental things to remember (…or avoid… I guess), some of which I learned from my own experiences (which I have included in this post free of charge!). While you’re reading the article, if you realize that you’re guilty of one of these mistakes, don’t fret! After all, experience is the best teacher—the fact that you know these mistakes on a personal level will make them easier to spot and avoid next time you start making a game.
Mistake 1: Not Having a Plan
Indie game development takes a lot of time and effort. But because you might not have the time to work on your game regularly due to having a full-time job or being a full-time student, it can be easy to sweep the whole thing under the rug and not approach your undertaking seriously. Two things can help here:
First off, you’ll have to realize that indie game development takes sacrifices. You’ll have to make time for it. Force yourself to make time for development sessions (at least three hours of intense development every few days). And you have to be consistent with it. Frequently breaking your development pattern can often lead to many days passing without any development since other things will start stealing your attention away from your game. Without consistency, you’ll start missing development sessions and accumulate a lot of lost time. Naturally, you’ll sometimes have to give up development time for other pressing issues in your life; in such cases, try and make up for that lost time later.
Dimension Dash took me two months to make, and the 2.0 update took three months. I programmed while I had important exams to prepare for and skipped some social school events because I gave myself a deadline to meet and I had to keep going (also because my school can organize some pretty lame events). And it still took months. This is definitely not to scare you—it’s to show you that it’s a commitment.
Secondly, it helps to have a plan before you start. Have a good idea of what you want the game to be like (be modest though—if it’s your first game, it should be a relatively simple one). But leave room for improvement because your idea of what the game should be like will improve once you get into the thick of development.
Give yourself a rough deadline (like, “I want to finish by April”) and go for it. Set weekly talks to keep yourself focused and to ensure that progress is steady.
And lastly, list out all the things that the game will need before it can be deemed 100% complete. The results will surprise you (they still surprise me), as the list will be longer than you’d expect. Keep in mind that it’s acceptable (and somewhat expected) if you overshoot and miss your completion deadline by at most two months.
Mistake 2: Not Testing as Early as Possible
When making a game, it’s important to remember that you aren’t making the game for yourself. This is a fundamental rule in all areas of game development, not just indie. I mean, sure, we also make games for the fun of it and the pride associated with it, but most of the time, the game we are making is for others to play. That means we have to make sure that people apart from ourselves can enjoy the game.
When beginning to develop a game, don’t worry about the visuals or aesthetics. Get the core mechanics down first and then spruce up the aesthetics just a little bit (so that people aren’t completely put off when they first see the game). After that, immediately go out and ask people about the game. Ask them about any problems they faced and what they thought about the game in general, and take every suggestion seriously.
There’s no doubt that some suggestions will just be whack (at every stage of development, people will always bring us whack suggestions), but there’s a reason that person is suggesting that feature, no matter how lame it is. If the suggestion is bad, just look at why it was posed. Was it to make the game more engaging? Easier? Funnier? Scarier?
It should be noted that if you’re making a game that relies heavily on aesthetics to communicate and function (no problem with that), you’ll need to take aesthetics more seriously before the first testing session.
Once you’ve gotten your first testing exercise down, you’ll know how to integrate your initial direction for the game with what people actually want, and you can make a game that people are more likely to actually want to play.
And don’t forget to test your game frequently. Every time a new major element is added that works, perfect it and then send it out for testing. Not only does it help you gauge how much people will like this feature, but it also helps you discover bugs in your game that come about when players play the game differently from how you usually play. Heck, I even remember when one of my testers for Dimension Dash found a bug that allowed players to fly simply because when he played he jumped off platforms earlier than I did.
And don’t “test” it by just playing it yourself. One of the golden rules of game development is that the game developer is the worst tester. He’s played the game literally hundreds of times along the course of development, so he is inadvertently mastering the game. He knows all the gameplay values and how the game works to a T because he made that game’s world himself. It’s not intentional, but the game developer disqualifies himself as a legitimate tester since he has no learning curve with his game and can’t play the game as a new player would.
Mistake 3: Adding New Features on a Whim
“A good artist knows how to show restraint” — Marko Vale
As I’ve explained during the discussion of the first two mistakes, your game and the vision you have for it will evolve as you develop it. So that brings me to the issue of dealing with this evolution.
Whether they’re from tester suggestions or inspiration during development, new features will come into your mind for your game. Before you consider adding them, think them through properly to see if they’re necessary and good for the game.
Lemme say this straight: you shouldn’t try to add everything you want to your game all at once. This is the unfortunate truth. You have to stay on track and follow your schedule. You can deviate and go off track a bit to add smaller features, sure, but for larger undertakings, you have to consider more carefully.
Let me give a short, real story to illustrate this: when I was making Dimension Dash, I went to my friend for a routine testing run. He said it was “alright,” and passed a comment that it could use some sort of boss level.
At first, I was taken aback, but then I realized it was a great idea. I was reluctant to add it, but realized that if I forced myself, I could still meet my deadline (maybe a few weeks late). Did I make it? Yes.
But I could’ve waited, too. If the new feature you want to add will cause too much of a delay, finish the game first and add that feature as part of an update.
Once you launch the game, you’ll understand how the market likes it and can improve on it through that same update. Also, you could decide to work on other projects/games before you start development on the update, which would help diversify your portfolio instead of being bogged down by just one game.
Mistake 4: Not Looking Forward to Challenges
If you are an indie developer, you will inevitably face challenges. One day you will face issues with data persistence, or editing third-party assets, or creating a whole complex custom character creation system for your game, or whatever the game decides to throw at you.
You have to be excited when you face these problems!
Initially, that’s not an easy thing to do: some of the problems you’ll face can be real headaches. The idea of facing new problems can be daunting too, since it means that something new has to be learned and the path to the solution won’t necessarily be a straight one.
I used to have that same mindset when it came to new challenges; they would scare or discourage me. Then I realized that facing new uncomfortable problems is instrumental to becoming a better and more resilient programmer. Uncomfortable situations are precisely the situations that make people grow, and that couldn’t be more true for programmers. We’re problem solvers, after all, so we have to be able to solve more diverse and difficult problems if we ever want to be considered good.
Embrace new problems whenever you face them—take them as opportunities to get better because that’s precisely what they are. If you’re making a game and you aren’t facing at least a few problems, then you may have chosen something too easy for yourself. Give yourself the challenge of making that game bigger and better.
Don’t be afraid to use Google or Stackoverflow.com—those two resources are extraordinarily useful for finding solutions.
Signing Off for Now!
This post is getting long, so I’ll end it here. The things I’ve written about are very important to becoming a successful game developer, so please take them seriously (no pressure there)! And feel free to share this advice with anyone else who’s into game development. Here’s a quick round-up of everything I’ve brought up:
- Always have a plan and rough deadline before starting a new game. Be consistent with development sessions.
- Give your game to people to test as early as possible, and let others play it whenever you make major additions to the game. Frequent testing is important.
- Show restraint when adding new impromptu features and remember that you can always just update your game later.
- Be excited whenever you face new challenges—you’re gonna be a better programmer by the time you solve them.
And as a last piece of advice—make use of Reddit when making games, especially the IndieDev and Gamedev subreddits. Those guys are extremely helpful in evaluating your games and helping you think of creative solutions.