Unlocks are predicates

418. Lesson identity

Module

1.10 — Progression

Lesson

Unlocks are predicates

Academic type

Systems

Lesson type

Text with practical assessment

Order

1

Estimated time

20–30 minutes, including practice

419. Learning objective

After this lesson, you can write one unlock as “when X, grant Y,” where X is an observable progression condition rather than a judgment such as “the player feels ready.”

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.

420. Why this matters

Progression is a system of thresholds and grants, not a list of rewards that appear at convenient moments. An explicit unlock contract lets a designer, tester, or implementation determine why something became available. It also gives an AI assistant a precise rule to restate or implement instead of asking it to guess what “ready” means.

This lesson concerns advancement, thresholds, and availability. Prices and payment flows belong to economy. The challenge involved in reaching a threshold belongs to difficulty.

421. Prior knowledge

You should have completed 1.9 L3 — Write one economy invariant and be able to distinguish a measurable system statement from a preference such as “the game should feel rewarding.” You also need the Stage 1 loop: ACT → RESPOND → CHANGE → AGAIN.

422. Core concept

An unlock predicate is a condition that can be evaluated as true or false against the game’s progression state. An unlock contract has two parts:

When X is true, grant Y.

• X — predicate: a specific, observable condition, such as “the player has completed three training tasks.”
• Y — grant: a specific progression result, such as “make the traversal tool available.”

A strong predicate names a state that can be checked. It may use a count, completion flag, recorded milestone, or other explicit threshold. It does not rely on mood, presumed competence, or an invisible judgment.

The grant must also be unambiguous. “Unlock better gear” does not identify what becomes available. “Make the reinforced pack available for purchase” names the progression result; the pack’s price remains an economy decision.

423. Mental model: threshold → grant

Review the contract with the Stage 1 loop:

1. ACT: the player performs an action relevant to progression.
2. RESPOND: the game communicates the result.
3. CHANGE: the recorded progression state changes when the stated condition is met.
4. AGAIN: the player can identify the next threshold or repeatable objective.

The loop does not require a new unlock after every action. It requires the progression change to be observable and governed by a rule.

424. Verified case boundary

A survival hull unlock is a verified progression theme. At the verified level, the contract can be stated as:

When the documented survival-hull milestone is recorded as complete, make the survival hull available.

This case establishes only the relationship between the recorded milestone and hull availability. It does not establish a particular threshold, list of contributing actions, price, or difficulty level. Any added counts or conditions used elsewhere in this lesson are fictional teaching examples, not documented facts about that case.

The availability unlock is a persistent progression state change: once the availability state has been granted, ordinary checks should continue to report the hull as available. It is not a recurring payout that should be issued again whenever the predicate is checked. The next lesson examines duplicate reward paths in more detail.

425. Common mistakes

Mistake 1: using a feeling as X

When the player seems ready, unlock better equipment.

“Seems ready” cannot be evaluated consistently. Replace it with a recorded state, count, milestone, or explicit threshold.

Mistake 2: leaving Y unspecified

After enough progress, grant something useful.

Neither “enough” nor “something useful” defines a testable contract.

Mistake 3: mixing progression with economy or difficulty

The predicate may control whether an item is available. Its price is an economy value. How demanding the qualifying activity is belongs to difficulty. Record these as separate decisions.

Mistake 4: treating every check as another grant

A predicate may be evaluated more than once. Rechecking a true predicate should confirm the persistent availability state rather than create a second payout or duplicate one-time transition.

426. Guided practice

Draft an unlock contract for a fictional progression system.

1. Choose one advancement target: an ability, area, tool, mission category, or item availability.

2. Write an initially vague condition, such as “when the player has enough progress.”

3. Replace it with an observable fictional condition using a count, completion flag, milestone, or explicit threshold.

4. Complete this frame:

   When ______________________________, grant ______________________________.

5. Inspect X. Replace words such as “ready,” “good,” “enough,” “understands,” or “deserves” with a state that can be checked directly.

6. Inspect Y. Name exactly what becomes available.

7. Record any price separately as an economy value. Record any challenge-tuning decision separately as a difficulty note.

8. Trace ACT → RESPOND → CHANGE → AGAIN.

9. Add two boundary tests: one just below the threshold and one at the threshold.

10. State what happens when the true predicate is checked again after the unlock has already been recorded.

A fictional answer could begin:

When the player has completed 3 traversal trials, make the reinforced pack available.

The number and content in this example are fictional. A valid answer must define one observable X, one specific Y, separate price and difficulty, and preserve availability after the first successful grant.

427. Practical assessment

Complete Unlock Contract and Boundary Tests. Submit one written unlock contract, its system boundaries, an ACT → RESPOND → CHANGE → AGAIN trace, and boundary tests showing the state immediately below the threshold, at the threshold, and after a repeated check.

You have demonstrated the capability when another person can:

• evaluate X as true or false from the stated progression data;
• identify exactly what Y makes available;
• distinguish the unlock from price and difficulty decisions;
• verify that the grant persists after the first successful transition; and
• verify that repeated checks do not create a recurring payout.

428. Key takeaways

• An unlock is a contract: when X is true, grant Y.
• X must be an observable progression predicate.
• Y must name the specific result that becomes available.
• Price and difficulty remain separate system decisions.
• Boundary tests reveal whether the threshold changes state at the intended point.
• An availability unlock is a persistent state change, not a recurring payout.

429. Next lesson

Continue with 1.10 L2 — Rewards that fire twice, which examines a duplicate-pay pattern without redefining the unlock contract.

430. Knowledge check