Skip, recapture, collision

364. Lesson identity

Module

1.8 — Tutorials

Lesson

Skip, recapture, collision

Academic type

Systems

Schema type

text

Order

2 of the module

Estimated time

20–30 minutes, including practice

365. Learning objective

After this lesson, you can identify one risk caused by skipping onboarding and one risk caused by recapturing control between gameplay and another UI or input mode.

366. Why this matters

A tutorial is not only a sequence of messages. It temporarily changes what the player is expected to do, what controls are active, and where attention is directed. A skip action can remove information the next state assumes the player received. A recapture action can also take control at the wrong time or leave the player in the wrong mode. Naming these risks before implementation gives you clearer direction for an AI coding partner and protects the Stage 1 milestone: the player can repeat the game loop without confusion.

367. Prior knowledge

You should have completed 1.1 — Foundations through 1.7 — Core Loop and the previous lesson, What must the player prove? You should be able to describe the Stage 1 loop as ACT → RESPOND → CHANGE → AGAIN and identify the visible change that proves progress.

368. Core concept

Onboarding and ordinary play do not always use the same UI or input mode. Skipping onboarding must preserve a valid destination state, while recapturing control must return the player to the correct mode without stealing input from another active interaction.

Treat a skip as a transition between supported states, not as deletion of text. Treat recapture as a transition into a named control mode, not as a generic command to enable input.

369. Mental model

The mode-boundary check

For every skip or recapture action, ask three questions:

Use the sequence ACT → RESPOND → CHANGE → AGAIN to inspect the result. The player acts on a skip or control request, the game responds, the active mode changes visibly, and the player can act again with the intended controls.

370. Concrete example

Imagine a tutorial that pauses play to explain how to interact with a nearby object.

• During the explanation, a Skip action is available.
• If the player skips, the game must still place them in a state where the object interaction is available and the next objective is legible.
• If the player opens a separate panel before the explanation ends, a generic recapture command could return control to gameplay while the panel still appears active.
• The player may then press a key expecting the panel to respond, while the game interprets it as movement or interaction.

The first failure is a skip risk: the destination assumes onboarding content that the player did not receive. The second is a mode risk: control ownership is ambiguous after recapture. Neither problem requires a complicated feature to diagnose; both become visible when you name the destination, owner, and proof of each transition.

371. Common mistake

A common mistake is to treat “skip” as harmless because it only removes presentation, or to treat “recapture input” as harmless because it only restores control. In practice, both actions change the player’s contract with the game. If the next state or input owner is not explicit, the player can be blocked, confused, or made to trigger the wrong system.

372. Guided practice

Create a two-row failure table for a tutorial you are designing or reviewing. Do not write code. For each row, complete the following fields:

Your table must include:

1. One concrete skip risk, such as the next objective relying on information that was skipped.
2. One concrete recapture or mode risk, such as gameplay receiving input while a panel or dialogue mode still appears active.
3. One visible response for each transition.

Then classify each risk as missing destination context, wrong input owner, or missing transition proof. A row may have more than one classification, but explain which classification is primary.

373. Validation / evidence

Your evidence is a completed two-row table and a short explanation of the primary classification for each risk. You have met the objective when another reader can answer all of these questions without guessing:

• What state follows the skip?
• What state or mode owns input after recapture?
• What visible change proves that the transition occurred?
• What could the player experience if the transition is wrong?

374. Key takeaways

• Skipping onboarding is a state transition, not merely the removal of a message.
• Recapturing control must identify the mode that owns the next input.
• Onboarding can use different UI and input rules from ordinary play.
• ACT → RESPOND → CHANGE → AGAIN helps verify that a transition leaves the player able to continue.
• A useful failure analysis names the destination, input owner, visible proof, and player-facing risk.

375. Next lesson

Continue to 1.9 — Basic economy.

376. Knowledge check