Page 1 of 1

## Putting Math Into the Context of Game Programming Part I- Derivatives, Related Rates, and Applications

### #1 macosxnerd101

• Games, Graphs, and Auctions

Reputation: 11803
• Posts: 44,329
• Joined: 27-December 08

Posted 01 April 2010 - 06:53 PM

POPULAR

So while helping out in the forums, I've seen a lot of misuse of mathematical formulas and notations in programs, specifically Precalculus and Calculus, that I hope to correct. Part I will cover Derivatives and Related Rates, and their applications in Game Programming.

To start off, a derivative represents a rate of change. If you have width, and you differentiate it with respect to u, you have dw/du or the rate of change of width with respect to u. The keyword here is rate. So you can have 3 width units per 1 u unit. In programming, specifically game programming, we are usually interested in the rate of change of a dimmension with respect to time. So dz/dt, where z is a dimmension.

One of the biggest mistakes I see in the forums is a notation mistake- users are adding dw to width. Like so:
```//given int width

width += dw;
}

```

While this is syntactically correct, as dw and width are both ints, this is very misleading. It implies that you are adding a rate (like 3 meters/second) to a dimmension or quantity (3 meters). If you would instead like to add a quantity over a period of change, first multiply by that unit of change (exactly like dimmensional analysis for those who have had Chemistry), then add that product to the original quantity. So sticking with our width example, and we want to find the total change over a period of time, we can set up a linear equation:
```width = dw*time + startingWidth;

```

So, the width is equivelant to the rate of change (or slope) over a period of time, plus the original width. Let's go over the applications of derivatives in programming. When you go to repaint() your window every x seconds, you now have a time to extrapolate the new dimmension or location of your Object. So if you are moving a characer 3 pixels per second, repainting every 100 seconds, you know that on ecah repaint, you want to move your character 300 pixels.

Now let's discuss about related rates. As the name suggests, related rates are used to relate the rate of change (so we need derivatives) of multiple dimmensions over a common dimmsion, usually time. So what are the applications of related rates in programming? Think about if you have a non-cubical (spherical, cone, cylindrical,triangular or rectangular pyramid, etc.) room flooding with water and a character trying to swim to the surface, how do you calculate the speed at which the character will need to swim in order to rise faster than the water? Let's work through this using a Sphere shaped room. The volume of a sphere is V = 4/3 * pi * r^3. When you differentiate Volume with respect to time, you get dV/dt = 4 * pi * r^2 * dr/dt. So the rate of change of the volume with respect to time is equivelant to 4pi * radius-squared * rate of change of radius with respect to time. Once you determine a constant rate of change for the radius, you can solve for the rate of change of the volume. Now it should be fairly simple to compare the position of the character and the rate at which it is swimming upwards, to the total volume and dv/dt.

For those of you who have played the N-Game, you'll find applications for this second example. So in certain levels of the N-Game, there is a laser-turret which targets the Ninja and fires a laser once it gets a lock. So how does this pertain to related rates? In the last example, we determined rate of change of volume. For this problem, we will be calculating dc/dt, or the rate of change of the hypotenuse for a right triangle. To begin, start the Ninja on a y = k line with the turret. This line is your b line in the pythagorean theorem a^2 + b^2 = c^2. Now, we will calculate dc/dt based on da/dt, or the rate of change of the hypotenuse based on the rate of change of line a. So since we've set up the Pythagorean Theorem, let's differentiate: 2a*da/dt + 2b*db/dt = 2c*dc/dt. Since line b isn't changing, db/dt = 0. So now our equation becomes 2a*da/dt = 2c*dc/dt or more simply, a*da/dt = c*dc/dt. It is up to you the programmer to determine da/dt, and c can be found from the Pythagorean theorem, so it should be fairly straight-forward to solve for dc/dt.

Now that we've talked about the math, let's talk about programming these concepts. As I talked about in my first derivative example, we can use the elapsed time to estimate positions from rate of change. In animation programming, we repaint() the window at set intervals so as to avoid flickering. So basically, you can position your objects according to their starting positions, modified by the number of repaints * rateOfChange. So dp/dt * t, or change in position with relation to time multiplied by time.

Edit: Thanks to Galois for catching my typo. I corrected the label for the Volume formula to read Volume of a sphere, not volume of a cone.

This post has been edited by macosxnerd101: 03 April 2010 - 11:29 PM

Is This A Good Question/Topic? 8

## Replies To: Putting Math Into the Context of Game Programming

### #2 lesPaul456

Reputation: 174
• Posts: 729
• Joined: 16-April 09

Posted 03 April 2010 - 09:13 PM

Nice job!

### #3 macosxnerd101

• Games, Graphs, and Auctions

Reputation: 11803
• Posts: 44,329
• Joined: 27-December 08

Posted 03 April 2010 - 10:21 PM

Thanks!

### #4 Galois

Reputation: 28
• Posts: 207
• Joined: 27-March 10

Posted 03 April 2010 - 11:04 PM

Several things to comment on:

1. In mathematics, dw may denote a differential of w, which can be seen as a change of w over a small interval. You usually deal with these things in the context of approximations. So something like width += dw can make sense and will probably mean the value of width after some time as expired. Now, if by dw programmer means a derivative of w (poor choice of a variable name) then, like you said, it is wrong.

2. Doing something like dw/dt * time will yield an approximation. Gotta integrate these things to get the exact value. Of course, if the value of time is very small then the approximation should be somewhat close to the real deal.

3. When you talk about the water filling the room, in one sentence you say it's a cone. You're talking about a sphere though

This post has been edited by Galois: 03 April 2010 - 11:11 PM

### #5 macosxnerd101

• Games, Graphs, and Auctions

Reputation: 11803
• Posts: 44,329
• Joined: 27-December 08

Posted 03 April 2010 - 11:27 PM

Galois, on 04 April 2010 - 02:04 AM, said:

Several things to comment on:

1. In mathematics, dw may denote a differential of w, which can be seen as a change of w over a small interval. You usually deal with these things in the context of approximations. So something like width += dw can make sense and will probably mean the value of width after some time as expired. Now, if by dw programmer means a derivative of w (poor choice of a variable name) then, like you said, it is wrong.

Yah, the whole reason I pointed that out was because I have seen projects where the users were using dw incorrectly by not factoring in change over time, just additional quantities.

Quote

2. Doing something like dw/dt * time will yield an approximation. Gotta integrate these things to get the exact value. Of course, if the value of time is very small then the approximation should be somewhat close to the real deal.

In the context of game programming, we're talking about 50-60 fps and pixels as units along the x and y axes, so the approximation should be good enough. In my part 3 tutorial, I'll cover integration and volumes of revolving solids in the context of 3D gravity. However, for my first two tutorials, I'm going to stick with basic derivatives as the first two are geared towards those less than halfway through Calculus I or AP Calculus AB.

Quote

3. When you talk about the water filling the room, in one sentence you say it's a cone. You're talking about a sphere though

I was going to do cones, but I thought spheres would be easier. Thanks for catching the typo.