I'm developing a simple card game, where there will be a matchmaking system that will put you against another human player. This will be the only game mode available, a 1vs1 against another human, no AI.

I want to prevent cheating as much as possible. I have already read a lot of similar questions here and I already know that I cannot trust the client and I have to make all verifications server side. I intend to have a server (need one for the matchmaking anyway) and I intend to make some verifications server side but if I want to check everything server side this makes my server to be able to keep track of the state of all current games and check every action, and I don't have the money/infrastructure to support that server.

My idea is to make clients check and verify some of the actions made by their opponent* and if they find some illegal action notify the possible cheating to the server and make the server verify it. This will still require my server to keep track of all current games, but it will save resources only checking some things that cannot be checked at client side(like card order in the deck) and only checking other things when they are actually wrong.

*(only those they can check with out allowing themselves cheating! for example:they can't check if the played card was in hand cos that will need them to know all cards in hand)

Summing up, my questions are: is this a viable approach? will I actually save resources doing this or the extra complexity in the server and client for exchanging this messages is not worth it? do you know any game that has successfully or unsuccessfully tried a similar approach?

Thanks all for reading and answering

  • \$\begingroup\$ Of course, then you'd need to validate those clientside checks... \$\endgroup\$ – ThorinII Nov 1 '13 at 6:34
  • \$\begingroup\$ yes, the idea is saving some validations by only checking those clientside checks, not all actions. But as Philip said, its probably a premature optimization \$\endgroup\$ – garcianavalon Nov 1 '13 at 11:49

Depending on the complexity of your game, verifying if an action is legal or not might require to backtrack large parts of the game. An example: Player A says Player B can't play that card right now because he has no ResourceX. PlayerB says he has plenty ResourceX. Who is right? To find out you would simulate the whole game again from start to finish to count the ResourceX the PlayerB has right now. So only verifying the players actions when one cries "foul" might not actually be that much of an optimization.

But is the effort really worth it?

I think you might have a case of premature optimization here. Although I don't know exactly what you are up to, a card game is usually not that computationally expensive on the server-side.

Card-games are usually designed to be played without computer support, so their game mechanics are usually computationally simple enough to be performed by humans*. Also, human players usually take several seconds to make a move, which feels like eternity for the server. That means your server has only a light-weight task to perform every few seconds per game. I don't know how many simultaneous players you expect, but as long as you are still in the scale of a non-commercial hobby project, I doubt that even the cheapest server you can find won't be able to handle it. On the premise, of course, that you know how to program efficiently.

*) as long as you exclude the players decision-making. Most games are build on the premise that the ideal winning strategy can theoretically be computed, but doing so is so complex that players and often even computers are unable to do so, so they need to use intuition. But you said you want no AI and only want player-vs.-player, so this is outside of the scope of this question. But it also makes one think about another cheating-aspect: Did you consider a player using a program to help them with decision-making? Like one which tells them the exact probability that the opponent has a certain card on hand?

  • \$\begingroup\$ I think you are right, I'm trying to avoid overloading the server before actually overloading. The fact that you answered my question with the same question (is the effort really worth it) sums it up pretty well \$\endgroup\$ – garcianavalon Nov 1 '13 at 11:43
  • \$\begingroup\$ For other visitors, note that, unless it actually interfaces with the game code (and potentially even then), the ability to detect an external program providing 'probability' help is essentially nil. \$\endgroup\$ – Clockwork-Muse Nov 1 '13 at 14:13

"I want to prevent cheating as much as possible." - So say we all. :)

Perhaps a more sensible approach is to not waste time doing anything above and beyond the reasonable and generally effective anti-cheating measures.

Those are: double-testing for bugs that would allow players to perform any illegal actions, and sending only encrypted data (via https or custom encryption), and encrypting the app itself to make hacking more difficult. That's it.

Players are most likely to cheat through bugs in the game than anything else.

You might simply do better, development-wise, to wait whether your players actually care enough to cheat. If the app is not in a figurative "top 500 chart" and cheating isn't dead simple (ie bugs) players won't care enough to waste their time trying to cheat through other measures, such as modifying the IP stream or hacking the app.

Unless of course you're dealing real money and actual prizes here.

If your app is successful and cheating does become a problem, that's when you should tackle it. But at this point it's going to be a cat & mouse game, and the cheaters will always win.

Basically what I'm saying is that 100% of your players won't cheat if it isn't possible through a reproducible bug and/or your app is not very popular. If your app does become very popular, less than 1% of your players will cheat in ways you can't even begin to imagine.

So as far as cheating goes, you should protect yourself against the obvious cheats (bugs, encrypting both app and IP stream) and only react to actual cheats you learn of, and address those directly. What you really want is to log all player actions, have them verify on the server and if you find an illegal action that is occuring rather often, find out why. Could be a bug, could be an exploit, could be a technical hack.

The most important anti-cheating measure is learning that players actually DO cheat, and how.

  • \$\begingroup\$ thanks, a very good answer too. It makes no sense to spent time trying to make the best anticheat solution while having exploitable bugs, I shall work before in the core things every game needs protection wise an then fix the problems that appear, rather than the other way round! \$\endgroup\$ – garcianavalon Nov 1 '13 at 11:47

I think you are running into some other problems here. What if the player is faking to be a normal client (by simulating your network traffic) and is using to corrupt your game by wrong validiation?

Instead of trying to build a bullet proof client system, which will lead you to continious bug / exploit fixing and banning, I would try to simplify the server system. I do not know enough about your game mechanic, but maybe you are able to boil the information on the server down to a minimum.

In general you should assume that the client you are talking to could deploy any code and game mechanic it feels like deploying. And this makes client side validiation nearly impossible


It depends a bit on what you consider as cheating. Is it using a tool to make/calculate the moves? Is it to change the deck of cards during the play? The first thing will be difficult to tackle. For the second one you can think about having each user insert it's cards and make a hash-code that is displayed on both sides. At the end the server can calculate the hash with the played cards and cards left. If a hash does not match then the user has cheated. If the rules were not followed then you can check this on your server too. You can do this on a user request to save resources. No information on the cards become available. To make the generation of the hash a bit more unique/complex you can include the username in the hash.


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.