Direction Vectors

Summary

A direction vector is a normalized vector used purely to represent "which way," with its length deliberately fixed at 1 so it never carries distance information. Subtracting one position from another and normalizing the result is the standard way to get "the direction from A to B" — this single, repeated pattern underlies aiming, movement toward a target, facing checks, and orienting objects toward each other throughout game code.

Why This Matters

Movement, aiming, and orientation logic all need a consistent way to ask "which way should this face/move," separate from "how far away is it." Using a raw, un-normalized offset for this purpose silently ties direction to distance — a far-away target and a nearby one would produce direction "vectors" of very different lengths, breaking anything that assumes a consistent unit length (like multiplying by a speed value, or feeding into a dot product for an alignment check). Treating direction as its own concept — always a unit vector — keeps every system that consumes a direction working correctly regardless of how it was derived.

Mental Model

A direction vector is a compass needle, not a route. A compass needle always has the same length no matter how far away your destination is — it only ever tells you which way to walk, never how far. Direction vectors work the same way: whether the target is one meter away or one kilometer away, the direction vector pointing toward it looks identical in length (1), differing only in which way it points.

Core Explanation

Derived from subtracting two positions, then normalizing. direction = (target - origin).normalized — subtraction gives the raw offset, normalization strips out the distance, leaving pure direction.
Always has a length of exactly 1 (a unit vector). This makes direction vectors directly comparable and safely combinable with other unit vectors (like an object's forward direction) without one dominating the other due to length differences.
An object's own "forward," "right," and "up" are also direction vectors, maintained by its rotation. transform.forward in Unity or GetActorForwardVector() in Unreal are pre-computed unit vectors derived from the object's current orientation, not from any subtraction — a second common source of direction vectors beyond "point minus point."
Multiplying a direction vector by a speed or distance value produces a meaningful displacement. direction * speed * deltaTime turns a pure direction back into an actual per-frame movement amount, cleanly separating "which way" from "how much" throughout the calculation.

Syntax / Theory

Engine-neutral (formula)

text

directionFromAToB = normalize(B - A)

C# (Unity)

csharp

Vector3 directionToTarget = (target.position - transform.position).normalized;
transform.position += directionToTarget * speed * Time.deltaTime;

csharp

Vector3 forward = transform.forward; // Already a unit vector — the object's own facing direction.

C++ (Unreal)

cpp

FVector DirectionToTarget = (Target->GetActorLocation() - GetActorLocation()).GetSafeNormal();
AddActorWorldOffset(DirectionToTarget * Speed * DeltaTime);

cpp

FVector Forward = GetActorForwardVector(); // Equivalent to Unity's transform.forward.

Both engines expose the object's own orientation as ready-made direction vectors (transform.forward/GetActorForwardVector()), sparing you from deriving them manually via subtraction — reserve subtract-then-normalize specifically for "direction toward some other point."

Practical Example

A "look at" behavior rotates an object to face a target using the direction vector between them.

csharp

public class LookAtTarget : MonoBehaviour
{
    public Transform target;

    void Update()
    {
        Vector3 direction = (target.position - transform.position).normalized;
        transform.rotation = Quaternion.LookRotation(direction);
    }
}

Quaternion.LookRotation expects exactly this — a direction vector — and uses it to compute the rotation that makes the object's forward axis point that way.

Common Mistakes

Passing a raw, un-normalized offset where a direction was expected. Functions like LookRotation or a dot-product-based alignment check assume a unit-length input; skipping normalization produces subtly wrong results that don't immediately look broken.
Forgetting the subtraction order determines which way the direction points. (target - self) points from self toward target; (self - target) points the opposite way — reversing the order silently flips every downstream calculation that depends on it.
Re-deriving a direction vector via subtraction when the object's built-in forward/right/up already provides it. Manually subtracting an object's own position from a point directly in front of it to approximate "forward" is unnecessary and error-prone compared to using the engine-provided direction directly.
Not guarding against a zero-length offset before normalizing, exactly the same zero-vector hazard covered in [[CON-0045]] — a target at the exact same position as the origin has no meaningful direction.

Game Development Example

A turret rotates to face the nearest enemy using the direction vector toward it, while a separate check uses the dot product to decide whether the target is even within the turret's forward-facing cone.

csharp

public class Turret : MonoBehaviour
{
    public float fieldOfViewDot = 0.5f; // ~60 degree half-angle, expressed via dot product.

    void TryTrackTarget(Transform target)
    {
        Vector3 direction = (target.position - transform.position).normalized;
        float alignment = Vector3.Dot(transform.forward, direction);

        if (alignment >= fieldOfViewDot) // Both vectors are unit length — see CON-0048.
        {
            transform.rotation = Quaternion.LookRotation(direction);
        }
    }
}

The direction vector here is doing double duty: rotating the turret, and feeding into the dot product that decides whether the target is even within view.

Best Practices

Always normalize an offset before treating it as a direction — never assume a subtraction result is already unit length.
Prefer an object's built-in forward/right/up direction vectors over manually deriving an equivalent through subtraction.
Be deliberate about subtraction order (target - origin, not the reverse) and document it if the direction's meaning isn't obvious from variable names.
Guard against normalizing a zero-length offset when the origin and target could coincide.

Exercises

Write a method that returns the normalized direction from one Transform to another, and use it to rotate an object to face a moving target every frame.
Take the LookAtTarget example and swap the subtraction order (transform.position - target.position instead of the reverse) — describe what visibly changes about the object's rotation.
You're building a homing missile that should curve gradually toward its target rather than snapping instantly to face it. Decide how the direction vector toward the target should be combined with the missile's current forward direction to produce gradual turning, and justify your approach.
Research spherical linear interpolation (Slerp) between two direction vectors and explain, in your own words, why it's generally preferred over plain linear interpolation (Lerp) when smoothly blending between two directions.

Vector Normalization — a direction vector is, by definition, a normalized vector; normalization is the mechanism that produces it.
Dot Product — comparing two direction vectors (to measure alignment, facing, or field-of-view) is one of the dot product's most common uses, and specifically requires both inputs to be direction vectors.
Coordinate Systems — a direction vector's meaning depends on which coordinate space it's expressed in (world space vs. an object's local space), the same distinction that applies to positions.

Direction Vectors

Direction Vectors

Summary

Why This Matters

Mental Model

Core Explanation

Syntax / Theory

Practical Example

Common Mistakes

Game Development Example

Best Practices

Exercises

Further Reading

Related Concepts