What must the player see?

251. Lesson identity

Module

1.5 — Camera

Lesson

What must the player see?

Academic type

Concept

Lesson type

Text

Order

1

Estimated time

20–30 minutes

This lesson establishes a camera-design habit: describe the player-facing purpose of a moment before selecting a camera system or implementation.

252. Learning objective

After this lesson, you can write one precise camera-intent sentence stating what the player must see or notice during a specific game moment, then test and revise that sentence after one condition changes.

253. Why this matters

A camera is not only a Transform component associated with a character. Its framing can direct and prioritize attention, support spatial understanding, and affect when information becomes readable. If the intent is unclear, a developer or AI assistant can produce a technically functional camera that presents the wrong information.

A short intent sentence gives later framing, tuning, and testing a shared target. It also makes the course loop useful as a design inspection: after changing one condition, you can ask whether the view still supports the intended player decision.

254. Prior knowledge

You should already be able to distinguish pointer-lock camera control from clickable choice interaction, as covered in 1.4 L3 — Pointer Lock vs. Clickable Choices. You also need a basic description of a game moment: who is acting, what changes, and what information the player may need.

You do not need camera code, projection settings, or camera-system terminology for this lesson.

255. Core concept

Camera intent is the player-facing purpose of the view in one specific moment.

Intent comes before implementation. It describes the information the view must prioritize and preserve, not the mechanism used to produce the view.

A useful intent sentence answers four questions:

1. Moment: When does this view apply?
2. Primary subject or change: What must the player notice first?
3. Necessary context: What surrounding information must remain readable?
4. Supported decision or action: What can the player decide or do with that information?

Use this pattern:

During [moment], the player must see [primary subject or change] while retaining enough view of [necessary context] to [make a decision or perform an action].

Avoid beginning with implementation language such as “Use a third-person follow camera” or “Set the field of view to 70.” Those may become possible solutions later, but they do not state the player-facing problem the camera must solve.

256. Mental model: an attention contract

Treat a camera intent as an attention contract between the game and the player:

The contract does not guarantee where every player will look, nor does it require every object to remain visible. It identifies which information deserves priority for a particular decision.

257. Testing the intent

Use the course loop as a design inspection:

ACT → RESPOND → CHANGE → AGAIN

• ACT: Describe or stage the moment.
• RESPOND: Identify what the player should be able to notice and decide.
• CHANGE: Alter one scene or viewing condition.
• AGAIN: Check whether the same intent still identifies the right priority and context.

The words of the loop are less important than the decision it supports: keep the intent if the information requirement remains valid, or revise it if the changed condition creates a different requirement. At this stage, you are testing a sentence, not building a camera system.

258. Concrete example

Imagine a small room with a locked exit on the far wall. The player activates a console, starting a short countdown.

An implementation statement would be:

Switch to an over-the-shoulder camera.

A player-facing intent would be:

During the countdown, the player must see the console’s changing state while retaining enough view of the locked exit to decide whether to remain at the console or move away.

This sentence creates useful constraints without prescribing a camera system. A close framing might make the console readable but hide the exit. A wide framing might preserve the exit but make the console state too small. The intent tells you what information to compare when evaluating those alternatives.

The sentence also establishes a priority. The changing console state is the primary subject; the exit is necessary context. Other room details may be visible, but they are not part of this moment’s requirement.

259. Diagnosing an incomplete intent

Consider this sentence:

During the countdown, the player must see the console.

It names a moment and subject, but it is incomplete. It does not identify the necessary context or explain what decision the view supports. A useful revision adds both:

During the countdown, the player must see the console’s changing state while retaining enough view of the locked exit to decide whether to remain or move away.

When revising an intent, add only information needed for the decision. Do not turn the sentence into a list of every visible object.

260. Common mistakes

Prescribing a solution

The camera should follow the player from behind with a narrow field of view.

This specifies construction and parameters without explaining what the player needs to notice.

Covering too much time

Throughout the whole level, the player must see every threat and objective.

Camera intent is more useful when attached to one moment, such as entering a room, reading a choice, spotting a threat, or choosing a route.

Omitting the supported decision

When the door opens, the player must see the room.

“See the room” does not establish a priority or explain what the information enables. Name the relevant subject, context, and decision.

Depending on one sensory channel

If a decision depends on a threat cue, directional audio should not be the only way to identify it. A moving silhouette, caption with direction, or directional threat indicator can provide equivalent information. The camera intent should name the visual information that the view must preserve rather than expecting the camera to communicate information available only through sound.

261. Guided practice

Use this moment:

The player opens a door into a dim storage room. A threat moves on the left. Its location is communicated through a moving silhouette and a directional threat indicator, accompanied by a moving sound and a caption. A usable light switch is on the right. The player must decide whether to investigate the threat or turn on the light first.

Write one camera-intent sentence using this pattern:

During [moment], the player must see [primary subject or change] while retaining enough view of [necessary context] to [make a decision or perform an action].

Before writing:

1. Name the exact moment.
2. Choose the information that should receive priority: the indicated threat, the light switch, or a meaningful relationship between them.
3. Identify the context that must remain visible for the alternative action.
4. Name the decision the view supports.
5. Combine those parts into one sentence without prescribing a camera system, distance, field of view, or code change.

One defensible answer is:

When the player enters the dim storage room, the player must see the indicated movement on the left while retaining enough view of the light switch on the right to decide whether to investigate or turn on the light first.

Another priority may be defensible if the sentence explains why it supports the same decision. The goal is not to copy the example but to make the information hierarchy explicit.

262. Change test

Now change exactly one condition. For example:

• the light switch moves behind a shelf;
• the threat indicator appears only after the player crosses the doorway; or
• the moving silhouette becomes visible before the door is fully open.

Ask:

• Is the original primary subject still the right priority?
• Is the necessary context still available at that moment?
• Does the sentence still support the same decision?

If all three answers remain yes, keep the sentence. If the change alters the information requirement, revise the sentence. Do not revise it merely because a different implementation might be convenient.

263. Validation and required evidence

Submit exactly two artifacts:

1. Camera-intent sentence: one sentence naming the specific moment, primary subject or change, necessary context, and supported player decision or action. Submit the revised version if your change test required a revision.
2. Change-test note: a brief note naming the one condition you changed and stating whether revision was necessary. If it was necessary, identify what information priority or context changed.

Your submission is valid if:

• the intent covers one specific moment;
• it establishes a primary subject, change, or piece of information;
• it identifies necessary context;
• it connects the view to a player decision or action;
• it does not present a camera system, field-of-view value, distance, parameter, or code change as the intent;
• the change-test note names one altered condition; and
• the note clearly states whether the intent remained valid or required revision.

264. Key takeaways

• Camera intent describes what the view must help the player notice and why.
• Framing can direct and prioritize attention, but it cannot guarantee where every player looks.
• A useful intent identifies one moment, a primary subject, necessary context, and a supported decision.
• Intent comes before camera systems, Transform values, and tuning parameters.
• Test the sentence after changing one condition, and revise only when the information requirement changes.

265. Next lesson

Next: 1.5 L2 — Camera Is Not the Simulation. Bring your completed camera-intent sentence forward as the player-facing view requirement. The next lesson will use it to distinguish what the camera must show from the pawn or simulation state.

266. Knowledge check