Fundamental Laws of Physics

Let's begin our physics journey by covering some of the basic concepts of physics and the properties of time, space, and matter. These fundamental concepts will give you a vocabulary to understand the more advanced topics that follow.

Mass (m)

All matter has mass. Mass is a measure of how much matter or actual atomic mass units. It doesn't have anything to do with weight. Many people have mass and weight confused. For example, they might incorrectly say that they weigh 75 kilograms (165 pounds) on Earth. First, kilograms (kg) are a metric measure of mass, that is, how much matter an object has. Pounds is a measure of force, or, more loosely, weight (mass in a gravity field). The measure of weight or force in the English system is a pound (lb.) and in the metric system is called a Newton (N). Matter has no weight per se; it only can be acted upon by a gravitational field to produce what we refer to as weight. Hence, the concept of mass is a much more pure idea than weight (which changes planet to planet).

In games, the concept of mass is only used abstractly (in most cases) as a relative quantity. For example, I might set the spaceship equal to 100 mass units and the asteroid equal to 10,000. I could use kilograms, but unless I'm doing a real physics simulation it really doesn't matter. All I need to know is an object that has a mass of 100 has twice as much matter as an object that has 50 mass units. I'll revisit mass in a bit when I talk about force and gravity. Mass is the measure of how much matter an object is made of and is measured in kilograms in the metric system or—ready for this—slugs in the English system.

Time (t)

Time is an abstract concept. Think about it. How would you explain time without using time itself in the explanation? Time is definitely an impossible concept to convey without using circular definitions and a lot of hand waving. Luckily, everyone knows what time is, so I won't go into it, but I do want to talk about how it relates to time in a game.

Time in real life is usually measured in seconds, minutes, hours, and so forth. Or if you need to be really accurate then it's measured in milliseconds (ms 10^-3 seconds), microseconds (ms 10^-6), nano (10^-9), pico (10^-12), femto (10^-15), etc. However, in a video game (most games), there isn't a really close correlation to real-time. Algorithms are designed more around the frame rate than real time and seconds (except for time modeled games). For example, most games consider one frame to be one virtual second, or in other words, the smallest amount of time that can transpire. Thus, most of the time, you won't use real seconds in your games and your physics models, but virtual seconds based on a single frame as the fundamental time step.

On the other hand, if you're creating a really sophisticated 3D game then you probably will use real time. All the algorithms in the game track in real time, and invariant of the frame rate, they adjust the motion of the objects so that a tank can move at, say, 100 feet per second even if the frame rate slows down to 2 frames per second or runs at 60 frames per second. Modeling time at this level of accuracy is challenging, but absolutely necessary if you want to have ultra-realistic motion and physical events that are independent of frame rate changes. In any case, we'll measure time in seconds (s) in the examples or in virtual seconds, which simply means a single frame.

Position (s)

Every object has an (x,y,z) position in 3D space or an (x,y) position in 2D space or an x in 1D or linear space (also sometimes referred to as an s). Figure 13.1 shows examples of all these dimensional cases. However, sometimes it's not clear what the position of an object is even if you know where it is. For example, if you had to pick one single point that locates the position of a sphere then you would probably pick its center as shown in Figure 13.2. But what about a hammer? A hammer is an irregular shape, so most physicists would use its center of mass, or balancing point, as the position to locate it, as shown in Figure 13.3.

The concept of position and the physically correct location of the position when it comes to games is usually rather lax. Most game programmers place a bounding box, circle, or sphere around all the game objects as shown in Figure 13.4 and simply use the center of the bounding entity as the center of the object. This works for most cases, where most of the mass of the object is located at the center of the object by luck, but if that's not the case then any physics calculations that use this artificial center will be incorrect.

The only way to solve the problem is to pick a better center that takes the virtual mass of the object into consideration. For example, you could create an algorithm that scanned the pixels making up the object and the more pixels that were in an area, the more that area would be weighted to be the center. Or if the object is a polygon-based object then you could attach a weight to each vertex and compute the real center of mass of the object. Assuming that there are n vertices and each vertex position is labeled by (x_i,y_i) with a mass of m_I, then the center of mass is

Velocity (v)

Velocity is the instantaneous rate of speed of an object and is usually measured in meters per second (m/s) or in the case of the automobile, miles per hour, or mph. Whatever units you prefer, velocity is the change in position per change in time. Stated mathematically in a 1 dimensional case, this reads:

In other words, the instantaneous change in position (ds) with respect to time (dt). As an example, say you are driving down the road and you just drove 100 miles in one hour, then your average velocity would be

In a video game the concept of velocity is used all the time, but again the units are arbitrary and relative. For example, in a number of the demos I have written I usually move objects at 4 units in the x- or y-axis per frame with code something like the following:

x_position = x_position + x_velocity;
y_position = y_position + y_velocity;

That translates to 4 pixels/frame. But frames aren't time, are they? Actually, they are as long as the frame rate stays constant. In the case of 30 fps, which is equal to 1/30^th of a second per frame, the 4 pixels per frame translate to:

Virtual Velocity = 4 pixel / (1/30) seconds
                 = 120 pixels per second.

Hence, the objects in our game have been moving with velocities measured in pixels/ second. If you wanted to get crazy then you could estimate how many virtual meters were in one pixel in your game world and perform the computation in meters/second in cyberspace. In either case, now you know how to gauge where an object will be at any given time or frame if you know the velocity. For example, if an object was currently at position x₀ and it was moving at 4 pixels/frame, and 30 frames go by, the object would be at

new position = x0 + 4 * 30 = x0 + 120 pixels.

This leads us to our first important basic formula for motion:

New Position = Old Position + Velocity * Time
             = xt = x0 + v*t.

This formula states that an object moving with velocity v that starts at location x₀ and moves for t seconds will move to a position equal to its original position plus the velocity times the time. Take a look at Figure 13.5 to see this more clearly. As an example of constant velocity I have created a demo DEMO13_1.CPP|EXE (16-bit version, DEMO13_1_16B.CPP|EXE) that moves a fleet of choppers from left to right on the screen.

Acceleration (a)

Acceleration is similar to velocity, but it is the measure of the rate of change of velocity rather than the velocity itself. Take a look at Figure 13.6; it illustrates an object moving with a constant velocity and one with a changing velocity. The object moving with a constant velocity has a flat line (slope of 0) for its velocity as a function of time, but the accelerating object has a slope of non-zero because its velocity is changing as a function of time.

Figure 13.6 illustrates constant acceleration. There is also non-constant acceleration. In this case the line would be a curve in part C of Figure 13.6. Pressing the accelerator in your car will give you the feeling of non-constant acceleration and jumping off a cliff will give you the feeling of constant acceleration. Mathematically, acceleration is the rate of change of velocity with respect to time:

Acceleration = a = dv/dt.

The units of acceleration are a little weird. Since velocity is already in units of distance per second, acceleration is in units of distance per second*second, or in the metric system, m/s². If you think about this it makes sense because acceleration is the change of velocity (m/s) per second. Furthermore, our second motion law relates the velocity, time, and acceleration, which states that the new velocity at some time, t, in the future equals the starting velocity plus the acceleration times the amount of time the object has been accelerating for:

New Velocity  = Old Velocity + Acceleration * Time
              = vt = v0 + a*t.

Acceleration is a fairly simple concept and can be modeled in a number of ways, but let's take a look at a simple example. Imagine that an object is located at (0,0) and it has a starting velocity of 0. If you were to accelerate it at a constant velocity of 2 m/s, you could figure out the new velocity each second simply by adding the acceleration to the last velocity, as shown in Table 13.1.

Table 13.1. Velocity as a Function of Time for Acceleration 2 m/s²

Time(t = s)	Acceleration (v = m/s)	Velocity (a = m/s2)
0	2	0
1	2	2
2	2	4
3	2	6
4	2	8
5	2	10

Taking the data in the table into consideration, the next step is to figure out the relationship between position, velocity, acceleration, and time. Unfortunately, this takes a bit of calculus, so I'll just give you the results in terms of position at some time t:

xt = x0 + v0*t + 1/2*a*t2

This equation states that the position of an object at some time t is equal to its initial position, plus its initial velocity, times time, plus one half the acceleration, times time squared. The 1/2*a*t² term is basically the time integral of the velocity. Let's see if you can use the equation in your game world of pixels and frames. Refer to Figure 13.7.

Assume these initial conditions: The object is at x=50 pixels, the initial velocity is 4 pixels/frame, and the acceleration is 2 pixels/frame². Finally, assume that these are the conditions at frame 0. To find the position of the object at any time in C/C++, use the following:

x = 50 + 4*t + (0.5)*2*t*t;

Where t is simply the frame number. Table 13.2 lists some examples for t = 0,1,2…5.

Table 13.2. An Object Moving with Constant Acceleration

Time/Frame (t)	Position (x)	Delta (x)=xt-xt-1
0	50	0
1	50+4*1+(0.5)*2*12 = 55	5
2	50+4*2+(0.5)*2*22 = 62	7
3	50+4*3+(0.5)*2*32 = 71	9
4	50+4*4+(0.5)*2*42 = 82	11
5	50+4*5+(0.5)*2*52 = 95	13

There's a lot of interesting data in Table 13.2, but maybe the most interesting data is the change in position each time the frame is constant and equal to 2. Now this doesn't mean that the object moves 2 pixels per frame, it means that the change in motion each frame gets larger or increases by 2 pixels. Thus on the first frame the object moves 5 pixels, then on the next frame it moves 7, then 9, 11, then 13, and so on. And the delta between each change in motion is 2 pixels, which is simply the acceleration!

The next step is to model acceleration with C/C++ code. Basically, here's the trick: You set up an acceleration constant and then with each frame you add it to your velocity. This way you don't have to use the long equation shown earlier—you simply translate your object with the given velocity. Here's an example:

int acceleration = 2, // 2 pixels per frame
    velocity     = 0, // start velocity off at 0
    x            = 0; // start x position of at 0 also
// ...
// then you would execute this code each
// cycle to move your object
// with a constant acceleration

// update velocity
velocity+=acceleration;

// update position
x+=velocity;

To see acceleration in action, I have created a demo named DEMO13_2.CPP|EXE (16-bit version, DEMO13_2_16B.CPP|EXE) that allows you to fire a missile that accelerates as it moves forward. Press the spacebar to fire the missile, the up and down arrow keys to increase and decrease the acceleration factor, and the A key to toggle the acceleration on and off. Look at the difference acceleration makes to the motion of the missile and how acceleration gives the missile a sense of "mass."

Force (F)

One of the most important concepts in physics is force. Figure 13.8 depicts one way to think of force. If an object with mass m is sitting on a table with gravity pulling it toward the center of the Earth, the acceleration is a=g (force of gravity). This gives the mass m weight and if you try to pick it up you will feel a pain in your lower back.

The relationship between force, mass, and acceleration is Newton's Second Law:

In other words, the force exerted on an object is equal to its mass times the acceleration of the object. Or, rearranging terms:

This states that an object will accelerate an amount equal to the force you place on it divided by its mass. Now let's talk about the units of measure. But instead of just blurting it out, let's see where it comes from in the metric system. Force is equal to mass times acceleration or kilograms multiplied by m/s² (m stands for meters, not mass). Hence, a possible unit of force is

This is a bit long, so Newton just called it—a Newton (N). As an example, imagine that a mass m equal to 100 kg is accelerating at a rate of 2 m/s². The force that is being applied to the mass is exactly equal to F = m*a = 100 kg * 2 m/s² = 200N.

This gives you a bit of a feel for a Newton. A 100 kg mass is roughly equivalent to the force of 220 lbs. on Earth, and 1 m/s² is a good accelerating run.

In a video game the concept of force is used for many reasons, but a few that come to mind are

• You want to apply artificial forces like explosions to an object and compute the resulting acceleration.

• Two objects collide and you want to compute the forces on each.

• A game weapon only has a certain force, but it can fire different virtual mass shells and you want to find the acceleration the shells would experience when fired.

Forces in Higher Dimensions

Of course forces can act in all three dimensions, not just in a straight line. For example, take a look at Figure 13.9, which depicts three forces acting on a particle in a 2D plane. The resulting force that the particle p "feels" is simply the sum of the forces that are acting on it. However, in this case it's not as simple as adding scalar numbers together since the forces are vectors. Nevertheless, vectors can be decomposed into their x, y, and z components and then the forces acting in each axis can be computed. The result is the sum of the forces acting on the particle.

In the example shown in Figure 13.9 there are three forces; F₁, F₂, and F₃. The final force F_final=<fx, fy> that object p feels is simply the sum of these forces:

fx = f1x + f2x + f3x
fy = f1y + f2y + f3y

Plugging in the values from the example in the figure, you get

fx = (x+x+x) = x.x
fy = (y+y+y) = y.y

With that in mind, it doesn't take much to deduce that in general the final force F on an object is just the vector sum of forces, or mathematically:

Where each force F_i can have 1, 2, or 3 components, that is, each vector can be a 1D (scalar), 2D, or 3D.

Momentum (P)

Momentum is one of those quantities that's hard to define verbally. It's basically the property that objects in motion have. Momentum was invented as a measure of both the velocity and mass of an object. Momentum is defined as the product of mass (m) and the velocity (v) of an object:

And the units of measure are kg*m/s, kilogram-meters per second. Now the cool thing about momentum is its relationship to force—watch this:

or substituting, p for m:

But, a = dv/dt, thus:

Or in English, force is the time rate change of momentum per unit time. Hmmm… interesting. That means if the momentum of an object changes a lot then so must the force acting on the object. Now here's the clincher. A pea can have as much momentum as a train—how? A pea may have mass of 0.001 kg and a train have a mass of 1,000,000 kg. But if the train is going 1 m/s and the pea is going 100,000,000,000 m/s (that's one fast pea) then the pea will have more momentum:

mpea*vpea    = 0.001 kg * 10,000,000,000 m/s = 10,000,000 kg*m/s
mtrain*vtrain = 1,000,000 kg * 1 m/s = 1,000,000 kg*m/s

And thus if either of these objects came to an abrupt stop, hit something for example, that object would feel a whole lot of force! That's why a bee hitting you on a motorcycle is so dangerous. It's not the mass of the bee, but the velocity of the bee that gets you in this example. The resulting momentum is huge and can literally throw a 200-pound guy off the bike.

This brings us to conservation of momentum and momentum transfer.