Exercise 8 — Point of View

GAME 1303-001 · Unity 6.x · Week 12 — Tuesday, November 10
In class, 10:30 – 11:45 · 2 points · Submit by end of class


The skill

The camera is the only thing the player actually sees. You can build a perfect mechanic in a perfect level and hide it behind a camera that shows the wrong thing at the wrong moment.

Camera work answers three questions:

  1. What can I see? — how much of the world is on screen
  2. What is it about? — what the framing says is important
  3. How does it feel? — tight and tense, or wide and calm

Today you frame the same scene three different ways and discover that camera choice changes the genre of your game without changing a single mechanic.

By the end of the block you will have: one scene, three cameras, a chosen framing, and a written argument for it.


What you need


Part 1 — Set up Cinemachine (15 min)

1. Make a virtual camera

GameObject → Cinemachine → 2D Camera (or Virtual Camera for 3D).

This adds a CinemachineBrain to your Main Camera automatically. From now on you never move the Main Camera directly — you move virtual cameras, and the Brain blends between them.

2. Follow the player

On the vcam, set Follow to your player. Press Play — the camera tracks.

3. Learn the three values that matter

Setting What it does
Dead Zone (Body → Composer/Framing Transposer) A box in the middle where the player can move without the camera moving. Widen this — a camera that reacts to every step is nauseating
Damping How slowly the camera catches up. Higher = heavier, more cinematic. Lower = tighter, more responsive
Lens → Orthographic Size (2D) or FOV (3D) How much world is visible. This is your genre dial

Set Dead Zone Width and Height to about 0.2 and Damping to about 1.0 as a starting point, then move on — you'll tune properly in Part 3.

4. Add a confiner

Add Extension → Cinemachine Confiner 2D. Draw a Polygon Collider 2D around your level bounds and assign it.

Without this, the camera happily shows the empty void past the edge of your level. Every student build has this problem until someone points it out.

✅ Checkpoint 1 — a virtual camera follows the player, with a dead zone and a confiner.


Part 2 — Three framings (25 min)

Make three virtual cameras on the same scene. Give each a different priority so you can switch between them by changing which is highest (or press the play/solo button on each in the Inspector).

5. Camera A — Tight

Orthographic Size roughly half your current value. FOV around 40 in 3D.

The player fills more of the screen. You can see their animation and their expression; you cannot see what is coming. This is a horror camera, or a character-drama camera. Threats arrive without warning, and that is the point.

6. Camera B — Wide

Orthographic Size roughly double. FOV around 80.

You can see the whole room, plan a route, spot the trap. The player is small. This is a strategy camera, or a puzzle camera. Nothing surprises you; the challenge is execution and planning.

7. Camera C — Offset

Back to a middle size, but move the composer's Screen X / Screen Y so the player sits off-centre — say Screen X 0.35 when moving right.

Now you see more of where you are going than where you have been. This is an action camera. Almost every good platformer and shooter does this, and almost no student build does it until this exercise.

8. Record all three

15 seconds of the same section of gameplay through each camera. You will use these in your notes and they make the comparison undeniable.

✅ Checkpoint 2 — three distinct framings of the same scene, all recorded.


Part 3 — Choose and defend (15 min)

9. Play each one for two full minutes

Not ten seconds. Two minutes, actually playing. Camera problems only surface once you stop noticing the camera.

Ask, for each:

10. Pick one and tune it

Choose the framing that serves your game, then tune:

11. Write your notes

Docs/Ex08_notes.txt:

Three framings tested (clips attached):
  A Tight   ortho 4.0,  centred
  B Wide    ortho 12.0, centred
  C Offset  ortho 7.5,  Screen X 0.35 lead

Chosen: C, offset.

Why: my game is about dashing through hazards at speed. On A I died
repeatedly to spikes I never saw — the camera made the game about
reaction time, which is not what my dash is for. B fixed that but the
player became a small dot and the dash stopped feeling powerful.
C gives me ~1.2 seconds of warning at full dash speed, which is just
enough to choose a route but not enough to relax.

Tuned: dead zone 0.3 wide (was 0.1 — camera twitched on every step),
damping 1.4, confiner on a polygon around the level bounds.

What surprised me: the wide camera made my level feel small and empty.
I had built it for a tight camera without realising.

That last line is the kind of observation worth the point. Your camera and your level design are a single decision — most students discover here that they built a level for a camera they hadn't chosen yet.

✅ Checkpoint 3 — one framing chosen and tuned, with a written argument comparing all three.


Part 4 — VR comfort (mandatory for VR track, 10 min)

Skip if you are not on the VR track.

Comfort is graded in this course. The rules are not stylistic:

Rule Why
Never move the camera the player didn't ask to move Camera motion without matching head motion is the primary cause of simulator sickness
No forced head rotation. Ever. Even brief automated rotation makes a meaningful fraction of people ill
Vignette during smooth locomotion Narrowing peripheral vision while moving dramatically reduces discomfort
Snap turn, not smooth turn — or offer both 30° snap increments; smooth turning is the second-biggest sickness trigger
Keep the horizon stable No camera roll, no tilt, no acceleration on the horizon line
Maintain frame rate Below the headset's native rate, comfort collapses regardless of everything else

On PlayerMove3D, set locomotionMode and useComfortVignette, then test in headset for at least five minutes. Distances and speeds that read fine on a monitor are frequently unusable at 1:1 scale.

Record your comfort settings in your notes.


Part 5 — Build and submit (5 min)

12. Build into MyGameName/PC_Builds/Ex08/, then submit

Zip as lastname_ex08.zip: the build, three clips (one per framing), and Docs/Ex08_notes.txt.

Canvas → Assignments → Exercise 8.


Rubric — 2 points

Criterion Pt Met when
Implementation 1 Build runs · Cinemachine virtual camera follows with a dead zone and confiner · three distinct framings built and recorded · no console errors · (VR) comfort settings applied and tested in headset
Design decision 1 One framing chosen with a written argument comparing all three in terms of what the player can see and when · dead zone and damping tuned deliberately

Troubleshooting

The camera doesn't move at all.
The Main Camera needs a CinemachineBrain. Adding a virtual camera usually adds it — check it's there and enabled.

The camera jitters.
Dead zone too small, or damping near 0. Also check your player's Rigidbody2D → Interpolate → Interpolate; a jittery player looks like a jittery camera.

The camera shows blackness past my level.
No confiner, or the Polygon Collider 2D doesn't cover the play area. Note the confiner needs the collider, not a sprite bounds.

The confiner does nothing.
For orthographic 2D you need Cinemachine Confiner 2D specifically, and the bounding shape must be a Polygon or Composite Collider 2D.

My screen shake stopped working.
ScreenShake moves the Main Camera's transform, which Cinemachine now overwrites every frame. Switch to a Cinemachine Impulse Source on the player and an Impulse Listener extension on the vcam.

The camera clips through walls in 3D.
Add the Cinemachine Collider extension to the vcam.


If you finish early


Before next week

Ex 9 — Curves & Locks: health, score, difficulty ramp, and one lock-and-key puzzle.

📘 Your Game Design Doc is due next week in Canvas. If you have been updating it since Week 4, next week is a formatting job. If you haven't, next week is a long night — start now. See assignment-game-design-doc.md.