I've been doing some reading recently into 'Component Based Game Engines', and wanted to share a few of my findings and thoughts about it, in the hopes it might interest someone. Component Based development has existed for years in the software development sector, so it only seems natural to attempt to apply this same theory to game engines. Before you read on, I'd like to point out that this is in no way going to be a tutorial or contain any implementation of Component Based Architecture, it simply serves to outline the theory behind it. I'd also like to mention that there is no RIGHT way of implementing Component Based Architecture - different approaches can be taken by different engines, depending on personal preferences and the requirements of the engine.
Imagine we're building an engine for a very generic 3D FPS. Usually, the first thing we would do is examine what 'objects' we have in our game, and create classes for them. We would also consider any shared behavior or data that certain objects need to have. For example, we have an 'Enemy' and a 'Player', which are both entities within our physical space. They'll need a position, maybe they each carry a weapon, and they each need health points. We'd then consider some objects further down our inheritance tree, for example different types of enemies would need different behaviors so we would probably be deriving enemies from our enemy class. This is the kind of game architecture that we are all used to. The following class diagram is one we should be comfortable with, it's a simple representation of part of the object hierarchy for a 3D FPS.
Familiar enough, yes? The Player inherits different behavior by overriding the virtual Update function in the ModelEntity, as does the PowerUp. The PowerUp then has two derived classes that add additional behavior on to that. This is a well established paradigm for structuring a game engine, as in our update loop we can treat all classes derived from ModelEntity uniformly in a single data structure, and make use of polymorphism and dynamic-dispatch to handle the different behaviors of each entity.
So, what actually is Component Based Architecture? Component Based architecture is different to our usual object hierarchy in that it focuses on making compositions of 'components' to form a game object, as opposed to the game object getting it's functionality through inheritance. When applying component based architecture to game engines, I find it is easier to refer to these components as 'Behaviours'. Each of these different Behaviours have their own Update() and Draw() functions that pretty much allow them to 'do their thing', and data members that are specific to that job. For example, the component 'ModelRenderable' may contain a Model and it's Draw() function may simply render that model. It may also have a velocity, or direction, or bounding box, the functionality of which is handled by it's Update() function. We can then group these behaviours together in composite classes in order to create what we consider to be a 'Game Object'. A player, for example, may contain a 'ModelRenderable' behaviour, a 'Health' behaviour that keeps track of their health, and any other functionality needed for that specific game. We can then refer to these 'Game Objects' polymorphically, just as before in our object hierarchy approach, in a 'Game World' object, that contains a collection of Game Objects. It's Update() and Draw() functions simply call the Game Object's Update() and Draw(), which in turn can carry out all of it's different behaviours. The following class diagram is a very light-weight outline of how Component Based Architecture could be implemented for games.
So the next question is - why use Component Based Architecture? We're all comfortable with object hierarchies, they're well established so that we can all understand one another's code. Well as to the answer to that - I'm not entirely sure as of yet. There are some cases in which code in object hierarchies can become very bloated, where base classes can implement code that is not used by some of it's derived classes. This makes sense however - as if a class uses most of it's base class' functionality, why re-write it just because it doesn't use some of the other base class functionality? It would add a lot of unnecessary code. But a component based engine would avoid this issue - as objects only implement the functionality or behaviour that you know they require. I've added some links to other resources and reading that might help you further understand Component-Based Architecture.
Imagine we're building an engine for a very generic 3D FPS. Usually, the first thing we would do is examine what 'objects' we have in our game, and create classes for them. We would also consider any shared behavior or data that certain objects need to have. For example, we have an 'Enemy' and a 'Player', which are both entities within our physical space. They'll need a position, maybe they each carry a weapon, and they each need health points. We'd then consider some objects further down our inheritance tree, for example different types of enemies would need different behaviors so we would probably be deriving enemies from our enemy class. This is the kind of game architecture that we are all used to. The following class diagram is one we should be comfortable with, it's a simple representation of part of the object hierarchy for a 3D FPS.
Familiar enough, yes? The Player inherits different behavior by overriding the virtual Update function in the ModelEntity, as does the PowerUp. The PowerUp then has two derived classes that add additional behavior on to that. This is a well established paradigm for structuring a game engine, as in our update loop we can treat all classes derived from ModelEntity uniformly in a single data structure, and make use of polymorphism and dynamic-dispatch to handle the different behaviors of each entity.
So, what actually is Component Based Architecture? Component Based architecture is different to our usual object hierarchy in that it focuses on making compositions of 'components' to form a game object, as opposed to the game object getting it's functionality through inheritance. When applying component based architecture to game engines, I find it is easier to refer to these components as 'Behaviours'. Each of these different Behaviours have their own Update() and Draw() functions that pretty much allow them to 'do their thing', and data members that are specific to that job. For example, the component 'ModelRenderable' may contain a Model and it's Draw() function may simply render that model. It may also have a velocity, or direction, or bounding box, the functionality of which is handled by it's Update() function. We can then group these behaviours together in composite classes in order to create what we consider to be a 'Game Object'. A player, for example, may contain a 'ModelRenderable' behaviour, a 'Health' behaviour that keeps track of their health, and any other functionality needed for that specific game. We can then refer to these 'Game Objects' polymorphically, just as before in our object hierarchy approach, in a 'Game World' object, that contains a collection of Game Objects. It's Update() and Draw() functions simply call the Game Object's Update() and Draw(), which in turn can carry out all of it's different behaviours. The following class diagram is a very light-weight outline of how Component Based Architecture could be implemented for games.
So the next question is - why use Component Based Architecture? We're all comfortable with object hierarchies, they're well established so that we can all understand one another's code. Well as to the answer to that - I'm not entirely sure as of yet. There are some cases in which code in object hierarchies can become very bloated, where base classes can implement code that is not used by some of it's derived classes. This makes sense however - as if a class uses most of it's base class' functionality, why re-write it just because it doesn't use some of the other base class functionality? It would add a lot of unnecessary code. But a component based engine would avoid this issue - as objects only implement the functionality or behaviour that you know they require. I've added some links to other resources and reading that might help you further understand Component-Based Architecture.
- Shows some of the problems that occur in object hierarchies, and also shows some different ways of implementing Component-Based Architecture: http://www.raywenderlich.com/24878/introduction-to-component-based-architecture-in-games
- This post by Gareth Jenkins of 36peas uses a similar architecture to one I outlined above: http://www.36peas.com/blog/2011/9/15/lightweight-component-architectures-and-object-composition-i.html
