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."
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."
Pietro, on my team for STARSTRUCK, implemented a world-relative control reference frame for Dr. Box to make forward movement and striking predictable with twin-stick analog controls. In this case, the result is similar to camera-relative except when panning to the side.
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!
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!
My first experiment is to remove the camera boom from the Blueprint Third Person project and parent the camera to the character controller instead of the camera boom. Noticed that I also raised the camera to provide a different perspective and avoid collision with most world objects.
Experiment 1: Results in a screen-relative scheme
This creates a screen-relative scheme that is very disorienting, especially if you move the mouse using keyboard controls. If you do not move the mouse it resembles a world-relative scheme. The camera is considered forward, relative to the world not the character, when the game starts and the character moves in straight line to the right of the world when you hold the "D" key. The camera changes orientation with the character (as expected) and stays behind the character in the same orientation even after releasing the "D" key (as expected). What makes it confusing is that going backwards relative to the character or camera is now "A" because going backwards relative to the world by pressing "S" will move the character to his left. Adjusting the mouse to fix this orientation problem only complicates matters by changing the forward vector relative to the world. Similarly, using a gamepad is less disorienting when you only uses the left control stick to move and the controls behave like you would expect from a world-relative scheme. However, if you touch the right cotnrol stick, the precise orientation relative to the world is lost and it gets hard to go back to your previous understanding of world directions. You can hold forward on the right stick and make discrete direction changes with the left analog stick too as these input are on separate axes.
For the second experiment, I kept the same component relationships and changed one boolean that influences camera orientation. The name of the variable is "Use Controller View Rotation" and it is highlighted in the picture below.
For the second experiment, I kept the same component relationships and changed one boolean that influences camera orientation. The name of the variable is "Use Controller View Rotation" and it is highlighted in the picture below.
Experiment 2: Results in screen-relative scheme
In this experiment, the major result is that it is hard to keep the character onscreen. Going to the right causes the camera to swing the behind the character (as expected) but also to adjust orientation to the right so that it is looking forward. Aside from not being able to see the character, it is actually more intuitive because the camera stays oriented to the direction that "A" will move the character, and this direction is persistent to the forward transform of the camera relative to the world. Moving the mouse without keyboard input allows the player to free look from a point behind their character. You can never see the character while moving unless you are moving forward or a direction close to the forward vector. For this project, the character should be able to move sideways or backwards without looking in the exact direction the character is facing so "Use Controller View Rotation" needs to be set to false. Currently, the effect is compounded because the camera is parented to the controller and this relationship achieves a similar effect on its own. This boolean may be more useful for a first person shooter camera, where the mesh is actually a child of the camera.
I will wrap up this article with one more experiment that led in a promising direction. I started from a fresh Blueprint Third Person project and copied the Camera Boom component, adjusted the x-value for its Camera >> Target Offset to 500 UU, and then made the existing Camera Boom setup a child of this Forward Displacement component. I also disabled "Use Controller View Rotation" on Camera Boom but not Forward Displacement as shown below.
I will wrap up this article with one more experiment that led in a promising direction. I started from a fresh Blueprint Third Person project and copied the Camera Boom component, adjusted the x-value for its Camera >> Target Offset to 500 UU, and then made the existing Camera Boom setup a child of this Forward Displacement component. I also disabled "Use Controller View Rotation" on Camera Boom but not Forward Displacement as shown below.
Experiment 3: Results in screen-relative scheme
The most noticeable feature here is that the camera is much further away. It does not exhibit the expected behaviours of USpringArms anymore, and the target offset displacement is in relation to the world and not the character as I had hoped. It will be an achievement to figure out how to offset the camera in front of the player properly and I may want to start from another direction. It seems like it will also be a challenge to break from the screen-relative scheme and learn how to create a robust camera-relative scheme as I intend to do throughout the course of this project. Now that the preliminary research and experimentation is done, let's get back on track by describing my goals in more detail. I will outline the features I want to create and my other goals here, and then expand on them in my next article.
GOALS
1. A faraway camera that trails the character with similar behaviours to the camera in Journey (ground-based camera only)
2. Custom collision avoidance to fit with the ideas expressed in "50 Camera Mistakes" as implemented in Journey
3. A hint system that allows camera movement to create cinematic shots while maintaining persistent input directions
4. To use the textbook cited above to expand on these goals and explain the principles behind my camera design intentions
GOALS
1. A faraway camera that trails the character with similar behaviours to the camera in Journey (ground-based camera only)
2. Custom collision avoidance to fit with the ideas expressed in "50 Camera Mistakes" as implemented in Journey
3. A hint system that allows camera movement to create cinematic shots while maintaining persistent input directions
4. To use the textbook cited above to expand on these goals and explain the principles behind my camera design intentions
The results of Experiment 3 provided some ability to make interesting shots, allowing this article to show a very small step forward!
RSS Feed