One of my play-testers encountered a bug that was caused by the game loading an old version of something. For example, they played v1 and when playing v2, the game crashed after the splash screen. I checked the logs and noticed the game was trying to load an old version of something. I told them to delete their user folder, and that fixed the game.
How do I handle this for future versions? I would have thought the Godot would use the newest version of something and overwrite the old version. Not sure why I thought that, but I did. Could someone please tell me how they deal with this problem?
v1 saved some assets in the users folder (user://)
v2 saves (at least some) of the “same” assets to the users folder
v2 assets have the same filename but have different data
This data is not backwards compatible with the v1 data
On first load of v2 it attempts to load user data and crashes as the data is not compatible
Is that correct?
If so, this is something you will need to manage yourself. You’ve got a few choices:
Use different filenames so v2 doesn’t attempt to load the old v1 data
Manually migrate data to the new v2 versions
If you don’t migrate it basically means users will “lose” their old data. If this doesn’t matter then using different filenames is probably the simplest approach.
You might need to roll a custom loading system that loads files that might change between versions. The issue you described it a very common game breaking bug for newer versions of games, especially when dealing with save systems.
For those kind of files, just check on game load if it adheres to a participant format, if not reformat it or update it to adhere to the new format.
Whenever you handle with delicate savedata or custom files that are locally saved onto a player’s device, I would suggest adding a field called “version”.
That way, you are always able to reference the file that you are loading into a potentially newer version.
With such a system in place, you can then write a custom (and maybe even automatic) file migration system that detects files with an “older” version which is then updated to a newer version with all its delicate changes.
In some games, save files will lose some properties, or gain new properties.
If a newer versioned game loads the save file and attempts to load properties that don’t exist in an older versioned save data, the game will naturally crash.
Thank you @gentlemanhal, @FreakyGoose, and @Locher for your responses. I really appreciate it, and I am sure future people will too! I only marked @gentlemanhal’s response as the solution, as it had an interesting link attached, but I wish I could mark you all as the solution.
What I am going to be doing is adding a version field and I am going to be handling it with my loading system depending on the version, this way I can make sure to avoid removing important data the player might want to keep. I am also going to be clearing the user’s cache on new game versions, just to be extra sure that even the shaders are refreshed to the newest version.
You could also save the local files into a separate folder for each version.
If the folder for the latest version doesn’t exist, check the older version’s folder and migrate the data. Afterwards remove the older version’s folder entirely.
But to be honest, you could achieve it in many different way and I believe you’ll find a convenient way to do it
Some things to consider when using the applications version for migrations.
You have no way of knowing when users are going to upgrade (unless its an online game with forced updates to connect). For example, a user might skip v2 and install v3. Meaning v3 can’t assume it only needs to migrate v2 data, it also needs to handle migrating from v1. This means the code will only get more complicated and bloated, as each new version has to handle data from all previous versions.
If a new version doesn’t require any data migrations it might get confusing if v4 is happily loading data from files with v3 in them or the path/file name. Especially if you only work on the game part time, or in a team.
This is why some migrations tools, like Flyway or Liquibase (database tools) actually version and keep track of migrations themselves.
Probably information overload at this point, but just some food for thought really.
(Yes, I’ve had a lot of issues with migrations in the past! )
Thanks for the suggestion Though I’m trying to reduce disk space usage as much as possible. Actually pretty proud of having my .exe be less than 300MB
)
Though I’m trying to reduce disk space usage as much as possible. Actually pretty proud of having my .exe be less than 300MB