Declare what rereading and reselection do
Players may skip a line accidentally or forget who made a request. A backlog helps recover that dialogue. Changing an earlier choice requires a separate rollback policy.
game-build’s playable-model contract requires an explicit decision about free reselection, fixed history for rereading, or irreversible nodes. This example chooses read-only history. If your game permits rollback, explain the destination and which committed results will be undone; clicking an old line must not silently alter progress.
Ren’Py’s dialogue-history documentation describes storing displayed lines for redisplay and a history identifier usable by a separate rollback action. These operations can be distinct; this page does not claim automatic implementation in Ren’Py or the skill.
A backlog also differs from a complete story gallery. Other routes may unlock in a separate archive after play. During the current run, history should respect information already revealed on that route.
Keep the lines, speakers and route actually played
Decide which dialogue, narration and committed player statements to retain, then apply that policy consistently. This example retains all three. Unchosen options are not things the player said. Preserve what was displayed at the time; a later clue must not rewrite an earlier line silently.
| What players need | Presentation |
|---|---|
| Who requested what | Keep the original speaker and line instead of merging two speakers into a summary. |
| What the player chose | Record committed speech or action descriptions in their actual order. |
| An unrevealed identity | Retain the name visible then, without substituting a future real name. |
| Whether an action finished | Keep the actual feedback; requesting repair does not make the object repaired. |
game-world-design distinguishes world facts, character beliefs and player knowledge. Hidden culprit identities, future responses and other-route dialogue must not appear just because the backend contains them.
game-art-direction places complete history on an on-demand page. Keep evidence needed for the current choice nearby: fees, danger or a crucial request should not require searching old pages before understanding a button.
Complete paper path: reread the repair request before paying
In an original text game, Lin He brings a lamp to a repair shop with three tokens. The lamp remains on the counter, unrepaired and unpaid for; its old switch must stay. The author selects these lines and rules as a paper example before implementation.
LIN: “The cable broke. Replace only that. Keep the old switch.”
TECHNICIAN: “I’ll check first, without removing the switch.”
The player chooses “Ask him to inspect the cable.” After inspection, he points to the damage.
TECHNICIAN: “It needs a new cable: two tokens. The switch works; I’ll keep it as you asked.”
Current choices: “Confirm cable replacement; pay two tokens” and “Decline repair and take the lamp.”
Having forgotten the agreement, the player opens Dialogue History. It shows Lin, the technician, the selected inspection and its actual feedback in that order. An unchosen leave-with-the-lamp route never occurred and is absent, as is the future response to authorizing repair.
The player scrolls to “Keep the old switch,” then closes history. The same two choices remain. The lamp is still on the counter, the balance is three and repair has not begun. Scrolling and closing did not repeat inspection.
Now the player confirms replacement. The rules charge two tokens once, leaving one. Later, the technician returns the repaired lamp with its old switch and the game shows this result. Only then does history include confirmation and delivery. Rereading inspection neither charges again nor restores the unrepaired lamp.
This path recovers a concrete agreement and resumes the current action. Paper reasoning defines expectations, not proof of a running interface. The project still needs to verify opening, scrolling, returning and fee records.
Give design and build a bounded history request
Declare the history policy in the existing GAME_DESIGN, then give game-art-direction the current scene and target viewport:
This project permits read-only history with no reselection from it. Design opening from current dialogue, scrolling and returning to the current choice. Preserve speakers and committed route. Give the history a clear scroll boundary, while keeping repair cost and switch retention beside the decision. Add no plot, rollback behavior or future branches.
This request uses the skill’s information hierarchy and history direction; it is not a ready-made component. game-build can implement the approved rules afterward, with opening and closing affecting presentation without settling actions.
Walk the example and a neighboring decline-repair route in the current build. Check route-specific content, return position, charges and possession. Persistence after loading follows the project’s save policy: use the version and path checks in save-state repair, rather than guessing the route from a freshly generated summary.
FAQ
Must clicking an old line return to the past?
No. History can be read-only. Rollback needs a declared destination, undo scope and irreversible boundaries that players can understand.
Can history show an unchosen route?
The current backlog retains displayed content from the actual route. A separate unlocked gallery may show other routes under clear conditions without leaking them during play.
Do it with the skill
Provide GAME_DESIGN, PRODUCT_BRIEF, history policy and target viewport to game-art-direction for the backlog entry, reading boundary and return experience. Build the approved behavior separately; direction is not a running component.
Read the method: On-demand history and current decision information · Read-only history, rollback and committed state · Actual branches and player knowledge · Actual paths and neighboring counterexamples