Reputation: 7664
First of all, I understand this question might be off topic and not in scope of stackoverflow but I still decided to ask since I don't know any other better place.
So if a mutliplayer game is being made where users can compete against each other, what measure are taken to prevent cheating. I'm asking because since the game source is viewable, anyone can simple modify the game source and potentially cheat.
FlappyBird
or a game where the further you go in a linear map, the more point you stack up.
At the end of the game, your score is submited via a http request.
Now what is stopping a user from editing the game which causes the points to stack up 10x faster? causing a higher score to be submited?
Edit 2: Or what is stopping the users from submitting a request containing false scores via cURL without ever having to play the game?
Upvotes: 3
Views: 143
Reputation: 24508
Multiplayer games prevent cheating usually by simply verifying the game steps, rather than just the complete game output. Since all other players need to know what other players do, you will have to tell the server every step of the way and let the server "simulate" the game and check if these steps are actually valid or not. The only way to cheat in this case is by writing an AI in your browser that will then produce a feasible set of steps coming to a good result.
You also will have to send these player steps to everyone else. Since in a continuous environment players can perform so many actions per second (e.g. move and turn), you want to make sure to minimize the amount of updates to be sent. E.g. when walking in a straight line, World of Warcraft,for example, only sends an update every 500ms. They might also do not necessarily simulate and verify every single step you take, but only every X steps to avoid people running through walls or jumping over entire buildings etc.
Please note that any fast-paced game will not work well when using AJAX calls. Just setting up a connection can take many times as long as just sending a packet through an established connection. That is why you want to use Websockets in that case.
Of course, minifying and obfuscating your code will put some stones in the ways of a cheater, but depending on the vulnerabilities of your system, they might do very little, since it is usually very easy to find the code that takes care of sending and receiving packets or other core aspects of your game, no matter how well obfuscated it is.
Upvotes: 2
Reputation: 10211
Since you cannot believe your clients, you should make an authoritative server and dumb clients model;
That articles are full of gems for who want implements an multiplayer game
the game state is managed by the server alone. Clients send their actions to the server. The server updates the game state periodically, and then sends the new game state back to clients, who just render it on the screen.
From your point of view, what happened is that you pressed the right arrow but nothing happened for a tenth of a second; then your character finally moved one square to the right. This perceived lag between your inputs and its consequences may not sound like much, but it’s noticeable – and of course, a lag of half a second isn’t just noticeable, it actually makes the game unplayable.
So you must implement a Client-side prediction and a Server reconciliation
Upvotes: 1
Reputation: 440
If you develop a "multiplayer" based game, than you should persist the data on a server, centralized, accessed by ajax within your game.
And you're right, someone could potentially "cheat" by overwriting your code with firebug for example or Greasemonkey before you send your data via a http request (ajax).
In order to prevent this you could load your ajax code for saving data dynamically. You can only prevent it by making it more difficult to overwrite your code. Use for example one-way-token in a virtual session, like the token used in OAuth, like a ticket for a ajax-call. Every other call without the right token should be refuted.
Upvotes: 1