This post is the most updated, modified version of a talk I gave at the Independent Games Summit, GDC 2015. It contains some background information on 2D scrolling, along with plenty of classic gaming nostalgia. I hope you find it useful and enjoyable!
Overview
Working on my game Mushroom 11, I was faced with many different design and technology challenges.
I wasn’t expecting to find references to issues like dynamically changing shapes or vertex animation, but I was quite surprised that camera work, a subject with more than 30 years of history in games, was hardly discussed.
I decided to start a journey through the history of 2D gaming, documenting their challenges, approaches, and the evolution of their solutions.
Also, since there’s a lack of proper terminology for the many different solutions, I started gathering and categorizing them into groups, providing a glossary, if only for my personal reference.
Scrolling
Scrolling (or panning) refers to any attempt to display a scene that is larger than what fits in a single screen.
There are many potential challenges with scrolling, like choosing…
- What the player needs to see
- What we, as designers, would like the player to focus on
- How to do it in a way that’s fluid and comfortable for the player
While I’m going to focus on 2D camera systems, many of these general concepts apply to 3D as well.
Neural Background
Before we examine these games, let’s touch on the neural background of scrolling so we can understand our vision and perception better.
By learning more about how our eyes and minds respond to visual input—like camera systems—we can understand precisely how scrolling can go wrong.
The fovea-centralis is the receptor inside our eyeball responsible for sharp and detailed central vision.
The second and third receptor belts, the parafovea and perifovea, excel at reducing images and motions to patterns, allowing you to notice any changes immediately—including recognizing familiar alarming shapes and changes in motion speed or direction. |
This visual input uses the fast track straight to the amygdala, allowing for an alert response while the visual cortex is still deciphering the input.
Over time, you can learn to respond faster to pattern changes by training your brain to tie any shift in your peripheral vision to the controls.
The vestibular system, located in our inner ear, is responsible for maintaining balance and providing spatial orientation. The signals it sends allow the body to remain balanced while maintaining visual focus on specific details.
When some people, like me, try to read in a car, the acceleration combined with the lack of visual corresponding feedback can lead to nausea and vertigo. |
The opposite is also true: as the perifovea quickly picks up a change in the background, it expects corresponding feedback from the vestibular system. When there is none (as you’re sitting firmly in front of your computer), the result can be the same.
So, conflicting sensory signals (visual vs. vestibular) may lead to discomfort and nausea. The effect is worse in 3D (especially VR), but still very much present in 2D games.
Attention, Interaction and Comfort
To help understand the problems that can arise with scrolling, I’ve categorized its elements into three major challenges:
1. Attention: Use the camera to provide sufficient game info and feedback (what the player needs to see).
2. Interaction: Provide clear player control on what’s displayed, make background changes predictable and tightly bound to controls (what the player wants to see). 3. Comfort: Ease and contextualize background changes (how to reconcile those needs smoothly and comfortably). |
Scrolling Nostalgia
So, let’s start our journey back in the 1980s, a mysterious time when game designers were inventing completely new design schemes while overcoming technical limitations that are hard to imagine today.
You’ll also notice references to several leading indie games from recent years. Each of these displays the innovation, attention and care that can be expected from independent artists, and camera work is certainly no different.
Follow the Action
Keep attention on your control subject
Generally speaking, your player has authority over the main character. This dictates that the attention should be directed at that character by closely following it with the camera.
In the early 80s, scrolling was a difficult task, and the developer had to face limitations such as CPU, memory capacity and segmentation. Even with those challenges, some great side-scrollers were released, gracefully overcoming these limitations.
However, in many cases, the motion was understandably simplistic or low-resolution.
It’s remarkable that back in 1980, a game like Rally-X was able to overcome its technological limitations and present a true dual-axis camera.
It uses the default position-locking mechanism, keeping the car in focus at all times and the camera motion completely predictable.
Rally-X © 1980 Namco |
Position-locking – Locking the camera to the player’s position
Note: The terms presented throughout this talk were created for my own reference and work, but I’d be delighted if others find them useful, make improvements, and provide me with feedback. |
Kung-Fu Master is another good example for position-locking. It was designed by Takashi Nishiyama, who also made Moon Patrol and would later create Street Fighter.
This game uses another basic mechanism which I call edge-snapping—simply snapping the camera to the edge of the level, allowing the character to move away from its anchor point.
Kung-Fu Master © 1984 Irem |
Edge-snapping* – Set a hard edge for camera positioning
* Edge-snapping is too common to mention for each game, and will be ignored from now on. |
Position-locking is basic, but still very useful. It works very well in crafting adventure games like Terraria, which has a small character relative to the screen size with fairly small jumps, providing plenty of viewing space in all directions.
Terraria © 2011 Re-Logic |
Position-locking |
Curb Camera Motion
Avoid unnecessary or unpredictable bumps
How do we avoid moving the camera if it’s not absolutely necessary?
30+ years ago, scrolling had several issues. It was CPU-intensive, requiring a major part of the screen to be refreshed. Even when successful, the relatively large pixels made scrolling choppy.
The best approach was to keep scrolling to the necessary minimum. One method is to allow the character to move within a certain window, and only scroll when it pushes against the edges of that window.
Jump Bug is considered by many to be the first platformer, although technically the player is automatically jumping repeatedly, and their control is limited to the jump height as well as left/right motion.
Jump Bug © 1981 Hoei/Coreland (Alpha Denshi) |
Camera-window – Push camera position as player hits window edge |
Most of the game has an automatically moving camera, forcing players to keep up while avoiding obstacles, like many other scrolling games of the time.
But the camera-window technique used in the last level’s design solved a problem that many designers didn’t even know existed, and set the standard for thousands of platformers to follow.
The camera-window technique also introduced some issues, like offering very little view of what’s coming from up ahead as the player jumps toward the exit.
One of my favorites, Rastan Saga, introduced movement in 2 axes with various paths to take.
It was also one of the first games to really evolve the relationship between the camera and the game mechanics. This camera-window is as high as a standard jump, so jumps don’t cause vertical camera motion unless Rastan has already moved within the window (eliminating the need for rapid camera jerks).
Rastan Saga © 1987 Taito |
Camera-window |
A major flaw with this method is that enemies coming from above are less noticeable, especially if Rastan has already moved vertically within the window. Moving left, which happens a lot in castles, is also really uncomfortable as it leaves a very narrow lookahead margin.
The camera-window technique is still used in modern games. See how in Fez, the horizontal camera-window is maintained through dimension shifts, and in fact, the shift axis is chosen to keep the character within the window.
The choice of camera-window in Fez is far from the default, but it represents the ideal camera solution for such unique game mechanics.
Vertically, the camera maintains straightforward position-locking and is smoothed using lerp-smoothing, which we’ll define later.
Fez © 2012 Polytron Corporation |
Camera-window* (horiz.)
* Also enforced during dimension shifts Position-locking (vert.) Lerp-smoothing Region-based-anchors Manual-control* * Right-stick provides extra panning Note: Grayed-out terms represent camera techniques that are defined later in the article. |
Snapping
Fix camera drift within window
We’ve covered the use of camera-window to reduce camera movement, but as we can see in Jump Bug and Rastan, it has some flaws as the player drifts away within the window. There are a few ways we can fix this.
Maybe my favorite classic game, Shinobi, has some very high jumps between multiple platforms. To address this, the designers came up with Shinobi’s unique, very wide vertical camera window.
As always, the window pulls the camera with it immediately. The problem with a wide (or tall) window is that, after a small jump, the character could be stuck at the top of the window with very little top-view, as in Rastan Saga.
Shinobi simply continuously aligns the camera, slowly, to the Ninja, keeping the focus on the action—and, in most cases, minimizing rapid camera motion.
Shinobi © 1987 Sega |
Position-snapping (vert.) – Constantly reduce window drift by focusing the camera back on the player
Camera-window (vert.) Position-locking (horiz.) Static-forward-focus |
One of the many features that Super Mario World introduced was platform-snapping.
As with any camera-window, the camera stays stationary until the character hits the edge. But since Mario will inevitably land on a platform, as soon as he does, the camera immediately snaps to its position.
Super Mario World © 1990 Nintendo |
Region-based-anchors
Platform-snapping* – The camera snaps to the player only as it lands on a platform Camera-window* (vert.) * Where applicable Dual-forward-focus* * Threshold triggered Manual-control* (horiz.) * Controller provides extra panning |
(This is the first mention of the work of Miyamoto and certainly not the last. Awareness and attention to the smallest details are what really make a great designer, not just implementing clever game mechanics.)
You can see the same idea in the original Rayman. The top of the screen serves as the top of the camera-window.
Notice how the camera does not move as Rayman jumps, but rather gently snaps when he lands.
This is a clever solution since the camera-window is just over the height of Rayman’s jump, showing once again how the camera system is an integral part of game design.
Rayman © 1995 Ubisoft |
Platform-snapping*
Camera-window* (vert.) Region-based-anchors Dual-forward-focus* Lerp-smoothing * Where applicable |
This technique is very effective even today, allowing the designers to keep the camera smooth during jumps and center it only when the jump is complete, or if it pushes the camera-window.
Note that platform-snapping is naturally only effective when the player can land on platforms. In other cases, like the Jetpack character in Awesomenauts, the player only conforms to the vertical camera-window.
Awesomenauts © 2012 Ronimo Games |
Camera-window (vert.)
Platform-snapping Position-locking (horiz.) |
Smoothing
Avoid sudden camera speed and direction changes
We talked before about the role of our peripheral vision and its effect on visual comfort. In the olden days, even simple tweening would look jumpy due to the larger pixels of the time.
80s Pixel (NES: 256×240 resolution) |
Retro Pixel (Contains multiple screen pixels) |
So, how can we smooth out the camera motion, when we are confined by a really strict and crude grid of large pixels?
Nowadays, we can design beautiful pixel art, and then move it across the actual pixels that are much finer than the pixel-art. And if you choose to avoid going pixel-perfect, you can even make use of the sub-pixel space, which most modern engines can handle.
Smoothing with (pseudo-) physics
Pseudo-physics can come into play to help with smoothing a position-locked camera (and you could argue that any engine physics are in fact pseudo).
Pac-Land is arguably the first modern platformer.
It has many of the elements that helped define this genre, such as jumping on platforms, avoiding enemies and picking up bonuses. With regard to smoothing, its speed goes from 0 pixels per frame to 1, 2, 3, all the way up to the maximum speed, and then damped down to 0.
With the camera being locked to the player’s position, the results are clear and smooth. But Pac-Land doesn’t have to scroll vertically, where the real smoothing challenge lies, with the fast acceleration and deceleration of jumping and landing.
Pac-Land © 1984 Namco |
Position-locking
Static-forward-focus |
Shigeru Miyamoto
At this point, I’d like to give a quick hat tip to Shigeru Miyamoto and show some of his early works. His invaluable contribution to the industry and attention to the smallest details of game design cannot be exaggerated.
In 1984, he started experimenting with scrolling, designing two games that used it in completely different ways. In both these games, the player has very little control of the scrolling, if any. It’s more like a room with a shifting background.
Excitebike had a modern scrolling action, affected by the speed of the bike. Scrolling was smooth enough, but had no real effect on the game.
The gameplay in Devil World, however, had everything to do with scrolling. In this Pac-Man clone, you play as a Christian dragon fighting the devil whose role is limited to changing the scrolling direction, pushing you closer to the edge.
Excitebike © 1984 Nintendo |
Devil World © 1984 Nintendo |
Devil World is also the only Miyamoto game that was denied release in North America due to the use of religious icons, but compared with the quality of his decades of work, it doesn’t seem like a huge loss.
However, it is important, and even inspiring at times, to look at the early and often less successful work of modern-day geniuses. Even the greatest artists experiment, and often fail.
Moving forward one year, it’s hard to exaggerate the brilliance of Super Mario Bros.
The gameplay itself incorporates a pretty simple left-to-right, horizontal only approach. It also does not allow backtracking beyond the edge of the screen, which is a common platformer trait (technically it can be defined as a one-sided camera-window).
Super Mario Bros. © 1985 Nintendo |
Speedup-push-zone – When inside the push-zone, gradually accelerate the camera to catch up with the player’s speed
Camera-window** One-sided Static-forward-focus |
When Mario goes all the way back then speeds up to cross the camera-window edge, it will move from 0 to full-speed in one frame, causing a major change in background speed and the inevitable discomfort that follows.
The designers solved this by adding a virtual point, around 25% off-center, where the camera speeds up to catch up with Mario. This way, by the time he hits the edge, the camera speed will have already caught up.
The next step for side-scrollers
Metroid was a groundbreaking game that helped coin a genre, combining platforming with exploration. (Its genre-brother Castlevania had a very basic position-locking camera, by the way.)
Metroid uses multi-axis progression—one at a time.
It introduced a different way of easing the camera into motion by allowing the character to step out of the window span, while speeding up the camera to catch up. How far across that line the player ends up depends on how fast it hits that line, but the result is smooth camera behavior.
Metroid © 1986 Nintendo |
Camera-window (horiz./vert.) Speedup-pull-zone – Pull the camera to catch up with player’s speed |
The advancement of technology had a direct effect on camera systems, with more pixels and more robust CPUs leading to more complex camera systems.
These allowed the camera to move freely, without the low-resolution jitter that characterized the camera motion of older side-scrollers (especially at slow speeds, which could lead to one every few frames).
Donkey Kong Country introduced plenty of innovative camera solutions, and it was among the first to use lerp (Linear Interpolation) smoothing, allowing for smoother jumps and a forward-focus switch (more on that later).
Donkey Kong Country © 1994 Nintendo (Rare Ltd) |
Lerp-smoothing – Continuously reduce the distance between the camera and the active player using Linear Interpolation Position-locking (vert.) Region-based-anchors Dual-forward-focus |
Lerp-smoothing might not sound like a major accomplishment, but that’s because it’s become such a standard tool in reducing jarring camera speeds, particularly jumps.
float lerp (float a, float b, float t) { return a + t * (b – a); } |
This is probably the most effective and ubiquitous smoothing technique. It works well for slow- or fast-moving characters, like in Super Meat Boy.
Super Meat Boy © 2010 Team Meat |
Lerp-smoothing
Position-locking |
(However, large characters moving extremely quickly can easily hit the edges of the screen before the camera can catch up, keeping incoming enemies hidden till the last minute. Kind of a nasty surprise.)
Never Alone is a beautiful game that came out in 2014. Its main smoothing technique takes into account the existing camera speed, which means that it moves into action slightly slower and can overrun its target point.
The result feels smooth and organic, though it’s obviously less reactive to rapid player motion.
Never Alone © 2014 Upper One Games |
Physics-smoothing – The camera is a physics-enabled entity, constantly closing in on the focus target
Position-averaging Cinematic-paths Region-based-anchors Cue-focus |
In code terms, if Lerp is EaseOut, then physics-smoothing is EaseInOut. Where available, check out the SmoothDamp method for details, or tailor your own implementation that takes into consideration the distance to the target as well as the current velocity.
If you’re simply using pixel-perfect shaders, you’ll see that your sprites sometimes seem to shift a pixel, compared to other sprites or to the background, due to math division inconsistencies.
Hyper Light Drifter uses a clever solution to enable smooth scrolling, even though it has low-res pixel art.
It pre-renders on a game-pixel-perfect canvas, then shifts the canvas on a screen pixel-perfectly to reflect the remainder of the position after the division by game-pixel size.
Hyper Light Drifter © 2016 Heart Machine |
Physics-smoothing*
* Game canvas resolution is 480×270. Camera scrolling uses full resolution. Region-based-anchors Target-focus Cue-focus Gesture-focus |
Framing
Keep the important details in the frame
Auto-scroll is beyond the scope of this talk since, by definition, it provides no player control over the scrolling motion.
However, it gives us a helpful reference on where players would ideally like to be positioned, providing a good balance between threats coming ahead, and leaving some room for threats coming from behind.
Scramble © 1981 Konami |
Auto-scroll – The player has no control over the scrolling, but has full authority over their placement in the frame |
As we’ve seen in Pac-Land, if you tie the camera to the player and provide directional control, you can focus the camera ahead of the player.
This provides plenty of room to look ahead while still keeping track of what’s behind, and serves as a guideline for where to go, since we strive to aim for the center.
Pac-Land © 1984 Namco |
Position-locking
Static-forward-focus – Has extra view space in the principal progression direction |
Going back even further, early 1981 saw the release of Defender, a shoot-em-up which inspired an entire new genre. It was way ahead of its time.
The way it presents a forward focus bidirectionally (or dual-forward-focus) almost went under the radar. Defender always tries to focus the screen on an imaginary point in front of the spaceship, around 25% of the screen-width forward.
This system works well for fast-paced games in which most enemies come from the front.
Defender © 1981 Williams Electronics |
Dual-forward-focus – When the player’s direction changes, the camera switches focus to enable a wide forward view |
Bonanza Bros. is a delightful side-scrolling heist game released in arcades by Sega in 1990. It has a split-screen feature for its unique one-on-one co-op mode, where the two brothers work together to complete the heist.
Of course, a clear forward view is essential for a heist scenario, so a dual forward view is enabled. However, it takes a few steps for the camera to catch up with the new target point, making this entire motion feel extra-smooth while supplying plenty of space.
The switch speed is around double that of the player’s, which also means that the camera only moves when the player moves. Check out Red in the figure below:
Bonanza Bros. © 1990 Sega |
Dual-forward-focus*
* Focus switch is based on walking speed |
This camera trick from Super Mario World is one of my favorite 2D camera techniques, with overwhelming attention being paid to the specific gameplay details:
Super Mario World © 1990 Nintendo |
Region-based-anchors
Platform-snapping* – The camera snaps to the player only as it lands on a platform Camera-window* (vert.) * Where applicable Dual-forward-focus* * Threshold triggered Manual-control* (horiz.) * Controller provides extra panning |
Once again, there are two anchors allowing for a wide forward view in whatever direction the player chooses to go.
However, even as the player starts heading back (which happens constantly in SMW), the camera will keep the target point until Mario hits a predefined threshold, only then will it lock to the other anchor. This is extremely helpful with SMW’s frequent left/right motion that does not warrant a direction change.
Cave Story similarly uses dual-forward-focus to slowly move the focal point from side to side, based on the walking speed.
It’s a bit like what we’ve seen in Bonanza Bros, but in this case, the camera moves toward the new anchor point at all times, speeding up as the player moves.
Cave Story © 2004 Studio Pixel |
Position-locking (vert.)
Dual-forward-focus Physics-smoothing Manual-control* * Controller provides extra vertical panning |
Jazz Jackrabbit 2 is a beautiful platformer from the early days of Epic Games. It has one truly unique camera element: moving the camera away from the player based on their controller input, both horizontally and vertically.
This is a perfect representation of what I call target-focus, where players provide cues on where to shift the camera, based on their actual destination or target.
When you walk left, you want to see more to the left. When the controller is released, the focus centers back on the player.
Jazz Jackrabbit 2 © 1998 Epic Games |
Lerp-smoothing (vert.)
Target-focus – The camera follows the controller input to provide true visual forward focus * Stick/cursor-keys push the focus point in the desired direction Manual-control* * Manual vertical look is an extension of target-focus |
Target-focus can reflect an even more literal visual target, as seen in pointer-controlled games.
In Snapshot, you use the mouse to capture snapshots of elements in the scene and release them elsewhere to complete puzzles. The pointer essentially acts as an extension of your view, and the camera focus is the average position between the player and the pointer.
Snapshot © 2012 Retro Affect |
Target-focus*
* Average between player and pointer Lerp-smoothing |
The Swapper uses some very advanced camera techniques. With regard to target-focus, the cloning device’s target spot serves as a representation of the player’s view and acts as a perfect visual focus.
This works well for any game with individually targeted weapons or devices. Players can even walk backward and still view ahead if they wish, though this versatile camera behavior also requires a secondary control scheme for the camera.
The Swapper © 2013 Facepalm Games |
Target-focus
Physics-smoothing Region-based-anchors Cue-focus Cinematic-paths |
Secrets of Rætikon has plenty of interesting camera features, but in terms of basic framing, it uses projected-focus, which is a simple extrapolation of the character’s position based on its current speed.
Note that this technique may not work well with platforms—especially vertically, where jumps and landing don’t extrapolate well.
Secrets of Rætikon © 2014 Broken Rules |
Projected-focus – The camera follows the projected (extrapolated) position of the player
Physics-smoothingCue-focus** Position and zoom based on attractors Gesture-focus** Certain actions invoke preset camera behaviors, e.g. zoom-out when flying Cinematic-paths |
Luftrausers incorporates some very interesting camera features, with a combination of…
- Focusing on where the plane is pointing to (target-focus)
- Predicting where it’s actually heading (projected-focus)
- Using other cues such as the water, battleships and flying bullets to draw focus while in proximity (cue-focus, see below)
Luftrausers © 2014 Vlambeer |
Target-focus / projected-focus
Physics-smoothing Cue-focus |
Direction
Set up scene cues, context and progression
So far, we’ve looked at how to provide the players with an accurate representation of their view and control, as well as what players generally want to see (Interaction, in our original diagram). We’ve also covered many different ways of making the view comfortable and effective (Comfort).
But, as the directors of our game, we’d also like to draw players’ Attention to what we know is important for them to see—for contextual reasons, to help them progress, or even to add drama or advance the narrative.
Wonder Boy, another one of my favorites, is a high-speed platformer that only allows forward progression using a good old-fashioned one-sided camera-window.
Unlike Super Mario Bros., it has no speedup zone to curb camera acceleration, but it introduces another interesting camera technique which I call camera-path. The camera is placed and moves to foreshadow the game’s upcoming challenges.
Wonder Boy © 1986 Sega |
Camera-path – A predefined progression path throughout the level
Camera-window* * One-sided Static-forward-focus |
3D camera techniques
The field of 3D camera systems is a fascinating and huge subject in its own merit, but 3D support had a vast influence on 2D gaming as well.
The 5th generation of consoles, with PlayStation and N64 (among others), opened up new capabilities backed by better hardware and the inception of true 3D gaming.
Designers could now make use of zooming and tilting, and even combine 2D and 3D into what we now call 2.5D (where the game takes place on a 2D plane, in a 3D world).
PlayStation’s Klonoa is one of those games. The player has basic 2D controls, but the game takes place in an elaborate 3D world.
Klonoa follows a 3D camera-path that provides direction and attention to gameplay and narrative details. This path provides positioning, tilting and zooming throughout all the levels, and actually serves as a hint path onto which forward focus and jumps can be applied.
Klonoa: Door to Phantomile © 1997 Namco |
Camera-path*
* Path hint, actually. Includes zooming and tilting. Camera-window (vert.) Lerp-smoothing Dual-forward-focus |
This type of camera control gives a rich set of tools to enable foreshadowing or, conversely, hide surprises in our games. When the camera in Klonoa zooms out to show the boss, it’s clear what you need to do next.
Donkey Kong Country introduced a tactic which eventually became standard in platformers: provide the level designer with tools to change the camera behavior according to the individual level, and even the content of individual regions within a level.
Faster, runner-style regions require a wide forward view at the expense of being able to see what’s behind the player. Some exploratory regions require a wider view on both sides.
Donkey Kong Country © 1994 Nintendo (Rare Ltd) |
Lerp-smoothing Position-locking (vert.) Region-based-anchors – Different regions (even within levels) set different anchors for position and focus Dual-forward-focus |
As we’ve seen with Klonoa, the technology that enables the presentation of 3D environments can be used to provide various directional tools, such as the use of zoom and dolly.
Zoom is the act of changing the field-of-view angle (FOV), and dolly is the film term for moving the camera forward or backward in relation to the target.
They both achieve the goal of reframing the scene, albeit through a completely different approach, with dolly providing a strong physical presence (where applicable). Film sites and databases will have more information on the differences between dolly and zoom, but for the sake of simplicity, we’ll refer to both techniques as zoom-to-fit.
In Yoshi’s Story, the scene is framed around Yoshi, the boss and the pillar, highlighting both of the elements that require the player’s attention: the target and the end of the field.
The camera not only centers around these elements, it even zooms out (dollies out, actually) to provide the necessary focus.
Yoshi’s Story © 1997 Nintendo (N64) |
Zoom-to-fit – Change zoom or move forward/back to provide a close-up view of relevant elements
Dual-forward-focusCamera-window (vert.) Platform-snapping Manual-control |
Insanely Twisted Shadow Planet has a very influential camera system which takes into account the player’s speed (projected-focus) and target (target-focus).
Most importantly, it’s among the first to use attractors to help focus players’ attention on external cues. Check out ITSP’s blog post for more information on this outstanding camera system.
Insanely Twisted Shadow Planet © 2011 |
Cue-focus* – Focus is influenced by game world cues (e.g. attractors)
* Position and zoom based on double-ring attractors for various cues, such as enemies and checkpoints Projected-focus Target-focus Physics-smoothing Note: Footage taken from the Shadow Planet Productions Blog: ITSP Camera Explained |
ITSP also uses double-ring attractor cues around various game elements, such as checkpoints and enemies. The outer ring gradually shifts the camera focus toward the cue using a weighted average.
When inside the inner ring, the position of the ship is completely ignored, and the camera focuses solely on the cue. Different cues have different rings, and these can overlap, which allows for a smooth shift between different attractors. |
There are different ways of attracting attention to game cues, but ring attractors are a robust way of providing attention to gameplay elements that require them.
They can also be used for the opposite reason: driving attention away from gameplay elements using detractors that repel the camera. These help add a sense of suspense and secrecy around hidden elements.
Aether is a beautiful Flash game made in 2008 by Edmund McMillen and Tyler Glaiel, and it introduces a unique approach to cueing: spinning the world to indicate proximity to a planet. This offers a sense of safety and guidance, where downward inevitably leads to the ground.
As you fly through space and get caught in a gravity field, the screen will start turning toward that gravity element:
Aether © 2008 Armor Games |
Cue-focus*
* Camera orientation shifts with gravity Position-locking Lerp-smoothing |
And no discussion on camera systems would be complete without talking about Limbo. By manipulating exposure, positioning and zooming, it creates a truly unique ambiance.
Every region in Limbo has unique characteristics, anchoring the positioning to a certain spot on the screen and allowing certain objects to provide further camera cues (e.g. attractor objects on enemies).
Limbo © 2010 Playdead |
Region-based-anchors*
* Zoom, position (and exposure) Position-locking* * Changes per region Cue-focus* * Certain actions trigger cues, e.g. enemy attacks, etc. Physics-smoothing |
Another simple yet effective approach is using region-focus, as in Geometry Wars.
It combines the position of the ship with the center of the field. This means that the screen is always moving in the same direction as the ship, but at half the speed.
Players always know where they are in the field by implicitly observing the offset from the center. This system works perfectly with enclosed, limited play fields, especially when threats are more likely to congregate in the center.
Geometry Wars © 2003 Bizarre Creations |
Region-focus* – Focuses on a region anchor (e.g. center of the play field), combined with the player’s position
* Camera position is the average of the ship and the center of the field |
Vessel is a classic puzzle game where the player is required to notice many different elements in order to solve its liquid-based puzzles, making camera regions even more significant.
Just like in Geometry Wars, Strange Loop solved it by giving more emphasis to the regions, keeping the camera almost stationary while working on a puzzle. This is a modern interpretation of the old room-based puzzle games, but in Vessel, the idea of a “room” is much more flexible, with widely varying sizes and characteristics.
One of the most clever ideas in Vessel is that, even when confined to a region, the camera still follows the player with minor movements.
Vessel © 2012 Strange Loop Games |
Region-focus*
* Camera position is based mostly on region anchor point, but shifts slightly as the player moves Region-based-anchors* * Different regions provide different anchor positions and zoom factors Cue-focus Physics-smoothing Cinematic-paths |
This provides a strong sense of control, even when stuck in a small area. Furthermore, as the player solves the puzzle and leaves the region, the camera is already in motion, which minimizes the jarring camera acceleration as it shifts to the next region.
Another way to use the camera to provide attention and drama is by using players’ behaviors to trigger predefined camera gestures.
Tomba is an interesting game, from the first crop of 2.5D PlayStation games. The camera here usually maintains a straight shooting angle, but shifts into different angles when the player performs certain actions, like climbing or moving between depths.
A unique sense of control is achieved when the camera shifts behind the player, while also providing a better view of what’s ahead.
Tomba! © 1997 Whoopee Camp |
Gesture-focus* – Camera gestures are triggered by gameplay
* Camera shifts to positions reflecting gestures and states Dual-forward-focus (horiz.) Platform-snapping Camera-window (vert.) |
Gameplay-triggered gestures can be used in different ways—various motion types and axes, reactive vs. predictive, and so on. I believe that we’re still scratching the surface when it comes to the relationship between player-driven actions and subsequent camera behavior.
A great example of the potential of gesture-focus can be found in indie brawler, Aztez.
It uses different camera gestures such as zooming (moving forward and backward) and tilting to add drama and context to certain fighting events, such as close encounters and final blows.
Aztez © 2017 Team Colorblind |
Gesture-focus*
* Zooming (move forward/back) and tilting triggered by gameplay actions Position-locking (vert.) Lerp-smoothing Zoom-to-fit |
In Sega’s classic brawler Streets of Rage, the camera mostly follows the action using the one-sided camera-window, which is standard brawler behavior.
However, from time to time, the camera steps out-of-screen (or rather, away from the player) to provide additional narrative or dramatic context.
Streets of Rage © 1991 Sega |
Cinematic-paths – The camera suspends normal function to provide an out-of-screen narrative context
Region-based-anchors Camera-window* * Standard brawler behavior: One-sided camera-window, effective between fights only |
This system is very powerful, allowing the designers to provide a cinematic break without interrupting the gameplay context, like a cut-less cutscene.
Cinematic paths are also used effectively in The Behemoth’s Alien Hominid and Castle Crashers.
In many cases, normal gameplay is suspended and the camera shifts toward a boss or story element. This achieves two goals—providing a narrative context as well as gameplay guidance—without drawing players’ focus away from the action.
Alien Hominid © 2004 The Behemoth |
Region-based-anchors
Cinematic-paths Camera-window* * Standard brawler behavior: One-sided camera-window, effective between fights only |
Multi-focal Camera
Focusing on multiple objects
As we’ve seen, even a single focal target presents a considerable challenge. So, how do we address multiple players or targets?
Gauntlet was a groundbreaking dungeon crawler, with advanced technology and an innovative design, for its time.
With multiple players on the screen, it simply locks the camera to their average positions. However, unless all players walk in the same direction, and as soon as the distance between the players reaches the size of the screen, no player can move.
In fact, if a player decides to leave but their character remains in play, everybody is stuck. The other players cannot cross (or push) the edges of the screen.
|
Position-averaging – Focuses on the average position of all targets |
Samurai Gunn uses the same technique, but deliberately pushes it to the edge to form its hectic environment.
This is even further emphasized with the frequent screen freezes and fadeouts. When it comes to the camera, as players frequently respawn or teleport, the average position immediately shifts, causing rapid changes of focus.
In fact, even the basic edge-snapping is avoided, which allows the camera to step out of the level boundaries. This works well with the atmosphere, but can be uncomfortable to watch, especially for spectators.
Naturally, as for controlling your character, players can simply step out of the screen if they so choose—they’re never blocked by the screen edge.
Samurai Gunn © 2013 Teknopants |
Position-averaging
Lerp-smoothing Edge-snapping* * To achieve its hectic atmosphere, edge-snapping is unusually avoided, so the screen is almost constantly moving |
Another approach can be found in good old Street Fighter, and throughout the franchise.
It uses a horizontal camera window which keeps the camera steady for the most part. As with any camera-window, players hitting the window edge will pull the camera with them.
When the camera moves, it may pull the other player with it, keeping all players within the window. The camera (and players) can only be stuck if both try to push the window in opposite directions.
Street Fighter © 1987 Capcom |
Camera-window* (horiz.)
* Hitting the window edge pulls the camera, and may pull the other characters with it |
Another franchise that redefined multiplayer is Nintendo’s Super Smash Bros.
Even the first in the series had an outstanding camera treatment. SSB looks toward the average position of all the players and zooms out as much as needed when the distance between them grows.
Super Smash Bros. © 1999 Nintendo (HAL Laboratory) |
Zoom-to-fit
Position-averaging* * Technically look-to average position Lerp-smoothing |
In the case of ROCKETSROCKETSROCKETS, this system serves a double purpose: fit everything in one frame while also directing players toward the center, punishing them if they try to avoid close encounters.
ROCKETSROCKETSROCKETS © 2014 Radial Games |
Zoom-to-fit
Position-averaging |
As previously shown in Never Alone, you can average the positions of any set of actors, single or multiplayer, possibly providing different averaging weights.
Never Alone © 2014 Upper One Games |
Physics-smoothing Position-averaging
Cinematic-paths Region-based-anchors Cue-focus |
Spelunky takes a different approach to the problem of conflicting positions by focusing on only one player at a time.
If the player dies, the torch (the white flag) is passed to another player. This becomes a secondary gameplay element by actually starting a death countdown for players outside of the screen.
Spelunky © 2008-2012 Mossmouth (Derek Yu) |
Position-locking
Lerp-smoothing Manual-control* * Up/down for extended vertical panning |
Providing additional camera control to the player
In some cases, designers might need to provide additional visual information based on user choices. One way to do this is to tie the camera to the controls.
Super Mario World was, once again, among the first to add extra camera control.
The SNES shoulder buttons push its camera to the respective direction. While this might have been a clever idea, it’s often criticized as useless, and most players don’t notice this feature to begin with.
Super Mario World © 1990 Nintendo |
Region-based-anchors
Platform-snapping* Camera-window* (vert.) * Where applicable Dual-forward-focus* * Threshold triggered Manual-control* (horiz.) * Controller provides extra panning |
The problem with SMW’s additional manual control is its unintuitive nature. The standard walking controls don’t provide any connection with the shoulder buttons.
A better example of providing intuitive manual camera control can be found in Osmos.
Not exactly your standard scroller, Osmos has a much more implicit way of changing the camera. Mouse-wheel on desktops or pinch-to-zoom on tablets provide a clear connection between the control and its action.
Osmos © 2009 Hemisphere Games |
Position-locking
Manual-control* * Mouse-wheel / multi-touch pinch to change zoom |
As seen above, in Jazz Jackrabbit 2, the extra controls for vertical panning perfectly correlate with their horizontal counterparts, and are thus predictable and clear.
Jazz Jackrabbit 2 © 1998 Epic Games |
Lerp-smoothing (vert.)
Target-focus – The camera follows controller the input to provide true visual forward focus * Stick/cursor-keys push the focus point in the desired direction Manual-control* * Manual vertical look is an extension of target-focus |
If manual focus extension is required, use the controls that are already in effect—like in Spelunky, where crouching or looking up shifts the camera focus respectively.
Spelunky © 2008-2012 Mossmouth (Derek Yu) |
Position-locking
Lerp-smoothing Manual-control* * Up/down for extended vertical panning |
Camera Shake
All control is lost
As we’ve seen throughout this research, providing true and clear camera controls invokes a sense of unity between the player and the virtual world behind the screen.
The opposite is also true: a disconnection between the camera and the controls, as achieved by a camera/screen shake, can provide a sense of drama as an action that’s more powerful than the player.
In my research, I tried to find the first game to use the camera shake. It wasn’t surprising to find that it led me to another Miyamoto title, back in 1983: Mario Bros.
The screen shake only occurs in certain versions of the game, probably due to technical or time constraints:
Mario Bros. © 1983 Nintendo |
Screen shakes (and freezes, which achieve a similar effect) have been used in countless games and can be seen in practically all of Vlambeer’s work through the years.
Check out Vlambeer’s designer JW’s talk discussing this feature at length.
Super Crate Box © 2010 Vlambeer |
Custom-Made CameraPutting it all together: Tailoring the camera to your game |
The level of details and attention put in your game is vast. As much as any other element, the camera deserves your attention.
Before you set up the default target-locked camera, try to characterize how you would ideally want your camera to work in your game.
Here are some basic ground rules that served me well when making my own game, and obviously led into this research:
- Find the unique and significant characteristics of your game
- Get inspired by other games facing similar challenges
- Make it your own
Clearly, this does not end at camera work—it can apply to any facet of your game, be it art, audio, tech, and so on.
As one of the first dual-axis platformers, Taito’s The Legend of Kage is a great example of tailoring the camera to the gameplay. (Fun fact: it’s also one of the first, and only, games to make the principal progress direction right to left.)
Note the use of the horizontal camera-window. Many epic battles happen on trees, so the camera window is set to exactly the width of a tree, stabilizing the camera to avoid the rapid direction changes while in battle.
The Legend of Kage © 1985 Taito |
Position-locking (vert.)
Camera-window* (horiz.) * Window size is based on the width of a tree |
Another example of tailoring a system’s design to its game’s unique properties is Shinobi.
To enable its high jumps, it provides a tall camera-window, almost the height of the entire screen. Then, to avoid it drifting off from the center, a slow position-snapping occurs.
Shinobi © 1987 Sega |
Position-snapping (vert.)
Camera-window (vert.) Position-locking (horiz.) Static-forward-focus |
Sonic the Hedgehog is a multi-axis high-speed platformer. The narrow window is designed to keep Sonic in the center of the screen at all times, as the player always needs a clear view of what’s quickly coming ahead.
The window is taller to further limit the vertical motion produced by smaller jumps. This is countered by the use of platform-snapping, which maintains vertical alignment as long as Sonic is on a platform.
Hitting the edge of the window at such high speeds can get a bit jarring at times, especially in loops or when descending to the bottom of the window with full gravitational speed.
However, keeping the window short and narrow minimizes the effect by limiting the possible acceleration that can be achieved while the camera is static.
Sonic the Hedgehog © 1991 Sega |
Platform-snapping
Camera-window Static-forward-focus Manual-control |
When a wide forward view is required but motion is not limited to any direction, dual-forward-view is a natural choice. There are a few different ways to snap the view to the desired anchor following a direction change.
Cave Story dynamically changes the snapping speed based on the player’s walking speed (e.g. base snapping speed plus walking speed).
Bonanza Bros. uses a slightly different method, limiting the movement only to when the player walks—which works for a heist game, but not necessarily for an enemy-packed platformer like Cave Story.
Cave Story © 2004 Studio Pixel |
Position-locking (vert.)
Dual-forward-focus Physics-smoothing Manual-control* * Controller provides extra vertical panning |
Fez doesn’t have armies of enemies coming at you, so a basic camera-window makes sense. But Fez’s designer cleverly repurposed this classic technique to closely fit the unique design of the game.
You could argue that, with corners being a common spot for dimension shifts, what’s behind you is actually more important than what’s ahead.
Furthermore, during a dimension shift, the camera is refocused to provide the maximum forward distance to the window edge, post-dimension shift.
Fez © 2012 Polytron Corporation |
Camera-window (horiz.)
* Also enforced during dimension shifts Position-locking (vert.) Lerp-smoothing Region-based-anchors Manual-control* * Right-stick provides extra panning |
The approach taken in Vessel represents a perfect design solution for a puzzle game that could otherwise be based on one puzzle per room. The use of region-focus to frame (and zoom) the camera around all necessary puzzle elements provides a clear presentation to the player.
The added player-based shifts provide a better sense of control, and ease the camera into motion when moving between regions, achieving a good combination of preset framing with solid perceived control.
Vessel © 2012 Strange Loop Games |
Region-focus*
* Camera position is based mostly on region anchor point, but shifts slightly as the player moves Region-based-anchors* * Different regions provide different anchor positions and zoom factors Cue-focus Physics-smoothing Cinematic-paths |
As we’ve seen, The Swapper tells an elaborate story with its unique atmosphere, achieved by just manipulating the camera across different cinematic paths.
This keeps the player in the game at all times, providing drama while not losing the sense of direction that is sometimes lost with cutscenes.
The Swapper © 2013 Facepalm Games |
Target-focus
Physics-smoothing Region-based-anchors Cue-focus Cinematic-paths |
Mushroom 11The camera choices I’m making |
The camera system in Mushroom 11 is based on meticulous per-region camera direction.
Each level comprises dozens of different regions, and each region has a dedicated rectangular path to which the camera is confined. That area also has a preset zoom (FOV factor).
Mushroom 11 © 2015 Untame |
Region-based-anchors*
* Preset rectangular path and zoom factor per region Position-averaging* Static-forward-focus* Cue-focus* * In applicable regions only Projected-focus Physics-smoothing* * Speed based smoothing-factor |
Regions are carefully ordered, and the camera is controlled by the mushroom piece(s) in the highest numbered region.
As soon as any piece, even a single cell, reaches a higher numbered region, the camera will shift to follow that piece.
Mushroom 11 © 2015 Untame |
Region-based-anchors*
* Preset rectangular path and zoom factor per region Position-averaging* Static-forward-focus* Cue-focus* * In applicable regions only Projected-focus Physics-smoothing* * Speed based smoothing-factor |
Note that the camera borders destroy any cells on touch, which makes the stakes for camera accuracy even higher.
This is illustrated well in the above example, which provides enough room for the player to devise a solution, followed by a quick camera shift as a piece reaches the new region—all achieved without letting the screen edge destroy any significant cell.
Regions come in two major types: Average-Oriented and Progression-Oriented. The region type dictates where the camera tries to focus.
After the focal point is determined, the camera will try to move toward that point while being confined to the region’s rectangular path.
Average-Oriented Region
Some regions use position-averaging between all the cells, naturally focusing the camera toward the larger mushroom piece.
This is effective in areas where the player is required to handle multiple pieces or when there is no single progression direction. It lends itself well to confined puzzle areas, where the pieces remain within acceptable proximity (otherwise they could be hit by the screen edge).
Mushroom 11 © 2015 Untame |
Region-based-anchors*
* Preset rectangular path and zoom factor per region Position-averaging* Static-forward-focus* Cue-focus* * In applicable regions only Projected-focus Physics-smoothing* * Speed based smoothing-factor |
Progression-Oriented Region
Regions with a more linear nature need to focus on the most progressed mushroom.
At any given moment, the most progressed mushroom piece (according to the region’s preset linear progression path) controls the camera, while the pieces left behind are ignored. An additional static-forward-focus distance is then applied, which fits this type of region well.
Mushroom 11 © 2015 Untame |
Region-based-anchors*
* Preset rectangular path and zoom factor per region Position-averaging* Static-forward-focus* Cue-focus* * In applicable regions only Projected-focus Physics-smoothing* * Speed based smoothing-factor |
Cues
Either region type can be used in conjunction with cue-focus.
While controlled by this region, certain objects and creatures can serve as camera attractors, with a specified/dynamic attraction factor. As seen below, boss battles are obvious candidates for this approach.
Mushroom 11 © 2015 Untame |
Region-based-anchors*
* Preset rectangular path and zoom factor per region Position-averaging* Static-forward-focus* Cue-focus* * In applicable regions only Projected-focus Physics-smoothing* * Speed-based smoothing-factor |
Smoothing
Smoothing is done using a combination of projected-focus and physics-smoothing.
What works best is using a smoothing factor that is based on the velocity of the mushroom: if the player moves fast, the camera is accurate (and jumpy); if the player gently trims the mushroom, it cruises gently.
Since there are no jumps in the game, the use of projected-focus is natural. Aiming the camera toward where the mushroom piece (or the average of all pieces) is projected to be in a few milliseconds achieves more accurate predictive behavior.
Mushroom 11 © 2015 Untame |
Region-based-anchors*
* Preset rectangular path and zoom factor per region Position-averaging* Static-forward-focus* Cue-focus* * In applicable regions only Projected-focus Physics-smoothing* * Speed-based smoothing-factor |
Once all these behaviors are defined, the camera system is equipped to handle multiple dynamically changing pieces with different sizes and speeds, moving quickly across regions.
Mushroom 11 © 2015 Untame |
Region-based-anchors*
* Preset rectangular path and zoom factor per region Position-averaging* Static-forward-focus* Cue-focus* * In applicable regions only Projected-focus Physics-smoothing* * Speed-based smoothing-factor |
Glossary
I created all these terms for my own reference, but it’d be wonderful if others find them useful, too. Feel free to suggest improvements to this list or share any of your other thoughts about camera systems in the comments.
Auto-scroll | Player only has no control over scrolling |
Camera-path | Predefined progression path throughout the level |
Camera-window | Push camera position as the player hits the window edge |
Cinematic-paths | Camera suspends normal function to provide an out-of-screen narrative context |
Cue-focus | Focus is influenced by game world cues (e.g. attractors) |
Dual-forward-focus | Player direction changes switch camera focus to enable wide forward view |
Edge-snapping | Set a hard edge for camera positioning |
Gesture-focus | Gameplay triggered camera gestures |
Lerp-smoothing | Continuously reduce the distance between camera and active player using Linear Interpolation |
Physics-smoothing | Camera is a physics enabled entity, constantly closing on the focus target |
Platform-snapping | Camera snaps to the player only as it lands on a platform |
Position-averaging | Focus on the average position of all relevant targets |
Position-locking | Camera is locked to the player’s position |
Position-snapping | Constantly reduce window drift by focusing the camera back on the player |
Projected-focus | Camera follows the projected (extrapolated) position of the player |
Region-based-anchors | Different regions (even within levels) set different anchors for position and focus |
Region-focus | Focus on a region anchor, combined with player’s position |
Speedup-pull-zone | Pull the camera to catch up with player’s speed after it crosses over window’s edge |
Speedup-push-zone | When inside the push-zone, gradually accelerate the camera to catch up with player’s speed |
Static-forward-focus | Extra view space in the principal progression direction |
Target-focus | Camera follows controller input to provide true visual forward focus |
Zoom-to-fit | Change zoom or move forward/back to provide a close-up view of relevant elements |
Thanks!
I want to thank the wonderful independent gaming community for their extensive help in this research, and a special thank you goes to the NYU Game Center for their tremendous support.