Limit save scumming

[JJM152]

There are probably three main approaches to this:

• [ ] Use a seeded RNG built into sugarcube. Seed the player on creation.
• [ ] Some data can be saved to the player state as needed, like we do store inventories. Challenge - you have to forces a state save in the story engine for any sort of permenance.
• [ ] Use the Web Storage API, particularly sessionStorage to serialize variables to.

The prime candidates for things like this are not just shops, but also some of the mini games, particularly things like the slots which actually break if the user reloads their browser. Reloading on any kind of gambling is just plain lame. Lets see what we can do about it.

[ezsh]

Use the Web Storage API, particularly sessionStorage to serialize variables to.

Does it mean simply bypassing the SugarCube serialisation layer? As far as I am aware, it uses Web Storage too.

[JJM152]

It does, but it ties the save/load to the display of the passage as part of the state history in regards to a passage, which is very limiting.

There's no problem with also using the WEB API to store data, just give the keys unique or hashed names and for my purposes, the session storage is enough. We don't need to persist between browser sessions.