The four parts on one artifact

509. Lesson identity

Module

1.micro-loop — The Playable Micro-Loop

Lesson

The four parts on one artifact

Academic type

Integration

Schema type

Practical

Order

1

Estimated time

20–30 minutes, including practice

This lesson turns the Stage 1 micro-loop into a compact build contract. You will describe one interaction on a single artifact, expose an ownership gap, and revise the contract before implementation.

510. Learning objective

After this lesson, you can label the input, rule, presentation, and feedback of one intended game interaction, identify an ownership gap, and correct the contract with explicit evidence.

511. Why this matters

A game interaction becomes buildable when each part has a clear responsibility and a visible relationship to the other parts. Without that separation, an action can be detected but produce no defined state change, or the game can change without giving the player enough information to interpret the result.

A four-part contract gives you a precise way to direct implementation, inspect AI-generated work, and decide what needs correction. Preserving both the diagnosed gap and the corrected version also creates a stronger brief for the next implementation step.

512. Prior knowledge

The canonical entry prerequisites are modules 1.1–1.3, 1.checkpoints, 1.ai-partner, 1.4, and 1.12. You should be able to describe a small player action and its intended result using the Stage 1 sequence ACT → RESPOND → CHANGE → AGAIN.

The immediate prerequisite is 1.12 L2 — Feedback audit. You should have completed it or be able to distinguish clear confirmation from absent or ambiguous confirmation.

513. Core concept

Four-part ownership

A playable interaction has four implementation responsibilities:

1. Input: what the player does and how the game detects it.
2. Rule: the condition that is evaluated and the state change that follows.
3. Presentation: the perceivable representation of the resulting state.
4. Feedback: the immediate information that helps the player interpret success, failure, or the reason nothing changed.

These are four responsibilities within one interaction, not four unrelated features. A reader should be able to trace the player’s action through every responsibility and understand how another input becomes possible.

Presentation and feedback do not always require separate effects. The same perceivable event can fulfill both responsibilities when it both represents the changed state and clearly communicates the result. For example, a door visibly moving from closed to open can present the new state and confirm success. The contract should state both functions rather than assuming that one automatically guarantees the other.

514. Mental model

Use this contract for each small interaction:

Trace the implementation responsibilities as:

input → rule → presentation → feedback → next input

The player-facing experience is still described as ACT → RESPOND → CHANGE → AGAIN.

515. Concrete example

Consider a small interaction in which the player activates a powered door:

The visible opening performs two functions: it represents the open state and confirms that the action succeeded. The warning cue covers the failure case, in which the unchanged door alone might not explain why nothing happened.

516. Common mistakes

A common mistake is to label only the player action and visible result, then assume the rule is obvious. “Press interact to open the door” does not specify the condition, state transition, or failure result.

Another mistake is to treat feedback as decoration that must be added as a separate sound or effect. Feedback is a communication responsibility, not a required extra asset. An existing state change can also provide feedback if the player can perceive and interpret it immediately.

A third mistake is to write placeholders such as “the game handles it.” A placeholder hides who owns the condition, state change, representation, or confirmation and therefore cannot guide implementation.

517. Guided practice

Complete the planned practical assessment Ownership-gap diagnosis and corrected contract.

Choose one small interaction from your intended game. Do not choose a complete feature or a multi-step system. Suitable scopes include picking up one object, toggling one light, opening one container, or attempting one unavailable action.

Step 1: Write a first draft

Create a four-row contract:

Do not silently improve the draft while diagnosing it. Preserve this version as evidence.

Step 2: Mark one ownership gap

Mark one phrase or row that is absent, ambiguous, or delegated to a placeholder. Name the affected responsibility: input, rule, presentation, or feedback.

Explain in one or two sentences what a developer would have to invent because of that gap. If the same event is intended to provide both presentation and feedback, explain how it fulfills each function.

Step 3: Correct the contract

Revise the marked phrase or row so the missing responsibility becomes explicit. Keep the other rows stable unless the correction requires a small consistency change.

Make one deliberate decision about whether the interaction communicates success, failure, or both. Justify that decision in one sentence.

Step 4: Trace the corrected cycle

Trace the corrected contract as:

input → rule → presentation → feedback → next input

If any link still depends on “the game handles it” or requires the reviewer to invent the central behavior, revise it again.

518. Validation and evidence

Submit or preserve:

1. The first-draft four-row contract.
2. One visibly marked ownership gap.
3. A short explanation of what the gap leaves undefined.
4. The corrected four-row contract.
5. A trace from input to the next possible input.
6. A one-sentence justification of the success, failure, or combined feedback decision.

The corrected artifact is sufficient when:

• The input identifies one detectable player action.
• The rule identifies a condition and resulting state change.
• The rule describes the unsuccessful result when failure is possible.
• The presentation gives the resulting state a perceivable form.
• The feedback lets the player interpret the result immediately.
• Any event serving as both presentation and feedback has both functions explained.
• A reader can trace all four responsibilities without inventing the interaction’s central behavior.

519. Key takeaways

• A micro-loop becomes actionable when its four responsibilities are written as one build contract.
• Input identifies the detected action; the rule determines what is allowed and what changes.
• Presentation represents the resulting state; feedback helps the player interpret the result.
• One perceivable event may satisfy both presentation and feedback when both functions are explicit.
• A preserved first draft, diagnosed gap, and corrected contract provide useful evidence for implementation review.

520. Next lesson

Next lesson: 1.micro-loop L2 — Direct a tiny implementation.

521. Knowledge check