Real-Time Cameras in Unreal Engine 4 - Part 4

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

The first three parts of this series focused on research and experimentation. My current strategy is to do as much as I can with Blueprints and then switch to code if I deem it is necessary for any features. The other result of this pre-planning phase is the realization that screen-relative control reference frames are easy in Unreal Editor 4, but it will take some effort to create a system that uses a camera-relative scheme. This is the first step, and might warrant creating a YouTube tutorial. However, the goal for this part is to define the goals for the entire project. All quotes below are from the reference above.

VISUAL TARGET

GOALS

1. A faraway camera that trails the character with similar behaviours to the camera in Journey (ground-based camera only)

See the visual target or play Journey to see what the result show look and feel like.

When I say ground-based, I mean that I will not focus on cameras for flying, gliding, swimming, or (in some cases) sliding as seen in Journey, because these mechanics are not present in the default game offered in Unreal Editor 4 examples.

    "Interactive 3D camera systems typically have the largest feature set of all. They encompass all of the requirements of         cinematic cameras with the added problems posed by an infinitely variable set of player actions. Providing a flexible             camera system will allow the designer a better choice of solutions to present their game play to the player. Typical                 features of such a camera system would include:

• Rendering projection type (e.g. perspective, orthographic, etc.).
• Determination of the camera's desired position (otherwise known as navigation).
• Camera motion characteristics; how the camera moves from its current position to the desired position.
• Determination of the camera's desired orientation.
• Reorientation characteristics of the camera; how the camera changes it orientation from the current orientation to the desired orientation.
• Dynamic changes to the rendering properties of cameras; examples include the field of view or aspect ratio.
• Ways of interpolating the position or orientation of active cameras.
• Fail-safe handling when the camera is unable to move to a valid position, or is unable to view the player character."

I removed viewports from this list, because those do not apply to the current project goals. The first bullet is a feature provided by Unreal Engine 4 as a perspective projection. The remainder of the features are covered by solutions offered by Unreal Engine 4 although some bullets will require custom scripting to complete. I will start moving towards completion of this goal first, so the next article will follow a camera design process outlined from p122-136 in the reference text.


2. Custom collision avoidance to fit with the ideas expressed in "50 Camera Mistakes" as implemented in Journey

There are quite a few features here, many of which can be cut. Most of these are listed among the 50 mistakes, were inspired by watching this talk, or relate to the solution of these mistakes as described by John Nesky. Some are best explained in that video, and I will leave out most of the explanation for these items.

• Simple undressed custom testing level that has blocking similar to levels in Journey
• Whiskers protruding from the back of the character to detect blocking collision
• Camera collision to move the camera away from objects with controlled behaviour (may use USpringArm here)
• Tag system for obstacles to determine whether they are allowed to break line of sight or the camera must avoid them
• Tag system for slopes that avoid collisions with whiskers, so they are not considered wall that must be avoided
• Tag system for opaque areas that the player can pass through, to allow cutting to another camera angle
• One common mistake is letting cuts remap directional controls - give the player a moment to adapt (keep in mind)
  
• Systems to avoid breaking the player's sense of direction: dead reckoning, recognizing landmarks (keep in mind)

One test level will be created to test all of these elements and I will be adding these features once the camera system is  still far from completion so that I can ensure it will accomodate collision avoidance.




3. A hint system that allows camera movement to create cinematic shots while maintaining persistent input directions

Hint systems are described in the text, and will be described in more detail when I begin making one for this project. These points are a continuation of the previous list and all credit must go to John Nesky, Feel Engineer on Journey, for this list.

• Hint system allows dynamic FOV for worm's eye shots
• Hint system avoids moving camera while player is trying to look at something
• Hint system releases control to the player gradually, so the camera is pushed hard initially but this peters off quickly
• Letting the camera pivot drift too far is a mistake
  
• Do not use rapid panning or transitioning to avoid using cuts when cuts could be used effectively
• Do not use a general constraint solver (e.g. AI) to avoid scripting hints

Additional considerations from John Nesky that do not fit elsewhere:

• Inverted controls should be an option, and were the only option available in Journey (a mistake made in this game)
  
• Responding to accidental controller input
• Use an S curve instead of linear sensitivity because analog sticks do not have much range
• Intermediate positions should be significantly less sensitive allowing players to make small adjustments
• Using a small FOV to start or changing FOV too aggressively leads to motion sickness in many players
• Translating or rotating up and down when the character jumps is a mistake, keep the camera steady
• Rubber band vertical jumping movements' effects on the camera or only move camera when the character lands

All of the features in this section are of low importance for this project, and my goals may be later reduced to creating a framework that could be used for making custom hints at a later time. I do not have a final goal for a finished level in mind, and this system will be a frivolous exercise without objectives and important landmarks to guide the player towards.


4. To use the textbook cited above to expand on these goals and explain the principles behind my camera design intentions

This goal is being completed through posting this series of articles - I hope you enjoy learning about camera design!