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:
- Translating - Moving the camera either up, down or side to side.
- Orbiting - Rotating the camera around the player, parallel to the ground.
- Pitching - Rotating the camera to look up and down.
- And Trucking - Moving the camera closer or farther away from the player.
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 camera rig hierarchy|
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.
|Top down view of the Root object following Suzy as she moves. The rest of the camera rig follows along.|
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.
|Rotation of the Root object causing the camera to orbit around Suzy.|
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.
|Comparison between rotating the Root object versus moving and rotating the camera directly.|
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.
|Side view of camera pitch change by rotating the Pitch object.|
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.
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.
|Trucking the camera in and out.|
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.
|Example of the settings panel of a Camera Manipulation Trigger.|
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.