Would not supporting save files be a bug?

[Tsukihime]

It is common for someone to add a new script and then suddenly none of their save files work anymore.


Some even consider it to be normal.


However, when it comes to game updates and patches, you likely have players that have already spent some amount of time on the game.


I consider any script that does not support old savefiles to be bugged and incompatible with the existing project.


Is it possible to write scripts that do not break save files? Of course.


Are there cases where it is simply not possible to avoid breaking save files? I'm not sure, but I don't think so.

 

[Dr.Yami]

Maybe some scripts would cause problems with save/load data, or might have crash(es) when load data.

In DataManager.load_game, it has a rescue there, I think we can temporarily remove that rescue and see what happens when load a save file that is not supported in new patch.

 

[Andar]

it depends on the script and the game project.


I agree that a lot of scripters are causing unneccessary problems by writing their scripts in a way that old saves break the scripts.


However, there are also cases where it's neccessary to force the player into a new game start simply to remove old structures that would take too much work to support.


However, the decision when to force a new game and when to support the old saves should be a concious one done by the game developer, and not forced upon him by scripts that ignore old saves.


unfortunately it's more difficult to write a script that can take old saves and adapt them to its new functions than to simply request a new game whenever the script was newly added - especially for new scripters it's easier to add new data into the regular setups of a new game than to check if the data exists in a save game and then manipulate those existing data structures into using the new data.


For example, a script that adds extra stats to actors - having them only in the actor initialisation makes simpler programming than to check the already leveled actors of a save whether they had the new stats or not and add them if the save was older than the adding of the stat script...

 

[♥SOURCE♥]

For example, a script that adds extra stats to actors - having them only in the actor initialisation makes simpler programming than to check the already leveled actors of a save whether they had the new stats or not and add them if the save was older than the adding of the stat script... 

You could create a method for the creation of the variables needed by the script. That method could be called in the initialize of the class (new game) or on demand when (a save file is loaded) the variables are not found.

def do_something # It is doing something. # Now it needs the variables from the new script. unless @one_of_the_variables_needed # Initialize variables needed for the script. initialize_script_variables end # Doing something with the variables.enddef initialize_script_variables @one_of_the_variables_needed = 4 @other_variable_needed = []end

However, when it comes to game updates and patches, you likely have players that have already spent some amount of time on the game.

Do you have any particular case (where a game update broke the player's save file, once the game was ready to play and not on development phase) in mind that you can use as an example?

Usually, scripts that are not compatible with old save files are added before game release, and an update to a script or any update upon release is unlikely to add new features and to request new data that old save files lack. During the development phase, having to start a new game is no big deal.

To answer your question, no, it would not be a bug unless you intend it to support old save files. 

 

[TheoAllen]

So far, this is my fave script to handles save file

http://forums.rpgmakerweb.com/index.php?/topic/18457-rgss3-object-reinitializer/

 

[Shaz]

I think once a game has been released, any changes should still work with save files, unless they're significant enough that you make the decision otherwise and state it to players.


I'm of the opinion that once a game is done, it's done. You don't keep going back adding more stuff to it and keep releasing it with more content. You make a game, then you move on to the next one. If you are making bug fixes, then you shouldn't really be adding new scripts, and any script mods should not break save files.


If you're still adding content and scripts, then the game isn't finished, and shouldn't be released. If it's released as a demo or it's clear that it's not the final version, THEN I think it's okay to do stuff that might break save files from the earlier versions, as players should know it's not in its final form and they may (likely) have to start over when it's actually released.

 

[Mithran]

Some scripts can fundamentally break save files because they change the layout of the save file itself - there is really no way around this, unless the script specifically includes legacy code to load old save files. Additionally, removing a script that added a class which has an object marshalled in to the save file will also break the save file, no real way around this either

Most scripts that "break save files", though, are generally because some variable, normally set to a default value by "initialize", does not exist when loaded from a save file (initialize is not re-run, the objects are simply loaded from the file). Instead of relying on initialize, I generally just wrap my variables to automatically grab a default value if one does not exist when it is encountered, and always use accessor methods to access instance variables.

def a_var @a_var ||= A_VAR_DEFAULTend(note: if the var is a true/false, you need a slightly different implementation, I use :true and :false symbols)As to whether or not this is a "bug" with the original script, it is more of a design decision by the person who made the script. The "proper" way to initialize variables is using the initialize method, but the above way takes minimum of effort and almost zero processor overhead to ensure development is not hindered by not being able to load old save files. Personally, I don't find there is any lack of clarity in tying conditional initialization to the variable accessor, but some people may feel different (or just not know or care that they are deprecating old save files). Personally, I use this method as much as possible.

 

[Kaelan]

I think once a game has been released, any changes should still work with save files, unless they're significant enough that you make the decision otherwise and state it to players.

I'm of the opinion that once a game is done, it's done. You don't keep going back adding more stuff to it and keep releasing it with more content. You make a game, then you move on to the next one. If you are making bug fixes, then you shouldn't really be adding new scripts, and any script mods should not break save files.

If you're still adding content and scripts, then the game isn't finished, and shouldn't be released. If it's released as a demo or it's clear that it's not the final version, THEN I think it's okay to do stuff that might break save files from the earlier versions, as players should know it's not in its final form and they may (likely) have to start over when it's actually released.

 ^ This, basically. If it's not the final version of the game (demo, alpha, beta, ,etc.), then you understand that when you download it. If it's still in development, maintaining cleaner code is more important than supporting old, incomplete versions of the game.

If it's gone through a proper "the game is done now" release, then you should do everything you can to avoid breaking any files.

 

[BadMinotaur]

I'm going to release an expansion to a project of mine to some Kickstarter backers, and the expansion massively improves upon the old combat system in a way not really supported by old saves. In this case, since I have intimate knowledge of what my own scripts contain, I was able to write a fairly simple converter so that if they use the old save with the new expansion it just finds what data it needs, converts it and when the player saves again it's all well and good.

That said, I didn't expect or plan for that and it was a massive pain in the butt to get working right. A lot of the suggestions here are great if you anticipate possible releasing an expansion or DLC that might break the old saves at some point, and I hope I get to use some of them in the future =)

 

[Engr. Adiktuzmiko]

Ruining save files during development is normal, it happens even simply because of design changes... but for an already "completed" game, any additional scripts via updates/patches/DLC should be save-file friendly...

As for the scripts themselves, I do think it's for the best if it's made to be save-file compatible as much as possible.