Video: Remi Lacoste. GDC 2013."...Emotionally Engaged Camera... " https://archive.org/details/GDC2013Lacoste
Reference: Mark Haigh-Hutchinson. 2009. "Real-Time Cameras: A Guide for Game Designers and Developers." Elsevier.

As we come closer to completing this series of articles, I have a varied assortment of guidelines from Haigh-Hutchinson that I have not shared yet. Many of these guidelines are echoed in Remi Lacoste's GDC Talk on the camera for Tomb Raider 2013, which is recommended viewing for anyone interesting in camera or conveying emotion in video games. His powerpoint for that talk highlights a key difference between the camera I made in Part 10 and the camera it was meant to emulate: "Instead of using an animated layer playing on top of our cameras, we used a physics based camera shake system allowing us to embrace a more custom approach." My Timeline-based implementation served as a good way to experiment with timelines, but in this post I recreate those camera behaviours using physics instead. I found Timelines useful in demonstration of my intention in Hugline Miami too, but ultimately physics provides better implementation when collision is involved. Today's grab-bag of wisdom happens to include three guidelines about camera collision.

• "Prevent the camera passing through (or close to) game objects or physical environmental features. If the near plane of the camera view frustum intersects render geometry, unwanted visual artifacts will be produced. These will certainly detract from the graphical quality of the game, and a best seem very unprofessional. This problem is typically easily avoidable; it should be considered as simply unacceptable in modern camera systems. A passable solution to avoid this problem is to apply transparency effects to the geometry in question. By effectively removing the geometry (and indeed actually doing so according to camera proximity), the camera may be allowed to pass through without creating distracting visual artifacts...
• Do not allow the camera to pass outside the game world. In the vast majority of cases, the camera is required to remain within the visible geometry of the world to prevent the player from seeing the construction of the game environment and thus destroying the illusion of the game play. There are limited cases where it is necessary to position the camera outside of the main game environment but only when care has been taken to hide construction details from the player...
• Avoid enclosed space with complex geometry (third person cameras). There needs to be sufficient space for the camera to be positioned such that the player character may be viewed in relation to the game play elements with the environment. Small enclosed spaces will require the camera to be moves outside the environment to achieve this. If kept in close proximity to the player character it will likely result in poor framing and frequent loss of line of sight. Environmental construction should take camera framing requirements into consideration from the initial design stages."

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

So far, my focus has been on third-person cameras. I will share some first person camera wisdom from the reference textbook in this post, and also give third person camera examples to contrast between tho two camera schemes. These examples will demonstrate the following three points as they pertain to both first person and third person:

1. "Do not require the player to manipulate the camera simply to play the game - unless it is a design requirement. For third person presentations, the camera system should be able to choose the most appropriate solution automatically, even in the most complex of situations. It is permissible to allow the player to control the camera when it is absolutely necessary or desirable to do so, but it should certainly not be required. Many games adopt a laissez-faire attitude to camera manipulation, which is unfortunate given its importance. If camera manipulation is allowed (or specified as part of the game design) then care must be taken to ensure the player cannot position the camera outside of the world geometry or into a position occluding the player character. The range of motion and method of manipulation must be carefully matched to the game design and technical requirements. An obvious exception to this rule would be first person games, where camera manipulation is an important part of regular game play. Even in this case, there are times where the camera orientation may be automatically adjusted to aid the player without overriding player control. Usually this is a subtle assistance to the player in clearly defined situations. Motion up or down steep inclines may induce some vertical pitching of the camera to assist in aiming or navigation of the world.
2. Allow camera manipulation when possible or dictated by game design requirements. Certain game play situations will disallow camera manipulation, but certainly denying the player this control can often seem restrictive. Naturally, we should strive to present a view that does not require this manipulation, but there are certainly cases where the design would demand the player to examine their environment in detail. It is also true that it can be difficult to judge player intent and camera manipulation allows a greater sense of control and determinism for the player. There can be nothing more frustrating to a player than being prevented from seeing the world in a manner relevant to their current situation or intended action. The problem, however, is that the camera designer should not abdicate this responsibility as a solution. Additionally, restrictions to camera manipulation after such control has been allowed may be confusing and frustrating to the player unless adequately explained...
3. Limited roll should be allowed in most regular game cameras. Little or no rotation should normally occur around the forward axis of the camera. Again, this is distracting and disorienting during regular game play, but within cinematic sequences, it is certainly permissible. Occasionally roll is used as part of an interpolation sequence to change the player's view of the game world, perhaps as part of a special mode of game play (e.g., climbing a wall and crawling along it). Some games have used this effect to intentionally disorient the player, but it should be used sparingly. Flight simulators and their ilk are an exception to this rule, as they usually present a view of the game world from the point of view of the vehicle. Even so, many people react poorly to extreme roll, so in external vehicle views it may prove wiser to only allow a limited amount of roll to emphasize a vehicle banking, etc. There are cases where roll can be used to a limited degree to emphasize differences in game play or to underscore an emotional state of the player character. Clearly, roll is perfectly allowed during cinematic sequences."

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.