PlayerPrefs behaviour

Unity Engine
,
1

Hi,

We have a nasty bug on our live iOS app for very few users having their progression resetted after a crash, with no specific reproductions. For now, only iOS users have reported the bug, none on Android.

We use PlayerPrefs for saving the progression and just now, we realized that we never actually call PlayerPrefs.Save(), which might be the source of the problem. However, we never during development or testing have encountered this problem of losing progression.

The doc says “By default Unity writes preferences to disk on Application Quit” but after some simple testing, we noticed that PlayerPrefs seems to be saved even if we kill the application without ever explicitly calling PlayerPrefs.Save() and to my knowledge, OnApplicationQuit is not called on iOS (our app is for iOS 5.1 and above).

After further testing in a test project (tested on device, iOS 6.1.3, Unity 4.1.2f1), if we minimize the app it seems to save the PlayerPrefs (through OnApplicationPause?). If we change PlayerPrefs and make the app crash intentionally, then PlayerPrefs is not saved.

Is PlayerPrefs behaviour exactly the same on all platforms and as described in the docs?
If so, what could explain that in my test app, PlayerPrefs is saved even if PlayerPrefs.Save and OnApplicationPause are never called?
Finally, except for a player playing the game for some time without minimizing the app and crashing, any other clues as to why the PlayerPrefs would be resetted when relaunching the app?

We will definitively add explicit calls to PlayerPrefs.Save but would love to know the source our problems and the intended behaviour of PlayerPrefs.

Thanks

2

You kinda answered your own question :wink:

PlayerPrefs are loaded into memory at startup, all changes happen also in memory as this is much faster then writing to disk. PlayerPrefs will be saved to disk when ever you leave the application like ApplicationQuit but also on application suspend and probably more. Suspend is what usually happends on iOS because of the home button.

Now when your application crashes, it obviously won’t take the normal route of exiting and no ApplicationQuit/Suspend will be called thus no PlayerPrefs saving. Thats why they’ve added the PlayerPrefs.Save(), so you can occasionally manually save. Do this when you game is idle since its not fast.

In a perfect world you shouldn’t need to be using PlayerPrefs.Save().
Ideally you should fix the cause of the crash ofcourse :wink:

3

Well, I was just wondering if anybody else had corrupted PlayerPrefs or PlayerPrefs that we resetted. It’s probably our code that does something bad, but you never know. :wink:

Here are some behaviours that I have noticed on iOS 6.1.3 Unity 4.1.2f1

  • Make a change to PlayerPrefs, minimize the app, reopen the app, make it crash, PlayerPres saved.
  • Make a change to PlayerPrefs, immediately make it crash, PlayerPrefs not saved.
  • Make a change to PlayerPrefs, wait 15 seconds, make it crash, PlayerPrefs is saved. (new behaviour found today)

So yes, I will use PlayerPrefs.Save() at checkpoints to be sure I never lose too much if the app crashes. However, my issue would be that the documentation for PlayerPrefs.Save() doesn’t clearly state the behaviour.

4

Just wanted to say that our bug was that our code was doing something funky in very special circumstances and corrupted data was written in the PlayerPrefs, which resulted in player profile being “resetted”.