Memory Game - basic anticheat ideas

[Mike]

So first i have doubts should i go canvas or DOM

 

Isn't canvas one idea harder for hacking, you can't jsut F12 and see all cards...

 

Also i'm planing to make a timer to see, which user beat the game fastest and to bypass hackers my plan is:

 

When game start send message to server: start game

After opening two cards of the same type send message: Two cards of the same type: type1

And repeat this till all cards are open.

And then send a message game over:

 

When every message is recieved, the server calculates the end - start time and save it as user result.

Also if this time is smaller or different than then the sum of all moves... someone is cheating bastard.

 

All message will have unique has, of the user ID, game ID and some salt to check on the server.

 

All messages are Ajax, json format.

 

So i hope you have some tricks, ideas, and so on to share...

 

Also i know there is a lot said in books, but i want to make something simple, like timer counter which will not be cheated easy, or if cheated

when i look at the logs, to see easily that it's cheat result.

[rich]

Is there a reason you want to invest so much effort in trying to make this game hard to hack? Is it actually worth it? Or part of a request from a client or something? (if not, I seriously wouldn't bother, it will consume your dev life and ultimately lead to nothing that can't be hacked anyway). If you want to be really hardcore about it, code the game in C++ and use emscripten/asm.js At least only a very dedicated few would be able to crack that.

[Ezelia]

So first i have doubts should i go canvas or DOM

 

Isn't canvas one idea harder for hacking, you can't jsut F12 and see all cards...

 

why he'll see the cards ? actually, what you display are just empty rectangles, the real card values should be maintained in your game logic.

when a player click a card, at this moment you assign the value of that card and show it ... when the card turns back you don't have to store anything in the DOM (don't know if it's clear ).

that being said, I have the same advice as rich, is it really necessary to protect the game from such hacks ?

[Quetzacotl]

I'm afraid you can't block hacks against game like this. All your logic is available to client, so hashing, salting etc. doesn't change much since hash and salt is on client. This way I can send all messages you need in 0.1 second. But you can make it much more harder to hack by using really complicacted algorithm to make hash, that is splited in few parts in client code (not in one place) and then just obscurify your code. It's hard to read and understand obscurifed code, and additionaly understand complicated hash algoritm, so hacking is a tough job, but it's possible.

[Gio]

If you are really determined to prevent cheating, it can probably be done to some extent, but it's fairly complicated.

 

First of all, you would need to exchange more messages with the server. The server will have to know the type of each card, and only reveal the type to the client when the card is clicked. This would slow things down, and I would advise that you shouldn't use Ajax for that, but something like socket.io that establishes persistent connections and is usually an order of magnitude faster. This approach is much safer with respect to cheating, as the game is essentially played on the server, not the client. However, you still cannot stop someone clicking all the cards on the board, writing down their types, and playing without having to remember anything.

 

There is another approach that I've used in a coupe of (different) situations though: the main idea is to trick cheaters. So you obfuscate the critical part of your code that maintains the types of your cards. Then you keep a couple of non-obfuscated functions in there that appear to store the types of your card - except that these would be the wrong types. If someone tries to cheat by looking at the code, the first thing they do is, presumably, look at those non-obfuscated functions to determine the type of each card. You can detect that on the server side, because you'll see that they're clicking the wrong cards, exactly in the way that you've tricked them into doing. Then you ban their IP address, and prevent them from cheating for real the next time they try.

 

I hope that makes sense

[sbat]

If I understand concept of your memory game, it is possible to "hack" them most efficiently with pen and paper. I.e. you can write down cards you already open and win against an honest player. Or, if it is really a game for money or otherwise worth the effort, it is - in concept - easy to write an efficient and honest bot playing this game.

 

Above limits what you can theorectically protect. 

 

In my past Flash games I only cared to store "Scores" variable in slightly obfuscated way (like XOR it with something and check against other checksum). Otherwise, lots of "young hackers" with ArtMoney-like tools submit too many bogus garbage. Protecting against more serious threats often does not worth it. 

[@99golems]

my philosophy is if people hack your game who cares. If they enjoy cheating in your game then you should consider that a personal victory, because someone is enjoying your game.

[Mike]

First thanks to all answers and here some update...

 

So i went for DOM based game, and custom js code with jquery as base for events and simple animation, also

I'm planing to use:

http://blog.guilhemmarty.com/flippy/

or

http://lab.smashup.it/flip/

 

And about the cheating... it's important not to prevent it 100% but to make it a little bit difficult so I'm going for little obfuscation.

Also the logic for the card pairs will be in the js, random every game start so simple: display block, or firebug want help to cheat.

 

I'll explain why i started the tread:

 

This is game is going to have a score (no matter if it's turns, time, or other score) but there is a sponsor and there will be prices for

the users with best scores (lets say every week top 3).

 

So it's important to have a way to distinguish cheaters versus non cheaters...

 

And here what i have in mind:

 

If i go for the BEST TIME

1. When the game start i send a message to the server and save server time, despite taht js timer starts

2. At every good turn 2 same cards i sent another message (at the and of the game you should have 8 of those for 16 cards 4 x 4 grid)

3. When you open the last two and game is finished send another message + the current js time last say 1m43s

 

Then i calculate the server time from the first and last message, also check if all other 8 messages are between those interval, and save the server time

, also if there is something cheaty with the times, I'll save a marker for this result - as "cheated"

 

And this way i easy can see if some score is, real or not...

 

Still thinking for some analogically way for counting moves so i can have two variables to calculate score: TIME and MOVES

 

...

 

well that's for now...

 

p.s.

And i read many said you can play once write down the types, or so..and then you know them... but that's easily countered by the random factor when pairs are made.

Of course there will always be a array or other variable in the JS holding the info about the card pairs... but i plan to make it with strange name, probably dynamic for every game start,

so it will be a bit more difficult to detect... also minified code as final obfuscation.

[Chris]

I would really go with the approach that the game is in fact running on the server.

 

On game start, you create an array of 16 card values, the client side knows NOTHING about the cards.

Whenever a card is clicked and has NOT been clicked before, a request is made to the server and the card motive is requested.

 

This way the server knows always which cards have been opened. All other ways are hackable and unsafe.

 

About claim that AJAX would be slow: nope, its completely okay for that kind of game. You just have to return a single value with the AJAX request so its not really measureable slower than a Websocket connection.

[Mike]

@Chirs yep it sounds ok

 

One question you mention "Whenever a card is clicked and has NOT been clicked before"

 

So do you have in mind that after once the card value is send from the server, there is no need to make a request again...

and if so if a user click once over every card, can't he than "see" the variable that store the card pair values...

 

i mean, i have always to question the server about the card value until user hit two of the same kind.

[Chris]

If the order of cards change every time the user clicks a card, then you would have to request the value of a card every time it has been clicked.

If you are playing traditional memory, the value of a card doesn't change, so it only have to be requested once from the server.

 

You would still have to send the clicks to the server, but he doesn't have to return anythig (speeding up the process a bit). You are only sending the clicks so the server can keep track on how many cards have been turned.

 

The problem is still: the user could be writing the motive on a sheet of paper, thus never make a mistake once he knows a card value. I don't think memory is the best game to offer valuable prices for

[Mike]

Well, maybe will try to persuade the client to make a lottery with everyone who beat the game 3 times (or 1 time).

 

It still sounds fun and still have a chance to get a price... and the score will be just for fun and comparison between friends.

[Gio]

Just my 2 cents about Ajax vs Websockets (socket.io): with ajax, you have to open an http connection for every message you want to exchange with the server. Regardless of the amount of data you need to transfer in the message, it takes time to establish a connection, so you have that overhead for each message. That's not the case with a websocket.

 

Of course Ajax may still be fast enough for you - that totally depends on what you need. In that case, make sure that you don't initiate a second Ajax connection before the first one has been terminated, because otherwise the order in which the server will receive the messages is not necessarily the same as the order in which you are sending the messages: if the user clicks two cards quite quickly, the server may register the clicks in the wrong order.