Thanks to the developers! (& suggestion for savegames)

[nick]

Plan for first stage:

* Transfer existing structure to JSON tree.
* Int32 enum object types - use associated strings instead.

Is this OK? Or do you think there are any other savegame data changes that should be done in this stage?
[Edit] I'll draw up a plan before i start though, and I should think that'll prompt a few questions.

[DraQ]

I think the worst thing about how saves work is galaxy generation.
Pioneer is a very progress-centric game, its gameplay is tied to the notion of getting more cash, better equipment, more reputation, etc.
Restarts are inherently painful.

Now, having some data missing from legacy saves isn't that bad if default values can be provided. Having illegal data, OTOH is going to be a problem. On one hand Pioneer needs better generated space badly, on the other it cannot or at some point in the future will be unable to afford improving it.

I think we should have some sort of cascading fallback for illegal values as well, for example if system doesn't contain the port player is supposedly in, put player in a random one, if there are no ports, but it was inhabited when the game was saved, put player in random port in nearest non-hostile inhabited system.
Worst case fallback would be player in starting location but retaining at least general reputation and monetary equivalent of their ship+equipment.

[impaktor]

Moving the player around like that would mean any mission deadline they have might be missed, thus causing reduced reputation, plus other unforeseeable effects.

lwho has been working on the galaxy code, and the aim is to have a "stable-galaxy" that is rarely/never? updated, and a "dev-galaxy", where we can add stuff freely. The player can choose which one to start a new game in, if I'm not mistaken.

[DraQ]

Moving the player around like that would mean any mission deadline they have might be missed, thus causing reduced reputation, plus other unforeseeable effects.

Better than having to start anew.

Having separate development galaxy doesn't solve the actual problem and only slows down the process of improvements trickling down into the actual game people play.

We can always just clear offending mission and mission relevant stuff (like cabin occupancy) if such fallback is triggered (or better - ask player if they want it, unless quest relevant object is no longer valid, then do it automatically).
Maybe notify players which updates may trigger fallbacks (so basically last version number up to and including current that may invalidate save data) and advise them to complete any missions and dock before updating.
That's way better than telling them "hey, we have this awesome new feature but will wreck your progress if you update - HARHARHAR".

[nick]

A fallback to nearest or starting system while preserving reputation and monetary equivalent of ship+equipment would be fine for me (it's starting from scratch that I'd want to avoid!)

[laarmen]

I guess I could hack a function that would dump all needed info in a json blob on stdout, and another that would just parse it and put you where you want to be with the stuff that you want. You'd still have to paste the json blob in the Lua file (Lua can't access the filesystem, IIRC, hence the dump to stdout), and you'd have to keep the old copy of pioneer when you upgrade to be able to make this poor man's save in case the save version has been bumped.

I'm not promising anything though, my plate is relatively full ATM. At the moment I'm trying to get the game to properly load the existing savefiles :-)

[DraQ]

I guess I could hack a function that would dump all needed info in a json blob on stdout, and another that would just parse it and put you where you want to be with the stuff that you want. You'd still have to paste the json blob in the Lua file (Lua can't access the filesystem, IIRC, hence the dump to stdout), and you'd have to keep the old copy of pioneer when you upgrade to be able to make this poor man's save in case the save version has been bumped.

I'm not promising anything though, my plate is relatively full ATM. At the moment I'm trying to get the game to properly load the existing savefiles :-)

But why have savegame versioning at all? Why not have fallback mechanism(s) triggered when the game encounters illegal values or fails to find critical information in the save file?

[FluffyFreak]

Because there's no way of doing that.
You're reading a stream of bytes that have to be in the correct order.
Almost no way of telling if what you've got is valid or invalid when you read it, and if you did what would you do with it? How do you fix it up?

[DraQ]

Because there's no way of doing that.
You're reading a stream of bytes that have to be in the correct order.
Almost no way of telling if what you've got is valid or invalid when you read it, and if you did what would you do with it? How do you fix it up?

Switch to some sort of TLV encoding format?

Have each record comprise of fixed* length Tag telling what it is, fixed* length Length telling how many bytes it takes and Value encoding whatever it's supposed to encode, taking as many bytes as specified.
It's easy to nest too because one record's value can encode its own TLV triplets and it's flexible because it doesn't need to depend on any particular ordering of save data and may ignore or react to unrecognized tags as needed.
It will bloat the saves up a few bytes, but it shouldn't be anything significant - you can encode up to 4GB record length in 4B, and up to 4G distinct tags (which is absolutely nuts, but let's say we can't come up with a sensible number) using another 4B, is 8 extra bytes per encoded value in save file that bad? In some case it can save us space enabling going from fixed length fields to variable length ones.
I haven't looked into Pioneer's save structure, but I expect it to consist mostly of bigger chunks of information than great many loose ints (or bytes).

*) Variable length is possible too, but you need some way of telling whether or not the next byte is still part of Tag/Length, this may involve something like having a chaining bit in each byte which leads to some minor inconveniences like having to discard every n-th bit (typically n=8 if you want chaining bit in each bye) before obtaining actual value, which implies bit operations and general low level mess, but still nothing terribly arcane.

[nick]

I'm getting to grips with JSON. I like the syntax.

Here's our savegame file so far:

Code: Select all

{
   "galaxy_generator" : {
      "name" : "legacy",
      "version" : 1
   },
   "leading_signature" : "PIONEER",
   "version" : 80
}

The ordering is now alphabetical, so "leading signature" isn't exactly leading anymore.

JSON "Number" can be used for integers and some floats, but other types such as quaternian will have to be converted to string prior to JSON serialisation, and the string parsed when loading. I'll write functions for these.
[EDIT] Actually a quaternian can be a JSON array of 4 floats.