0
\$\begingroup\$

I'm going to develop a real-time browser game using NodeJS in backend for a fast WebSocket, but I'll both prevent bots and other cheats, so my frontend JS might be very advanced.

I'm experienced with developing bot scripts, so I already know that I have to prevent all scripting methods for automating the game (clicking elements, using in-game functions, and so on), but to do that, I have to keep the WebSocket in an anonymous function where the whole game script will be.

Is there a good way to verify that the WS connection is in the official script in case cheaters would like to find a way to stop it to run a modified script?

My current ideas, might not be the best?

  • Generate the HTML with a script with a unique ID from the backend that the backend will accept only once, and other connections using this ID will just be rejected

  • Same as above, but push the ID through headers (might improve performance when comparing)

  • Bind the WS handshake value to their IP in the backend (will not allow multiple users on same IP, and will require the backend to unbind the IP before it can be used again - will easily be a problem)

  • Captcha, I know it can be pushed like every 10 min, but I don't want to use captcha after the login has been verified because the game will require the player to be able to do actions fast in some cases (to survive)

Why so complicated?

I've tried 2 other web games of same category, and another game.

The first was full of issues like latency and UI issues, so it was pain to play. The latency was unstable, but actions was done anyway, no matter if I wasn't aware about it before it was too late, but I'm pretty sure this game uses SSE instead of WS.

The 2nd game was too annoying because it had captcha way too often, like every 10 min. The 3rd game too, it sent captcha way too often. I think that it's okay with a captcha to verify login and registration, but when playing, captchas will make players leave because it's annoying

\$\endgroup\$
2
  • \$\begingroup\$ would using React and some "hard-to-find" WS in it and using encoded data maybe be a solution? it's not supposed to be "impossible" to cheat as it would be impossible to do with a website, but too hard for any "normal" cheaters \$\endgroup\$ Commented Apr 21, 2020 at 16:29
  • \$\begingroup\$ How do you want to prevent a script clicking on elements? Do you plan to move your ui around to not have fixed positions? \$\endgroup\$
    – Zibelas
    Commented Nov 25, 2020 at 19:58

1 Answer 1

1
\$\begingroup\$

With web - accept as a fact "Any client is a potential cheater".

If you have any game logic on the frontend - nothing will save your game from the cheaters.

If you move all the logic to the server (Or duplicate logic and make the server always arbitrary right) and can prevent any attempts to compromise WebSocket messages (like sending invalid JSON to crash the server) - it's more than enough. And practically all you can do.

Don't try to bind IP to the client. For your server, my IP and IP of my GF machine will be the same.

WSS (SSL) - also mush have. Glad we have lets-encrypt now in 2k20.

Don't bother with super-complex HTML generation. It gives nothing and guarantees nothing. Learn about JWT tokens.

CAPTCHA is awful. With all the above you don't need a captcha. In fact, with captcha pushed like every 10 min the only thing you can achieve - it 0 players online.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .