Pixel Camera - 2D rig that stays on the grid

Give an orthographic camera this component and it follows your player without ever landing between pixels.
It does five things every frame, and the order is the whole design. It aims at the target – or at the weighted centre of several. It moves that aim point only as far as leaving the dead zone requires. It eases towards it, frame-rate independently. It clamps the visible rectangle inside the current room or map. Then it adds shake and rounds the result onto the pixel grid.
Snapping last is not a detail. Snap before clamping and the camera can end a frame a pixel outside the map. Snap before easing and the easing quantises into a stutter, because a frame that should move the camera a third of a pixel moves it either none or one. The unrounded position is kept in a field and only the rounded one is ever written to the transform, so rounding error cannot accumulate – and parallax layers have a smooth number to read instead of a staircase.
This package is complete. No trial, no watermark, no time limit, source included.

THE CAMERA IS SNAPPED AND MY ART STILL SHIMMERS
This is the most common thing people ask about, and the camera is almost never the cause. There are three culprits, and this package handles all three.
Your player is between pixels. A sprite parked at x = 1.4703 does not become sharp because the camera is exact; what gets sampled is the difference between the two. Put the SpriteRenderer on a child and add Pixel Snap Visual to it: the child is rounded, the parent keeps the true position your movement code and your Rigidbody2D own. Snapping the player's own transform instead is the obvious fix and the wrong one – a body whose position is rewritten every frame fights the solver.
Your Rigidbody2D is not interpolating. Physics steps fifty times a second and the screen draws more often, so with Interpolation set to None the body holds still for a frame and then jumps, and a faithful camera reproduces the jump. The inspector looks at your target and tells you, with a button that fixes it.
Your parallax layers are computed from a rounded camera. A factor below one applied to a staircase gives a staircase with uneven steps. Pixel Parallax Layer reads the rig's unrounded position and rounds once, at the end, against the same grid.
And the editor window scans your whole open scene, lists every sprite that is off the grid with the size of its error, and snaps them all with one press.

ROOMS ARE RECTANGLES, NOT COLLIDERS
Tick Use Rooms, drop Pixel Camera Room components in, and drag their corners out in the scene view. The rig frames the smallest room the target is standing in, so a side chamber drawn on top of a hall wins.
Each room chooses how the camera arrives: a cut, a glide at the usual half-life, or Slide Seconds – a straight move over exactly that long, which is the screen-by-screen transition of a top-down classic, the one where the player is held still for precisely as long as the screen takes to move. Easing is the wrong tool there, because easing never quite arrives.
The collider-and-trigger way has four failure modes that cost people an evening each: an unassigned shape fails silently, a shape whose object starts inactive builds an empty cache, the cache has to be invalidated by hand after a zoom change, and damping lets the camera drift outside the shape before it is pulled back. A serialised rectangle has none of those, needs no physics module at all, and costs two comparisons to test.

THE DEAD ZONE, AND WHY EXIT-CENTRING LURCHES
While the target is inside the dead zone the camera does not move at all – a character who turns around, jumps, or paces two steps either way should not drag the entire screen with them. When the target leaves, the camera moves just enough to put it back on the edge, not to centre it. Centring on exit makes the camera travel half the dead zone in one go, every time the line is crossed, and the lurch arrives exactly when the player is trying to read the screen.

THE ROOM THAT IS SMALLER THAN THE SCREEN
When the map is narrower than the view on an axis there is no position that satisfies both edges at once. Clamping in the usual order snaps to whichever edge is tested last, and the room appears to jump sideways as the player moves. This rig centres that axis instead – the only answer that looks deliberate, and what a one-screen room wants anyway.

WHAT AN ULTRAWIDE MONITOR SHOWS FOR FREE
A level composed for 16:9 opens up on a 21:9 monitor and hands the player a view they were not meant to have yet: the boss waiting past the door, the corridor's dead end, the seam where the tileset stops. Unity's own advice is to compose for the narrowest ratio and let wide screens see more, which is no advice at all for a game built out of rooms.
Set Max Visible Width to the number of art pixels the widest screen may show. The camera pillarboxes past that, centred, and the composition holds on every monitor. Max Visible Height does the same vertically, and Respect Safe Area keeps the picture clear of a phone's notch.

SEVERAL TARGETS, AND ZOOM THAT FITS IN WHOLE STEPS
Fill Extra Targets and the aim point becomes the weighted centre. Tick Zoom To Fit and the rig steps the zoom out in whole numbers until everything is on screen. Whole steps rather than a smooth scale: a continuous zoom-to-fit spends the entire transition at fractional zoom, which is the state this package exists to avoid.
And it does not pump. A plain fit walks straight into that bug: two players drift apart and cross the exact distance at which zoom 3 stops fitting, the fit says 2, the camera zooms out – and at zoom 2 they fit at 3 again, so the screen pumps in and out several times a second. Here, zooming out happens at once, because the alternative is a target off screen; zooming back in waits for a margin of slack and then moves one step.

LOOK AT SOMETHING ELSE FOR A MOMENT
rig.FocusOn(theDoorThatJustOpened, 1.5f); – the camera frames that instead and eases back on its own when the time runs out. The dead zone, the bounds and the rooms all keep working against the new point, and there is no state to unwind afterwards. The thing every game needs twice and nobody wants to write a state machine for.

SHAKE IN WHOLE PIXELS, AND A PUNCH
Add trauma from your own code and forget about it: Shake(0.6f). It drains by itself, and it adds rather than sets, so three quick hits build instead of the third cutting the second short. The amplitude is trauma squared, so a hit arrives hard and leaves quietly.
There is no rotational shake, on purpose. Rotating an orthographic camera by a degree and a half puts every sprite edge at an angle the pixel grid cannot express. The offset is rounded to whole art pixels before it is applied, so a shake can never be the thing that puts the camera between them.
On top of the noise there is a directional punch: rig.Punch(awayFromTheHit, 0.7f). Noise says "something happened"; a punch says "something hit you from over there". With noise alone, a bullet from the left and a mine underfoot look identical. Noise and punch are summed and rounded once, together, so the pair still lands on a whole pixel.
And the shake runs on unscaled time by default, so a hit-stop that freezes Time.timeScale does not freeze the shake with it – which is the opposite of what the freeze is for. The follow stays on scaled time: the world has stopped, so the camera should stop chasing it.

SPLIT SCREEN
The rig sizes itself from its own camera's viewport rather than from the whole window, so two cameras each owning half the screen both show the right amount of world at the right zoom. Sizing from the window instead – which is what most camera scripts do – shows a half-height camera twice as much world as it should, and it is invisible until the day you add a second player.

WHAT THIS DELIBERATELY DOES NOT DO
Sub-pixel scrolling – rendering the world into a low-resolution target and drawing that target one sub-pixel off, so the camera glides while the art stays crisp – is not in here. It is a real technique and it looks lovely. It also needs a render target sized to the pipeline in use, a blit that differs between the built-in pipeline and URP, and it fights parallax layers and screen-space UI, which are drawn at full resolution and so do not glide with it. This package is built the other way round: everything in it works in any pipeline with nothing installed. If you need sub-pixel scrolling, Unity's own Pixel Perfect Camera with Upscale Render Texture is where to start, and this rig will still do the following and the framing underneath it.

THIS AND UNITY'S PIXEL PERFECT CAMERA
They are not the same job and they do not fight. Unity's component handles the upscale: it sets orthographic size and can render to a low-resolution target. It does not follow anything, and it has no dead zone, no bounds and no shake. This rig handles the movement, and sets orthographic size itself so it works with no packages installed at all.
One pairing is worth knowing about: Upscale Render Texture together with a smoothly eased follow is the combination people report as jitter. The inspector notices that component and says so.