Saving and loading games

[byorgey]

It should be possible to save the current state of your game, and then later to load from a saved game. There is nothing theoretically difficult about this, but it will take a good deal of engineering. Off the top of my head, a save would need to include.

• A version number, so that we can do something reasonable with saves created by a previous version of the game.
• The current state of the world:
  • The seed used to generate the world
  • Which tiles have been loaded
  • The contents of those tiles (either the complete contents, or perhaps just a catalog of the cells whose entity contents have changed from their initial value)
• All (active and inactive) robots, including their CEK machine state.
• Note, when saving entities (either in the world map, or in an inventory, or a robot entity), if the hash matches the hash of a standard entity, we only have to save the hash. Otherwise we must serialize the entire entity.
  • Note that for this to work well on old save files, we need to keep old/outdated entities around (perhaps in a separate old_entities.yaml file) so that we can load them.
  • Alternatively (this might be simpler), every save file could just contain a complete description of every entity which needs to be referenced?
• Probably various other fields of the GameState and/or UIState.

For loading entities and recipes, we use .yaml files, so that they can be easily human-editable. However, for saving the entire game state we definitely don't want to do that. Instead we should use some kind of binary serialization framework so save files will be as compact as possible. Since we can already load scenarios from .yaml files, it makes sense at this point to just double down on that and make save files use the same format.

Once we enable this feature, we'll have to be very careful about versioning things such as entities and recipes, world generation, etc., and keep around old versions of things (as much as is reasonable) so that we can correctly load save files produced by older versions of the game.

Note, a related issue is #7 .

[xsebek]

Thanks for making this issue! I think a more directly related issue is Generate world by tiles (#29).

I could then save loaded tiles and generate new ones in whatever is the current world generation function.
Thus, if I save the game on v1.41.0 and load it on v1.42.0, I could send robots to explore tiles with new features from version 1.42.0.

If the save was done per square, then changing world generation could introduce problems (:mountain:), but with tiles, I do not care what would have been on the unexplored ones in the previous version.

TLDR I would argue for the world state to be the seed and complete tiles, so versioning world generation is not a headache.

[byorgey]

Hmm, thanks, that's definitely worth considering! That would certainly simplify the need to keep track of versions for world generation. On the other hand, it might create weird seams at tile boundaries where e.g. half a lake on a previously loaded tile is suddenly right next to half a mountain on a new tile. But I'm not sure how important that is.

[xsebek]

I wonder if we could dramatically simplify this by implementing #29, #7 and give each entity a unique character and actually try storing the game as YAML.

- robots:
  ...
- seed: 0
- world:
  - tile:
    - x: 0
    - y: 0
    - map: >
      +------------------------+
      |   *       AAA    TTT   |
      | ~~ *    AAAÅÅ     TT   |

Most users likely will not change that many tiles, so the map will not take much space.

I guess with #7, robot definitions should not be an unbound number of lines either, but I do not know how many robots would need to keep a non-default state and how long that would be.

I still see this as viable option with some pros:

• the whole save might be less than a 1000 lines
• human editable
• simplifies Challenge mode #15
• simplifies Add structures to classic world #112
• easier to implement
• simple to support minor versions
• space conscious users can use text file compression

[byorgey]

I suppose it could be worthwhile to try a text-based solution. At the very least it opens up a fun new avenue for cheating ;-).

As for giving each entity a unique character, I think that would be rather restrictive (for example with #186 we now have multiple kind of mountain/vein entities with the same display, which is on purpose). But I don't think we have to do that: we could store a separate "entity palette" which lists characters and what entity they correspond to in this save file. We can try hard to use the same characters that are used for the actual display, so the saved map will mostly look the same as in the game. But in cases where multiple entities have the same character, we can just arbitrarily generate new unique characters for some of them.

Note that for the game state of robots we have to store their entire CEK machine state, not just their definitions.