Introduction 

The architecture of software design is a much-debated subject. Every developer has his own opinion about what is good software design and what is not. Most developers agree on what is bad design, on what is good design there are a wide variety of opinions. Unfortunately, due to the nature of software development, there is no silver bullet; there is no one design strategy that always works.

There are a couple of strategies that have proofed to be successful. These strategies have known strengths and weaknesses. The advantage of using such a strategy is allowing you to focus on building your game, instead of worrying if your codebase will implode after someone decided the game should function a bit different than how the code was originally written.

Architecture

In game development, the entity-component-system is an architectural pattern that is used successfully in small, medium and large games. The main strength of this strategy is the usage of the composition over inheritance pattern. This pattern prevents the build-up of complex object inheritance tree’s, that will make your code impossible to refactor without a lot of side-effects.

So how does this pattern work, at its core, there are three elements; entity, components, and systems guess you didn’t see that coming. Let’s describe these one by one, I’m starting with the smallest and most simple one the “component”:

Component

 The component represents a single attribute of an entity. Some examples of entities can be:

• Position
• Rotation
• Scale
• Physics body
• Texture
• Health

Entity

 Entities are the “game-object” some examples:

• Ball
• Camera
• Player
• Enemy
• Bullet

An entity can have multiple components, for example, a ball entity can have the following components: position, rotation, scale, texture and physics body. A camera entity might only have a position. Usually, all entities have a unique-id for fast access, but there can also be other ways of accessing entities.

System

The system is responsible for one aspect of the game, a simple game has can, for example, have the following systems:

• Rendering
• Physics
• GUI
• Sound
• AI

What a system does is iterating over all entities that have components of the types defined by the system. For example, the physics system will act only on entities with a physics-component and a position-component. The rendering system will only act on entities that have a position and texture component. 

For example, if a ball entity has a position and physics and texture component. The physics system will pick up the ball entity, as it has a physics and position component. The physics-system control a physics-engine, that will do its magic and calculate a new position for the ball. The physics system will set this new position on the position component.

The rendering-system will also pick up the ball entity, as it acts on all entities that have a position and a texture component. The rendering system can render the ball using the texture and the position found with the ball entity (yes, the same component that was just updated by the physics-system).

Now imagine you spend some time implementing the architecture described above, and you after, running it, realize the ball is not really moving very realistic. That might be because you forgot to take rotation into account.

To fix it you now only have to create a rotation-component and add it to the ball entity. Now add in the physics system a check if the entity has a rotation component and if so just set the rotation on this component. In the rendering-system also add some code to check if there is a rotation component and if so render with this rotation.

This is where the power of this architecture emerges, imagine you have not one ball entity but have a lot of entities like the ball, wall, player, ground, etc. and you forgot about the rotation. You only have to modify the rendering system and the physics system. Then by simple adding a rotation component to the entities you want to have rotation on, magically all those objects have a rotation. Now adding rotation seems like a trivial thing to do, but what does this architecture enforces is the separation of concerns (e.g. rendering and physics) while still allows adding new functionality. And important; It does this without the usage of inheritance but rather by composition.

Possible features

The architecture described above is in itself quite powerful. But there are some more interesting possibilities with this architecture. I will describe some of them below.

Game-mechanic tweaking

Creating a generic mechanic-tuning-utilities; as there are a limit number of component types, you can create a (developer) GUI-overlay that allows you to modify the values of a component. This will allow you to in real-time modify the values, e.g. the position, size, texture, acceleration, the weight of a certain entity his components. This will help you tremendously in fine-tuning game mechanics without the need to keep recompiling and reloading your game.

Level-editor

Taking this even a step further you could use the above system to load all entities and relevant components from a file, e.g. XML. This will also help you decrease compile and loading time, letting you focus more one tuning game mechanics. This could then be a very good start for creating a level-editor, letting a none technical team member (game-designers) tweak game mechanics.

Dynamic loading

Something else that can be managed using this system, is implementing an entity loading/unloading mechanism. You can define an interface with functions like initializing, loading, starting, stopping, unloading, destructing. Now you can implement a loading mechanism that guarantees the loading and initializing always happen asynchronously. This will allow you to load and unload entities in a uniform and controlled manner. You could also choose to run all the systems in a different thread you need to take some more care about modifying components, but this could allow you to do a lot of performance enhancements, as for example, the AI needs less frequent updates then a renderer.

Real-world example

Note this implementation is done in Java, as I’m using libGDX as the platform, but the architecture is certainly not limited to Java and can also be implemented in other languages like C++.

Enough of the theory, now for a real implementation. As a hobby project, I have been creating a small iOS/Android game, my first implementation of this game was naïve, with one source file containing all logic. No need to explain this is a bad implementation, but this did allow me to check if my idea was fun and create a quick prototype and do some fast iterations from there.

For reference, the “bad” implementation can still be found here:  https://github.com/tgobbens/fluffybalance/blob/master/core/src/com/balanceball/Balanceball.java  

After I created this implementation I decided I wanted to implement the same game using a better manageable implementation.

The “main” entry file can be found here: https://github.com/tgobbens/fluffybalance/blob/master/core/src/com/balanceball/BalanceBallSec.java.

So, I’ve created my own entity-component-system. If you want to create your own game using an entity-component-system, and want the game to be ready as soon as possible then I wouldn’t recommend writing one yourself. However, if you want to learn about programming or just create something for fun, implementing such a system is easy, and you will learn a lot from doing this. Another reason to implement this yourself is you get a lot of freedom allowing you to add specific tricks and features that can help you improve your codebase.

The entity component system can be found under https://github.com/tgobbens/fluffybalance/tree/master/core/src/com/sec and yes there are some optimisation and improvements opportunities in this code base. But it does show an easy to understand implementation. When trying to understand make sure you know what Java generic types are. It’s quite common you need to find a certain entity to update or get some info from. As there are a lot of components you know there will be only one instance from. I’ve added a method to get the first entity of a certain type. For example, give me the camera entity, or give me the first “game-world” entity. But there are also helper functions to get all entities of a certain type. The same trick is used for getting components of an entity.

You will also find a basic type called “engine”, used for binding everything together. This will trigger the updates and holding references to all systems and entities. If you look for a “starting” point for the architecture this is where to start looking.