A mechanic is a rule

74. Lesson identity

Module

1.3 — Mechanics and rules

Lesson

A mechanic is a rule

Academic type

Concept

Schema type

text

Order

1

Estimated time

20–30 minutes

This lesson removes attractive or commercial labels from game-design language. You will practice describing what a mechanic does rather than relying on what it is called.

75. Learning objective

After this lesson, you can rewrite a named mechanic as a rule sentence that states the relevant player action or game condition, the game’s immediate observable response, and the resulting change.

76. Why this matters

Names such as “stealth mode,” “combo system,” or “panic meter” can sound precise while hiding the actual behavior. A rule sentence gives another person something they can test. It also makes design alternatives easier to compare: if two versions produce different responses, costs, constraints, or state changes, they are different rules even if they share a name.

77. Prior knowledge

You should have completed 1.2 L2 — Correct and dead. You should be able to distinguish an action that succeeds from one that fails and describe the observable result without relying on promotional language.

78. Core concept

A game mechanic is an observable rule, not a feature label.

A useful rule sentence identifies three required parts:

1. ACT: What the player does, or what game condition becomes true.
2. RESPOND: What immediate feedback the game produces in response. This may be visible, audible, or otherwise observable through play.
3. CHANGE: What resulting simulation state, resource state, affordance, or player constraint becomes different.

These parts answer different questions. RESPOND tells you what immediately communicates the event. CHANGE tells you what is now true in the game or what the player can or cannot do because of it.

A mechanic becomes concrete when another person can read its rule and predict what should happen. The rule may also state a cost, limit, duration, failure condition, or timing constraint, but it should describe behavior rather than implementation.

79. Mental model

Use ACT → RESPOND → CHANGE to write the rule.

After the rule is clear, you may ask an optional testing question:

Under what reset, persistence, or re-entry condition can this rule be tested again?

For the locked door, the locked state persists while the player lacks the required key. Repeating the interaction under that same condition should still deny passage. If the player later obtains the key, the condition has changed, so the next interaction tests a different branch of the rule.

Repeatability is not a required fourth component of every mechanic. Some mechanics reset, some persist, and some change state so that repeating the same input produces a different result.

80. Concrete example

Suppose a design note says: “Focus vision.” That label does not explain the trigger, feedback, or effect on the game state.

Rewrite it as a rule:

When the player holds the focus button and focus is available, nearby interactive objects gain a visible outline, and the focus resource decreases until the button is released or the resource reaches zero.

Break the rule into its required parts:

• ACT: Hold the focus button while focus is available.
• RESPOND: Nearby interactive objects gain a visible outline.
• CHANGE: The focus resource decreases, limiting how long the outlines can remain active.

Then ask the optional testing question:

• Reset, persistence, or re-entry: The mechanic can be tested again when focus is available. If focus recovers after release, that recovery condition must be stated elsewhere in the rule set or added to this rule.

“Focus vision” may remain as a menu or design label, but the name alone is not a mechanic specification.

81. Common mistakes

Treating a noun as a rule

“Inventory,” “stealth,” and “stamina” name areas of design. They do not state what triggers a response or what changes.

Describing feedback without a state change

“The screen flashes red” identifies a response, but not the resulting state. Did health decrease, did an alarm begin, or did movement become restricted?

Restating the response as the change

“The door remains closed” and “the door does not open” communicate nearly the same immediate result. A distinct change or constraint would be: “the doorway remains unavailable, so the player cannot pass through it.”

Treating repetition as universal

A stateful mechanic may produce a different result after its state changes. Ask when the rule can be tested again, but do not assume that the same input must always produce the same outcome.

Do not add technical components to disguise an incomplete rule. First make the observable behavior precise.

82. Guided practice

Rewrite each label as one rule sentence containing ACT, RESPOND, and CHANGE:

1. Quick heal
2. Alarm state
3. Locked drawer

For one sentence, make a deliberate decision about a cost, limit, duration, or failure condition. Then state whether the rule persists, resets, or requires a re-entry condition before it can be tested again.

You may use this format:

When [action or condition], the game [immediate observable response], causing [resulting state, resource, affordance, or constraint].

Check each sentence:

• Is the action or triggering condition explicit?
• Can another person predict the immediate feedback?
• Does the change identify a resulting state, resource, affordance, or constraint rather than merely repeating the feedback?
• Does the sentence describe behavior instead of repeating the feature label?
• If repeat testing matters, did you identify the relevant reset, persistence, or re-entry condition?

83. Practical assessment

Choose one unfamiliar feature label from this list:

• Momentum guard
• Echo scan
• Pressure lock

Without assuming any established meaning for the label, make one design decision and rewrite it as an observable rule sentence. Then annotate the sentence with:

• ACT: the action or condition;
• RESPOND: the immediate observable feedback;
• CHANGE: the resulting state, resource, affordance, or constraint;
• Optional retest condition: when the rule can be tested again, if relevant.

Score the response using one point for each criterion:

1. The action or condition is explicit.
2. The immediate feedback is observable.
3. The resulting change is distinct from the feedback.
4. The sentence describes behavior rather than merely renaming the label.
5. Any stated cost, limit, duration, failure, reset, persistence, or re-entry condition is internally consistent.

A score of 4–5 demonstrates the lesson capability. A score below 4 means the sentence should be revised using the missing criterion.

84. Validation / evidence

Your evidence consists of the three guided-practice sentences and the annotated practical-assessment sentence.

At least two guided-practice sentences must include all three required parts. At least one must include a meaningful cost, limit, duration, or failure condition. The practical-assessment sentence must earn at least 4 of the 5 available points.

A sentence does not pass if it provides only a label, intended mood, visual effect, or technical component.

85. Key takeaways

• A mechanic is an observable rule, not a feature name.
• ACT → RESPOND → CHANGE identifies the required parts of a rule sentence.
• RESPOND is the immediate observable feedback; CHANGE is the resulting state, resource, affordance, or constraint.
• Repeat testing is an optional question about reset, persistence, or re-entry, not a universal fourth component.
• Costs, limits, timing, and failure conditions make rules easier to test.

86. Next lesson

Choose your strongest completed rule sentence and preserve it as evidence. Bring that exact sentence to 1.3 L2 — Invariants you can check, where you will derive two checkable invariants from it.

87. Knowledge check