Modes own the device

205. Lesson identity

Module

1.4 — Controls and input

Lesson

Modes own the device

Academic type

Systems

Schema type

Text

Order

1

Estimated time

20–30 minutes

This lesson establishes a system for assigning responsibility for interpreting mouse and keyboard input to explicit modes. The title uses “own” as shorthand: a mode does not own the physical device itself; it is responsible for interpreting selected inputs while that mode is active.

206. Learning objective

After this lesson, you can list two input modes and specify how each mode maps selected mouse and keyboard inputs to game actions and observable results.

207. Why this matters

The same physical input can mean different things in different parts of a game. Moving the mouse might rotate the view during exploration, select an option during a conversation, or produce no game response while a pause screen is open. If these mappings remain implicit, a new feature can cause an inactive handler to react at the wrong time.

A mode table gives you and an AI coding partner a visible contract for interpreting input. It separates what the player physically does from what the active mode means by it and what the player can observe afterward.

208. Prior knowledge

You should be able to describe a player action in ordinary language and identify the mouse and keyboard inputs your game currently uses. The previous lesson, 1.ai-partner L3 — Validate what changed, established the practice of checking behavior against observable evidence.

209. Lesson assumption and boundary

For this exercise, assume that exactly one gameplay or UI mode is active at a time. The mode table covers only inputs delegated to that active mode.

A project may also reserve controls for another explicit owner, such as a deliberately global game control. Browser, operating-system, platform, and accessibility controls are outside this table and should not be suppressed accidentally. This lesson does not expand into layered input architecture, rebinding systems, or platform API implementation.

210. Core concept

An input mode is an explicit boundary for interpreting selected physical inputs in a particular game situation.

Keep these three terms separate:

1. Physical input or event: what occurs on the device, such as pressing E, moving the mouse, or clicking a button.
2. Mode-specific game action: the meaning assigned to that input by the active mode, such as open conversation, advance line, or select response.
3. Observable result: the change the player can perceive, such as a dialogue panel appearing, the next line becoming visible, or no game change occurring.

The active mode is responsible for interpreting only the inputs assigned to it. If neither the active mode nor an explicitly reserved owner handles an input, the intended game result may be no response.

A useful input mode table makes all three levels visible:

The table is a design contract before it is a coding detail. It prevents active and inactive handlers from silently assigning conflicting meanings to the same physical input.

211. Mental model

Use this interpretation test:

INPUT → INTERPRET → RESULT → AGAIN

1. INPUT: Record the physical input, such as a key press or mouse movement.
2. INTERPRET: Identify the active mode and the game action, if any, assigned to that input.
3. RESULT: Record the single observable game result permitted by that mapping.
4. AGAIN: Repeat in the same mode and then after changing modes.

For each selected input, ask:

1. What physical input occurred?
2. Which gameplay or UI mode is active?
3. What game action does that mode assign to the input?
4. What observable result should follow?
5. If the active mode does not handle it, is there an explicitly reserved owner?

If neither the active mode nor a reserved owner handles the input, no game response can be the correct result. This is a deliberate boundary, not evidence that every unhandled platform input should be blocked.

212. Concrete example

Consider a game with Exploration and Dialogue modes. In Exploration, pressing E can map to the game action open conversation when the player is near a character. Once dialogue begins, Dialogue becomes active. Pressing E now maps to advance line, producing a different visible result.

The physical input has not changed, but the active mode maps it to a different game action and result. Mouse movement can similarly map to rotate view in Exploration, while a pointer action over a visible response can map to select response in Dialogue.

This separation prevents the word “action” from ambiguously referring to the key press, the interpreted command, and the resulting game change.

213. AI-native workflow

Use AI as a specification and implementation assistant, not as the authority on control design.

1. Write two modes and their physical-input mappings before asking for code.
2. For each mapping, name the physical input, mode-specific game action, and observable result.
3. Ask the AI to flag duplicate or conflicting mappings, including any inactive handler that might still process the input.
4. Decide which conflicts are intentional, reserved for another explicit owner, accidental, or unresolved.
5. Ask the AI to convert the approved table into a short verification checklist without adding modes, inputs, actions, or results.
6. Perform the INPUT → INTERPRET → RESULT → AGAIN test yourself in both modes and compare observed behavior with the table.

A useful prompt is: “Here is my input mode table. For each row, separate the physical input, active-mode game action, and observable result. Flag conflicting mappings, inactive handlers that might respond, and missing no-response decisions. Do not add controls that are not in the table.”

214. Common mistake

A common mistake is checking the mode in only one input handler while other handlers remain able to respond. The problem is inconsistent enforcement of the design contract, not the mere choice of representation. A boolean can represent two exclusive states correctly if every relevant handler applies the same rule; it becomes unsafe when checks are incomplete or their meanings disagree.

Another mistake is assuming every physical input must produce a game result. An input may deliberately have no game mapping in the active mode, provided that decision is explicit and does not interfere with reserved platform or accessibility controls.

215. Guided practice

Create a two-mode input table for a small game situation. Use Exploration and Dialogue, or replace them with two modes from your own design.

For each mode, record:

• one physical mouse or pointer input;
• the mode-specific game action assigned to it;
• its observable result;
• one physical keyboard input, its game action, and its result;
• one input the mode does not interpret;
• whether that unhandled input has an explicitly reserved owner or produces no game response.

Then make one deliberate decision about a physical input that could have different meanings. For example, decide whether pressing Escape closes dialogue, opens a pause screen through an explicitly reserved owner, or produces no game response in that mode. Record the decision rather than leaving it implicit.

Walk through the table twice:

• once while the first mode is active;
• once after changing to the second mode.

For each walk-through, trace one pointer input and one key input through INPUT → INTERPRET → RESULT → AGAIN. Do not write only “handled.” Name the game action and the observable result, or record that neither the active mode nor a reserved owner handles the input.

Finally, ask: Does each essential UI action have an appropriate non-pointer route, and does this mode leave platform and accessibility controls untouched?

216. Validation / evidence

Your evidence is a completed input mode table with:

• two named modes;
• at least one pointer mapping and one keyboard mapping for each mode;
• a clear separation between physical input, game action, and observable result;
• at least one input that each mode does not interpret;
• one deliberate decision about a physical input with potentially different meanings;
• an explicit active-mode owner, reserved owner, or no-game-response decision where relevant;
• two INPUT → INTERPRET → RESULT → AGAIN walk-throughs, one for each mode;
• a check that essential UI actions have an appropriate non-pointer route and that platform and accessibility controls remain untouched.

The table is valid when another person can predict the game result of each selected input from the active mode without guessing what “action” means. They must also be able to distinguish a deliberate no-game-response decision from accidental interference with controls outside the table.

217. Key takeaways

• A physical input, a mode-specific game action, and an observable result are different things.
• For this exercise, one gameplay or UI mode is active at a time and interprets only its delegated inputs.
• An explicitly reserved owner may handle a control outside the active mode's table.
• If neither the active mode nor a reserved owner handles an input, no game response may be intentional.
• Reliable behavior depends on enforcing the mode contract consistently across relevant handlers, not on a particular state representation.
• A mode table can guide both human implementation and AI assistance.

218. Next lesson

Next: 1.4 L2 — Reproduce before you patch. It follows by converting this mode table into an observed-behavior reproduction: record what each relevant mode and input actually does, without guessing the cause before the behavior has been reproduced.

219. Knowledge check