Why You’re Failing [Theory]

If you want the TL;DR version of this article, read only the words in bold and look at the pictures.

If you’re a game developer at any level, I’m sure you’re aware of the following scenario (I will be using the analogy of a brick wall to explain building a game)


You scope out this large (it’s going to be amazing) game. Then, as one person, you try to complete the whole thing. Sure, when you start to build the wall, you think you have have a lot of bricks. You work on making that one corner super polished. Perhaps the character controller is really detailed even if there’s not actually any levels. I think you’ve been there. That moment when you start polishing two hours into the process.

As you probably know, this method fails in general. This method does work for some people though, queue next scenario:


This is a triple A studio. They have a lot of money, a lot of wall builders, and a lot of bricks. They can build a wall of that size because even if one person burns out 10 more people are waiting to take that guy’s place.

You are not a triple-A studio.

Don’t act like one. Don’t have huge project ambitions unless you have a huge team and a huge wallet to back it up. one of the number one things that will kill your game is a scope that is too large. Take your hands off the microfiber cloth and stop polishing! Screen shake is not necessary, and it will eat into the time you could be developing other things.

You will feel less motivated the longer your project takes, so treat your development time like a fuse and use every second for only what’s most important.

Some indies already know this though. Like the one below:


So eventually, you learn to scale your game down, but it’s still not enough.


You decide to make a Dungeon Crawler with simple polygon graphics where you face enemies in Unity. Sound easy enough? So you start with making the character controller. You go in depth with it and make it able to sprint, jump and roll out of the way. Then you make the character in 3D and use Mecanim to animate him in Unity.

Next, you want to make the enemies. You manage to make a cube that moves towards the player, the player has so many cool moves compared to the enemy that it feels unbalanced. Not only that, but in your scene, you’re fighting on a white plane and it looks like junk. Not at all what you had imagined. Then you get an idea for another game, and abandon your Dungeon Crawler.

You may have been there before. The problem here is that you’re front loading development. You’re putting so much effort into how the game should start and into a select few mechanics that everything else must scale in proportion and you drain all your motivation.

This is where my theory comes in:


My approach is one of incremental development. At a base, the idea is that if you get the game into a state where you can play it from start to end as soon as possible, then you can always back fill content later.

Let’s take the example from earlier and see how we could apply it:

You decide to make a Dungeon Crawler with simple polygon graphics where you face enemies in Unity. Sound easy enough? Before you start, you theorize what you need for a minimum playable game. you decide the minimum game looks like this:

  1. Enter start room of dungeon
  2. Go into room with enemies
  3. Defeat enemies
  4. Go into room with exit
  5. Exit game

So you start with making the character controller. You only make it move. No jumping or anything. You only create what you need to work at a minimum. Now, as soon as possible, you create the exit. When you hit play, you can now walk from the start room to the end room and exit the game. You now have a minimum playable game, the essence of this theory.

Next, you back fill. You make enemies spawn and make them hurt the player with a simple melee. Next, you make the player hurt the enemies with a ranged attack. You do not polish anything, you only put in what the game needs to function. This means no image effects, screen shake, or animations.

Now, you have completed all goals. Test the game with people to see how they like the mechanics. Then, polish! 😀

This is just a theory, one that I am trying to incorporate into my current game, Firewall. so far it has been working amazingly! 🙂

Maybe this theory can work with your game too!