To kick off the blog, I’m starting with a series of articles about various math related skills that you should probably have under your belt if you want to be a game programmer. Always remembering that although I aspire to game dev status, I have not actually dev’d any games that anyone has ever played before, so I may or may not know what I’m talking about. I tend to lean more towards the latter.

In any case, here’s a thing you should probably be conversant with if you’re going to be a game developer; the Pythagorean Theorem. Whether you just learned it in school recently, or it has been a while, chances are good it probably sticks out at you as something you remember (even if just vaguely). In such a case, perhaps you remember it, but don’t grasp just what exactly you might use it for in a game.

Mathematically, the formula looks like this:

Knowing this (and a little algebra), you can determine the length of any side of the triangle as long as you know what the other two sides are:

As I mentioned, assuming you’ve learned this in school, you probably remember it quite well.“But what USE is it?!”, I hear you moaning over there.

This is also well known as “the distance formula”.

Say that the player is at coordinates (6, 2) and the bad guy is at coordinates (2, 5) and you want to know how close they are, because the bad guys have a shooting range of 5 units, and you want to know if he’s close enough to shoot or not.

Since you know the X and Y positions of both the player and the enemy, you  can use them to easily construct a right angle triangle and determine the lengths of two of the sides, leaving just the hypotenuse as the edge to calculate, which happens to be the distance that you’re interested in. To calculate the first two sides, some simple math is needed to determine how far apart the points are on the X and Y axis:

Plugging everything we know, we easily calculate that the displacement along the X axis is -4 and along the Y axis it’s 3. A little bit of multiplication and square rooting later (you did remember that a square and a square root cancel each other out, right?), and boom, we determine that the distance between the enemy and the player is 5.

Looks like the player is going to get shot.

Note that these diagrams assume that the origin is in the bottom left of the screen, which it may or may not be in your particular usage case. If you’re using something like libGDX or OpenGL, it might be, whereas with SDL the origin is at the top left. This doesn’t matter, though, and the technique still works regardless.

It’s important to note that because a squared number is always positive, the length that you calculate this way is always a positive number (or 0, in the degenerate case), and is never negative. This allows you to calculate the distance from Enemy to Player the same as the way from Player to Enemy without having to worry.

General Tip

The square root you have to take to determine the final length in the last step might be expensive (relatively speaking) depending on how often you need to calculate it. If the actual length doesn’t matter to you and you just need to compare some lengths (to determine which is the shortest, to see if anything is in range, and so on) you can just compare the squared values (25 in this example) without doing the square root operation at all. Just make sure you know what you’re comparing to.

Whether this is an optimization that is useful for you is entirely down to your own discretion and the results of your code profile (You DO profile your code and don’t fall into the old trap of assuming you are smart enough to know where the bottlenecks are, right?), but it’s a handy thing to know nevertheless.

That’s it for this week! Next week will be a discussion on some basic Trigonometry, assuming I don’t see something shiny that distracts me. Stay tuned!