I wonder what they're doing about cheating? I guess this type of game is not so easy to 'cheat' with but I'm sure it is possible.
I was thinking about building an Unreal Tournament clone in WebGL, but I'm still not sure what to do about cheating.
I was thinking about building an Unreal Tournament clone in WebGL, but I'm still not sure what to do about cheating.
The trick is to have as many checks and balances on the server side as possible (to prevent walking though walls, warping, etc).
One idea that's just crossed my mind is the idea of serving different Javascript to each client? It could be obfuscated uniquely every time someone loads the page in a detectable way. I,e you can serve IP x.x.x.x with obfuscation seed y and then you know to expect a certain behaviour. Variables and program flow can be changed to confuse nieve would be hackers, but important the structure of the network communication can be changed in a subtle way. Any hack scripts would need to counter for this which would make things far more complicated.
I wish my university term would be over so I can start hacking away on this idea! :)
It is, in fact, not a bigger problem if the code is readily readable. Someone with the technical chops to read the source code and figure out weaknesses that can be exploited for cheating wouldn't be stumped by a binary blob for very long. My usual approach when trying to figure out "cheats" for most such things is to bypass the client altogether and analyse the network traffic to figure out the underlying protocol. Then come up with a client that reproduces those(simple replay attacks at first to see what works and what doesn't) and as my understanding of what does what evolves make it more sophisticated and flexible.
Having your source code fully available to any would-be attacker will force you to not make the mistake of hoping that nobody figures out how things work to be able to attack you. It forces you to pay attention to server-side checks to enforce the constraints of your game(what? that guy just changed his position in a way that's way too fast? not possible!).
You also have the problem of hidden information. Most games have a fog of war or simply walls that should obscure some part of the game state. If this is sent to the client, somebody will expose that information: maphack. It's not at all a trivial problem to define and send only exactly the slices of the game state that the client should have access to.
And any game where timing matters is subject to auto-aim bots and other such cyborg-style assistance to the players. Bomberman is subject to this: imagine a browser plugin that automatically moves your character out of range of a bomb in the last few instants before it explodes.
Checking client input is rather difficult, but it's no more difficult then developing the game itself. Just a lot of hassle and checking.
Even if you do all this stuff, people can still break it. Look at pretty much every game made. There are ways to cheat.
Also cheating is only trouble when it degrades other player's experience or when they are hacking/hurting the monetization.
As stated, if the logic is performed on the server-side then the only way a client can cheat is by modifying the inputs.
The one thing that makes it hard for client to know in which way to cheat the inputs is... Randomization.
Do not make something where players are recompensed when doing a super skilled move, like a headshot. Or you'll have aimbots. As simple as that. Player has a shotgun? Make it fire 30 miny bullets at once with some server-side randomization (that's how many shotguns work btw).
Do not want to give info about the other side of the map so that a rogue bot cannot shift to the correct strategy automatically ? Use server-side fog of war. That way the very info needed to "map hack" simply is NOT available on the client.
It is hard to combat all forms of cheating. But maphack can definitely be mitigated and randomization can really help with many aimbots.
Regarding the "highlight players behind walls": two things to do. 1) do not allow to fire through walls (unless the first Counter-Strike, which was totally silly in that you could fire through 2-meters wide wall with a simple pistol) and 2) server-side fog-of-war. Do simply not send to the client the info that would allow the client to determine that an ennemy is behind the wall too early.
Sure, at one point you need to give the info: give it as late as possible and make is so "super crazy high reflex" are not rewarded in an insane way. For example make it slower to "switch gears", etc.
It all comes to a balance between fun and anti-cheat but many things can be done to make cheaters life way harder and, most importantly, way less efficient.