The Complexity Barrier

Have you ever wondered why games are so fun to start and so hard to finish? How a project you were so excited about can become something you dread working on?

Anyone who's experienced this may attribute this lack of motivation and passion about their project to be their own failing, when in fact it may just be the result of hitting the complexity barrier.

So what is the complexity barrier? Simply put, it's the point at which a projects complexity prohibits you from making enough progress to keep you motivated. As a projects size increases the cost of integrating new features increases at an even faster rate. The reason for this is fairly straight forward, a game or any other large project is a series of interconnected features. Features that depend on or interact with one another, as the number of features and dependencies increases, so does the number of things you have to account for when you make a new change or add new functionality.

So what is the net result of the increasing costs of integrating new features? As the project grows you get less new functionality for your time invested. At a certain point you will hit the complexity barrier where it no longer seems worth your time to add a single feature to the project. These increasing integration costs are also what limit the size of a project any one individual can create.

As these practical issues of getting less new functionality for your time and spending more time bug fixing then adding functionality affect you, you begin to experience psychological affects as well. Moving from early in the project where new functionality was coming a mile a minute to a point where adding one attribute to one object results in 45 minutes of testing and regressions tends to frustrate a developer. As frustration builds the motivation to work on the project collapses and you are left with yet another unfinished project. This point of abandonment is the complexity barrier. This barrier indicates the largest project that you can hope to create given your technology and resources. Most people hit this point before their intended game is even half way done. The odds against recovering from this are nearly insurmountable.

So how do you ensure you do not hit the complexity barrier in the middle of your project?

There are a number of things you can do, the first is obviously selecting a game design that seems well within your ability to finish. Something like a casual game or retro game. I guarantee (unless you've already shipped a bunch of games) you will be amazed at just how hard it is to finish it.

Aside from that there are three main things that I have identified.

1. Write as little code as possible
The less code you have to write to add features and functionality to your game the less it will cost you to integrate new features. This is what makes technologies like TGB so attractive, so much of the work has been done for you that you really have to do very little to make things happen. If you are building your own technology as you build your game functionality you will increase your dependency chain exponentially. Every feature you want to add to the game means you have to add new features to your technology. Leveraging existing mature technology removes that dependency chain and enables you to focus entirely on game code. This pushes the complexity barrier much farther out enabling you to create a lot more game play features before you hit it.

2. Have a great content pipeline
So you've managed to build your own technology, get all the game mechanics you want and all you have left is to fill out some levels. You seem to have escaped the perils of the complexity barrier, right? Well no, what happens when you decided that you really need to add a new enemy type, or the artist wants to add some additional animations to the main character. Perhaps an animated tile would look really good in your level? If you (like most do) neglected to build a suite of tools that enable you to make these kinds of changes without writing more code you can still slam right into the complexity barrier. If every new enemy type requires you to sublcass a new class from your "CEnemy" class and implement it's interface all over again you will find you suddenly lose motivation to work on making new levels for your game.

Competing your technology is just the beginning, you'll find that once functionality stabilizes building your content and adding new assets will become a bigger headache then building your technology ever was.

3. Plan to spend more time building your game then you do working on its code.
This tip is a little more abstract. It ensure that you have the right focus for successfully completing your game. I know people who spend months (or even years) working on their technology only to bust out 30 levels in as many days, slap a shell around the thing and stick it on the market. It may be code complete but it's not a finished game. Customers don't care how much time and energy you put into coding the game, they are only interested in two things. The games design and it's production values. This is what customers will be willing to pay money for, to them the technology is invisible. So don't spend all your time focused on building game features and gloss over the most important features of a game, its design and production.

There is a lot more I could say on this topic but I will leave it there, to some of you this may be old news but I hope that it will be of use to developers who find themselves defeated by their projects and chronically unmotivated.