LSO's: Best way to save game state?

12 posts

Flag Post

Are Local Shared Object’s the “best” way to create a saved game state?

Or would it be better to use a password type system?

In my current game there are about 600 variables (95+% boolean) I’d like to have saved in a game save, and I’ve contemplated using a password type system that uses at least a 10X10 (probably 11X11 or 12X12) grid of 64 alphanumeric characters where each character can hold five boolean states. The problem is this would require the user to cut and paste each time the game is saved/loaded. The upside is that there is no mysteriously lost saved data as it is all user controlled.

My question then is, what are some of the pro’s/con’s of using shared objects? Any opinions if they’d be a better way to go for a game save state?

Or are there other alternatives I’m missing?

Flag Post

In my opinion, Shared Objects are the best way to save any game data between sessions, since it’s the only way to do it (you can’t write files to the hard drive because of the sand box).

Making the user copy/paste passwords is cumbersome and outdated. The only question is whether you have the skills to implement the Shared Object.

What’s possible? If you do it right, you could have a “slot” system where the player can save their data to three different slots, so they can have three games going on one computer, like on Papa Louie: When Pizzas Attack.

Flag Post

.sol files are easy to hack. Making a game with those means Mrcreds will again be shouting “I AM KING OF KONGREGATE YAYEYAYEYAYE” until he’s shot or something.

Flag Post

Use shared objects for most items and server side implementations for more advanced stuff. Shared objects are basically cookies, so they can be deleted and dont persist across computers. Additionally, they are easy to hack as crushproof pointed out, though you can help reduce that by using some encryption on the values.

Most of the time you should stick to lso’s.

Flag Post

“though you can help reduce that by using some encryption on the values.”

Kinda good idea… The problem with encrypting the values is that it will be very obvious that it’s encrypted and it’s not much harder to decompile swf’s than lso’s.

If you do something like a checksum (surreptitiously – maybe even just xor the first half of the values, xor the second half, xor them together. have all three as variables on the lso, and hide it somewhere like in an array), if it’s hidden well then it may even stop the hacking xP You could even xor it with the kongregate username so that when testing off-site, one wouldn’t be able to obtain the correct checksum [too easily].

Data isn’t mysteriously lost. When newer versions of games are uploaded, they go to different locations. Overcome by putting it in a higher directory.

Base64 is a relatively good idea for booleans. I’d suggest a checksum at the end (or middle) so editing a random letter wouldn’t work.

Flag Post

If someone wants to cheat on your game that badly, that they are going to de-compile it and reverse-engineer your encryption algorithm, and generate a new data file, then I say let them have it… or, compile into an .exe.

Flag Post

Well, all you can do is at least deter people. That cuts down a lot of cases, as its often not worth more than the time that it takes to open an .sol editor and change a number/boolean.

Flag Post

If you want me to speak truthfully, a exe game is alot easier to hack than a flash game (with a memory editor) – You edit values ingame rather than outgame (save files – and lol I made a word). Also, anyone with the right tools (ollydbg, hex editor) can edit exe’s freely – Although ollydbg is extremely difficult to use :D Sorta… I can patch jumps on small games so that you always win or something (small = 5kb or less)

Anyways, checksum. now.

Flag Post

If you do use a checksum on your save-file, don’t give an error if the file is corrupted (ie has been hacked). Instead, this could move the player into a ‘safe-mode’, where although it is possible to continue it is mysteriously impossible to submit high scores or statistics. To do that, use a ‘broken by default’ system. Then you can hide your checksum validation away somewhere, which fixes your submission routine.
(Incidentally, this is from a theoretical perspective, I don’t know what you can do with Flash specifically. Maybe you’d be limited to using variables which must be in certain ranges to be valid.)

Furthermore. If you think about what a save-file hacker does – they will make a minor change ingame, then see how that affects the save-file. Firstly, if you convolve all your data together, a small change would affect everything, at which point they would probably go off and hack the program instead. OR, you could use an error-correcting code. There will probably be some positions which you could arrange to be different every save. Times saved can increment, time in-game can go up, x and y positions would be different and so on. The hacker will figure these are not relevant and ignore them. So add one more, which is actually parts of these convolved with your high-score (and other sensitive data). Then you can work out what the hacker has changed, and change it back. You can do this only on score submission, and only to the score uploaded, not the one you display in-game.

Flag Post

I have a game where I actually do this, and I use a dynamic key for encrypting that is different for each object saved (in addition to a few other ways it changes). Since it is dynamic, the encrypted variables cannot be copied and pasted from another computer or another save slot without causing the rest of the values to be corrupted in some way and making the game throw out the invalid save. They also would have to figure out the method used to create the key on top of the method of encryption.

Its actually a cool system and works great. I know for a fact that if someone tried hard enough, they could hack it. But that doesnt matter to me, I’m just trying to slow down the .sol kiddies – which it should do greatly.

Flag Post

Wow, Lysis and Nabb, you guys seem like you know your stuff, and that sounds like a great system Coder… scratched head… I didn’t realize the extent to which the games were hacked, but I think these suggestions are great! Now I just need to figure out how to convolve data and use exclusive ors … any good books on that topic anyone?

Flag Post

*cough**cough* (off the top of my head)

Lysis → Agreed. That’s basically the whole idea with memory hacking anyways (search for a value, increase the value ingame, sieve through those that matched, etc.) – What you say about finding what has been changed is an excellent idea – However it could backfire if the hacker edits the checksum (the other values would change?)

Indie → I’m suggesting that you use steganography instead of cryptography for security (well a little bit combined). The point of using hidden checksums (as long as you don’t have a function called stopHackers()) is that a hacker wouldn’t have a clear direction to head in, and may choose to find another game to hack. xor was just an example of a simple checksum.

If you’re going to protect save data, make sure botting and glitching is unprofitable – A chain is only as strong as its weakest link.

(kinda off-topic, but I would consider myself getting a really high score in numberhash hacking – in the sense of programming.)