Where Do Items in Text Adventures Come From: Use Provenance Records to Avoid Keys Appearing Out of Thin Air
You can maintain a provenance record for each item, answering four questions: from whose hands, in what way, under what conditions, and in which scene it entered the player's disposable range. This record, beyond the item name list, lets the author verify whether the appearance of keys, letters, and tickets has a basis; each subsequent transfer still needs to be checked item by item.
Introduction
You can maintain a provenance record for each item, answering four questions: from whose hands, in what way, under what conditions, and in which scene it entered the player's disposable range. This record, beyond the item name list, lets the author verify whether the appearance of keys, letters, and tickets has a basis; each subsequent transfer still needs to be checked item by item.
The following uses a fictional teaching example. In the mountain city post office scene, the player borrows a brass key from counter clerk A Lan to open the second-floor archive room. The characters, numbers, and dialogue in this example are fictional, only to demonstrate the recording method.
First Build a Provenance Record for the Item
Do not write "Backpack: brass key." It is recommended to write a complete record:
| Field | Content |
|---|---|
| Item | Brass key |
| Source type | Borrowing |
| Source character | A Lan (post office counter clerk) |
| Acquisition scene | Post office lobby, afternoon |
| Acquisition condition | The player explains they want to check old archives and leaves their name |
| Current status | Held, not returned |
| Destination record | Empty |
Source types are divided into at least five kinds: pickup, borrowing, consumption, handover, loss. Pickup is when the player takes an unowned or takeable object from the scene; borrowing is when another person temporarily hands something over with an expectation of return; consumption is when the quantity or state decreases after use; handover is when the player gives the item to a character or location; loss is when it is taken away, lost, or expires. Different types allow different subsequent responses. A borrowed key can be demanded back, while a picked-up key usually will not be.
Write the Acquisition Process into the Narrative, Not Just the Result
Writing only "you get the key" will make it impossible later to judge whether this key should appear. It is recommended to place the source clue in the acquisition scene first, then let the player get it:
A Lan takes a brass key from the drawer and places it on the counter. "Second-floor archive room, the innermost row of iron cabinets. Leave your name, and return it before dark."
Options:
- Leave your name and take the key.
- Ask whether you can go now.
- Say you are just looking around.
After the player chooses 1, the log writes "Obtained: brass key (borrowed from A Lan, needs to be returned)." Option 2 does not change the holding status, only advances the scene. Option 3 does not obtain the key, and later the archive room cannot be opened. In this way, the key's source has already appeared in the narrative, and both the player and the author can check back.
Repeated Taking Must Have a Response, Not Silent Stacking
If the player walks to the counter again, another key cannot be given. It is recommended to respond according to the current status:
A Lan glances at the brass key in your hand: "The one in your hand hasn't been returned yet."
If the player has already returned the key, borrowing again generates a new borrowing record, and the return deadline resets. If the player has never borrowed it, the response returns to the first borrowing dialogue. The basis for the response to repeated taking is "current holding status," not "whether they have been to the counter."
Consumption, Handover, and Loss Must Have Destinations Written
The key being used to open the archive room does not equal consumption. Unlocking is use, and the key is still in hand. What truly changes the holding status is return, loss, or being taken away. It is recommended to write a destination record for each status change:
| Event | Destination type | Record |
|---|---|---|
| Use the key to open the archive room door | Use | The key is still held |
| Put the key back on the counter | Return | Handed back to A Lan, holding ends |
| The key falls into the drain | Loss | Lost, can no longer be used to open the door |
| Give the key to colleague A Yan | Handover | Holding transfers to A Yan |
The difference between handover and borrowing lies in expectation: handover usually does not expect the original object to return, while borrowing expects return. If the player gives the borrowed key to A Yan, A Lan should subsequently question the player, not A Yan, because the borrowing relationship occurs between the player and A Lan. This relationship can be recorded separately in a line: "Unreturned responsibility: player."
When Records Are Missing, Do Not Write in New Facts
When the player is in front of the archive room door and there is no key in the provenance record, there are three ways to handle it. Choose one according to the scene's needs, and do not improvise "you remember there is a key in your pocket."
First, clearly block: the door is locked, and the player needs to go back and borrow it. Second, provide an alternative path: the window is not closed, but it triggers other consequences. Third, acknowledge the missing record and pause: if this is text in serialization, it is recommended to mark in the author's notes, "Missing key source here, to be added," rather than forcing it into the main text.
If the player claims, "I took the key before," but it is not in the record, the response can remain consistent within the world:
You feel your pocket, and there is only a ticket. The archive room door remains locked.
This is not denying the player, but letting the narrative continue based on existing records. When AI generates text adventures, the output may not always be consistent with the records, so the provenance record must be stored separately by the author or process, and cannot rely only on model memory.
Completion Check
After writing a scene, check item by item:
- Does every disposable item have a source type, source character, acquisition scene, and acquisition condition?
- Are borrowed items marked with an expectation of return?
- Do consumption, handover, and loss all have destination records?
- When taking repeatedly, does the response rely on the current holding status?
- When records are missing, did you use blocking, an alternative path, or a to-be-added marker, rather than adding new facts?
Taking the brass key as an example, the complete chain is: A Lan lends it out → the player holds it → opens the archive room (use, still held) → returns it to the counter (return, holding ends). If the key falls into the drain midway, the record changes to loss, and this key should no longer appear in any subsequent door-opening option. Running through these five checks is more effective at preventing keys from appearing out of thin air than repeatedly maintaining an item name list.
