Ticking

We can now use inheritance and polymorphism (overriding virtual functions) to support a variety of GameObject types. Let's update our program to support Goblin objects:

1// Goblin.h
2#pragma once
3#include <string>
4#include "GameObject.h"
5
6class Goblin : public GameObject {
7 public:
8  Goblin(const std::string& name, int x, int y)
9    : Name(name), xPosition(x), yPosition(y) {}
10
11  std::string Name;
12  int xPosition;
13  int yPosition;
14};

We'll add a SpawnGoblin() method to the World class, which will create a GameObject managed by that World when called. This function will also return a reference to the spawned object, so callers can access it if needed:

1// World.h
2// ...
3class World {
4 public:
5  Goblin& SpawnGoblin(
6    const std::string& Name, int x, int y
7  ) {
8    Objects.emplace_back(
9      std::make_unique<Goblin>(Name, x, y)
10    );
11    return static_cast<Goblin&>(*Objects.back());
12  }
13  // ...
14
15 private:
16  std::vector<std::unique_ptr<GameObject>> Objects;
17};

1// main.cpp
2// ...
3int main(int argc, char** argv){
4  // ...
5  World GameWorld;
6  Goblin& Enemy{GameWorld.SpawnGoblin(
7    "Goblin Rogue", 100, 200)};
8  std::cout << "A " << Enemy.Name
9    << " was spawned in the world";
10    
11  // ...
12}

1A Goblin Rogue was spawned in the world

Finally, we can now override the Tick() function for our Goblin objects. Let's allow our goblins to move regardless of whether any events are happening:

1// Goblin.h
2#pragma once
3#include <string>
4#include "GameObject.h"
5
6class Goblin : public GameObject {
7 public:
8  Goblin(const std::string& name, int x, int y)
9      : Name(name), xPosition(x), yPosition(y) {}
10
11  std::string Name;
12  int xPosition;
13  int yPosition;
14
15  void Tick() override {
16    std::cout << "\nTick() updating position";
17    xPosition += 1;
18  }
19
20  void Render(SDL_Surface* Surface) override {
21    std::cout
22      << " - Rendering at x = " << xPosition;
23    // ...
24  }
25};

1A Goblin Rogue was spawned in the world
2Tick() updating position - Rendering at x = 101
3Tick() updating position - Rendering at x = 102
4Tick() updating position - Rendering at x = 103
5...

If needed, they can also react to events in addition to ticking. When the player presses an arrow key, let's change the direction our Goblin moves on each tick:

1// Goblin.h
2// ...
3class Goblin : public GameObject {
4 public:
5  // ...
6  int Velocity{1};
7
8  void HandleEvent(SDL_Event& E) {
9    if (E.type != SDL_KEYDOWN) return;
10    if (E.key.keysym.sym == SDLK_RIGHT) {
11      std::cout << "\nHandleEvent() setting "
12        "velocity to 1";
13      Velocity = 1;
14    } else if (E.key.keysym.sym == SDLK_LEFT) {
15      std::cout << "\nHandleEvent() setting "
16        "velocity to -1";
17      Velocity = -1;
18    }
19  }
20
21  void Tick() override {
22    std::cout << "\nTick() updating position";
23    xPosition += Velocity;
24  }
25  
26  // ...
27};

1A Goblin Rogue was spawned in the world
2Tick() updating position - Rendering at x = 101
3Tick() updating position - Rendering at x = 102
4HandleEvent() setting velocity to -1
5Tick() updating position - Rendering at x = 101
6...

In complex projects, updating objects often depends on the state of other objects in the world. For example, consider a UI element that appears attached to one of our game objects:

1// NameTag.h
2#pragma once
3#include "GameObject.h"
4#include "Goblin.h"
5
6class NameTag : public GameObject {
7 public:
8  Goblin& Parent;
9
10  void Tick() override {
11    // Are these arguments correct?
12    // It's unclear whether Parent has ticked yet
13    SomeFunction(
14      Parent.xPosition,
15      Parent.yPosition
16    )
17  }
18};

The issue here is that we don't know the order in which our objects' Tick() functions are called. If Parent ticks before NameTag, there's no problem. However, if NameTag ticks first, the Parent.xPosition and Parent.yPosition values will not have been updated yet, resulting in stale data.

Using these stale values means our NameTag's position will be based on where the Goblin was in the previous frame, not the current frame. As a result, our NameTag will lag one frame behind the Goblin object it's supposed to be attached to.

These off-by-one-frame issues are extremely common, even in major released projects. They're difficult to notice explicitly, especially when many things are happening on-screen simultaneously. However, they contribute to a general feeling that our game is less responsive than it should be, so it's worth preventing these problems where possible.

In complex projects, the architecture to manage these inter-object dependencies can get quite elaborate. A common and simple first step involves breaking our tick process into multiple phases and establishing a convention on what type of updates should be performed in each phase.

For example, we could split our ticking into two phases: TickPhysics(), followed by TickUI():

1// Application Loop
2while (shouldContinue) {
3  // Handle Events
4  while (SDL_PollEvent(&Event)) {
5    // ...
6  }
7
8  // Update Objects
9  GameWorld.TickPhysics();  
10  GameWorld.TickUI();  
11
12  // Render Objects
13  GameWindow.Render();
14  GameWorld.Render(GameWindow.GetSurface());
15
16  // Update Frame
17  GameWindow.Update();
18}

We can then establish the convention that any code that updates the physical state of our world belongs in TickPhysics(). Our TickUI() functions are called after all objects have had their TickPhysics() functions called, so any code in a TickUI() function can be confident that our object's positions in the world are up to date:

1// NameTag.h
2// ...
3class NameTag : public GameObject {
4 public:
5  NameTag(const Goblin& Parent)
6  : Parent(Parent) {}
7
8  Goblin& Parent;
9  int xPosition;
10  int yPosition;
11
12  void TickUI() override {
13    // We know these values have been updated
14    // because TickPhysics() happens before TickUI()
15    xPosition = Parent.xPosition;
16    yPosition = Parent.yPosition;
17  }
18};

The GameWorld.SpawnGoblin(Name, x, y) approach in this section was used to simplify memory management. It absolves consumers from needing to manage the lifecycle of their GameObject instances, as it is all handled by the World class.

However, larger projects can have hundreds or thousands of GameObject subtypes. Therefore, scaling this technique would involve adding an additional method to our World class for each subtype, and potentially multiple methods if the type has multiple constructors.

1// World.h
2// ...
3class World {
4public:
5  Goblin& SpawnGoblin(int Arg1, int Arg2) {
6    // ...
7  }
8  
9  Dragon& SpawnDragon(int Arg1) {
10    // ...
11  }
12  
13  // The Dragon type has multiple constructors
14  Dragon& SpawnDragon(int Arg1, float Arg2) {
15    // ...
16  }
17  
18  // ...
19}

We could solve this by creating objects outside of our World, and then transferring ownership:

1// World.h
2// ...
3class World {
4public:
5  void AddObject(std::unique_ptr<GameObject> Object) {
6    // ...
7  }
8}

1auto Enemy1{std::make_unique<Goblin>(100, 200)};
2World.AddObject(std::move(Enemy1));
3
4auto Enemy2{std::make_unique<Dragon>(50)};
5World.AddObject(std::move(Enemy2));
6
7auto Enemy3{std::make_unique<Dragon>(100, 0.5f)};
8World.AddObject(std::move(Enemy3));

We can make this API simpler and less error-prone. For comparison, the Unreal Engine API for creating objects in the world looks like this:

1GetWorld()->SpawnActor<Goblin>(100, 200);
2GetWorld()->SpawnActor<Dragon>(50);
3GetWorld()->SpawnActor<Dragon>(100, 0.5f);

However, implementing this requires more complex C++ techniques that may be unfamiliar, so don't worry if this is difficult to follow. It's not required for this course and is only included as a reference:

1// World.h
2// ...
3class World {
4 public:
5  template <typename T, typename... Args>
6  T& SpawnObject(Args&&... args) {
7    Objects.emplace_back(std::make_unique<T>(
8      std::forward<Args>(args)...));
9
10    return static_cast<T&>(*Objects.back());
11  }
12  // ...
13};

We introduce these techniques and cover them in more detail in our advanced course. They include:

• Function templates , which enable the compiler to create functions at compile time, based on template arguments we provide between < and > tokens. In the following example, we're using the Player and Goblin types as a template argument.
• The ... syntax, which allows us to create variadic functions . Variadic functions can handle a variable number of parameters. In this example, we're collecting an unknown number of parameters to forward to the constructor of the type we passed as a template argument.
• The std::forward function, which implements perfect forwarding . This allows arguments to be forwarded from one function to another in a way that respects their value category.

Our more flexible API can be used like this:

1// main.cpp
2// ...
3int main(int argc, char** argv){
4  // ...
5  World GameWorld;
6  
7  Player& PlayerOne{
8    GameWorld.SpawnObject<Player>(
9      "Player One"
10    )};
11    
12  Goblin& Enemy{
13    GameWorld.SpawnObject<Goblin>(
14      "Goblin", 100, 200
15    )};
16  // ...
17}

This lesson introduced the concept of ticking in game development using C++ and SDL2:

• We introduced tick functions, and how we can use them to allow our objects to update their state on every frame.
• We created GameObject and World classes to manage multiple game objects and remove complexity from our application loop.
• We discussed potential issues like off-by-one-frame errors and how to mitigate them.
• Finally, we explored advanced techniques for generalizing object creation in larger projects.