Choose Visible Requirements or Temporary Omission
If players see a storeroom and hear that visits can be requested, a requirement can explain why entry is unavailable. “Enter secret basement: undiscovered” reveals a room they do not yet know exists.
| Situation | Suggested presentation |
|---|---|
| Action and requirement are known | Show the action, current gap, and available next step. |
| Existence is secret | Present it after the intended discovery instead of spoiling it with a lock icon. |
| No current way to qualify | State present unavailability or omit it by design; do not promise eventual access. |
This is not universal. A game deliberately built around route previews may offer controlled advance information consistent with its promise. A readable requirement does not automatically give story knowledge to characters.
Explain the Present Gap, Not the Whole Outcome
“Requirements unmet” offers little help; “Duty keeper’s permission needed” identifies whom to ask. Show a missing key separately so obtaining it does not imply permission.
A nearby note or a response to an attempted action can explain the limit. Necessary information should appear when needed and remain consistent. Disclose known costs before action without publishing hidden motives or endings.
The sources separate button, cost prompt, and character response. Put the present gap beside its action instead of repeating the whole quest history. Requirements may concern presence, conflicting commitments, location, or willingness as well as items and numbers.
Original Example: Permission Still Requires a Key
Paper design, “The Storeroom Visitor”: a sign says, “Request a visit to the tool shelves; collect this visit’s key after approval.” The player learns the action here and initially has neither permission nor key. The duty keeper can authorize the shelves, not the archive area. Entry checks both current permission and possession; refusal spends nothing and changes no location.
| State, action | Response |
|---|---|
| First arrival | Entry unavailable; “Ask the keeper, then collect the key after approval.” |
| Request shelf visit | Keeper says, “Yes, shelves only; archives closed.” Permission is recorded; key still missing. |
| Collect key | Keeper actually hands it over; possession changes and entry becomes available. |
| Enter | Current permission and held key pass; location becomes the shelf area, not archives or a completed search. |
| Exit and return key | Keeper receives it; possession clears. Re-entry requires collecting it again. |
Permission ends when leaving the storeroom scene at the end of this visit. The author chooses that collecting again during the same visit is allowed from the keeper still present. A prompt mentioning recollection cannot freely duplicate keys in every save.
Complete walkthrough: read the public rule, request and receive approval, collect the key, enter, inspect, exit and return it, attempt the old entry option and receive refusal, then leave to end the visit. Each step reads current state; a once-visible button is not permanently valid.
This is an original design path, not a running product or playtest recording. Check whether actual players can read unavailable-action reasons, recognize availability, and proceed after feedback.
Recheck an Option After Conditions Change
An option may qualify when rendered and fail when selected: a key returns, a commitment is withdrawn, a person leaves, or permission expires. Presentation cannot bypass the rules. Preserve the appropriate state after refusal and give the current reason.
Loading restores the visit, permission scope, and possession. “Once approved” does not mean valid now. If permission semantics change, migrate or explicitly invalidate old saves rather than expanding an old record to the archives.
Secret options need the same care. Discovery in one branch cannot leak through a shared scene into an undiscovered route. Distinguish an existing world fact, player knowledge, and character belief.
Check Four Counterexamples
Key without permission must fail in this design; permission without key identifies the missing item; both allow entry but not archive access; a stale click after return cannot re-enter or produce negative item counts.
If everything is unavailable, offer a legal inquiry, wait, exit, or alternative by design. Every limit need not immediately disappear, but players should understand their position.
Keep essential current requirements near choices and full quest history in an optional log. If prompts expose culprits, entire routes, or endings, return to current knowledge. Rule walkthroughs detect disclosure and wrongful access, not whether exploration feels enjoyable.
FAQ
Should every locked option remain visible?
No universal rule applies. Explain known requirements while withholding undiscovered secrets. Deliberate route previews still need controlled information and character knowledge boundaries.
May the story continue automatically after unlocking?
Yes, in an explicitly chosen automatic flow. If entry is the player’s choice, receiving a key should not also enter, search archives, or submit evidence. Define the automatic scope.
Do it with the skill
Use $game-world-design to review locked options with player knowledge, prerequisites, actual state, and ways to satisfy requirements. Separate public limits from spoiler labels. Give a current reason, feasible next step, and actual unlocked action. Check revoked conditions, returned items, stale clicks, and loading without automatic access or secret disclosure.
Read the method: Prerequisites, foreseeable information, and failure feedback · Hidden causality and current player knowledge · Buttons, visible requirements, and prompts · Actual validation and state commitment