The camera is one of the elements of a game that, if done right, gets little to no attention from players. And that’s a good thing! Managing the camera is one of the tedious and boring parts of games. A well done camera enables the player to focus on what’s going on and show him the fun parts of a game, requiring little to no interaction. A bad camera requires a lot of fiddling and/or is not showing what’s important to players at all times.

A camera gets the player’s attention only when it fails to work in some way. I remember rotating the camera much more than was pleasant while playing old Tomb Raider titles. And I also remember jump’n’run titles that forced me to perform hundreds of “leap of faiths” simply because the camera didn’t show me where pressing the jump-button would take me. Many times, it’s not even apparent that the camera is the culprit! A often-used scapegoat that falsely has to take the blame is the level design. While I do agree that you should keep in mind your camera characteristics when designing a level, reworking it until it works with a “bad” camera is just trading one for another (possibly even worse) evil.
That might be the reason why many game developers don’t give the camera the love and caring it deserves. Yes, nobody gets an award for good camera behavior, but doing it wrong can ruin a game completely!

I’ll start by introducing two extreme cases and their intended goal. I can safely anticipate the outcome that none of them is the holy grail and there’s probably no general-case solution that would work for every game. There’s no such thing as free lunch! While knowing what’s possible is vital, it won’t save you from testing out and experimenting to find out what works for each specific game.
Still, the two extreme cases are ideal to show the two main goals a camera has to accomplish!

Extreme case 1: The locked-on camera

The locked-on camera is very prominent in platformers and is often the quick result of a bare-bone camera implementation. Footage of games in early development stages often use this camera model.
The idea is pretty simple: always move the camera so that the player’s character is in the center of the screen. The motivation behind that is also a no-brainer: the player’s character is the most important entity in the game and should always be visible. Of second-most importance is where the player’s actions will take the character, so it’s vital to show the  immediate vicinity of the character.

A variant of this model is to focus the camera on anther point that’s relative to the player’s character. For example, centering on a position that’s slightly higher than the player reveals more of the space above, possibly making higher platforms and collectibles visible. That of course comes at the cost of decreased visibility of what’s happening below the player. A falling character won’t see far down and might not be able to evade spikes or other deadly hazards. The same applies for left/right shifted camera centers.

The locked-on camera model is made to fulfill the first goal of a good camera:
Goal 1: focus on the player’s character!

Extreme case 2: The fixed camera

The fixed camera model is the complete opposite of the locked-on camera model. While the latter is bad in almost any case, the fixed camera model definitely has its uses! It’s been successfully used in many platformers, including Pitfall and VVVVVV.
The idea of the fixed camera model as simple as can be: just don’t move the camera! This simple statement changes the way a platformer is played completely. On one hand, by eliminating all camera movements, many of the problems you face otherwise simply disappear. On the other hand, levels (or in this case, screens) must be designed with the fixed viewpoint in mind at all times. This gets even more complicated if you need to target different screen sizes and resolutions. Because a player doesn’t see what awaits him at the next screen until he’s there, the game creates an artificial “visual cover”. Level design needs to consider this and adjust accordingly. For example, it’s not advisable to put an enemy right where the player enters a screen.

The fixed camera model is made to fulfill the second goal of a good camera:
Goal 2: move as little as possible!

Putting it together

Now what? We have established two goals for our perfect camera that seemingly contradict each other. And in fact, it’s not possible to fulfill each condition perfectly. What we can do however, is come up with a compromise between the two that satisfies both to a certain degree. So what do we want? We want as little movement as possible, while still keeping the focus on all the important stuff!

Sounds vague and inaccurate to you? That’s because it is! From here on out, I will present techniques that might or might not work for a specific platformer. It’s a matter of trying out methods and keeping what’s good.

But before I continue with some methods, I want to rephrase goal 1: I’d like to generalize it a bit to make it suitable for more cases. While the player’s character might be very relevant at all times, there are occasions when other in-game elements are just as important for the player. Consider a skidding turtle shell in Super Mario 3 (or many other Mario titles). Isn’t it vital for the player to know where the shell is?
Another example: consider a game where your character can throw grenades to take out enemies. He/she will probably lob them from a safe spot to take out enemies. In this case, the grenade might even become more important than the character itself, even if only for a few seconds!
Hence the rephrasing of goal 1:
Goal 1 (improved): focus on what’s important!
While I admit that this is a bit vague, let me also say that “importance” is hard to define in general and strongly depends on the game at hand!

Here’s our problem visualized:

Which part of the game should we show?

Deciding on which part of the game to show is not a trivial task

The light part in the center shows one possibility of what part of the game to show with our camera. We could have positioned the camera more to the right, making the enemy on the right and the treasure cave at the lower right visible, but also hiding the enemy on the left. We could have positioned it more upwards, showing the collectible diamonds at the top, but hiding the possibly dangerous acid pit to the right.

Again, what to show and where to position the camera at any given point in time cannot be answered in general but depends on what is important and what is not!


In the following section, I’ll present some methods that can help you get your camera to do what it should do: let the player focus on other things!

Note that it’s possible, if not necessary to combine the presented methods.

Smooth camera movements

The smoothly moving camera is a cornerstone for most good cameras. It makes the gameplay experience much more fluid and helps letting the player not lose track of where the camera is going. Nothing’s worse than doing a 1 frame cut from one camera position to a (distant) other. The player loses the sense of where he’s at and needs some time to recover. Time he could spend having fun!

Smooth camera movements work in almost any case! It’s a pretty safe bet to just apply it for any platformer. It’s easy to implement as well! In many cases, the distance the camera travels towards its current target in each frame is made directly proportional to the distance left to go. That makes the camera quickly approach its target, slowing down the nearer it gets. By doing so, there are no movement stutters and everything feels fluid. But don’t overdo it! Not moving enough per frame can cause the game to feel slow and let important things come into focus too slowly.

Also be aware that the smoothly moving camera is not a way to fix your general camera positioning issues! You might be able to hide the flaws a bit, but the underlying problems are still there. That’s because it’s much more important where to put the camera’s focus than how to move the camera there! Remember our goals! :)

Dynamic centering

Another widely adopted technique when dealing with cameras is to dynamically adjust the camera’s target position based on the velocity (or even acceleration) vector of the player’s character. If the character is quickly charging right, it’s very likely the player will want to see what’s to the far right. The faster the character moves, the more important this behavior gets. The same applies for vertical movements!

One thing to watch out for is when your character is able to quickly change direction. Running left, then suddenly right might produce quick camera pans that are unwanted. Furthermore, combining this technique with others, such as windowing, can cause strange effects and corner cases as well.

In-level camera helpers

In some circumstances, it might not be possible to achieve certain camera positions with general methods alone. In these cases, you can use level-specific “helpers” that govern where your camera should be looking at certain positions in the level. You basically guide your camera to the correct positions, even in tricky situations.

Note that using these methods gives you much more control over what to present to the player. While that’s great, these methods also require more work during level design because these helpers have to be placed into each level seperately.

In-level camera helpers are also direct manifestations of goal 1!

Level hints (attractors, repulsors, pushers)

Attractors are a way of saying: this position is important! Placing an attractor in the level means the camera will be drawn towards this position. There are many parameters and ways to implement that. One way is to measure the distance between the camera position and an attractor and if it’s below a threshold, shift the camera’s position by some amount, indirectly proportional to the distance. Attractors can be used to focus the player’s attention towards a high-valued collectible or an otherwise hidden path. It’s also possible to attach attractors to (moving) enemies, but one needs to be careful because the dynamic nature of this can also produce unwanted camera positions.

Repulsors are the precise opposite of attractors. The push the camera away from its position. They are useful for telling the camera where not to look, like boring ground or a secret area.

Pushers can be used for directing the camera in a certain, arbitrary direction. For example, when there is a giant pit right before the player’s character, it might be useful to direct the camera downwards a bit so the player is focussed onto that and can better gauge the situation. Placing a downwards pointing pusher will accomplish that.

Please note that the terms I came up with for these elements are not at all generally accepted. It’s just the terms I use (in code and otherwise).

Camera on rails

The more linear your level design is, the better suited the camera on rails is. When using this method, one places invisible railroad tracks throughout the levels. The camera can only be positioned along the railroad tracks. To determine the current camera position, one can either look for the nearest track, or let the camera “follow” the player’s character by only moving along the tracks. These two methods slightly differ, because in the former case camera “jumps” might occur, while in the latter the camera might lose track (pun not intended) of the player’s character. A combination of both methods might also be viable.


Another term I “invented”, windowing means that the target a camera tries to center on is not a single point anymore, but can have any shape and size. Mostly ellipses or rectangles are used though. That introduces some sort of slack into our camera model. For simplicity’s sake, let’s say our target is always the player’s character. As long as he/she is not moving outside our window, we don’t need to move the camera at all, fulfilling our second goal perfectly! Of course, if the window size is too big, we fail at meeting goal 1!

I’ve found that a higher vertical window is perfect for dealing with the issues arising when jumping (see the sidenote).

Other methods

I don’t claim to have presented nearly close to all the methods possible when dealing with 2D platformer cameras.  I’m sure there are several other methods that I have not mentioned or even thought of! If you have different ideas and/or working methods, let me hear! :)

Sidenote: issues with (vertical) camera movement

While horizontal camera movements are not too bad in platformers, vertical camera movements are trickier. Firstly because the vertical movements of most playable characters are much more sudden and quick than horizontal movements. Compare the movement pattern of a jump in a Mario title to that of walking (or running). Secondly, on almost any physical device, the screen width is larger than the screen height, giving you much less room to work with vertically. Put differently: there’s a reason why you play Doodle Jump with your phone/tablet upright! ;)

Quick vertical camera movements can cause a sense of control loss and repeated up-and-down tilts might even make them feel sick. The prime example where this can happen is jumping. If you take the name “Jump’n’Run” seriously, jumping is half the game! So we need to address this in a proper way!

With a locked-on camera, this effect becomes the most apparent. Depending on the sizes of your player’s character and the viewing window/viewport (or more specifically, the ratio between the two), this can work out bad or just downright awful! The jump-height and -speed is also important, of course. If your character is small and the player sees a lot of the surroundings, it “only” feels off and may be annoying. But the more space the character takes, the worse it gets. Worst case: during the ascent of a jump, the camera moves so much vertically that the ground from where the player just jumped off becomes not visible anymore (given flat terrain). This makes players really uneasy and causes a lot of uncertainty! It also makes it harder for them to gauge the height of their jump. It’s normal to measure the height of a jump as the distance from the ground you jumped off of. But if the ground is not visible anymore, how should the player learn about the character’s jumping abilities? Learning this and more generally, realizing what the character can and cannot do is one of the most important concepts of a platformer! And a bad camera can screw that up completely..


Camera issues are present in so many games, it’s not even funny! Especially game development beginners fall into the trap and stop thinking about the camera and its movement as soon as it follows the player’s character in some way, instead of improving and tailoring it until it is really working! While there’s no general recipe to follow to get to a perfectly behaving camera, there are methods that can help developers, one game at a time! :)