Well, yesterday I asked on anti-cheat JS, and confirmed what I kind of already knew that it's just not possible.

Now I wanna measure roughly how hard it is to implement a server side checking that is agnostic to client input, that does not mess with the game experience so much.

I don't wanna waste to much resource on this matter, since it's going to be initially a single player game, that I may or would like to introduce some kind of ranking, trading system later on. I'd rather deliver better more cool game features instead.

I don't wanna have to guarantee super fast server response to keep the game going lag free. I'd rather go with more loose discrete control of key variables and instances. Like store user's action on a fifo buffer on the client, and push that actions to the server gradually.

I'd love to see a elegant, generic solution that I could plug into my client game logic root (not having to scatter treatments everywhere in my client js) - and have few classes on Node.js server that could handle that - without having to mirror/describe all of my game entities a second time on the server.

3 Answers
3

To continue from where we left off - the ideal solution is to do all the important work on the server. Since you haven't really said what your game is (Action RPGs can be along a wide spectrum) here are thoughts on how to hide the delays for the user without compromising security in a general way.

It is worth it to investigate what working on games in the DOS era was like. A lot of the solutions that were devised to do an RTS on such limited hardware apply here for the delay introduced because of HTTP.

It is worth bearing in mind that not all games can be made this way. It doesn't make much sense for many of the more complex action games to do everything on the server. However there are some general tricks to speed things up:

Use Comet/Long-polling AJAX for anything the server does independent of the player. Monster movement, timed tile falls in a puzzle game, responses from the AI engine.

Liberally separate calls from responses where you can. It is tempting to calculate a path with A* on request, but it will be better if the task is broken into multiple steps. Step one just says "Yes, you can travel in that direction." and then over Comet, after the path is calculated, the unit is updated with proper path directions.

Build the delays into your game design. If there is a long delay for units to start moving, have them do a little salute or something before they move. The extra time it takes to do that will cover over the delay if you can do nothing else to remove it. (Which you can, see above and below)

Make use of the extra processing. Like doing the pathfinding on the server, you can make the client side's job easier by doing most things on the server.

Once critical things are being done on the server, you can in most cases get away with doing double-checks on less-critical things. With unit movement, you can start them off in the direction clicked, so long as the final path only comes over the wire.

Make sure you perform any economy change that is difficult to reverse on the server. This includes changing resources in an RTS, spending coins on items, gaining score, anything that has a value and a quantity. Changes to unit damage happen on the server and are passed up. Changes to HP in a turn-based-rpg are passed up.

Make sure you retain all economy values on the back end and only perform actions on that model given the NAME of the action and not the numbers involved. If Tom the Barbarian has just made an attack on Ginger the Kobold, All the numbers for the attack should be taken from the server-side model of the game, not the client side. Then the final HP change is sent up to the game.

Separate animations from actions. Tom the Barbarian's attack is a big swing that takes .5 seconds to complete. That's .5 seconds you can use to get the results of the attack from the server. If the action was a cheat, then the kobold just doesn't take any damage. Peace is restored to the universe.

There are no silver bullets here. Network gaming is some of the hardest stuff you can endeavor to build as a programmer. And you will mess things up. Keep your source un-obfuscated and offer in-game or out-of-game rewards to people that help you find errors with the game. Rather than cheating, some of the crackers will turn their exploit in for the bounty.

I can't thank you enough. Well, it'll take a while for me to digest all you've said - I was already working on planning my client-server communication architecture that has some of the stuff you pointed on it - I'll post it as soon as I develop it a little bit further. And as curiosity just think of my game as a Monster Hunter Demake - 2D Top Down with no leveling/exp - very equip/loot centered. And it's not really very fast paced - not as fast or flooded as Diablo - more A Link to the Past pace.
–
Billy NinjaSep 21 '12 at 14:39

@BillyNinja Good luck! :) Sounds like a great game. Don't forget to link to it in your profile!
–
DampeS8NSep 21 '12 at 14:43

Since it is a single player game, you can do it without any lag at all (assuming you send/receive asynchronous messages).

coming to difficulty, its fairly simple implementation. All you do is cross check the action (like price, item available etc.,) which 99.99% will be valid.

Now you decide what should happen when some thing fishy happens (like something tried to buy without sufficient gold), usually your client should handle this first (by disabling to buy without sufficient gold or prompting a message) and your sever next will handle the hackers/cheaters by double checking it.

Best way is that you don't wait for server response, its unnecessary to wait for confirmation from server that the action is valid. But when when you receive the response that an invalid action has received then you can prompt a message saying "something went wrong in the server, reloading..." and reload the page. Never prompt a message "caught you cheater" or something because it could be a bug in your code. Just log such events in your server and analyze the scenario by simulating the same scenario in your environment.

This can be dangerous, a crafty cheater can simply disable the checks with the server in the code and get away with a lot before being detected. It is best to also do critical things only on the server.
–
DampeS8NSep 21 '12 at 14:08

1

lets pretend, the pro hacker disabled server interaction completly, what is going to happen? lets pretend he level up to max cap, and killed world boss in 2 seconds with white weapon, it all happned in the client, its just fulfilling his fantacy but nothing is in the server, his scores, level, coins will remain same & lame. btw above answer is given in conjunction with his previous question where he is not interested in implementing complete/complex server checks.
–
Noob Game DeveloperSep 22 '12 at 5:20

Well, I've been busy lately and wasn't able to implement or even plan nothing really solid. But I've come up with some ideas that will probably disencourage most of the cheaters in the first builds.

For starters I'm going with the combo Node.js + Socket.io.

I don't wanna do monsters AI and/or track it's movements in the server, or do collision detection or anything that may overload the server with requests or processing.

I'll process and keep on the server, of course, some of the keys actions for gameplay, the ones that players I'll be most interested on cheating. Like spawning, shopping, dealing/taking damage, killing/generating monster loot.

As I told on one of my comments, the game will have no Exp/Leveling system, and I'll have character progression more dependent on loot/craft/equipment (there will be other stuff, but that's the core). That's interesting cause, since almost everything players cheat on boils down to killing mobs and getting the drop, and since loot is generated randomly on the server, I can ruin the drop if I detected or suspect that player used some sort of cheating.

In order to decide if a player is cheating or not, the server will be taking as input a series of key info data that may be evidence against the cheater on some consistency checks that will process at each request.

//checks if the player is spamming attacks on random targets that are impossible to hit
//warping - cheating on movespeed - or something like that
if (euclideanDist(enemy.X, enemy.Y, last.enemy.X, last.enemy.Y) > (timeDiff *hero.moveSpeed) + tolerance )
//Detect as cheater - callFBI();

The more info I get as input along with request, more checks I'll be able to do. And depending on how much a I player do suspect actions, I can ban his IP or apply cloaked gameplay penalties on the server side.

You can't conduct server side checks by asking the client to send data. Someone hacking the client will just change it to send the data the server expects. The only way you can practically stop a client from cheating at a certain game mechanic is to host that mechanic on the server.
–
KylotanSep 25 '12 at 2:26

Yes, the cheater can always override the data he is sending, BUT depending on the consistency checks I implement and how much data I send to the server, the player will have to do so very intelligently (to the point it'll be unpractical). And at the end of the day, the player will not be able to cheat on key things like his HP, damage, loot etc. Yes, I know that's not completely secure. it's a heuristic. But I simply don't want to have to implement a full MMO solution bring all its hindrance to gameplay, infrastructure costs etc. for a single player game.
–
Billy NinjaSep 25 '12 at 12:59

I seriously doubt it will be impractical, especially given that you are using Javascript. But it's up to you.
–
KylotanSep 25 '12 at 14:34

=( The more I think about it more flaws I see on my system. But right now the only really critical point left to cover on the server is to know if the monsters AI is working properly there in the client (cheaters can completely disable the AI just by overriding a single value). How can I penalty someone for cheating just because he was not hit by any monster anytime? At this point the threshold to point out cheaters starts to get blurry - but I think I can still cover partially this problem using my current approach allied to some game design decisions.
–
Billy NinjaSep 25 '12 at 18:20