Norby wrote:It isn't impossible technically.
No, but the compromises necessary to make it work might not be pleasant.
Saving in space means serialising the state of all relevant game objects to the save game, then restoring them on load. The problem here - matters of programming all the serialisers and reference resolvers aside - is that a JS script is a relevant game object, so the current variables in all ship and world scripts must be saved. So, what happens in the following scenario?
1) Player saves the game
2) Player upgrades an OXP
3) Player loads the game
At the moment it's fine - the game picks up the new OXP, reinitialises the world script, and calls its
startUp
method to wake it up and let it do any further initialisation.
If we serialised all the values to the save game, then what happens is the OXP update gets overwritten by the values in the save. That includes the values of variables like
this.shipWillExitWitchspace
because we have no [1] way to determine which values in an OXP script the author is treating as constant and which they are treating as variables. Worse, if the player
removes the OXP, its scripts
still exist in the save game and still potentially get reloaded (or perhaps don't get reloaded ... either could cause a hard-to-diagnose in-flight bug).
Being able to keep the same savegame from release to release, and being able to add and remove OXPs freely without risk to the savegame (beyond a bit of bloat to your mission variables section) requires keeping the information stored in the savegame to a relatively abstract level. Allowing the player to only save in situations where changes beyond the abstract level are mostly unnoticeable is the easiest way to do that.
I can't think of an example of a game which successfully solves this problem - they all do at least one of:
- have short enough game lives that "restart to upgrade or change expansions" is acceptable
- risk irrepairable save corruption if you do change expansions mid-game
- don't allow expansions (or put extremely strict limits on what they can do)
- limit where you can save
Wildeblood wrote:I still think {witchspace jumps are} a logical point to allow saving.
More practical, certainly, but still extremely difficult. The main difficulty is that it would be a significant shock to OXPs which may be assuming at various levels that the game will load with the player docked. A lot of OXPs, especially older ones, use "first launch from station" as a trigger for various events, and there are probably a range of obvious and subtle assumptions about how game startup works elsewhere too.
Just allowing saving at non-main stations caused some difficulties, and this would be quite a bit bigger. e.g. what happens in the situation where you pursue a mission ship into witchspace, die, the game reloads ... and runs the
startUp
event in the new system from the save? How many copies of the mission ship end up in the new system, and what configuration do they have? There may still be the serialisation issues above associated with ships sharing the player's wormhole - I'm not sure.