50 Typical Gaming Camera Design Errors (Part 1)

Original author: John Nesky
  • Transfer
image

This article is a translation of a speech by John Nesky with GDC14.

The second part here is

John - one of the developers at TGC , known for his game Journey. He started working there as a game designer, but later became interested in setting up the camera in Journey, so now his position sounds like Feel Engineer.


It is unlikely that you will find any community of developers specializing in gaming cameras. And there is perhaps only one book on this subject - Real Time Cameras authored by Mark Haigh-Hutchinson. But I would like to study this topic more deeply and find out how people solve certain difficulties.

The fact that not much attention is focused on the topic of cameras is not surprising - as long as they work as they should, there is no need to discuss them. They become noticeable when they do something wrong. Players only start discussing the camera when they want to complain that it annoys them.

Therefore, in order to talk about gaming cameras, you need to come to terms with mistakes. And in this article I will tell you what can go wrong when you start designing camera behavior in your game.

Outside the cinema


Sure, we can learn a lot from cinema, but there are a lot of rules for gaming cameras. The operator can plan in detail how he will shoot the scene, but game designers lack such luxury. Everything in the game, including the camera, must respond to the player’s actions and adapt to the current situation. To do this, we need to formulate the rules for good behavior of the game camera and teach the computer how to implement them.

Types of Gaming Cameras


image
There are three types of game cameras:
  1. with a third-person view with a fixed shooting angle;
  2. from a third party with a dynamic shooting angle;
  3. and in the first person.

There are a large number of differences between them, but the main one (from which the rest follows) is the distance from the camera to the character controlled by the player.

In the first case, the camera is located far from the character. Therefore, you need to get rid of everything that can get in the way of the field of view and block the character. Roughly speaking, you are getting rid of the fourth wall. All two-dimensional games do this - this applies to both games with a side view and a top view (in this case, you get rid of the ceiling, not the wall).

In the case of the first-person view, on the contrary, the distance is zero. The camera is actually located inside the character’s skull, so you don’t need to make sure that the camera monitors it - the player already sees the world through the character’s eyes. So the character will never be out of sight, and there is no need to get rid of walls or ceilings.

The remaining type of cameras - with a third-person view and a dynamic shooting angle - is somewhere in the middle between the previous two and inherits the worst features of both.

During the development of Journey, we wanted the player to be able to explore the world in detail, so we refused the first type of camera. At the same time, we wanted the player to see his character well, so we had to abandon the camera with a first-person view. So, we needed a camera located inside the game world and located directly next to the character. Therefore, we had to bother with the definition of collisions, so that the field of view between the camera and the character remained clean, so that the player always saw what he was doing.

All these restrictions have turned out to be a whole bunch of problems for us. There were at least 50 pieces, and I took the liberty to number them for your convenience. I encountered most of these problems while working on Journey, and as a rule, the first solution was always wrong. Some of them remain even in released games, and some remain unresolved in Journey.

In fact, at first there were 100 errors in this list, but I had to cut it a bit to fit into the performance schedule.

# 1 Use a dynamic camera without the need


Third-person dynamic cameras are the most difficult to implement. There is nothing wrong with using simpler options, concentrating on other aspects of the gameplay and bringing them to a presentable state. A dynamic camera will not make the game better, but rather, on the contrary, it will ruin everything. For example, in the long-published three-dimensional Mario and Zelda, a dynamic camera was used, and in the latest sequels, the developers again returned to the static one. And these games got pretty good reviews.

For student work, game jams and similar events with tough time frames, it is definitely better to use simpler camera models - with a fixed angle or in the first person view.

# 2 Use a camera that is not suitable for level design


Level design is closely related to camera design. Both the level and the camera should help the player navigate the game world. If you know what angle the camera will be at, you can design the entire level with this in mind. If the camera can change its direction, you need to be sure that the camera organically moves around the world, indicating the player the right direction. At the same time, the camera should work well in all types of locations that are in your game: both in narrow rooms and in open spaces.

# 3 Use global coordinates and quaternions to describe camera position


This problem concerns, rather, exclusively software implementation of camera behavior. It can be assumed that the third-person camera should behave like a person holding a camera in his hands and turning it in different directions. But the fact is that in games with a third-person view, in contrast to games with a first-person view, the axis of rotation is not the camera, but the game character. And when the camera rotates, it must make an orbit around the character. Therefore, it is not so important to store the global (x, y, z) coordinates of the camera, because they can always be calculated from the coordinates of the character.

As for quaternions - it is believed that orientation in space is best described using them, and they are really very useful. But players do not think with quaternions, they think with Euler angles, and, therefore, with concepts such as pitch and yaw. For them, it’s easier to turn the camera left-right and up-down using analog sticks or any other control. So it’s better to use Euler angles to describe the orientation of the camera, and, therefore, use concepts such as pitch, yaw and, possibly, roll.

It is not necessary to use angles in the final calculations, but they must appear as input, which can later be converted to quaternions. As for the description of the camera position, instead of global three-dimensional coordinates, it is better to use the distance from the character and the deviation along two axes (if there is a need to place the character not in the center of the screen).

# 4 Use a distance from the camera to the character at which the field of view can be easily obscured


The field of view is essentially an imaginary line connecting the camera and the character. This line is a key part of the whole logic regarding the operation of the camera, and most of the program code is committed to keeping the field of view clean.
The closer the camera is to the character, the less likely is the violation of the purity of the field of view.

# 5 Allow obstacles to obstruct the field of view on the sides


Most often, obstacles block the view, appearing precisely from the sides of the screen. And the easiest way to prevent this is to constantly check with a rakecast from the character to the camera whether the character has been obscured. If an obstacle blocks it, we can move the camera closer to the character. But if you move it instantly, this will lead to a sharp change of frames, and a frequent sharp change of frames leads to a violation of the 30 degree rule. This rule came from the cinema and states that with a sharp change of frames, the shooting angle should change by at least 30 degrees. This helps to avoid the feeling of a jittery image.

Therefore, it is much more pleasant when an obstacle that threatens to block the field of view is enveloped in advance by the camera. You can detect such an obstacle using a series of rakastas coming from the character from different angles.
image
As soon as one of the rakastas finds an obstacle, you can advance to start moving the camera so that the obstacle does not come into view. If you wish, you can reuse these calculations in subsequent frames to facilitate the processor.

# 6 Move the camera away from the obstacle when a player tries to move the camera in his direction


So we come to the first conflict in our model of camera behavior.

In Journey and other similar games, the user can control the camera using analog sticks on the gamepad. And it is very important that the intentions of the player are in the first place for your game. Therefore, if a player wants to turn the camera in some direction, the camera must necessarily listen to it, otherwise it will simply start to get angry. And now we have a situation where the camera is trying to bypass the obstacle, and the player is trying to direct the camera at this obstacle. In this case, the only possible solution in my opinion is to bring the camera closer to the player. But since we can already know in advance that an obstacle is threatening to get into the field of view, and the player is trying to rotate the camera just so that this obstacle hits the lens, we can slowly bring the camera closer to the character. Then, by the time the obstacle has to come into view,

# 7 Let the player move the camera inside an obstacle


To avoid this error, just use the spherical collider around the camera to prevent the camera from entering the game objects.

# 8 Allow various forces to compete in the right to move the camera


We have already considered the case when the camera tries to avoid an obstacle, and the player tries to direct it into this obstacle. But this is not the only case, there are many similar situations. The camera movement must satisfy several conditions at once, and if these conditions compete with each other, a situation may arise when they screen each other's actions, and we will not get a very good result.

But we can arrange the conditions a little differently. We know that the camera has only seven degrees of freedom: pitch, yaw, roll, distance from the character, two-axis offset, and viewing angle. Therefore, we can organize the work of conditions based on what degrees of freedom are important for which conditions. In the example discussed earlier, both conditions concerned the pitch of the camera. In this case, we take all the conditions relating to a certain degree of freedom, and prioritize them. Again, as an example, we previously know that entering a player has the highest priority, so we allow him to move the camera toward an obstacle.

# 9 Do not allow narrow obstacles to disrupt the field of view


Keeping the field of view clean is important, but there are times when trying to avoid an obstacle between the camera and the character will bring more problems than good. This applies to small narrow obstacles, such as columns. In this case, it will look better if you just let the camera fly past an obstacle. The player will still be able to follow the movement of the character, despite the fact that he will be briefly obscured. For these purposes, you can divide the obstacles into those that can obscure the character, and those that can not.

# 10 Allow the camera to cross obstacles


As we already found out, it’s okay to break the field of view with a small obstacle, but in no case should obstacles be allowed to run into the camera itself. In this case, again, you can use the spherical collider to determine if the camera is touching an obstacle, and if it is, move it away.

# 11 Think of hills as obstacles to avoid


Journey is full of sand dunes with gentle slopes and, as with other obstacles, it is important to avoid them between the camera and the character. However, do not perceive the hills as obstacles that need to be skirted to the right or left, it will be much more logical to raise the camera above the hill. As for the Journey, there the sand dunes are not counted during the rakast. But you can check the direction of the normal to the surface that blocks the field of view, and from it determine whether it is worth going around the obstacle from the side, or it is better to raise the camera above it.

# 12 Move the camera sideways when an obstacle appears behind


So far, we have considered cases where an obstacle appears on the side and the camera moves to the left or right. But obstacles can come from completely different directions. For example, if a character moves towards the camera, and the camera moves backward, a situation may arise when the camera is cornered, and even movement to the sides will not be able to get it out of there. To prevent this situation, it is worth using a rakecast directed back from the camera, and using it to find out if there is an obstacle behind it, and if it is, simply move the camera closer to the character.

# 13 Let the near border of the camera render cross the character


The near clipping plane is a technical limitation common to all cameras in 3D graphics. Everything that is closer to this border is cut off, which can cause holes in objects to appear. We need to make sure that the character is rarely closer than this border, and better never. Therefore, between the character and the obstacle there should always be enough space for the camera so that the nearest render border does not intersect the character model. To do this, it is enough to make the size of the character's collider so that the character never approaches the obstacle at a distance less than critical.

# 14 Use the same distance for any pitch angle


image
If you look up, the camera needs to go down so that the character remains in view. But if we lower the camera down, it will hit the ground quickly enough, unless you move it closer to the character. In some games, the camera first crashes into the ground, and only then approaches. But it is much better to make it begin to approach in advance, taking into account the surface of the floor and following a smooth trajectory. It will also be useful to use a similar trajectory in the opposite direction, so that if you look down and the camera rises above the character, the distance to the character will increase. If you look down, the horizon is hidden from the field of view, you only see a small piece of floor around the character, and you can become a little cramped. But if you increase the distance to the character,

# 15 Use the same viewing angles for view from below and for other camera angles


The sky is big. And it would be nice to capture as much sky as possible in the lens. In real life, we can see almost the whole sky at once, using peripheral vision. Our viewing angle along with the periphery reaches almost 180 degrees. To give the player looking at the sky in your game a similar feeling, you can increase the camera’s viewing angle as it approaches the ground. This will give the player the feeling that he is looking at the sky through the eyes of his character.

# 16 Change pitch, distance and viewing angle independently


As we said earlier, when changing the pitch, you should also change the camera distance and viewing angle. But if these values ​​are changed independently of each other, then we will encounter an unpleasant effect. The fact is that when you change the viewing angle, the sizes of objects on the screen also change, since the viewing angle is essentially a zoom. When you change the distance, the sizes of objects will also change. Moreover, in our case, these values ​​will change in opposite directions, and the player’s character, along with all other objects on the screen, will begin to frantically change its size. Therefore, it is better to make the distance and viewing angle together depend on the pitch, and also change together. However, you are sure to come across a situation where some other camera control mechanisms will also want to change the distance or viewing angle. In this case, the absolute values ​​of these values ​​can be made dependent on the pitch, and other mechanisms can be allowed to change the relative modifier for the desired values. It can be both multipliers and the usual addition-subtraction.

# 17 Do not change frames when a character passes through an opaque area


In this case, the threat to the purity of the field of view is in front, which actually happens very rarely, because the character itself has a collider that will not allow him to pass through the obstacle. But there are situations when an obstacle is passable. For example, in Journey, sand waterfalls act as such obstacles. In this case, the only thing you can do is drastically change the frame.

# 18 Change control during abrupt frame change


When you tilt the analog stick up, it means you give the command to go forward. But the direction of this “forward” depends on the direction of the camera. And when the camera suddenly changes direction when changing frames, the “forward” value also changes dramatically. In this case, the player is not able to instantly change the position of the finger, he needs time to navigate. Therefore, a sharp change of frames is an excellent reason to use a cut-scene or some kind of transition effect from one frame to another. Or you can, at the moment when you need a change of frame, put the player in a situation in which nothing will threaten him. In addition, you can interpolate the forward value between frames. Not sure if this works well, but some do.

# 19 Disturb the player’s sense of direction


Change of control is a temporary problem, because the player can quickly adapt to new conditions. However, a frame change with a change in the shooting angle affects the player in the longer term, disrupting his sense of direction. Players most often use two methods of orientation in space. The first method is the so-called numerical reckoning, when a person monitors his change in position in space. For example, if a person turns around 180 degrees, he understands that the north is now the south. The second way of orientation is by the distinctive features of the landscape and the environment as a whole. With a sharp change of frames, the first method of orientation does not work anymore - the player cannot know how many degrees the camera has rotated, and therefore cannot rotate an imaginary map to orient itself.

# 20 Break the 180 degree rule


This is a well-known rule in cinema, which consists in the fact that when changing frames, you cannot change the shooting angle by 180 degrees. Fortunately, in games we don’t have to worry too often about this rule, because changing personnel is an extreme measure that you need to resort to only if there is no other way out. But there are times when this rule comes in handy. Most often this applies to cut scenes. For example, at the end of the cutscene, the camera should show the player enough information for orientation. You can also, after the cut-scene is over, slowly move the camera from its original position to the game one.

# 21 Focus only on player character


Before that, we talked exclusively about the character, but the player needs to see other environmental objects in order to successfully navigate in space. For example, a player needs to see the earth directly around the character in order to know if he will crash into the wall or fall off a cliff. He also needs to see more distant objects, for example, mountains on the horizon in Journey or a character of another player.

# 22 Always rely on the player to control the camera


For many players, controlling a character and a camera at the same time is about as difficult as tapping yourself on the head and stroking your stomach. Even if a player manages to control the camera, its movements will be twitching. Therefore, the camera should try to show the player in advance what he needs to see at a given time, so that he does not have to manually rotate it.

# 23 Do not change yaw when a player runs


The easiest way to let the player see where he is going is to turn the camera in the direction of his movement. Just take the direction of the player’s movement and apply it to the yaw angle of the camera so that it floats after the character. But there is one caveat - for example, if a player runs towards the wall, there is no need to direct the camera into the wall. Therefore, it is worth using the speed of the character to determine the direction of his movement, and not the direction of the stick of the gamepad. Moreover, if the player, say, rested against an invisible wall, do not tease him by showing what is behind this wall, it is better to simply turn the camera in the right direction, showing the player where to go.

# 24 Obstruct distance estimation


The problem is that the monitor screen is a flat surface. But even if we had three-dimensional displays, the depth of perception is still a poor mechanism for estimating distances. Players are much better at evaluating distances in the display plane. For example, if your game is a top view, it’s easier for players to estimate horizontal distances, and if on the side, players can estimate vertical distance and horizontal along one axis.

# 25 Leave the camera horizontal when the character reaches the edge of the cliff


When a person approaches a cliff, he usually looks down, and the camera should do exactly the same. To do this, you need to make another rakecast, this time directed down directly in front of the character. And as soon as the rakecast detects that the character has approached the cliff, the camera should move up and change the pitch so that the shooting angle allows you to see this cliff and the character’s position relative to the edge. An additional advantage of this technique is the fact that the camera will be ready in advance to go around the edge if the player begins to fall from the cliff. If you do not do this and leave the camera in the normal position, then when the character falls, she will follow him and herself will crash into the edge of the cliff.

It seemed to me redundant to publish all 50 points at once - the article would have been huge. Soon the second part of the translation will appear.

Also popular now: