Developers Club geek daily blog

1 year, 9 months ago

This article — transfer of performance of John Neski (John Nesky) with GDC14.

John — one of developers in the TGC company known for the game Journey. It began to work as the game designer there, but afterwards was fond of setup of operation of the camera in Journey therefore now his position sounds as Feel Engineer.

It is unlikely you will find some community of the developers specializing in game cameras. Also there is, perhaps, only one book on this subject — Real Time Cameras behind Mark Heyg-Hutchinson (Mark Haigh-Hutchinson) authorship. But it would be desirable to study more deeply this subject and to learn how people solve these or those difficulties.

The fact that the great attention is not riveted on a subject of cameras is unsurprising — so far they work as it is necessary, to discuss them there is no need. They become noticeable when do something not so. Players begin to discuss operation of the camera only when want to complain that it irritates them.

Therefore to talk on game cameras, it is necessary to reconcile to errors. And in this article I will tell what can go not so when you begin to project behavior of the camera in your game.

Outside cinema

Undoubtedly, we can learn much at cinema, but for game cameras there are many rules. The operator can plan in details as he will shoot a scene, but game designers are deprived of such luxury. In total in game, including the camera, has to react to actions of the player and adapt to the current situation. For this purpose we need to formulate rules of good behavior of the game camera and to teach them to execute the computer.

Types of game cameras

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

Between them there is a large amount of distinctions, but the basic (from which the others follow) is a distance from the camera to the character managed 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 follow ways of a field of the overview and to block the character. Roughly speaking, you get rid of the fourth wall. All two-dimensional games are so made — it concerns as games with a side view, and with the top view (in this case you get rid of a ceiling, but not of a wall).

In a case with a type from the first person, on the contrary, the distance equals to zero. The camera actually is in a skull of the character therefore you do not need to care for that the camera monitored it — the player and so sees the world eyes of the character. So the character will never pass out of sight, and there is no need to get rid of walls or ceilings.

The remained type of cameras — with a type from the third party and the dynamic angle of shooting — is somewhere in the middle between previous two and inherits the worst lines both.

During development of Journey we wanted that the player could investigate in details the world therefore refused the camera of the first type. At the same time we wanted that the player could see well the character therefore it was necessary to refuse also the camera with a type from the first person. Means, we needed the camera placed in the game world and which is directly near the character. Therefore we had to potter with determination of collisions the overview field between the camera and the character remained pure that the player always saw what it does.

All these restrictions turned back for us the whole array of problems. They were at least 50 pieces, and I made bold to number them for your convenience. I faced the majority of these problems, working on Journey, and, as a rule, the first solution always was wrong. Some of them remain even in the released games, and some and remained unresolved in Journey.

Actually at first in this list there were 100 errors, but it was necessary to cut down a little it to keep within regulations of performance.

#1 to Use the dynamic camera needlessly

Dynamic cameras from the third party — the most difficult in implementation. There is nothing shameful in using simpler options, to concentrate on other aspects of game process and to bring them to a presentable status. The dynamic camera will not make game better, and more likely on the contrary — everything will spoil. For example, in long ago the published three-dimensional Mario and Zelda the dynamic camera was used, and in the last sequels developers returned to static again. And these games received quite good comments.

For student's works, geymdzhem and similar actions with tough time frames unambiguously to use simpler models of the camera better — with the fixed corner or from the first person.

#2 to Use the camera not suitable to design of levels

The design of levels is closely connected with design of the camera. Both level, and the camera have to help the player to be guided in the game world. If you know under what corner there will be a camera, you can design all level taking into account it. If the camera can change the direction, it is necessary to be sure that the camera organically moves on the world, specifying the player a right direction. At the same time the camera has to work well in all types of locations which are in your game: and in narrow rooms, and on open spaces.

#3 to Use global coordinates and quaternions for the description of provision of the camera

This problem concerns more likely exclusively program implementation of behavior of the camera. It is possible to assume that the camera from the third party has to behave as the person holding the camera in hand and turning it in different directions. But the matter is that in games with a type from the third party, unlike games with a type from the first, a spin axis is not the camera, and the game character. And when the camera turns, it has to make the movement on an orbit around the character. Therefore it is not so important to store global (x, y, z) camera coordinates because they can always be found from coordinates of the character.

As for quaternions — it is considered that it is the best of all to describe orientation in space by means of them, and they are really very useful. But players do not think of quaternions, they think of Euler angles, and, so such concepts as pitch and roving. For them it is more clear to turn the camera by means of analog stacks or any other control to the left-to the right and up-down. So it is better to use Euler angles to describe orientation of the camera, and, so to use such concepts as pitch, roving and, perhaps, a roll.

It is not obligatory to use corners in final calculations, but they have to appear in quality of input data which can be translated afterwards in quaternions. As for the description of provision of the camera, instead of global three-dimensional coordinates it is better to use distance from the character and a deviation on two axes (if there is a need to locate the character not in the center of the screen).

#4 to Use such distance from the camera to the character at whom the viewing field can be easily covered

The viewing field in fact represents the imagined line connecting the camera and the character. This line is key part of all logic concerning operation of the camera, and the most part of a program code is engaged in the fact that it saves a viewing field pure.
The camera is closer to the character, the violation of purity of a viewing field is less probable.

#5 to Allow obstacles to block a viewing field on each side

Most often obstacles block the overview, appearing from screen sides. And the easiest way of prevention of it is permanent check reykasty from the character to the camera whether the character was covered. If the obstacle blocks it, we can move the camera closer to the character. But if to move it instantly, it will lead to sharp change of frames, and frequent sharp change of frames leads 30 degrees to violation of the rule. This rule came from cinema and says that at sharp change of frames the angle of shooting has to change at least by 30 degrees. It helps to avoid feeling of the shivering image.

Therefore it is much more pleasant when the obstacle which threatens to block a viewing field is bent around by the camera in advance. You can find such obstacle, using a series of the reykast proceeding from the character under different corners.
As soon as one of reykast finds an obstacle, you can in advance begin to shift the camera so that the obstacle did not come into the view. At desire you can reuse these calculations in the subsequent frames to facilitate operation of the processor.

#6 to Remove the camera from an obstacle when the player tries to shift the camera in its party

Here we also approached the first conflict in our behavior model of the camera.

In Journey and other similar games the user can manage the camera by means of analog stacks on the gamepad. And it is very important that intentions of the player were for your game on the first place. Therefore if the player wants to turn the camera in any party, the camera shall obey him, otherwise he simply will begin to be angry. And here we had a situation when the camera tries to bypass an obstacle, and the player tries to send the camera to this obstacle. In this case the only solution possible in my opinion is to bring closer the camera to the player. But as we can know already in advance that the obstacle threatens to come into the view, and the player tries to turn the camera just so that this obstacle precisely got to a lens, we can slowly bring closer the camera to the character. Then, by the time of when the obstacle has to come into the view, the camera will be already quite close to the character and will leave an obstacle behind.

#7 to Allow the player to move the camera in an obstacle

To avoid this error, it is rather simple to use a spherical collider around the camera not to allow the camera to enter in game objects.

#8 to Allow different forces to compete in the right to movement of the camera

We already considered a case when the camera tries to avoid an obstacle, and the player tries to send it to this obstacle. But it is not the only case, there is a set of similar situations. The movement of the camera has to meet several conditions at once and if these conditions compete with each other, then there can be a situation when they shield actions of each other, and we will receive not really good result.

But we can organize conditions a little in a different way. We know that at the camera only seven degrees of freedom: pitch, roving, a roll, distance from the character, shift on two axes and a viewing angle. Therefore we can organize work of conditions, based on what degrees of freedom for what conditions are important. In the example reviewed earlier both conditions concerned pitch of the camera. In this case we take all conditions concerning a certain degree of freedom, and we prioritize them. Besides, for an example earlier we know that input of the player has the top priority therefore we allow it to move the camera towards an obstacle.

#9 not to allow narrow obstacles to break an overview field

It is important to save an overview field pure, but there are cases when attempts to avoid emergence of an obstacle between the camera and the character bring more problems, than advantage. It concerns small narrow obstacles, for example, of columns. In this case it will be better to look if you just allow the camera to fly by by an obstacle. The player all the same will be able to trace the movement of the character in spite of the fact that that will be for a while covered. For these purposes it is possible to separate obstacles into those which can cover the character, and those which cannot.

#10 to Allow the camera to be crossed with obstacles

As we already found out, there is nothing terrible in breaking an overview field a small obstacle, but it is impossible to allow obstacles to run into the camera at all. In this case besides it is possible to use a spherical collider to define whether the obstacle camera concerns and if concerns, to remove it far away.

#11 to Perceive hills as obstacles which need to be avoided

In Journey it is complete of sandy dunes with gentle slopes and, as well as in a case with other obstacles, it is important to avoid their emergence between the camera and the character. However, you should not perceive hills as obstacles which need to be bent around on the right or at the left, it will be much more logical to raise the camera over the hill. As for Journey, there sandy dunes are not considered during reykast. But it is possible to check the direction of a normal to that surface that blocks an overview field, and to determine by it whether it is worth bending around an obstacle sideways, or it is better to lift the camera over it.

#12 to Shift the camera sideways when the obstacle appears behind

Still we considered cases when the obstacle appears sideways, and the camera is removed to the left or to the right. But obstacles can appear from absolutely different parties. For example, if the character moves towards the camera, and the camera moves back, there can be a situation when the camera is driven into a corner, and even the movements in the parties will not be able to bring her from there. For prevention of such situation it is worth using reykast, directed back from the camera, and with its help to find out whether there is no obstacle behind it, and if it is, it is simple to shift the camera closer to the character.

#13 to Allow near border of a render of the camera to cross the character

The near border of a render (near clipping plane) is the technical restriction inherent to all cameras in three-dimensional graphics. Everything that is closer than this border, is cut off because of what in objects holes can appear. We need to make sure that the character is seldom closer than this border, and it is never better —. Therefore between the character and an obstacle always there has to be enough place for the camera that the near border of a render did not cross model of the character. For this purpose it is enough to make the sizes of a collider of the character such that the character never approached an obstacle on distance, it is less than critical.

#14 to Use identical distance for any corners of pitch

If you look up, the camera needs to fall down that the character remained under review. But if we lower the camera down, it quickly enough will crash into the earth if only you do not move it closer to the character. In some games the camera at first crashes into the earth, and only then comes nearer. But it is much better to make so that it began to come nearer in advance, considering a surface of a floor and following a smooth trajectory. Also useful will use a similar trajectory and in the opposite direction that if you look down, and the camera rises over the character, the distance increased to the character. If you look down, then the horizon disappears from an overview field, you see only a small piece of a floor around the character, and to you can become a little close. But if to increase distance to the character, then it will be possible to see slightly more space around.

#15 to Use identical viewing angles for a look from below and for other slope angles of the camera

The sky — it is big. Also it would be quite good to take as much as possible sky in a lens. In real life we can see almost all sky at once, using peripheral sight. Our viewing angle together with the periphery reaches nearly 180 degrees. To give to the player looking at the sky in your game, similar feelings it is possible to increase a camera viewing angle in process of approach it to the earth. It will give to the player feeling that he looks at the sky eyes of the character.

#16 to Change pitch, a distance and a viewing angle independently from each other

As we already spoke earlier, at change of pitch it is necessary to change a distance of the camera and a viewing angle also. But if to change these values independently from each other, then we will face unpleasant effect. The matter is that at change of a viewing angle, also the sizes of objects on the screen as the viewing angle is in fact a zoom change. At change of a distance the sizes of objects will also change. At the same time in our case these values will change in opposite directions, and the player's character, together with all other screen objects, will begin to change the sizes convulsively. Therefore it is better to make so that the distance and a viewing angle together depended on pitch, and changed too together. However, you will surely come up against a situation when some other controling mechanisms the camera also want to change a distance or a viewing angle. In this case absolute values of these values can be made dependent on pitch, and to other mechanisms to allow to change the relative modifier for the necessary values. It can be both multiplicators, and normal addition subtraction.

#17 not to replace a frame when the character passes through opaque area

In this case threat of purity of a field of the overview is in front that really happens very seldom because the character in itself has a collider which will not allow it to pass through an obstacle. But there are situations when the obstacle is passable. For example, in Journey as such obstacles sandy falls act. In this case the only thing that you can make — it is sharp to replace a frame.

#18 to Change management at sharp change of frames

When you incline analog stik up, it means, you give command to go forward. But the direction of it depends on the direction of the camera "forward". And when the camera suddenly changes the direction when changing frames, value "forward" too sharply changes. At the same time the player not in forces it is instant to change finger provision, it needs time to orient. Therefore sharp change of frames is an excellent occasion to use a kat-scene or some effect of transition of one frame to another. Or it is possible at the moment when change of a frame is necessary, to place the player in such situation in which nothing will threaten it. Besides, it is possible to interpolate value between frames "forward". It is not sure whether well it works, but some so do.

#19 to Break feeling of the direction at the player

Change of management — a temporary problem because the player quickly enough can adapt to new conditions. However, change of frames with change of an angle of shooting influences the player in more long term, breaking its feeling of the direction. Players most often use two methods of orientation in space. The first method is a so-called navigation notation when the person monitors the change of position in space. For example, if the person is developed by 180 degrees, he understands that the North is the South now. The second method of orientation — on distinctive features of a landscape and environment in general. At sharp change of frames the first method of orientation does not work any more — the player cannot know, on how many degrees the camera and therefore cannot turn the imagined card turned to orient. Therefore the important fact will be the fact that the camera has to show to the player distinguishable reference points or some other objects which will allow it to understand where it is now and not to lose feeling of the direction.

#20 to Violate the rule of 180 degrees

This widely famous rule in cinema which is that when changing frames it is impossible to change the angle of shooting to 180 degrees. Fortunately, in games we should not worry too often on this rule because change of frames is a last resort to which it is necessary to resort, only if there is no other output. But there are cases when this rule is necessary by the way. Most often it concerns kat-scenes. For example, in end time of a kat-scene the camera has to show to the player information, sufficient for orientation. It is also possible to transfer slowly after the termination of a kat-scene the camera from home position to game.

#21 to be focused only on the player's character

Before we spoke only about the character, but the player needs to see also other objects of an environment successfully to be guided in space. For example, the player needs to see the earth directly around the character that the nobility whether he will crash into a wall or whether will fall from break. He needs to see also more remote objects, for example, of the mountain on the horizon in Journey or the character of other player.

#22 Always to rely on the player in a question of management of the camera

For many players at the same time to manage the character and the camera — it is approximately as difficult how at the same time to tap itself on the head and to iron a stomach. Even if the player manages to drive the camera, its movements will be antsy. Therefore the camera has to try to show to the player in advance what he needs to see at present time that it had not to turn it manually.

#23 not to change roving when the player runs

To allow the player to see the elementary method where it goes, it to deploy the camera in the direction of its movement. Just take the direction of the movement of the player and apply it to the angle of roving of the camera that it floated after the character. But there is one nuance — for example if the player runs towards a wall, there is no need to send the camera to a wall. Therefore it is worth using the motion speed of the character to define the direction of its movement, but not the direction of a stik of the gamepad. If the player, say, rested against an invisible wall, you should not tease him, showing what behind this wall is, just it is better to deploy the camera in the necessary party, showing to the player where it should go.

#24 to Interfere with a distance assessment

The problem is that the monitor screen — a flat surface. But even if we would have three-dimensional displays, perception depth all the same is the bad mechanism for an assessment of distances. Players evaluate the distances which are in the display plane much better. For example, if in your game the top view, to players is simpler to evaluate horizontal distances and if sideways — players can evaluate vertical distance and horizontal on one axis.

#25 to Leave the camera in horizontal position when the character reaches an edge of steep

When the person approaches break, he usually looks down, and the camera has to do in the same way. For this purpose it is necessary to make one more reykast, this time directed just before the character down. And as soon as reykast will find out that the character approached break, the camera has to move up and change pitch so that the angle of shooting allowed to see this break and provision of the character concerning edge. Additional plus of such acceptance is the fact that the camera will be already in advance ready to rounding edge if the player begins to fall from break. If it not to make and leave the camera in normal provision, then when falling the character it will follow it and itself will crash into an edge of steep.

To publish at once all 50 points it seemed to me excessive — article would turn out huge. Shortly there will be the second part of transfer.

This article is a translation of the original post at
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here:

We believe that the knowledge, which is available at the most popular Russian IT blog, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.
Best wishes.

comments powered by Disqus