How to Design a Reduced-Motion Mode for a Story Game

Start with a normal-versus-reduced expression map

Let the preference select presentation, not game state

Store the preference as a presentation setting and have the interface read the same rule result. The rules engine validates and commits an action first; presentation then expresses that result using the current preference. Do not let a normal-mode animation-complete event award a reward, advance time, or unlock a clue. That coupling can cause the reduced version to miss, pre-empt, or repeat a commit.

Use a small contract:

1. The input produces the same action candidate.
2. The rules engine commits time, resources, position, clues, character knowledge, and outcome once.
3. The normal or reduced renderer reads that same commit record.
4. A shared rule event or timestamp determines when the next input is eligible. Both renderers read that eligibility; animation completion and preference changes cannot unlock input early.

Action acceptance, outcome commitment and next-input readiness can be separate stages. While an outcome is pending, both modes retain waiting feedback and the input gate. No clue, reward or success appears before its rule commitment.

Changing the preference must not pause a countdown, extend a choice window, alter an opponent's turn, or grant a character new knowledge. If the settings panel obscures play, define its pause policy separately; both motion modes follow the same pause rule.

Define the boundary for a preference change mid-action

The riskiest point is after input has committed while the camera is still moving. Record the start, end, and committed state for every interruptible presentation. When the preference changes, choose a new presentation path without rolling back rules or replaying input.

The same principle applies when switching from reduced to normal motion: do not replay missed shake or transition for the current result. The next new effect uses the normal expression. A preference change therefore cannot become a mechanical commit.

Original case: three checks at the fog-harbor bell tower

Fog-Harbor Bell Tower is a fictional story-game scene designed for this article. It has no implemented build or executed result. Before the tide bell rings, the player gives the keeper a copper tab engraved with a swallowtail mark and asks him to open an old letter box. Scene state includes tab ownership, the keeper's known clues, remaining bell rings, whether the box is open, and the next opportunity to ask a question.

In this case, one rule event commits the complete success record and next-question eligibility before decorative motion begins. Before that event, both modes wait and disable questioning. On success, the tab is valid. Normal mode pushes the camera toward the lock, gives the box a small tremor, and reveals an old route sheet. Reduced mode holds the camera, changes the lock outline, reveals the sheet in place, and labels it “Old route archived.” Both commit one tab transfer and one clue, leave the same number of bell rings, and offer the same next action: ask the keeper about a gap on the sheet.

On refusal, the player holds a similar tin token. Normal mode gives the item slot a small shake. Reduced mode keeps it fixed and shows “Crest mismatch” with a swallowtail glyph. Neither transfers the item, opens the box, nor gives the keeper knowledge of the old route. Both still let the player return to the archive to find the copper tab.

On repeat, the player submits the already-used copper tab again. Both modes say “Copper tab already delivered,” grant no second sheet, consume no additional bell ring, and create no second question opportunity. If the player enables reduced motion halfway through the first successful camera push, the complete success record and next-question eligibility are already committed, so the interface may stop the push and place the box and result card at their end positions. The committed clue remains, the unplayed tremor is cancelled, and no reward fires twice.

Check state equivalence in the real interface

A target image can approve direction but cannot prove operability. After implementation, use actual input in the target viewport and retain state snapshots before action, after commit, and when input becomes available again. This is a verification plan, not a claim that this article executed the tests.

• Normal and reduced modes use the same control to complete the same valid input.
• Both show the same result text, clue content, character-knowledge scope, resources, and time.
• Both gain next-input eligibility at the same committed rule event or timestamp. Record that point and focus destination; animation completion is not its substitute.
• Invalid input returns the same refusal reason and commits no state in either mode.
• Repeated input grants no duplicate reward, deduction, or story advance in either mode.
• Change preference before input, during accepted-action/pending-outcome, after outcome commit, during motion and after the result. Check waiting state, disabled input, timer and readiness timestamp; only presentation configuration may differ.
• After shake, zoom, parallax, and moving transitions are replaced, the current action, necessary basis, pressure, and result remain legible.
• Every input path the project actually supports (keyboard, controller, or touch) can reach settings and return focus.
• After exit and reload, the preference persists or resets according to the product decision while saved story state remains unaffected.

When a difference appears, first classify it as a rule commit or presentation read. If one mode omits a clue, repair its reading of shared state. If switching adds a reward, remove the mechanical commit from the animation callback. Do not relax rules or extend timing merely to pass the check.

Hand off reduced-motion direction on one page

Put the decision in art direction rather than scattering it across animation notes. For each high-risk moment, hand off:

The project need not claim a universal automatic switch. Define its own preference, two expressions, and state-equivalence conditions for implementation, then complete checks in the real interface.

FAQ

Must reduced-motion mode remove every animation?

No. Replace shake, camera pushes, large displacement, parallax, and moving transitions first. A brief fade, in-place state change, or stationary focus cue can remain when it keeps required information clear and follows the project's reduced-motion direction.

Can reduced motion slow a timed choice?

The mode in this article changes presentation only, so timing and rules remain unchanged. If the product also offers pause or timing assistance, design and name that separately as an explicit mechanical change.

Related reading

• How to Design Game Feedback Players Can Understand→
• How to Simplify a Story Game Interface→
• How to Design Skippable Game Cutscenes→
• How to Design Mute and Volume Settings for a Story Game→