I have gone through many articles on the internet and got to a final conclusion that their is almost no way to protect the game (it can be hacked or its code can be extracted from its APK) and should write more server side code than client side code.

But i also know that the only consequence i will face is that server would have to handle 2 times more of data.

And i wanted to ask you that if i should write server side code or client side code for an MMORTS game (Massively Multiplayer Online Real Time Strategy)?

  • \$\begingroup\$ You'd like us to tell you that it's all right to only write client side code because you don't feel like handling twice the data? What is your question about? You have to decide what's best for you: (high) cheating probabilities or higher data transfer cost and handling? What's best for your (genuine) players? Do you want to make money? \$\endgroup\$ – Vaillancourt Nov 18 '15 at 11:02
  • \$\begingroup\$ @AlexandreVaillancourt the main problem is that the person is not able to cheat in the game because the game comprises of a tournament. After a person wins a tournament he wins real cash. So, what do you think i should do in this case? \$\endgroup\$ – Developer Nation Nov 18 '15 at 11:06
  • 1
    \$\begingroup\$ "the main problem is that the person is not able to cheat in the game because the game comprises of a tournament" In what a tournament prevents cheating? Since the middle age, dishonest knights had ways to cheat. Tournament does not prevent cheating. \$\endgroup\$ – Vaillancourt Nov 18 '15 at 11:12
  • 1
    \$\begingroup\$ And if the genuine players play for money, and they find out you did not take enough precautions to prevent cheating, I'm sure some will be annoyed enough to send your a letter from a lawyer. \$\endgroup\$ – Vaillancourt Nov 18 '15 at 11:14
  • 2
    \$\begingroup\$ There are haters out there. If you don't prevent cheating, your game will be screwed from day one. \$\endgroup\$ – Vaillancourt Nov 18 '15 at 12:14

Any moderately popular multiplayer game will be targeted by hobbyist cheat developers who just want to exploit it for fun. But when you also add an incentive to cheat in form of price money, you are practically paying people to hack your game. It is a literal job offer to professional cheat developers.

When you want to prevent cheating, you need to calculate all game mechanics which influence victory or defeat on the server and not trust any results from the client.

When your RTS implements some fog-of-war mechanic, you also need to manage which information you send to the clients. Do not send any information over the network which is not supposed to be known to the receiver.

When you do this well, the only cheating you still need to be afraid of is automation, which can only be caught through heuristics.


Foreword: I'n not an expert about MMOanything or games in general, but I have a decent grasp on security and I wrote more than a single client/server app. Also being an avid gamer kind of helps.

Your conclusion about the inability to protect your game is essentially correct, at least if you expect it to be 100% cheat free: whatever logic you delegate to the client has a chance to be bent by a very determined player (and if money is involved, odds are you'll find some...), whether because you are trusting the client (eugh...) or due some glitch in the validation code you might use if you don't.

You could in principle make a game completely cheat free by delegating almost everything on the server side, and turn the app into a plain graphical interface that just shows the battle outcomes, and accepts inputs (with heavy validation too...).

Point is, while this approach is quite easy for gambling and very slow paced games (board games, for instance), it quickly becomes unpractical for all others, especially when visual delay is important (think about bullets, for instance), and unless you greatly simplify the RTS mechanics of your game, odds are this approach will not be suitable for you.

So this is what you can do to make your game reasonably cheat free: if your players compete against each other in a way that it's disadvantageous for all players to cheat at once in a same game (for instance because they gain nothing by favouring a player over another, or because the pot comes equally from all player funds) you can make each client validate the data coming from the others.

I'll make a simple example: suppose you delegate all bullets physics to the clients (a reasonable assumption), you can make sure that each client keeps tabs on the others or a subset of the other clients (as a full check would scale like O(N^2), even though reducing the checks would greatly reduce the security of the system as a whole).

As soon as a client detects someone firing at a rate not allowed by it's level or by the game rules in general, or some bullet reaching destination faster than expected, it will rise a red flag by the server and mark the whole game as invalid.

At this point the game can be cancelled (no money paid), and the offending player can be marked as a potential cheater (if it's the first offence) or banned, if he has been repeatedly marked (and some external check verify his fault, otherwise malicious players could use your own system to ban first class players... See how tricky this thing is? :) ).

Mind that this is a very basic example, with a very basic response from the system (which in turn might allow cheating by abusing the rules. A player might use this to cancel a limited number of unfavorables games to get a better shot, or just for griefing).

The topic is very complex, and not being an expert I'll stop here, I still hope to have gave you an idea about what expects you if go ahead

Hope this helps

  • \$\begingroup\$ i like your validation example but one small question i have also seen that some hackers extract the code of apk and change code according to their needs. I would like to know how do i validate a 250MB APK file that it is the same file that is on server and not a file that has been altered. \$\endgroup\$ – Developer Nation Nov 19 '15 at 5:48
  • \$\begingroup\$ @DeveloperNation: I did it for fun a couple of time, you don't need to be much of a hacker... as for the validation: you can't. period. Point is: your code will run on what is called "untrusted hardware": it means that your users can do what they want, how they want it, with your code, and tell your server whatever your server "wants to hear". As long as trusted computing is not involved (and I don't want to touch the argument with a 10 meters pole) every measure you take to prevent attackers from reverse engineering your apk can be considered at most a "speed bumper" \$\endgroup\$ – R1ck77 Nov 19 '15 at 10:22
  • \$\begingroup\$ one more thing that if the game is browser based then will u consider it to be still on the untrusted hardware or not? \$\endgroup\$ – Developer Nation Nov 20 '15 at 4:19
  • \$\begingroup\$ @DeveloperNation: yep, the same considerations apply \$\endgroup\$ – R1ck77 Nov 20 '15 at 7:45
  • \$\begingroup\$ but the software is kept on is the main server only the display part is done on the browser then how come it is considered as untrusted? \$\endgroup\$ – Developer Nation Nov 20 '15 at 8:05

You need to write both, probably. Some games leverage existing applications (MUDs for instance can use telnet) however odds are you are going to want your own client so that things are presented in a certain manner and the user can interact in a certain manner -- user experience, etc.

One form of cheating is to alter the game state in a manner that is not allowed. Because the client is entirely in user land you cannot trust input from it. This means your server needs to ensure the game state integrity. There are a number of techniques based on your game and requirements.

Another form of what is considered "cheating" in some games is botting (automated playing). This generally requires work on the client side of things such as memory scanning and other neat stuff, read up on VAC and Warden for client side techniques.


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