Real-Time Cameras in Unreal Editor 4 - Part 6

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.

    Player abilities and controls
   
    The manner in which the player character is controlled and its abilities within the confines of the game engine have a             significant impact on camera design.

• How does the player character move? Does it accelerate slowly? Is the motion constrained to be upon a path or surface? Is the player able to jump or fly?

A: The player walks on ground surfaces and jump to reach higher ground. There is no acceleration and the movement is not contrained to any surfaces. Unlike Journey, there is no flying, gliding, sliding or other movement planned outside of the Unreal Editor 4 default pawn behaviours.

• Have character motion and abilities been finalized? Changes to either of these components may greatly influence camera requirements.

A: Yes, as released in the current version of Unreal Editor 4. Further pawn changed are not mentioned in the road map.

• Where should the camera be located compared to the character?

A: Faraway and behind the character, unless directional input or camera hints are applied, with feet visible at all times.

• Is it important to retain a position that allows a view from a particular orientation with respect to the character orientation?

A: No, orientation with respect to the character will be altered dramatically by camera hints.

• What is important for the player to see?

A: The character's feet for platforming, the landscape and landmarks, and hazards in the environment.

• Should the camera be focused on the player character (especially in aiming or long-range weapon games)?

A: Yes, with some forward offset.

• Is there a part of the character that must be kept visible (e.g., feet in some platform games)?

A: Yes, the feet.

• Is there some other game object that should be framed rather than the player character?

A: No.

• Does the orientation of the camera need to vary according to the position of the player or other game play considerations?

A: Yes, the hint system should be able to take the player from bird's eye to worm's eye based on the character position.

• How should the player character be controlled?

A: Gamepad, with a stretch goal to continually include and maintain the ability to use mouse and keyboard input.

• Does the situation demand a different kind of control scheme from regular game play?

A: No, there is only one control scheme throughout gameplay.

• Will this control scheme change according to the game play requirements?

A: No. it may change from Unreal Editor 4 defaults to better represent Journey control schemes though.

   
    Environmental concerns
   
    No camera system is likely to be able to cope perfectly with the arbitrary complexities of game environments without             either predetermined motion paths or extensive analysis (and storage) of possible camera positions; the camera system     has to both dynamically navigate the environment and present a view of the world that satisfies both aesthetic and game     play requirements. There will undoubtedly be cases where the physical nature of the environment precludes camera             placement to satisfy either (or both) of these conditions. This should obviously be avoided whenever possible and is a         good case for prototyping of camera placement and motion before committing to a particular environment. Attempting to     find camera solutions after artwork has been completed can lead to both designer frustration and additional work for the     artists. Design the environment around game play and camera limitations if possible, anticipating compromises in the         process.

    Let us enumerate some of the questions that a camera designer should pose when considering how the camera                 system should function within a particular game environment.

• Within what kind of environment is the character moving? Is the world confined with relatively small spaces or open and able to allow easy positioning or movement of the camera?

A: Open, with gentle slopes and various objects with different profiles that are scattered sparsely through the environment.

• Does the environment influence camera positioning or orientation? For example, the character could be moving through the surface of a water plane, thus requiring the camera to avoid interpenetration of its near plane. A confined, closed space will require a different camera solution compared to a free-form flight over a wide open space.

A: Yes, there will be objects that the camera must avoid colliding with.

• Does the camera need to be positioned outside of the environment and if so, how will that be presented to the player? How will the camera transition between regular game play and this special case?

A: No.

• Is this camera required to follow the player through an environment that may dynamically change (e.g., closing doors)? If the camera were prevented from moving, would the player be able to interpenetrate the camera?

A: No, not in the scope of this project.

• Does the camera need to avoid complex geometry or large game objects?

A: Yes.

• Should the camera motion be restricted to a specific path or surface to aid this avoidance?

A: No. This may change if there are no other elegant solutions to avoiding large game objects in the test level.

• Are there changes that can be made to the geometry to simplify camera design or implementation?

A: No, the geometry will be blocked out with the simplest possible shapes.

• Are there specific requirements for the camera in this situation, for example, framing of a specific game object in addition to the player character?

A: Yes, in some case we will wish to use a hint system to frame landmarks in the environment.

• What kind of presentation would work best: first or third person? Does the player character have differing abilities that would demand wildly different camera behaviours?

A: Third person. No.

• How will changes between different camera behaviours occur?

A: Any changes will be subtle differences and will either occur in one frame or interpolate over a few frames if necessary.

• Can interpolation methods be guaranteed to work given the environment?

A: Yes. The environment will be rebuilt in any case where this proves true.

• Are different camera solutions required according to how the player enters the area, for example, from different sides of a half-pipe shaped room?

A: No.

• Is it necessary to have collision geometry that is marked specifically for the camera?

A: Yes, a tag system will be introduced and described in more detail after completion of camera base behaviours.

• In general, collision geometry should be chamfered or otherwise angled to allow the camera to move smoothly across surfaces if necessary, assuming that collision geometry is distinct from that of rendering geometry.

    Technical concerns
   
    In addition to the more general technical concerns laid out earlier in this chapter, we must consider the capabilities of the     existing game engine that pertain to camera usage:

• Are there technical limitations that must be considered when designing camera motion, placement, or orientation? Such limitations may include rendering performance issues, proximity to the game characters or geometry, control reference frame determination, and so forth.

A: Indeterminate. This will be determined over the course of development, and by increasing experience with the engine.

• If the camera is forced to pass through game objects or geometry can their rendering be altered to make them transparent or otherwise unobtrusive without adversely affecting game play?

A: Yes, but these solutions will be avoided in this project until all other viable options have been examined.

• Is it possible for the camera to be prevented from moving to its desired position, and if so, how should this be dealt with?

A: Yes, an elegant solution will be determined on a case by case basis using the soon-to-be-made tag system.

• Is it necessary to have fail-safes built into the camera system to cope with unexpected situations that normally do not arise in regular game play? Examples might include doors closing between the camera and its intended target, the camera being forced outside of the game environment, interpenetration of the camera and its target, etc.

A: Yes, there will likely be undesirable results that arise which need fail-safes but these possibilities are not fully explored.

• Do we wish to allow camera manipulation including repositioning? To what extent will this be allowed?

A: Yes. Only yaw will be controlled by the player, the camera hint system will control orientation based on positioning.

• Can the camera be positioned such that game objects will be unable to pass through its location or obscure the player character? If not, do we have the ability to control rendering of objects that satisfy either of these conditions?

A: Yes, and potentially yes. These issues will be investigated where the tag system fails to solve them.

• Does the environment offer opportunities to occlude the player character that cannot be resolved? Can the environment be changed or constructed so it can be removed as necessary?

A: Yes, it is possible that such environmental features are created. Yes, these cases will call for rebuilding the level.

• Is it necessary to interpolate or otherwise transition smoothly between different cameras? If so, how will the transitions cope with geometry or objects that might prevent the transition from completing normally? Additionally, how will such interpolation occur between potentially different camera behaviours or properties?

A: No, a single camera will be used. Cut transitions will be used if any situations arise where a second camera is needed.

    These lists of questions are by no means exhaustive, but the should provide enough information for the initial pass at a     potential camera solution. It is advisable to create a document that outlines the capabilities of the camera system and         how the game design can work within those contraints. This document will be a useful crib sheet for both level and                camera designers to ensure that level construction takes account of technical limitations and the desired aesthetics for     the camera solution required by a specific game."

The following parts to this series will occur after substantial advancements have been made, or new educational lessons or resources have been found or created. Follow me @dodgethistweet to get updates when the new blog posts become available online. Hope this list of questions by Mark Haigh-Hutchinson was helpful for you! I will be posting one of his Camera Design Guidelines at the beginning of every part from 7-20. Or, check them out in his book from p132 onward.