Points and Vectors

The single most important distinction in game math hides behind two things that look identical on screen: both are just a list of numbers like (3, 1, 4). Yet one is a point — a location, "the chest is here" — and the other is a vector — a displacement, "two metres east and one up". A vector has a direction and a length but no home; you can slide it anywhere. A point has a home but no direction.

Confuse them and the bugs are baroque: a "velocity" that drifts when you move the world's origin, an enemy that teleports when you reparent it. Keep them straight and the algebra itself tells you what is legal.

The four operations — and the one that is forbidden

Write points as P, Q and vectors as \vec{v}, \vec{w}. There are exactly four combinations that make sense, and one that does not. We build them up one line at a time.

Step 1 — point minus point is a vector. Subtract two locations and the "where" cancels; what survives is the trip from one to the other — its direction and length. This is the workhorse: the displacement from Q to P.

P - Q \;=\; \vec{v} \qquad (\text{a vector: the displacement from } Q \text{ to } P).

Step 2 — point plus vector is a point. Start at a location and apply a displacement: you land at a new location. This is how everything moves — the player each frame is P_{\text{new}} = P_{\text{old}} + \vec{v}\,\Delta t.

P + \vec{v} \;=\; P' \qquad (\text{a point: } P \text{ moved by } \vec{v}).

Step 3 — vector plus vector is a vector. Two displacements done in sequence are one combined displacement — "east two, then up one" is a single arrow.

\vec{v} + \vec{w} \;=\; \vec{u} \qquad (\text{a vector}).

Step 4 — point plus point is meaningless. Add two locations and ask what you get. "The chest plus the door" is nonsense, and worse, the answer changes if you move the origin — so it cannot describe anything physical. The operation is simply not defined.

P + Q \;=\; \text{??} \qquad (\text{undefined — locations don't add}).

(The honourable exception is an average: the midpoint \tfrac12 P + \tfrac12 Q is fine, because the weights sum to 1. A general sum of points with weights summing to 1 is an affine combination, the only blessed way to "add" points.)

How the maths enforces the rules: w = 1 vs w = 0

You could police all this by hand — or you could let the numbers do it for you. In homogeneous coordinates every quantity carries one extra bookkeeping component, w: a point gets w = 1, a vector gets w = 0.

P = (P_x, P_y, P_z, \mathbf{1}), \qquad \vec{v} = (v_x, v_y, v_z, \mathbf{0}).

Step 5 — watch the w-component do the policing. Add or subtract component-wise and just read the last slot:

\underbrace{1}_{P} - \underbrace{1}_{Q} = \underbrace{0}_{\vec{v}}, \qquad \underbrace{1}_{P} + \underbrace{0}_{\vec{v}} = \underbrace{1}_{P'}, \qquad \underbrace{0}_{\vec{v}} + \underbrace{0}_{\vec{w}} = \underbrace{0}_{\vec{u}}.

Point minus point lands on w = 0 — a vector. Point plus vector lands on w = 1 — a point. Vector plus vector stays at w = 0. And the forbidden one outs itself: point plus point gives w = 1 + 1 = 2, which is neither a point nor a vector, a loud signal that you did something undefined. The same w also makes a translation matrix ignore vectors (you don't move a direction) while still moving points.

A point is a location; a vector is a displacement (a direction together with a length). With points P, Q and vectors \vec{v}, \vec{w}:

Point − point = vector — P - Q = \vec{v}, the displacement from Q to P.
Point + vector = point — P + \vec{v} = P', the point moved by \vec{v}.
Vector + vector = vector — \vec{v} + \vec{w} = \vec{u}, displacements compose.
Point + point is undefined — locations don't add (only affine combinations, weights summing to 1, are allowed).
The bookkeeping — points carry w = 1, vectors carry w = 0, so the arithmetic of the w-slot enforces every rule above.

The distinction is not pedantry — it is how you store a game world. A character's position is a point (where it stands). Its velocity is a vector (how fast and which way it heads), and the update is the canonical point-plus-vector,

P_{t+\Delta t} = P_t + \vec{v}\,\Delta t.

When the AI asks "which way is the enemy?", it never adds the two positions — it subtracts them, point minus point, to get the displacement \vec{d} = P_{\text{enemy}} - P_{\text{self}}: a vector pointing straight at the target, whose length is the distance. Normalise it and you have a heading; measure it and you have a range. Every "look at", "chase", and "shoot toward" in the engine is one point subtraction.

A point and a vector are usually stored as exactly the same kind of triple — a Vector3 or (x, y, z) struct doesn't know or care which one it holds. That is convenient right up until it hides a bug: the compiler happily accepts playerPos + enemyPos because, syntactically, "triple plus triple" always type-checks — even though semantically you just added two locations, which is the one operation the maths forbids.

The code runs. It produces a number. It just isn't a meaningful location — and worse, it silently depends on where the world's origin happens to sit, so it can look "close enough" in one scene and wildly wrong in the next. A classic version of the mistake: computing a midpoint as a + b instead of the affine average \tfrac12(a + b), or writing pos + otherPos when you meant pos + velocity. Nothing crashes; the character just drifts to a place that makes no sense. The fix isn't a runtime check — it's naming your types (or at least your variables) so a point can never masquerade as a vector in the first place.