0
\$\begingroup\$

I'm working on a fairly simple JavaScript + Node JS + socket.io (M)MORPG where multiple people play in the same world. This is actually working, but cheating is insanely easy at the moment.

My goal is not to stop people from cheating client-side, I know this is impossible.
My goal is to have the server know when someone is cheating and do something about it.
What I really want to know is how well a Node JS server would be able to handle the constant anti-cheat checking.

People can just adjust the client-side JS code and the server currently doesn't do too much checking.

So a player could just change his X & Y coordinate and teleport around the map at will.

It would be fairly simple to implement basic checks that don't allow crazy cheats.
But I'd like a real way to prevent this.

One possibility is to keep track of all player data on the server and make sure nothing weird is happening client-side by constantly comparing the data the server has.
My issue with this is that I have a lot of collision checking and my world will become rather big.
I'm not sure how good of an idea it is to do all of this collision checking server side as well. Sure it would work for one or two players, but what about 10? 50? 200?
Especially with all of these players bouncing off walls, shooting bullets, hitting monsters, getting hit by monsters, colliding with monsters, ...

As far as I know, the only way to actually prevent cheating is by making the server check all movement and wall/bullet/monster collisions.

Are there any other options? Like using an anti-cheat engine of some sort? I know games like MapleStory have that, but I have no idea how they work or how affordable that would be?

Or will doing all the collision checks server side be fine?
At some point, like around 50-100 players, I could set up a second server instance to limit the amount of players on each server.
Ofcourse I would also only check collisions near the player, so not map-wide for each player.

Any help/advice on this is appreciated.

Here's a link to my game that will make my questions less abstract.
It's far from finished and the world is still very small, but it should give a good idea of what I'm asking:

http://185.115.218.199:3000/

\$\endgroup\$
  • 1
    \$\begingroup\$ It sounds like you understand the situation. You choose between A) simulating on the client and trusting what it says (allows any violation of game rules), B) simulating on the client and spot-checkkng on the server (allows cheats that avoid your spot checks), C) simulate on the server (allows no violation of game rules). You understand that the more loopholes you close, the more computation you need to run on the server. Where the right trade-off point between consistency and cost is for your game is a judgement call you'll need to make. \$\endgroup\$ – DMGregory Jul 17 '18 at 13:03
  • \$\begingroup\$ @DMGregory my issue is that I have 0 prior experience with node js so I have no idea how this will turn out once a few people start playing the game ... \$\endgroup\$ – Pascal Claes Jul 17 '18 at 13:05
5
\$\begingroup\$

There is just one way to prevent cheating: Handle all your game mechanics on the server.

Anthing else is snake-oil.

That applies even more to web-based games where every player can access all kinds of powerful cheating tools just by pressing F12.

Anti Cheat Tools (ACTs) work by infiltrating the players operating system and doing all kinds of low-level system checks to find processes, files and memory patterns which might indicate that the player is trying to cheat. This requires an actual program on the user's computer which they need to install (usually they install it together with the normal game client). In a web-based game, this is not an option. The point of web-based games is that the player does not need to download and install any additional software.

And besides, ACTs are software, too. They can be hacked just like the game client can be hacked. The companies which make them usually try to make that difficult by using lots of obfuscation methods to make their ACTs harder to reverse-engineer. But that just makes it less convenient to hack their tool, not impossible.

Whether "doing all the collision checks server side is fine" in regards to performance depends on how you implement collision checks. There are all kinds of optimizations you can use to handle collisions of 200 objects in real-time. But this is a very broad topic. The best optimizations are always specific to the game. If you need help with this, please open a new question where you add more details about what kind of collisions you need to detect, how your bounding volumes tend to be distributed, how many of them move and how often, etc., etc..

\$\endgroup\$
  • \$\begingroup\$ If handling all the mechanics on the server is the only way, I guess I'll have to go that way wether it's viable performance wise or not. I'll just have to find a way to keep up performance if required then I guess. \$\endgroup\$ – Pascal Claes Jul 17 '18 at 13:03
  • \$\begingroup\$ gamedev.stackexchange.com/questions/161814/… \$\endgroup\$ – Pascal Claes Jul 17 '18 at 13:38
  • \$\begingroup\$ @PascalClaes yes, you need to do all the checks on the server. That does not mean the client can't do them also. In fact, you can save some traffic and server time by having the client check first, and the server check is there for when there are cheaters. That is a common approach on the web (not only for games). Also, regardless of being web or not, the client can do prediction, and then correct when it has the response from the server. I went over some of that here. About your collision problem, do not forget space partitioning. \$\endgroup\$ – Theraot Jul 18 '18 at 11:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.