Keep the failing save and locate the first difference
Do not finish diagnosis with “start again.” Retain a copy of the failing save and its content, rule and save-format versions. Record the path to saving, the save location and the first mismatch after load.
| Symptom | Compare first |
|---|---|
| Returned item reappears | Ownership before/after load and whether loading grants it again. |
| NPC quotes an unseen secret | Evidence access and the event informing them; check copying player knowledge to everyone. |
| Reward claimed twice | Completion/claim state and repeated settlement during scene entry or rendering. |
| Deadline resets or a settled matter returns | Saved time/status and recreated or prematurely triggered events. |
| Old save enters the wrong route | Changed node/variable meaning interpreted through new rules. |
This concerns restoring and continuing. Failure and restart decides the restart point and retained progress. Both need definition, but they are different operations.
Connect current state with committed history
game-build uses snapshots for quick loading and events for diagnosis and replay. State answers who currently holds the key; history answers who borrowed it, returned it or witnessed evidence. A key count alone cannot recover memory; replaying events as unconditional new grants changes the result.
Persist facts actually read later: location, ownership, accepted promises, evidence access, completion, claimed rewards or pending consequences. Every inconsequential chat word need not become a state variable.
UI and dialogue read restored facts. Generated expression cannot turn a new “he forgives you” line into committed trust. When online parsing participates in actions, replay consumes recorded normalized candidates rather than asking the model to reinterpret an old move.
Original path: loading after the key is returned
Original archive investigation, as a paper validation design rather than an implemented test. The keeper holds the reading-cabinet key. The player may borrow it and read a revised catalog or leave it unread. Contents are revealed only through actual inspection. This example has no timers or randomness.
| Step | Expected saved/read result |
|---|---|
| Fresh start | Keeper holds key; player has not read; keeper knows lending is possible without knowing the future route. |
| Borrow, open, read | Keeper agrees and transfers the key. Actual reading informs the player; keeper did not witness the contents. |
| Return | Player hands back the key and keeper receives it. Current ownership returns while borrowing/return history and player knowledge remain. |
| Save here, then load | Keeper still holds the key, player has read and keeper has not seen contents. Load does not lend or return again. |
| Continue questioning | Keeper may remember the return but cannot quote unseen contents. Choosing to show them later updates knowledge then. |
Current ownership, history and each person’s knowledge differ. A key reappearing in inventory needs a state fix, not new dialogue. Correct ownership alongside leaked contents points to knowledge restoration or branch history.
Compare a neighboring route: borrow, return without reading, save and load. Neither person can quote contents, and the keeper still holds the key. Shared ownership with different reading history exposes deriving story solely from current items.
This loan has no coin reward, so it needs no invented claim test. Where a project has rewards, inspect claimed state and prevent repeated scene entry, load or completion clicks from granting it again.
Do not silently reinterpret old saves after an update
Copy edits may preserve save compatibility. Changed node identifiers, variable meaning, effects or knowledge permissions require checking how the new build reads old saves. Declare affected paths before choosing migration or explicit incompatibility.
Suppose “catalog inspected” formerly meant the player read it, but now also means the keeper did. Reusing that value invents a disclosure. Migrate the old fact to player knowledge; recover keeper access only from supported history, not a guessed value.
On incompatibility, retain the original save and explain supported continuation rather than overwriting it with a fresh state before a warning. Validate a migration through actual loading and subsequent input. A version number alone does not repair meaning.
Replay the failure and a distinguishing neighboring route
Fix the actual content, rule and save versions, replay the failing save/load/continue sequence and compare ownership, knowledge, commitments and settled results. Fix the seed where randomness exists; deterministic projects need no added random system.
Run a neighboring choice sharing the earlier path. Check unchosen events and each NPC’s knowledge. Repair the located state or reader rather than deleting the designed choice to obtain a normal display.
Record tested versions, input, expected and observed results. A screenshot establishes one visible screen, not correct restoration and subsequent operation.
FAQ
Does loading execute every previous event again?
Restoration methods vary, but load must not duplicate settlement. Snapshots and events serve different roles; reconstruction retains history without repeated grants, ownership changes or settled consequences.
Must every update invalidate old saves?
No. Assess actual node, rule and format changes. Compatible copy edits need no forced restart; semantic changes need migration or explicit rejection and affected-path validation.
Do it with the skill
Use $game-build to repair this load bug locally. Provide approved design, runtime version, failing save, pre-save state and observed load differences. Locate ownership, knowledge, commitments, deadlines or reward readers/writers, declare compatibility and affected paths, and retain the old save copy. Replay the failing route plus a neighboring unchosen route without changing gameplay or endings to bypass the bug.
Read the method: Snapshots, events, replay and compatibility · Versions and reproducible validation paths