I'm using PlayerPrefs to store the players' highscore on each level, but in the next version I'll change how scoring works.

  • For example, In the old version players could easily reach 250 points on a specific level, while in the new version it's difficult to reach even 50.

I would like to delete PlayerPrefs data which were saved during earlier versions, because scores that high would cause some issues in the newer version.

What is the best way to safely maintain compatibility of saved data between versions, but also be able to reset them if a new update requires it?

My current solution is that from now on I use new keys to store the data, for example by adding the current version to it.

  • For example, in version 2.0 the data that was originally saved with the key "score-Level8" would now be saved with "score-Level8-2.0".

This way the player's progression gets "reset" after an update, but the old saves remain until another game changer update comes, and I have to increase the version part of the key from 2.0 to 3.0.

This feels a bit error-prone and unprofessional.


1 Answer 1

  1. Save in your playerprefs the version you are using.
  2. Have some migration function in case your current version is higher than the saved version.
  3. Always migrate only one version, in case saved version is 1.0 and current game uses 4.0, you should migrate from 1.0 to 2.0 to 3.0 to 4.0 without skipping a version.
  4. You can either adjust the score on migrating or just wipe it.

If you change the name of the key, you might run into troubles with backwards availability. Your user might not always use the most current game version and you would have to search/ guess all past naming schema. By keeping the same name and a separate version key, you can handle the loading of keys according to the version.

  • You have to keep the loading function of each version you have ever created of your playerprefs for true backwards compatibility.
  • You should not override the old data before you successfully migrated to a newer version in case something goes wrong in the middle of converting.
  • You should migrate all data at once to not get inconsistent fields between versions. You can migrate the data the first time you need to access it but usually at startup of your application it is a good idea to check if it is up to date.
  • \$\begingroup\$ This is a good strategy to use, but it might be worth pointing out that it's important to run that migration on all saved data at first load if the version is newer - don't want to have a nice migration system in place to wind up with data intended for different versions of the app 😀. \$\endgroup\$
    – Joe
    Sep 2, 2020 at 13:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .