The Full Spectrum Warrior Camera System

FW: http://www.gamasutra.com/gdc2004/features/20040325/giors_01.shtml

Camera systems are among the most important systems in any game. After all, the camera is the window through which the player interacts with the simulated world. Unfortunately, the camera system is often neglected during the development process, as it is easy to take for granted. When making Full Spectrum Warrior (FSW), special attention was given to camera system issues, resulting in unique solutions to several problems.

This article discusses specifics of the camera system as developed for FSW. A brief functional overview of the camera system will be followed by a description of the high-level architecture. Following that, the details of the motion system will be examined. The next section covers FSW's unique "autolook" feature. Then, the bane of every camera system-collision avoidance-will raise its ugly head. Finally, debugging, tuning, and miscellaneous issues will be covered. To wrap it all up, the limitations of the FSW camera system will be discussed, along with some general recommendations that apply to most projects.

FSW System Functional Overview

In FSW, the user controls two teams of four soldiers each, and the primary camera system is under the control of the user (manipulated with the gamepad's right thumbstick). One of the soldiers on each team is the team leader. Pressing the Y button switches teams. The camera performs a fly-by to the other team's leader, assuming the same facing as the soldier. During the fly-by, the camera is not under user control. When the camera arrives at the team leader, camera control returns to the user.

There is a brief lockout period at the beginning of a fly-by during which inputs from the gamepad are not accepted. However, after the initial lockout period, the user may make inputs. In this situation, when an input is detected, the camera cuts immediately to the destination and the user regains control of the system.

The user may also select different soldiers on a team using the d-pad. The camera automatically attaches to the character, performing a mini-fly-by. This allows the user to get different vantages on the current situation.

FSW also has in-game cinematics, which take over camera control. In addition to use of the normal in-game view system, the cinematic camera may move between preset positions.

High-Level Architecture

Although only one camera can be viewed at any particular time, the camera system actually comprises several cameras, each of which may operate simultaneously and independently. Using multiple, independent cameras is useful because different viewing situations have different requirement. Attempting to make one general purpose camera that does everything is likely to lead to an overly-complex system.

Additionally, using multiple cameras allows blending camera positions and orientations during transitional cases. This technique is not currently used in FSW, though cinematic transitions use a filtering algorithm that behaves very much like a blend.

In FSW, each camera is derived from an abstract base class, which provides an interface for common functions, such as obtaining the camera world matrix or zoom factor. The "main camera" implements the primary user-controlled view and fly-by systems. There are several other cameras for cinematics, in-game events, and the playback system.

With several cameras in simultaneous operation, it can be difficult to coordinate their activities and their interactions with other game components. FSW has a "camera manager" object which tracks the cameras. All interactions with other game components take place in part through the camera manager.

Motion System

Instead of using FSW's actual coordinate system (it is a bit unorthodox), the following coordinate system will be used for the remainder of this paper:

• The view coordinate system is a typical right-handed system. Relative to the screen: the positive x-axis points to the right, the positive y-axis points up, and the positive z-axis points into the screen (away from the viewer).

	Figure 1: View coordinate system.

• The world coordinate system is similar to the view coordinate system: the positive x-axis points east, the positive y-axis points up, and the positive z-axis points north.
  
• Since the camera is always assumed to remain horizontal, the orientation can be specified with only two angles, pan and tilt. Pan rotates around the y-axis, while tilt rotates around the x-axis. Note that, when calculating camera matrices, tilt is applied first, then pan.

It is also worth noting that some cinematic transitions interpolate the camera orientation using quaternions. However, quaternion interpolation is the exception rather than the rule in the FSW camera system.

To control the motion of a camera, it is often useful to move the camera using target points. A target point is the final position where the camera should arrive. The camera controller filters the camera position to move the camera to the target point with a smooth motion. Using target points helps separate the problem of choosing good viewing positions from the problem of providing smooth and predictable motion.

The Basic Proportional Controller (PC)

The PC is common in many camera systems. If you have worked on a camera system, you have probably used a PC, though it might have been called something else--terminology for this particular construct is not very consistent.

The typical implementation is to set the velocity vector, V, equal to a proportion, C, of the difference between the current position, P, and a target position, Pt:

V = C(P₁ - P)

One advantage of the PC is its simplicity. In addition, the PC has a nice arrival characteristic. As the current point, P, approaches the target, Pt, the velocity asymptotically approaches zero, following an exponential decay. This gives the PC a "graceful" feeling when it is approaching its destination.
Although the PC is simple and has a nice arrival characteristic, it also has two significant disadvantages.

1. The "exit" characteristic can be abrupt. When the target point, Pt, changes suddenly (as happens when the target is changed from one game object to another), the PC will change velocity instantaneously. This sudden change in velocity makes the camera system feel unnatural.
2. The current position, P, lags behind moving targets. When a target is moving, the PC lags behind by the following proportion, which can be found by rearranging the previous equation:

Lag = |P₁ - P| = |V| / C

This lag behind moving points leads to tuning issues. When the PC is tuned for a nice "arrival" characteristic, the lag behind moving objects will often be very large. When the PC is then tuned to reduce lag, the arrival characteristic will often be too fast (and the exit characteristic can grow to excessive levels).

The Modified Proportional Controller (MPC)

To solve the problems encountered with the PC, the FSW camera system uses a modified proportional controller ("MPC" for short). The MPC addresses the two drawbacks of the basic PC in the following manner.

The exit characteristic is controlled. The exit characteristic is controlled by limiting the acceleration of the current position, P. This is a straightforward calculation.

	Figure 2: Limiting acceleration. V is the current velocity and Vk is the desired velocity. Vdiff is the current difference and dV is the limited acceleration (delta velocity) for one frame.

Given a current velocity vector, V, and a desired velocity vector, Vk, calculate the difference:

V_diff = V_k - V

Assume that Alim is the acceleration limit (a scalar, not a vector). The maximum change in velocity for one frame is:

dV_max = A_lim * dt

Now, compare dVmax with Vdiff:

if (|V_diff| < dV_max)
dV = V_diff
else
dV = dV_maxV_diff / |V_diff|

Now, use dV to update the velocity.

V¹ = V + dV

Lag is compensated.

Lag is corrected by adding the target point's velocity, Vt, into the desired velocity:

V_k = C(P₁ - P) + V₁

This desired velocity, Vk, is then used to determine the acceleration, which is limited as mentioned above.

As mentioned previously, camera orientation is parameterized by a pan and a tilt value. The two parameters are updated independently using a one-dimensional version of the MPC described above.

More About Target points

Although the MPC helps solve many of the issues involved in making a camera system operate in a nice, smooth manner, it does not solve every problem, and it can still exhibit problems with certain types of inputs. In particular, when working on the motion system, the following problem arose.

When a moving target point is specified, it is expected that the camera will eventually track exactly onto the moving point, i.e., the camera may have to fly to catch up, but it should eventually be dead-on. That is a reasonable expectation, however, since the camera has limited acceleration (to keep it moving smoothly), it becomes obvious that, when a target point stops abruptly, it is impossible for the camera to do anything but overshoot (since its acceleration is limited and it cannot "stop on a dime"). This means there are only two possible choices: either the motion system can lag behind the target to give it a "buffer space" for handling sudden decelerations, or the motion system can track exactly onto target points, but it will overshoot when the target point decelerates rapidly.

There are rather many potential ways that the MPC could be changed to handle this problem. One option is to ensure that the camera lags behind moving target points. Another is to try to make some sort of "smart" algorithm that overshoots, but then does not attempt to return to the target point.

The FSW solution

There is a deceptively simple alternative to modifying the MPC: avoid the issue by making target points behave reasonably whenever possible. The MPC algorithm remains unchanged, but its inputs are improved. Examples from FSW are:

• Target points generated from user controls are acceleration-limited. When the user pans or tilts the camera, the thumbstick inputs do not directly affect the velocity. Instead, the user controls the acceleration, and a resistance value limits the maximum velocity.
  
• Soldier positions are filtered with a PC prior to target-point generation. The MPC is not used in this situation, since the target points will eventually feed into the MPC, anyway. In addition to keeping camera motion smooth, this creates a "lag behind" feature that the FSW designers specifically requested.

The FSW "Autolook" Feature

Autolook is a unique feature of the FSW camera system that automatically assists looking around corners. In most third-person games, the character is centered on the screen or is viewed at a constant offset (e.g., over the right shoulder). However, because of the nature of realistic urban combat, this does not work well for FSW. Soldiers tend to spend a lot of time near walls and the corners of buildings. Consequently, using a view centered on the soldier will often result in over 50% of the FOV obstructed by wall.

Autolook solves this problem by determining which part of the view is unobstructed. In this technique, horizontal rays (y value is constant) are cast from the camera center towards the left and right of the camera centerline. When rays intersect the environment, the distance to the intersection is multiplied by a weighting factor (which is identical for all rays) and added to (or subtracted from) the angular offset. Lines on the left side of the camera centerline add to the offset, causing the camera to pan right. Lines on the right side are subtracted from the offset, causing the camera to pan left.

Autolook only affects the orientation of the camera. Position is not modified, as changing the position in this case caused disturbing motion. After the autolook angle is calculated, the angle is filtered, preventing jarring motions.

The weighting factor for autolook depends upon the typical viewing distance. This factor is a tune parameter in FSW and was adjusted until an acceptable result was obtained.

	Figure 3: Autolook raycasts (top view).

	Image 1: Autolook, before and after comparison. The image on the left has no autolook. Roughly 50% of the screen is occupied by a wall. The image on the right uses autolook. The wall occupies much less screen space, bringing more of the playable area into view. Notice how the soldier is framed to the left instead of center.

During playtesting, autolook was a well-received feature of FSW. But does this mean that it would be useful for other games? It isn't possible to give a definitive answer, but, since autolook changes the view angle outside the direct control of the user, it is reasonable to assume that any game which requires quick and precise screen-space aiming would not be well suited to this technique.

However, FSW uses a world-space reticle, which removes many of the issues involved with screen-space aiming. Since the reticle moves through world space, the precise position of the camera is not critical. It is only necessary that the camera keep the reticle in view. It remains to be seen if this technique is responsive enough for quick-paced action games, but the technique should work well for slower-paced games.