search

Attnam / ivan

Iter Vehemens ad Necem - a continuation of the graphical roguelike by members of http://attnam.com
GNU General Public License v2.0
301 stars 43 forks source link

New file format for saves :HELP: #507

Open jakwings opened 5 years ago

jakwings commented 5 years ago

The current format is not truly cross-platform (sizeof(type) & endianness) and it often invalidates the old saves just because a new game state is introduced.

The new format should at least support:

  1. variable-size data (e.g. items)
  2. nested data structure (e.g. creatures and inventory)
  3. an easy way to provide default values (for updating the old saves)

Optional feature:

  1. cross-compiler & cross-platform
  2. schema validation for spotting corrupted data (and auto-fix?)
  3. pretty-printing with dev comments

I prefer binary data, so that we don't have to deal with text encoding and syntax.

Just a proposal for now, the most difficult jobs are:

AquariusPower commented 5 years ago

what about tokens? https://github.com/Attnam/ivan/pull/342#issuecomment-388576383 unique delimiters to the beginning and ending of a sector. so sorted/ordered data would not be required one day :) it would be "load on demand", "save at will" (and "fireball in the golem!" xD)

jakwings commented 5 years ago

Yes, a simple improvement is to prepend the version number (edit:) AND a resource identifier and the size of data to every sector but we still keep the order in mind. Then the rest is to provide default values for missing data. Unimportant data can be just discarded even though it can make the game more difficult because some things suddenly vanish into the void or get burried in the walls. If the changes make it unable to reach the endgame, then it is time to drop support for old saves and clean up the code.

If the sectors are unordered, how do we make the delimiters unique and unchanged when new data kicks in? The delimiter can be contained in the new data.

EDIT: hmmm... I still feel it is easy to go wrong by this method.

AquariusPower commented 5 years ago

Instead of expect the data to be there and then load it, as in: it first loads the map, and for each square loads items and a character; It would read the token/resourceID and based on it would use the appropriate loader: item, character, square etc. I think, not sure, this could help on letting old savegames be compatible with new game versions. What it could do is essentially what XML is: ID+DATA, but in binary mode! But one must weight what is doable, how much trouble this data save/load design would be to implement/maintain? So, this is just a scratch suggestion :)

jakwings commented 5 years ago

This looks like a good candidate: https://github.com/liteserver/binn

It works very much the same as the current Save/Load method. Just more robust.