I think you understand this wrong. This isn't a save game invalidation, he changes constructs of the player, the houses, the npcs and so on. If an array has to be converted to a new one, this is often a lot of work, since you have to do it for the whole savegame. If you do this in a team, you can ask somebody else to write this code. But the new save game must fit to the new features, since he codes alone, he skips that part. Why not, it's not that it isn't fun to reopen all the game, just playing the game after you finished it already, what is the long term goal after all?
I understand unreal save handling just fine, and the specific portion I called out was the series of updates where he was adding progression. What changed in saves during that? Nothing. Literally nothing changed. Specifically, the progress gates are handled via global true/false flags. If you've done the thing, it gets added to the save as a string in a list. If you
haven't done the thing, it doesn't exist in the save, at all, in any shape or form. (From a technical perspective, unreal handles it so that the flag is true if in the list, and false if not in the list) There is precisely one flag in that list in a new game, and it's for Fern's first stage.
So, given the knowledge that the different game versions during progression updates were actually compatible with each other, what reasons could exist for invalidating saves?
- Force testers to run through the full progression each time, thus ensuring a larger range of testing and higher likelihood that someone encounters a flaw in the setup.
- Ensure that players who encountered a flaw in the setup and got locked out of prior progression are locked out and forced to start a new save where that will presumably not happen again.
- Spite
The third one is on the list because the developer is a person and people have emotions, and his reaction to being asked for ways to bypass the progression testing (during which he also disabled the all portals cheat) was to implement a cheat named "imma lazy sack" which, at least for a while, would drop big bold message to the effect of "I'm sure your mother would be proud" when used.
And, just to be clear: if he is changing game critical save arrays every single time the game updates? That's not exactly a good sign. The only time those should be getting updates with that degree of frequency is when a prototype is so new that the save format itself (and its interaction with the core systems) is still actively being built. That's not the kind of thing that should be relevant in the case of a changelog like:
Fluids are now displayed at each barn
Q hotkey can be used for quick actions at barns and breeding yards
Nephelym lists are now sorted alphabetically
Details are displayed by default when interacting with roamers
Project renamed from Radiant to OBF (this will make sense later)
Copy and paste added for faces in creator mode
Fixed Mega Slime's dialogue
Fluids display: That's a rendering/ui change, fluids have been in save format for ages.
Hotkey: that's a hardcoded hotkey to activate new UI. Nothing tied to saves
List sorting: Technically this could involve sorting them in the save too, but if you need to change your save format to sort a list, you really shouldn't be in gamedev. (It also doesn't need to change the format, the nephelym are stored in a list in the save and their order in said list is largely irrelevant)
Details display: yet another UI change. Nothing tied to save format.
Project rename: this involves a fair chunk of technical interaction between parts of the compiled/exported project, but if the save is involved here literally all that would need to change is the filename. (And generally, the save isn't part of this specific issue aside)
Copy and paste: yet another user interface change. No bearing on save formats, just on what the player can do.
Mega slime dialogue: this could theoretically impact saves, but everything tied to the mega slime is a global flag like the ones I mentioned above. Adding new dialogue choices or progression paths tied to the mega slime literally just boils down to adding a new flag and then setting up when and how it interacts with the dialogue. It would honestly be more work to invalidate the save and reset how the dialogue works overall than to fix it in a forward-safe manner that wouldn't invalidate saves.
And if a bugfix is big enough to warrant breaking changes in save handling, it's big enough to be spelled out instead of relegated to a "fixed miscellaneous bugs" note.
TL/DR: Derelict has a history of literally unnecessary save invalidation, so I am not inclined to give him the benefit of the doubt when saves are incompatible with a new version and nothing overtly related to saves has changed.
