Don’t build more than what you need

One of the more abstract lessons I learned through making my AppWeek game was to build for the current project. I am, in my spare time, trying to build what one could call a 3D game engine. I’ve been (very) slowly building up code in various areas that will hopefully enable me to efficiently build game ideas when I have them. At this point it’s little more than a class library full of stuff.

One aspect of this “engine” was an entity system I was building. The idea was the composition pattern that many people have moved to for game development. At its core it means that an object in my game is nothing more than a container that is then stuffed with a bunch of components that actually build it up. The idea is that you can make building blocks (components) that you then combine to make more interesting objects. It’s a great theory but I’ve never really used a component system for a full game.

The first week was well underway, but I didn’t feel like I was moving fast enough to actually finish what I wanted. Eventually it hit me that the entity system (or at least my mindset) was causing friction between me and productivity. I was spending too much time managing component classes and interfacing between them, and not enough time progressing on the actual gameplay.

Towards the end of the first week, I decided to make a radical move and scrap the entire entity system for a “traditional” class hierarchy approach. Boy was that a good decision! It took me no time at all to build back to where I was and then it was much easier for me to continue to build upon my objects to finish off the game. I’m certain if I had kept fighting the component system, I never would have reached the point I did.

What it boils down to is that if you’re familiar with one paradigm or have a piece of code that works for your needs, stop trying to improve upon it until you have downtime or a real reason to improve it. Your customers won’t care if you used an entity system or class hierarchy, but if you spend all your time obsessing over details like that you might never get to the point of having customers.

Comments

• Anonymous
  September 29, 2010
  Totally agree! Too often I spend too much time optimizing class structure and the code itself like there are umpteen developers and dozen of companies waiting for me to finish it so they can buy it for big bucks and use it for Xty years :) The biggest problem is: It happens on my own personal and not so important "tooling" projects more often than on a real project :) Anil