4
\$\begingroup\$

Disclaimer: I know that client-side is always to be held with suspicion, but I'm trying to conceive of a way to verify the success or failure of javascript-based mini-games.

Mini-games to add fun to client-side game

Here is an example scenario:

I implement a javascript-dependent picture-sliding game for various pictures.
You know the type:

http://3.bp.blogspot.com/_AAvC0ZSs-1k/SUv8waQg0zI/AAAAAAAABN0/tzf3pA9nDxA/s400/SlidingPuzzle-ForHelen.jpg

So that would be a javascript game that would be served from my website.

How to check success

I then want to set up a verification scheme to verify that the game has been completed, the browser would ping the website with a verification code or scheme to say "hey, I'm done, and the javascript mini-game is complete".

There are two ways that I can think of to make the verification work.

  1. One is a "replay" scheme, e.g. each of the moves that the user does would be concatenated and sent to the server, which would have a system for verifying that the end result was indeed a valid solved state.

  2. The other is a "summary" verification code, for example if each of the numbers is assigned a random letter client-side, the final sliding puzzle state would result in a word-code like asdfaseasewadsfwef when read from left to right, top to bottom, which can be sent to the server upon completion to receive a pass/fail grade of success. Obviously that isn't checking the intermediary steps, just the final result, but it'd probably be a lot faster and less resource-intensive, and would probably prevent a bit more abuse than just a GET request with a "go" parameter.

I don't have a huge, high bar for 100% secure communication in this case because I just want to add fun, and give some minor/non-overwhelming benefits from the mini-games, not build a fort-knox system. And if someone is smart enough to hack up a solution to the mini-games to automate them, I won't be excessively broken up about it.

Techniques?

So with that in mind, are these two approaches valid? Are there other approaches to try with this? Any examples in the wild that I could learn from?

Improve this question
\$\endgroup\$
3
  • 1
    \$\begingroup\$ I'd say if you're doing anything client-side, do what's easiest for you. A client will always exploit the game if he wants to, it's not worth the bother if the code is client-side. I agree with jhocking in going for the second solution, and agree that the majority of people will be deterred. \$\endgroup\$ – Jonathan Connell Jun 16 '11 at 15:02
  • \$\begingroup\$ A couple of completely unrelated things, don't make a 5x5 version of this game, it doesn't really grow harder or more fun, it just takes more pushing around, and red numbers on a red background is never going to be a hit. \$\endgroup\$ – aaaaaaaaaaaa Jun 16 '11 at 15:04
  • \$\begingroup\$ Yes indeed, the image is just one that I pulled from the web at random. Even the sliding puzzle type is just an example, I'd like to come up with something more original, just need to get the groundwork of how to make it feasible down. \$\endgroup\$ – Kzqai Jun 16 '11 at 15:28
3
\$\begingroup\$

new answer

(I thought of a better approach than what I wrote in the first place, but I'm leaving the original answer for reference)

Instead of having the client tell the server when the puzzle is completed, do it the other way around (ie. the server tells the client when the puzzle is completed). That way the client simply tells the server what move was made every time the player makes a move, and then the server can tell the client when the puzzle is complete in the response to the request from the client.

This way you get the security of option 1 without the bother of writing code to playback a series of moves.

old answer

Personally I would go with option 2 because you don't need this to be 100% secure. That is definitely a lot easier.

However, are you sure you don't care about cheating? Whether or not cheating on the mini-game matters depends on the reward for successfully completing the mini-game. If successfully completing the mini-game has any affect at all on other players, then I would consider cheating pretty important and go with option 1.

And note that "any affect" can be very subtle. Let's say that completing the mini-game just earns access to a new level for that one player. In that case, I wouldn't really care if they passed the mini-game by cheating. If however the mini-game earned them some visible trophy (eg. a badge on their profile) that other players can see then I would want to protect against cheating. And if the mini-game earned them a special weapon then I would definitely want to protect against cheating.

Improve this answer
\$\endgroup\$
5
  • \$\begingroup\$ I guessed that as the game is in Javascript, @Tchalvak isn't all that bothered about cheating. You could verify everything server-side, but in the end the player could still too easily create a solver for the mini games. The verification would be huge work also compared with just simply deciding to use a different language. \$\endgroup\$ – Jonathan Connell Jun 16 '11 at 15:17
  • \$\begingroup\$ Y'know what, I'm gonna change my answer because I thought of something better. \$\endgroup\$ – jhocking Jun 16 '11 at 15:19
  • \$\begingroup\$ @jhoking ;) I hope i'm not annoying you? :P \$\endgroup\$ – Jonathan Connell Jun 16 '11 at 15:22
  • \$\begingroup\$ no no, I was thinking about this anyway because I'm starting a job where I'm developing a Flash front-end to a multiplayer web-game. ActionScript is just as visible as JavaScript so it has the exact same security concerns. \$\endgroup\$ – jhocking Jun 16 '11 at 15:25
  • \$\begingroup\$ Yes that's the way I made a checkers game a while back with AJAX :P. The user tells the server what he is moving, and the server tells him if he can, and what the consequences are. It's a lot of requests though (because the server can't tell the client, he has to ask). Though it is probably the best solution for security & rapidity. \$\endgroup\$ – Jonathan Connell Jun 16 '11 at 15:28
2
\$\begingroup\$

Recording all the player moves and sending them to the server, is a good choice.

If you wanted more cheat protection, you could even have a key that is generated each move, using a seeded random number generator, using the the time in milliseconds for each key. Verify the moves and verify that the moves were created validly.

This will prevent people from packet sniffing and trying to spoof the moves with a solver program.

Improve this answer
\$\endgroup\$
7
  • \$\begingroup\$ I agree that all moves should be sent to the server for validation. I don't understand how some random numbers would add to the protection? You can easily see in the JS code what's going on and spoof the same behavior (eg. adding some random numbers or spaced timestamps) \$\endgroup\$ – bummzack Jun 16 '11 at 6:49
  • \$\begingroup\$ Its not just a random number, its a number and a timestamp that are verifiable on the server. You could make the method of creating the key extremely confusing to decipher and have small parts of it all over the entire codebase that seem unrelated but will cause the key to not be correct. It will not protect entirely from hackers, but it will make it require a lot of work to figure out how to send fake scores. \$\endgroup\$ – AttackingHobo Jun 16 '11 at 8:14
  • 2
    \$\begingroup\$ Making it extremely confusing and spreading the code/logic over the entire codebase will also make it very confusing and hard to maintain for yourself though :) \$\endgroup\$ – bummzack Jun 16 '11 at 9:56
  • 1
    \$\begingroup\$ Yeah I wouldn't bother with a key generated on the client-side. You could have a key generated on the server that gets sent to the client when the mini-game starts, but even that seems pointless to me. The primary and only real security here would be replaying the game on the server, where you know it's legit. \$\endgroup\$ – jhocking Jun 16 '11 at 14:54
  • 1
    \$\begingroup\$ I don't see why anyone would resort to packet sniffing on a Javascript game... \$\endgroup\$ – Jonathan Connell Jun 16 '11 at 15:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.