A playtester finishes your platformer and says the jump feels floaty. You spend two days retuning gravity, jump velocity and coyote time, and it still feels floaty. Then you drop the camera's smoothing from 0.35 seconds to 0.12 and the problem disappears. The jump was never the problem. The camera was lagging behind the character on every arc, so the player's eyes were reading a slow rise against a slow-moving background.
Cameras get treated as a programming detail — something to wire up once and forget. In practice the camera is the only mechanic that runs in every frame of your game, and it silently colours how every other system feels. It deserves a spec, default values, and a tuning pass of its own.
Camera problems wear other systems' clothes
The hardest part of camera work is that players never report camera bugs. They report symptoms. Here is the translation table worth pinning above your desk:
| What the playtester says | What is often actually wrong |
|---|---|
| "The jump feels floaty" | Follow damping too high; camera trails the arc |
| "I keep dying to things offscreen" | No lookahead, or deadzone too wide horizontally |
| "Combat feels cramped" | Fixed distance; no pull-back when enemy count rises |
| "It made me a bit sick" | Rotational shake, or FOV that changes too fast |
| "I got lost" | Camera never frames the objective or the exit |
| "The boss is unfair" | Boss framing forces the player to track two things at once |
If you log playtest feedback verbatim — and you should, in a playtesting module or a plain spreadsheet — add a "suspected system" column and allow yourself to write camera there. Half the time the retune is a two-minute value change instead of a two-day mechanics rewrite.
The four knobs that do most of the work
Almost every 2D and third-person camera is made of the same four parameters. Name them in your docs so your team argues about numbers instead of vibes.
1. Deadzone
The rectangle around the character inside which the camera does not move at all. Without one, the camera jitters on every small movement and idle animation. Too large and the character can reach a screen edge before the camera reacts.
Starting points for a 1920x1080 2D game: a deadzone roughly 160 px wide and 120 px tall, centred slightly below the vertical middle so there is more space above the character than below. Asymmetric deadzones are normal — platformers usually want a taller vertical deadzone so small hops don't scroll the screen, and Itay Keren's Scroll Back survey of side-scroller cameras is still the best catalogue of how classic games shaped these windows.
2. Damping
How fast the camera closes the gap once the character leaves the deadzone, usually expressed as a smoothing time. 0.08–0.15 s reads as tight and responsive. 0.3 s and above reads as dreamy, cinematic — or floaty, if your game is about precision.
Use different values per axis. Vertical damping is often slower (0.2–0.3 s) so jump arcs don't yank the view, while horizontal stays snappy. Also consider damping asymmetry by direction: catching up toward the player's facing direction can be faster than falling back.
3. Lookahead
Offsetting the camera ahead of movement so the player sees where they are going. This is the single cheapest fix for "I died to something I couldn't see." Offset the target by a fraction of current velocity — for a character running at 8 units/s, an offset of 1.5–3 units in the movement direction — and ramp it in over ~0.25 s so a quick direction change doesn't whip the view.
Crucially, lookahead should decay when the player stops. A camera that stays offset after the player halts feels off-centre and wrong.
4. Framing overrides
The rules that beat the default follow behaviour: room-bounded cameras that stop at level edges, a pull-back when a fight starts, a temporary point of interest when a door unlocks, a locked axis during a platforming sequence. Celeste's room-based framing is a good mental model — the camera is not one behaviour, it is a default plus a list of named exceptions.
Write these as named states, not as scattered trigger volumes: Default, CombatWide, BossLocked, VistaHold, CutsceneRail. Each gets its own row of parameter values. This is exactly the kind of thing that belongs in your mechanics documentation alongside the movement spec — in GameDesignerX, a camera entry in the mechanics module with a parameter table and the named states keeps designers and engineers editing the same numbers instead of two divergent copies.
Shake that adds impact without adding nausea
Screen shake is the most over-applied camera effect in indie games. Three rules keep it useful:
- Drive it with a trauma value, not with events. Add trauma (0–1) on impact, decay it linearly (about 1.0 per second), and derive the actual offset from trauma squared or cubed. Small hits barely register; big hits feel enormous; overlapping hits don't stack into a seizure.
- Prefer translation over rotation. Rotational shake is a major motion-sickness trigger. If you use it, keep it under about 2 degrees.
- Cap the total. Set a maximum offset in screen percentage — 2–3% of screen height for standard hits — so a chaotic moment never blurs the playfield.
Third-person specifics
If you're in 3D, four more things earn a line in the spec:
- Collision. A spring arm that pulls in when geometry intrudes, with a pull-in that is fast (0.05 s) and a return that is slow (0.4 s). The reverse feels like the camera is shoving you.
- Pitch limits. Clamp to roughly −60° to +70°. Full vertical freedom mostly produces bad screenshots.
- FOV and speed. A modest FOV increase while sprinting (say 70° to 78°) sells velocity, but ramp it over 0.5 s or it reads as a lurch. Always expose a base FOV slider.
- Lock-on. Decide explicitly what happens when the target dies, goes out of range, or is obscured. Undefined lock-on release is a classic source of "the camera fought me" feedback.
A one-hour camera tuning pass
Run this as its own playtest session, with one build and one tester per configuration:
- Disable all shake and post-processing; tune the follow behaviour clean first
- Walk, run, stop and reverse direction on flat ground — check lookahead ramp and decay
- Jump at maximum height repeatedly — check vertical damping doesn't lag the arc
- Fall from your longest survivable drop — can the player see the landing zone?
- Stand at each level's boundary — does the camera clamp cleanly without popping?
- Trigger every named camera state and the transitions between two of them in quick succession
- Re-enable shake; fight the busiest encounter in the game
- Play 10 minutes at your target minimum resolution and on a handheld-sized screen
Record the parameter set that wins as a versioned entry, not as values left in an engine asset. When a build regresses six weeks later, you want a diff, not a memory.
Ship the settings players need
Expose at minimum: camera shake intensity (including 0%), motion blur toggle, FOV slider, invert X and Y independently, and sensitivity separated for horizontal and vertical. These are standard accessibility options now, and they cost far less than the players who bounce off in the first ten minutes.
The camera is the lens every other design decision is seen through. Give it a page in your documentation, four named parameters, a list of states, and one dedicated tuning session — and a surprising number of "the game feels wrong" notes will resolve themselves.