Exercise 8 — Point of View
GAME 1303-002 · Unreal Engine 5.8 · 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:
- What can I see? — how much of the world is on screen
- What is it about? — what the framing says is important
- 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
- Your own game project, with a level you can play
- No extra plugin needed — Spring Arm, Camera, and Cine Camera Actor are built in
- VR track: your headset, reserved in advance. Part 4 is mandatory for you.
Part 1 — Set up Cinemachine (15 min)
1. Set up the camera rig
On BP_Player: Add Component → Spring Arm, then Add Component → Camera as a child of the Spring Arm.
The Spring Arm is the whole rig. It handles distance, lag, and collision, and you will almost never move a Camera component directly again.
2. Configure it to follow
On the Spring Arm:
- Target Arm Length — how far back the camera sits
- Use Pawn Control Rotation ✔ for 3D · ✘ for a fixed side-on 2D view
Press Play — the camera tracks.
3. Learn the three values that matter
| Setting | What it does |
|---|---|
| Enable Camera Lag + Camera Lag Speed | How slowly the camera catches up. Low speed = heavier, more cinematic. High = tighter, more responsive |
| Camera Lag Max Distance | A cap so fast movement never outruns the frame — Unreal's closest equivalent to a dead zone |
| Camera → Field of View (or Ortho Width in orthographic) | How much world is visible. This is your genre dial |
Set Camera Lag Speed to about 10 and Max Distance to about 100 as a starting point, then move on — you'll tune properly in Part 3.
4. Stop the camera showing the void
Enable Do Collision Test ✔ on the Spring Arm so the camera never pushes through geometry.
For level bounds, place Blocking Volumes just outside the play area, or clamp the camera's location in the Player Controller. Without one of these, 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 camera setups on the same level. The easiest way to compare is three Cine Camera Actors placed in the level, switched with Set View Target with Blend — or simply change the Spring Arm values between takes and record each.
5. Camera A — Tight
Target Arm Length roughly half your current value, or FOV around 40.
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
Target Arm Length roughly double, or 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 length, but set the Spring Arm's Socket Offset so the player sits off-centre — say Y +200 when moving right (or use Target Offset to lead the movement direction).
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:
- Did I die to something I couldn't see? (too tight)
- Did the level feel empty or slow? (too wide)
- Did I have to move before I could see where to go? (offset wrong way)
- Did I feel sick? (damping too low, or dead zone too small)
10. Pick one and tune it
Choose the framing that serves your game, then tune:
- Widen the dead zone until the camera stops twitching on small movements
- Raise damping until it feels heavy, then back off until it stops feeling laggy
- Set the confiner so the void is never visible
11. Write your notes
Docs/Ex08_notes.txt:
Three framings tested (clips attached):
A Tight arm 300, centred
B Wide arm 1200, centred
C Offset arm 700, socket offset Y +200 (leads movement)
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: camera lag speed 8 (was 20 — camera twitched on every step),
lag max distance 120, collision test on, blocking volumes at the 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 BPC_PlayerMove3D, set LocomotionMode and UseComfortVignette (drive a post-process vignette from movement intensity), 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. Package 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 | Packaged build runs · Spring Arm rig follows with lag configured and collision testing on · three distinct framings built and recorded · no blueprint or output-log 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 · camera lag and offset tuned deliberately |
Troubleshooting
The camera doesn't move at all.
The pawn isn't possessed, or the Camera component isn't a child of the Spring Arm. Check Auto Possess Player → Player 0.
The camera jitters.
Camera Lag Speed very high with a low Max Distance, or the character movement itself is stuttering. Check Enable Camera Rotation Lag separately from location lag.
The camera swings wildly around corners.
Do Collision Test is pulling the arm in when it hits geometry. Reduce Probe Size, or move the probe channel to one that ignores small props.
The camera shows blackness past my level.
Add Blocking Volumes outside the play area, or clamp the camera location in your Player Controller.
Camera shake stopped working.
Start Camera Shake runs on the Player Camera Manager. If you switched view target to a Cine Camera Actor, the shake applies to the manager's active view — re-check which camera is actually active.
In orthographic mode everything looks wrong.
Unreal's orthographic support is less forgiving than Unity's. Set Ortho Width rather than FOV, and expect to adjust near/far clip planes manually.
If you finish early
- Add a second Cine Camera Actor triggered by a
BP_TriggerZoneusing Set View Target with Blend (blend time 0.5). That's a cutscene camera in about two minutes. - Try camera lead: scale Socket Offset with the character's velocity. It is subtle and it is what makes fast games readable.
- Push Target Arm Length to an extreme in both directions and note where the game stops being your game.
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.