Jump to content

  • Log In with Google      Sign In   
  • Create Account


Avoiding cheating in a multiplayer HTML5 game


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
20 replies to this topic

#1 speciesUnknown   Members   -  Reputation: 527

Like
0Likes
Like

Posted 09 May 2012 - 04:45 AM

The problem with this in principle is that the source code is available to the client. What I want to do is build an RTS, but I'm wondering if there is any realistic way of preventing cheating. My theory is that its not really possible, in a lockstep system, to detect whether a command has come via the user clicking or via some cheat mechanism. Also, I dont think its possible to prevent cheats such as revealing the map; basically, anything that doesn't cause a desync is possible.

Added to this the fact that the client has easy access to all the code via normal developer tools like firebug, and you have a potential disaster.

Not being a fan of obfuscation, which is easily reverse engineered, im wondering if running a lockstep simulation via websockets is not totally vulnerable to cheating.
Don't thank me, thank the moon's gravitation pull! Post in My Journal and help me to not procrastinate!

Sponsor:

#2 DemonRad   Members   -  Reputation: 290

Like
0Likes
Like

Posted 09 May 2012 - 05:58 AM

Theorically only what server says matters. So if a player send a message with "create building K in (X,Y)" or "move unit J to place (X,Y)" the server may answer to client that message was processed and immediatly after that , the server send updates to both players. If you want to prevent from cheating clients (common way that can be used to cheat is "seeing" through fog of war, if you see what enemies are doing you can easily counter their strategies). To solve that problem the server can just send data of visible (or nearly visible) units/buildings.

Another way is just to use clients for spot cheating. If a client suppose an enemy is cheating it request to server a "cheat control". Then server analize data to see if someone cheating (usually you don't want complex task on sever so additional checks should be done only when required).

Common ways to spot cheating are:
Players reacting to fast on your choices
Player moving unit to fast
etc..


If you balance very well your game you don't have to warry about bots, they are predictable. Is very hard someone write a very good bot, so untill strategy matters more than micro-management bot cheating will be hard to obtain (and if you have only few players cheating that's good no?)

Edited by DemonRad, 09 May 2012 - 06:02 AM.

Peace and love, now I understand really what it means! Guardian Angels exist! Thanks!


#3 speciesUnknown   Members   -  Reputation: 527

Like
0Likes
Like

Posted 09 May 2012 - 08:11 AM

Theorically only what server says matters. So if a player send a message with "create building K in (X,Y)" or "move unit J to place (X,Y)" the server may answer to client that message was processed and immediatly after that , the server send updates to both players. If you want to prevent from cheating clients (common way that can be used to cheat is "seeing" through fog of war, if you see what enemies are doing you can easily counter their strategies). To solve that problem the server can just send data of visible (or nearly visible) units/buildings.


Restricting data send to the client does not work with a lockstep simulation, because the simulation is being run independently on all clients, and only commands are sent over the network. To run the simulation properly, all clients need all data. In the case of a web game, where the only available connection is between the clients and the server, the server has to relay commands to the clients, so the server can also run the simulation, but it is not telling the clients what units are visible.

Another way is just to use clients for spot cheating. If a client suppose an enemy is cheating it request to server a "cheat control". Then server analize data to see if someone cheating (usually you don't want complex task on sever so additional checks should be done only when required).

Its nearly impossible for a client to spot cheating. Even humans are very very bad at this (think of the number of times you got accused of cheating - in the case of games like COD this is usually several times per minute) so an automatic version would suffer from serious edge case difficulties.

Common ways to spot cheating are:
Players reacting to fast on your choices

Lockstep simulations usually run at a very low tick rate, say 5hz, so there is no way to determine how fast a user is reacting to your choices. Moreover, it is almost impossible to separate the nebulous heap of incoming commands out into discrete choices.

Player moving unit to fast

Doesn't happen in lockstep, because this would cause a desync.

etc..


If you balance very well your game you don't have to warry about bots, they are predictable. Is very hard someone write a very good bot, so until strategy matters more than micro-management bot cheating will be hard to obtain (and if you have only few players cheating that's good no?)


Don't thank me, thank the moon's gravitation pull! Post in My Journal and help me to not procrastinate!

#4 Antheus   Members   -  Reputation: 2393

Like
0Likes
Like

Posted 09 May 2012 - 08:35 AM

via the user clicking or via some cheat mechanism.


You can't prevent botting.

Don't waste time on it.

Or switch to a secure platform, something like consoles.

#5 SimonForsman   Crossbones+   -  Reputation: 5761

Like
3Likes
Like

Posted 09 May 2012 - 08:43 AM

The problem with this in principle is that the source code is available to the client. What I want to do is build an RTS, but I'm wondering if there is any realistic way of preventing cheating. My theory is that its not really possible, in a lockstep system, to detect whether a command has come via the user clicking or via some cheat mechanism. Also, I dont think its possible to prevent cheats such as revealing the map; basically, anything that doesn't cause a desync is possible.

Added to this the fact that the client has easy access to all the code via normal developer tools like firebug, and you have a potential disaster.

Not being a fan of obfuscation, which is easily reverse engineered, im wondering if running a lockstep simulation via websockets is not totally vulnerable to cheating.


With a lockstep RTS game there are only really 2 cheats you have to worry about:
1) Maphacks.
2) Bots.

Both can be designed around, Maphacks are made worthless if there is no fog of war and bots are only really beneficial if players benefit from a high APM and micromanagement. (If the strategy is the important part then it is very difficult to write an effective bot, just look at how common it is for RTS game AIs to be given advantages at higher difficulty settings rather than just playing better)

Edited by SimonForsman, 09 May 2012 - 08:45 AM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#6 speciesUnknown   Members   -  Reputation: 527

Like
0Likes
Like

Posted 09 May 2012 - 09:19 AM

via the user clicking or via some cheat mechanism.


You can't prevent botting.

Don't waste time on it.

Or switch to a secure platform, something like consoles.


The objective here is an HTML5 RTS.

The general answer I'm getting here seems to be that cheating is impossible to prevent anyway, but that lockstep makes most forms of cheating pointless.

And consoles aren't really as secure as they claim to be. Assuming the console is totally secure is a great way to have a catastrophe when suddenly the "security" gets broken.

Also, I find the common answer to "I have problem X with technology Y" being "don't use Y, switch to Z" highly irritating. You cant just switch your entire platform and toolset every time you have a problem. You will have new problem on those platforms as well (and probably be told to switch back). And since we are dealing with a theoretical problem, we can theoretically switch between platforms until we are blue in the face because more theoretical problems will occur.
Don't thank me, thank the moon's gravitation pull! Post in My Journal and help me to not procrastinate!

#7 swiftcoder   Senior Moderators   -  Reputation: 9584

Like
0Likes
Like

Posted 09 May 2012 - 09:31 AM

Also, I find the common answer to "I have problem X with technology Y" being "don't use Y, switch to Z" highly irritating.

It is however the only truly correct answer in this case. The only way to entirely prevent cheating, is via trusted computing - and given that TPM on the desktop has failed to become a reality, consoles are the closest you can get at this time to a trusted computing platform.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#8 Antheus   Members   -  Reputation: 2393

Like
1Likes
Like

Posted 09 May 2012 - 09:51 AM

The general answer I'm getting here seems to be that cheating is impossible to prevent anyway,


Botting != cheating.

Botting on HTML5 cannot be prevented, it's the wrong platform. Cannot be done as in Does not compute.

And since we are dealing with a theoretical problem


No theory here: ", to detect whether a command has come via the user clicking or via some cheat mechanism." - cannot be done. It is impossible. HTML5 does not know about input devices, it has no mechanism to distinguish where inputs come from.


It is however possible to monitor action patterns on server and apply heuristics to attempt to determine which actions are direct human input and which aren't. This will be unreliable, it will raise false positives and negatives and it will not be able to detect certain types of undesirable actions. But this has nothing to do with HTML5.

You cant just switch your entire platform and toolset every time you have a problem.


No, but it helps to choose a platform which is at least capable of solving a problem vs. one that isn't. Just like some software is still written in native code, simply because other platforms aren't capable of solving those problems.

Edited by Antheus, 09 May 2012 - 09:54 AM.


#9 Kaze   Members   -  Reputation: 948

Like
0Likes
Like

Posted 09 May 2012 - 11:19 AM

Even if you ignore the security issues I would go for server side game logic over p2p client logic to cut down on network traffic and synchronization issues.

#10 Antheus   Members   -  Reputation: 2393

Like
1Likes
Like

Posted 09 May 2012 - 11:41 AM

Even if you ignore the security issues I would go for server side game logic over p2p client logic to cut down on network traffic and synchronization issues.


Server-side logic doesn't prevent botting.

Keep in mind that there is a bot for SC2 which intercepts GPU calls, interprets the graphics (machine vision) then issues inputs via known controllers. It was, IIRC correctly, tested online.

Humans are a form of bot.

The only solution is to develop gameplay which offers no incentive to bot.

#11 Bacterius   Crossbones+   -  Reputation: 8152

Like
1Likes
Like

Posted 09 May 2012 - 03:05 PM

This has already been discussed before. From the point of view of the server, the client and the bot are functionally equivalent. This is enough to show any kind of measure will be pointless. Heuristics can be employed but bot behaviour can sometimes be indistinguishable from human behaviour to an algorithm and this will just end badly for everyone else but the bots, with people getting kicked randomly because they decide to go on a grinding spree or something.

A way many games deal with this is, simply, making accounts cost money, which has the nice (arguable) effect converts bots into revenue. It's not an ideal solution, and unless your game is revolutionary or gets very popular nobody will pay for it. Otherwise your options are much more limited and pretty much boil dlown to Antheus's solution, make sure botting is useless in your game (perhaps by creating a dynamic market which will respond to bot dumps in an intelligent way, or requiring resource acquiring to be a very interactive process impossible for a bot to perform on its own).

For instance an MMO called Dofus used to occasionally, randomly have players that were getting resources get attacked by "resource protectors" which are relatively easy to beat but require some form of intelligence to defeat successfully as they usually attacked at range and hid behind obstacles. Of course, ultimately the bot developers discovered a solution, but it did last a long time.

Edited by Bacterius, 09 May 2012 - 03:09 PM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#12 Sik_the_hedgehog   Crossbones+   -  Reputation: 1483

Like
0Likes
Like

Posted 09 May 2012 - 09:53 PM

Let's be fair: if you can have AI opponents in the game, then the player can make a bot. Remember, those AI opponents you fight against in single player work exactly the same way bots do (except that generally bots have their "difficulty setting" cranked up to maximum).
Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

#13 ndssia   Members   -  Reputation: 172

Like
0Likes
Like

Posted 10 May 2012 - 10:55 AM

I'm not too knowledgeable about the technical details of HTML5, but generally, any data that the client receives is fair game, and can be retrieved; in HTML5's case, I don't know if there's any way to detect that; maphacks will have free reign.

#14 jbadams   Senior Staff   -  Reputation: 17221

Like
1Likes
Like

Posted 10 May 2012 - 06:25 PM

I'm going to have to agree with SimonForsman on this one: due to the technical limitations others have mentioned, the best idea is probably to design around it so this isn't an issue. If you make the map visible to all players then map hacks have limited-to-no usefulness, and with the right type of game play you can make it prohibitively difficult to create a bot that performs acceptably within a reasonable amount of time.

Given this is a strategy game, unless their is some broken (unbalanced) strategy that a bot can take advantage of through faster input most players should learn to easily beat an AI player, making any bots that arise of limited use.

#15 wolfscaptain   Members   -  Reputation: 200

Like
0Likes
Like

Posted 10 May 2012 - 10:01 PM

In a client-server model, you can prevent cheating almost completly (irrelevant of the platform of choice) with some effort.

For beginers, the client doesn't decide anything. It might run the simulation locally to make it feel the game responds immidetly, but the server is the only real authority and can fix the client data if it isn't correct, for example if a collision occurd which the client didn't know about (known as client side perdiction).
This prevents any meddling with global game data. You can see yourself teleporting or doing any common cheat if you stop the server from correcting you, but the other players see your true state.

To prevent meddling with local data (such as fog of war, or changing game textures to see through walls), the server need only send the actual data the client should know about.
This is probably going to be a bit tricky to program, but it might not (didn't really give it much thought about implementation details).

Preventing any useful bots is done by sending from the clients only input state, such as the keyboard and mouse states, and not actual game actions, such as "shoot".
The server then decides what actions are required (this prevents the client from doing things like shooting a whole magazine of ammo with one click, for example).

P2P is a very hard model to make properly - both because of synchronization issues, and because of security - to begin with, regardless of the platform.

#16 swiftcoder   Senior Moderators   -  Reputation: 9584

Like
1Likes
Like

Posted 10 May 2012 - 10:32 PM

Preventing any useful bots is done by sending from the clients only input state, such as the keyboard and mouse states, and not actual game actions, such as "shoot".
The server then decides what actions are required (this prevents the client from doing things like shooting a whole magazine of ammo with one click, for example).

That may stop obvious hacks like shooting an entire clip at once, but it doesn't do anything at all to stop bots in general - bots can manipulate the mouse and keyboard state indistinguishably from a human (for example, in the case of HTML5, manufacturing input events directly in the DOM).

The point of a bot is not that it exploits options unavailable to the human player, but that it does so faster and more accurately. Aim bots are the perfect example - they instantaneously snap to the target, where the human experiences a certain reaction time delay and may additionally suffer from a degree of inaccuracy.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#17 Bacterius   Crossbones+   -  Reputation: 8152

Like
0Likes
Like

Posted 11 May 2012 - 12:02 AM

Aim bots are the perfect example - they instantaneously snap to the target, where the human experiences a certain reaction time delay and may additionally suffer from a degree of inaccuracy.

May? Are there really people out there capable of pointing to a given pixel in a single, swift mouse gesture? I need to see that Posted Image (pixels in the corner don't count!)

Note that bots don't always act in a perfect way, e.g. they don't always take the direct most efficient path to whatever goal they are aiming for, most bots have started introducing voluntary noise in their operation which would thwart detection algorithms. For instance recent aimbots have a "sensitivity setting" where the user can adjust how quickly and accurately the aimbot works, so that instead of going around blatantly pwning people, he actually sometimes misses, dies, etc... which makes it less obvious to detect it, while stilling giving the aimbot user a significant edge (but instead of a 120/0 kd-ratio for instance, he'd have, say, a 40/8 which is more credible).

This might seem to defeat the aimbot's purpose as it intentionally reduces its accuracy so that it can remain undetected longer, but nobody said aimbots had to be perfect, as long as the aimbot "plays" better that the player itself, the need of keeping the aimbot running logically takes precedence over maximizing the aimbot's performance (in most cases, anyway)


The same thing applies for other bots, of course. For instance in MMO's a grinding bot might occasionally stop for a variable amount of time, do/say something predefined, then resume grinding (basic example).


All of this comes under the same, basic concept, how to differentiate between a bot and a human, which has been a major question for several years now (turing test anyone?), in various situations. It's fairly trivial to debunk a chatbot for instance, because it's really easy to stump them, but when the bot's only interactions are mouse/keyboard commands your options are much more limited.

Edited by Bacterius, 11 May 2012 - 12:03 AM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#18 wolfscaptain   Members   -  Reputation: 200

Like
0Likes
Like

Posted 11 May 2012 - 12:27 AM

That may stop obvious hacks like shooting an entire clip at once, but it doesn't do anything at all to stop bots in general - bots can manipulate the mouse and keyboard state indistinguishably from a human (for example, in the case of HTML5, manufacturing input events directly in the DOM).

The point of a bot is not that it exploits options unavailable to the human player, but that it does so faster and more accurately. Aim bots are the perfect example - they instantaneously snap to the target, where the human experiences a certain reaction time delay and may additionally suffer from a degree of inaccuracy.


Yes, you can't stop bots completly no matter what you do, but it stops a whole lot of cheats, added with the other suggestions I wrote.

Micro-management (which aimbot can be considered as) can't be stopped.

#19 jbadams   Senior Staff   -  Reputation: 17221

Like
0Likes
Like

Posted 11 May 2012 - 09:16 PM

In a client-server model, you can prevent cheating almost completely (irrelevant of the platform of choice) with some effort.


While what you've said is true, we're discussing a lock-step simulation rather than a client-server model, and the OP has already specified that he does not wish to change target platform or his core technology choices. Changing architecture to client-server is certainly a valid suggestion that could solve most of the potential problems, but it's a solution that's already been suggested to and rejected by the OP.

#20 speciesUnknown   Members   -  Reputation: 527

Like
0Likes
Like

Posted 11 May 2012 - 11:41 PM


In a client-server model, you can prevent cheating almost completely (irrelevant of the platform of choice) with some effort.


While what you've said is true, we're discussing a lock-step simulation rather than a client-server model, and the OP has already specified that he does not wish to change target platform or his core technology choices. Changing architecture to client-server is certainly a valid suggestion that could solve most of the potential problems, but it's a solution that's already been suggested to and rejected by the OP.


Given that this is an RTS, its likely that lockstep is by far the simplest solution. I think the server is going to need to be more heavily involved than it would in a p2p system, but not to the point of running the entire simulation - i'm going to use it to broker commands between the various clients, which will still run the simulation seperately. Other than maphacks, I'm no longer worried about cheating.
Don't thank me, thank the moon's gravitation pull! Post in My Journal and help me to not procrastinate!




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS