Auto-save support

[Bertram25]

The game is lacking auto-save support:

Each time the character is changing from a map to another, an auto-save game should be created.
Then, when loading a game, the player should asked whether her prefers loading the auto-save or the regular one.
The auto-save loading should be proposed only if the regular savegame is older than the auto-save file.

[suitecake]

Hi Bertram; have you done any preliminary work on this task? If not, I'd be up for this. It'd be a time-saver for when crashes happen (and could be useful for diagnosing crashes).

[Bertram25]

Fine by me, but please propose the use-cases before implementing them. I, myself, haven't looked at it closely enough to say whether the summary is enough to make something fine to play with. :)

[suitecake]

Proposed design:
Auto-saves occupy a special, permanent slot in the Load Game menu. There is only ever one auto-save per machine (to keep things simple; if we want to support one auto-save per playthrough, we should probably go the whole way and implement a profile system). This save slot appears at the top of the 'save game list' (displayed when the user is loading a game). If it doesn't already, the load game screen should be updated so that the cursor's initial position is the most recent save game (so that if the auto-save is newer than any manually saved game, the cursor defaults to the auto-save).

Whenever a user leaves a map, an auto-save is generated before the next map is loaded. This should be done as early as possible so that if a crash occurs in the process of loading the next map (which is easy to do atm if there's a typo in the lua map script), the user retains his/her progress.

Loading the auto-save should initialize the map that was being loaded. In other words, though the auto-save is being taken prior to the new map being loaded, loading the auto-save should result in the new map being initialized (along with any triggers on entering the new map).

An options entry should be introduced for enabling/disabling auto-saves (enabled by default). A nice-to-have would be a third option: Minimal auto-saves (ie, not bothering to auto-save on map transitions within a city, only on first entering the city). We can start naive with auto-saves on each map transition, and expand on this later.

One concern is time spent in file I/O. It's quick on my machine (desktop, SSD, fast CPU), but may noticeably increase map transition times on other platforms (especially some of the more limited/embedded platforms people have gotten this to run on). If we run into this, a good solution would be either a new options entry or a compilation variable for streamlining auto-saves, spinning off an auto-save on a separate thread so map transition times aren't noticeably impacted.

I haven't reviewed how save games work yet. If a save game isn't a complete snapshot of the game state (if, for example, player status effects are shaved off), there's some risk of abuse by users. Will need to explore this.

What are your thoughts?

[Bertram25]

Thanks for the analysis :)

Auto-saves occupy a special, permanent slot in the Load Game menu. There is only ever one auto-save per machine (to keep things simple; if we want to support one auto-save per playthrough, we should probably go the whole way and implement a profile system). This save slot appears at the top of the 'save game list' (displayed when the user is loading a game). If it doesn't already, the load game screen should be updated so that the cursor's initial position is the most recent save game (so that if the auto-save is newer than any manually saved game, the cursor defaults to the auto-save).

Yeah, one auto-save slot can be used, even as a start on this. Btw, saving on a regular save-point should either delete the auto-save, or the engine should propose the most recent file per default. I mean not propose the auto-save if its corresponding slot is newer.
This also means the auto-save file will have to keep track of its mother slot somehow.

Whenever a user leaves a map, an auto-save is generated before the next map is loaded. This should be done as early as possible so that if a crash occurs in the process of loading the next map (which is easy to do atm if there's a typo in the lua map script), the user retains his/her progress.

Well no. The auto-save should be created just after the map has loaded, for several reasons:

• We are sure the map has loaded fine.
• The character is on a predefined starting position so we can save its position without any counter thought.
• the character XP/inventory/Event table hasn't changed yet while it can be problematic when saving at ending time.
• If the map after that one fails, no problem, we can load the beginning of that one as it is how I see the feature anyway.

An options entry should be introduced for enabling/disabling auto-saves (enabled by default). A nice-to-have would be a third option: Minimal auto-saves (ie, not bothering to auto-save on map transitions within a city, only on first entering the city). We can start naive with auto-saves on each map transition, and expand on this later.

IMHO, let's not overcomplicate this. Let's go with regular auto-save support whatever the map, and let us rather tell the engine an auto-save shouldn't be created on certain map transitions instead, for story purpose.
I'd still like the game to save my inventory when I get out of a shop, even if in a town, for instance but I wouldn't like the game to stuck me in a story transition map.

One concern is time spent in file I/O. It's quick on my machine (desktop, SSD, fast CPU), but may noticeably increase map transition times on other platforms (especially some of the more limited/embedded platforms people have gotten this to run on). If we run into this, a good solution would be either a new options entry or a compilation variable for streamlining auto-saves, spinning off an auto-save on a separate thread so map transition times aren't noticeably impacted.

This is a more general topic IMHO. Saving a game takes really few time and can be "hidden" just before the fade-in after the new map loading process. Moving certain thing on different threads shouldn't be taken lightly, and resources loading is not the first thing I'd move out. (I'd first move audio in a separate thread to be honest ;])

I haven't reviewed how save games work yet. If a save game isn't a complete snapshot of the game state (if, for example, player status effects are shaved off), there's some risk of abuse by users. Will need to explore this.

There is already a "risk" of abuse from players as the save format is in plain text, formatted for lua.
I don't plan and don't want any kind of protection system since the ones that will want to mod the game will always manage to do it anyway and it's easier for me to use save-game for debugging.
That said, yes, normally the save games should represent the game state quite well. :)
If you spot anything, feel free to tell.

Best regards,