Ticking
Using Tick()
functions to update game objects independently of events
In our previous projects, we've updated the state of our objects based on events detected in our application loop:
// Application Loop
while (shouldContinue) {
// Handle Events
while (SDL_PollEvent(&Event)) {
if (Event.type == SDL_QUIT) {
shouldContinue = false;
}
GameObject.HandleEvent(Event);
}
// Render Objects
GameWindow.Render();
GameObject.Render(GameWindow.GetSurface());
// Update Frame
GameWindow.Update();
}
However, in more complex projects, most objects may need to update their state consistently, even when they're not receiving any events. For example, characters not controlled by our player may need to continue to act and move, and animation, and visual effects should continue to update.
Tick Functions
To implement this capability, our applications can introduce the notion of ticking. On every iteration of our application loop, we call a function on our objects that allows them to update their state.
These are commonly called tick functions:
// Application Loop
while (shouldContinue) {
// Handle Events
while (SDL_PollEvent(&Event)) {
if (Event.type == SDL_QUIT) {
shouldContinue = false;
}
GameObject.HandleEvent(Event);
}
// Update Objects
GameObject.Tick();
// Render Objects
GameWindow.Render();
GameObject.Render(GameWindow.GetSurface());
// Update Frame
GameWindow.Update();
}
Game Objects and Worlds
Complex projects can have thousands or millions of objects that are ticking on every frame, so we commonly use an intermediate object to manage this complexity
Let's have all of our game objects inherit from a standard base class:
// GameObject.h
#pragma once
#include "SDL.h"
class GameObject {
public:
virtual void HandleEvent(SDL_Event& E) {
// ...
}
virtual void Tick() {
// ...
}
virtual void Render(SDL_Surface* Surface) {
// ...
}
};
We'll create a World
class that manages all of the game objects in our world. When our main application loop prompts our world to handle an event, tick, or render, we'll forward that instruction to all of our objects:
// World.h
#pragma once
#include <vector>
#include <memory>
#include "GameObject.h"
class World {
public:
void HandleEvent(SDL_Event& E) {
for (auto& Object : Objects) {
Object->HandleEvent(E);
}
}
void Tick() {
for (auto& Object : Objects) {
Object->Tick();
}
}
void Render(SDL_Surface* Surface) {
for (auto& Object : Objects) {
Object->Render(Surface);
}
}
private:
std::vector<std::unique_ptr<GameObject>> Objects;
}
Let's update our main application loop to use our new class:
// main.cpp
#include <SDL.h>
#include "Window.h"
#include "World.h"
int main(int argc, char** argv){
SDL_Init(SDL_INIT_VIDEO);
Window GameWindow;
World GameWorld;
SDL_Event Event;
bool shouldContinue{true};
// Application Loop
while (shouldContinue) {
// Handle Events
while (SDL_PollEvent(&Event)) {
if (Event.type == SDL_QUIT) {
shouldContinue = false;
}
GameWorld.HandleEvent(Event);
}
// Update Objects
GameWorld.Tick();
// Render Objects
GameWindow.Render();
GameWorld.Render(GameWindow.GetSurface());
// Update Frame
GameWindow.Update();
}
SDL_Quit();
return 0;
}
Game Object Subtypes
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:
// Goblin.h
#pragma once
#include <string>
#include "GameObject.h"
class Goblin : public GameObject {
public:
Goblin(const std::string& name, int x, int y)
: Name(name), xPosition(x), yPosition(y) {}
std::string Name;
int xPosition;
int yPosition;
};
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:
// World.h
// ...
class World {
public:
Goblin& SpawnGoblin(
const std::string& Name, int x, int y
) {
Objects.emplace_back(
std::make_unique<Goblin>(Name, x, y)
);
return static_cast<Goblin&>(*Objects.back());
}
// ...
private:
std::vector<std::unique_ptr<GameObject>> Objects;
};
// main.cpp
// ...
int main(int argc, char** argv){
// ...
World GameWorld;
Goblin& Enemy{GameWorld.SpawnGoblin(
"Goblin Rogue", 100, 200)};
std::cout << "A " << Enemy.Name
<< " was spawned in the world";
// ...
}
A 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:
// Goblin.h
#pragma once
#include <string>
#include "GameObject.h"
class Goblin : public GameObject {
public:
Goblin(const std::string& name, int x, int y)
: Name(name), xPosition(x), yPosition(y) {}
std::string Name;
int xPosition;
int yPosition;
void Tick() override {
std::cout << "\nTick() updating position";
xPosition += 1;
}
void Render(SDL_Surface* Surface) override {
std::cout
<< " - Rendering at x = " << xPosition;
// ...
}
};
A Goblin Rogue was spawned in the world
Tick() updating position - Rendering at x = 101
Tick() updating position - Rendering at x = 102
Tick() updating position - Rendering at x = 103
...
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:
// Goblin.h
// ...
class Goblin : public GameObject {
public:
// ...
int Velocity{1};
void HandleEvent(SDL_Event& E) {
if (E.type != SDL_KEYDOWN) return;
if (E.key.keysym.sym == SDLK_RIGHT) {
std::cout << "\nHandleEvent() setting "
"velocity to 1";
Velocity = 1;
} else if (E.key.keysym.sym == SDLK_LEFT) {
std::cout << "\nHandleEvent() setting "
"velocity to -1";
Velocity = -1;
}
}
void Tick() override {
std::cout << "\nTick() updating position";
xPosition += Velocity;
}
// ...
};
A Goblin Rogue was spawned in the world
Tick() updating position - Rendering at x = 101
Tick() updating position - Rendering at x = 102
HandleEvent() setting velocity to -1
Tick() updating position - Rendering at x = 101
...
Dependencies and Off-By-One-Frame Errors
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:
// NameTag.h
#pragma once
#include "GameObject.h"
#include "Goblin.h"
class NameTag : public GameObject {
public:
Goblin& Parent;
void Tick() override {
// Are these arguments correct?
// It's unclear whether Parent has ticked yet
SomeFunction(
Parent.xPosition,
Parent.yPosition
)
}
};
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()
:
// Application Loop
while (shouldContinue) {
// Handle Events
while (SDL_PollEvent(&Event)) {
// ...
}
// Update Objects
GameWorld.TickPhysics();
GameWorld.TickUI();
// Render Objects
GameWindow.Render();
GameWorld.Render(GameWindow.GetSurface());
// Update Frame
GameWindow.Update();
}
If we then establish the convention that any code that updates the physical state of our world belongs in TickPhysics()
, any logic in an overloaded TickUI()
function can be confident that those world positions are up to date:
// NameTag.h
// ...
class NameTag : public GameObject {
public:
NameTag(const Goblin& Parent)
: Parent(Parent) {}
Goblin& Parent;
int xPosition;
int yPosition;
void TickUI() override {
// We know these values have been updated
// because TickPhysics() happens before TickUI()
xPosition = Parent.xPosition;
yPosition = Parent.yPosition;
}
};
Summary
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
andWorld
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.
Tick Rate and Time Deltas
Learn how to create smooth, time-aware game loops that behave consistently across different hardware configurations