One 1998 Nintendo title made a permanent mark on cameras long before the third person action genre really took off - and it is not The Legend of Zelda: Ocarina of Time. While games like GTA III (2001) and Demon's Souls (2009) both have similar targeting systems to Ocarina of Time, these features were also present in GTA III's precursor Body Harvest (1998) so neither camera can claim as much influence.

I am talking, of course, about Super Mario 64, whose success allowed other influential third person games like Resident Evil 4 (2005) and Gears of War (2006) to create their own revolutions.

Remember that the N64 controller only had one control stick! The follow camera was a vast improvement from its contemporaries, which were often limited to static cameras as seen in Resident Evil (1996) and rail cameras like in Star Fox (1993).

The revolutionary feature in this game is a camera that slowly rotates behind the player to adjust to their movements - notably causing avatars to run in circles when running towards the camera. If you have ever seen this in a game, chances are that camera is a "follow camera" that was inspired by Super Mario 64.

There are two camera modes in Super Mario 64: Mario Mode and Lakitu Mode. My project, Super Maria 64, will focus on implementation of Mario Mode. See reference of a player completing the game in Mario Mode here. Lakitu Mode is preferred by many players and aged better with time, but it is basically another layer of features on top of the features in Mario Mode... so we will avoid that complexity.

This post documents the first step towards the goal of the Super Maria 64 project, and provides readers with a quick mock-up of the camera lag seen in our reference. I will show video of the final result taken with Sequencer, as well as the blueprints.

Reference: Mark Haigh-Hutchinson. 2009. "Real-Time Cameras: A Guide for Game Designers and Developers." Elsevier.

This post is the conclusion to a series intended to share knowledge I found in the resource John Nesky called the "only textbook" in the field of cameras for game design. The final nuggets of wisdom discuss fundamental aspects of any camera. Conveniently, I am beginning to build a new third person camera based on learnings from the Camera Experiments series, and these fundamentals are an excellent place to start - especially as I have neglected sharing them. or even thinking about them. for so long!

For the purpose of keeping this discussion quick and to the point, I have chosen to focus on mouse control schemes only. This is a quick primer on how to start your own camera. Here are the final camera design guidelines from Haigh-Hutchinson's textbook, see the previous articles in this series for more of this wisdom.

• "Limit the reorientation speed of the camera. Unless it is under direct player control, rapid or discontinuous reorientation of the camera is disorienting and confusing. Reorientation of the camera causes the entire rendered view of the world to be redrawn; since the direction in which the camera is facing (through the lens as it is often called) determines the part of the world to be drawn. By limiting the velocity of this reorientation, this effect can be minimized. In third person cameras, this may be at a cost of losing sight of the target object for a short period. Instantaneous reorientation is permissible when the cut is made in an obvious fashion such as in combination with a repositioning of the camera, but only when the new orientation is retained for a sufficient period to allow the player to understand the new situation. Retention of the player control reference frame... can assist in this regard. Still, instant reorientation should occur infrequently, and preferably not in quick succession. Reorientation to a new desired heading should usually prefer the shortest angular direction...
• Retain control reference frames after rapid or instantaneous camera motion. With third person camera systems using a camera-relative control reference frame, instant or rapid camera motion will potentially disorient the player. This often results in unintended player character motion, possibly resulting in the demise of the player character. At best, this is merely frustrating; at worst it can induce a desire on the player to throw the controller across the room in annoyance. If the control change occurs at the threshold of a game area, it may in fact cause the player character to cross back into the previous area, possible forcing a load delay and yet another control reference change."