Hacker News new | ask | show | jobs
by sbov 4601 days ago
I've worked on a few flash games in my free time. Ultimately since the game code resides in the client, it will always be feasible to cheat. That, of course, doesn't mean you can't deter some.

One of the things that kept people from snooping around was encryption. All communication went to 1 vaguely named endpoint with 1 parameter, which was a an encrypted list of the parameters and the action to take. This will deter some, but not others.

At the start of a game, the client had to contact the server for a key. This changed each time you played. Any score submission required this key - if it was wrong I ignored it. Only 1 score submission per key.

Note that you have other useful information now: you know how long they were in game to get their score. I flagged scores that were abnormally high for the time it took to get them. I would then review them, and based upon their score history hellban them - they could still play, but no-one saw their high scores except themselves.

If Candy Crush did something similar, they would likely catch you. You wouldn't even know until you gloated and your friends said they can't see your score. Some people who got hellbanned would contact me, and I'd give them a free pass.

Of course you could cheat and get a normal score in a normal timeframe, but I didn't care as much about that.

Beyond trying to thwart cheating, I'm a big fan of cheating in games myself. It's part of why I enjoy eve online so much, because they encourage the usage of 3rd party tools more than any other game I've played.

The most extensive thing I've programmed for cheating is probably a custom MUD client to facilitate multiplay. The clients report to eachother information they know. All clients keep the state of the group and the things I'm fighting. They also keep track of which client can do what, so I can type into any client that I want to heal someone and the program will figure out which client is able to do that, and tell it to do so.