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

I was recently introduced to a powerful tool in UE4 called the Timeline. All of my previous articles were created without any knowledge of this tool, but now I cannot ignore the fact it provides simpler and more robust solutions than my previous attempts. This weekend was devoted to creating a platformer style camera that is modelled after Tomb Raider 2013 as a warm up for using timelines. There will be no ledge grabbing, vaulting, climbing, or ice-picks in my prototype - so only jumping and landing from a drop will be covered here. My starting point is the default Third Person Blueprint in UE4.10.3 with no modifications except to create a basic test level that has a lot more jumping and height differences. (Aside: In full scale game production, this level would have all the different sizes and shapes - often called metrics - that the avatar could traverse. so locomotion systems, animations, camera, and controls could be tested before the game world is created).

• "Minimize unintentional camera motion whenever possible. This is especially true of cinematic sequences, but it is true to say that camera motion should be avoided unless it would either result in the camera being left behind by the player character, or the camera interpenetrating the player character. Slight or unintentional camera motion caused by reactions of the player character to environmental factors (or noise from player controller inputs) should be avoided. Similarly, if camera motion is directly linked to that of the player, it often results in an "unnatural" or "stiff" feeling camera.

• Ensure camera motion is smooth. Smooth, frame-coherent motion of the camera is necessary to avoid disorienting or distracting the player. Of course, smooth motion is normally achieved by velocity dampening, which has the adverse effect of allowing the target object to either accelerate away from the camera or worse, overtake and interpenetrate the camera. Nonetheless, smooth camera motion is of great importance and there are techniques available to assist the camera in cases where the player character is subject to rapid acceleration. Low-pass filter can help smooth out irregularities in movement especially when the camera motion is tied directly to that of the player character, where noise from unwanted player input may cause slight motion."

Notice the cameraman uses a smooth path up, and highlights the gracefulness of the landing by not overtaking his target, the figure skater.
The opposite effect is achieved in Tomb Raider when Lara Croft lands a jump, but the camera still has smooth motion throughout the landing.

My initial approach is to add a Scene Component to the ThirdPersonCharacter Blueprint and have a new blueprint that tracks the location of this Scene Component. The new blueprint will be the ThirdPersonCameraTarget, and it will use a timeline to track the movement of the ThirdPersonCharacter with velocity dampening.

The first rule of timelines is they can be used on Actor Blueprint Graphs, but NOT Actor Component Blueprint Graphs or Scene Component Blueprint Graphs. This can provide a conceptual barrier for someone who has not used them before, especially when it seems like adding a timeline to a Scene Component Blueprint Graph is the ideal solution. After realizing this limitation, I arrived at two possible options, and chose the latter after running into issues with the former:

1. Run the timeline on the ThirdPersonCharacter to provide an intended location to the ThirdPersonCameraTarget, which parents a CameraBoom with a FollowCamera child.
2. Run the timeline on the ThirdPersonCameraTarget by making it a pawn, completely separating the controller for the camera from the controller for the avatars movement.
   

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

While this is not a continuation of the project I stopped thinking and blogging about in September of last year, it is the result of me continuing to build skills in implementing real-time cameras. The new project involves prototyping a camera for a third person shooter for PC where clicking the right mouse button goes into an over the shoulder view while aiming. A rapid method of implementation for over the shoulder aiming views is described in detail, along with some relevant details on firing projectiles from the camera instead of the player.

• "Retain the camera position with respect to the player when instantly moving the camera to a new position (third person cameras). In other words, try to retain the same control (and visual reference frame when repositioning the camera. Many games fail to take this into account, which usually results in player frustration as the character moves in unintended directions when the camera is repositioned. This can often result in the demise of the player character, or possibly cause the player character to cross an area boundary forcing data loading or other delays. Retention of player intent is of paramount importance. As with rapid orientation changes, repositioning of the camera in this way should occur infrequently and in reaction to established game play or player motion requirements."

I am not following the textbook advice to its fullest extent in this project.

In this case I wanted to replicate the third person aiming camera in games, including Tomb Raider, where the camera assists by zooming in when aiming to avoid the accuracy problems inherent to third person shooters. I have chosen initially to snap immediately to the new perspective, which is based on the character controller's facing direction, and not the camera's current perspective. This rapid repositioning of the camera could be jarring or disorienting if the player clicks the right mouse button while facing the camera. I find this intuitive as it follows the convention of fighting games where the player's character can melee attack towards the camera and want to provide this flexibility. I will, however, be watching for signs while others playtest the game to ensure that player intention is maintained.

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

There comes a time in each project when the team must re-evaluate their goals to make sure they make sense. Neglecting to do this at an appropriate time can lead to what is colloquially called "tunnel vision." Thankfully, I reassessed before going too far in the wrong direction by following a tunnel that was leading me away from my ultimate goal. Some of you may have noticed that my previous descriptions of Journey's camera behaviours were slightly off target. After playing Journey again and watching a tutorial on UE4 programming, I realized that I am better off starting over again using code instead of blueprints because there is more room for customization. The first step in terms of customization is the same one I outlined in my next post: "to offset the camera's focus from the character to a position directly in front of him." My plan is to start by implementing offset, then move forward towards the vision outlined previously with the additions described below.

• "Do not focus directly on the player character when it is moving. This pertains to third person cameras that are often made to look directly at the player character, i.e., the position of the player character does not vary in screen space. While this might seem initially to be correct, and it does present the player character well, it is actually undesirable in many cases. Typically, we need to be looking ahead of the character within the environment and to anticipate future actions. However, the rules governing the amount of look ahead are complex..."

Side note: Everyone - even less technical UE4 developers - should watch or follow along with this tutorial series because it describes powerful techniques for blueprints and code, as well as the relationship between a coder and a technical artist as they work together on the same project.

Introduction to UE4 Programming (19 videos)
https://www.youtube.com/playlist?list=PLZlv_N0_O1gb5xvsc7VM7pfoRAKLuIcFi

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

I have made a small step forward by implementing a world-relative control reference frame in Unreal Editor 4. The player can rotate the camera around the character without changing the forward direction on the control pad. Unfortunately, I have had to disconnect the automatic turning of the character mesh with the controller, and then hook it up again sloppily for now. I won't be sharing the Blueprint section that controls the current facing direction of the character mesh, and will also hold back from releasing any tutorials until I have got this section at a more polished stage. Until then, I will push on with the goals I described in Part 4 and share my progress with you - but first a camera design guideline from the resource above:

• "Attempt to keep the player character in view (third person cameras). Total occlusion by geometry or other game objects (or alternatively, view frustum culling) of the main player character will disorient and confuse the player, yet surprisingly few games pay attention to this essential point. Note that this does not necessarily mean focus on the player character directly, nor does it mean that partial or temporary occlusion is not permissible."