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.
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.
EXAMINE HIGH-LEVEL DESIGN GOALS
"what is required of the camera system."
"Discuss with the game designers their vision for how the game should be presented to the player and which camera presentation style(s) best match their requirements. Look for existing examples of camera solutions that succeed under similar circumstances and determine what properties are desirable for your particular situation."
One aspect of this project that complicates its goal to imitate Journey is that the gameplay is fundamentally different for vanilla Unreal Editor 4 compared to the original game. There are similar mechanics in both, but our game is missing crucial features for the gameplay that Journey offers because I have chosen not to incorporate them. DISCLAIMER: This project is intended as an educational exercise for me, and for you, and does not represent a fully developed camera design.
"what is required of the camera system."
- "Scope of the game and how that impacts camera design on a global scale"
- "What commonality is present in different parts of the game?"
- "Will a single presentation style be sufficient and what should the style be?"
"Discuss with the game designers their vision for how the game should be presented to the player and which camera presentation style(s) best match their requirements. Look for existing examples of camera solutions that succeed under similar circumstances and determine what properties are desirable for your particular situation."
One aspect of this project that complicates its goal to imitate Journey is that the gameplay is fundamentally different for vanilla Unreal Editor 4 compared to the original game. There are similar mechanics in both, but our game is missing crucial features for the gameplay that Journey offers because I have chosen not to incorporate them. DISCLAIMER: This project is intended as an educational exercise for me, and for you, and does not represent a fully developed camera design.
EVALUATE PLAYER CHARACTER ABILITIES
"How the player character moves or interacts with the environment"
"Without a thorough understanding of how the player character behaves is it difficult to present the game play in a meaningful manner. A player character that walks upon two feet at a relatively slow pace has different requirements than, for example, a flying vehicle. Moreover, do the player abilities change over time and thus require varying camera solutions?"
In Journey, this is true because different sections resemble flying, gliding, sliding, or even even swimming through sand. Many of the difficulties and considerations made by John Nesky for that game will not be addressed here.
"How the player character moves or interacts with the environment"
"Without a thorough understanding of how the player character behaves is it difficult to present the game play in a meaningful manner. A player character that walks upon two feet at a relatively slow pace has different requirements than, for example, a flying vehicle. Moreover, do the player abilities change over time and thus require varying camera solutions?"
In Journey, this is true because different sections resemble flying, gliding, sliding, or even even swimming through sand. Many of the difficulties and considerations made by John Nesky for that game will not be addressed here.
DETERMINE SCOPE OF ENVIRONMENTS
"implications of the environmental design upon camera placement and motion"
"Once a game area, (sometimes referred to simply as a "room") is initially constructed, even in a rudimentary form, it should be possible to understand the scope of what will likely be required for the camera. At the very least, major concerns regarding potential geometry complexity and position of the camera should be evident."
"implications of the environmental design upon camera placement and motion"
- How freely can the camera move through the environment?
"Once a game area, (sometimes referred to simply as a "room") is initially constructed, even in a rudimentary form, it should be possible to understand the scope of what will likely be required for the camera. At the very least, major concerns regarding potential geometry complexity and position of the camera should be evident."
DEFINE CAMERA BASE BEHAVIOR(S)
"Once an understanding of the previous three items has been made it should be possible to determine the fundamental desired camera behavior used in the majority of the game. This may be the full extent of the required camera behaviours, except for refinements caused by subsequent game play changes. More likely is that specialized solutions will be required for those situations where finer control over camera positioning or orientation is necessary to highlight a particular game play element."
"The base camera behavior should be prototyped as quickly as possible. Since the game play experience is dependent upon the camera presentation, determination of the camera solution is a high-priority item. Nonetheless, it is true that the simplest camera solution generally proves to be the easiest to design."
Nb. We do not have a fully defined base behaviour for this camera design yet. Before we can reach this milestone, we will have to make substantially progress on the bullet points for this goal and then begin to address some of the points in goal number two - especially creation of the game area.
"Once an understanding of the previous three items has been made it should be possible to determine the fundamental desired camera behavior used in the majority of the game. This may be the full extent of the required camera behaviours, except for refinements caused by subsequent game play changes. More likely is that specialized solutions will be required for those situations where finer control over camera positioning or orientation is necessary to highlight a particular game play element."
"The base camera behavior should be prototyped as quickly as possible. Since the game play experience is dependent upon the camera presentation, determination of the camera solution is a high-priority item. Nonetheless, it is true that the simplest camera solution generally proves to be the easiest to design."
Nb. We do not have a fully defined base behaviour for this camera design yet. Before we can reach this milestone, we will have to make substantially progress on the bullet points for this goal and then begin to address some of the points in goal number two - especially creation of the game area.
DETERMINE AREA SPECIFIC REQUIREMENTS
"where the default camera behavior is unable to present the game play in a satisfactory manner"
Since only one game area is planned, area specific requirements will not apply to this project. Future projects may take the camera behaviour that is developed here and apply them to new levels that are either designed to be playable experiences or designed as stress tests to show off the approach to designing level specific tweaks to an existing camera.
"We would start by analyzing the particulars of how the player moves, where the camera needs to be positioned during that movement, where the enemy AI objects may be placed, and so forth. This should occur before any firm commitment has been made to the physical layout of the environment, art resources, and so forth. Game play requirements such as these will normally have a higher priority than aesthetic requirements, but they are bound by the limitations of available technology."
TECHNICAL EVALUATION OF CAMERAS
"The easiest camera problems to solve are the ones that you do not have, which is another way of saying that you should design problems away whenever possible. Good communication between the three disciplines of programming, design, and art is as important with camera system design and implementation as any other major system."
Main points to consider:
I am going to publish the next part today, as it relates to all of the considerations discussed here and breaks them into questions that will elaborate more fully on the camera design specifics for this project.
"where the default camera behavior is unable to present the game play in a satisfactory manner"
Since only one game area is planned, area specific requirements will not apply to this project. Future projects may take the camera behaviour that is developed here and apply them to new levels that are either designed to be playable experiences or designed as stress tests to show off the approach to designing level specific tweaks to an existing camera.
"We would start by analyzing the particulars of how the player moves, where the camera needs to be positioned during that movement, where the enemy AI objects may be placed, and so forth. This should occur before any firm commitment has been made to the physical layout of the environment, art resources, and so forth. Game play requirements such as these will normally have a higher priority than aesthetic requirements, but they are bound by the limitations of available technology."
TECHNICAL EVALUATION OF CAMERAS
"The easiest camera problems to solve are the ones that you do not have, which is another way of saying that you should design problems away whenever possible. Good communication between the three disciplines of programming, design, and art is as important with camera system design and implementation as any other major system."
Main points to consider:
- Processor usage
- Memory usage
- Scripting capabilities
- Debugging capabilites
I am going to publish the next part today, as it relates to all of the considerations discussed here and breaks them into questions that will elaborate more fully on the camera design specifics for this project.
RSS Feed