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.
Avoiding cheating in a multiplayer HTML5 game
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).
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.
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.
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.
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.
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.
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.
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.[/quote]
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(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.
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.
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.
Author
[quote name='wolfscaptain' timestamp='1336708898' post='4939199']
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.
[/quote]
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
