I have a love / hate relationship with the subject of **mathematics**. Learning about it in school is a dreadful experience. Using it in school is even worse. However, once you take that knowledge to the real world and start applying it there, you unlock a swathe of new avenues both conceptually and financially (and I don’t mean that you can start cheating in **online casino games**).

**Math** is everywhere, and one of the greatest sins of the education system is that only a sliver of its usefulness is conveyed to students. Not that this understanding makes my calculus classes any more bearable, though.

The memed example is **taxes**.

Calculating finances and taxes owed is a pretty simple task from a mathematical perspective. The equations, at least, are pretty straightforward, and most of it can be done through programs like Excel anyway (not that you would know that from eighteen years of education).

There is another field, a more creative field, where all the math you hated starts to come together beautifully: **Game Development!**

**Game Dev Basics**

Making video games is easier than ever these days. Game engines like Unreal, Unity, and Godot do all of the REALLY complex number crunching for you and are almost completely free. You technically don’t even have to know how to program since both Unreal and Unity support drag-and-drop node systems for adding behaviors to objects.

Art programs like Krita, Blender, Gimp, and Paint.NET are just a handful of easy to use software for creating assets. You can even get a vast range of audio assets using sites like Freesounds.org and programs like Audacity. Not to mention the thousands of tutorials and forums online that cover just about every topic, question, and problem imaginable.

Still, it’s not all sunshine and rainbows. If you dive deep enough into a project, you’ll eventually run into that pesky mathematics. Whether it’s calculating how high a character can jump or how many bullets he’s got left in his gun, it’s an inevitability that you’re going to run into some number crunching at some point. So here’s a quick breakdown of the basic **mathematics** you should familiarize yourself with to really get into game design.

**Trigonometry**

This is a staple of game design and computer graphics and is vital for a vast number of problems. If you learned this in high school, then do you remember how to calculate the distance between two points? Yep, good ol’ **Pythagorean’s Theorem**.

Say you have a playable character and a zombie standing near each other in a top-down, 2d game. The zombie wants to eat the player’s brain. How do you check whether or not the zombie is close enough to munch on that grey matter?

Well, you have to calculate the distance between them. This is easy when they’re standing on a straight line from each other, but what if they’re at an angle to one another? This is the perfect use-case for Pythagorean’s Theorem.

In fact, it’s so useful that most game engines have the equation built-in as a simple function, ready to go. Of course, you’ll probably want an understanding of what’s going on behind the scenes for more advanced use-cases later on.

**Functions**

Then there are the good ol’ trig functions. Sine, Cosine, and Tangent. These three functions have a *huge* amount of flexibility for what you can do with them. In class, you probably only used them for calculating the angles in shapes. That’s very useful, of course, but the graphs you get when plotting them are equally as useful.

Let’s take Sine as an example. A simple sine equation would be sin(X). You can input any value of X, and the function will return a value between negative one and positive one. That might not sound so useful at first, but here’s the trick: X can be *anything*. Two or two billion, the Sine of it will always return a value between one and negative one.

But what if, instead of just an arbitrary number, we put *time* into a sine function? A number that continually goes up every second? We would loop through values between one and negative one. What if we took that output and did something like this:

**Floating_Skull_Enemy.position + sin(time)**

Now we’ve got a cool skull enemy that will smoothly bob up and down, forever, with no external animation required! Assuming we applied the values to the correct axis, but I’ll get to Vectors later.

Don’t discount other types of functions too. **F(x) = x ^{2}** (pronounced

*F of X equals X-squared*) is a very simple, but extremely useful equation. Say we’re designing an RPG with a playable character that gains experience from killing monsters.

How much experience does he need to level up? Do you want to figure exactly how much experience he’s should get per level in a game where you expect the player to level up a hundred times in a single playthrough? Why waste all that time and effort when you can just plug the level into a simple exponential equation: **Experience_To_Lvl_Up = (Current_Lvl) ^{2}**

The more he levels up, the harder it becomes to reach the next level.

There are also Logarithmic equations, which, in contrast to a function like X^{2}, increase *slow*ly. They look something like this: **F(x) = Log(x)**

A use-case would be for something like a cool item. Say you have a potion that increases how much damage the player can do to monsters. You want the player to be able to use multiple of these potions at once, but you don’t want things to get *too* out of hand. Instead of hard capping a limit onto the bonus (like, no more than 5 bonus damage, max), you could have the damage increase *logarithmically.* The damage will increase quickly, at first, and then taper off. The bonus damage still increases but at smaller increments every time.

If you’re having trouble imaging how these functions work, go to an online calculator like Geogebra or Desmos, and play around. Accurately visualizing how these functions work is an essential step in understanding how to apply them.

**Vectors**

Anything that’s gotta do with positioning and moving an object in a virtual environment is going to involve Vectors. Vectors are very simple to understand since they’re basically just giant arrows.

Every game engine I’ve used has a coordinate system, an X and Y axis, that starts at zero and goes off to infinity. A Vector is just a big arrow that points FROM zero to a POINT. If we have Vector V<3, 4>, then we have an arrow that goes three units to the right and points to a spot four units up.

Positions of objects are stored as Vectors. In a game, I have a zombie that walking around looking to grab some thought for food. Where is he? Well, the zombie is listed as being at the spot (25, -34), which means that to find him, I draw an arrow twenty-five units to the right and thirty-four down from the origin (point zero).

What if that zombie smells some breakfast brains at (4, 10) and wants to move towards it? Well, I’ll need to figure the direction from where the zombie is to the unfortunate soul, which would be another vector. The math isn’t hard, so I won’t do it here, but we’ll get a giant arrow from the zombie to the meat. That won’t do. If we just apply that directly, the zombie will teleport to where it wants to go, and *nobody* wants teleportation zombies. We just need the direction we’d like the zombie to go in, and then we can set how fast the zombie gets there.

To do this, we need the *normal* of that Vector we calculated. The Normal of a Vector is another Vector that points in the same direction but has had its size reduced to 1. It’s another basic formula, but every game engine I’ve used have Normalization as a built-in feature you can access on any Vector. Once we’re pointed in the right direction, we can then multiply the normal by however fast we want the zombie to go, and we’ll get something like this:

**Zombie.move = Direction.Normal * Zombie_Speed**

Making games in three dimensions isn’t all that different, conceptually. You just add a third value to every Vector, which is usually represented as Z. If a 2d Vector looks like (x, y), then a 3d vector looks like (x, y, z).

In high school, you probably only worked in two dimensions for functions and plotting graphs and *maybe* touched on three-dimensional geometry, like cubes, spheres, and cylinders. That’s alright. You don’t need to be a math wiz to understand a lot of this stuff.

Let’s say we want to put an evil floating skull a bit in the air, on the other side of a room. The center of this room is our **origin**, or (0, 0, 0). We’ll put our skull five units away from the center, six units up. This puts our evil skull smack-dab in the center of the far wall. However, that’s kind of boring. It’s too symmetrical. Let’s add some asymmetry by moving our skull to the right two units.

To recap, if we were standing in the center of the room, facing in the direction of the X-Axis, our skull enemy would be five units in front of us, six units up around eye-level, and then to our right by two units. In other words, the skull is floating at **Vector (5, 6, 2)**!

**Game Dev Mastery**

So, technically, you don’t need to know any of this. Then again, technically, we don’t need **video games** at all, right? Sure, but then we wouldn’t have video games to play.

The point is that you can always take your hobbies to the next level, and if you want to start making games, maybe even aspire to actually sell one other people will play, then gritting your teeth and doing some gosh-darned math w