[Gamasutra is proud to present an excerpt from the book Real-Time Cameras by Mark Haigh-Hutchinson, a veteran Retro Studios staffer who was diagnosed with pancreatic cancer in 2008 and passed away in 2009. The book, published posthumously with help from his colleagues and friends, is available now. For more information on the book's creation, please read this blog post.]

The Camera as an A.I. Game Object

In many ways, the problems presented by camera navigation have parallels within the domain of artificial intelligence (AI). As suggested earlier [in the book], the camera may be thought of as an AI character, at the very least in terms of the determination of its position and orientation within the game world.

The camera may be able to move more freely than many types of AI characters, however, since it is typically floating rather than being constrained to moving on surfaces or under the influence of a physical simulation. This freedom of movement is one of the benefits of a virtual camera system when compared to real-world cameras.

Yet, even though the camera may determine its path finding in a similar way to that used by AI characters, there are usually additional constraints concerning (for the most part) aesthetic issues such as target object framing, target object distance, and render geometry avoidance.

There are many interesting areas of AI navigation research, such as robotics, that may be applied to cameras. In particular, research toward autonomous methods of movement determination is highly relevant if we desire to have camera motion that is responsive to dynamic game events. The references at the end of this excerpt contain several pertinent examples such as Borenstein.

Since there are a large variety of environmental types, we will assume here that the camera is constrained to remain within a closed environment consisting of a collision surface representation such as a polygonal mesh, with additional independent game objects. Here closed means that the representation of the environment forms a contiguous surface that constrains all usual game objects (even so, there may still be cases where it is necessary for the camera to be positioned outside of the environment).

The collision surface may be considered as a separate entity to that of the rendered world (although they may in fact be the same), with additional information regarding surface materials stored on a per-face or sub-surface basis. It is also assumed that mechanisms exist within the game engine to cast rays through the environment returning results as to collision points and the materials found at that point.

Additionally there may be a need to filter the types of materials that are eligible for detection in any particular ray cast (e.g., some surfaces may allow the camera to pass but not regular game objects). Optimization and organization of collision data is not discussed in this book, but the reader is referred to VandenBergen and Ericson for more information about collision system design and implementation. Additionally, Chapter 9 describes some of the main methods used in camera collision detection and avoidance.

Predictive cameras (as described in Chapter 2) typically have better navigation results than reactive cameras, as they are more likely to anticipate changes to the environment that would occlude the player character. Naturally, this comes at additional performance cost.

Navigation Techniques

Fundamental to all navigation methods are the ways in which the camera may request environmental data regarding potential obstructions or paths of motion. The nature of the game environment, its data representation, and facilities offered by the game engine will greatly influence the choice of navigation techniques. We may consider there to be two general classifications: dynamic and pre-defined.

Dynamic navigation techniques

Dynamic navigation refers to techniques that do not rely on predefined information to position or move the camera. Instead, they question the game world to determine how the camera should be positioned on a per-frame basis. Since this can be computationally expensive, a number of techniques may be required to amortize the processor cost.

An important consideration when using dynamic solutions is that it is difficult to account for the myriad of positions and actions that may be performed by the player. This means that it is difficult to test all the permutations as well as to be certain that no special case exists that might be problematic for the chosen navigation solution. Let us examine some of the more common dynamic navigation methods.

Ray casting

One of the simplest and most common navigation methods is that of the ray cast, a mathematical projection of a straight line through the virtual environment. By using trigonometry it may be determined if the line would intersect with either the collision geometry corresponding to the environment or that of an object within it. As might be expected, this can be computationally intensive especially given the complexity of many environments.

An important goal when implementing camera systems is to limit the amount of such testing whenever possible. Amortization of ray casting is entirely possible and can be quite effective in reducing the processor requirements at a cost of limiting the amount of information available to use for navigation.

Fortunately, navigation does not require a per-frame updating of such information as its decisions are normally longer lasting and may take more time to evaluate than collision or other immediate concerns. Similarly, reducing the set of data to be compared against (e.g., using spatial partitioning or material filtering) is also recommended.

Ray casts can often provide extremely pertinent information for camera systems, for example, collision prediction and player character occlusion. Furthermore, ray casts may be combined together to produce a more detailed view of possible obstructions. On the other hand, since ray casting normally involves (by definition) projection of a 3D line through the game world, it is entirely possible for the ray to pass through small openings and thus not register a collision.

Normally this problem is reduced by simply increasing the number and positioning of the ray casts to cover a larger area, although care must be taken given the potential performance costs. It may also be avoided by having a separate collision mesh that only pertains to camera movement and would thus not include such small openings.