User Control for Camera Direction

User Control for cameras is not a very deep subject but I have some notes. These notes are based on experience from implementation and not concrete facts.

User Control For Orbiting a Camera around a Target

Smoothing

I prefer no acceleration or weight on the camera rotation based on player input, but that is something that many designers disagree with me about. My reasoning is that I like the immediacy of control to camera direction and I care more about accuracy than soft movement. The opposing reasoning is that it feels jumpy and unpolished. Spend some time on the smoothing parameters to get a decent compromise, especially if the smoothing also applies to cameras used for precision aiming.

Leash Camera Example

The leash camera is simple to implement and tracks a moving camera target intuitively without much polish. It can even be implemented without resorting to euler angles or quaternions since it deals entirely with the offset between the camera and the target over time.

The camera will work as long as the target speed and the distance between the camera and the target are within reason, which is usually true in platforming games.

The idea is that as the target moves away from the camera, the camera moves straight towards (or away from) the target to maintain the desired distance. Think of this as walking a dog that is running all over the place, and the leash will be stretched straight from the dog walker to the dog. The dog walker will rotate and move far less than the dog but still keep up with it. (For this example to work you also need to assume that the leash is a straight rod and not really a leash at all.)

Leash Camera Direction tracking a target moving from left to right.

Framing a target

I tend to update a game camera in this order:

1. Update all possible camera targets
2. Determine current target (“subject”)
3. Apply change of camera mode or parameters
4. Determine the camera facing direction
5. Determine a camera position
6. Collision and other post update operations.

I make exceptions to this order for cameras with restricted positioning, such as cameras aligned with splines, which is a topic for future posts. Although this site does not focus on VR there are additional order updating considerations for that too.

Placing a camera to frame a subject

Of these steps, the most basic one is probably determining the camera position. It is also more forgiving than camera rotation in terms of keeping track of distant objects on the screen. When rotating the camera a distant point will move farther on-screen than a closer point, but when translating the camera the distant point will move less than a closer point.

First steps for a game camera

The first version of a camera tracking a target on screen could be a fixed offset from the center of the target with the camera looking straight along the offset.

This is really all there is to get started and it is time to think about the next steps. This is a few questions to ask about the game before deciding on a direction for the camera that will influence level layout, art detail, how far sounds need to be heard and much more.

There are a lot of considerations when framing multiple targets at once but to reduce the scope this post will focus on game cameras with a single target. This post does not contain anything new, it is intended as a checklist to get started with a game camera.

Different camera distances

Any artistic qualities for framing subject would require a far longer post so instead I will resort to suggest defining some metrics at this point;

Intersection of three planes

Three plane intersections can make framing shapes on a screen trivial, along with many other applications. While useful for prototyping, I don’t tend to use three plane intersection in final products as there are a lot of things working together.

There are several cases where three planes do not meet in a single point, but there is a simple test for that. For most intersection applications with camera space I have not encountered this but it is worth keeping in mind.

Intersection of three planes

Unsurprisingly the solution is similar to finding a point along the line of a two plane intersection:

P = (d1(n2 ✕ n3) + d2(n3 ✕ n1) + d3(n1 ✕ n2)) / (n1 ᐧ (n2 ✕ n3))

Intersection of two non-parallel planes

Plane intersections can solve a number of camera framing optimization problems and is an easy way to for example find the rays along the corners of the view frustum given the screen edge planes.

Any line that lies on a plane is perpendicular to its normal, so the only line that is shared between both is perpendicular to both normals, or the cross product of the normals:

D = n1 ✕ n2

If the planes are parallel the cross product will be zero since there will be no intersection. This is a rare case when dealing with camera space but worth keeping in mind.

Two parallel planes will not intersect and two non-parallel planes will intersect in a line.

If any point of the line is already known, for example the intersection of any two camera frustum planes will intersect with the camera position, this is all that is needed.

If no point along the intersection is known there are a few more steps.

Constructing the camera frustum planes

The camera frustum is defined by the orientation and field of view of the camera and looks like a pyramid with the peak located at the camera and everything inside is visible on the screen.

Each edge of the the screen can be represented by a plane and in addition the near and far distances cap the frustum. Creating planes of the surface of the frustum is not the only way to represent it but it is convenient for many tests and placements.

A typical camera frustum with plane normals pointing outwards.

Before jumping in to formulas the value of field of view needs to be described.
The most common way to describe field of view in games is an angle between the top and bottom or between the left and right side of the screen, and most math uses the half field of view.