Real-Time Cameras in Unreal Editor 4 - Part 9

FollowCamera and DebugSphere for MyCharacter

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."

When the player is not pressing the right mouse button, camera and player movement are similar to the default third person camera

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.

When the player presses the right mouse button, the camera moves upwards and FOV decreases to create an over the shoulder view

Components of MyCharacter

Some of you may have noticed that the FollowCamera is not directly behind the player, but is instead offset to the character's right hand side. This allows the reticule to stay in the centre of the screen at all times, and prevents the need for a raycast to determine where the player is aiming. It is a quick and dirty implementation that I may have to improve later.

Also, note that the ReticleArm is a child of the camera.

This ReticleArm is another SpringArmComponent that is offset from its parent in the forward direction, and point forwards (negative arm length with respect to its parent), where a sphere is attached. The DebugSphere can be seen in the first picture of this article on the far right of the picture.

---

Properties for FollowCamera

Properties for Reticle Arm

Since the camera and reticule are offset, the origin of the projectile should be offset too. The simplest way to do this was to spawn the projectiles at the base of the ReticleArm. I used the DebugSphere while positioning the camera to quickly determine whether the current test position of the camera would cause the projectile to hit the player. The ReticleArm allows me to tune the placement of the reticule even more exactly when enabled. I have also considered converting the DebugSphere's transform to screen values and making the reticule follow it instead of locking it to the centre of the screen.

Want to see some blueprints to make this work? I have not included the MyHUD class from the Blueprint First Person example project because it is not my work, and I did not change it much besides adding a branch with a boolean variable ToggleHUD to control it. I have changed when the reticule appears using this handy script on the MyCharacter blueprint.

Every frame the MyCharacter object checks its own HUD reference and sets the ToggleHUD variable to the current value of IsAiming

This reticule looks slightly ridiculous when migrated over to the third person project because it always targets the player character, which does not give the player a good affordance to determine where their shots will go. To improve this, we need blueprints to alter a number of properties when aiming, in addition to the changes in component values above. A decrease in Field of View (FOV) provide a simple zoom-like action that narrows the focus of the player to allow them to concentrate on aiming. Lifting the CameraBoom allows us to see over the characters shoulder. We must remember to undo these changes when the right mouse button is released. Both of these occur while we are aiming, but still more effects are controlled by the IsAiming Boolean variable. I chose to reduce horizontal movement from the camera's perspective by a tuneable factor when this Boolean is set to true, and reduce forward and backward movement by an even greater factor too.

Whenever the right mouse button is pressed, we decrease FOV to a tuneable number, and raise the CameraBoom by a tuneable number

Setting the Field of View to initial values that could be changed by the player (but not in game)

The default field of view is set to 90 for the Blueprint Third Person project. I wanted to ensure that this value could be adjusted by the player before starting the game, so I chose to set a variable instead at Event Begin Play instead of hard-coding this value.

Since the FOV is set equal to, and not incremented and decremented, the value must be set using a reference that contains the default value.

---

In the movie business, this camera would be considered risky because it can break the 180 degree rule. The quote at the beginning is a restatement of this rule for video games. Players can lose their orientation if a sudden change of direction occurs and their points of reference have suddenly jumped from one side of the line between camera and player to the other. Although the rule is broken here, I feel it is acceptable because the player is in control of this change, and it can only occur when they make the decision to allow it. This would place it within the "established game play ... requirements."

The textbook goes on to note other acceptable exceptions that break the 180 degree rule: "It is also permissible to use this when camera motion would be forced through geometry and/or the camera has lost sight of the player for an extended period (say 2 seconds). This case would be known as a fail-safe."

Rules are made to be broken. While using rules from cinematography is helpful for explaining ideas, always remember that the interactive medium of video games has it's own rule set that does not strictly adhere to rules used in other media.

---

EDIT: Tonight I played Assassin's Creed: Brotherhood, which is an example of a successful game that uses a similar camera reorientation when the player goes into aiming mode and their character is facing the camera. It also allows the players to shoot in any direction with a button press. Both of these actions allow the player to attack enemies coming from behind quickly. It seems that this style of camera is better suited to open world games, where the enemies can come from any direction although this can be handled by allowing the player to rotate the camera quickly or turn 180 degrees with a button.