Camera is not the simulation

267. Lesson identity

Module

1.5 — Camera

Lesson

2

Academic type

Systems

Schema type

text

Title

Camera is not the simulation

Estimated time

20–30 minutes, including practice

This lesson installs a three-part ownership boundary: the input owner receives and describes the player's request, the simulation owner determines what is true about the pawn, and the view owner determines how that truth is shown.

268. Learning objective

After this lesson, you can assign a player request, an authoritative pawn state, and a camera presentation decision to the correct owner, then explain how the camera should respond when the pawn's state changes.

269. Why this matters

A camera is a view of game state, not the source of that state. Input also should not become the state itself: a player's request to move is different from the simulation deciding whether and where the pawn moves. Keeping input, simulation, and view responsibilities distinct makes behavior easier to inspect and gives you more precise instructions for AI. This boundary prevents a presentation system from becoming a hidden authority over gameplay state.

270. Prior knowledge

You should have completed 1.5 — ¿Qué debe ver el jugador? and be able to state the player-facing purpose of a view for a moment. You also need the Stage 1 loop language: ACT → RESPOND → CHANGE → AGAIN.

271. Core concept

The input owner receives the player's action through a control and identifies the request being made. It can say, for example, “the player requested movement toward the doorway.” It does not decide whether the pawn actually moves.

The simulation owner determines the authoritative game state. For a pawn, that can include position, velocity, health, and whether an action is allowed. It evaluates the request and determines what becomes true: perhaps the pawn moves, stops at a wall, or remains in place. Any authoritative state change in the loop belongs to the simulation owner—not to the camera.

The view owner decides how that state is framed, followed, emphasized, or temporarily obscured for the player. The camera may read the pawn's position and adjust its framing. It should not silently become the authority that decides where the pawn exists in the simulation, nor should it change the pawn's state to make a presentation easier.

A useful boundary is:

• Input owner: “What request did the player make?”
• Simulation owner: “What is true about the pawn after that request?”
• View owner: “How should the player see that result?”

The boundary is about responsibility, not necessarily about which file or component contains the code. A single script can contain more than one responsibility, but the decisions must remain distinguishable.

272. Mental model

Use the three-owner chain:

Player action  →  Input owner  →  Simulation owner  →  View owner
(request)         identifies       changes what is true    presents the result

For each event, ask three questions:

Then test the boundary through the Stage 1 loop. The loop is not saying that the camera creates the change; it identifies where to inspect the responsibilities:

1. ACT: The player makes an action.
2. RESPOND: The input owner identifies the request, and the simulation owner evaluates it.
3. CHANGE: The simulation owner establishes any authoritative change in pawn state. The view owner then adjusts presentation so that result is readable; it does not create or authorize the pawn change.
4. AGAIN: Repeat from a new position or situation and check whether the simulation remains the owner of state changes.

273. Concrete example

Imagine a small third-person room with a pawn, a doorway, a blocking wall, and a camera that follows from behind.

• The player requests movement toward the doorway. That request belongs to the input owner.
• The simulation evaluates the request and determines that the wall blocks the path, so the pawn remains at its current position. That authoritative result belongs to the simulation owner.
• The camera pulls back slightly so the doorway remains visible. That framing decision belongs to the view owner.

The important distinction is that the simulation owns the unchanged position as well as a changed position. The camera does not cause the pawn to remain in place, and it does not move the pawn to improve the composition.

If the player later requests movement away from the doorway, the input owner identifies the new request. The simulation decides whether the pawn changes position and owns that state change if it occurs. The camera observes the resulting state and may revise its framing. The camera does not move the pawn, and the input layer does not declare that movement succeeded.

If a wall obstructs the camera, the view owner can shorten the camera distance, shift the angle, or choose another clear placement. The pawn's collision with the room remains a simulation decision. A camera adjustment must not teleport the pawn to solve a camera problem.

274. Common mistake

A common wrong assumption is: “The player pressed a movement control, so the pawn moved, and the camera should follow the input.” The input owner only identifies a request. The simulation owner decides the authoritative result and owns any state change. The view owner presents that result.

Another common mistake is: “If the camera follows the pawn, the camera owns the pawn.” Following is observation plus presentation. The camera can use the pawn as a target while the simulation remains the owner of the pawn's position and of every authoritative change to that position.

275. Guided practice

Complete the ownership table for this situation: the player requests movement toward a doorway, a wall blocks the path, the pawn remains in place, and the camera pulls back slightly to reveal the doorway.

Then make one design decision: choose whether the camera should follow tightly, maintain a wider framing, or shift to reveal the doorway. Write three short sentences:

1. What request did the input owner identify?
2. What state change, or lack of state change, did the simulation owner establish?
3. What does the view owner change, and what must it leave unchanged?

Run the thought experiment through ACT → RESPOND → CHANGE → AGAIN. On the first pass, identify the simulation decision as the owner of the pawn's state change or unchanged state. On the second pass, change one condition: the player requests movement away from the doorway. Check whether the simulation still owns the resulting pawn state and whether the view owner only changes presentation.

276. Validation / evidence

Your evidence is a completed ownership table and a three-sentence ownership explanation. It passes when:

• the player's movement request is assigned to the input owner;
• blocking, permission, and the pawn's authoritative position are assigned to the simulation owner;
• any authoritative pawn state change is explicitly assigned to the simulation owner, not the camera;
• framing, distance, angle, and visibility choices are assigned to the view owner;
• the explanation distinguishes a request from the resulting pawn state and from its presentation;
• the camera responds to changed state rather than creating or authorizing that state; and
• the three-owner separation remains intact after the second pass through ACT → RESPOND → CHANGE → AGAIN.

277. Key takeaways

• The input owner identifies what the player requested.
• The simulation owner determines what becomes true about the pawn and owns authoritative state changes.
• The view owner determines how that truth is presented.
• A camera may observe position without owning position.
• A request, a simulation result, and a view response are different responsibilities.

278. Next lesson

Continue to 1.6 — UI, HUD, and UX.

279. Knowledge check