← back
#
2019-10-09: the mathematics of game programming

Game development and game engines tend to require a lot of parallel processing power in order to run any significantly complex rendered scenes. This is a consequence of the fact that the building blocks consist of simple triangles, along with a variety of other systems, such as particle effects and in-game physics.

Before we begin, there is an essential concept that will be discussed, which while not being mathematical in nature, serves as the base for most games. Specifically, the concept of the "game loop" which often consist of:

1. process input

2. update game

3. render

This basic flow continues infinitely and allows the developer to handle whatever input it received from the player, then update the game world with whatever variables are at play, then render the sprites or textures or models or physics, and finally start over at the beginning.

Now, in games vector arithmetic is very common, typically for determining line location and length, or the relative location of a point for a given set of points. For vectors that consist of a single vertex of the style of (x,y,z), the simplest operations of addition and subtraction apply like so:

(1,2,3) + (0,2,2) = (1,4,5)

(1,2,3) - (0,2,2) = (1,0,1)

For multiple line vectors, basic knowledge of geometry and trigonometry of the angles apply. Some simple visualizations:

Vector dot product values are useful for many things, such as calculating diffuse lighting or player position relative to another character. Specifically, a vector dot product is a mathematical operation on two vectors, which returns a number. Formulaically this is...

dot product = u . v

A good way to visualize this is as follows:

Vector cross products are also operations on two vectors, wherein the result is a third vector which is perpendicular to the first two and has a length that is an average of both lengths. These are quite useful for a number of applications, notably collision detections; e.g. between the player and the wall, the cross product vector would be the "adjusted" path that the player would take due to collision with a wall. Formulaically this is...

cross product = u x v

This can be visualized as follows, where the blue line is the cross product:

Matrix math is related to the vector arithmetic, with some of the more interesting applications being related to HLSL or GLSL shaders. In addition they can be used for handling bounding boxes or bounding sphere since subtracting matrixes of the length or radius makes multidimensional concerns simpler. Some typical examples of the variety used in game development might be as below:

When it comes to the concept of collisions, bounding boxes are an important concept since they can define the minimum and maximum extent of an object, and thus, allows for the creation of walls that can block the path of a game character from moving in that direction.

For a rectangle, the bounding box would be as follows, where lx is the x-coord of the largest dimension and wy is the y-coord of the smallest dimension:

bounding box of a rectangle, length min = [lx1 - lx2, ly1 - ly2]

bounding box of a rectangle, length max = [lx1 + lx2, ly1 + ly2]

bounding box of a rectangle, width min = [wx1 - wx2, wy1 - wy2]

bounding box of a rectangle, width max = [wx1 + wx2, wy1 + wy2]

For a circle, the bounding box would as follows, where cx is x-coord of the centre of the circle, and r is the radius:

bounding box of a circle, min = [cx - r, cy - r]

bounding box of a circle, max = [cx + r, cy + r]

For a sphere, the bounding box would be the below:

bounding box of a sphere, min = [cx - r, cy - r, cz - r]

bounding box of a sphere, max = [cx + r, cy + r, cz + r]

A related concept to the bounding box is the bounding sphere which is similar but using spheres as a cheap way of reducing excessive surfaces to collide as an alternative to using boxes.