Real-Time Cameras in Unreal Editor 4 - Part 8

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

Let's continue with Mark Haigh-Hutchinson's description of look-at offset from page 250 of the reference:

• "Look-at offset. This is an alternative method of defining the look-at position. In this case, the position is a displacement from the player character, but calculated in character space, that is, relative to the direction in which the character is facing (optionally the movement direction of the character."

And now an in-depth discussion of look-at offset from pages 256-257:

• In third person games, the focal point of the main camera is usually positioned close to the player character, but this may certainly change according to current game play requirements. We refer to the physical displacement of the desired look-at position from the player's position as the look-at offset. This is a convenient representation of the focal point as the player is most often interested in their character's interaction with the environment and would normally desire viewing the world surrounding their character during regular game play.
• Many third person cameras use a constant look-at offset, so that the look-at position is located at a fixed position relative to the player character. Often this is the origin of the player character, or vertically above this position. While this gives a consistent view of the character, in many cases it is a detriment to game play. In most third person games, it is actually more important to see ahead of the character's movement to judge the relationship between the character and other game elements. In terms of long-range weapons and aiming, it is even more important to look where the player's weapons will hit rather than the character.
• The difficulty with using a constant look-at position, especially one that is positioned ahead of the player character's motion, is that this position will oscillate about the vertical axis of the character every time the character changes direction.
• Even with orientation lag, this could cause an unpleasant amount of orientation change for each slight reorientation of the the character. This effect may be minimized by using a spring or other damping mechanism to move the look-at position from its current position to the newly derived position over time. It can also be helpful to apply a high-pass filter to remove noise generated by small character motions. Combined with regular orientation lag, this is usually sufficient to resolve oscillation of the look-at position.
• While the camera is continuing to track its desired look-at position, its right vector should remain parallel to the horizontal coordinate plane to avoid roll.
• The look-at position should not necessarily be tied directly to the player character. In most cases, we should scale the offset according to the velocity of the player character to allow players to see further ahead of their character. The amount of offset to use (which is calculated in character space) can also be varied according to game play situation. However, simply scaling the offset according to the player speed will result in rapid camera reorientation whenever the player's motion is interrupted, and would be quite disconcerting to the player. Moreover, when the player character is able to change directions quickly, the camera would track these changes exactly, leading to quick full scene movement or jitter at a disorienting rate of change.
• To solve this problem, we can calculate a desired look-at position according to the player speed (plus other requirements). The current look-at position is moved toward the desired position over time by using a proportional controller, or PID controller, or spring to damp the motion. Additionally, applying digital filters to the look-at position motion (or for that matter, the desired position of the camera itself) will reduce sensitivity to slight or unintentional motion of the target object. These methods are covered in detail later..."
  

Now, making a camera track the character fluently seems as difficult as programming a automatic drone to safely follow people around.

The complexity of this one issue will probably keep me busy for many months. For now, I quickly explain why the camera behaviour I am seeking is still a camera-relative scheme despite being closer to the Blueprint Third Person by Epic Games and the Dark Souls Camera Tutorials (hyperlinked in Part 2) by Daerst than I originally understood. Finally, I disseminate notes from my Journey playthrough and how they promote a different camera-relative scheme from my original intention.

As a quick recap, camera-relative schemes take into account player orientation and position as well as camera orientation and position. The edge case I failed to conceptualize was was moving towards the camera, and the resulting motion that is applied to the character. Screen-relative seems to imply that moving the character directly forward and into the camera does not change the orientation of the screen. Camera-relative, on the other hand, allows the camera to move out of the way based on character movement rather than specific movement of the camera controls. While the camera is reorienting around the character, the character's movement controls change in a screen relative manner.

Many third person games, Including Journey, are categorized as camera-relative schemes because if you walk towards the camera it reorients itself  and you must change the angle of your directional stick (although a scheme does not need to do this to be consider camera-relative). Screen-relative games should not change based on movement and should be completely detached, because any movement effects on the camera create an inconsistent forward vector with respect to the screen. Screen-relative should mean that the player can consistently interprete the screens forward vector as the forward movement vector as seen in the first-person shooter genre. World relative is a special case where changing the camera angle does not alter the movement controls in any way because they have a mutually exclusive effects.

Originally, I thought the key to creating the Journey camera was to start with a world-relative scheme and adjust its behaviour with hints and other superficial modifications. In fact, Journey has a scheme that is very similar to the Dark Souls camera created by the Daerst in Unreal Engine 4. Moving any direction except directly forward pulls the camera behind the character. I only realized my mistake by playing the game.
Also, controller tilt for camera control is present in Journey but will not be implemented here because I am not interested in it.
Journey allows the player to go offscreen briefly. Given the reduced scope of this project, I see no reason to ever allow this to happen.
The basic look-up and look-down behaviours are more complicated than I took account for although I had planned to implement these same behaviours for the hint system. One previously unnoticed behaviour happens when the player is facing NE-SE or NW-SW and it repositions the camera by sliding horizontally so that the character is one the line between the opposite third of the screen and the middle third. Moving N, E, or W while holding the camera controls to the right or left draws a circle 3-5 character widths in diameter. Moving E or W while leaving the camera controls untouched draws a circle 10-15 character widths in diameter. This gives a rough ratio of controlled camera rotation speed around the character to automatic camera around the character when movement is not due N.

The scope of the project is being reduced by removing the hint system. Collision will still be implemented and will focus on "whiskers" as described by John Nesky. The level blocking will include a circular staircase around a wide cylinder, as seen repeatedly in Journey, specifically for testing the implementation of the whiskers to mimic the original game's behaviour.

---