Entity Component System (ECS)

Introduction

Almost everything that exists in the game is an entity, from the player and NPCs to the map terrain and UI. An entity doesn't do much on it's own, but acts as a container to add components to. This is a common pattern in game development called an Entity Component System (ECS). Each component is responsible for one piece of functionality. We can make an entity do something interesting with the right combination of components.

Example: Tree Entity

For example, to create a tree:

public static Entity createTree() {
    Entity tree = new Entity()
        .addComponent(new TextureRenderComponent("images/tree.png"))
        .addComponent(new PhysicsComponent())
        .addComponent(new ColliderComponent());
    return tree;
}

1. We start with a new entity
2. We add a TextureRenderComponent which draws the tree texture on screen
3. We add a PhysicsComponent which lets the tree use game physics
4. We add a ColliderComponent which adds a rectangular collider around the tree, so other physics entities can't walk through it.

The tree would look like this in the game (green border indicates physics collider):

Example: Player Entity

A simple player entity might look like:

public static Entity createPlayer() {
  return new Entity()
    .addComponent(new TextureRenderComponent("images/player.png"))
    .addComponent(new PlayerMovementComponent())
    .addComponent(new InventoryComponent())
    .addComponent(new CombatComponent());
}

We can reuse the same texture render component that we used for the tree, but also add player-specific components to control movement, give the player an inventory, and give them combat capabilities (e.g. health and attack damage).

Read Next

• How to use entities
• How to use components

Behind the Scenes

Why use ECS over inheritance?

Inheritance has some strong limitations, both in game development and general software development. Inheritance only allows for change along one axis. This explanation of the bridge pattern has a great explanation of how this leads to problems. For an example that relates to game development, consider this inheritance tree for enemies:

If the scope of the project changes, and we now want to add a FlyingRangedEnemy, we are in trouble. The flying code exists in an entirely different part of the inheritance tree! In this case, composition (e.g. the bridge pattern) can be used to extract the flight code into a separate class, which both FlyingRangedEnemy and FlyingMeleeEnemy can use.

ECS can be considered as simply the bridge pattern taken one step further, where entity behaviour is defined completely by composition. The core entity class only contains functionality that is required for every entity in the game, and is never extended from. In general, it is recommended to keep inheritance trees wide rather than deep, and use composition where possible.

Further Reading

• Article explaining ECS
• Game Engine Architecture, 3rd Edition, Chapter 16.2
• Famous talk on Data-Oriented Programming: One step beyond ECS, we can throw away the idea of representing data as objects. Data-Oriented programming can create very performant code and is gaining traction in game development.
• Unity Engine's Data-Oriented Implementation