User Control for Camera Direction

User Control for cameras is not a very deep subject but I have some notes. These notes are based on experience from implementation and not concrete facts.

User Control For Orbiting a Camera around a Target

Smoothing

I prefer no acceleration or weight on the camera rotation based on player input, but that is something that many designers disagree with me about. My reasoning is that I like the immediacy of control to camera direction and I care more about accuracy than soft movement. The opposing reasoning is that it feels jumpy and unpolished. Spend some time on the smoothing parameters to get a decent compromise, especially if the smoothing also applies to cameras used for precision aiming.

Input Curve

Ideally you have analog inputs for the camera control, digital input is fine but it takes away from accuracy. In order to increase the meaningful range of analog input try to modify the curve a bit. Assuming input values range between -1 to 1, I often end up with the input value cubed:

rotation_speed = camera_rotation_max_speed * input3

Fighting for rotation priority

One approach is to simply add together user rotation to camera mode rotation, but the result can be rotation speeds that add up and become too fast.

The complication occurs when the camera mode wants to rotate one way and the user to the opposite, or when the user has a restricted rotation speed and the camera mode rotates in the same direction and the total speed is greater than normally allowed.

One approach is to ignore camera mode rotation when the user input is nonzero, another to choose the maximum rotation if both are in the same direction and add them if in opposite directions. This is something I tend to solve slightly differently for each camera mode, where a vehicle camera that is rotating towards the direction of the velocity of the camera target has higher priority than the user and a leash camera would use only user input if that was nonzero.

Spend some time to determine how the user input should influence the camera mode orientation. There are several options and the best way to choose something is generally to try them all.

Rotation Limits

There are usually limits for camera directions, more often for the pitch angle (rotation around the horizontal axis) to limit how low and high the camera can go. If the game has smoothing for the user control rotation, make sure to apply that smoothing to reaching the limits.

Letting users look upwards can be a positive but allowing the camera to get too close to the ground can be a problem for dealing with collision or seeing under things. One way to get around that is to simply let the camera rotate upwards without moving further downwards at a predetermined relative height from the target. Before reaching that height you can slow down the vertical movement to soften the transition from orbiting around the target to orbiting around the camera center.

If there are yaw limits (rotation around the vertical axis) due to parts of the scene that the user shouldn’t see (probably because there is no art in those parts) consider basing the limits on the world space limits so the user can see what is intended to be seen without going to the far edges of the scene.

Automatically Recentering User Input

Some game cameras will automatically recenter the camera direction after users have adjusted the camera, usually to allow for a wider range for users to see but that may not be ideal angles to run around with after the user lets go of the camera control. In some cases the camera might stay at the user control direction for a few seconds before recentering. The recentering can mess up the game controls a bit because it isn’t intuitive to keep up directional controls if you can’t predict how the camera will rotate or platforms you jump towards might go out of view as you’re trying to line up the jump. This happened during development of Pac-Man World 2 with one designer urging the constant recentering and another building levels with vertical precision jumping, and the camera code obviously couldn’t support both.

You can minimize the impact of the recentering if you scale the amount of rotation on the distance the player moves so the camera will not move before the player moves and will naturally blend with the movement. Most camera transitions can be concealed by locking the adjustment to player movement.

Other Input Devices

Another type of camera user control is using handheld screens with tilt and acceleration input. If the device tilt is not one to one with the ingame camera there is a resting orientation where the device matches up with the default camera. This is usually determined when entering a scene or switching camera modes and the device acceleration and tilt can be used to adjust the in-game camera angles.

Combining tilt controls with in-game rotation limits is bad. You get freedom to look around by tilting the device up to that point and the illusion of looking through a small window goes away. Try to avoid smoothing functions that add too much lag on the in-game orientation since there is already lag from reading the accelerometers.

Don’t assume that games need user camera control just because other games have it, but if there is a good reason to include it make sure it is useful in the context of the game and adds to the experience.