Now you’re talking with components

in Design Principles

Last week we introduced the concept of components as framework for programming game objects. As opposed to last week, this week we will discuss a more technical object: how to add communication between components. I will first describe a few use cases and why we are interested, before discussing several approaches and their advantages and disadvantages.

Now you’re thinking with components

in Design Principles

In an average game there will be a lot of different types of game objects. Since these game objects often share behaviour, it makes sense to categorise them to avoid code duplication. The common solution — in object-oriented languages, that is — is to use inheritance. Inheritance does have limitations however and on further inspection it does not appear to be the obvious choice at all. Switching to a component-based approach resolves a lot of issues. Developers using Unity will probably recognise the alternative I will discuss in this post, and I would lie if I was not heavily inspired by it. My main focus however will be to explain why a component-based approach is used. By explaining the philosophy behind components I am hoping to give existing Unity (or another game engine) users a better picture of the intended use, and new users an interesting new take on game programming.