Component Design Systems

On my IceCream 1945 Code Project article, I recently received the following question:

I’m still trying to wrap my head around the component design system. Can you suggest any more required reading on the topic?

I wrote a quick off-the-cuff response, but I’d like to dive a little deeper into the question here. I made a mistake saying it’s like object-oriented programming because I think that’s inaccurate once you get past the basics. Instead, I would say the component model is very much like service oriented programming. Each component is written to provide a specific service to any entity in your game. To demonstrate the difference, here’s an example of a short loop on a game’s enemies using procedural programming:

foreach (Enemy e in enemyList) {
    SimulateVelocity(e);
    CheckForCollision(e);
    RunAI(e);
    // etc
}

Here is a similar loop using object-oriented programming:

foreach (Enemy e in enemyList) {
    e.SimulateVelocity();
    e.CheckForCollision();
    e.RunAI();
    // etc
}

Now, here’s that same loop using the component model:

foreach (SceneItem si in scene.AllSceneItems) {
    foreach (IceComponent component in si.Components) { // list of services attached to this item
        component.Update(); // tell the service to update
    }
}

Notice this time we don’t care what kind of SceneItem we’re referencing. And, we don’t even need to tell it to execute specific behaviors, which would start to become littered with conditionals in an advanced game. Instead, we’re just telling it to execute whatever service components are bound to it.

This way, we don’t have to worry about the looping, or worry about whether we should call an AI routine on something without AI, or velocity on a static object, etc. If the scene item should have velocity, it gets a VelocityComponent service. If it should have AI, it gets an AIComponent service. With IceCream, those components are automatically run each Update() without us having to write the loop or ensure the proper routines are called on all the right objects. Each of these Components provides a basic service to the SceneItem it is bound to, without any care as to what that SceneItem represents or is “doing” in the game.

For further reading, check out this Wikipedia entry for Component-based software engineering.

Leave a Reply

Your email address will not be published. Required fields are marked *