Handling Object Collisions

A common requirement we will have when implementing our game logic is a need to understand not just when a collision happened, but the nature of that collision.

For example, our HandleCollisions() function may encounter a situation like the following:

It's not entirely clear how this should be resolved. If the player got into this situation by falling down, the expected resolution would be to push the character back up. But, if they got into this situation by jumping into the wall from the left, the natural response would be to push the character back to the left:

To understand how to resolve this situation, our HandleCollisions() function often needs to get a deeper understanding of how this situation arose. This might involve tactics like:

• Checking the velocity of the player
• Comparing the positions of the colliding objects
• Comparing the width and height of the intersection rectangle

Ultimately, how we react to any collision will be a judgment call based on the needs of our game. The following code shows some examples of how we can get more information on the nature of the collision, and the state of our objects when it happened:

1// ...
2
3void GameObject::HandleCollisions() {
4  isOnGround = false;
5  for (const GameObject& O
6    : Scene.GetObjects()
7  ) {
8    // Prevent self-collision
9    if (&O == this) continue;
10
11    SDL_FRect Intersection;
12    if (Bounds.GetIntersection(
13      O.Bounds, &Intersection
14    )) {
15      if (Velocity.x > 0) {
16        std::cout << "I was moving right\n";
17      }
18      if (Velocity.y >= 0) {
19        std::cout << "I wasn't falling\n";
20      }
21      if (Position.x < O.Position.x) {
22        std::cout << "I'm to the left of the "
23          "object I collided with\n";
24      }
25      if (Intersection.h > Intersection.w) {
26        std::cout << "The intersection is "
27          "mostly vertical\n";
28      }
29
30      std::cout << "I think I should be pushed "
31        "to the left";
32      Position.x -= Intersection.w;
33    }
34  }
35}

1I was moving right
2I wasn't falling
3I'm to the left of the object I collided with
4The intersection is mostly vertical
5I think I should be pushed to the left

Previous Position

We can also keep track of additional data to assist our collision system in determining how it should resolve collisions. A frequently useful addition is to keep track of both the previous position and the current position of the object.

This lets our HandleCollisions() function retrieve both the Position and PreviousPosition of the object, which can further help it understand how it should react.

For more complex simulations, our object may need to be comprised of multiple bounding boxes. For example, we might need to determine if objects hit our player's weapon, shield, or body:

We can create many mechanics with a single bounding box and some clever logic.

For example, classic platformer games typically have mechanics where jumping on the head of an enemy defeats them, but hitting any other part causes the player to lose a life.

An intuitive approach to solve this problem might be to add separate bounding boxes for the head and the body, but this is rarely necessary. Instead, the illusion can be created with a single bounding box, and comparing the state of the objects at the time they intersect:

1// ...
2
3void GameObject::HandleCollisions() {
4  isOnGround = false;
5  for (const GameObject& O
6    : Scene.GetObjects()
7  ) {
8    // Prevent self-collision
9    if (&O == this) continue;
10
11    SDL_FRect Intersection;
12    if (Bounds.GetIntersection(
13      O.Bounds, &Intersection
14    )) {
15      if (Position.y < O.Position.y) {
16        std::cout << "I landed on his head";
17      }
18    }
19  }
20}

In a more complex game, our objects can collide with many different things, such as enemies, walls, and projectiles.

If the player collides with a wall, we might want to change their position but, if they collide with a projectile, perhaps we want to reduce their health instead.

In a real project, it is typically the case that our objects will use some form of component system (which we introduce in the next chapter) or inheritance based on a polymorphic base type.

With a polymorphic approach, we can add a virtual method for retrieving information as to the type of the object. Derived types can override those functions as needed.

In the following example, we add GetType(), GetTypeName() and HasType() functions to our GameObject base type. We then add Player, Floor, and Projectile base types that override them:

1// ...
2enum class GameObjectType {
3  GameObject, Player, Projectile, Floor
4};
5
6class GameObject {
7public:
8  virtual GameObjectType GetType() {
9    return GameObjectType::GameObject;
10  }
11
12  virtual std::string GetTypeName() {
13    return "GameObject";
14  }
15
16  bool HasType(GameObjectType TargetType) {
17    return GetType() == TargetType;
18  }
19
20  virtual ~GameObject() = default;
21  // ...
22};
23
24class Player : public GameObject {
25public:
26  using GameObject::GameObject;
27  GameObjectType GetType() override {
28    return GameObjectType::Player;
29  }
30
31  std::string GetTypeName() override {
32    return "Player";
33  }
34};
35
36class Floor: public GameObject {
37public:
38  using GameObject::GameObject;
39  GameObjectType GetType() override {
40    return GameObjectType::Floor;
41  }
42  std::string GetTypeName() override {
43    return "Floor";
44  }
45};
46
47class Projectile : public GameObject {
48public:
49  using GameObject::GameObject;
50  GameObjectType GetType() override {
51    return GameObjectType::Projectile;
52  }
53  std::string GetTypeName() override {
54    return "Projectile";
55  }
56};

Implementing Polymorphism

To implement run-time polymorphism, systems like our Scene and physics code will be working with pointers or references to that polymorphic base type. For example, rather than managing a collection of GameObject instances, our Scene might manage a collection of GameObject pointers, or smart pointers:

1// ...
2#include <memory> // for std::unique_ptr
3
4// Adding some type aliases to reduce noise
5using GameObjectPtr = std::unique_ptr<GameObject>;
6using GameObjects = std::vector<GameObjectPtr>;
7
8class Scene {
9public:
10  Scene() {
11    Objects.emplace_back(std::make_unique<Player>(
12      "dwarf.png",
13      Vec2{
14        2 * PIXELS_PER_METER,
15        4 * PIXELS_PER_METER
16      },
17      1.9f * PIXELS_PER_METER,
18      1.7f * PIXELS_PER_METER,
19      *this,
20      true
21    ));
22
23    Objects.emplace_back(std::make_unique<Floor>(
24      "floor.png",
25      Vec2{
26        3.0f * PIXELS_PER_METER,
27        5.0f * PIXELS_PER_METER
28      },
29      2.0f * PIXELS_PER_METER,
30      2.0f * PIXELS_PER_METER,
31      *this,
32      false
33    ));
34  }
35  
36  const std::vector<GameObject>& GetObjects() const {
37  const GameObjects& GetObjects() const {
38    return Objects;
39  }
40
41  // ...
42
43private:
44  std::vector<GameObject> Objects;
45  GameObjects Objects;
46};

We also need to update Render(), Tick(), and HandleEvent() to handle each object now being a GameObjectPtr (which is an alias for std::unique_ptr<GameObject>) rather than a simple GameObject:

1// ...
2
3class Scene {
4  // ...
5  void HandleEvent(SDL_Event& E) {
6    for (GameObjectPtr& Object : Objects) {
7      Object->HandleEvent(E);
8    }
9  }
10
11  void Tick(float DeltaTime) {
12    for (GameObjectPtr& Object : Objects) {
13      Object->Tick(DeltaTime);
14    }
15  }
16  
17  void Render(SDL_Surface* Surface) {
18    for (GameObjectPtr& Object : Objects) {
19      Object->Render(Surface);
20    }
21  }
22  // ...
23};

Our HandleCollisions() function will need similar updates:

1// ...
2void GameObject::HandleCollisions() {
3  isOnGround = false;
4  // Updating the type from GameObject to GameObjectPtr
5  for (const GameObjectPtr& O : Scene.GetObjects()) {
6    // Replacing the & operator with .get()
7    if (O.get() == this) continue;
8
9    SDL_FRect Intersection;
10    if (Bounds.GetIntersection(
11      // Replacing the . operator with ->
12      O->Bounds, &Intersection
13    )) {
14      isOnGround = true;
15      Position.y -= Intersection.h;
16      Velocity.y = 0;
17    }
18  }
19}

Depending on the state of your code, there may be other updates required to accomodate this switch to using pointers. The changes are typically going to involve the following:

• Updating . operators to be ->
• Converting a std::unique_ptr<GameObject> to a GameObject or GameObject& using the * operator: *SomePointer
• Converting a std::unique_ptr<GameObject> to a raw GameObject* using the get() method: SomePointer.get()

Using Polymorphism

Now that we've split our game objects across multiple types, our collision system has more information with which to determine its reaction. Below, we log out the what type of object we collided with, and restricted our previous logic to only be used if we collided with a floor type:

1// ...
2
3void GameObject::HandleCollisions() {
4  isOnGround = false;
5  for (const GameObjectPtr& O : Scene.GetObjects()) {
6    if (O.get() == this) continue;
7
8    SDL_FRect Intersection;
9    if (Bounds.GetIntersection(
10      O->Bounds, &Intersection
11    )) {
12      std::cout << "I hit a " << O->GetTypeName();
13      if (O->HasType(GameObjectType::Floor)) {
14        std::cout << "\nReacting to floor..."
15        isOnGround = true; 
16        Position.y -= Intersection.h;
17        Velocity.y = 0;
18      }
19    }
20  }
21}

1I hit a floor
2Reacting to floor...
3I hit a floor
4Reacting to floor...
5...

Text Replacement Macros

We now have a problem that commonly occurs with polymorphic systems. Our child classes are expected to override some simple inherited functions in a predictable, repeated pattern:

1class Projectile : public GameObject {
2public:
3  using GameObject::GameObject;
4
5  GameObjectType GetType() override {
6    return GameObjectType::Projectile;
7  }
8
9  std::string GetTypeName() override {
10    return "Projectile";
11  }
12};

As we covered before, we'd usually want to simplify and standardize the overriding of these methods, so we can provide a macro. It might look something like this:

1#define GAME_OBJECT_TYPE(TypeName)     \
2  GameObjectType GetType() override {  \
3    return GameObjectType::TypeName;   \
4  }                                    \
5                                       \
6  std::string GetTypeName() override { \
7    return #TypeName;                  \
8  }                                    \

Using this macro in a derived class would look like this:

1class Projectile : public GameObject {
2public:
3  using GameObject::GameObject;
4  GAME_OBJECT_TYPE(Projectile)
5};

We covered text replacement macros in more detail in our introductory course

With our system now set up, we can add depth with a similar approach we use for any other polymorphic system.

Below, we add a CanPassThrough() method that determines whether our type is a solid object like the floor or something that objects can move through such as light foliage. This is set to true on the base class, but derived classes can override it:

1// ...
2
3class GameObject {
4public:
5  virtual bool CanPassThrough() { return true; };
6  // ...
7};
8
9// ...
10
11class Floor : public GameObject {
12 public:
13  using GameObject::GameObject;
14  GAME_OBJECT_TYPE(Floor)
15
16  bool CanPassThrough() override { return false; }
17};

We can also add an OnHit() method to our base class, which subtypes can override to create more complex hit interactions. Below, our Projectile type uses this to inflict damage if it hits a Player:

1// ...
2
3class GameObject {
4public:
5  virtual void OnHit(GameObject& Target) {}
6  // ...
7};
8
9// ...
10class Player : public GameObject {
11 public:
12  using GameObject::GameObject;
13  GAME_OBJECT_TYPE(Player)
14
15  void TakeDamage(int Damage) {
16    Health -= Damage;
17  }
18
19private:
20  int Health{100};
21};
22
23class Projectile : public GameObject {
24 public:
25  using GameObject::GameObject;
26  GAME_OBJECT_TYPE(Projectile)
27
28  void OnHit(GameObject& Target) override {
29    if (Player* P{dynamic_cast<Player*>(&Target)}) {
30      P->TakeDamage(10);
31    }
32  }
33};

Integrating these new capabilities with our collision system would look something like this:

1// ...
2
3void GameObject::HandleCollisions() {
4  isOnGround = false;
5  for (const GameObjectPtr& O : Scene.GetObjects()) {
6    if (O.get() == this) continue;
7
8    SDL_FRect Intersection;
9    if (Bounds.GetIntersection(
10      O->Bounds, &Intersection
11    )) {
12      O->OnHit(*this);
13      if (O->CanPassThrough()) {
14        // I can pass through this object - no need
15        // to change my position or velocity
16        continue;
17      }
18
19      if (O->HasType(GameObjectType::Floor)) {
20        isOnGround = true;
21        Position.y -= Intersection.h;
22        Velocity.y = 0;
23      }
24    }
25  }
26}

We've included the complete versions of our GameObject and Scene classes below, containing all the techniques and concepts we covered in this lesson.

To keep things simple, we've removed the intersection and relevancy-testing code from the previous lesson:

In this lesson, we made our game objects interact by implementing a collision system. We replaced arbitrary position limits with detection logic based on bounding box intersections.

We focused on resolving collisions by correcting object positions and velocities, particularly for floor interactions, and applied polymorphism to allow varied responses depending on what objects are colliding.

• Check for collisions by iterating through scene objects and testing bounding box intersections, skipping self-collision checks.
• The intersection rectangle (SDL_FRect) provides data (width, height) useful for resolving the collision.
• Basic floor collision response involves moving the object up by the intersection height and zeroing vertical velocity.
• Use flags like isOnGround to communicate collision state to other parts of the game logic (e.g., jumping).
• More advanced resolution considers collision angle/sides by comparing intersection width and height or object velocities.
• Object-oriented design with virtual methods enables defining specific behaviors (like damage on hit or pass-through ability) for different object types.
• Using smart pointers like std::unique_ptr manages memory for polymorphic objects stored in collections like std::vector.