Building with Components

Inheritance is useful, but sometimes we need more flexibility. This lesson introduces composition, a powerful design pattern where we build complex objects by combining smaller, focused "component" objects. We'll explore why inheritance isn't always the best fit and see how composition allows us to mix and match capabilities like animation, audio, and physics for different game entities.

As we build more complex projects, the objects we need to build become more and more powerful. Objects in a game, for example, might need capabilities including:

• The ability to be animated
• The ability to emit audio
• The ability to simulate physics and collide with other objects

A class that includes all of these capabilities would already be quite complex, and these represent only a tiny subset of the capabilities that objects need in more complex games.

Why can’t we use Inheritence?

We’re already familiar with one way of managing the complexity in a class: we can organise these capabilities into a hierarchy, and then use inheritence to allow one class to include the capabilities of its parent.

However, inheritence isn’t really sufficient here, as these abilities don’t naturally exist in a hierarchy. Any given object will need some combination of these capabilities. For example:

• A wall needs to have physical collisions but doesn’t need to be animated.
• A fire needs to be animated and emit audio but doesn’t need to have physical collisions.
• An enemy monster needs all 3 of these capabilities, and more.

It’s not possible to arrange these capabilities into an inheritence tree in an elegant way. We would end up with the classes being too complex - for example, a class containing audio-emitting capability that most of their objects do not require. Alternatively, we’d end up having duplication, such as the code to emit audio being written in multiple classes.

So, we need a better design to organise this.

Multiple Inheritance

C++ is a rare example of a language that supports multiple inheritance, where a class can directly inherit from multiple base classes. We cover multiple inheritance in detail in our advanced course:

Multiple Inheritance and Virtual Base Classes

A guide to multiple inheritance in C++, including its common problems and how to solve them

We could attempt to use multiple inheritance to address this problem. For example, below, we have a Monster class inheriting from three base classes, representing the three example capabilities we listed above:

1class Monster :
2  public Animation,
3  public Audio,
4  public Physics
5{
6
7};

However, multiple inheritance is rarely used in this way. Multiple inheritance can lead to quite complex architectures, and doesn’t fully solve this problem anyway.

The composition-based techniques we cover in this chapter are much more common, and gives us a lot more flexibility. Later in the lesson, we’ll see examples of capabilities that cannot be implemented through multiple inheritance, but are easy to solve by composition.

Composition

Much like the event loop, composition is another example of a design pattern. It doesn’t involve any new language capabilities - rather, it uses the techniques that we’ve already covered. It applies these techniques to build a system whose design has proven itself to be an effective way to solve a common problem we encounter when building complex software.

Composition is the simple idea of combining multiple objects to create more complex behaviours.

First, we break our required capabilites into dedicated classes, such as a class to manage audio, a class to manage animation, and so on. Objects we create from these classes are often referred to as components.

Then, we create another class that is designed to manage a collection of components. Instances of this second class are often called entities.

This creates a symbiotic system where:

• Components give capabilities to the entities they’re attached to
• Entities decide what capabilities they need by choosing which types of components to attach

This gives us an elegant solution to our original problem. If an entity needs collision and audio capabilities, we can attach a PhysicsComponent and an AudioComponent to it. If some other entity needs animation and audio, it can have an AnimationComponent and an AudioComponent.

An Example of Composition

In the next lesson, we’ll implement a flexible component system, where our entities can have any number of components, and where we can easily create new component types to grant our entities new capabilities.

For now, let’s introduce a simple, minimalist example of composition to review some important concepts and establish the core idea. Feel free to skip this section if you’re more comfortable - we’ll be discarding the code we create here and begin building our more advanced system starting with the next lesson.

Base Classes

We’ll start by creating a base class for all of our entities. It contains the usual Tick(), HandleEvent(), and Render() functions for connecting to our game loop later:

1// Entity.h
2#pragma once
3#include <SDL.h>
4#include <string>
5
6class Entity {
7 public:
8  Entity(std::string Name) : Name{Name} {}
9  std::string Name;
10
11  virtual void Tick(float DeltaTime) {}
12  virtual void HandleEvent(SDL_Event& E) {}
13  virtual void Render(SDL_Surface* S) {}
14};

And, similarly, we’ll create a base class for our components. They’ll also contain the three methods that we need to connect our component to the game loop.

For a component to empower the entity it’s attached to with some capability, it will typically need to know what that entity is. As such, we’ll store a pointer to that Entity, and initialize it from the constructor:

1// Component.h
2#pragma once
3#include <SDL.h>
4
5class Entity;
6
7class Component {
8 public:
9  Component(Entity* Parent) : Parent{Parent} {}
10
11  virtual void Tick(float DeltaTime) {}
12  virtual void HandleEvent(SDL_Event& E) {}
13  virtual void Render(SDL_Surface* S) {}
14
15 protected:
16  Entity* Parent{nullptr};
17};

Extending Base Classes

Let’s extend these base classes with some specific component types that will confer appropriate abilities to the entity they’re attached to. We’ll simulate this with some simple logging in Tick() overrides for now, but we’ll create useful components later in the chapter:

1// Component.h
2#pragma once
3#include <SDL.h>
4#include <string>
5#include <iostream>
6#include "Entity.h"
7
Component Class (Unchanged)|Show
8class Component {/*...*/};
20
21class AnimationComponent : public Component {
22 public:
23  using Component::Component;
24  void Tick(float DeltaTime) override;
25};
26
27class AudioComponent : public Component {
28 public:
29  using Component::Component;
30  void Tick(float DeltaTime) override;
31};
32
33class PhysicsComponent : public Component {
34 public:
35  using Component::Component;
36  void Tick(float DeltaTime) override;
37};

1// Component.cpp
2#include <iostream>
3#include "Component.h"
4#include "Entity.h"
5
6void AnimationComponent::Tick(float DeltaTime) {
7  std::cout << Parent->Name << ": Animating\n";
8}
9
10void AudioComponent::Tick(float DeltaTime) {
11  std::cout << Parent->Name << ": Audio\n";
12}
13
14void PhysicsComponent::Tick(float DeltaTime) {
15  std::cout << Parent->Name << ": Physics\n";
16}

Our Entity subtypes can now select the abilities they need by constructing appropriate components, and connecting them to the game loop by forwarding the required function calls.

We’re only using Tick() in the following example, but you can also override HandleEvent() and Render() if required.

For now, the specific Entity subtype determines what components each instance will have. The system we build later in the chapter will be much more flexible but, for this lesson, we’ll keep things simple:

1// Entity.h
2#pragma once
3#include <SDL.h>
4#include <string>
5#include "Component.h"
6
Entity Class (Unchanged)|Show
7class Entity {/*...*/};
17
18class Wall : public Entity {
19 public:
20  // Inherit the Entity(std::string) constructor
21  using Entity::Entity;
22  void Tick(float DeltaTime) override {
23    Physics.Tick(DeltaTime);
24  }
25
26 private:
27  PhysicsComponent Physics{this};
28};
29
30class Fire : public Entity {
31 public:
32  using Entity::Entity;
33  void Tick(float DeltaTime) override {
34    Animation.Tick(DeltaTime);
35    Audio.Tick(DeltaTime);
36  }
37
38 private:
39  // Fire has Animation and Audio components
40  AnimationComponent Animation{this};
41  AudioComponent Audio{this};
42};
43
44class Monster : public Entity {
45 public:
46  using Entity::Entity;
47  void Tick(float DeltaTime) override {
48    Animation.Tick(DeltaTime);
49    Audio.Tick(DeltaTime);
50    Physics.Tick(DeltaTime);
51  }
52
53 private:
54  // Monster has all three components
55  AnimationComponent Animation{this};
56  AudioComponent Audio{this};
57  PhysicsComponent Physics{this};
58};

Connecting Everything Together

Let’s create our basic Scene class to construct and manage some entities:

1// Scene.h
2#pragma once
3#include <SDL.h>
4#include <vector>
5#include <memory> // for std::unique_ptr, std::make_unique
6#include "Entity.h" // for Wall, Fire, Monster
7
8// Type aliases for clarity
9using EntityPtr = std::unique_ptr<Entity>;
10using EntityPtrs = std::vector<EntityPtr>;
11
12class Scene {
13 public:
14  Scene() {
15    // Create entities, passing required names
16    // to constructors
17    Entities.emplace_back(
18      std::make_unique<Wall>("Wall_1")); 
19    Entities.emplace_back(
20      std::make_unique<Fire>("Fire_1")); 
21    Entities.emplace_back(
22      std::make_unique<Monster>("Monster_1")); 
23  }
24
25  void HandleEvent(SDL_Event& E) {
26    // Forward event handling to all entities
27    for (EntityPtr& Entity : Entities) {
28      Entity->HandleEvent(E);
29    }
30  }
31
32  void Tick(float DeltaTime) {
33    // Forward ticking to all entities
34    for (EntityPtr& Entity : Entities) {
35      Entity->Tick(DeltaTime);
36    }
37  }
38
39  void Render(SDL_Surface* Surface) {
40    // Forward rendering to all entities
41    for (EntityPtr& Entity : Entities) {
42      Entity->Render(Surface);
43    }
44  }
45
46 private:
47  EntityPtrs Entities;
48};

Finally, let’s hook everything up to a basic game loop. The following main.cpp and Window.h classes have not changed since the previous chapter:

1#include <SDL.h>
2#include "Window.h"
3#include "Scene.h"
4
5int main(int argc, char** argv) {
6  SDL_Init(SDL_INIT_VIDEO);
7  Window GameWindow;
8  Scene GameScene;
9
10  Uint64 LastTick{SDL_GetPerformanceCounter()};
11  SDL_Event Event;
12  while (true) {
13    while (SDL_PollEvent(&Event)) {
14      GameScene.HandleEvent(Event);
15      if (Event.type == SDL_QUIT) {
16        SDL_Quit();
17        return 0;
18      }
19    }
20
21    Uint64 CurrentTick{SDL_GetPerformanceCounter()};
22    float DeltaTime{static_cast<float>(
23      CurrentTick - LastTick) /
24      SDL_GetPerformanceFrequency()
25    };
26    LastTick = CurrentTick;
27
28    // Tick
29    GameScene.Tick(DeltaTime);
30
31    // Render
32    GameWindow.Render();
33    GameScene.Render(GameWindow.GetSurface());
34
35    // Swap
36    GameWindow.Update();
37  }
38
39  return 0;
40}

1#pragma once
2#include <iostream>
3#include <SDL.h>
4
5class Window {
6public:
7  Window() {
8    SDLWindow = SDL_CreateWindow(
9      "Composition Example",
10      SDL_WINDOWPOS_UNDEFINED,
11      SDL_WINDOWPOS_UNDEFINED,
12      700, 300, 0
13    );
14    if (!SDLWindow) {
15      std::cerr << "Window could not be created! SDL_Error: "
16        << SDL_GetError() << std::endl;
17    }
18  }
19
20  ~Window() {
21    if (SDLWindow) {
22      SDL_DestroyWindow(SDLWindow);
23    }
24  }
25
26  Window(const Window&) = delete;
27  Window& operator=(const Window&) = delete;
28
29  void Render() {
30    // Fill background
31    SDL_FillRect(
32      GetSurface(), nullptr,
33      SDL_MapRGB(GetSurface()->format,
34        220, 220, 220));
35  }
36
37  void Update() {
38    SDL_UpdateWindowSurface(SDLWindow);
39  }
40
41  SDL_Surface* GetSurface() {
42    // Ensure window exists before getting surface
43    if (SDLWindow) {
44      return SDL_GetWindowSurface(SDLWindow);
45    }
46    return nullptr;
47  }
48
49private:
50  SDL_Window* SDLWindow{nullptr};
51};

Running our code, we should now see our various components interacting with the entities they are attached to, identified by their names:

1Wall_1: Physics
2Fire_1: Animating
3Fire_1: Audio
4Monster_1: Animating
5Monster_1: Audio
6Monster_1: Physics

Advanced Examples

Creating an entity and component system gives us a great deal of flexibility. It allows us to do things that are far beyond what can be achieved by inheritance alone.

The following image is from Unreal Engine, showing their implementation of how an entity can be constructed by composing a flexible hierarchy of components:

By building a compositional framework, we can do things like:

• Control what components an entity has, independent of that entity’s subtype. For example, one Monster might have a completely different set of components to another Monster.
• Attach multiple components of the same type. For example, if our entity needed to render two (or more) images, we don’t need a class that can render multiple images - we can simply attach multiple image components to the entity.
• Add and remove components at run-time. This means our entities can gain or lose capabilities while our game is running, perhaps in response to player actions
• Attach components to other components, thereby creating a hierarchy. For example, this could allow our player entity to attach a component that renders a 3D model of a radio. We could then attach an audio component to that 3D model component, to emit sound from the location of the radio.

We’ll implement these capabilities throughout the rest of this chapter.

Summary

This lesson introduced the composition design pattern as a flexible alternative to inheritance for building complex objects. We saw how entities can gain capabilities by attaching specialized components. While our initial example was simple, it demonstrated the core concept of combining objects to achieve greater flexibility than inheritance hierarchies typically allow.

• Inheritance struggles when capabilities don't fit a neat hierarchy.
• Composition builds complex objects by combining simpler objects (components).
• An entity manages a collection of components.
• Components provide specific capabilities (e.g., animation, physics) to their entity.
• Composition allows mixing and matching capabilities easily.

Free and Unlimited Access

Professional C++

Unlock the true power of C++ by mastering complex features, optimizing performance, and learning expert workflows used in professional development

View Course