What to Clear Before Restarting a Text Adventure: How Authors Check Initial State for Last-Run Information
When restarting a text adventure, the first screen should contain only what this run's setup allows. Authors should check four categories of cross-run residue—identity, resources, known clues, and location and task—against the first-run baseline, changing or deleting anything that only held in the previous run.
Introduction
When restarting a text adventure, the first screen the player sees should contain only what this run's setup allows. The check an author needs to do is not reading the whole text, but listing four categories of input that can carry over between runs—identity, resources, known clues, and location and task—comparing each against the first-run baseline, and changing content that only held in the previous run into initial values or deleting it. Below, a fictional teaching example, "Camp Departure," illustrates the specific method. The characters, numbers, and dialogue in this example are made up for explanation, not actual test data.
First write the first-run baseline, then write the allowed-retention list
The premise of the check is having two things: one is what each field should be at the start of this run, and one is what content is allowed to be carried over from the previous run. Without these two, the comparison becomes judgment by impression.
Take the fictional text adventure Camp Departure as an example. The player plays a traveler spending the night at a camp at the foot of a mountain, and after dawn chooses a route into the mountains. The first-run baseline can be written as a table:
| Field | First-run baseline | Allowed retention |
|---|---|---|
| Player identity | Nameless traveler, not joined to any group | None |
| Resources | 2 portions of dry rations, 1 flask of water, 1 fire token | None |
| Known clues | Only knows there is an old road on the north side of camp | None |
| Location | Camp at the foot of the mountain | None |
| Current task | Decide which road to take today | None |
If the game design allows inheritance, for example the player obtained an amulet in the previous run, then the "Allowed retention" column says "Amulet (if obtained in previous run)," and the rest remains empty. The shorter the allowed-retention list, the easier the check is to do.
Compare category by category: identity, resources, known clues, location and task
The four categories of input each have different ways of bleeding through, so look at them separately during the check.
For identity, a common problem is how the character is addressed. In the previous run the player may have already given a name or joined a group, and if the start of this run continues to use an address like "Captain," that amounts to assuming the previous run's relationship still exists. The check method is to list all forms of address to the player in the first few paragraphs of this run, and ask one by one: does this address hold in this run's baseline?
For resources, pay attention to quantity and existence. At the end of the previous run the player may have had 1 portion of dry rations left, and if the start of this run says "you counted the remaining dry rations," that implies the quantity is continuous. If the first-run baseline says 2 portions, it should be written as 2 portions, or simply not mention a specific number.
Known clues are the easiest to miss. In the previous run the player may already know where the old road leads, and if this run has the character say "I've walked that road," that brings the previous run's knowledge in. The check method is to pick out all sentences in this run of the form "the player already knows X" and compare them against the baseline item "only knows there is an old road on the north side of camp."
For location and task, see whether the character first mentions the previous run's ending. For example, if in the previous run the player chose to stay at camp, and at the start of this run the character asks "what did you see when you went into the mountains yesterday," then the previous run's result has bled in. In the first-run baseline the player has not yet entered the mountains, so this sentence does not hold.
A running constructed case: input and expected differences across two playthroughs
Making the four categories above into a comparison table gives a reusable check template. Still using Camp Departure, suppose the first run ended when the player reached halfway up the mountain, and the second run restarts.
| Check item | First-run input (fictional) | Second-run expected input (fictional) | Difference handling |
|---|---|---|---|
| Identity address | Character calls the player "traveler" | Still calls them "traveler," not "mountaineer" | Delete "mountaineer" |
| Resources | 2 portions of dry rations, 1 flask of water | 2 portions of dry rations, 1 flask of water | If written as "remaining dry rations," change it back |
| Known clues | Only knows there is an old road on the north side | Only knows there is an old road on the north side | Delete "you remember the fork halfway up the mountain" |
| Location | Camp at the foot of the mountain | Camp at the foot of the mountain | Delete back-references like "return to camp" |
| Current task | Decide which road to take | Decide which road to take | Delete "continue yesterday's route" |
Under the condition that this example does not allow inheritance, the second-run expected input column is the first-run baseline. The difference handling column is what the author actually needs to change. This table can be copied directly, replacing the fields with the corresponding items in your own story.
It should be noted that when a character makes up an excuse in dialogue, such as "I dreamed yesterday that you went into the mountains," this belongs to the character's words, not a new world fact. When checking, mark it as a "character statement," and do not conclude from it that the player really did enter the mountains. Characters can lie or misremember, but the author must be clear about what is setup and what is dialogue.
Check priorities when AI output is involved
If the story uses AI to generate narration, prompt constraints do not guarantee that every output is correct. The limitation directly relevant to this topic is: past events that were not provided cannot be used as known facts. When checking, the author should focus on whether the AI has written the previous run's ending into the start of this run. The method is to cut out the start of this run separately, read it sentence by sentence against the first-run baseline, and mark any back-references such as "you already," "last time you," or "still remember." After marking, decide manually whether to delete, change to a neutral description, or add a sentence explaining that this is the character's guess.
Completing the check
After revising, finish with three questions. First, can every known fact in this run find a source in the first-run baseline or an explicit inheritance list? Second, is there any resource that, although not shown, is treated as available by default in the options? Third, do the character's forms of address and back-references cite previous-run experiences that have already been deleted? Then use two previous-run records with different endings to prepare opening samples separately: if this work does not allow inheritance, the two new openings should maintain the same factual baseline, while the tone may vary. Save the baseline table, and when revising the opening next time, still review against the same table.
