307. Lesson identity
308. Learning objective
After this lesson, you can use the provided CONTRABAND pointer-lock dialogue case summary to explain why visible choice buttons were not reliably usable and define the mode, access, feedback, and return conditions that a usable alternative must satisfy.
309. Why this matters
A UI element can be visually clear and still be unusable in the current control state. “Add dialogue choices” is incomplete unless the interaction contract states how the player reaches a choice, confirms it, recognizes the resulting change, and returns to play.
This extends the previous HUD-budget lesson. Choosing what to display is not enough: the current mode must also let the player act on that information.
310. Prior knowledge
You should have completed the earlier work on input modes, playable loops, and the HUD budget. You should be able to distinguish displayed information from simulation state and use ACT → RESPOND → CHANGE → AGAIN to inspect an interaction.
311. Provided case summary
This lesson uses the following limited summary of a verified CONTRABAND interaction theme:
- Dialogue choices were presented as visible buttons.
- The surrounding control state used pointer lock.
- While pointer lock remained active, ordinary cursor selection was unavailable, so the visible buttons did not have a reliable pointer-based selection path.
This summary is the complete case evidence supplied for the lesson. It does not establish the original implementation’s DOM focus, keyboard bindings, controller bindings, dialogue-state logic, feedback behavior, or return behavior. Treat those details as unknown rather than inferring them.
312. Core concept
Mode-appropriate UI matches the controls and attention state actually available at the moment of use. A button is not an available choice merely because it is visible, labeled, and clickable under other conditions.
Use the Mode → Access → Choice → Return check:
| Check | Question | Evidence of a usable interaction |
|---|---|---|
| Mode | What control or interaction state is active? | The current gameplay or dialogue state is identifiable. |
| Access | Which input path is available now? | A supported pointer, keyboard, controller, or other path is communicated. |
| Choice | How is an option selected and confirmed? | Selection works consistently and produces a visible response. |
| Return | What happens after confirmation? | The player can identify the new state and knows how control resumes. |
The provided summary establishes a conflict at Access: the buttons implied ordinary cursor selection, but pointer lock made that path unavailable. It does not supply enough evidence to claim what happened at confirmation or return. Those are requirements to verify in a proposed correction, not facts about the original case.
313. Technical clarification
Pointer lock, focus, and application state are related but separate concerns:
- Pointer lock controls relative pointer capture and ordinary cursor availability.
- DOM or keyboard focus determines which page or interface element receives relevant input.
- Dialogue state is application logic that determines whether dialogue is active, which actions are accepted, and how the game returns to normal control.
Releasing pointer lock does not automatically transfer focus, activate dialogue logic, confirm a choice, or restore gameplay afterward. A usable interaction contract must manage and communicate each required transition.
314. Reading the case through a playable loop
Apply ACT → RESPOND → CHANGE → AGAIN:
- ACT: The player needs an available method for selecting and confirming a choice.
- RESPOND: The interface needs to acknowledge the selection.
- CHANGE: The dialogue or control state needs to change visibly.
- AGAIN: The player needs to know which controls are active and how to continue.
A visible button fails as an available choice if the player cannot complete the first step. A proposed correction is incomplete if it repairs selection but leaves feedback or return behavior ambiguous.
315. Interaction contracts
More than one contract can be valid if it satisfies the current mode.
Contract A: explicit cursor-selection state
The dialogue explicitly enters a cursor-selection state, releases pointer lock, establishes the required focus and dialogue state, accepts a button choice, displays confirmation, and explicitly restores the intended gameplay state afterward.
Contract B: communicated non-pointer selection
Pointer lock remains active, but the dialogue presents and supports a clear keyboard, controller, or other non-pointer selection path. The interface displays the current selection, acknowledges confirmation, changes the dialogue state, and communicates how normal control continues.
The lesson does not claim that either contract was used in the original CONTRABAND implementation. They are alternatives for analysis.
316. Common mistake
Do not treat an unavailable input path as a styling problem. Larger buttons, stronger contrast, glow, or animation may improve presentation, but none makes an unavailable cursor usable.
A second mistake is assuming that releasing pointer lock automatically completes the transition. Pointer availability, focus, dialogue logic, feedback, and return to play still need explicit handling.
317. Scored practical response
Use only the provided case summary and the two proposed contracts. Write a short response with the following sections:
- Mode: Identify the documented control state when the choices are shown.
- Access: Explain the documented conflict between the buttons and ordinary cursor selection.
- Choice: State what selection and confirmation behavior your correction must provide.
- Return: State what the player must be able to identify after confirmation. Mark original-case details as unknown where the summary supplies no evidence.
- Rejected fix: Reject one presentation-only change and explain why it does not restore the missing input path.
- Selected contract: Choose Contract A or Contract B and trace it through ACT → RESPOND → CHANGE → AGAIN.
Scoring guide: 10 points
- 2 points — Mode and Access: Correctly identifies pointer lock and the unavailable ordinary cursor path.
- 2 points — Choice and Return: Defines confirmation, visible response, and a legible control state after the choice without inventing original-case behavior.
- 1 point — Rejected fix: Rejects a presentation-only fix for a causal reason.
- 4 points — Loop trace: Gives one accurate point each for ACT, RESPOND, CHANGE, and AGAIN.
- 1 point — Technical distinction: Does not imply that releasing pointer lock automatically manages focus or dialogue state.
A response is successful at 8 points or more, provided it earns at least 1 point in each category.
318. Validation
Before finishing, verify that your response:
- Uses only facts contained in the provided case summary.
- Labels unsupported original-case details as unknown.
- Explains the failure as a mismatch between visible choices and available input.
- Selects one complete interaction contract rather than only changing appearance.
- Separates pointer lock from focus and dialogue state.
- Completes ACT → RESPOND → CHANGE → AGAIN with visible feedback and a clear return state.
319. Key takeaways
- A visible choice is not available unless the current mode provides a reliable way to select it.
- Pointer lock controls relative pointer capture and cursor availability; it does not automatically manage focus or dialogue logic.
- Presentation-only changes cannot restore an unavailable input path.
- A complete interaction contract covers access, confirmation, visible change, and return to a known control state.
- When evidence is limited, distinguish documented facts from design requirements and unknown implementation details.
320. Next lesson
Next: 1.7 — Level design. The same questions about available action, readable feedback, and control state will next be applied to how a simple space teaches movement and interaction.
321. Knowledge check
Answer these items for yourself before reading the answers.
According to the provided CONTRABAND case summary, what failure is documented?
Show answer and feedback
Answer: Visible buttons implied ordinary cursor selection while pointer lock made that input path unavailable.
Why: The supplied evidence establishes the mismatch between visible pointer-based choices and unavailable ordinary cursor selection. It does not document label length or original confirmation and return behavior.
Which statement correctly distinguishes pointer lock from focus and dialogue state?
Show answer and feedback
Answer: Pointer lock controls cursor capture; focus and the application’s dialogue state must be managed separately.
Why: Pointer capture, input focus, and application dialogue logic are separate concerns even when one transition affects all three.
A designer keeps pointer lock active, adds a bright glow to each button, and makes no other change. Why is this insufficient?
Show answer and feedback
Answer: The change improves presentation but does not provide a supported selection path.
Why: Visual emphasis does not restore the missing input path. The contract must support pointer selection or communicate another usable method.
Consider this proposed contract: dialogue begins; pointer lock is explicitly released; dialogue focus and state are established; the player selects an option; confirmation appears; the intended gameplay state is restored. Which analysis best justifies it?
Show answer and feedback
Answer: It creates Access, confirms the Choice with a visible response, produces a Change, and establishes how the player can act Again.
Why: The justification covers the complete interaction contract without claiming that the proposed design describes the original implementation.
Which statements belong in an evidence-bounded analysis of the provided case? Select all that apply.
Show answer and feedback
Answer: Pointer lock made ordinary cursor selection unavailable while visible choice buttons were presented.; A correction must provide a supported selection path and readable confirmation.; Original focus and return behavior should be marked unknown because the supplied summary does not document them.
Why: A sound analysis separates documented facts from requirements for a correction and from unknown original implementation details.