What does this mean for me? You will always be able to play your favorite games on Kongregate. However, certain site features may suddenly stop working and leave you with a severely degraded experience.
What should I do? We strongly urge all our users to upgrade to modern browsers for a better experience and improved security.
We suggest you install the latest version of one of these browsers:
Kongregate is a community-driven browser games portal with an open platform for all web games.
Get your games in front of thousands of users while monetizing through ads and virtual goods.
Learn more »
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?
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.
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.
“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.
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.
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.
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.
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.
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?
\*cough\*dareyourmind.net hackits.de hackquest.com bright-shadows.net\*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](http://www.kongregate.com/games/MrcredsAlex/numberhash "lol mrcreds") hacking – in the sense of programming.)