• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
speciesUnknown

Avoiding cheating in a multiplayer HTML5 game

20 posts in this topic

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.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
[quote name='DemonRad' timestamp='1336564689' post='4938644']
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.


[/quote]
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.
[quote]


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).
[/quote]
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.
[quote]
Common ways to spot cheating are:
Players reacting to fast on your choices
[/quote]
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.
[quote]
Player moving unit to fast
[/quote]
Doesn't happen in lockstep, because this would cause a desync.
[quote]
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?)

[/quote]
0

Share this post


Link to post
Share on other sites
[quote]via the user clicking or via some cheat mechanism.[/quote]

You can't prevent botting.

Don't waste time on it.

Or switch to a secure platform, something like consoles.
0

Share this post


Link to post
Share on other sites
[quote name='Antheus' timestamp='1336574101' post='4938674']
[quote]via the user clicking or via some cheat mechanism.[/quote]

You can't prevent botting.

Don't waste time on it.

Or switch to a secure platform, something like consoles.
[/quote]

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.
0

Share this post


Link to post
Share on other sites
[quote name='speciesUnknown' timestamp='1336576797' post='4938687']
Also, I find the common answer to "I have problem X with technology Y" being "don't use Y, switch to Z" highly irritating.[/quote]
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.
0

Share this post


Link to post
Share on other sites
[quote]The general answer I'm getting here seems to be that cheating is impossible to prevent anyway,[/quote]

Botting != cheating.

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

[quote]And since we are dealing with a theoretical problem[/quote]

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.

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

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
1

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='Kaze' timestamp='1336583959' post='4938704']
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.
[/quote]

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.
1

Share this post


Link to post
Share on other sites
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
1

Share this post


Link to post
Share on other sites
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).
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='wolfscaptain' timestamp='1336708898' post='4939199']
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).[/quote]
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.
1

Share this post


Link to post
Share on other sites
[quote]Aim bots are the perfect example - they instantaneously snap to the target, where the human experiences a certain reaction time delay and [u][b]may[/b][/u] 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 [img]http://public.gamedev.net//public/style_emoticons/default/blink.png[/img] (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
0

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1336710723' post='4939201']
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.
[/quote]

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.
0

Share this post


Link to post
Share on other sites
[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.[/quote]

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.
0

Share this post


Link to post
Share on other sites
[quote name='jbadams' timestamp='1336792562' post='4939487']
[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.[/quote]

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.
0

Share this post


Link to post
Share on other sites
Maphacking is impossible to prevent in a lockstep simulation. I would like the point out that you can sometimes find ways to reduce the risk though.

For example, in Warcraft 3, one popular way to defeat maphacks was to hide a malformed lighting event in the fog of war. If the client tries to render it, it would crash instead. Of course, this only worked for two reasons:
1) the client was proprietary and hence difficult to modify.
2) Most cheaters are not knowledgeable enough to make their own hacks, and hence don't know how to get around this

Of course this won't work at all in an open source game, since this is essentially exploting an easily fixed bug. In fact, once the method of maphack detection is known, hack authors can easily modify to get around it even if the client is difficult to modify, (for example in Wc3, one popular workaround is to only reveal the minimap).
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0