Define what loading promises the player
NovelToGame distinguishes current state, events and knowledge. First choose the rollback promise: free reselection, fixed-history review or irreversible nodes. The interface and implementation must agree.
Original example: a festival organizer promises a vendor a stall, gives a spare key to a volunteer and privately learns that the stage leaks. Loading must preserve the promise and ownership. Only characters who heard the private information may know it.
“Affinity 35, progress 60%” cannot express those facts. Record what changes later choices without turning every background detail into layered state.
Store current facts and consequential history
| Item | Current state | Event or later use |
|---|---|---|
| Key | Volunteer holds it | Transfer history; store-room checks ownership |
| Stall | Reserved | Promise history; reassignment prompts a response |
| Leak | Established world fact | Player and witnesses know; others do not |
| Evening inspection | Incomplete | Becomes a task when due, then resolves |
Final values alone cannot explain what the player did. Events alone make loading require reconstruction and risk repeated consequences. Combine them as needed without adding an unused parallel data file.
Loading must not advance or duplicate consequences
Loading before inspection time must not trigger the evening task merely because the interface reopened. A completed inspection must not deduct resources again or recreate the leak. Preserve trigger, status and resolution for delayed consequences.
After choosing another route, check for residue from unchosen people, objects or secrets. Restart returns to the defined initial state, not merely an empty text panel. AI may express committed state but cannot casually change ownership or relationships in a load summary.
The same version, initial state and inputs should yield the same state and event order. Wording may vary; established facts must not drift with generated prose.
Declare compatibility when rules change
A wording change may preserve save meaning; action effects, knowledge permissions or irreversible nodes may not. Track content, rules and save versions and either migrate explicitly or reject incompatible saves. Do not silently reinterpret an old choice.
In the actual build, test loading after a promise, after a resolved consequence, and around branch changes and restart. Check for duplicated objects, leaked secrets and revived tasks.
This method defines creative semantics, not a universal database or file format. Verify actual read/write behavior and interface effects in the target runtime.
FAQ
Must every line of dialogue be saved?
No. Prioritize consequential facts, knowledge and promises. A new promise should be validated and committed; a chat summary cannot replace authoritative state.
Do it with the skill
Ask game-build to verify saves and loads against state and history, including knowledge, promises, ownership, delayed consequences, branch changes and restart.
Read the method: Snapshots, events and replay