Now that there are a couple of neat canvas demo's of both classic platform and even 3D fps games in HTML5, the next step might be to try developing a multiplayer HTML5 game. HTML5 socket support makes this relatively straight-forward, but with client-side source being viewable by anyone in the browser, what are some solutions for basic game security features for a HTML5-frontend multiuser game -- such as being able to prevent a faked high-score submit?
+5
A:
The simple answer is: You can't trust the data from client, which means that the high score submit can't come from the client.
Since the code client is available for anyone to inspect, there's no way of trusting the data that the client sends your server. Even if you encrypt the data with a per-user encryption key (which is possible), the user can simply alter your code within the browser and change the values it's sending to the server.
Since your game is multiplayer, this might be possible IF the server generates all the scoring events. If the server generates all the scoring events, the client never sends score data to the server which means that the high score data can't be faked.
You'll still have to deal with cheating, which is even more challenging, but that's another issue...
Larry Osterman
2010-06-05 03:33:28
I'm still thinking of ways where server generating the scoring events might work... It seems that inevitably, the clientside would have initiate some feedback for the game to be interactive - such as clicking or pressing a button, which would ultimately be translated to just a socket/URL call, assuming each scoring process is sent to server.Since the URL to send this scoring event is out in the open (and there's no way to avoid this?), it seems like people can just easily abuse it by setting a scraper to the URL, even.What kind of game could have only server-confined scoring events?
ina
2010-06-07 11:07:45
@ina: pretty much every commercial online game does all its scoring on the server. The client initiates the actions but the server resolves them and decides the outcome.
Kylotan
2010-06-08 10:10:12
@ina: What kylotan said. Don't have a "generate a score" event. Have a "player took this action" event. If the action results in a score being generated, generate the score on the server. It means that your client is nothing more than a display for events generated by the server - there's effectively no gameplay elements executed on the client, they all happen on the server and are rendered on the client.
Larry Osterman
2010-06-08 14:59:54
OK, so something like this? Server random generates "hit score possibility" with limited time and space window of valid user-generated "hit" (ie, click in some box, in the next 3 seconds...) Info sent thru server url though... so... with timeout, for the case where someone abuses the server call url by creating a super-pinging bot, for ex?
ina
2010-06-11 11:14:32
You're over thinking it. Think of it this way: Client sends a "player attacked <other player>" message and starts the "player attacked" animation. Server decides if the player hit or not and sends a "you hit!" or "you missed!" message back to the client. The server keeps track of hit points, health, etc. When one player dies, the server sends a "you died" message to the dead player and a "you killed them" message to the killing player. All the stats and record keeping is on the server, the client does nothing but show UI. The same idea applies to other game types (poker, etc).
Larry Osterman
2010-06-11 21:45:16