Reply to Re: Dink with Lua scripting
If you don't have an account, just leave the password field blank.
You vastly overestimate the coding skills of this community. Decrypting even a simple text file is beyond 99% of our members' skills. Can the skilled people release a simple tool to do it for the others? Yes. Will they? I hope not,
I would probably write such a tool myself, because I very much dislike it if I don't have control over what my computer is doing. I might not release it publicly, but I would certainly give it to any programmer who asks for it.
If you consider your time wasted when people cheat, then don't start; either there are so little users that your time is wasted (and if you're unlucky there are still cheaters), or there are cheaters.
in theory an encryption tool can work with a unique key chosen by the developer right?
Um, strictly speaking, yes, but it doesn't help you. The program needs the key to decrypt the file, otherwise it is useless (a save file doesn't help you if you're unable to load it). But the program is under full control of the user. So the user can simply tell the program to write the unencrypted data, or even the encryption key, to a file.
Closed source people seem to think that by not releasing the source, they protect themselves against that, but that is a very weak protection. Especially teenagers (who you probably want to protect against most) are very good at figuring out how to use disassemblers and debuggers to get the information they need. The Dink community may not have enough members to contain one of those, so here it might actually work. But the reason it works, and you're not wasting your time, is that you're wasting your time, because there aren't many users.
There are a few things that can be done to create a fair tournament, but none of them may sound good to you.
Firstly, you can avoid the problem. What is the problem? That cheaters have control over their hardware, and use that control to make the program do what they want. If you make sure they don't control their hardware, they can't cheat (if there are no bugs). This means distributing computers to all players, which cannot be opened (because there's a person watching them, or because the computers will self-destruct when they try to open them). The guard scenario may work well in a classroom setting, for example. It does not work at all for something you want people to download from the internet. This is the only scenario where encryption actually works as protection of data (that can be downloaded over the internet by the trusted machine).
Secondly, you may make cheating too complex. If people need to upload a video of their playthrough which is checked by a human to see if it was done fairly, it would be very hard to write cheating code that isn't detected. This doesn't prevent all types of cheating; they can still find out the answers to puzzles without solving them. It also takes a huge amount of manpower when the community is getting larger.
Thirdly, what I think is the only realistic option (unless you're in a classroom setting), is to prevent the "benefits" of cheating. The cheaters want to have their names at the top of the high score list for everyone else to see. So instead of having a global high score list, you have a score for each person, and they can compile their own list of their score and those of their friends. If they think someone is cheating, they ask them and if they don't like the answer, they'll remove them from their list of friends. I'm sure people will still cheat, but nobody will care.
Actually, that third version is probably the only fun one for large groups anyway, because otherwise virtually everyone will be unable to reach the top 10 list; there's always someone with a higher score. If you add "friends of friends" to the list, you can still get a reasonably large list of competitors, without it being so large that competing becomes unrealistic.
I would probably write such a tool myself, because I very much dislike it if I don't have control over what my computer is doing. I might not release it publicly, but I would certainly give it to any programmer who asks for it.
If you consider your time wasted when people cheat, then don't start; either there are so little users that your time is wasted (and if you're unlucky there are still cheaters), or there are cheaters.
in theory an encryption tool can work with a unique key chosen by the developer right?
Um, strictly speaking, yes, but it doesn't help you. The program needs the key to decrypt the file, otherwise it is useless (a save file doesn't help you if you're unable to load it). But the program is under full control of the user. So the user can simply tell the program to write the unencrypted data, or even the encryption key, to a file.
Closed source people seem to think that by not releasing the source, they protect themselves against that, but that is a very weak protection. Especially teenagers (who you probably want to protect against most) are very good at figuring out how to use disassemblers and debuggers to get the information they need. The Dink community may not have enough members to contain one of those, so here it might actually work. But the reason it works, and you're not wasting your time, is that you're wasting your time, because there aren't many users.
There are a few things that can be done to create a fair tournament, but none of them may sound good to you.
Firstly, you can avoid the problem. What is the problem? That cheaters have control over their hardware, and use that control to make the program do what they want. If you make sure they don't control their hardware, they can't cheat (if there are no bugs). This means distributing computers to all players, which cannot be opened (because there's a person watching them, or because the computers will self-destruct when they try to open them). The guard scenario may work well in a classroom setting, for example. It does not work at all for something you want people to download from the internet. This is the only scenario where encryption actually works as protection of data (that can be downloaded over the internet by the trusted machine).
Secondly, you may make cheating too complex. If people need to upload a video of their playthrough which is checked by a human to see if it was done fairly, it would be very hard to write cheating code that isn't detected. This doesn't prevent all types of cheating; they can still find out the answers to puzzles without solving them. It also takes a huge amount of manpower when the community is getting larger.
Thirdly, what I think is the only realistic option (unless you're in a classroom setting), is to prevent the "benefits" of cheating. The cheaters want to have their names at the top of the high score list for everyone else to see. So instead of having a global high score list, you have a score for each person, and they can compile their own list of their score and those of their friends. If they think someone is cheating, they ask them and if they don't like the answer, they'll remove them from their list of friends. I'm sure people will still cheat, but nobody will care.
Actually, that third version is probably the only fun one for large groups anyway, because otherwise virtually everyone will be unable to reach the top 10 list; there's always someone with a higher score. If you add "friends of friends" to the list, you can still get a reasonably large list of competitors, without it being so large that competing becomes unrealistic.
