Now that we understand basic motion in our game engine, it's time to explore the forces that drive that motion. In this lesson, we'll implement several physical forces including gravity, drag, and friction.

We'll see how each affects our game objects differently based on their properties like mass and velocity. These techniques will allow you to create more realistic and engaging gameplay.

In this lesson, we'll continue to use the basic application loop and components we introduced in the previous lesson. We'll mostly be working in the GameObject class in this lesson.

It currently looks like the following, with the most notable characteristics being the Position, Velocity, and Acceleration vectors, and the Tick() function that updates them:

1// GameObject.h
2#pragma once
3#include <SDL.h>
4#include "Vec2.h"
5#include "Image.h"
6
7class Scene;
8
9class GameObject {
10 public:
11  GameObject(
12    const std::string& ImagePath,
13    const Vec2& InitialPosition,
14    const Scene& Scene ) : Image{ImagePath},
15                           Position{InitialPosition},
16                           Scene{Scene} {}
17
18  void HandleEvent(SDL_Event& E) {}
19
20  void Tick(float DeltaTime) {
21    Velocity += Acceleration * DeltaTime; 
22    Position += Velocity * DeltaTime; 
23  }
24
25  void Render(SDL_Surface* Surface);
26
27 private:
28  Vec2 Position{0, 0}; 
29  Vec2 Velocity{0, 0}; 
30  Vec2 Acceleration{0, 0}; 
31  Image Image;
32  const Scene& Scene;
33};

Forces

In the previous section, we saw that a change in an object's speed, or velocity, is called acceleration. Something that causes an object to accelerate is called a force.

For example, the acceleration from gravity is caused by the gravitational force. Or, by simply pushing an object, we are exerting a force on it, causing it to accelerate.

Mass

More powerful forces cause more acceleration but, conversely, heavier objects require more force to accelerate. This relationship has the following equation, which is usually shorted to $F = MA$ :

\text{Force} = \text{Mass} \times \text{Acceleration}

For example, if we had an object with a mass of two kilograms ( $kg$ ), and we wanted to accelerate it by $3m/s^2$ , we would multiply these two values to calculate the required force:

\begin{align} \text{Force} &= 2kg \times 3m/s^2 \\ &= 6kg \times m/s^2 \end{align}

These $kg \times m/s^2$ units are given a simpler name: Newtons, abbreviated $N$ :

\begin{align} \text{Force} &= 2kg \times 3m/s^2 \\ &= 6N \end{align}

Directional Forces

Forces can apply acceleration in a specific direction so, like other directional types, we can represent them using vectors:

1Vec2 Force;

Similarly, we can determine the overall magnitude of a force by calculating the magnitude of that vector:

1Vec2 Force{3, 4};
2std::cout << Force.Length();

The $F = MA$ relationship applies whether $F$ and $A$ have a scalar type like float, or a vector type like Vec2.

Unlike velocity, whose magnitude is called speed, the magnitudes of force and acceleration do not have a specific name. In mathematical writing, we'd differentiate them in the typical ways, such as using bold for vectors and vertical bars to denote the magnitude of vectors. For example: $\bold{F} = M \bold{A}$ and $\lvert \bold{F} \rvert = M \lvert \bold{A} \rvert$ .

However, informally, people often use "magnitude" and "force" for both the vector and scalar forms. We can usually infer which form is being used based on the context. If it's the name of a variable in a program, we can generally tell based on the data type (eg float vs Vec2)

Implementing Forces and Reaction

Practically, the main reason we may want to implement forces in our games is for scenarios where we have a single force that we want to affect many objects.

For example, let's imagine we want to simulate a gust of wind that acts on our whole scene. This becomes quite easy if our objects have some generic ApplyForce() function, and they each have an individual Mass variable to use in the $F = MA$ relationship:

1// Scene.h
2// ...
3
4class Scene {
5public:
6 // ...
7  void Tick(float DeltaTime) {
8    for (GameObject& Object : Objects) {
9      Object.ApplyForce({1, 0});
10      Object.Tick(DeltaTime);
11    }
12  }
13  // ...
14};

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  void ApplyForce(const Vec2& Force) {
8    // TODO: Update Acceleration
9  }
10  // ...
11 private:
12  float Mass{50};
13  // ...
14};

To help with this, the $F = MA$ equation can be rearranged as needed. One such rearrangement is $A = F/M$ , meaning we can calculate the acceleration we need to apply in response to a force by dividing that force by the mass of the object.

For example, if $10N$ of force is applied to an object of mass $5kg$ , that object should be accelerated by $10/5 = 2 m/s^2$ . We can calculate the acceleration that results from a force, and add it to our current Acceleration like this:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  void ApplyForce(const Vec2& Force) {
8    Acceleration += Force / Mass;
9  }
10  // ...
11};

The same force applied across all objects in our Scene will now impart a rightward acceleration, and the magnitude of that acceleration will be based on each object's individual mass.

A screenshot of our scene showing the application of a force

We don't want forces applied in previous frames to accumulate so we need to reset our acceleration to some initial value at the start or end of each frame. Common choices are $(0, 0)$ , or $(0, -9.8)$ if this is how we're implementing gravity:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  void Tick(float DeltaTime) {
8    Velocity += Acceleration * DeltaTime;
9    Position += Velocity * DeltaTime;
10    Acceleration = {0, -9.8};
11  }
12  // ...
13};

Multiple Forces

Using vectors makes the application of multiple forces straightforward. We can simply apply each force in turn to the acceleration vector. In this example, the second force counteracts the horizontal acceleration of the first force, and adds some downward force:

1// Scene.h
2// ...
3
4class Scene {
5public:
6  // ...
7  void Tick(float DeltaTime) {
8    for (GameObject& Object : Objects) {
9      Object.ApplyForce({1, 0});
10      Object.ApplyForce({-1, -1});
11      Object.Tick(DeltaTime);
12    }
13  }
14  // ...
15};

A screenshot of our scene showing the application of multiple forces

Vector addition is associative, so we can alternatively combine the force vectors then apply them to the acceleration:

1// Scene.h
2// ...
3
4class Scene {
5public:
6  // ...
7  void Tick(float DeltaTime) {
8    for (GameObject& Object : Objects) {
9      Object.ApplyForce(
10        Vec2{0.01, 0} + Vec2{-0.01, -0.01});
11      Object.Tick(DeltaTime);
12    }
13  }
14  // ...
15};

Below, we model a spaceship taking off, where we have three forces:

wind applying a mild sideward force from the scene.
an engine applying an upward force from within the object's class
gravity trying to force the ship back to the ground, applied directly to the object's Acceleration

1// Scene.h
2// ...
3
4class Scene {
5public:
6 // ...
7  void Tick(float DeltaTime) {
8    for (GameObject& Object : Objects) {
9      Object.ApplyForce(WindForce);
10      Object.Tick(DeltaTime);
11    }
12  }
13  // ...
14
15 private:
16  Vec2 WindForce{10, 0};
17  // ...
18};

Remember that forces update our Acceleration, so we should ensure all forces are applied before we use our acceleration value:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  void Tick(float DeltaTime) {
8    ApplyForce(EngineForce);
9    Velocity += Acceleration * DeltaTime;
10    Position += Velocity * DeltaTime;
11    Acceleration = {0, -9.8};
12  }
13  // ...
14 private:
15  Vec2 Acceleration{0, -9.8};
16  Vec2 EngineForce{0, 500};
17  // ...
18};

After combining all forces, our ship moves mostly upwards:

A screenshot of our scene showing the application of three forces

Gravitational Force

We previously established the $F=MA$ relationship, or equivalently the $A = F/M$ relationship. A good question at this point might be to ask why this relationship doesn't seem to apply to gravity.

If the gravitational force was constant, we'd expect heavy objects to be accelerated less - that is, as $M$ increases within the equation $A = F/M$ , then $A$ would decrease.

However, our observed experience shows that is not the case - heavy objects typically do not fall slower than lighter objects.

So, for $A = F/M$ to apply to gravity, that would mean the gravitational force, $F$ , cannot be a constant - it must affect different objects in different ways.

That is indeed the case - the reason that $A$ doesn't reduce as the mass of our object ( $M$ ) gets larger is that, if $F$ is the gravitational force, it also gets larger as $M$ gets larger.

The gravitational force is calculated as follows:

F = G \dfrac{m_1 \times m_2}{r^2}

In this equation:

$G$ is a tiny, fixed number called the gravitational constant
$m_1$ and $m_2$ are the masses of the objects involved. For example, $m_1$ could be the mass of the Earth, and $m_2$ could be the mass of the object we're simulating.
$r$ is the distance between the two objects' centers of gravity.

The distance between the two objects is labelled $r$ because, in most practical cases, it is the radius of something. For example, if we're calculating the force applied to an object on the surface of Earth, the distance between that object and the center of the Earth is equivalent to the radius of the Earth.

We can calculate the $9.8m/s^2$ acceleration value for gravity because we know the values of $G$ , $m_1$ (the mass of Earth), and $r$ (the distance from the center to the surface of Earth). We don't know in advance the mass of the object we're simulating, $m_2$ , but to calculate the acceleration from gravity, we don't need to know that value.

That is because we multiply by $m_2$ to calculate the gravitational force $F$ , but we then divide by that same mass to calculate the acceleration in $A = F/M$ . This multiplication and division by $m_2$ cancel each other out, so it doesn't matter what $m_2$ is - the acceleration from gravity will be the same regardless.

Drag

In our everyday lives, we've likely noticed that, when a force stops acting upon a moving object, that object tends to decelerate and eventually come to a stop.

The most common example of drag that we encounter is air resistance. As an object moves through the air, it experiences resistance from the air molecules, creating a force opposing the motion and causing it to gradually slow down.

We can simulate this effect as a decelerating force - that is, a force acting in the opposite direction to the object's current velocity:

A chart showing drag acting in the opposite direction to velocity

Drag is typically represented using a quadratic model, where the magnitude of the force is proportional to the square of the magnitude of the velocity. One way to calculate the square of a vector is to multiply it by its own length, so we can calculate a simple drag force like this:

1Vec2 GetDragForce() {
2  return -Velocity * Velocity.GetLength();
3}

The -Velocity * Velocity.GetLength() expression means both the direction and magnitude of the drag force are based on the object's current velocity:

Direction: The unary - operator ensures the direction of the force is acting in the opposite direction of the velocity because, if we have some vector $V$ , then $-V$ will point in the opposite direction.
Magnitude: By multiplying Velocity by its own length, the magnitude of the vector returned by GetDragForce() will be the square of the magnitude of the velocity. For example, the vector $(0, 4$ ) has a magnitude of $4$ . If we multiply $(0, 4)$ by $4$ , we get $(0, 16)$ , which has a magnitude of $16$ . This squaring is exactly what we want for the quadratic model of drag.

We can incorporate the drag force into our physics simulation, ensuring it updates the Acceleration before the Acceleration updates the Velocity:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  void Tick(float DeltaTime) {
8    ApplyForce(DragForce());
9    Velocity += Acceleration * DeltaTime;
10    Position += Velocity * DeltaTime;
11    Acceleration = {0, -9.8};
12  }
13  // ...
14};

Drag Coefficients

By itself, -Velocity * Velocity.GetLength() is a relatively simplistic way to represent drag. In the real world, the strength of the drag force depends on a lot of factors, including the size and shape of the object, the nature of its surface, and the particle density of whatever environment it is traveling through (such as air or water).

For example, a race car is designed to minimize the amount of drag it encounters, thereby increasing its maximum speed. A parachute has the exact opposite goal, so it is designed to maximize drag. An object encounters more drag if it's moving through water than if it were moving through air.

Typically, we just simplify all of these characteristics into a simple floating point number called a drag coefficient. We can modify on a per-object basis to modify the strength of the drag force:

1// GameObject.h
2// ...
3
4class GameObject {
5// ...
6 private:
7  float DragCoeffficient{0.2};
8  Vec2 GetDragForce() {
9    return -Velocity * Velocity.GetLength()
10      * DragCoefficient;
11  }
12  // ...
13};

Below, we simulate a character falling through the air. Once they deploy their parachute by pressing the spacebar, we increase the drag coefficient to slow their fall:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  void HandleEvent(SDL_Event& E) {
8    if (E.type == SDL_KEYDOWN) {
9      if (E.key.keysym.sym == SDLK_SPACE) {
10        DeployParachute();
11      }
12    }
13  }
14  // ...
15 private:
16  // ...
17  float DragCoefficient{0.2};
18  void DeployParachute() {
19    DragCoefficient = 30;
20  }
21  // ...
22};

Terminal Velocity

A common scenario we'll be simulating is a scenario where we have a force applying a constant acceleration in a given direction. Examples include an engine accelerating a vehicle forward, or gravity accelerating an object to the ground.

Given the nature of motion, a constant acceleration causes the velocity to change linearly. The relationship between gravity and the velocity of an object falling through the air might look something like this, where both acceleration and velocity point downwards (in the negative y direction):

A chart showing the effect of gravity without drag

However, in most scenarios, we also have drag acting on the object. Drag tries to slow the object down, and the strength of that effect increases as the velocity increases. When the velocity gets high enough, that drag force will be equal to the force coming from gravity (or whatever other force was causing the velocity to increase).

At that point, the drag and accelerative force will balance each other out, causing the net acceleration to be zero and the velocity to stop changing. The level at which the velocity stops changing in a given situation is called the terminal velocity or terminal speed.

A chart showing the effect of gravity with drag, resulting in terminal velocity

Revisiting our falling character example, we see gravity and drag balance each other out when our fall speed reaches around $58m/s$ :

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  void Tick(float DeltaTime) {
8    ApplyForce(DragForce());
9    Velocity += Acceleration * DeltaTime;
10    Position += Velocity * DeltaTime;
11
12    if (std::abs(Acceleration.y) < 0.1) {
13      std::cout << "\nTerminal Velocity: "
14        << Velocity;
15    }
16
17    Acceleration = {0, -9.8};
18  }
19  // ...
20};

1Terminal Velocity: { x = 0, y = -58.2389 }
2Terminal Velocity: { x = 0, y = -58.239 }
3Terminal Velocity: { x = 0, y = -58.2391 }
4...

If we deploy the parachute, thereby increasing the drag coefficient, our maximum falling speed reduces to around $4.8m/s$ :

1Terminal Velocity: { x = 0, y = -4.75522 }
2Terminal Velocity: { x = 0, y = -4.75534 }
3Terminal Velocity: { x = 0, y = -4.75546 }

Clamping

Because of the nature of drag calculations, and inherent inaccuracies with floating point numbers, it's somewhat common for objects to decelerate to extremely low velocities, but take an unreasonably long time to completely come to a stop.

This can lead to objects having tiny, twitching movements that look unnatural. To solve this, we typically choose to "clamp" or "snap" values to zero once they get sufficiently small.

It can take some experimenting to choose where to implement this and what values to use, but the following example shows a way to snap any velocities that fall between -0.1 and 0.1 to 0:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  void Tick(float DeltaTime) {
8    ApplyForce(DragForce());
9    Velocity += Acceleration * DeltaTime;
10    Position += Velocity * DeltaTime;
11
12    Acceleration = {0, -9.8};
13    Clamp(Velocity);
14  }
15  // ...
16  
17 private:
18  // ...
19  void Clamp(Vec2& V) {
20    V.x = std::abs(V.x) > 0.1 ? V.x : 0;
21    V.y = std::abs(V.y) > 0.1 ? V.y : 0;
22  }
23  // ...
24};

Friction

The final force we may want to consider modeling is friction. Friction acts upon an object that is sliding across another object, such as a skier on a mountain.

Similar to drag, the effect of friction is to cause the object to decelerate. Therefore, the direction of the friction force is opposite to the direction of velocity. The magnitude of the friction force $F$ depends on two factors:

\lvert F \rvert = \mu \times \lvert N \rvert

$\mu$ is the Greek letter mu, and represents the coefficient of friction between the two objects. Values of $\mu$ depend on the nature of the two surfaces and have been measured and published for many combinations.

For example, the $\mu$ for rubber on tarmac is usually above $1.0$ , whilst for a snowboard on snow it is usually under $0.1$ . For games, we typically just experiment and settle on values that feel good in gameplay.

$N$ is called the normal force, which the surface exerts on the object we're calculating friction for. In the simple case of an object moving over a horizontal surface, we can approximate $N$ as being equal to the mass of the object multiplied by its downward acceleration.

We won't cover more complex cases here but feel free to research the normal force in more detail if desired.

Implementing Friction

Let's see an example of applying friction to slow down an object. We calculate the magnitude of $N$ by multiplying the coefficient, mass, and downward acceleration. We then create a vector of this magnitude that points in the opposite direction of the velocity vector:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6   // ...
7    Vec2 FrictionForce(float DeltaTime) {
8    // |F| = u * |N|
9    float Magnitude{FrictionCoefficient
10      * Mass * -Acceleration.y};
11
12    // No friction
13    if (Magnitude <= 0) return Vec2(0, 0);
14    
15    // To calculate F, we multiply the magnitude by a
16    // normalized direction vector that points in the
17    // opposite direction to the velocity
18    return -Velocity.Normalize() * Magnitude;
19  }
20  // ...
21}

In its current form, this friction force can overpower small velocities, therefore moving objects in the opposite direction rather than simply stopping them.

To solve this, we can calculate the magnitude of the stopping force that would be required to reduce the object's velocity to $0$ , and ensure our friction force isn't stronger than that. Remember, $\text{Force} = \text{Mass} \times \text{Acceleration}$ , and $\text{Acceleration} = \text{Velocity} / \text{Time}$ :

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  Vec2 FrictionForce(float DeltaTime) {
8    // How much force can friction apply
9    float MaxMagnitude{FrictionCoefficient
10      * Mass * -Acceleration.y};
11
12    // There is no friction
13    if (MaxMagnitude <= 0) return Vec2(0, 0);
14    
15    // How much force is required to stop the
16    // object right now
17    float StoppingMagnitude{Mass *
18      Velocity.GetLength() / DeltaTime};
19      
20    // Return the smaller of the two forces
21    return -Velocity.Normalize() * std::min(
22      MaxMagnitude, StoppingMagnitude);
23  }
24  // ...
25};

Adding our friction simulation to our Tick() function might look like the following. As before, we should apply all of our forces before we use our Acceleration to update the Velocity, but it doesn't make a significant difference whether we apply friction or drag first.

Note that we need the downforce from gravity for our friction calculation to work correctly, but we'll add a check to ensure it doesn't cause our objects to fall through the floor. We'll introduce floor collisions later in the chapter to create a more robust way of doing this:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  void Tick(float DeltaTime) {
8    ApplyForce(FrictionForce(DeltaTime));
9    ApplyForce(DragForce());
10    Velocity += Acceleration * DeltaTime;
11    Position += Velocity * DeltaTime;
12    Acceleration = {0, -9.8};
13    Clamp(Velocity);
14    
15    // Don't fall through the floor
16    if (Position.y < 2) {
17      Position.y = 2;
18      Velocity.y = 0;
19    }
20  }
21  // ...
22};

Changing Friction

As with drag, we can update our friction coefficient at run-time based on our game state.

Below, we modify the amount of friction an object encounters based on its position in the world. We reduce the friction coefficient when the object is in an icy area, and set it to 0 (removing the effect of friction entirely) when it's not making contact with the ground:

1// GameObject.h
2// ...
3
4class GameObject {
5 public:
6  // ...
7  float GetFrictionCoefficient() {
8    // Assuming a vertical position <= 2 means
9    // the object is on the ground
10    if (Position.y > 2) {
11      // Object isn't on the ground
12      return 0;
13    }
14
15    if (Position.x > 5 && Position.x < 6) {
16      // Area from x=5 to x=6 is icy
17      return 0.1;
18    }
19
20    // Default friction amount
21    return 0.5;
22  }
23
24  Vec2 FrictionForce(float DeltaTime) {
25    float MaxMagnitude{GetFrictionCoefficient()
26      * Mass * -Acceleration.y};
27      
28    // The rest of the function is unchanged
29    if (MaxMagnitude <= 0) return Vec2(0, 0);
30
31    float StoppingMagnitude{Mass *
32      Velocity.GetLength() / DeltaTime};
33
34    return -Velocity.Normalize() * std::min(
35      MaxMagnitude, StoppingMagnitude);
36  }
37  
38  // ...
39};

Static and Dynamic Friction

In more realistic simulations, friction is often represented by multiple forces. The most notable example is to split the concept into two categories: static friction and dynamic friction.

Static friction applies when the object is stationary. It acts to prevent the object from starting to move.
Dynamic friction applies when our object is moving. It acts to decelerate the object. Dynamic friction is sometimes called kinetic friction or sliding friction.

When all other things are equal, static friction is generally stronger than dynamic friction. You're likely to have noticed this phenomenon in everyday life, for example, when pushing a car.

It takes a lot of force to overcome the static friction and get the car moving. However, once it has started moving, it's easier to keep it moving as we now just need to overcome the weaker dynamic friction.

Complete Code

A complete version of our GameObject class that implements all of the techniques we covered in this lesson is available below:

Summary

In this lesson, we've explored how to implement forces in our game physics system. We've seen how forces and mass interact to produce acceleration, and how multiple forces can be combined to create complex behaviors.

We've also implemented realistic physical effects like drag and friction that add depth to our simulation. Key takeaways:

Forces cause acceleration according to the equation $F = MA$
Each game object can have its own mass, affecting how it responds to forces
Multiple forces can be applied simultaneously, and they combine through vector addition
Drag produces a force opposite to an object's velocity, with magnitude proportional to velocity squared
Friction slows objects moving across surfaces, with magnitude dependent on the normal force
Terminal velocity occurs when forces like gravity and drag balance each other out
Clamping can be used to prevent tiny residual velocities from causing visual jitter

Force, Drag, and Friction