Tom Plunket

Tom Plunket moved to Southern California to work at Sammy Studios back at the end of 2003 but there was a big meltdown and conflicts there led to his not-terribly-amicable departure. He is presently employed by Ready At Dawn Studios, LLC in Irvine, CA. Ready At Dawn made their name doing some of the biggest selling games for the Sony PSP, and are now working on a project that will be huge for the home console (iow, "not a handheld") market.

Tom read all that he could find about ExtremeProgramming and this website was pointed out to him by PhlIp via web postings on CompLangCplusplus? circa summer 2002.

He lives at http://www.fancy.org/ but he doesn't really push it too hard. He also started http://www.scivium.com/ and http://onenationdivisible.blogspot.com/ but fell off the blogging wagon too. Besides moderately evangelizing "Beyond Agile" (for the game industry has fallen deeply into the well of BuzzwordCompliance?), he spends most of his (enjoyable) time writing controllers for the camera in 3D games.

I often do derivations at my desk of math stuff I knew once but forgot. Sometimes I do it for fun, to see if two things that look similar or related actually are. This yields a whiteboard full of equations, or maybe a desk covered in paper that are covered in equations. One of my coworkers frequently brings his kids and his kids' friends by, and gaze in awe at this "stuff". My favorite comment was, "so that's what math is for!" Heh, I love kids. It gives us an excuse though to talk to them about paying attention in school and doing their homework. :)

Camera control in 3D games

It's an interesting problem, and one that most games get utterly wrong. I had the fortune of working on the SyphonFilter? series' early incarnations (on the original PlayStation) where we had a fantastic programmer working on this, and he gave me a lot of information on what sorts of problems he was running into and what sorts of solutions he was coming up with. I took this information and have molded it and grown it to encompass the requirements for a variety of games that I've worked on, and I'm approaching a general solution for the problem. This is very exciting, and will lead to publication of this solution at some time.

Some of the problems that people run into can be attributed to inappropriate coupling in the architecture of the system. Ostensibly, there is a bit of software that generates a location and an orientation for the camera, but too often the architecture of the system just stops there and jams a whole ton of logic into one function or one class. Fact is, there's more than one thing going on here (as my description above likely implies), so it actually makes sense to break the components out to some degree.

Each bullet implies a "system" of some degree; leaf-level bullets generally map to individual classes (but this is a work-in-progress and as such woefully incomplete; it's past my bed time!).

Determine "ideal" camera location and look-at point (which implies orientation), among other parameters (such as field of view)
Compute "view" vector (i.e. look at point - camera location)
Determine collisions between this vector and the environment (including entities in the environment)
Truncate or bend the view vector, as appropriate
Compute delta vectors for both computed points from the current state
Determine collisions between these vectors and the environment
Bend these delta vectors based on the collisions
Update the current notion of "ideal location" based on the new delta vectors
Compute the desired movement vectors with damped springs between the "ideal" and "current" positions (see http://en.wikipedia.org/wiki/Damping), through the appropriate coordinate system (see below)
Determine collisions between the movement vectors and the environment
Bend the movement vectors as appropriate
Move the camera

Advanced implementations will keep track of the target velocities as well as positions, and subsequently damp the sprung motion based on the relative velocities rather than absolute. This gets tricky and somewhat tedious when working in non-Cartesian spaces (or maybe I'm just not that smart!).

Coordinate spaces that are used for camera control include:

Cartesian, which is the XYZ space that everyone is familiar with
cylindrical, which uses polar coordinates on the ground plane plus height above target
spherical, which uses polar on the ground plane plus angle above target

For the motion of the camera itself, Cartesian is good when there isn't a specific focus point for the camera; the camera is looking at the scenery rather than a specific object (e.g. the player avatar). When there is a specific target, it's often better to use cylindrical or spherical coordinates to track the camera motion. The decision between cylindrical and spherical comes down to aesthetics; spherical tracking looks best when used in games where the camera closely follows the player avatar (and is what appears in the PlayStation2 and Wii versions of MX vs. ATV Untamed), whereas cylindrical coordinates track "nicer" in games where the camera is fixed more relatively to the environment, such as in God of War (although I don't know if this is how they do it, I suspect it is [Yeah, ImplementationGuessing is a nice sport]).

For the determination of what to look at, decisions need to be made between these coordinate systems as well. However, in this case, the determination is a little more ambiguous. In my experience, if the camera position is tracking in Cartesian space, the look-at point should be non-Cartesian, and vice-versa, but I don't have any better rules for this at this time.

I based my decisions on which sorts of coordinate systems to use based on observing how the cameras move in movies, since many are familiar with them (to understate a bit), so I thought it best to design an in-game camera system that behaved as people would "naturally expect" based on their experience with other media.