Creating an Input Component

In this lesson, we connect player input to entity behavior. We'll first implement a simple InputComponent that directly modifies an entity's state.

Then, we'll refactor this using the command pattern, creating objects that represent actions like "move left" and "shoot".

Finally, we'll use std::unordered_map to map keys to these commands, enabling easy customization of our keybindings.

Starting Point

In our previous lesson, we established communication between components and their entities, explored dependency management. Our Entity objects can hold components like TransformComponent and ImageComponent, and these components can interact.

For this lesson, we’ll let our Entity objects move. To support this, we’ll update our TransformComponent with a new public Move() function:

1// TransformComponent.h
2#pragma once
3#include "Vec2.h"
4#include "Component.h"
5
6class TransformComponent : public Component {
7public:
8  using Component::Component;
9
10  Vec2 GetPosition() const {
11    return Position;
12  }
13  
14  void Move(const Vec2& Movement) {
15    Position += Movement;
16  }
17
18private:
19  Vec2 Position{0, 0};
20};

A Basic Input Component

Let's start by creating a simple InputComponent. Its primary role will be to listen for specific SDL_Event types (like keyboard presses) and directly tell its owning Entity's TransformComponent to move.

This approach works for simple cases but, as we'll see, it quickly becomes limiting. Here's a basic implementation:

1// InputComponent.h
2#pragma once
3#include "Component.h"
4
5class InputComponent : public Component {
6 public:
7  using Component::Component;
8  void HandleEvent(const SDL_Event& E) override;
9};

1// InputComponent.cpp
2#include <iostream>
3#include <SDL.h>
4#include "InputComponent.h"
5#include "Entity.h"
6
7void InputComponent::HandleEvent(const SDL_Event& E) {
8  if (E.type == SDL_KEYDOWN) {
9    if (!GetOwner()) return;  // Safety check
10    TransformComponent* Transform{
11      GetOwner()->GetTransformComponent()};
12    if (!Transform) return;  // Safety check
13
14    switch (E.key.keysym.sym) {
15      case SDLK_LEFT:
16        Transform->Move({-1.0, 0.0});  
17        std::cout << "Input: Move Left\n";
18        break;
19      case SDLK_RIGHT:
20        Transform->Move({1.0, 0.0});  
21        std::cout << "Input: Move Right\n";
22        break;
23      // Add cases for other keys if needed
24      default:
25        break;
26    }
27  }
28}

Let’s update our Entity class with an AddInputComponent() and GetInputComponent() , using the same pattern we applied for managing TransformComponents:

1// Entity.h
2// ...
3
4#include "InputComponent.h"
5
6// ...
7
8class Entity {
9public:
10  // ...
11
12  InputComponent* AddInputComponent() {
13    if (GetInputComponent()) {
14      std::cout << "Error: Cannot have "
15        "multiple input components";
16      return nullptr;
17    }
18
19    std::unique_ptr<Component>& NewComponent{
20      Components.emplace_back(
21        std::make_unique<
22          InputComponent>(this))};
23
24    NewComponent->Initialize();
25
26    return static_cast<InputComponent*>(
27      NewComponent.get());
28  }
29
30  InputComponent* GetInputComponent() const {
31    for (const ComponentPtr& C : Components) {
32      if (auto Ptr{
33        dynamic_cast<InputComponent*>(C.get())
34      }) {
35        return Ptr;
36      }
37    }
38    return nullptr;
39  }
40
41  // ...
42};

Finally, we’ll move over to our Scene and give our player character an InputComponent to verify everything is working:

1// Scene.h
2// ...
3
4class Scene {
5public:
6  Scene() {
7    EntityPtr& Player{
8      Entities.emplace_back(
9        std::make_unique<Entity>())};
10
11    Player->AddTransformComponent();
12    Player->AddInputComponent();
13  }
14
15  // ...
16};

Running our game and hitting the arrow keys should trigger the appropriate reactions from our InputComponent:

1Input: Move Left
2Input: Move Right

The Command Pattern

While the basic InputComponent works, it mixes input detection (checking SDL_Event) with action execution - Move(). The command pattern separates these concerns. Rather than an action being implemented as a direct function call, the command pattern has us represent them as durable entities, such as objects.

We’ll discuss the advantanges of this soon and the capabilities it unlocks, but for now, let’s implement the basic idea. We’ll define a Command class that represents an action that can be executed on some target:

1// Commands.h
2#pragma once
3class Entity;
4
5class Command {
6public:
7  virtual void Execute(Entity* Target){};
8  virtual ~Command() = default;
9};

Now, let's create a specific command for movement. It will inherit from Command and override the Execute() method to perform the actual movement using the Target entity's TransformComponent.

As with any object, commands can store additional data or functions as needed to help them fully represent the desired action. In this case, we’ll store a Vec2 representing the direction and magnitiude of movement that the command represents:

1// Commands.h
2#pragma once
3#include "Vec2.h"
4
Command Class|Show
5class Command {/*...*/};
11
12class MovementCommand : public Command {
13public:
14  MovementCommand(Vec2 Movement)
15  : Movement{Movement} {}
16  void Execute(Entity* Target) override;
17  Vec2 Movement;
18};

1// Commands.cpp
2#include "Commands.h"
3#include "Entity.h"
4
5void MovementCommand::Execute(Entity* Target) {
6  if (!Target) return; // Safety check
7  Target->GetTransformComponent()
8        ->Move(Movement);
9}

Note, to keep the examples simple, we’re assuming that Target has a TransformComponent. In more robust systems, we’d likely add additional checks and error handling as needed here.

Advantages of Commands

Why go to the trouble of creating command objects? This pattern unlocks several capabilities that are much harder to implement with direct input handling.

Key Customization

Most games allow players to rebind keys so, at the time we’re writing our code, we don’t necessarily know what the left and right arrow keys, for example, are supposed to do. The player might have changed them.

Using commands, we can create a mapping from input events (e.g., SDLK_LEFT) to Command objects (e.g., a MovementCommand configured for leftward movement). Changing bindings simply involves updating this mapping, without touching the core input handling or entity logic.

We’ll build our InputComponent to support this process throughout this lesson.

Context-Specific Bindings

In a relatively complex project, our control scheme varies depending on the context. The actions that buttons take will vary greatly depending on whether the player is in the main menu or in the game, or whether their character is on foot or in a vehicle.

Being able to save and switch an entire set of keybindings in an organized way is very useful in these scenarios.

Non-Player Characters

More complex games include non-player characters, such as enemies that the player has to fight. The AI code we write will need to issue commands to these characters, but these commands are not generated by keyboard and mouse events.

Decoupling player input from the commands that are issued to entities in our games allows us to create more flexible and reusable code. If our entity has a HandleCommand() method that accepts Command objects, that entity can be controlled by either the player or our AI.

In the case of the player, Command objects will be the result of input whilst, for the NPCs, they will be the result of AI logic. But the entity doesn’t need to care - it’s HandleCommand() function just works regardless of where the Command originated from.

Storing Commands

When a command is an object, it has all the usual object capabilities. It can be stored in an container to be executed later (a "command queue")

For example, in some situations, the full command may take some time to construct. For example, a player might select an ability to use and then, some frames later, select the target of that ability. Being able to hold a command in memory and fully define it over multiple steps makes mechanics like these easier to create.

Undo / Redo

In addition to a command being stored for executation later, it can also continue to be stored even after it has been executed. This lets us review and access the history of commands that have been previously executed.

A common feature where this is useful is the ability to undo (or redo) previous actions. Once we have built a command system, undo and redo functionality tends to be much easier to implement:

1// Commands.h
2// ...
3
4class MovementCommand : public Command {
5public:
6  // ...
7  void Execute(Entity* T) {
8    // Remember the target I was executed on
9    Target = T;
10    Target->GetTransformComponent()
11      .Move(Movement);
12  }
13  
14  void Undo() {
15    Target->GetTransformComponent()
16      .Move(-Movement);
17  }
18  
19  Entity* Target;
20  Vec2 Movement;
21};

Implementing Commands

Given the inherent flexibility of commands, we’re mostly free to use them in any way that suits our needs. The most basic usage is to create a Command and then call its Execute() method, providing a target:

1MovementCommand MoveRight({10.0, 0.0});
2MoveRight.Execute(SomeEntityPointer);

Commonly, we’d give our Entity class a way receive a command, and execute it on itself. A straightforward approach is to add a HandleCommand() method to the Entity base class. This method will take a pointer (or reference) to a Command object and call its Execute() method, passing this as the target.

For our simple example, we won’t need to store the commands for long - we’ll just discard them after shortly after they’re executed. Therefore, we’ll give our HandleCommand() function ownership of the command it receives by accepting it as a std::unique_ptr. This means that command will be automatically deleted once the function ends:

1// Entity.h
2// ...
3#include "Commands.h" 
4// ...
5
6class Entity {
7public:
8  // ...
9  virtual void HandleCommand(
10    std::unique_ptr<Command> Cmd
11  ) {
12    Cmd->Execute(this);
13  }
14
15  // ...
16};

Now, instead of directly calling Move(), our InputComponent would create a Command object and pass it to the target Entity's HandleCommand() method. For example, creating and handling a move command might look like this:

1// InputComponent.cpp
2#include <SDL.h>
3#include <memory> // for std::make_unique 
4#include "InputComponent.h"
5#include "Entity.h"
6
7void InputComponent::HandleEvent(
8  const SDL_Event& E
9) {
10  if (E.type == SDL_KEYDOWN) {
11    Entity* Owner{GetOwner()};
12    if (!Owner) return;
13    TransformComponent* Transform{
14      Owner->GetTransformComponent()};
15    if (!Transform) return;
16
17    switch (E.key.keysym.sym) {
18      case SDLK_LEFT:
19        Owner->HandleCommand(
20          std::make_unique<MovementCommand>(
21            Vec2{-1.0, 0.0}));
22        break;
23      case SDLK_RIGHT:
24        Owner->HandleCommand(
25          std::make_unique<MovementCommand>(
26            Vec2{1.0, 0.0}));
27        break;
28      default:
29        break;
30    }
31  }
32}

Unordered Maps

Let’s update our InputComponent to support dynamic key rebinding. To manage our key bindings (linking specific keys to specific commands), we need a way to quickly find the command associated with a pressed key (like SDLK_LEFT).

The std::unordered_map container is perfect for this. It stores key-value pairs and provides fast lookups based on the key. If you’re familiar with other programming languages, a std::unordered_map is the C++ equivalent to what you might recognize as a hash map, a dictionary, or an associative array.

We’ll cover the key points of std::unordered_map below, but we also have a dedicated lesson in our advanced course if you want a more detailed introduction:

Hash Maps using std::unordered_map

Creating hash maps using the standard library's std::unordered_map container

Creating Unordered Maps

To use a std::unordered_map, you first need to include the <unordered_map> header. When you declare a map, you specify the type of the key and the type of the value as template arguments. Here are two examples:

1#include <string>
2#include <unordered_map>
3#include <SDL.h>
4
5int main(int argc, char** argv) {
6  // A map where keys are strings (e.g., setting names)
7  // and values are integers (e.g., setting values)
8  std::unordered_map<std::string, int> Settings;
9
10  // A map where keys are SDL Keycodes (which are integers)
11  // and values are strings (e.g., action names)
12  std::unordered_map<
13    SDL_Keycode, std::string> KeyToActionName;
14
15  return 0;
16}

Remember, we can alias complex types if we prefer:

1using KeyMap = std::unordered_map<
2  SDL_Keycode, std::string>
3  
4KeyMap KeyToActionName;

The keys in an unordered map must be unique. If you try to insert an element with a key that already exists, the map's behavior depends on the insertion method used (some methods overwrite, others don't).

Accessing Elements

The most common way to access elements in a std::unordered_map is using the square bracket operator [], similar to arrays or vectors.

If you use [] with a key that already exists in the map, it returns a reference to the corresponding value, which you can read or modify.

If you use [] with a key that does not exist in the map, it performs two actions:

1. It inserts a new element into the map with the given key. The value associated with this new key is value-initialized (e.g., 0 for integers, nullptr for pointers, default-constructed for objects).
2. It then returns a reference to this newly created value.

This automatic insertion behavior can be convenient, but also potentially surprising if you only intended to read a value.

1#include <SDL.h>
2#include <unordered_map>
3#include <string>
4#include <iostream>
5
6int main(int argc, char** argv) {
7  std::unordered_map<
8    SDL_Keycode, std::string> KeyToActionName;
9
10  // Add mappings using []
11  KeyToActionName[SDLK_LEFT] = "Move Left";   
12  KeyToActionName[SDLK_RIGHT] = "Move Right";  
13  KeyToActionName[SDLK_SPACE] = "Jump";       
14
15  // Retrieve and print a value
16  std::cout << "\nSDLK_LEFT maps to: "
17    << KeyToActionName[SDLK_LEFT];
18
19  // Modify an existing value
20  KeyToActionName[SDLK_SPACE] = "Primary Action";  
21  std::cout << "\nSDLK_SPACE now maps to: "
22    << KeyToActionName[SDLK_SPACE];
23
24  // Accessing a non-existent key adds it with a
25  // default value.  For std::string, the
26  // default value is an empty string ""
27  std::cout << "\nSDLK_LSHIFT maps to: '"
28    // Key doesn't exist
29    << KeyToActionName[SDLK_LSHIFT]  << "'"; 
30
31  // Check the size - it increased because
32  // SDLK_LSHIFT was added
33  std::cout << "\nMap size: "
34    << KeyToActionName.size();
35
36  return 0;
37}

1SDLK_LEFT maps to: Move Left
2SDLK_SPACE now maps to: Primary Action
3SDLK_LSHIFT maps to: ''
4Map size: 4

Checking if a Map Contains an Element

Because using [] automatically inserts an element if the key isn't found, it's often necessary to check if a key exists before attempting to access its value, especially if you don't want accidental insertions.

C++20 introduced the contains() method for associative containers, including std::unordered_map. It simply returns true if the key exists and false otherwise.

1#include <SDL.h>
2#include <unordered_map>
3#include <string>
4#include <iostream>
5
6int main(int argc, char** argv) {
7  std::unordered_map<
8    SDL_Keycode, std::string> KeyToActionName;
9  KeyToActionName[SDLK_LEFT] = "Move Left";
10  KeyToActionName[SDLK_RIGHT] = "Move Right";
11
12  if (KeyToActionName.contains(SDLK_LEFT)) {
13    std::cout << "\nMap contains the LEFT key with value: "
14      << KeyToActionName[SDLK_LEFT];
15  }
16
17  if (!KeyToActionName.contains(SDLK_a)) {
18    std::cout << "\nMap does not contain the A key";
19  }
20
21  return 0;
22}

1Map contains the LEFT key with value: Move Left
2Map does not contain the A key

1#include <SDL.h>
2#include <unordered_map>
3#include <string>
4#include <iostream>
5
6int main(int argc, char** argv) {
7  std::unordered_map<
8    SDL_Keycode, std::string> KeyToActionName;
9  KeyToActionName[SDLK_LEFT] = "Move Left";
10  KeyToActionName[SDLK_RIGHT] = "Move Right";
11
12  if (KeyToActionName.count(SDLK_LEFT) > 0) { 
13    std::cout << "\nMap contains LEFT key";
14  }
15
16  if (KeyToActionName.count(SDLK_a) == 0) { 
17    std::cout << "\nMap does not contain A key";
18  }
19
20  return 0;
21}

1Map contains LEFT key
2Map does not contain A key

Key Bindings

Now we can combine the command pattern and std::unordered_map to create a flexible key binding system. The idea is to map specific SDL_Keycode values (the keys) to a mechanism that creates the appropriate Command object (the values).

Since we want to create commands that potentially need runtime information, we'll store functions capable of creating the commands. Functions that are primarily designed to create and return objects are sometimes called factories or factory functions.

Command is a polymorphic type, so code that uses our factory functions doesn’t necessarily know exactly what type the command will have - just that the type derives from Command. As such, our factory functions will need to create the command in dynamic memory, and return a pointer to it.

Rather than trying to manage this memory manually, we’ll use smart pointers. We’ll have our factory return std::unique_ptr<Command> instances, so whoever calls our factory immediately assumes ownership of the command it created.

We can use std::function to store our factories. Let’s create aliases for these types above our InputComponent class:

1// InputComponent.h
2// ...
3#include <functional> // for std::function
4#include <memory> // for std::unique_ptr
5// ...
6
7class Command;
8using CommandPtr = std::unique_ptr<Command>;
9
10// Command factories take no args and return
11// CommandPtr (std::unique_ptr<Command>)
12using CommandFactory = std::function<
13  CommandPtr()>;
14
15// ...
16
17class InputComponent : public Component {
18  // ...
19};

Next, our InputComponent needs to store an mapping between SDL keycodes and the factory that creates the command associated with that button. Let’s add an unordered_map with a type alias for that:

1// InputComponent.h
2// ...
3#include <unordered_map> 
4// ...
5
6class Command;
7using CommandPtr = std::unique_ptr<Command>;
8using CommandFactory = std::function<
9  CommandPtr()>;
10using KeyToFactoryMap = std::unordered_map<
11  SDL_Keycode, CommandFactory>;
12
13class InputComponent : public Component {
14public:
15  // ...
16
17private:
18  KeyToFactoryMap KeyDownBindings;
19};

We’ll also provide a way to add (or change) a keybinding:

1// InputComponent.h
2// ...
3
4class InputComponent : public Component {
5 public:
6  // ...
7  void BindKeyDown(
8    SDL_Keycode Key, CommandFactory Factory
9  ) {
10    KeyDownBindings[Key] = Factory;
11  }
12  // ...
13};

Finally, we’ll need a way to set up our default keybindings. Overriding the Initialize() function is likely the best place for that logic.

Our final InputComponent.h class looks like the following. We still have to implement some of this logic in our source file, which we’ll do next.

1// InputComponent.h
2#pragma once
3#include <functional>
4#include <memory>
5#include "Component.h"
6
7class Command;
8using CommandPtr = std::unique_ptr<Command>;
9using CommandFactory = std::function<
10  CommandPtr()>;
11using KeyToFactoryMap = std::unordered_map<
12  SDL_Keycode, CommandFactory>;
13
14class InputComponent : public Component {
15 public:
16  using Component::Component;
17  void Initialize() override;
18
19  void HandleEvent(const SDL_Event& E) override;
20
21  void BindKeyDown(
22    SDL_Keycode Key, CommandFactory Factory
23  ) {
24    KeyDownBindings[Key] = Factory;
25  }
26
27private:
28  KeyToFactoryMap KeyDownBindings;
29};

Implementing Keybindings

To complete our input component, there are three remaining things we need to do in our InputComponent.cpp:

1. Define the factory functions for creating command objects.
2. Implement our Initialize() override to bind some keys to our factory functions - that is, add entries to our KeyDownBindings map where the key is the SDL keycode and the value is the function that creates the command associated with that key
3. Update our HandleEvent() function to dynamically create the correct event based on the current state of our KeyDownBindings map

First, let's define the functions that will create our different commands. These functions return a CommandPtr, which is the alias we created for std::unique_ptr<Command>:

1// InputComponent.cpp
2#include <SDL.h>
3#include "Entity.h"
4
5// Our type aliases are coming from here
6#include "InputComponent.h"
7
8namespace{
9// Factory function for moving left (negative X)
10CommandPtr CreateMoveLeftCommand() {
11  return std::make_unique<MovementCommand>(
12    Vec2{-5.0, 0.0});
13}
14
15// Factory function for moving right (positive X)
16CommandPtr CreateMoveRightCommand() {
17  return std::make_unique<MovementCommand>(
18    Vec2{5.0, 0.0});
19}
20}
21
22// ...

Using the namespace keyword with no name here creates an anonymous namespace. Things that are in an anonymous namespace are only accessible within that same file. This is desirable here, as we don’t want to pollute the global namespace with things that are only relevant to our InputComponent.cpp file.

Next, let’s implement our Initialize() override to set up some default keybindings:

1// InputComponent.cpp
2// ...
3
4void InputComponent::Initialize() {
5  BindKeyDown(SDLK_LEFT, CreateMoveLeftCommand); 
6  BindKeyDown(SDLK_RIGHT, CreateMoveRightCommand); 
7  // Bind other keys as needed...
8}
9
10// ...

Finally, let’s update our HandleEvent() function to work with our dynamic keybindings. It will check our KeyDownBindings map to see if the key is associated with a factory function. If so, it will call that function to create a Command.

We will then pass that command to our owning entity’s HandleCommand() function or, alternatively, execute the command right here:

1// InputComponent.cpp
2// ...
3
4void InputComponent::HandleEvent(const SDL_Event& E) {
5  if (E.type == SDL_KEYDOWN) {
6    Entity* Owner{GetOwner()};
7    if (!Owner) return;  // Safety check
8    SDL_Keycode Key{E.key.keysym.sym};
9    if (KeyDownBindings.contains(Key)) {
10      // This line is explained in the next section
11      Owner->HandleCommand(
12        KeyDownBindings[Key]()
13      );
14      
15      // Alternatively:
16      // KeyDownBindings[Key]()->Execute(Owner);
17    }
18  }
19}

R-Values

The previous example contains a fairly complex expression that is likely to be confusing:

1Owner->HandleCommand(KeyDownBindings[Key]());

Let’s break this down step-by-step:

• KeyDownBindings[Key] retrieves the command factory associated with the key the player pressed. We know the KeyDownBindings map has a factory for this key because our earlier contains() check returned true.
• KeyDownBindings[Key]() immediately invokes that factory, returning a command in the form of a std::unique_ptr<Command> (or a CommandPtr, if we use our alias)
• HandleCommand(KeyDownBindings[Key]()) forwards this command to the HandleCommand() function.

The memory ownership aspect adds additional complexity here. Our factory function returns a std::unique_ptr, meaning that the HandleEvent() function should "own" that command. How can it transfer its ownership to the HandleCommand() function without using std::move()?

The reason is that, in our expression, the compiler can see that our HandleEvent() function is not storing the value returned by KeyDownBindings[Key](). It just immediately forwards it to the HandleCommand() function without storing a local copy. As such, it can be implicitly moved - if HandleEvent() isn’t storing the value, it can’t use it in the future, so it doesn’t need to own it.

If our HandleEvent() function was storing the command by, for example, saving it in a variable, then it would need to use std::move() to transfer its ownership to the HandleCommand() function:

1void InputComponent::HandleEvent(const SDL_Event& E) {
2  if (E.type == SDL_KEYDOWN) {
3    Entity* Owner{GetOwner()};
4    if (!Owner) return;
5    SDL_Keycode Key{E.key.keysym.sym};
6    if (KeyDownBindings.contains(Key)) {
7      CommandPtr Command{KeyDownBindings[Key]()};
8      Owner->HandleCommand(std::move(Command));
9    }
10  }
11}

These "temporary" values that we don’t store have a slightly obscure but official name: r-values. We have a dedicated lesson covering this topic in more detail in the advanced course:

Value Categories (L-Values and R-Values)

A straightforward guide to l-values and r-values, aimed at helping you understand the fundamentals

Continous Input

Our current InputComponent uses SDL_KEYDOWN events. This works perfectly for discrete actions – actions that happen once when a key is pressed.

However, in many situations, we want an input to be continuous - the action continues to happen as long as the button is held down.

A better approach for continuous input is polling. Instead of waiting for an event, we actively ask SDL for the current state of the entire keyboard each frame.

We covered keyboard state and polling in more detail here:

Understanding Keyboard State

Learn how to detect and handle keyboard input in SDL2 using both event-driven and polling methods. This lesson covers obtaining and interpreting the keyboard state array.

The key point is that SDL provides the SDL_GetKeyboardState() function for getting the current keyboard state. It returns a pointer to an internal SDL array where each element represents the state of a physical key (scancode). A value of 1 means the key is currently pressed down, and 0 means it's up.

We'll need a way to map the SDL_Keycode values we use in our bindings (like SDLK_LEFT) to the SDL_Scancode indices used by this array. SDL provides SDL_GetScancodeFromKey() for this conversion.

Updating the InputComponent for Polling

To implement polling, we need our InputComponent to do work every frame. We can add a Tick() override to handle this continuous checking.

We'll also add a separate map specifically for bindings related to continuous actions, keeping them distinct from the discrete key-down bindings. We’ll add a BindKeyHeld() function for adding bindings to this map:

1// InputComponent.h
2// ...
3
4class InputComponent : public Component {
5 public:
6  // ...
7  void Tick(float DeltaTime) override; 
8  
9  // For reference - this hasn't changed
10  void BindKeyDown(
11    SDL_Keycode Key, CommandFactory Factory
12  ) {
13    KeyDownBindings[Key] = Factory;
14  }
15  
16  void BindKeyHeld( 
17    SDL_Keycode Key, CommandFactory Factory
18  ) {
19    KeyHeldBindings[Key] = Factory;
20  }
21  // ...
22
23private:
24  // Map for discrete key presses (events)
25  // For reference - this hasn't changed
26  KeyToFactoryMap KeyDownBindings;
27  
28  // Map for continuous key holds (polling)
29  KeyToFactoryMap KeyHeldBindings;  
30};

Now, let's implement the Tick() method in InputComponent.cpp. Inside Tick(), we get the keyboard state array.

Then, we iterate through our KeyHeldBindings. For each binding, we convert the SDL_Keycode to an SDL_Scancode, check the state array at that scancode's index, and if the key is pressed, we create and dispatch the associated command:

1// InputComponent.cpp
2// ...
3
4void InputComponent::Tick(float DeltaTime) {
5  Entity* Owner{GetOwner()};
6  if (!Owner) return; // Safety check
7
8  // Get the current keyboard state
9  const Uint8* CurrentKeyStates{
10    SDL_GetKeyboardState(nullptr)};
11
12  // Check bindings for keys being held down
13  for (const auto& [Key, Factory] : KeyHeldBindings) {
14    SDL_Scancode Scancode{SDL_GetScancodeFromKey(Key)};
15    if (CurrentKeyStates[Scancode]) {
16      // Key is held, create and handle command
17      Owner->HandleCommand(Factory());
18    }
19  }
20}
21
22// ...

Let’s update our Initialize() function to bind our movement actions to our new continuous input handling instead:

1// InputComponent.cpp
2// ...
3
4void InputComponent::Initialize() {
5  // Bind keys for continuous holding
6  BindKeyDown(SDLK_LEFT, CreateMoveLeftCommand); 
7  BindKeyHeld(SDLK_LEFT, CreateMoveLeftCommand); 
8  BindKeyDown(SDLK_RIGHT, CreateMoveRightCommand); 
9  BindKeyHeld(SDLK_RIGHT, CreateMoveRightCommand); 
10
11  // Example: Bind a discrete action
12  // BindKeyDown(SDLK_SPACE, CreateJumpCommand);
13}
14
15// ...

Key Repeat Events

When a keyboard button is held down, most desktop platforms have a mechanism for reporting this, sometimes called key repeat events. The platform will continuously report key events as long as the keyboard button is held down, and SDL will make those events visible to us through the event loop.

We covered key repeats in more detail in our introduction to keyboard handling:

Handling Keyboard Input

Learn how to detect and respond to keyboard input events in your SDL-based applications. This lesson covers key events, key codes, and modifier keys.

However, platforms tune their key repeat mechanism on the assumption the keyboard is being used for text input, rather than controlling a game character.  Specifically:

• There tends to be a long delay between the initial keyboard event, and the first "repeat" event. That means the user has to hold their key down for a long time before we start getting repeat events.
• That delay before the first repeat event, and the delay between repeat events, is inconsistent across platforms and can sometimes be configured within the system settings.

If the keyboard is being used for text input in our game, this is all fine. But if it’s being used for something like character movement, we don’t want that to be delayed or changed based on system settings. So, in those scenarios, we should use the polling approach instead.

1// InputComponent.cpp
2// ...
3
4void InputComponent::HandleEvent(const SDL_Event& E) {
5  if (E.type == SDL_KEYDOWN) {
6    if (E.key.repeat) return; 
Previous Code Unchanged|Show
13  }
14}

Complete Code

The complete version of our InputComponent and Command classes we created in this lesson are provided below:

1#pragma once
2#include <functional>
3#include <memory>
4#include <unordered_map>
5#include <SDL.h>
6#include "Component.h"
7
8class Command;
9using CommandPtr = std::unique_ptr<Command>;
10using CommandFactory = std::function<
11  CommandPtr()>;
12using KeyToFactoryMap = std::unordered_map<
13  SDL_Keycode, CommandFactory>;
14
15class InputComponent : public Component {
16 public:
17  using Component::Component;
18  void Initialize() override;
19  void Tick(float DeltaTime) override;
20
21  void HandleEvent(const SDL_Event& E) override;
22
23  void BindKeyDown(
24    SDL_Keycode Key, CommandFactory Factory
25  ) {
26    KeyDownBindings[Key] = Factory;
27  }
28
29  void BindKeyHeld(
30    SDL_Keycode Key, CommandFactory Factory
31  ) {
32    KeyHeldBindings[Key] = Factory;
33  }
34
35private:
36  // Map for discrete key presses (events)
37  KeyToFactoryMap KeyDownBindings;
38  // Map for continuous key holds (polling)
39  KeyToFactoryMap KeyHeldBindings;
40};

1#include <SDL.h>
2#include "InputComponent.h"
3#include "Entity.h"
4#include "Commands.h"
5#include "Vec2.h"
6
7namespace{
8CommandPtr CreateMoveLeftCommand() {
9  return std::make_unique<MovementCommand>(
10    Vec2{-5.0, 0.0});
11}
12
13CommandPtr CreateMoveRightCommand() {
14  return std::make_unique<MovementCommand>(
15    Vec2{5.0, 0.0});
16}
17}
18
19void InputComponent::Initialize() {
20  BindKeyHeld(SDLK_LEFT, CreateMoveLeftCommand);
21  BindKeyHeld(SDLK_RIGHT, CreateMoveRightCommand);
22  // Bind other keys...
23}
24
25void InputComponent::Tick(float DeltaTime) {
26  Entity* Owner{GetOwner()};
27  if (!Owner) return; // Safety check
28
29  // Get the current keyboard state
30  const Uint8* CurrentKeyStates{
31    SDL_GetKeyboardState(nullptr)};
32
33  // Check bindings for keys being held down
34  for (const auto& [Key, Factory] : KeyHeldBindings) {
35    SDL_Scancode Scancode{SDL_GetScancodeFromKey(Key)};
36    if (CurrentKeyStates[Scancode]) {
37      // Key is held, create and handle command
38      Owner->HandleCommand(Factory());
39    }
40  }
41}
42
43void InputComponent::HandleEvent(const SDL_Event& E) {
44  if (E.type == SDL_KEYDOWN) {
45    Entity* Owner{GetOwner()};
46    if (!Owner) return;
47    SDL_Keycode Key{E.key.keysym.sym};
48    if (KeyDownBindings.contains(Key)) {
49      Owner->HandleCommand(KeyDownBindings[Key]());
50      // Alternatively:
51      // KeyDownBindings[Key]()->Execute(Owner);
52    }
53  }
54}

1#pragma once
2#include "Vec2.h"
3
4class Entity;
5
6class Command {
7 public:
8  virtual void Execute(Entity* Target) {}
9  virtual ~Command() = default;
10};
11
12class MovementCommand : public Command {
13public:
14  MovementCommand(Vec2 Movement)
15  : Movement{Movement} {}
16  void Execute(Entity* Target) override;
17  Vec2 Movement;
18};

1#include "Commands.h"
2#include "Entity.h"
3#include "TransformComponent.h"
4
5void MovementCommand::Execute(Entity* Target) {
6  if (!Target) return;  // Safety Check
7  Target->GetTransformComponent()
8        ->Move(Movement);
9}

We also made smaller changes to our Entity, Scene, and TransformComponent classes, which we’ve highlighted below:

1#pragma once
2#include <memory>
3#include <vector>
4#include <SDL.h>
5#include "Component.h"
6#include "TransformComponent.h"
7#include "ImageComponent.h"
8#include "InputComponent.h"
9#include "Commands.h" 
10
11using ComponentPtr = std::unique_ptr<Component>;
12using ComponentPtrs = std::vector<ComponentPtr>;
13
14class Entity {
15public:
16  virtual void HandleEvent(const SDL_Event& E) {
17    for (ComponentPtr& C : Components) {
18      C->HandleEvent(E);
19    }
20  }
21
22  virtual void Tick(float DeltaTime) {
23    for (ComponentPtr& C : Components) {
24      C->Tick(DeltaTime);
25    }
26  }
27
28  virtual void Render(SDL_Surface* Surface) {
29    for (ComponentPtr& C : Components) {
30      C->Render(Surface);
31    }
32  }
33
34  virtual ~Entity() = default;
35
36  virtual void HandleCommand(
37    std::unique_ptr<Command> Cmd
38  ) {
39    Cmd->Execute(this);
40  }
41
42  TransformComponent* AddTransformComponent() {
43    if (GetTransformComponent()) {
44      std::cout << "Error: Cannot have "
45        "multiple transform components";
46      return nullptr;
47    }
48
49    std::unique_ptr<Component>& NewComponent{
50      Components.emplace_back(
51        std::make_unique<
52          TransformComponent>(this))};
53
54    NewComponent->Initialize();
55
56    return static_cast<TransformComponent*>(
57      NewComponent.get());
58  }
59
60  TransformComponent* GetTransformComponent() const {
61    for (const ComponentPtr& C : Components) {
62      if (auto Ptr{
63        dynamic_cast<TransformComponent*>(C.get())
64      }) {
65        return Ptr;
66      }
67    }
68    return nullptr;
69  }
70
71  InputComponent* AddInputComponent() {
72    if (GetInputComponent()) {
73      std::cout << "Error: Cannot have "
74        "multiple input components";
75      return nullptr;
76    }
77
78    std::unique_ptr<Component>& NewComponent{
79      Components.emplace_back(
80        std::make_unique<
81          InputComponent>(this))};
82
83    NewComponent->Initialize();
84
85    return static_cast<InputComponent*>(
86      NewComponent.get());
87  }
88
89  InputComponent* GetInputComponent() const {
90    for (const ComponentPtr& C : Components) {
91      if (auto Ptr{
92        dynamic_cast<InputComponent*>(C.get())
93      }) {
94        return Ptr;
95      }
96    }
97    return nullptr;
98  }
99
100  ImageComponent* AddImageComponent() {
101    std::unique_ptr<Component>& NewComponent{
102      Components.emplace_back(
103        std::make_unique<ImageComponent>(
104          this))};
105
106    NewComponent->Initialize();
107
108    return static_cast<ImageComponent*>(
109      NewComponent.get());
110  }
111
112  using ImageComponents =
113    std::vector<ImageComponent*>;
114  ImageComponents GetImageComponents() const {
115    ImageComponents Result;
116    for (const ComponentPtr& C : Components) {
117      if (auto Ptr{dynamic_cast<
118        ImageComponent*>(C.get())}
119      ) {
120        Result.push_back(Ptr);
121      }
122    }
123    return Result;
124  }
125
126  void RemoveComponent(Component* PtrToRemove) {
127    for (size_t i{0}; i < Components.size(); ++i) {
128      if (Components[i].get() == PtrToRemove) {
129        Components.erase(Components.begin() + i);
130        return;
131      }
132    }
133
134    std::cout << "Warning: Attempted to remove "
135      "a component not found on this entity.\n";
136  }
137
138private:
139  ComponentPtrs Components;
140};

1#pragma once
2#include <SDL.h>
3#include <vector>
4#include "Entity.h"
5
6using EntityPtr = std::unique_ptr<Entity>;
7using EntityPtrs = std::vector<EntityPtr>;
8
9class Scene {
10public:
11  Scene() {
12    EntityPtr& Player{
13      Entities.emplace_back(
14        std::make_unique<Entity>())};
15
16    Player->AddTransformComponent();
17    Player->AddInputComponent();
18  }
19
20  void HandleEvent(SDL_Event& E) {
21    for (EntityPtr& Entity : Entities) {
22      Entity->HandleEvent(E);
23    }
24  }
25
26  void Tick(float DeltaTime) {
27    for (EntityPtr& Entity : Entities) {
28      Entity->Tick(DeltaTime);
29    }
30  }
31
32  void Render(SDL_Surface* Surface) {
33    for (EntityPtr& Entity : Entities) {
34      Entity->Render(Surface);
35    }
36  }
37
38private:
39  EntityPtrs Entities;
40};

1#pragma once
2#include "Vec2.h"
3#include "Component.h"
4
5class TransformComponent : public Component {
6public:
7  using Component::Component;
8
9  Vec2 GetPosition() const { return Position; }
10
11  void Move(const Vec2& Movement) {
12    Position += Movement;
13  }
14
15private:
16  Vec2 Position{0, 0};
17};

Summary

We've significantly improved our input system by implementing the command design pattern. Instead of directly manipulating components based on input events, we now create Command objects that represent the desired action. This separation enhances flexibility and maintainability.

We saw how this pattern benefits key customization, NPC control, and potentially advanced features like undo. We integrated command execution into our Entity class and used std::unordered_map to build a data-driven key binding mechanism using command factories.

Key takeaways:

• The command pattern encapsulates requests as objects (e.g., MovementCommand).
• It decouples the invoker (input handler) from the receiver (entity).
• We can use it to allow key mapping using std::unordered_map.
• It allows different sources (player input, AI) to issue the same commands.
• Commands can store state for execution and potentially undo operations.
• Using command factories (std::function) in maps provides flexibility for command creation.

Next Lesson

Creating an Image Component

Display graphics by creating an ImageComponent that loads files and renders them via SDL_image.

ContinueView Course