50 typical gaming camera design errors (part 1)

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

Second part here
')
John is one of the developers at TGC , famous for its Journey game. He started working there as a game designer, but later became interested in setting up the camera work in Journey, so now his position sounds like Feel Engineer.

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

The fact that there is not much attention to 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 start discussing camera work only when they want to complain that it annoys them.

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

Outside the cinema

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

Types of game cameras

There are three types of gaming cameras:

1. with a third-person view with a fixed shooting angle;
2. third-person dynamic angle shooting;
3. and first person.

There are a lot of differences between them, but the main one (from which the rest flow) 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 bar the character. Roughly speaking, you get rid of the fourth wall. All two-dimensional games do this - this applies to both games with a side view, and with a top view (in this case, you get rid of the ceiling, not the wall).

In the case of a first-person view, on the contrary, the distance is zero. The camera is actually located inside the character's skull, so you do not need to worry about the camera watching him - the player and so sees the world through the eyes of the character. So the character is never 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 explore the world in detail, so we abandoned the first type of camera. At the same time, we wanted the player to see his character well, so we had to give up 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 tinker with the definition of collisions so that the field of view between the camera and the character remained clear, so that the player always saw what he was doing.

All these restrictions turned out for us a whole bunch of problems. There were at least 50 of them, and I took the liberty of numbered 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 have remained unresolved in Journey.

In fact, at first there were 100 errors in this list, but I had to cut it a bit to meet the schedule of the speech.

# 1 Use a dynamic camera unnecessarily

Dynamic third-person cameras - 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 a long-published three-dimensional Mario and Zelda, a dynamic camera was used, and in the last sequels, the developers again returned to static. And these games got pretty good reviews.

For student work, gamejams and similar activities with a rigid time frame, it is definitely better to use simpler camera models - with a fixed angle or from the first person.

# 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 at what angle the camera will be, you can design the whole 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, pointing the player in the right direction. At the same time, the camera should work well in all types of locations that are in your game: in narrow spaces, and in open spaces.

# 3 Use global coordinates and quaternions to describe camera position

This problem concerns, rather, only the software implementation of camera behavior. It can be assumed that the third-person camera should behave like a person holding a camera in their 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 view from the first, the axis of rotation is not a camera, but a game character. And when the camera rotates, it must move in 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, which means with such concepts as pitch and yaw. For them, it is clearer to turn the camera left-right and up-down using analog sticks or any other control element. So it is better to use Euler angles to describe the orientation of the camera, and, therefore, to use such concepts as pitch, yaw and, possibly, roll.

It is not necessary to use angles in finite computations, but they should appear as input data, which can later be converted to quaternions. As for describing the position of the camera, 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 position 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 all the logic relating to 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 it is that the visual field is compromised.

# 5 Allow obstructions to block the field of view on the sides

Most often, obstacles block the view, appearing from the sides of the screen. And the easiest way to prevent this is to constantly check with the raikast from character to camera, whether the character was not obstructed. If the obstacle blocks it, we can move the camera closer to the character. But if you move it instantly, it will lead to a sharp change of frames, and 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 at least 30 degrees. This helps avoid the feeling of a shaky image.

Therefore, it is much more pleasant when an obstacle that threatens to bar the field of view, bends around the camera in advance. You can detect such an obstacle by using a series of raysts emanating from a character from different angles.

As soon as one of the raikasts detects an obstacle, you can begin to move the camera in advance so that the obstacle does not come into view. If you wish, you can reuse these calculations in subsequent frames to facilitate the work of the processor.

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

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

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 player’s intentions come first for your game. Therefore, if a player wants to turn the camera in some direction, the camera must obey him, otherwise he will simply start to get angry. And here we have a situation where the camera is trying to circumvent an obstacle, and the player is trying to send a camera to 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 the obstacle threatens to come into view, and the player is trying to turn the camera just so that this obstacle exactly hits the lens, we can slowly bring the camera closer to the character. Then, by the time when the obstacle should be in sight, the camera will be quite close to the character and leave the obstacle behind.

# 7 Let the player move the camera inside the obstacle

To avoid this error, simply use a spherical collider around the camera to prevent the camera from entering the inside of 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 obstacles and the player tries to send it to this obstacle. But this is not the only case, there are many similar situations. Camera movement must satisfy several conditions at once, and if these conditions compete with each other, then a situation may arise when they shield each other’s actions and we get a not very good result.

But we can arrange conditions a little differently. We know that the camera has only seven degrees of freedom: pitch, yaw, roll, distance from the character, bias in two axes and viewing angle. Therefore, we can organize the work of conditions, based on what degrees of freedom for which conditions are important. In the example considered 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, for example, we know earlier that player input has the highest priority, so we allow him to move the camera in the direction of an obstacle.

# 9 Do not allow narrow obstacles to violate 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 would be better to look if you just let the camera fly past the obstacles. 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 overshadow the character, and those that can not.

# 10 Allow the camera to cross obstacles

As we have already found out, there is nothing terrible about disrupting the field of view with a small obstacle, but in no case should we allow the obstacles to run into the camera itself. In this case, again, you can use a spherical collider to determine if the camera is touching the obstacle, and if it does, move it away.

# 11 See hills as obstacles to avoid

Journey is full of sand dunes with gentle slopes and, as is the case with other obstacles, it is important to avoid their appearance between the camera and the character. However, it is not necessary to take the hills as obstacles that need to bend around the right or left, it would be more logical to lift the camera above the hill. As for the Journey, there the sand dunes are not counted during the rakests. But you can check the direction of the normal to the surface that obstructs the field of view, and determine from it whether it is worthwhile to bend around an obstacle from the side, or better to raise the camera above it.

# 12 Move the camera sideways when an obstacle appears in the back

So far, we have considered cases where an obstacle appears on the side and the camera moves to the left or the right. But obstacles can appear from completely different sides. For example, if a character moves in the direction of the camera, and the camera moves backwards, a situation may arise where the camera will be cornered, and even side movements will not be able to pull it out. To prevent such a situation, it is worthwhile to use a raikast that is directed backwards from the camera, and with its help, find out if there are any obstacles behind it, and, if there is one, simply move the camera closer to the character.

# 13 Allow near camera render border to cross character

The near border of the render (near clipping plane) is a technical limitation peculiar to all cameras in three-dimensional graphics. Everything that is closer to this boundary is cut off, which can cause holes in objects. We need to make sure that the character is rarely closer than this limit, and better never. Therefore, between the character and the obstacle there should always be enough space for the camera so that the near limit of the render does not cross the character model. To do this, it is enough to make the dimensions of the character's collider such that the character never approaches an obstacle a distance less than the critical one.

# 14 Use the same distance for any pitch angle

If you look up, the camera needs to go down so that the character remains in sight. But if we drop the camera down, it will quite quickly crash into the ground, 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 start to approach in advance, considering the surface of the floor and following a smooth trajectory. It is also 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 view, you see only a small piece of the floor around the character, and you may become a little cramped. But if the distance to the character is increased, then it will be possible to see a little more space around.

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

The sky is big. And it would be nice to capture as much of the sky as possible into the lens. In real life, we can see almost the entire sky at once, using peripheral vision. Our viewing angle with the periphery reaches almost 180 degrees. To give the player looking at the sky in your game, similar sensations, you can increase the angle of view of the camera 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 angle of view independently of each other

As we said earlier, when changing the pitch, you should also change the distance of the camera and the angle of view. But if these values ​​change 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. In this case, in our case, these values ​​will change in opposite directions, and the player’s character, along with all the other objects on the screen, will start to frantically change its dimensions. Therefore, it is better to make the distance and angle of view depend on the pitch together, and also change together. However, you will definitely encounter a situation when some other camera control mechanisms also want to change the distance or viewing angle. In this case, the absolute values ​​of these quantities can be made dependent on the pitch, and other mechanisms can be allowed to change the relative modifier for the desired quantities. It can be both multipliers and ordinary addition-subtraction.

# 17 Do not change the frame when the character passes through an opaque area

In this case, the threat of 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 it to pass through an obstacle. But there are situations when the obstacle is passable. For example, in Journey, sandy waterfalls act as such obstacles. In this case, the only thing you can do is to drastically change the frame.

# 18 Change control during a sharp change of personnel

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 value of “forward” also changes dramatically. In this case, the player is unable to instantly change the position of the finger, he needs time to navigate. Therefore, a sharp frame change 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 frame change, put the player in a situation in which he will not be threatened. You can also interpol the “forward” value between frames. Not sure if it works well, but some do.

# 19 Break the player's sense of direction

Change of management is a temporary problem, because the player can quickly adapt to new conditions. However, changing frames with a change in 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 navigation number, when a person watches his change of position in space. For example, if a person turns around 180 degrees, he understands that the north is now south. The second method of orientation is based on the distinctive features of the landscape and the environment as a whole. With an abrupt change of frames, the first orientation method no longer works — the player cannot know by how many degrees the camera has turned, and therefore cannot turn an imaginary map to orient it. Therefore, an important fact is that the camera should show the player discernible landmarks or some other objects that will allow him to understand where he is now, and not lose a sense of direction.

# 20 Break the 180 degree rule

This is a widely known rule in cinema, which is 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 the change of personnel is an extreme measure that we need to resort to only if there is no other way out. But there are times when this rule will come in handy. Most often this concerns cut scenes. For example, during the end of the cut scene, the camera should show the player enough information to navigate. You can also slowly transfer the camera from the starting position to the game after the cutscene is finished.

# 21 Focus only on player character

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

# 22 Always rely on the player in control of the camera

For many players, controlling a character and a camera at the same time is about as difficult as simultaneously tapping oneself on the head and stroking the belly. Even if the player copes with the control of the camera, its movements will be jerky. Therefore, the camera should try to show the player in advance what he needs to see at a given point in time so that he does not have to manually turn it.

# 23 Do not change yaw when a player is running

The simplest way to let a 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 point the camera at the wall. Therefore, you should use the speed of movement of the character to determine the direction of its movement, and not the direction of the stick gamepad. Moreover, if a player, say, has rested against an invisible wall, you should not tease him, showing that he is behind this wall, it is better to simply turn the camera in the right direction, showing the player where he should go.

# 24 Interfere with 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 bad mechanism for estimating distances. Players estimate the distances in the display plane much better. For example, if your game has a top view, it is easier for players to estimate horizontal distances, and if from the side, players can estimate vertical distance and horizontal distance on the same axis.

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

When a person comes to a cliff, he usually looks down, and the camera should do the same. To do this, you need to make another raykast, this time directed down directly in front of the character. And as soon as the raikast finds that the character has approached the cliff, the camera should move up and change the pitch so that the angle of the shooting allows you to see this cliff and the position of the character 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 off a cliff. If this is not done and the camera is left in its usual position, then when the character falls, she will follow him and herself will crash into the edge of the cliff.

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