LocalStorage not persistent

[Finders_Keepers]

I want to know how to keep the localstorage save data persistent in my game. If i reset my device the locally stored data is lost Eventhough i'm not clearing the cache. I'm trying to save highscore and stuff. How do i keep it persistent should i keep some log on the server?

I'm running the game on Chrome fyi

[mattstyles]

Local storage can always be revoked by the user, which is what you are doing. I think I remember that some browsers might decide to clear it if they need to, this stack overflow post which refs Chrome and Firefox docs (although its an old post) implies that on desktop (well, in browsers, its webviews that are maybe a little more volatile) you're largely fine to consider it persistent but if you're targeting webviews (in particular, iOS) then it could be cleared more regularly.

If you really want it totally persistent, and away from clearing by the user, then you'll need to implement a server solution. Anything on a client device can be wiped at any time by the user (well, most things).

[Finders_Keepers]

ikr, the data is being wiped out, i see many posts about localstorage here but server side handling for save data is missing. How would i go about saving it on Xampp which i use. Do you know phaser specific php side coding tutorial i could benefit from?

[mattstyles]

No idea with php and xampp but good way that keeps things nice a separate is to create a RESTful service (using any language, there will be tuts for any language), create yourself two endpoints, one to post to and one to get from, ping stuff you want to save to the post route and save it somewhere and return an id, ping that id to the get route to go and get it back. super simple.

The only tricky part here (which is tricky however you look at it) is getting back the id next time which would require the user to do some work to either login (this could just be enter something unique which identifies them) or save that id locally i.e. in local storage! Which would bring you back to your issue of having local storage nuked, but, in that case, the only option is that the user has to 'log back in' using something unique. There is no other way if you're worried about persistence on the client.

There are a couple of different flows you need to handle to make this all nice:

Anonymous

1) User hits your site. Attempt to grab an id from local storage, but find nothing. User does stuff. You send some data to your save endpoint, that endpoint saves that data somewhere and returns an id. Save that id into local storage.

2) User leaves your site and re-enters it (hence, killing all memory). Go back to #1, but now you'll find an id in local storage so ping your endpoint to go get the data, patch it in to your game state and continue.

Pro here is that this is all transparent to the user, they just hit up your url and play your game, when they hit it again they can start where they left off.

Big issue here is that the user (who is anonymous) is tied to the client i.e. to the browser and to the device they are playing on.

Another con here is that your server does not know who all this data is coming from so it'll keep recreating state. Eventually this will become an issue. Say you save every minute, after someone has played for 30 mins you'll have 30 saves, if you're stuffing this into a DB that'll be 30 entries, if the user did not do a great deal in 30 mins they're basically all the same. You could have a job that deletes them all after a set amount of time, infact, you'd probably need it.

Logged in

1) User hits your site. You hit them with a log in form, just a single input field for now. User enters something (lets call it an id) in the form and submits it. This triggers a ping to the get endpoint, if there is a data entry against that id then return the data, otherwise this is a new user so return default state or return nothing and let the client handle setting up default state. Store this id in a variable in your code i.e. its in memory and lasts as long as the user is on your page.

2) User does stuff on your site, you ping data using the id and save that data.

3) User leaves the site, comes back later. Proceed to #1 again, but now the server can return the previous data, based on the id and the user can carry on playing.

Big pro here is that the user can play on any device, so long as they remember their id they're golden.

Another pro is that the server knows who is sending stuff to it so that after 30 mins it can just keep saving the state against the id, meaning there is just the one in the server.

You can still save that id to local storage to make this all more seamless for the user, but now you have the backup that the user can manually enter the id if the local storage gets wiped for whatever reason. Of course, you might want some sort of recovery mechanism if the user forgets their id, but that can get trickier still.

Big con is that if a users' id is 'Dave' and another person tries to use that id then whoever 'logged in' last wins, infact, its actually worse than that because they'll both be saving data to the same id, if user 1 leaves and user 2 keeps playing and then leaves, if user 1 comes back they'll get user 2's state. Bad times.

Logged in with password

In order to try and work out multiple users using the same id you have to do some other stuff to try and make sure users are unique. A password of some kind helps to keep users unique, although the same thing would happen if two users logged in with the same user/pass combo (although this should be extremely rare). You could also try and trigger by IP, but that won't actually work as IP's aren't static (take, for example, being on your mobile device and moving around as you play, say, on the train, or you just play from multiple places, home, office etc). Of course you don't want to save the password anywhere (which would require the user to log in manually with every visit) but you could implement revokable tokens which you can store locally (check out oauth for good practises and schemes for doing it).

If you really want to go this deep do some reading on implementing oauth, or even 2-factor authentication, although both of these sound like maybe overkill for what you want, but, however you do it, if you're saving remotely you need to try and solve the double user problem mentioned earlier.

[Finders_Keepers]

This is amazing. You really went to town on this one. I mean It was overkill when you mentioned RESTful service. I know about it only in passing but this is too much for a little ol' game saving highscores. Thanks for a brief introduction to databases and server side programming. I'm going to stick to localstorage for now.
I super admire your clear language here and the fact that you took the time to write a blog post.

I was expecting a few lines like POST in the html document. So this means i'm good for now. Thanks

[spinnerbox]

Local storage can be wiped out by just one call

window.localStorage.clear();

If you want the data to be saved, you must use a database.

Phaser is pure javascript so it cannot be used to save data to database directly, but since it works in the browser sandbox, AJAX API is available. I would suggest using JQuery AJAX API which simplifies calls to a server side scripts. Yes PHP is a server side technology and you can save data to database with it but you must first create an AJAX call with proper configuration so that the server knows what to do and where to save.

If you were to load Phaser and JQuery in the same page you can just use pure JavaScript function to send AJAX call and trigger it when pressed a Phaser button. Its pure JavaScript, there are no obstacles.

You can use MySQL for testing but you also must create a database scheme.

Also I would recommend CodeIgniter MVC because it has lot of premade tools for creating CRUD(Create Read Update Delete) apps

[Finders_Keepers]

Are these features necessary for implementing on an arcade game? With the intent to release on a game platform like Spil? Should i expect to create a service that communicates via AJAX calls on their platforms?

[spinnerbox]

Can you share a link of this Spil thing?

Is it this one: http://www.spilgames.com/ ?

Ususaly sites that allow uploading user made games, have their own web service, so all comes down to calling their web service API functions to upload achievements, score, etc...

Kongregate is one example: http://developers.kongregate.com/docs/api-overview/client-api

[Finders_Keepers]

Precisely what i thought. Kongregate is one example but i think all of the paying platforms must have their own web service API.to be relevant
Also If you know about other spil named sites for html5 gamedevs to sell to, Do tell.

[spinnerbox]

I have never heard about Spil, that is why I asked about link. The one I mentioned, I found it by just Googleing. Check their docs for API and for developers.

You could also try Google Play Game Services, which makes you use a google account.

Also Facebook has their API for uploading games.

Newgrounds allows only Flash/ActionScript3.

 

[mattstyles]

All of these services that host games for you work the same way, they expect you to only ship client-side code, which means you need to use XHR to make calls (use fetch, its much easier and better, but you'll need a fallback if you plan on targeting older browsers, which some platforms might require). You could still host your backend services elsewhere and make calls, although you'd need to handle cross-origin (this is simple enough), the platform apis presumably don't have the cross-origin stuff but you'd still communicate via XHR with them.

Does anyone know if there is a service like those mentioned that allows uploading server code? Presumably not as its a much harder thing for them to support and largely unnecessary for the types of games they serve.