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: 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: ```c++ class Monster : public Animation,// public Audio,// public Physics// { }; ``` 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`. Abstract art representing computer programming

Abstract art representing computer programming

Creating entities by composing components ## 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: ```c++ // Entity.h #pragma once #include #include class Entity { public: Entity(std::string Name) : Name{Name} {} std::string Name; virtual void Tick(float DeltaTime) {} virtual void HandleEvent(SDL_Event& E) {} virtual void Render(SDL_Surface* S) {} }; ``` 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: ```c++ // Component.h #pragma once #include class Entity; class Component { public: Component(Entity* Parent) : Parent{Parent} {} virtual void Tick(float DeltaTime) {} virtual void HandleEvent(SDL_Event& E) {} virtual void Render(SDL_Surface* S) {} protected: Entity* Parent{nullptr}; }; ``` ### 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: ```c++ // Component.h #pragma once #include #include #include #include "Entity.h" // //class Component {/*...*/}; class Component { public: Component(Entity* Parent) : Parent{Parent} {} virtual void Tick(float DeltaTime) {} virtual void HandleEvent(SDL_Event& E) {} virtual void Render(SDL_Surface* S) {} protected: Entity* Parent{nullptr}; }; // class AnimationComponent : public Component { public: using Component::Component; void Tick(float DeltaTime) override; }; class AudioComponent : public Component { public: using Component::Component; void Tick(float DeltaTime) override; }; class PhysicsComponent : public Component { public: using Component::Component; void Tick(float DeltaTime) override; }; ``` ```c++ // Component.cpp #include #include "Component.h" #include "Entity.h" void AnimationComponent::Tick(float DeltaTime) { std::cout << Parent->Name << ": Animating\n"; } void AudioComponent::Tick(float DeltaTime) { std::cout << Parent->Name << ": Audio\n"; } void PhysicsComponent::Tick(float DeltaTime) { std::cout << Parent->Name << ": Physics\n"; } ``` 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: ```c++ // Entity.h #pragma once #include #include #include "Component.h" // //class Entity {/*...*/}; class Entity { public: Entity(std::string Name) : Name{Name} {} std::string Name; virtual void Tick(float DeltaTime) {} virtual void HandleEvent(SDL_Event& E) {} virtual void Render(SDL_Surface* S) {} }; // class Wall : public Entity { public: // Inherit the Entity(std::string) constructor using Entity::Entity; void Tick(float DeltaTime) override { Physics.Tick(DeltaTime); } private: PhysicsComponent Physics{this}; }; class Fire : public Entity { public: using Entity::Entity; void Tick(float DeltaTime) override { Animation.Tick(DeltaTime); Audio.Tick(DeltaTime); } private: // Fire has Animation and Audio components AnimationComponent Animation{this}; AudioComponent Audio{this}; }; class Monster : public Entity { public: using Entity::Entity; void Tick(float DeltaTime) override { Animation.Tick(DeltaTime); Audio.Tick(DeltaTime); Physics.Tick(DeltaTime); } private: // Monster has all three components AnimationComponent Animation{this}; AudioComponent Audio{this}; PhysicsComponent Physics{this}; }; ``` ### Connecting Everything Together Let's create our basic `Scene` class to construct and manage some entities: ```c++ // Scene.h #pragma once #include #include #include // for std::unique_ptr, std::make_unique #include "Entity.h" // for Wall, Fire, Monster // Type aliases for clarity using EntityPtr = std::unique_ptr; using EntityPtrs = std::vector; class Scene { public: Scene() { // Create entities, passing required names // to constructors Entities.emplace_back( std::make_unique("Wall_1")); // Entities.emplace_back( std::make_unique("Fire_1")); // Entities.emplace_back( std::make_unique("Monster_1")); // } void HandleEvent(SDL_Event& E) { // Forward event handling to all entities for (EntityPtr& Entity : Entities) { Entity->HandleEvent(E); } } void Tick(float DeltaTime) { // Forward ticking to all entities for (EntityPtr& Entity : Entities) { Entity->Tick(DeltaTime); } } void Render(SDL_Surface* Surface) { // Forward rendering to all entities for (EntityPtr& Entity : Entities) { Entity->Render(Surface); } } private: EntityPtrs Entities; }; ``` 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: ```c++ #include #include "Window.h" #include "Scene.h" int main(int argc, char** argv) { SDL_Init(SDL_INIT_VIDEO); Window GameWindow; Scene GameScene; Uint64 LastTick{SDL_GetPerformanceCounter()}; SDL_Event Event; while (true) { while (SDL_PollEvent(&Event)) { GameScene.HandleEvent(Event); if (Event.type == SDL_QUIT) { SDL_Quit(); return 0; } } Uint64 CurrentTick{SDL_GetPerformanceCounter()}; float DeltaTime{static_cast( CurrentTick - LastTick) / SDL_GetPerformanceFrequency() }; LastTick = CurrentTick; // Tick GameScene.Tick(DeltaTime); // Render GameWindow.Render(); GameScene.Render(GameWindow.GetSurface()); // Swap GameWindow.Update(); } return 0; } ``` ```c++ #pragma once #include #include class Window { public: Window() { SDLWindow = SDL_CreateWindow( "Composition Example", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 700, 300, 0 ); if (!SDLWindow) { std::cerr << "Window could not be created! SDL_Error: " << SDL_GetError() << std::endl; } } ~Window() { if (SDLWindow) { SDL_DestroyWindow(SDLWindow); } } Window(const Window&) = delete; Window& operator=(const Window&) = delete; void Render() { // Fill background SDL_FillRect( GetSurface(), nullptr, SDL_MapRGB(GetSurface()->format, 220, 220, 220)); } void Update() { SDL_UpdateWindowSurface(SDLWindow); } SDL_Surface* GetSurface() { // Ensure window exists before getting surface if (SDLWindow) { return SDL_GetWindowSurface(SDLWindow); } return nullptr; } private: SDL_Window* SDLWindow{nullptr}; }; ``` Running our code, we should now see our various components interacting with the entities they are attached to, identified by their names: ```c++ // Wall_1: Physics Fire_1: Animating Fire_1: Audio Monster_1: Animating Monster_1: Audio Monster_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: Abstract art representing computer programming

Creating an entity using components in Unreal Engine 5 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.

Building with Components

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation