Choose the Function Before an Inventory System
An original novel’s keepsakes, tools, and evidence need not all become clickable items. Ask which action, experience, or later response changes when the player gets one.
A key can change access, a tool can change observation, and a letter can change who receives information. A keepsake may remain a narrative display without becoming a universal tool or numerical reward.
The world-design method makes systems serve core decisions. An item can belong to a single scene. One borrowed flashlight may need only a held-item indication rather than slots, weight, crafting, and equipment screens. A larger collection can justify an interface that clarifies uses and ownership.
Write an Acquisition and Use Note
| Field | Decision |
|---|---|
| Initial ownership | Holder or location; visibility does not give possession. |
| Acquisition | Permission, player action, and actual handoff point. |
| Use | Valid targets, permissions or positions, and effects of failure. |
| After use | Retain, consume, transform, or transfer; distinguish these outcomes. |
| Feedback and later read | Visible change and where subsequent content reads it. |
This is a combined editorial worksheet, not a native skill format. Choose when consumables are spent, including refused starts and failed attempts after use begins. A reusable tool remains held in this example; other games may deliberately implement damage or durability.
Complete Paper Path: Borrowing a Flashlight
Original design, “The Album Before Closing”: the player wants to read an exhibit number obscured by shadow. A keeper can lend a flashlight for this gallery. The player already has permission to inspect this exhibit, not enter the office. Its number establishes neither authorship, authenticity, nor ownership.
Initial view: the label is unreadable in ordinary light. A flashlight is visible on the desk, but the held-item indicator is empty. The player may ask to borrow it or inspect other legible exhibits. Here is the borrowing path:
Player: “Borrow the flashlight to inspect this exhibit.”
Keeper: “Yes. Use it in the gallery and return it before leaving.”
The player selects “Take the flashlight”; the keeper actually hands it over. The indicator reads “Borrowed flashlight.”
At the exhibit the player selects “Light the number.” The label reveals “B7,” and the discovery records this exhibit’s visible number. The flashlight remains held.
At the desk the player selects “Return the flashlight.” The keeper takes it, the held-item indicator clears, and the discovery remains. “Received,” says the keeper.
| Subsequent action | Rule and feedback |
|---|---|
| Illuminate again | While held, observation may repeat without duplicating the number or consuming the tool. |
| Click office door while holding it | Access is absent; the tool cannot substitute for permission. Ownership remains. |
| Illuminate after returning it | “Flashlight returned; ask to borrow it again.” No execution or copy from a stale button. |
| Search catalog with B7 | Read the known number; authorship and destination still need checking. |
This design is unbuilt and untested with players. Its path checks ownership and repeat effects, not actual lighting, click targets, or attention to feedback.
Prevent Items Reappearing After Loading or Return
Current possession differs from borrowing history and discoveries. A post-return save should keep the flashlight with the keeper and B7 known to the player. Saving only “borrowing succeeded” cannot restore possession.
A one-use copying voucher needs a different rule. If consumed on successful copying, a refused prerequisite check retains it; success spends one, and the next attempt reads the remaining count. A line saying “copied” does not by itself create a copy or spend the voucher.
Use an existing state machine when available rather than creating files to imitate this worksheet. Animation, inventory icons, and dialogue read confirmed results; they cannot independently decide ownership.
Repair Useless or Universally Effective Items
Acquisition only shows a description: identify the intended change to action or experience. A keepsake may remain narrative display without a tool slot.
Every target succeeds: define targets and conditions. Illumination does not replace keys, permission, or interpretation.
Returned item still appears held: repair current ownership and its display while retaining real observations. Do not erase history to fix an icon.
Repeated use repeats rewards: distinguish repeat observation, repeat acquisition, and consumption. Replay the failure and an adjacent counterexample. Migrate or explicitly reject old saves when rules change their meaning. Observe understanding and enjoyment in actual play.
FAQ
Must every item be consumed or upgraded?
No. Reusable tools, evidence, consumables, and keepsakes may work differently. Add consumption, durability, or upgrades when they affect this game’s decisions.
Can an item description replace feedback from use?
Not fully. A description helps explain use, but action should show success, refusal, or a partial effect. Transfers must change current possession and subsequent actions.
Do it with the skill
Use $game-world-design to design this section’s items from the scene, permissions, and core actions. Specify initial ownership, acquisition, valid targets, effects, consumption or return, and later reads. Include a normal path and a repeated-use or post-return counterexample. Do not add inventory, crafting, or durability systems automatically or report a paper design as a playtest.
Read the method: Action prerequisites, item changes, and system scope · Item destinations and later reads · Committed ownership, loading, and presentation limits