After putting Sprite Clipper into a holding pattern, I started looking for a new nerd hobby.  I figured I would naturally progress into using slick2d, the Java game architecture that first set me off to make SC.  I didn’t have much of an idea of what kind of game I wanted to make, so I thought I would investigate different architectures to get some inspiration.

That’s when I ran across component video game architectures, which totally eschew object-oriented programming concepts.  This was completely new to me.  The gospel of OOP had been preached to me in nearly every context I came across it.  But, after reading some articles about the component paradigm, I began to see the drawbacks of class hierarchies.

The main goal of component architectures is to reduce coupling between various parts of the program as much as possible.  Let’s say you have an extensive class hierarchy, but you want to add a new feature to only certain classes in the inheritance tree (call them classes C) but not in some other classes (call them classes NC).  If the youngest common ancestor of all classes of C (call it superclass S) is also an ancestor of any class in NC, then you’re kind of SOL if you want to use inheritance.  You can’t give superclass S the new feature without also giving it to some class in NC.  Essentially, the class hierarchy couples different classes together, reducing your ability to selectively update parts of the tree in a robust manner. (I say robust because you could always just copy and paste the feature into each class in C, but the CompSci gods would strike you down for your heresy.)

In component architectures, inheritance is avoided.  In fact, most classes are avoided altogether.  Instead, all objects are simply containers of components, which are self-contained contained behaviors.  Want an object to respond to user input?  Add a UserInput component to the object.  Want an object to be destructable?  Add the Destructable component.  Using components, the object can be completely customized without affecting other classes or other objects.

Since component architectures are used to manage the behavior of  individual objects, they present a different problem from class hierarchies – how do you manage all the objects in your program?  Well, one strategy is to define a scripting language that will emulate inheritance, kind of like the one described in this Powerpoint presentation.  The presentation gives a good overview of the advantages and disadvantages of component architectures, and was probably the most useful resource I came across while investigating this topic.

So are component architectures next on my list of things to try out?  Probably not, actually.  I came across another intriguing new concept – functional languages – that I think I’ll explore first.  Functional languages are even stranger to me than component architectures, and I’m just a sucker for a new experience.