This cheat sheet will list several common geometrical problems found in games, and how to solve them with vector math.

Complete list of basic vector operations

But first, a little review.

For this, I assume that you have a vector class readily available. This is mostly 2D-focused, but everything works the same for 3D, except for differences concerning vector product, which I will assume to return just a scalar in the 2D case, representing the “z” axis. Any case that only applies to 2D or 3D will be pointed out.

Strictly speaking, a point is not a vector – but a vector can be used to represent the distance from the origin (0, 0) to the point, and so, it is perfectly reasonable to just use vectors to represent positions as if they were points.

I expect the class to give you access to each of the components, and to the following operations (using C++ style notation, including operator overloading – but it should be easy to translate to any other language of your choice). If a given operation is not available, you can still do it manually, either by extending the class or creating a “VectorUtils” class. The examples below are usually for 2D vectors – but 3D is usually simply a matter of adding the z coordinate following the pattern of x and y.

• Vector2f operator+(Vector2f vec): Returns the sum of the two vectors. (In a language without operator overloading, this will probably be called add(). Similarly for the next few ones.)
  a + b = Vector2f(a.x + b.x, a.y + b.y);
• Vector2f operator-(Vector2f vec): Returns the difference between the two vectors.
  a – b = Vector2f(a.x – b.x, a.y – b.y);
• Vector2f operator*(Vector2f vec): Returns the component-wise multiplication of the vectors.
  a * b = Vector2f(a.x * b.x, a.y * b.y);
• Vector2f operator/(Vector2f vec): Returns the component-wise division of the vectors.
  a / b = Vector2f(a.x / b.x, a.y / b.y);
• Vector2f operator*(float scalar): Returns the vector with all components multiplied by the scalar parameter.
  a * s = Vector2f(a.x * s, a.y * s);
  s * a = Vector2f(a.x * s, a.y * s);
• Vector2f operator/(float scalar): Returns the vector with all components divided by the scalar parameter.
  a / s = Vector2f(a.x / s, a.y / s);
• float dot(Vector2f vec): Returns the dot product between the two vectors.
  a.dot(b) = a.x * b.x + a.y * b.y;
• float cross(Vector2f vec): (2D case) Returns the z component of the cross product of the two vectors augmented to 3D.
  a.cross(b) = a.x * b.y – a.y * b.x;
• Vector3f cross(Vector3f vec): (3D case) Returns the cross product of the two vectors.
  a.cross(b) = Vector3f(a.y * b.z – a.z * b.y, a.z*b.x – a.x*b.z, a.x*b.y – a.y*b.x);
• float length(): Returns the length of the vector.
  a.length() = sqrt(a.x * a.x + a.y * a.y);
• float squaredLength(): Returns the square of the length of the vector. Useful when you just want to compare two vectors to see which is longest, as this avoids computing square roots
  a.squaredLength() = a.x * a.x + a.y * a.y;
• float unit(): Returns a vector pointing on the same direction, but with a length of 1.
  a.unit() = a / a.length();
• Vector2f turnLeft(): Returns the vector rotated 90 degrees left. Useful for computing normals. (Assumes that y axis points up, otherwise this is turnRight)
  a.turnLeft = Vector2f(-a.y, a.x); 
• Vector2f turnRight(): Returns the vector rotated 90 degrees right. Useful for computing normals. (Assumes that y axis points up, otherwise this is turnLeft)
  a.turnRight = Vector2f(a.y, -a.x);
• Vector2f rotate(float angle): Rotates the vector by the specified angle. This is an extremely useful operation, though it is rarely found in Vector classes. Equivalent to multiplying by the 2×2 rotation matrix.
  a.rotate(angle) =  Vector2f(a.x * cos(angle) – a.y * sin(angle), a.x * sin(angle) + a.y * cos(angle));
• float angle(): Returns the angle that the vector points to.
  a.angle() = atan2(a.y, a.x);

Simple cases – warming up

Case #01 – Distance between two points

You probably know that this is done with the Pythagorean theorem, but the vectorial way is simpler. Given two vectors a and b:

float distance = (a-b).length();

Case #02 – Alignment

Sometimes, you want to align an image by its center. Sometimes, by its top-left corner. Or sometimes, by its top-center point. More generally, you can do alignment using a vector whose two components go from 0 to 1 (or even beyond, if you’d like), giving you full control of alignment.

// imgPos, imgSize and align are all Vector2f
Vector2f drawPosition = imgPos + imgSize * align

Case #03 – Parametric Line Equation

Two points define a line, but it can be tricky to do much with this definition. A better way to work with a line is its parametric equation: one point (“P0″) and a direction vector (“dir”).

Vector2f p0 = point1;
Vector2f dir = (point2 - point1).unit();

With this, you can, for example, get a point 10 units away by simply doing:

Vector2f p1 = p0 + dir * 10;

Case #04 – Midpoint and interpolation between points

Say you have vectors p0 and p1. The midpoint between them is simply (p0+p1)/2. More generally, the line segment defined by p0 and p1 can be generated by varying t between 0 and 1 in the following linear interpolation:

Vector2f p = (1-t) * p0 + t * p1;

At t = 0, you get p0; at t = 1, you get p1; at t = 0.5, you get the midpoint, etc.

Case #05 – Finding the normal of a line segment

You already know how to find the direction vector of a line segment (case #03). The normal vector is a 90 degree rotation of that, so just call turnLeft() or turnRight() on it!

Projections using the Dot Product

The dot product has the incredibly useful property of being able to compute the length of a vector’s projection along the axis of another. To do this, you need the vector that you’ll project (“a“) and a unit vector (so make sure that you call unit() on it first!) representing the direction (“dir“). The length is then simply a.dot(dir). For example, if you have a = (3, 4) and dir = (1, 0), then a.dot(dir) = 3, and you can tell that this is correct, because (1, 0) is the direction vector of the x axis. In fact, a.x is always equivalent to a.dot(Vector2f(1, 0)), and a.y is equivalent to a.dot(Vector2f(0, 1)).

Because the dot product between a and b is also defined as |a||b|cos(alpha) (where alpha is the angle between the two), the result will be 0 if the two vectors are perpendicular, positive if the angle between them is less than 90, and negative if greater. This can be used to tell if two vectors point in the same general direction.

If you multiply the result of that dot product by the direction vector itself, you get the vector projected along that axis – let’s call that “at” (t for tangent). If you now do a – at, you get the part of the vector that is perpendicular to the dir vector – let’s call that “an” (n for normal). at + an = a.

Case #06 – Determining direction closest to dir

Say that you have a list of directions represented as unit vectors, and you want to find which of them is the closest to dir. Simply find the largest dot product between dir and a vector in the list. Likewise, the smallest dot product will be the direction farthest away.

Case #07 – Determining if the angle between two vectors is less than alpha

Using the equation above, we know that the angle between two vectors a and b will be less than alpha if the dot product between their unit vectors is less than cosine of alpha.

bool isLessThanAlpha(Vector2f a, Vector2f b, float alpha) {
    return a.unit().dot(b.unit()) < cos(alpha);
}

Case #08 – Determining which side of a half-plane a point is on

Say that you have an arbitrary point in space, p0, and a direction (unit) vector, dir. Imagine that an infinite line goes by p0, perpendicular to dir, dividing the plane in two, the half-plane that dir points to, and the half-plane that it does not point to. How do I tell whether a point p is in the side pointed to by dir? Remember that dot product is positive when the angle between vectors is less than 90 degrees, so just project and check against that:

bool isInsideHalfPlane(Vector2f p, Vector2f p0, Vector dir) {
    return (p - p0).dot(dir) >= 0;
}

Case #09 – Forcing a point to be inside a half-plane

Similar to the case above, but instead of just checking, we’ll grab the projection and, if less than 0, use it to move the object -projection along dir, so it’s on the edge of the half-plane.

Vector2f makeInsideHalfPlane(Vector2f p, Vector2f p0, Vector dir) {
    float proj = (p - p0).dot(dir);
    if (proj >= 0) return p;
    else return p - proj * dir;
}

Case #10 – Checking/forcing a point inside a convex polygon

A convex polygon can be defined to be the intersection of several half-planes, one for each edge of the polygon. Their p0 is either vertex of the edge, and their dir is the edge’s inner-facing normal vector (e.g., if you wind clockwise, that’d be the turnRight() normal). A point is inside the polygon if and only if it’s inside all the half-planes. Likewise, you can force it to be inside the polygon (by moving to the closest edge) by applying the makeInsideHalfPlane algorithm with every half-plane. [ops, this actually only works if all angles are >= 90 degrees]

Case #11 – Reflecting a vector with a given normal

Pong-like game. Ball hits a sloped wall. You know the ball’s velocity vector and the wall’s normal vector (see case #05). How do you reflect it realistically? Simple! Just reflect the ball’s normal velocity, and preserve its tangential velocity.

Vector2f vel = getVel();
Vector2f dir = getWallNormal(); // Make sure this is a unit vector
Vector2f velN = dir * vel.dot(dir); // Normal component
Vector2f velT = vel - velN; // Tangential component
Vector2f reflectedVel = velT - velN;

For more realism, you can multiply velT and velN by constants representing friction and restitution, respectively.

Case #12 – Cancelling movement along an axis

Sometimes, you want to restrict movement in a given axis. The idea is the same as above: decompose in a normal and tangential speed, and just keep tangential speed. This can be useful, for example, if the character is following a rail.

Rotations

Case #13 – Rotating a point around a pivot

If used to represent a point in space, the rotate() method will rotate that point around the origin. That might be interesting, but is limiting. Rotating around an arbitrary pivot vector is simple and much more useful – simply subtract the pivot from it, as if translating so the origin IS the pivot, then rotate, then add the pivot back:

Vector2f rotateAroundPivot(Vector2f p, Vector2f pivot) {
    return (pos - pivot).rotate(angle) + pivot;
}

Case #14 – Determining which direction to turn towards

Say that you have a character that wants to rotate to face an enemy. He knows his direction, and the direction that he should be facing to be looking straight at the enemy. But should he turn left or right? The cross product provides a simple answer: curDir.cross(targetDir) will return positive if you should turn left, and negative if you should turn right (and 0 if you’re either facing it already, or 180 degrees from it).

Other Geometric Cases

Here are a few other useful cases that aren’t that heavily vector-based, but useful:

Case #15 – Isometric world to screen coordinates

Isometric game. You know where the (0, 0) of world is on the screen (let’s call that point origin and represent it with a vector), but how do you know where a given world (x, y) is on the screen? First, you need two vectors determining the coordinate base, a new x and y axes. For a typical isometric game, they can be bx = Vector2f(2, 1) and by = Vector2f(-2, 1) – They don’t necessarily have to be unit vectors. From now, it’s straightforward:

Vector2f p = getWorldPoint();
Vector2f screenPos = bx * p.x + by * p.y + origin;

Yes, it’s that simple.

Case #16 – Isometric screen to world coordinates

Same case, but now you want to know which tile the mouse is over. This is more complicated. Since we know that (x’, y’) = (x * bx.x + y * by.x, x * bx.y + y * by.y) + origin, we can first subtract origin, and then solve the linear equation. Using Cramer’s Rule, except that we’ll be a little clever and use our 2D cross-product (see definition at the beginning of the article) to simplify things:

Vector2f pos = getMousePos() - origin;
float demDet = bx.cross(by);
float xDet = pos.cross(by);
float yDet = bx.cross(pos);
Vector2f worldPos = Vector2f(xDet / demDet, yDet / demDet);

And now you don’t need to do that ugly find-rectangle-then-lookup-on-bitmap trick that I’ve seen done several times before.

If you can think of any good videos that I missed, please leave a link on the comments. I will update the post with any videos that I enjoy.

Game Design

• Jesse Schell, “Games for Change”
  http://www.g4tv.com/videos/54256/games-for-change-jesse-schell-presentation-video
• Jesse Schell, “Design Outside the Box”
  http://www.g4tv.com/videos/44277/dice-2010-design-outside-the-box-presentation
• Jonathan Blow, “Braid Postmortem”
  http://www.youtube.com/watch?v=gwsi7TEQxKc
• Jonathan Blow, “Video Games and the Human Condition”
  http://www.youtube.com/watch?v=SqFu5O-oPmU
• Petri Purho, “Why Being Poor and Having no Budget is Good for Making Games”
  http://www.youtube.com/watch?v=iwXFOgNVMww

Programming & Technical

• John Carmack, “Quakecon 2011 Keynote”
  http://www.youtube.com/watch?v=4zgYG-_ha28
• David Aldridge, “I Shot You First! Gameplay Networking in Halo: Reach”
  http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking
• Jonathan Blow, “Programming Aesthetics Learned from Making Independent Games”
  http://www.myplick.com/view/7CRyJCWLM71

C++

(Most of the following are highly technical and specific, but I recommend the first presentation, “Why C++?”, to every programmer.)

• Herb Sutter, “Why C++?”
  http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C
• Herb Sutter, “Writing Modern C++ Code: How C++ has evolved over the years”
  http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T
• Herb Sutter, “C++ Questions and Answers”
  http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers
• Herb Sutter, “Perspectives on Modern C++”
  http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11
• Scott Meyers, Andrei Alexandrescu & Herb Sutter, “C++ and Beyond”
  http://channel9.msdn.com/posts/Scott-Meyers-Andrei-Alexandrescu-and-Herb-Sutter-C-and-Beyond
• Herb Sutter, “Heterogeneous Computing and C++ AMP”
  http://channel9.msdn.com/posts/AFDS-Keynote-Herb-Sutter-Heterogeneous-Computing-and-C-AMP
• Bjarne Stroustrup, “C++0x: An overview”
  http://video.google.com/videoplay?docid=-3478907067117491758
• Herb Sutter, “C++0x Lambda Functions”
  http://vimeo.com/23975522
  (slides: http://www.nwcpp.org/images/stories/lambda.pdf)

The key to multi-threaded OpenGL is in creating multiple contexts that share data between them. On Windows, it is done with the wglShareLists() procedure. On X and Apple APIs, it can be done during context creation (glXCreateContext() and aglCreateContext(), respectively). It boils down to creating a second context for the loader thread, and setting it to share data with the main context. This way, all data loaded on the second context will be available on the main one – you can just create a texture normally on the loader thread, and then glBindTexture() it on the main thread, for example.

On Windows/C++0x, the code looks like this:

void startLoader(HWND hwnd)
{
	// Assuming that this is the main thread
	HDC hdc = GetDC(hwnd);
	HGLRC mainContext = wglGetCurrentContext();
	HGLRC loaderContext = wglCreateContext(hdc);
	wglShareLists(loaderContext, mainContext); // Order matters

	boost::thread([=] () {
		wglMakeCurrent(hdc, loaderContext);
		runLoader();	// Your method for loading textures
		wglMakeCurrent(nullptr, nullptr);
		wglDeleteContext(loaderContext);
	});
}

Most APIs (such as Allegro, SDL, wxWidgets, etc) will provide you with a simple method of retrieving the window handle, which is all that you require to call the above procedure.

Note that you could create the context and share the lists inside the loader thread, but wglShareLists() must be called BEFORE anything is done on the main context, so the safest way is to do it on the main thread (otherwise, the new thread could take a while to run and be too late to do it).

IMPORTANT! I have observed that, on some cases (Windows 7 64, NVIDIA 320M), attempting to use a texture after it has been created (via glGenTextures()) but before its data finished uploaded (in this case, via glTexSubImage2D()) resulted in the texture being corrupted, and remaining corrupted even after it was uploaded. This will happen even if you wait for glTexSubImage2D() to return before using it on the main thread, since OpenGL is asynchronous. To avoid this problem, make sure that you glFinish() the loader thread before you attempt to use any textures initialized there.

—

“If programming languages were religions”

(Inspired by “If programming languages were cars“)

C would be Judaism – it’s old and restrictive, but most of the world is familiar with its laws and respects them. The catch is, you can’t convert into it – you’re either into it from the start, or you will think that it’s insanity. Also, when things go wrong, many people are willing to blame the problems of the world on it.

Java would be Fundamentalist Christianity – it’s theoretically based on C, but it voids so many of the old laws that it doesn’t feel like the original at all. Instead, it adds its own set of rigid rules, which its followers believe to be far superior to the original. Not only are they certain that it’s the best language in the world, but they’re willing to burn those who disagree at the stake.

PHP would be Cafeteria Christianity – Fights with Java for the web market. It draws a few concepts from C and Java, but only those that it really likes. Maybe it’s not as coherent as other languages, but at least it leaves you with much more freedom and ostensibly keeps the core idea of the whole thing. Also, the whole concept of “goto hell” was abandoned.

C++ would be Islam – It takes C and not only keeps all its laws, but adds a very complex new set of laws on top of it. It’s so versatile that it can be used to be the foundation of anything, from great atrocities to beautiful works of art. Its followers are convinced that it is the ultimate universal language, and may be angered by those who disagree. Also, if you insult it or its founder, you’ll probably be threatened with death by more radical followers.

C# would be Mormonism – At first glance, it’s the same as Java, but at a closer look you realize that it’s controlled by a single corporation (which many Java followers believe to be evil), and that many theological concepts are quite different. You suspect that it’d probably be nice, if only all the followers of Java wouldn’t discriminate so much against you for following it.

Lisp would be Zen Buddhism – There is no syntax, there is no centralization of dogma, there are no deities to worship. The entire universe is there at your reach – if only you are enlightened enough to grasp it. Some say that it’s not a language at all; others say that it’s the only language that makes sense.

Haskell would be Taoism – It is so different from other languages that many people don’t understand how can anyone use it to produce anything useful. Its followers believe that it’s the true path to wisdom, but that wisdom is beyond the grasp of most mortals.

Erlang would be Hinduism – It’s another strange language that doesn’t look like it could be used for anything, but unlike most other modern languages, it’s built around the concept of multiple simultaneous deities.

Perl would be Voodoo – An incomprehensible series of arcane incantations that involve the blood of goats and permanently corrupt your soul. Often used when your boss requires you to do an urgent task at 21:00 on friday night.

Lua would be Wicca – A pantheistic language that can easily be adapted for different cultures and locations. Its code is very liberal, and allows for the use of techniques that might be described as magical by those used to more traditional languages. It has a strong connection to the moon.

Ruby would be Neo-Paganism – A mixture of different languages and ideas that was beaten together into something that might be identified as a language. Its adherents are growing fast, and although most people look at them suspiciously, they are mostly well-meaning people with no intention of harming anyone.

Python would be Humanism: It’s simple, unrestrictive, and all you need to follow it is common sense. Many of the followers claim to feel relieved from all the burden imposed by other languages, and that they have rediscovered the joy of programming. There are some who say that it is a form of pseudo-code.

COBOL would be Ancient Paganism – There was once a time when it ruled over a vast region and was important, but nowadays it’s almost dead, for the good of us all. Although many were scarred by the rituals demanded by its deities, there are some who insist on keeping it alive even today.

APL would be Scientology – There are many people who claim to follow it, but you’ve always suspected that it’s a huge and elaborate prank that got out of control.

LOLCODE would be Pastafarianism – An esoteric, Internet-born belief that nobody really takes seriously, despite all the efforts to develop and spread it.

Visual Basic would be Satanism – Except that you don’t REALLY need to sell your soul to be a Satanist…

Thanks to jfs and other people on #aegisub for the suggestions. Keep in mind, this list is a joke, and is not meant to offend anyone. Also, if you’re a Muslim, please don’t kill me.

A simple model

How simply could we model a computer game? Let’s start by separating the game in two parts: the data inside the computer, and everything outside the computer. This might seem like a strange thing to say, but remember that games are, first and foremost, interactive software. So, outside the computer, we have (at the very least) the player. Inside the computer we have all sorts of data, but the most important is what we call the game state: it contains all the dynamic information of the game: the position of the player, monsters and camera; the current time; the score – in essence, everything that changes with time.

A computer game can then be understood as a system in which those two entities – player and game state – interact with each other according to a specific pattern of rules. The player inputs data into the system, and the system uses the game state to generate output to display to the player. This is not very different from ordinary applications, in which e.g. a click (input) might cause a dialog to show up (output). The difference is how that behaves in respect with time.

The Game Loop

Most applications are developed in a reactive way – your program just sits around waiting for the user to click something, and then it does something in response. There is a main loop behind your application as well, but it’s not important – it’s abstracted away. With games, your code is constantly being invoked, even in the absence of user input.

The pseudo-code for a video game will often look like this:

void GameClass::main() {
    init();
    runMainLoop();
    deInit();
}

The main loop looks something like this:

while (running) {
    processInput();
    updateGameState();
    drawScreen();
}

First, it reads input from the user and stores it somewhere. Here, it will check the keyboard, gamepad, plastic guitar and network message queues – basically, it will collect all information from the outside world.

After that, it will use that information to update the game state – depending on what conditions we have, they will have different results. For example, on the menu screen, detecting that the “down” arrow got pressed might increment the “currently selected menu item” variable, but the same input while on the game might instead trigger the “set player as moving down” flag. Note that the world update is invoked even if the user didn’t perform any input. This is a very important property of most video games.

Lastly, it will collect the current game state data to generate the output – it will figure out where the player and camera and everything else are, and generate an image to display on the screen. A more complicated game will also have to deal with other forms of output – audio and network, for example.

A More Sophisticated Main Loop

The loop pseudo-code above suffers from a major flaw: it will run at unpredictable speeds – on fast machines it might run thousands of times per second (which would be a waste), and on slow machines it might run on unacceptably slow speeds – perhaps only five updates per second or so. Besides the obvious issues, this makes the game much harder to program – it’s much easier to write your game logic when you know that you’ll have a fixed number of steps per second.

Consider this: the player presses the right arrow, and you store a flag containing that information. Now, on every step, regardless of any player action, you’ll move the player to the right by 1 unit in the game state (which, let’s say, corresponds to 1 pixel on the screen). If the game runs at 5 Hz (that is, 5 updates per second), the player will move VERY slowly. If it runs at 5000 Hz, he’ll be out of the screen before you can even see it!

A possible solution to this is to calculate the real time elapsed between two steps and use this information during the step. In practice, however, this makes the game development much harder and error prone. It will also make networking a true nightmare, and will essentially make reliable behavior (e.g. replays) impossible.

A much better solution is to fix the rate at which your game performs its updates. Most modern games use an internal clock of 60 Hz or 30 Hz. Let’s assume 60 Hz for our example. This means that, 60 times per second, your game will check the input from the player, update the game state, and try to display something on the screen. But how do we control that?

First, let’s consider the case of a very fast computer. In this case, before each iteration of the main loop, we’ll check if it’s time for the update. If it isn’t, we’ll simply wait (preferably yielding the time slice back to the operating system), without doing any processing.

In the case of a slower computer, things are trickier – we can’t skip on updating the game state, or the game will run in slow motion, so we must sacrifice the output – the screen rendering. On most games, screen rendering is the slowest part of the pipeline, meaning that most games WILL be able to run at 60 Hz given enough sacrifice on graphics. If not, then the game will be way too slow, and we have no choice but ask the player to get a better computer.

In pseudo-code, our new algorithm now looks somewhat like this:

while (running) {
    if (isTimeToUpdate()) {
        processInput();
        updateGameState();
        if (hasTimeToDraw()) drawScreen();
    } else {
        waitUntilItsTime();
    }
}

It’s simple, but it’s very similar to real game loops found in real games.

The Foundation

At this point, it should be clear that the vast majority of the game code will run inside the main loop – in a simple game, everything except for initialization and deinitialization. Also, that code is now separated in three functions: processing input, updating the game state, and rendering the screen. Since all three of them are controlled by the loop, it’s the foundation block of every game.

Having this foundation, your task of implementing a game has been reduced into three simpler and relatively independent tasks. The input you collect will be used on the state updating stage, and the state created by that step will be used to generate the output to the user, but they are each their own logically distinct operations, and how they interact with each other is now clear.

If you understand the topic discussed in this article, then all you have to figure out in order to make a (very) simple game is “how to read user input?”, “how to draw stuff on the screen?” and “how to keep track of my state and update it?”. None of those are, at a basic level, difficult, but they might be different from what programmers are used to coding.

On the next article, we’ll try to figure those things out and write an extremely simple real-time game using those concepts.