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.

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?)

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).
[/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.

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.

Player moving unit to fast
[/quote]
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?)

[/quote]

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)

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

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.