Even in a moderately complex game, there can be hundreds of things moving about at the same time.
All the time things will be created and removed.
Some of the things can collide, with several different outcomes depending on what type of things that collides, and the state of those things.
Some aspects of the things are shared between the things, others are different.
All the time things will be moving, changing, colliding, spawning new things, and so on...
How on Earth can we handle all this while keeping our code clean and well-structured?
The entity-component-system pattern to the rescue!
The entity-component-system pattern is a popular way to organize data and code in games.
It is used in most of the foundations here at Nilwen.
The entity-component-system pattern means that you organize the code and data representing the "things" in the games as:
Entities - Individual "things" in the game. For example: The player, enemies, bullets, explosions, etc.
Components - Pieces of data representing aspects of the entity. For example the position of a bullet.
Systems - System that handles aspects of the entities. For example a system that handles collision control.
The systems are code. The components are data, handled by the systems. An entity is the sum of its components.
Let's say you have a very simple game containing a player and some monsters. The player might shoot bullets at the monsters. If the bullets hit the monsters an explosion occur.
The player, monsters, bullets and explosions are the entities.
All entities in this game does have a position.
The player, bullets and monsters can collide with other entities. An explosion entity, on the other hand, can not collide with other entities.
Both the player and monsters can loose "life points" when damaged.
There are some systems to handle those concerns:
The Position system handles the positions of entities.
The Collision system handles the collision detection of entities.
The Life system handles the "life points" of entities.
There are also the systems Player, Monster and Explosion for handling the specifics of the player, monster and explosions.
Putting it all together
What we have now is some simple entities, components and systems.
When an entity is created in the game, the components for that entity are added to the relevant systems.
In order to keep track of the entities. Every entity is given an unique id number.
The entity id is how we know which component is part of which entity.
One way to visualize the relationships between the entities, components and systems is a tabulation. With each column representing a system, each row representing an entity and each cell representing a component.
In this example entity 0 is the player, 1 and 2 are two monsters and 3 an explosion.
The circles in some of the cells represent a component. The absence of a circle in a cell means that the entity does not have any component handled by that system.
The circles in the cells in the Position column represents the position component for the entities - the circles in the Collision column represent the component useful for detecting collision, for example size - and so on.