Now that we have our basic Entity-Component System structure, let's focus on making the pieces work together. This lesson explores how components can access their owning entity and interact with sibling components.

We'll implement mechanisms for handling dependencies between components and see how traditional inheritance can still be combined with composition by creating specialized entity subtypes.

Communication Between Entities and Components

Components rarely exist in isolation. They often need to know about the Entity they belong to (e.g., to access its other components or trigger entity-level actions) or interact with sibling components (like our ImageComponent needing position data from a TransformComponent).

To enable this communication, we'll give every Component a way to access its owning Entity. We can achieve this by passing a reference or pointer to the Entity into the Component's constructor and storing it as a member variable.

We'll use a raw pointer here, as the Entity owns the Component, not the other way around:

1// Component.h
2#pragma once
3#include <SDL.h>
4
5// Forward declaration to avoid circular includes
6class Entity;
7
8class Component {
9public:
10  // Constructor now takes a pointer to the
11  // owning Entity
12  Component(Entity* Owner) : Owner(Owner) {} 
13
14
15  // Getter for the owning entity
16  Entity* GetOwner() const { 
17    return Owner; 
18  } 
19
20  // ...
21
22private:
23  // Store a pointer to the owner
24  Entity* Owner{nullptr}; 
25};

We'll update our TransformComponent and ImageComponent to inherit this constructor:

1// TransformComponent.h
2#pragma once
3#include "Vec2.h"
4#include "Component.h"
5
6class TransformComponent : public Component {
7public:
8  // Inherit the constructor from the base class
9  using Component::Component;
10  
11  TransformComponent() { // <d>
12    std::cout << "TransformComponent created\n"; // <d>
13  } // <d>
14
15  // ...
16};

1// ImageComponent.h
2#pragma once
3#include "Component.h"
4
5class ImageComponent : public Component {
6 public:
7  // Inherit the constructor from the base class
8  using Component::Component;
9
10  ImageComponent() { 
11     std::cout << "ImageComponent created\\n"; 
12   } 
13   
14   // ...
15};

Let's update our AddTransformComponent() and AddImageComponent() to pass a pointer to the Entity that is constructing the component:

1// Entity.h
2// ...
3
4class Entity {
5public:
6  // ...
7
8  TransformComponent* AddTransformComponent() {
9    if (GetTransformComponent()) {
10      std::cout << "Error: Cannot have "
11        "multiple transform components";
12      return nullptr;
13    }
14
15    ComponentPtr& NewComponent{
16      Components.emplace_back(
17        std::make_unique<
18          // Pass 'this' (the Entity*)
19          TransformComponent>(this))}; 
20
21    return static_cast<TransformComponent*>(
22      NewComponent.get());
23  }
24
25  ImageComponent* AddImageComponent() {
26    ComponentPtr& NewComponent{
27      Components.emplace_back(
28        // Pass 'this' (the Entity*)
29        std::make_unique<ImageComponent>(this))}; 
30
31    return static_cast<ImageComponent*>(
32      NewComponent.get());
33  }
34
35  // ...
36};

We can see our inter-component communication in action by having our ImageComponent retrieve the position of the Entity they're attached to by accessing its TransformComponent.

Note that the following code assumes that the entity the ImageComponent is attached to always has a TransformComponent. Later in the lesson, we'll add logic to ensure that is the case:

1// ImageComponent.h
2#pragma once
3#include "Component.h"
4
5class ImageComponent : public Component {
6 public:
7  using Component::Component;
8  // ...
9  void Render(SDL_Surface* Surface) override;
10};

1// ImageComponent.cpp
2#include <iostream>
3#include "ImageComponent.h"
4#include "Entity.h"
5
6void ImageComponent::Render(
7  SDL_Surface* Surface
8) {
9  // Assume we have an owner, and the owner
10  // has a TransformComponent
11  TransformComponent* Transform{
12    GetOwner()->GetTransformComponent() 
13  };
14
15  std::cout << "ImageComponent rendering at: "
16    << Transform->GetPosition() << '\n';
17}

1TransformComponent ticking
2ImageComponent rendering at: { x = 0, y = 0 }
3TransformComponent ticking
4ImageComponent rendering at: { x = 0, y = 0 }
5TransformComponent ticking
6ImageComponent rendering at: { x = 0, y = 0 }
7...

Component Dependencies

Since our ImageComponent needs a TransformComponent to know where to render, it's a good idea to take steps to enforce this dependency. We can add a check within the ImageComponent itself.

A reasonable place is right after it's constructed and added to the entity, perhaps via an Initialize() method, or even directly within the constructor (though modifying the owner's component list during construction can be tricky).

Most systems handle this by having a separate Initialize() function which is called after the object is constructed. Let's add that as a virtual function to our Component base class:

1// Component.h
2// ...
3
4class Component {
5 public:
6  // ...
7  virtual void Initialize() {} 
8  // ...
9};

We'll call it at the appropriate times within our AddTransformComponent() and AddImageComponent() functions:

1// Entity.h
2// ...
3
4class Entity {
5public:
6  // ...
7
8  TransformComponent* AddTransformComponent() {
9    if (GetTransformComponent()) {
10      std::cout << "Error: Cannot have "
11        "multiple transform components";
12      return nullptr;
13    }
14
15    ComponentPtr& NewComponent{
16      Components.emplace_back(
17        std::make_unique<
18          TransformComponent>(this))};
19
20    NewComponent->Initialize(); // <h>
21
22    return static_cast<TransformComponent*>(
23      NewComponent.get());
24  }
25
26  ImageComponent* AddImageComponent() {
27    ComponentPtr& NewComponent{
28      Components.emplace_back(
29        std::make_unique<ImageComponent>(this))};
30
31    NewComponent->Initialize(); 
32
33    return static_cast<ImageComponent*>(
34      NewComponent.get());
35  }
36  // ...
37};

Our ImageComponent can now override this to make sure it's being added to an entity that has a TransformComponent. If not, the ImageComponent will log an error message and request its own removal:

1// ImageComponent.h
2// ... 
3
4class ImageComponent : public Component {
5 public:
6  using Component::Component;
7  // Override Initialize
8  void Initialize() override; 
9  // ...
10};

1// ImageComponent.cpp
2// ...
3
4void ImageComponent::Initialize() {
5  Entity* Owner{GetOwner()};
6  if (!Owner->GetTransformComponent()) {
7    std::cout << "Error: ImageComponent "
8      "requires TransformComponent on its Owner\n";
9
10    // Request removal
11    Owner->RemoveComponent(this);
12  }
13}

Edge Cases

Our ImageComponent is checking if its owner has a TransformComponent at the point it's constructed, but it is possible that the TransformComponent be removed afterwards.

This would leave our ImageComponent in a broken state. We could check for the TransformComponent every time we Render(), but that has a performance cost that may not be worth paying.

If it's a realistic scenario that a component depends on some other component that might be removed from the entity, we should spend some time expanding our system to support this. For example, any time a component is removed from an entity, that entity could push an SDL_Event onto the event queue.

Alternatively, we could handle this within our Entity and Component infrastructure. An example solution would be to add an OnComponentRemoved() method to our Component base class:

1// Component.h
2// ...
3
4class Component {
5public:
6  // ...
7  virtual void OnComponentRemoved(Component* C) {} 
8  // ...
9};

Before an entity removes one of it's components, it can iterate through all the other components to notify them of what is happening:

1// Entity.h
2// ...
3
4class Entity {
5public:
6 
7  void RemoveComponent(Component* PtrToRemove) {
8    for (size_t i{0}; i < Components.size(); ++i) {
9      if (Components[i].get() == PtrToRemove) {
10        for (ComponentPtr& C : Components) {
11          C->OnComponentRemoved(PtrToRemove);
12        }
13        Components.erase(Components.begin() + i);
14        return;
15      }
16    }
17
18    std::cout << "Warning: Attempted to remove "
19      "a component not found on this entity.\n";
20  }
21
22  // ...
23};

Then, any component that cares when some other component gets removed can override the OnComponentRemoved() method and react accordingly:

1// ImageComponent.h
2#pragma once
3#include "Component.h"
4
5class ImageComponent : public Component {
6 public:
7  // ...
8  void OnComponentRemoved(Component*) override;
9  // ...
10};

1// ImageComponent.cpp
2// ...
3
4void ImageComponent::OnComponentRemoved(
5  Component* Ptr
6) {
7  // Check if the component being removed is a
8  // TransformComponent
9  if (dynamic_cast<TransformComponent*>(Ptr)) {
10    std::cout << "ImageComponent: Owner's "
11      "TransformComponent was removed!\n";
12
13    // React to removal...
14  }
15}

Note that we should be careful about calling Owner->RemoveComponent() here - at this point, there is already an invocation of RemoveComponent() in progress - that's why OnComponentRemoved() has been called. If we call RemoveComponent() again, that call can reduce the size of our array and change the indices of elements, disrupting the iteration that the previous invocation was in the middle of.

Note that the code in our components also assume that the component has an owner - that is, Owner is not a nullptr or, worse, a dangling pointer.

Our component's will always have an owner in our examples, but it's technically possible for someone to write code that violates this. An obvious example is just directly creating and using a component with no Entity involved:

1// Unintended usage
2ImageComponent BrokenComponent{nullptr}; 
3
4// Likely crash
5BrokenComponent.Render(Surface);

We cover techniques that can reduce this risk, such as private constructors and the friend keyword, in our advanced course.

Friend Classes and Functions

An introduction to the friend keyword, which allows classes to give other objects and functions enhanced access to its members

View Related Lesson

However, we'll keep things simple in this course. Our components will always have the correct owners, and we won't remove components that other components depend upon. As such, we won't need this OnComponentRemoved() notification system but, in more complex projects, it's worth considering what capabilities you need to have, and then build robust systems to support them.

Entity Subtypes

While the component system provides great flexibility through composition, it doesn't mean we have to abandon inheritance entirely. We can still create specialized Entity subclasses if it makes sense for our game structure, and get all the same benefits of inheritence.

Entity subtypes can customise how they manage their components, too. For instance, all characters in our game might need both a position (TransformComponent) and a visual representation (ImageComponent). We can create a Character class that inherits from Entity and automatically adds these essential components in its constructor.

1// Character.h
2#pragma once
3#include "Entity.h"
4#include "ImageComponent.h"
5#include "TransformComponent.h"
6
7class Character : public Entity {
8 public:
9  Character() {
10    // Automatically add required components
11    // upon construction. The AddComponent
12    // methods already handle passing 'this'
13    Transform = AddTransformComponent();
14    Image = AddImageComponent();
15  }
16
17  // Optionally add Character-specific methods here
18  void SayHello() const {
19    std::cout << "Character says hello!\n";
20  }
21
22 private:
23  // Optional: store direct pointers for
24  // convenience if frequently accessed.
25  TransformComponent* Transform{nullptr};
26  ImageComponent* Image{nullptr};
27};

Let's update our Scene to include a Character.

1// Scene.h
2// ...
3#include "Character.h"
4
5class Scene {
6public:
7  Scene() {
8    // Create a Character instead of a generic Entity
9    // The Character constructor handles adding
10    // its default components
11    EntityPtr& NewCharacter{Entities.emplace_back(
12      std::make_unique<Character>()
13    )};
14  }
15
16  // ...
17};

The Scene doesn't need to worry about the character's components - the Character makes sure it has what it needs:

1TransformComponent ticking
2ImageComponent rendering at: { x = 0, y = 0 }
3TransformComponent ticking
4ImageComponent rendering at: { x = 0, y = 0 }
5TransformComponent ticking
6ImageComponent rendering at: { x = 0, y = 0 }
7...

Additionally, just because our Character objects comes with some components as standard, that doesn't mean our Scene (or any other code) can't add more. We have the flexibility to do whatever we need:

1// Scene.h
2// ...
3
4class Scene {
5public:
6  Scene() {
7    EntityPtr& Player{
8      Entities.emplace_back(
9        std::make_unique<Character>())};
10
11    // The player character needs more components
12    Player->AddImageComponent();
13    Player->AddImageComponent();
14  }
15  // ...
16};

1TransformComponent ticking
2ImageComponent rendering at: { x = 0, y = 0 }
3ImageComponent rendering at: { x = 0, y = 0 }
4ImageComponent rendering at: { x = 0, y = 0 }
5// ...

Complete Code

Our complete code, which we'll build upon throughout this chapter, is available below:

Summary

This lesson enhanced our ECS by enabling communication and dependency management. We gave components access to their owning entity via an Owner pointer, allowing sibling component interaction.

We introduced an Initialize() step to enforce dependencies (like ImageComponent requiring TransformComponent) and demonstrated how an OnComponentRemoved() notification system could be added for robust dependency handling.

Finally, we saw how entity subtypes (Character) can combine inheritance with composition for convenient setup of standard entities.

Key takeaways:

Components can access their Entity via an Owner pointer passed during construction.
Sibling components can be found using GetOwner()->GetComponent()-style functions.
An Initialize() method allows components to verify dependencies after being added.
Components can request their own removal if dependencies aren't met.
An OnComponentRemoved() notification helps components react if a depended-upon component is removed later.
Entity subclasses (like Character) can inherit from Entity to provide default component setups.

Entity and Component Interaction

Communication Between Entities and Components

Component Dependencies

Entity Subtypes

Complete Code

Summary

Creating an Input Component

Game Development with SDL2