Saving and loading

Saving and loading are features that allows a player to exit and re-enter the game and continue from where they left off, and/or return to a point in the game where they've previously been. Storing the game's state so that it can be retrieved later is called saving it and retrieving the state to put the game in it again is called loading. Saving and loading are common accessibility features.

The stored states can be kept while the game isn't running, allowing the player to continue a playthrough even after turning the device off and back on, which can be convenient for taking breaks, especially in long games. And it's possible to keep several saves stored, allowing for the player to go back and forth between different parts of the story.

Variants

A typical example of saveslots

A list of autosaves shown as a simple menu with scene names

The most common UI for saving and loading in VNs is saveslots. They're a visual representation of "boxes" where the game's state can be stored, typically shown as a grid of images, and when a state is saved into one of the "boxes" its image gets replaced by a screenshot of what the game looked like right before saving it. Saveslots usually also have some text shown on them, such as the time and date where they were last saved into, the name of a chapter the game was in at that time, and a name that the player assigned to the saveslot.

Some games automatically save their progress when the player reaches particular points in the story, or when the player exits the game. The states that are stored this way are called autosaves.

A less common way to handle saves is through passwords. These are sequences of characters that can be shown on screen and typed by the player. When the player reaches particular points in the story, the game can show them a password that they can then write down outside the game, and then when they want to load them they have to type the same sequence of characters in order to load the state that the password represented.

A related but slightly different feature is skipping read text which remembers which lines had been seen in previous playthroughs so that the player may fast-forward through those but the fast-forward stops when reaching a line they hadn't seen before.

Implementation

In a simple linear VN without branching, saving can be as simple as counting the lines of dialogue from the start of the VN and up to the one that's being shown when saving, then storing the resulting number in a file. And then loading can be done by quickly simulating the effects of the first N lines of dialogue where N is the number that was saved, without showing anything on screen until you reach the line that was on screen when saving. But this approach has a couple of drawbacks:

• If lines are added or removed in later versions of the game, different versions will struggle loading each other's saves.
• If there's branching involved, a single number can't identify as easily how the player reached a specific line.

To fix the first issue, a visual novel engine may assign IDs to each line in such a way that the lines can retain the same IDs when other lines are added and removed before or after them. This usually involves splitting the VN into sections and assigning an ID to each section (for example each section may start at a label and the section ID will be derived from the label name), then assigning IDs to each line in a way where line IDs refer to the sections they're in, and are also derived from the text of the line (possibly through a hash function).

And to fix the second issue, saved games may encode the same types data that's stored for history to work.

Autosaves at specific points in the game may be implemented the same way as normal saves, or in linear games they may be implemented by having named points in the script that, when they're reached, the game remembers that they've been reached, and from then on the list of autosaves can include a button to jump to that point in the script.

Implementing password systems

Passwords need to be short enough that the player can easily write them down and enter them later, so it may be easier to implement them for linear VNs or VNs where branches may split but don't get joined together again. For example, a short linear VN may show passwords as six-digit numbers where the first three digits refer to the scene, the next two refer to the line within the scene, and the last one is a check digit. If the check digit is valid and the scene exists but the line can't be found, the game may assume that the save is from another version of the game, and since it can't find the exact line to jump to, it may just jump to the start of the scene where the line was. A longer game or one with more complex branching may use longer passwords or use a larger set of characters/symbols instead of sticking to the digits from 0 to 9.