Rewards that fire twice

431. Lesson identity

Module

1.10 — Progression

Lesson

Rewards that fire twice

Academic type

Case Study

Schema type

case-study

Order

2 of the module

Estimated time

25–35 minutes, including practice

This lesson uses a supplied synthetic scenario in which two reward paths may process the same event. The labels “tagged-kill path” and “ambient-pay path” are analytical labels for this exercise; they are not claims about a published case or a verified implementation.

The purpose is not to repeat 1.10 — Unlocks are predicates. The purpose is to identify when multiple observers become duplicate payment authorities and to define one authoritative route for each reward obligation.

432. Learning objective

After this lesson, the learner can identify a duplicate-pay pattern from the supplied synthetic scenario and specify one authoritative reward path for an event.

This is a systems exercise using a hypothetical or explicitly labelled example. It is not documented CONTRABAND production history unless a verified theme is named.

433. Why this matters

A reward contributes to progression only when its trigger, obligation, and authority are clear. Multiple systems may legitimately observe the same event. Observation alone is not duplication. Duplication occurs when more than one route credits the same reward obligation for the same event.

AI can help list possible routes or organize a trace, but the developer must decide:

• what event occurred;
• what reward obligation applies;
• which authority may satisfy that obligation;
• what evidence shows that repeated handling does not grant another credit.

434. Prior knowledge

You should be able to:

• describe a progression predicate from 1.10 — Unlocks are predicates;
• distinguish a condition from the reward granted when that condition is satisfied;
• use the Stage 1 loop: ACT → RESPOND → CHANGE → AGAIN.

435. Core concept

One event may have multiple observers, but each defined reward obligation should have one authoritative pay path.

Use this contract:

For each event and defined reward obligation, exactly one reward authority may grant the credit. Repeated handling of the same event must not grant another credit for that obligation.

The contract separates three questions:

1. What happened? Identify one event rather than its callbacks, notifications, or secondary observations.
2. What is owed? Name the precise reward obligation instead of referring vaguely to “the reward.”
3. Who may grant it? Select one authority for that event-obligation pair.

Two consequences are not automatically duplicates. If they satisfy different, explicitly documented obligations, both may be intentional. The analysis must distinguish separate obligations from two routes paying the same obligation.

436. Synthetic case

Assume the following exercise scenario:

One event: K-17
  ├─ Route A observes K-17 and can grant Reward R
  └─ Route B observes K-17 and can also grant Reward R

The supplied trace records:

Starting balance: 10 R
Route A handles K-17: balance becomes 15 R
Route B handles K-17: balance becomes 20 R

For the exercise, the defined obligation is grant 5 R once for K-17. The expected ending balance is therefore 15 R. The trace supports a duplicate-pay diagnosis because both routes satisfy the same obligation for the same event.

Do not generalize the labels, values, or route structure beyond this synthetic scenario.

437. Diagnostic model

A useful analysis sequence is:

ONE IDENTIFIABLE EVENT
        |
        v
ONE DEFINED REWARD OBLIGATION
        |
        v
ONE NAMED REWARD AUTHORITY
        |
        v
ONE CREDIT
        |
        v
REPEATED HANDLING ADDS NOTHING

This is a diagnostic model, not a required implementation architecture. An event identifier is one possible form of evidence, not a mandatory technical solution.

438. Applying ACT → RESPOND → CHANGE → AGAIN

• ACT: the player action produces event K-17.
• RESPOND: Route A and Route B observe K-17.
• CHANGE: the selected authority grants 5 R once, changing the balance from 10 R to 15 R.
• AGAIN: the other route or a repeated handler processes K-17; the balance remains 15 R for this obligation.

The AGAIN step tests the contract rather than merely restating it.

439. Decision rule

A complete decision names the event, obligation, authority, and repeated-handling result:

“For event K-17, Route A is the authority that may grant 5 R once. If Route B or another handler processes K-17 for the same obligation, it grants 0 additional R.”

Selecting Route A is only an exercise decision; the supplied scenario does not establish a preferred production architecture. Route B could instead be selected if the contract named it as the sole authority and the evidence supported the same one-credit result.

440. Common mistakes

Fixing only the displayed total

Changing the visible balance from 20 R to 15 R can hide the symptom while leaving both payment authorities active. Diagnose the routes that changed the underlying reward state.

Treating every observer as invalid

Several systems may need to observe one event. The defect is not observation; it is duplicate authority over the same obligation.

Assuming every second consequence is a duplicate

A second consequence may be intentional if it satisfies a separate, named obligation. Do not merge distinct obligations merely because they share an event.

Saying only “prevent duplicates”

That phrase does not identify who pays, what is paid, or what repetition must do. Write a testable contract instead.

441. Guided practice

Use only the supplied synthetic evidence above.

Step 1 — State the event

Write one sentence:

“The player action produces event K-17.”

Do not redefine Route A and Route B notifications as separate reward-bearing events.

Step 2 — Trace both routes

Create a two-row table. For each route, record:

• the event it observes;
• the obligation it attempts to satisfy;
• the amount it grants;
• the resulting balance;
• whether it is authoritative under your proposed contract.

Step 3 — Diagnose the pattern

Compare the supplied expected result, 15 R, with the observed result, 20 R. State whether the evidence shows multiple observers, duplicate payment, or both. Explain the distinction.

Step 4 — Make the decision

Select one authority and complete this contract:

“For [event], [authority] may grant [defined reward] once. Repeated handling by [other route or handler] grants [result] for the same obligation.”

Step 5 — Test AGAIN

Add a final row showing a repeated processing attempt. Record the balance before and after that attempt. Under a valid one-pay contract, the balance remains unchanged.

442. Validation and evidence

A sufficient analysis contains:

1. one clearly identified event;
2. two separately traced observer routes;
3. one precisely named reward obligation;
4. the supplied starting, observed, and expected balances;
5. one selected reward authority;
6. a one-event, one-pay contract;
7. an AGAIN result showing no second credit for the same obligation;
8. a note explaining that a separate reward would require a separately named obligation.

Another developer should be able to inspect the trace and determine why the second credit is duplicate rather than intentional.

443. Key takeaways

• Multiple observers do not necessarily mean multiple valid payment authorities.
• Duplicate payment is defined relative to the same event and the same reward obligation.
• A useful contract names the event, obligation, authority, amount, and repeated-handling behavior.
• Validate the underlying reward state, not only the displayed total.
• Keep synthetic evidence separate from claims about a real game or implementation.

444. Next lesson

The next lesson introduces difficulty boundaries. Carry forward the same contract discipline: difficulty may affect only explicitly allowed surfaces, and it must not silently duplicate or reassign a progression reward obligation.

445. Knowledge check