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

This article will have a much higher quotation to original text ratio than any other article in this series. I will be taken a set of questions from the resource above and answering them as best I can for the current project. This is a camera design exercise that will hopefully yield many of the project particulars that I have not been able to communicate yet. My responses are shown in red text and not indented, however, these effects may not be seen on mobile devices viewing this webpage.

    "Camera design questions

    After designing camera systems and behaviours for some time, the process of evaluating the game design can be                reasonably standardized. One effective method is to produce a list of questions particular to the requirements of the             game design. Consider the following possible questions and customize them so that a full understanding of a                        particular game play situation has been gained before starting its camera design.

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

In the last part, I described the goals for this project as a whole and broke these goals into bullet points. Now, the focus is shifting to goal number 1, and I will elaborate on it by outlining the camera design process that will take place over the course of this goal. At the end of this part, you should have a better understanding of what I mean when I say that the main objective of this goal is to prototype a camera base behaviour. All quotes and headings below are from the reference above.

"When playing any new game, intentionally take some time to manipulate the player character in ways that tax (or break) the camera system. Observe how the system handles difficult cases as well as simply noting how it behaves with respect to regular character motion and orientation changes. Determine how your camera system would deal with similar cases."

Haigh-Hutchinson advocates starting with gameplay requirements for any camera design. In this case, those requirements are defined by a single player in an Unreal Editor 4 level without a vehicle or any weapons. Adding more interesting elements beyond jump would create interesting camera design challenges but are beyond the scope of this project.

 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

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

After completing the two tutorials from Part 2 and playing some third person games, I feel ready to start experimenting with blueprints. Blueprints seem the better modality for free-form experimentation compared to code because they provide visual feedback in both the event graph and the scene itself which will increase my ability to read the results of each iteration.  At the end of this part, I will outline the project goals, however, these goals will be further developed in my next article.

Here is an excerpt from Mark Haigh-Hutchinson's book that describes some important decisions that will be made for this camera system today; i.e. when the camera is facing in a direction that is straight forward or to the right of the character,
where does up on the keyboard or analog control stick make the character move? (italics from source text):
      "A control reference frame refers to a relationship between changes to the controller input and how it affects movement     or other aspects of player control. In a typical first person game, the control reference frame typically corresponds directly     to the direction in which the player character is facing (we will refer to this as character-relative), and is usually restricted     to a 2D orientation rotated around the world up-axis. In third person games, the control reference frame is often based         on the relative position of the camera and the player character (known as camera-relative...), or sometimes the view             transform of the camera (screen-relative). On rare occasions, the character-relative scheme can be used in third person     games, although this can cause problems when the character is facing the camera. A lesser used control reference             frame is world-relative, where the controls are based purely on the world coordinate scheme irrespective of player                 character or camera position...
     The most important part of the control reference frame is that it should always reflect the intended action of the the player.     Preserving the intended movement of the character under control reduces the disorientation than many players feel."

One weird result of implementing the tutorial videos' camera system is that holding the "D" key to move right causes the character to run circles around the camera as the camera tracks him. The radius is a point behind his back, and can be tweaked with two values to determine the responsiveness of the camera. Only forward and backwards have persistent orientations and these directions are persistent relative to the camera and not relative to the world. This is example of a behaviour in camera-relative schemes that I want to avoid for this project - the character should run in straight lines in all directions. The visual target for this project. Journey, uses camera hints extensively to reposition the camera at drastically different perspectives of the character while the player holds a persistent direction on the controller. While this might appear to demonstrate a character-relative scheme similar to the controls in a first person shooter, it is actually closer to a camera-relative scheme. The behaviours that I intend to mimic include the persistence of directions in the control scheme with different perspectives.

Camera-relative schemes take into account both the positions and orientations of the camera and player. A simple camera relative scheme draws a line (or vector) from the camera to the player and considers it the forward vector for character movement. While this does not apply to Journey, the controls do not change when your character turns to faces the side of the screen. This would not work well for an analog control stick because if the player intends to go to the right they must tap right to orient their character in that direction and then immediate hit forward on the control stick with no other directional input to steer them off course. This may work with discrete directional controls like the separate keys on a keyboard, but fails to allow players to complete their intentions with continuous directional analog input. Now, let's start experimenting!