3D Action Adventure Kit Camera Documentation
While you may not realize it, the camera is one of the most important elements of any video game. It’s literally the only way you can see anything in the game. Big game companies put large amounts of resources into designing, coding, and polishing the camera to provide the player the best experience possible. Cameras allow designers the ability to show players what they want them to see, or how they want them to feel using camera movement and placement. This document will cover all the topics needed to understand how to control and design the camera system used in the 3D Action Adventure Kit.
Note: This documentation is specific to TGEA, not the newest T3D build. Most of the workflow is still relevant but specific lines of code called out or editor shortcut keys may no longer be relevant.
Camera Features Overview
The basic features of the cameras included in this kit are:
3 Different Camera Modes Overview
Dynamic Player Camera
This camera acts as though it is on a leash following your player model. As you run forward the camera will follow behind. If you make a turn the camera will continue to follow you. If you turn around to run back to where you were coming from, the camera will stop and turn with you. This camera takes the least amount of effort to implement because it works very well in most situations automatically.
Constrained Axis Camera
While the Free-Orbit Camera is not a separate camera mode, it is a powerful feature of the Dynamic Player Camera and Constrained Axis Camera. This camera functionality allows the user to hold down the Right Mouse Button and have free-control over the camera’s orbit around the player. The Free Orbit Camera is not available if you are using the Path Camera Mode.
Camera Control using Triggers and Dynamic Fields
This next section discusses how to implement and control the three main camera modes. Let’s get started!
Cameras controlled by Triggers
The first thing we will discuss is how triggers control the different camera modes. When the player enters a trigger, the trigger will tell the code to enter into the specified camera mode. The camera mode is specified using information that is stored in the Trigger object’s attributes. The Trigger attributes can include information such as what camera mode to switch to, the pitch or yaw of the camera, or how long the transition between camera modes should take. Be sure to remember that the camera mode is switched when the player enters the trigger, not while they are inside the trigger.
For example, I may have my player jumping along the side of a cliff using a Constrained Axis Camera. Once the cliff jumping section is over, the player must run through a field. I would want the camera to switch to the Dynamic Player camera so that the camera follows behind the player instead of remaining Constrained to a particular axis. I would do this by placing a Dynamic Player Camera Trigger on the route between the cliff and the field. When the player runs through this trigger, the camera will smoothly transition between the Constrained Axis Camera to the Dynamic Player Camera and if designed correctly, the player should not even notice there was a shift in camera modes.
How do I create a Camera Trigger?
This is done the same way as creating any other trigger. To create a trigger in torque open the editor, enter World Creator mode (F4), then navigate to Mission Objects>Mission>Trigger (step 1 below)
Once you click to create the Trigger you will be prompted to create a trigger (step 2 below). Give your trigger an appropriate name, select the type of Camera you wish to use from the datablock drop down menu, and then click okay (Don’t worry, we will go into the different camera datablocks in the next section). You do not need to worry about the Polyhedron field. It’s best to just leave that as the default value.
Tip: The editor, by default, when it creates a new object will place the object on the nearest piece of ground or geometry that the center of the camera is looking at. Therefore, make sure you are looking at the ground whenever you create a new object. Otherwise the new object you create might spawn on the other side of the map! If you want to change this setting it can be found in the editor menu bar under World>Drop Location.
Once you click okay you should now see a small yellow box sitting on the ground. This yellow box is your new trigger! That’s all you need to do to get started with camera triggers. There are a few more camera mode specific trigger attributes to learn and we will be covering those in their respective sections.
Before we go into the camera specifics we’ll need to quickly discuss Dynamic Fields. Dynamic Fields are properties that the level designer adds to each trigger to give it unique properties.
For example: a property I could add to the Path Camera would be to always look directly at the player. This would be done by creating a Ddynamic Field with the label lookAtPlayer and the value set to 1. (1 means on, and 0 means off).
To create a Dynamic Ffield, select your trigger and go to the inspector to view its attributes (F3). Scroll down to the very bottom and you will see the Dynamic Fields section. Click on the green plus symbol (step 1 below). This will create a new Dynamic Field with some default values (step 2). The text box on the left is the Dynamic Field label (or property that you are modifying), the text box on the right is what the value of that property you wish to set. What you will want to do is erase these default values and put in your own values. For the example above, you would put lookAtPlayer in the left text box, and 1 in the right text box (step 3). Make sure after you input these that you press Apply (step 4).
Tip: If you want to remove a Dynamic Field, just click on the red minus symbol that is located beside your Dynamic Field and this will delete it.
Dynamic Player Camera Trigger Implementation
Now that we’ve covered how to create Camera Triggers and Dynamic Fields, let’s get more specific about how to implement the different types of cameras.
The type of Trigger datablock to use if you want to switch to the Dynamic Player Camera is the CameraTrigger_Player datablock. When creating the trigger (step 2 above) you would select CameraTrigger_Player from the dropdown menu. Anytime the player enters this Trigger the camera will switch into the Dynamic Player Camera. The only Dynamic Field you will need to adjust for the Dynamic Player Camera is the time Attribute. The time attribute controls the length of time the camera will transition from its previous camera position into the new camera position. Time is measured in milliseconds so if you want the camera transition to last for 2 seconds, you’d need to put “2000” into the dynamic field properties.
Constrained Axis Camera Trigger Implementation
The Constrained Axis Camera is essentially a modified Dynamic Player Camera, and therefore we will use the same datablock as the Dynamic Player Camera: CameraTrigger_Player.
The big changes that make this camera so powerful are the abilities to control the pitch, yaw, and camera distance. These attributes will really allow the designer full control of what the player sees and how they move through your level. It can also be used to help give players hints by "steering" them to look at certain areas.
Once again, these attributes are controlled by the following Dynamic Fields:
forcedYaw controls the left to right rotation of the camera. If this attribute is set, it will always look at your player from the specified angle. The forcedYaw attribute uses radians and ranges from 0 to 2p (0 – 6.28) and is relative to world coordinates. You may need to try a few values to find the correct angle.
forcedPitch controls the up/down rotation of the camera. If this attribute is set, it will rotate the camera up above or down below the player to look at them. The forcedPitch attribute ranges from -1.5 to 1.5. If the forcedPitch is set to -1.5 the camera will be directly below the player looking up. If it is set to 0.0, the camera will be exactly horizontal with the player. If it is set to 1.5 the camera will be looking straight down above the players head.
forcedRadius controls the distance the camera is away from the player. Think of this as if the camera is on a stick. One end of the stick is touching the player, the other end has the camera on it. The forcedRadius is the length of that stick. The forcedRadius attribute ranges from 0 to infinite, though anything more than 20 and you’re going to be pretty far away from the player.
time, as explained previously, controls the amount of time this camera transitions from the previous camera position, to the current one.
Example: Let’s say the current Constrained Axis Camera settings for our player are forcedPitch .4 and forcedRadius 7 (see image below). If the player is moving along a ledge and I want to give them a better view of what is below, I could simply create a camera trigger along the ledge that has a forcedPitch value of 0.8, a time value of 4000, and a forcedRadius value of 10. What this does, is that as the player is moving along the ledge, when they enter this new camera trigger, the camera will perform a nice and slow 4 second transition from previous camera to a view that is looking down on the character and zoomed out slightly to give more room to see below.
Path Camera Path Setup
The Path Camera works very differently from the two previous camera modes mentioned. The Path Camera works as if the camera is on a fixed track and it dolly’s along the track depending on where the player is. Before we talk about the trigger properties for this, we need to learn how to create paths.
How to Create a Path
In Torque, creating paths is very simple. The steps outlined below should have you creating your very own paths in no time.
Path Camera - Trigger Implementation
The Path Camera Trigger is implemented the same way as the previous cameras but with a few modifications. The trigger datablock that must be used is CameraTrigger_Path. The Dynamic Fields that can be used for the Path Camera are:
Path Camera - Path Implementation
Now that we understand how to create paths and how to hook them up using the Path Camera Trigger, we can start creating paths for the Path Camera. The Path Camera is implemented using 2 separate paths. The first path is used to mark the path that the player is running along. The second path is the corresponding path used as a track that the camera moves along.
For example, let’s create a path with 3 nodes along the ground. We’ll call this path player_path (shown in black below). Let’s now create another path with 3 nodes but we’ll create this path in the air above the player_path. We’ll call this new path camera_path (shown in blue). When the player is standing at the first Path Marker of the player_path, the camera will be located on the first Path Marker of the camera_path. As the player runs along the player_path towards the second Path Marker, the camera will follow along on the camera_path. When the player reaches the second node on the player_path, the camera will also be at the second node on the camera_path. The camera is always in the relative positiong on the camera path, to where the player is on the player path.
Closest Point Warning
No Orbit-Camera for Path Camera
The last camera trigger that we will discuss is the CameraTrigger_Reset. When the player leaves this trigger, the camera will automatically switch back to the default Dynamic Player Camera. This allows you to surround your whole play area with this camera, and if somehow the player ends up somewhere they aren’t supposed to be, at least their camera switches back to the default camera so they are still able to run around and not have the camera stuck in a certain mode.
This trigger is implemented by selecting the CameraTrigger_Reset datablock when you create the trigger.
One final item to be covered before we wrap things up, is the new ignoreCamera attribute that you will now find inside every object’s attribute list. What this setting allows you to do is turn off the geometry detection on any object you would like. For example, you may have your character running along on a path and the player passes behind a tree. Instead of having the camera jarringly zoom in so that the tree does not block the player from the camera, you can turn on the IgnoreCamera attribute for the tree. This will allow the character to pass behind the tree and the camera will follow along as if the tree wasn’t even there.
After reading this document you should have a strong understanding of how to design and control the various camera modes. Be sure to look adn see how we have implemented the different camera modes in our demo level, which is included with the kit. One of the biggest reasons we created this demo level was as an example for others to learn from. If you have any further questions, please direct them to the ubiqvisuals.com support forums. For additional camera tips please refer to our Level Design Documentation.