General directions on developing a server side control system for JS/Canvas Action RPG

Question

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.

Answer 1

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.

Answer 2

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.

Hope this helps.

Answer 3

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.

like shown bellow

//checks if the monster HP was compromised on the client if (target.id == lastTarget && eClientHP != target.currHP) //possible cheat detected - this monster wont drop loot

//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.