Lessons from Suzy Cube: The Camera System, Part 1

Welcome to the first or three articles in a series examining the camera system used in Suzy Cube. This series will dive into several aspects of the game’s camera system with each describing a particular set of features. These articles will also follow the chronological order in which the features have been implemented into the camera system.

The work I’ve put into Suzy Cube’s camera system is especially important to me because it was, actually, the catalyst for the entire project. Before Suzy Cube was a game, it was simply an experimental project for me to attempt to recreate the interesting camera work seen in Super Mario 3D Land for the Nintendo 3DS. For those of you unfamiliar with the game, it is a third person platforming game which, unlike many other 3D action titles, does not allow the player to control the camera. Instead, as the levels are generally a linear set of challenges, the camera automatically switches perspectives as the player moves about the game world in order to best frame the action for the upcoming challenge. This was exactly what I found so great about the game’s camera work and set out to emulate.

So, as I started work on my camera rig, I knew the camera was going to have to be able to perform certain basic movements:

To achieve all of this, I built a hierarchy of objects. For those of you unfamiliar with this concept, in such a hierarchal structure, moving a parent object will move all of its children accordingly, while moving a child will have no effect of its parent. This way, it was possible for me to build a rig which allowed some actions to be applied to all objects in the hierarchy and others to be isolated to only certain parts.

The Camera Rig

Here is a breakdown of the camera rig:

The rig consists of a Root object which is the parent of the Pitch object which is, in turn the parent of the actual Camera object. By splitting up the rig this way, it’s much easier to apply the aforementioned camera movements in isolation as each part of the rig handles particular movements.

The Root Object

The Root object is what actually follows Suzy around as she is moved by the player. Since it is the parent object, all others, including the camera, move around accordingly. 

Since Suzy is quite responsive and her movements can be quite quick, the camera’s position constantly interpolates toward her current position to smooth out the camera’s movements. 

The task of orbiting also falls on the Root object. By rotating it parallel to the ground, the camera can be made to orbit around Suzy. As a rule, the Root object is only ever rotated along this one axis, its Y or Up axis. This way it is always kept parallel to the ground plane and all changes to the camera’s orbit only ever affect the Root object’s Y axis of rotation.

By using the Root object, centred on Suzy as the pivot for our rotation, it allows the camera to maintain a constant distance and trace a nice arc around the focal point as it orbits.

Compare this to a situation in which the camera’s position and rotation are simply interpolated from point to point. Notice how the the camera rotating around the Root object traces a nice circular arc while the linearly interpolated camera traces a straight line, causing it, in fact, to get much closer to Suzy midway through its motion. So, the Root object allows the camera, by extension, to orbit smoothly around the player character while following along as she runs around the level.

The Pitch Object

As the name implies, the Pitch object has one job and one job only, to control the camera’s pitch, which is to mean rotating it to look up or down. The Pitch object is centred directly on the Root object and so is also, always at the camera’s focal point, which is, usually Suzy herself. By rotating the Pitch object along its local X axis, upward and downward, in turn causes the camera to swing up and down as the Pitch object is its direct parent.

This does not necessarily need to be handled by a whole different object, but doing so ensures that the camera never finds itself at a strange angle whenever a camera move affects both the pitch and the orbit of the camera. Another advantage of the Pitch object being a child of the Root object is that only the Pitch object’s X rotation axis ever changes. As camera’s orbit is entirely handled on the Root object, rotating the Pitch object along its local X axis will always only cause the camera to pitch up or down and never inadvertently tilt or roll because of a strange combination of angular inputs even when interpolating between rotations.

The Camera

And finally, we have the Camera itself, which represents the view from which the scene is rendered. Since it simply moves along with its parent, the Pitch object, which subsequently moves around with its parent, the Root object, the camera can simply be moved forward and backward along its local Z or Forward axis to move it closer to or farther from Suzy.

Though, the Camera is normally centred on the Root object, it is also possible to offset its position along its local X and Y axes. This allows the camera to show more of what’s coming ahead of the player for example, or can otherwise be used to adjust Suzy’s position on screen. Since these movements are also made in the camera’s local space, they will stay consistent as far as how they affect the player character’s position on screen regardless of the rig’s current pitch or orbit settings.

Controlling It All

So, how are these various camera movements all controlled during gameplay if not by the player? The answer comes in the form of Camera Manipulation Trigger Volumes. These are generally set up as trigger boxes that, when entered by Suzy, will trigger a change to any number of camera settings including the ones discussed above.

This panel shows all of the camera settings which can be changed when entering the trigger including the ability to define a different target for the camera instead of Suzy if this better serves the gameplay in a particular part of a level. By mindfully placing these Camera Manipulation Triggers along a level, I’m able to ensure the camera always shows players exactly what I want them to see.

The Basics Covered

So, these were the first bits of functionality I set up way before even having a real character running around and form the foundation for the camera work in the game. Even with no more that these controls. If I had stopped here, things would have been in pretty good shape, but not necessarily all that great, so please, check back again next week to catch the next part in the series as I start explaining some of the subtler things implemented into the camera system to help it on the road from a good camera system to a great one.