Component based game architecture

As a C++ programmer, I find that when I’m writing code for myself, I like it to be well designed, maintainable, and as simple as possible. Unfortunately as I continue to add features, the application gets bigger and new requirements or unforeseen design issues tend to lead to re-factoring. I have a hard time leaving messy code messy, and I don’t tend to hack features in, so every once in a while I clean up. It’s way more fun to add new visuals and features. But these rewrites need to be done, otherwise the source code becomes an unmaintainable bug prone mess.

That’s exactly what I’m doing for the next couple of days. Most the game objects use a component based game architecture. This lets me share and add functionality between game objects in a data driven manner. For example, there is no ‘Storage Barn’ object in the source code. There’s a data file that ties together components for the visual model, path finding, user interface, resource storage, state machine, graphics effects, etc. The result of this is a storage barn.

The only object that doesn’t use this architecture are the citizens themselves. They use code left over from my game prototype. The problem is that I want to add functionality to the citizens, such as a user interface that opens when you click on them. This functionality already exists in the game engine, but as the citizens are different from everything else they can’t use it directly. So I’d either have to duplicate code, or clean things up properly. Once cleaned up, they’ll share the same UI, rendering, animation, selection, and state machine components as everything else.

The plus is that when it’s done, the source code is smaller and adding functionality to the citizens will be easy. The minus is that code reorganization isn’t fun, and when complete it will do exact the same thing as before.