LÖVE

A game in LÖVE automatically writes to the appdata directory or Library folder on Mac and some other directory on Linux. The user could easily find this folder with some research. From there they could hack their high score, etc. Is there a way to prevent this? I've tried locking the file in TextWrangler, but then LÖVE can't access it. It isn't a big deal, I was just curious if there was a way to prevent this or if there are any plans to change this in future versions of LÖVE as it is alpha software.

Alpha software or not, it's amazing right now!!!

Encryption

RedHot wrote:Encryption

Any idea on how I'd go about doing this...? I suppose there is no way to FULLY stop cheating, but encryption would do the trick! I'm sure people could decrypt it if they really wanted, but that's up to them

Eamonn wrote:A game in LÖVE automatically writes to the appdata directory or Library folder on Mac and some other directory on Linux. The user could easily find this folder with some research. From there they could hack their high score, etc. Is there a way to prevent this? I've tried locking the file in TextWrangler, but then LÖVE can't access it. It isn't a big deal, I was just curious if there was a way to prevent this or if there are any plans to change this in future versions of LÖVE as it is alpha software.

Alpha software or not, it's amazing right now!!!

Some things you could do:

• 1. Don't save highscores and similar data in plain text. Use some simple encryption (like with a LUA AES library).
• 2. Store that stuff on a server

However another thing to keep in mind, it is trivially easy to open a love application (on a mac, right click->show package content) and then edit the code inside your .love file. There are some options you have to compile the lua files, such as luajit, but even those can be reverse engineered. This means that someone (though they would need at least a bit of computer know-how) could edit your code and therefore have it save a modified value (as point 1 above) or send the server a modified value (as point 2 above)

You can't do much about point 1, but with 2 you can handle it like many multiplayer games do, where the client sends their inputs to the server, which then figures out how the player should be able to perform the actions they are trying to do, ultimately ensuring that they can't just tell the server "give me a super high highscore"

long story short: there's no perfect way to avoid cheaters, but chances are 99% of your userbase won't even know to look any further than an encrypted text file, so that should be enough for most purposes.

A more important question is: why do you care? It's a single player game. Let people muck about. It's not like you have to pay them based on their scores or anything.

Plu wrote:A more important question is: why do you care? It's a single player game. Let people muck about. It's not like you have to pay them based on their scores or anything.

What if I have an online game? Then you want to prevent cheating, because you want to keep things fair for other players. And it seems that in Love you only need to unzip the game, change one parameter (e.g. acceleration) and you have an advantage.

Przemator wrote:What if I have an online game? Then you want to prevent cheating, because you want to keep things fair for other players. And it seems that in Love you only need to unzip the game, change one parameter (e.g. acceleration) and you have an advantage.

Not just in LÖVE. You cannot assume the player does not control everything that happens on a machine they have access to. You prevent cheating by doing as much as possible on your servers instead of on the clients, because clients can be changed, manipulated and replaced (it can be other things than changing the source code of the client; the cheating players can use bots, keyboard macros, trainers, custom built clients...). Now, that will not be enough, so you'll probably want to have some diagnostic program running (on your servers) that analyses the packets you get from the clients, and check for anomalies --- things that are unlikely, that players probably shouldn't be able to do but do anyway --- and once the diagnostic program is reasonably certain the anomaly is not a fluke, but caused by cheating, it can kick the offending player (or ban it, or shadowban it, or any number of things).

Yep. The old programming paradigm... never trust user input. Validate everything on the server side, because you can trust it. That's really the only way. Trying to protect source code on the client side is a hopeless battle; you can never win.

Thanks for all the feedback! It seem's like all the questions I ask all tie in with each other. I asked recently about connecting to a server, and now I asked about cheating, and it was suggested to store things on a server! I'll probably just encrypt it if I even want to go as far as that. This was just for my own curiosity. Thank's everyone!

Just keep in mind that if you let the client send data to the server and then store it, it's still not safe. They could just fake a message saying they have a million points. The only way to make highscores actually safe is to run the game itself on the server (which is difficult). You can make it semi-safe by making it harder to cheat the scores, but really it's always possible to cheat unless the whole game runs on trusted hardware.