Shown is not true

280. Lesson identity

Module

1.6 — UI, HUD, and UX

Lesson

Shown is not true

Academic type

Systems

Schema type

text

Order

1

Estimated time

20–30 minutes, including practice

281. Learning objective

After this lesson, you can name one value that could be displayed incorrectly while the simulation remains correct, and identify the simulation value that the display should represent.

282. Why this matters

A HUD is not the game state. It is a claim about the game state made through text, icons, bars, and timing. If that claim is wrong, the player makes decisions from false information even when the underlying simulation is working correctly. This distinction helps you direct AI toward the correct responsibility: preserving the information contract between simulation and presentation.

283. Prior knowledge

You should have completed 1.5 L2 — Camera is not the simulation. You should be able to distinguish authoritative simulation state from camera position and other presentation choices. No code or project edit is required for this lesson.

284. Core concept

An information contract defines what a presentation element claims about the simulation.

The simulation owns the value that is true in the game: for example, the player's current health is 40. The HUD presents an interpretation of that value: perhaps a number, a bar, or a warning state. The presentation can be wrong in several ways:

• It reads the wrong variable.
• It uses an old value.
• It applies the wrong conversion or rounding.
• It labels one value as another.
• It updates at the wrong time.

A correct simulation does not automatically produce a truthful display. The display must preserve the intended meaning of the value it communicates.

285. Mental model

Use this two-column model whenever a display appears suspicious:

Then apply the Stage 1 loop:

ACT → RESPOND → CHANGE → AGAIN

• ACT: The player performs an action.
• RESPOND: The simulation produces a result.
• CHANGE: The authoritative value changes, if the rules require it.
• AGAIN: The player acts again using what the presentation claims.

The loop exposes the contract: after the simulation changes, does the display communicate the same state the player needs to act?

286. Concrete example

Imagine a player has two charges remaining. The simulation stores charges = 2, but the HUD shows 3 because it is displaying the maximum charge count instead of the current count.

• Simulation truth: two charges remain.
• HUD claim: three charges remain.
• Player decision: the player may spend a charge believing another one is available.
• Contract failure: the HUD is showing a related value, but not the value promised by its label.

The simulation can remain fully correct while the player-facing information is false. The first diagnostic question is therefore not “Is the rule broken?” It is “Which value does this display claim to represent, and which value is actually shown?”

287. Common mistake / wrong assumption

A common mistake is treating any visible value as evidence of the underlying state. A health bar that looks full does not prove that health is at its maximum; it may be reading a cached value, using the wrong denominator, or updating late. Do not repair the simulation merely because the presentation is wrong. First identify the value the simulation says is authoritative, then compare the display against the contract.

288. Guided practice

Consider this conceptual loop:

1. The player takes damage.
2. The simulation reduces health from 75 to 50.
3. The HUD continues to show 75.
4. The player decides whether to take another risk.

Write three short answers:

1. Which value is currently authoritative?
2. What exactly is the HUD claiming?
3. Name one possible presentation failure that explains the mismatch.

Make one decision: choose whether the first investigation should target the damage rule or the health display. Choose one and justify it in one sentence using the information contract. The expected judgment is to investigate the display first, because the stated simulation value changed correctly while the HUD claim did not.

289. Validation / evidence

Your evidence is a four-line diagnosis containing:

• one authoritative simulation value;
• one conflicting displayed value;
• one named presentation failure;
• one sentence explaining why the mismatch does not, by itself, prove that the simulation rule is broken.

A strong answer uses a concrete value such as “simulation health is 50, but the HUD shows 75” and identifies the contract being violated: the HUD claims to show current health but communicates an older or incorrect value.

290. Key takeaways

• The simulation is the source of truth; the HUD is a communication layer.
• A display can be wrong while the underlying game rule is correct.
• An information contract states what a UI element claims to represent.
• Diagnose the mismatch before changing the simulation.
• Use ACT → RESPOND → CHANGE → AGAIN to check whether presentation keeps pace with state changes.

291. Knowledge check

292. Related resource / next lesson

Next: 1.6 L2 — HUD budget. The pointer-lock-dialogue resource is placed with that next lesson, not with this lesson.

293. Knowledge check