Map interactions, not isolated features

2341. Lesson identity

Module

5.13 — Systems thinking

Lesson

Map interactions, not isolated features

Academic type

Systems

Schema type

text

Order

Lesson 1 in the module

Estimated time

35–45 minutes, including practice

This lesson develops the ability to produce a system-interaction map before changing a feature. The map identifies state owners, dependencies, feedback loops, boundaries, and player-facing contracts.

2342. Learning objective

After this lesson, you can produce a system-interaction map for a proposed change that names affected state owners, directional dependencies, feedback loops, system boundaries, and observable player contracts.

2343. Why this matters

A feature rarely belongs to one system. A seemingly local change can alter rewards, progression thresholds, difficulty, UI messaging, persistence, or the player’s expectations about what will happen next. When those relationships remain implicit, an AI-generated implementation may be locally plausible but globally inconsistent. Mapping the interactions first gives you a way to inspect scope, direct AI work, and detect missing consequences before they become debugging problems.

2344. Prior knowledge

You should already be able to:

• distinguish a system rule from its presentation;
• describe state changes and player-facing feedback;
• evaluate whether variation creates meaningful outcomes rather than quantity alone;
• identify a proposed change and its intended player effect.

The immediate prerequisite is 5.12 L2 — Evalúa la variación sin venerar la cantidad. This lesson extends that evaluation discipline from generated outputs to interacting game systems.

2345. Core concept

A feature is not an isolated object. It is a change to a network of state owners and contracts.

A state owner is the system responsible for creating, updating, or persisting a particular fact. Examples include an inventory system owning item quantities, a progression system owning unlock thresholds, or a UI layer presenting information without owning the underlying truth.

A dependency is a directional relationship: one system may read an authoritative fact, send a command or change request to its owner, react to an emitted event, or rely on an exposed result. The owner performs authoritative writes; a non-owner should normally request a state transition through an explicit contract rather than mutate authoritative state independently. A causal chain moves in one direction, while a feedback loop includes a return arrow from a later effect to an earlier system variable. The return can reinforce change or balance it. A boundary marks what a system is responsible for and what it must receive or expose through an explicit interface.

The map is useful because it asks four questions before implementation:

1. What state changes?
2. Who owns each fact?
3. Which systems depend on that fact?
4. What does the player now expect to see or be able to do?

2346. Mental model

Use the Owner → Dependency → Contract → Loop map.

Represent each relationship with an arrow and a verb. If you claim a feedback loop, continue the path until an arrow returns to an earlier node. For example:

Encounter challenge
  └─increases→ resource consumption
       └─reduces→ available resources
            └─limits→ available actions
                 └─increases→ encounter challenge

This is a closed, reinforcing loop: greater challenge can reduce the player's options, which can increase later challenge again. Without the final return arrow to encounter challenge, the relationships would form only a causal chain.

You may use a structured edge list instead of a visual diagram. Use a table with these columns: Source, Relationship, Target, Authoritative owner, Evidence, Player-facing contract, and Unresolved?. Put one directional edge in each row, and show a closed loop by making the target of a later row return to the source or target of an earlier row. Group rows by system boundary or tag each source and target with its boundary.

Then draw a boundary around each responsible system, or record the equivalent boundary tags in the structured table. Do not treat a screen as a system owner merely because it presents a fact owned elsewhere. Either format is acceptable for submission.

2347. Concrete example

Suppose the proposed change is: “Add a temporary shield that absorbs one hit and then disappears.”

An isolated-feature description might list only a pickup, a shield icon, and a hit animation. An interaction map exposes the wider contract:

Pickup rule
  └─grants→ shield state [owned by Player Status]
       ├─updates→ combat resolution [reads shield state]
       ├─updates→ HUD indicator [presents shield state]
       ├─affects→ damage feedback [must distinguish absorbed hit]
       └─persists?→ save/load boundary [must decide whether it survives]

Combat resolution
  └─consumes→ shield state on qualifying hit
       ├─triggers→ feedback event
       └─changes→ player risk calculation
            └─changes→ route and encounter decisions
                 └─changes→ exposure to qualifying hits
                      └─feeds back into→ combat resolution

In prose, the pickup rule grants shield state owned by Player Status. Combat resolution and the HUD read that state, while combat resolution consumes it on a qualifying hit and emits feedback. The resulting change in perceived risk can affect route and encounter choices, which alter later exposure to qualifying hits and therefore return to combat resolution.

The map reveals decisions that the isolated feature description hides:

• Is the shield owned by the pickup system or by Player Status after collection?
• Does environmental damage count as a qualifying hit?
• Can multiple shields stack, replace one another, or be wasted?
• Does the HUD show the shield before the authoritative state changes, or after?
• Does saving preserve the shield?
• What does the player learn when the shield is consumed?

These are not implementation details that can safely be delegated without direction. They are part of the feature’s rule and player-facing contract.

2348. AI-native workflow

Use AI as a map critic, not as the owner of the design decision.

1. Write the proposed change in one sentence and state the intended player effect.
2. List the known state owners yourself. Mark uncertain ownership with ? rather than guessing.
3. Ask AI to generate a dependency inventory using only the information you provide. Require it to separate facts, assumptions, and open questions.
4. Compare the response against your map. Add a relationship only when you can name its evidence or the design question it exposes.
5. Ask AI to search for missing player-facing contracts: feedback, costs, restrictions, persistence, and edge cases.
6. Keep final ownership and boundary decisions under your control. A polished diagram is not evidence that the architecture is correct.

A useful prompt is:

Review this proposed change and interaction map. Identify possible state owners, directional dependencies, feedback loops, and player-facing contracts. Do not invent project facts. Label each item as stated, inferred, or unresolved. Return questions before suggesting implementation.

2349. Common mistake

The common mistake is treating every arrow as an implementation detail and every screen as a system owner. This produces maps that show components but not authority. If two systems can independently decide the same fact, the map should expose that conflict instead of hiding it behind a generic label such as “game manager.”

A second mistake is stopping at direct dependencies. A reward may directly update inventory, indirectly affect progression, alter available actions, and change perceived difficulty. The indirect path is often where the player-facing contract changes.

2350. Guided practice

Create an interaction map for this proposed change:

“When the player completes a difficult encounter, award a rare key that unlocks an optional route.”

Work through these steps:

1. State the intended player effect in one sentence.
2. List at least five candidate facts, such as encounter completion, reward eligibility, key quantity, route availability, and player feedback.
3. Assign a state owner to each fact. If ownership is unknown, write unresolved and add a question.
4. Record at least six directional relationships using arrows or structured-table rows labeled with verbs such as reads, grants, unlocks, presents, persists, or consumes.
5. Identify one closed feedback loop and include its return relationship to an earlier node or table entry. For example: optional route grants resources → resources reduce later encounter pressure → lower pressure increases successful completions → successful completions grant further route resources. Label the loop as reinforcing because its effects can support further successful completions; if your loop instead counteracts its initial change, label it balancing.
6. Draw boundaries, group rows, or apply boundary tags for the systems responsible for encounter resolution, inventory or rewards, progression or route access, and presentation.
7. Write three player-facing contracts. Include what the player must be told, what action must become available, and what happens if the key is unavailable or already owned.

Make one explicit design decision: Can the key be earned more than once, and if not, which system prevents or communicates duplicate rewards? Record the decision and the owner responsible for enforcing it.

2351. Validation / evidence

Your map is adequate when another developer can inspect it and answer all of the following without guessing:

• Which system owns each important fact?
• Which systems read or change that fact?
• Where does the proposed change cross a boundary?
• What feedback loop could amplify, reduce, or redirect player behavior?
• What will the player see, be allowed to do, or reasonably expect?
• Which decisions remain unresolved?

Submit the interaction map, or its structured-text equivalent, as a scored practical artifact. Score 1 point for each rubric item demonstrated:

1. At least five named facts.
2. An authoritative owner for each fact, with unknown ownership marked unresolved.
3. At least six directional edges labeled with relationship verbs.
4. At least one genuinely closed feedback loop with a return relationship, labeled reinforcing or balancing when useful.
5. At least four explicit system boundaries or equivalent boundary tags.
6. At least three player-facing contracts.
7. Unresolved assumptions or ownership conflicts recorded as questions.
8. The required duplicate-key ownership decision and its enforcing owner.

A visually neat map or well-formatted table that omits uncertainty or fails to close its claimed feedback loop does not satisfy those rubric items.

2352. Key takeaways

• A feature change is a change to a network of state owners and contracts.
• Ownership answers who is authoritative; dependencies answer who relies on that authority.
• Indirect effects and feedback loops often matter more than the first direct connection.
• Boundaries make responsibility inspectable and expose conflicting ownership.
• AI can critique a map and find omissions, but design decisions must remain explicit and reviewable.

2353. Next lesson

Continue to 5.13 L2 — Prioritize the safest intervention.

2354. Knowledge check