Context description of save files

[Xeno]

Hi There (noob alert)

With autosave being a puzzle (which one is what again? Did it roll over? _autosave: of what?) and none of the save files have game context information, I'd like to suggest adding some.

In my mind I see the following information needing to be displayed for each savefile:
Saved game time
Saved system (star system)
Saved dock (if docked)
Saved player money
Saved ship type (and id? name?)

And as if you are really interested, these would be nice to also have
Ico image of player character
Player character name
-and/or-
Details about ship (img, make, weight, 1st order cargo?)

Now some of these could be tacked onto the filenames themselves at save. But, imho, i think the save screen should interpret the save files and create a display table of info columns. This may also be an opportunity to add version control (or at least information) onto saves.

Also, I realize I only did a tenuous search for information about this topic and I'm new. If it's on the todo, just tell me to politely shutup.

[impaktor]

Also, I realize I only did a tenuous search for information about this topic and I'm new. If it's on the todo, just tell me to politely shutup.

It's in our minds:
#847
#2814

but you can keep talking here. It's the right place for discussion.

[FluffyFreak]

This would be good to have.
Does a save game have a header? Maybe we just need expand it, populate it, then read it back when making the list of savegames.
The UI can come later once we've got that working.

[eloquentmess]

If save games don't have headers, it ought to be simple to add them. The question at this point becomes: Do we add a backwards-compatibility layer so old save-games work with the newer system? And when do we take it out?

I'd say don't bother with backwards-compatibility. New code often breaks save-games. I learned today that the one I've been playing the longest no longer works, nor any of my others. So I started over. But that's just my opinion, and someone might feel more attached to their work in one of their saves.

If the star system, money, etc. are all included in the save file, then it ought to be simple to grab those pieces of information from a save game without requiring a header. But if they're all lumped together in a way that can't be read without reading the whole file, then headers might be better.

[robn]

I'd say don't bother with backwards-compatibility. New code often breaks save-games. I learned today that the one I've been playing the longest no longer works, nor any of my others. So I started over. But that's just my opinion, and someone might feel more attached to their work in one of their saves.

There's a bit of a fixation on preserving savefile compatibility at the moment. Its always been considered a fools errand.

A year ago I started work on a new savefile format (based on JSON, so a deep k/v store) that has easy upgrading as part of its design. I got a lot of the way through it, but got blocked on new-equipment, which has now been merged of course. So I could get back to it now if I had the time.

Anyway, that savefile format would make it trivially easy to add header information - its just some extra fields.

[Xeno]

I'm a bit surprised the savefiles aren't already in some JSON variant.

Are there any engine utils to *make* images? Not the infoface stuff, actually produce jpg or png images? There's nothing like an ico of something meaningful. If not... shrug. Just having a header read back would help. Maybe we can make a series of ship images to have it reference (pre-canned, but indicates what you're flying).

I don't really have any old savefiles yet. I guess I'm backward compatibility agnostic.

[FluffyFreak]

I'm a bit surprised the savefiles aren't already in some JSON variant.

Don't be, things that I'm not looking forward too are seeing how long they take to load/save and their size-on-disk. JSON stored as text K/V pairs are going to be huge and they need parsing.
Doing things as manual serialisation of binary values in specific order is common for games because the saved format file is MUCH smaller and doesn't require any parsing overhead. You just stream it out/in writing/reading bytes as you go.

Of course most games have a stable file format whereas ours is permanently in-development. Even having a mod installed and then removing it would break a save game.

Are there any engine utils to *make* images? Not the infoface stuff, actually produce jpg or png images? There's nothing like an ico of something meaningful. If not... shrug. Just having a header read back would help. Maybe we can make a series of ship images to have it reference (pre-canned, but indicates what you're flying).

Yeah we can save screenshots etc, might be fiddly to do but we could probably take a screenshot for autosaves or everytime you bring up the menu.

[robn]

Don't be, things that I'm not looking forward too are seeing how long they take to load/save and their size-on-disk. JSON stored as text K/V pairs are going to be huge and they need parsing.

During development the overhead was negligible. Also my gut feeling is that it doesn't have to be a problem simply because loads of performance-critical applications parse JSON all day long. There is faster serialisation protocols around if necessary (eg sereal).

Yeah we can save screenshots etc, might be fiddly to do but we could probably take a screenshot for autosaves or everytime you bring up the menu.

Screenshot might not be useful. What if you save while on a UI screen or something? I'd like to show a spinner of the ship and maybe a map of the current system. Just some visual cue.

[Xeno]

I'd like to show a spinner of the ship and maybe a map of the current system. Just some visual cue.

Something like this:



first draft, it's fat ugly and huge but it's got most of the right parts I think and if the ship was a spinner it might even be neat.