On Windows, the PlayerPrefs location depends on the company name and on the product name. Is PlayerPrefs product specific on WebGL as well?
The answer is no. I’ve done some testing. I am confident to say that PlayerPrefs is not product name specific. Different products can share the same key. However, unfortunely each different Kongregate upload have a diferent access path. This means that if I put the new game in the place of the old game, PlayerPrefs would achieve the desired effect, but for obvious reasons this is inconceivable.
The tests methodology:
I have created 3 different builds in the same project. They save or load with the respective commands PlayerPrefs.SetString(“EricCardTest”,“Success”) and PlayerPrefs.GetString(“EricCardTest”,“Failed”).
Build number - Build name- Functionalities
B1 - Game1 - Save and Load
B2 - Game1 - Load
B3 - Game2 - Load
Then I’ve done 5 uploads in the respective order on two different Kongregate Games - K1 and K2
Build Number - KongGame - Status
-
B1 - K1 - Failed, then Succeeded. (First run was used to save data)
-
B2 - K1 - Succeeded
-
B2 - K2 - Failed
-
B3 - K1 - Succeeded
-
B3 - K2 - Failed
Conclusions:
Because, uploads 1, 2 and 4 were a success, PlayerPrefs does not differ project names.
As all uploads in the game K2 were a failure, PlayerPrefs (at least on Kongregate) uses not only the domain(www.kongregate.com) and port, which is the same for all games, but it does use something else. Prehaps it uses the full URL?
Like pretty much everything that lives in a browser is bound to the domain / URL of the page. So even when you host the exact same game on two different webservers / domains, they can’t access the playerprefs of each other.
As you can read here Unity uses the IndexedDB API to store the playerprefs for WebGL builds.