Difficulty is not the whole game

446. Lesson identity

Module

1.11 — Difficulty

Lesson

Difficulty is not the whole game

Academic type

Systems

Schema type

text

Order

1

Estimated time

20–30 minutes, including practice

447. Learning objective

After this lesson, you can write a difficulty scope that names two surfaces difficulty may change and two surfaces it must not change.

448. Why this matters

A difficulty setting is a contract about the challenge the player faces. It is not permission to alter every number in the game. If difficulty changes rewards, unlock thresholds, or prices without an explicit design decision, the player is no longer receiving a clean challenge adjustment. A narrow scope also gives you a better instruction to give an AI: change the specified challenge surfaces and preserve everything else.

449. Prior knowledge

You should be able to distinguish a rule from its presentation and identify a reward obligation from the previous lesson, 1.10 L2 — Rewards that fire twice. You should also be able to describe a small playable loop using ACT → RESPOND → CHANGE → AGAIN.

450. Core concept

Difficulty changes the challenge contract, not the whole game state.

A difficulty rule may change how demanding an encounter is: for example, enemy reaction time or the amount of incoming damage. Those are challenge surfaces. It should not silently change the economy, progression thresholds, unlock ownership, or the meaning of a successful action. Those surfaces have separate responsibilities and must remain stable unless the design explicitly says otherwise.

Use this distinction:

The phrase changes X, not Y is a scope test. If X is not a challenge surface, or if Y is not explicitly protected, the difficulty design is underspecified.

451. Mental model

The difficulty boundary

Write the rule as four statements:

1. Difficulty changes: Name two challenge surfaces.
2. Difficulty does not change: Name two protected surfaces outside the challenge contract.
3. All other rules remain: Preserve rewards, costs, thresholds, and ownership unless separately specified.
4. The loop remains recognizable: The player can still ACT → RESPOND → CHANGE → AGAIN.

Example boundary:

On Hard, enemy reaction time decreases and incoming damage increases. Enemy reward value and unlock thresholds do not change.

The first two changes affect the challenge. The two protections prevent difficulty from becoming an accidental economy or progression rewrite.

452. Concrete example

Imagine a short encounter:

• The player enters a room and ACTS by moving toward an exit.
• An enemy RESPONDS by tracking the player.
• The player CHANGES position after taking a hit.
• The encounter starts AGAIN until the player reaches the exit or fails.

A valid difficulty scope could be:

• Allowed: reduce enemy reaction delay.
• Allowed: increase incoming damage.
• Forbidden: change the reward granted for reaching the exit.
• Forbidden: lower the threshold required for the next unlock.

The Hard version is more demanding because the encounter gives the player less time to react and makes mistakes more costly. It is not more difficult because rewards were secretly reduced or progression was moved. Those changes would affect different systems and should require separate decisions.

453. Common mistake / wrong assumption

The common mistake is treating every player-facing number as a difficulty number. A reward amount, shop price, or unlock threshold may be visible during a difficult encounter, but visibility does not make it part of the challenge contract. Another mistake is writing “Hard mode changes enemy stats” without naming which stats and which systems are protected. That instruction is too broad for reliable implementation or review.

454. Guided practice

Write a difficulty scope for the encounter in the concrete example. Your scope must contain exactly four entries:

• Allowed 1: one challenge surface difficulty may change.
• Allowed 2: a different challenge surface difficulty may change.
• Forbidden 1: one economy or reward surface that must remain stable.
• Forbidden 2: one progression or unlock surface that must remain stable.

Then test your scope against these questions:

1. Do both allowed entries describe the demands of the encounter rather than its rewards or advancement?
2. Do both forbidden entries protect a separate system responsibility?
3. Can a developer implement the rule without guessing what else may change?
4. Does the loop still read as ACT → RESPOND → CHANGE → AGAIN?

If any answer is no, revise the boundary rather than adding more numbers.

455. Validation / evidence

Your evidence is a four-line difficulty scope with two allowed and two forbidden surfaces. It passes when:

• the two allowed surfaces change the challenge itself;
• one forbidden surface belongs to economy or rewards;
• one forbidden surface belongs to progression or unlocks;
• the scope states what remains stable instead of relying on the phrase “balance everything”; and
• the scope does not alter the meaning of success in ACT → RESPOND → CHANGE → AGAIN.

456. Key takeaways

• Difficulty is a scoped change to the challenge contract.
• “Changes X, not Y” makes the boundary explicit.
• Rewards, costs, and progression thresholds do not become difficulty surfaces automatically.
• A narrow scope is easier to implement, test, and direct with AI.

457. Knowledge check

458. Next lesson

Next: 1.11 L2 — Don’t blame the profile. This lesson applies the difficulty boundary to independent contracts and a larger set of rules without rewriting unrelated systems.

459. Knowledge check