Reproduce before you patch

220. Lesson identity

Module

1.4 — Controls and input

Lesson

Reproduce before you patch

Academic type

Debugging lab

Schema type

Practical

Order

2 in the module

Estimated time

About 30 minutes, including assessment

221. Learning objective

After this lesson, you can write a precise reproduction in player steps that records relevant execution context and observed behavior without guessing the cause.

222. Why this matters

An input report is evidence, not an explanation. If you patch the first suspected cause, you may change the wrong mode, action, or device path. A reliable reproduction provides a stable starting point for investigation: another person should be able to perform the same action in the same relevant context and check the same result.

223. Prior knowledge

You should have completed 1.4 L1 — Modes own the device. You should be able to identify the active input mode and the actions that mode owns. You also need the Stage 1 loop language: ACT → RESPOND → CHANGE → AGAIN.

224. Core concept

A reproduction is a procedure, not a theory.

A useful reproduction states the starting context, exact player action, and observable result. It does not claim why the result happened.

“Pressing confirm once in Dialogue mode leaves the current prompt visible” is an observation. “The dialogue handler is broken” is an assumption about the cause.

Keep these records separate:

Record device or execution details only when they could affect reproduction. Relevant details may include the input device or control mapping, build or platform, browser, and active mode. Do not add unrelated system information.

An expected result also needs an oracle: a design rule, specification, acceptance criterion, established behavior, or other stated source. If no source is available, label the expectation provisional instead of presenting a personal assumption as established behavior.

225. Mental model

Use Observed → Expected → Hypothesis.

1. Observed: What happened after a specific player action?
2. Expected: What visible or audible change should have happened, and what source supports that expectation?
3. Hypothesis: What might explain the difference? Mark it as untested.

A reproduction is complete when another person can start from the stated context, perform the exact action, and check the same observation. A hypothesis is optional and never replaces the steps.

For the Stage 1 loop, document the sequence as:

• ACT: Perform one stated player action.
• RESPOND: Record the immediate visible or audible response.
• CHANGE: Record the change that occurred or failed to occur.
• AGAIN: Reset to the same starting context and repeat to check consistency.

226. Concrete example

Weak report:

Confirm is broken because the dialogue system ignores the button.

Stronger reproduction:

Context: Dialogue mode is active; a prompt with a confirm instruction is visible; the test uses a controller with its current mapping; the tested build is identified.

1. From the stated context, press the mapped confirm control once.
2. Observe that the current line remains visible and no next line appears.
3. Return to the same prompt with the same mode, device, mapping, and build.
4. Press the same control once again.
5. Record whether the result occurs again.

Expected result and source: The dialogue advances after one confirm action, according to the stated interaction rule. If that rule cannot be located, write: “Provisional expectation: the dialogue advances after one confirm action.”

Unverified hypothesis: The active mode may not be receiving or owning the confirm action.

The hypothesis remains outside the numbered reproduction.

227. Common mistakes

• Naming a cause instead of giving player steps.
• Omitting a device, mapping, mode, build, platform, or browser detail that could change the result.
• Treating a personal assumption as the established expected behavior.
• Repeating from a different starting state and calling the result consistent.
• Changing code before preserving the original observation.

228. Guided practice

Create a reproduction for this invented report: “Pressing the action button near a locked door does nothing.” Do not edit code or name a cause yet.

Write these parts:

1. Starting context: Active mode, player position, visible door state, and any device, mapping, build, or platform detail that could affect the test.
2. ACT: The exact action, including whether the control is pressed once, held, or pressed in a sequence.
3. RESPOND and CHANGE: What the player observes and which change does not occur.
4. Expected result and source: Cite the available rule or specification. If none is available, label the expectation provisional.
5. AGAIN: Explain how to restore the same context and repeat the test.
6. Hypothesis: Write one possible cause, label it unverified, and keep it outside the numbered steps.

229. Practical assessment

Transform this ambiguous input complaint into a complete reproduction:

“The menu button sometimes does nothing.”

Submission format

Submit one short report using this structure:

• Starting context:
• Numbered player steps:
• Observed result:
• Expected result and source:
• Reset and repeat procedure:
• Unverified hypotheses:

Do not propose or apply a patch.

Scoring rubric: 6 points

Award one point for each criterion:

1. Starting context: States the initial mode or screen and includes only relevant device/control, mapping, build, platform, or browser details.
2. Exact action: Uses numbered steps and specifies the exact control action and sequence.
3. Observed result: Records a visible or audible result without inferring a cause.
4. Expected result: States the expected change and names its source, or clearly labels the expectation provisional.
5. Reset and repeat: Explains how to restore the same context and repeat the action to check consistency.
6. Hypothesis separation: Keeps possible causes outside the reproduction and labels them unverified.

Threshold: A complete reproduction earns 6/6. Revise any missing criterion before moving to diagnosis.

Model-based self-check

Compare your work with this model for a different invented complaint:

“Confirm does not advance the prompt.”

• Starting context: Dialogue mode; prompt visible; keyboard mapping unchanged; tested build identified.
• Steps: 1. Open the stated prompt. 2. Press the mapped confirm key once. 3. Observe the prompt. 4. Restore the same prompt and repeat once.
• Observed result: The current prompt remains visible after each press.
• Expected result and source: The prompt advances after one confirm action, according to the stated interaction rule. If that rule is unavailable, the expectation is provisional.
• Reset and repeat: Reopen the same prompt with the same mode, mapping, device, and build, then repeat the action.
• Unverified hypothesis: The active mode may not own the confirm action.

Use the model to check structure, not to copy its details into your menu-button report.

230. Validation checklist

Before submitting, confirm that your report:

• gives another tester a repeatable starting context;
• records only context details that could affect the result;
• uses numbered player actions;
• distinguishes observation from expectation;
• identifies the source of the expectation or marks it provisional;
• restores the same context before repeating;
• keeps every proposed cause outside the reproduction.

231. Key takeaways

• A reproduction describes what the player does and what the player observes.
• Relevant device and execution context can be necessary for repeatability.
• Expected behavior needs a stated source; unsupported expectations are provisional.
• Observed behavior, expected behavior, and possible causes are separate records.
• Use ACT → RESPOND → CHANGE → AGAIN to preserve the sequence before proposing a patch.

232. Next lesson

Continue to 1.4 L3 — Pointer lock vs clickable choices.

233. Knowledge check