50 Game Camera Mistakes

John Eskil is a field engineer at Back Company who became passionate about improving camera design while developing a game with a dynamic camera for the first time.

Cameras are most noticeable when they fail. Players only discuss cameras to complain when they are distracting, which is why the discipline is often overlooked.

Game cameras differ from cinematography because they must react to player actions and adapt to the situation in real-time, requiring formalized rules of good camera design taught to software.

• Fixed angle third person - camera never rotates, far distance from avatar • Dynamic angle third person - camera on sliding scale between close and far • First person - camera inside the avatar's skull with zero distance

Dynamic third person cameras are the hardest kind to design. Many respected games like Super Mario 3D World and Legend of Zelda Link Between Worlds use fixed camera angles, proving dynamic cameras do not automatically improve games.

Level design and camera design must work together. If the camera angle is known ahead of time, levels can be designed around it. If dynamic, levels must flow gracefully and the camera must navigate the environment effectively.

• Use Euler angles (pitch and yaw) instead of quaternions for camera orientation representation • Store camera position as distance from avatar and offsets rather than global XYZ coordinates • Players think in Euler angles, not quaternions, matching how they control cameras

Programmers often incorrectly assume third person cameras should pivot in place like a human holding a camera. Instead, game cameras should pivot around the avatar like a moon orbiting.

The imaginary line between camera and avatar is crucial for entire camera design. A camera distance that is too far breaks line of sight, making player view obstructed by obstacles.

• Use ray casts called whiskers to detect obstacles approaching line of sight • Preemptively swing camera away from obstacles rather than cutting closer immediately • Cutting violates the 30-degree rule in cinema, creating jarring motion

When player tries to swing camera toward an obstacle while obstacle avoidance pushes away, gradually interpolate camera closer so it squeezes by the obstacle before it blocks view.

Organize constraints by seven degrees of freedom: yaw, pitch, roll, horizontal offset, vertical offset, forward-backward offset, and field of view. Prioritize constraints per axis to avoid cancellation.

Tag obstacles by whether they're allowed to break line of sight. Narrow obstacles like pipes can eclipse the avatar temporarily without requiring camera avoidance since players can track the avatar visually.

Prevent obstacles from colliding into the camera itself using sphere collision detection. If camera touches a narrow column, push it out until no longer touching.

Interpret hills differently from walls. Instead of swinging sideways, raise camera above the hill. Check surface normals or skip collision detection with slopes like sand dunes in Journey.

When line of sight is broken from behind (avatar running toward camera backed into corner), use rear ray cast to detect the problem and pull camera closer without swinging sideways.

The near clipping plane cuts off objects closer to it, leaving gaping holes. Ensure enough space between avatar and walls for camera to fit its near clipping plane through without intersecting the avatar.

Make avatar's collision radius wider than the actual model so they never press against walls, leaving space for the camera to fit between the model and wall.

When looking up, camera swings downward to keep avatar in view but crashes into ground unless distance is reduced. When looking down, pull camera out to avoid feeling claustrophobic.

Create smooth curves that anticipate floor and ceiling shapes, allowing camera to glide smoothly to avatar's feet for worm's eye view rather than abruptly pulling closer.

When looking at the sky, expand field of view to take in more of the large sky at once, matching how humans use peripheral vision to see almost 180 degrees to sides.

• Link distance and field of view changes together during pitch transitions • Derive both from pitch angle so they transition like gears • Prevent appearing to expand then shrink as FOV and distance change

Have base distance and field of view derived from pitch, then allow other factors to apply multipliers or offsets to the base values rather than changing independently.

When pitch, distance, and field of view shift independently, the avatar appears to expand and shrink on screen, creating a disorienting effect.

When line of sight is threatened from the front due to opaque surfaces, the only solution is to cut the camera. This is rare because avatar collision prevents obstacles from hitting line of sight from the front.

Cuts change which direction is forward on the analog stick, disorienting players who cannot instantly adapt. Provide cut scenes, transition effects, or safe situations where players are not in danger during cuts.

• Players use dead reckoning (tracking position and orientation changes) and landmark recognition to navigate • Camera cuts make dead reckoning impossible since rotation amount is unclear • Show recognizable landmarks or navigation cues after cuts to help players maintain sense of direction

In cinematography, don't cut camera to swap character sides. Avoid rotating camera behind characters talking to each other. Less critical in games since cuts should be avoided, but important during cut scenes.

Player needs to see terrain immediately around avatar's feet to detect walls and cliff edges, plus distant landmarks like mountains or partners to maintain orientation.

Many players struggle to control avatar and camera simultaneously. Relying entirely on player camera control results in jerky, unfocused views.

Map player's running direction to camera yaw so it drifts behind the avatar. Use player velocity rather than stick direction since players may be running into invisible walls or dead ends.

If player runs into a wall, don't show them the wall directly. Swing camera around to show where they should be going instead of taunting them with invisible obstacles.

Screens are two-dimensional with weak depth perception. Players judge distances better when motion aligns with the plane of the screen, making camera angle crucial for distance estimation.

For narrow catwalks, point camera directly down the catwalk to align critical distance axis with screen's sideways axis. This lets players better judge how far they are from edges.

• Cast downward rays ahead of avatar to detect drops • Rotate camera pitch to bird's eye view when cliff is detected • Help avatar track what's below while preparing camera to clear the edge

Detect average terrain slope ahead of avatar rather than directly under feet. Apply same pitch-rotation technique for slopes as cliffs, allowing camera to look up or down based on upcoming terrain.

Rule of thirds makes images more attractive with subjects off-center and facing inward. Implement by sliding camera sideways instead of rotating in place, keeping avatar as orbital focus.

Players use screen center to aim analog stick. Off-center avatar confuses players about running direction, so use rule of thirds only when standing still, returning avatar to center during movement.

Different movement types like running, flying, and horse riding take different trajectories through space. Each requires different camera behaviors and player judgment capabilities.

When flying with limited fuel in Journey, camera tilts downward as fuel depletes to show landing zones. Player must always see where they will land, especially when running low on flight power.

Procedural camera behaviors respond to environment shape but don't determine what's important. Game designers must add scripted hints to tell camera which targets matter and should be shown.

Dynamic cameras work well in open areas with few obstacles but struggle in small closed spaces. Scripted hints become more critical to navigate complex geometry and maintain useful framing.

When scripted hint targets nearby objects, avoid constantly rotating to point at them as they move. Instead pull camera back to include multiple subjects in view without rotation, appearing more graceful.

For distant targets like sun or horizon objects, translation cannot change screen position so rotation is necessary. Slide camera sideways or back for nearby targets; rotate for distant ones.

When rotating camera toward target with avatar centered, the avatar itself may eclipse the target. Slide camera to side using rule of thirds or tilt down to see over avatar's head.

Allow players to override scripted hints whenever possible. If hint must override control, ensure camera already shows everything player needs to see, preventing frustration.

• Add delay after player stops controlling camera before scripted hints kick in • Allows player's intended camera direction to remain in place momentarily • Triggers hints after delay ends or player begins moving again

Disable overbearing hints for replayers and experts who know the game. After hints establish player goals, disengage them to allow players to explore new areas and find their own paths.

A significant fraction of players want inverted pitch controls while others prefer standard. This is the only control option in Journey, making it essential for accessibility.

Supporting multiple input methods like analog stick and gyroscope can cause problems. Journey allows both but players accidentally tilt controllers, causing unintended camera swings that should be disableable.

• Linear sensitivity on analog sticks limits fine control • Use S-curve to reduce sensitivity at neutral position for slow camera adjustments • Allow intermediate slow speeds for precise camera tuning

Players often push analog sticks fully deflected. Providing intermediate control speeds would enable finer camera direction adjustments for better precision.

Smooth avatar motion using elastic band approach where camera attracts to avatar position, allowing avatar to drift from center. This smooths jerky movement but requires limits.

• Limit how far avatar drifts from screen center to prevent running off-screen • Set hard limit on distance from center • Monitor avatar position to trigger correction when limit approaches

Camera can look ahead of avatar in direction they're running. Yoshi's Island adjusts camera ahead when player runs in consistent direction for short time.

When camera zooms in on tiny objects, small motions become large on screen exaggerating speed. Zooming in increases apparent motion speed while zooming out makes everything appear slower.

Small field of view causes rapid camera motion and exaggerates speed, triggering simulation sickness in many players. Zooming out reduces perceived motion speed and prevents illness.

• FPS games are most common simulation sickness triggers • Players resolve by expanding default field of view in configuration • Console games should include wider default FOV or configuration option

Rapid field of view shifts like sniper zooming or racing boost effects trigger simulation sickness. First person shooters with scope weapons are particularly problematic.

Screen shake and camera bob are accessibility concerns affecting some players severely while others are unaffected. Provide settings to disable these effects for players with simulation sickness.

Screen shake emphasizes impacts and alongside vibration makes games feel more real. It's widely used for perceived polish but affects players differently, making accessibility essential.

Right amount of shake for one player is too much for another. Some players experience nausea from screen effects while others tolerate them well.

• Bouncing camera with avatar's walk cycle makes motion feel realistic • Camera bobbing is slower longer shake equally likely to trigger simulation sickness • Should be toggleable in accessibility settings

TowerFall includes settings to turn off camera effects, demonstrating best practice. Games should offer tuning down or disabling screen shake and camera bob for affected players.

• Many games lock camera to avatar during jumps creating abrupt stops and starts at takeoff and landing • These sudden motion changes trigger simulation sickness • Mario games wait until landing on higher surface before moving camera

Journey uses rubber band smoothing for rapid vertical motions from jumping to prevent sickness-inducing jerks.

Fast smooth camera transitions between positions, common in 3D Zelda games, create jarring sense of motion mimicking cuts. They violate spirit of no-cut rule.

Anticipate reaching pitch limits and slow camera down as it approaches rather than maintaining speed until abrupt stop. This prevents jarring movement.

• Euler angles suffer gimbal lock when looking straight up and down • Set limits to prevent reaching gimbal lock angles • Prevent player from looking straight up or down

Slow camera down as pitch approaches limits rather than rapid movement until abrupt stop. This creates smoother feel when reaching maximum up or down tilt.

As games get more lifelike, they trigger simulation sickness more because motion seen on screen mismatches actual motion felt. VR headsets face particular challenges with motion sickness.

Don't make games exclusively for Oculus Rift or other VR platforms. Ensure alternative play methods exist because some players cannot play VR games now or in the near future.

Test with children and people unfamiliar with you, as they will point out flaws and criticize frankly. Some testers with simulation sickness don't want to admit it, feeling like weakness.

• Pry gently with testers to surface simulation sickness issues • Create comfortable environment for honest feedback about problems • Prevent customer illness by prioritizing comprehensive testing feedback

Don't write general constraint solver that evaluates all constraints and optimizes for best angle. This approach is almost never right because results become unpredictable and undesignable.

Deeply understand relationships between camera constraints to prioritize them effectively. Predictable changes to behavior enable iteration and design refinement, unlike computer-optimized solutions.

Solutions that work for Journey may not work for other games. Use this 50-item checklist as criteria to evaluate camera solutions rather than as prescriptive rules.

Developers must conduct their own research and development on camera systems. The list serves as starting point and evaluation framework, not replacement for custom iteration.

• Avoid unnecessary dynamic cameras when fixed angles suffice • Preserve line of sight between camera and avatar • Support player control overrides and accessibility options • Test with diverse demographics including children

Game developers will need to apply many same research and development processes to their own projects. Success requires iteration and understanding of specific game context.