We must distinguish cheater from hacker , and we must not exclude cheater detecting from game engine.
However, I do not have much time now.
We must distinguish cheater from hacker , and we must not exclude cheater detecting from game engine.
However, I do not have much time now.
You could start by assuming that everyone is a cheater and a hacker. If itās a networked game, let the server (or other clients) verify all the data that the client sends, and refuse/correct any data that is inconsistent.
You need to keep in mind, though, that someone who plays the game owns the computer he plays it on. He can do whatever he wants with the game, and play the game whatever way he wants to. You cannot restrict someone from changing the way the game works.
What you can do is (in the case of a networked game) make sure that someone who plays the game does not ruin the game for others. You can do that by making sure that the data that is received from that client is consistent and makes sense.
splitting your code into tiny pieces (page wise, line wise, letter wiseā¦) and assign them into the cells.
No complete solutions here, but something to think about.
Using the typical aimbot example, a hacker/cheater modifies the client to allow āperfectā aim to be toggled on/off by clicking an icon on the screen. The client is also modified to respond to exe size, cksum request, etc. with the correct answer when queried. If the perfect aim function is not overly used it will just appear, statistically, that the player is really good, and any kind of programmatic checking will show the client is valid.
Even something like a small app that loads the client from a server every time can be hacked to instead load a modified client from a local file.
If there was a silver bullet, commercial PC games would not have this issue. Probably the best deterrent, IMHO, is threat of banning combined with frequent updates in which the installer is downloaded automatically and does a cksum of the existing exe against itās file size (and of course requiring the current version to play). Not going to stop updates if the hack is an external program, and too many large updates would annoy legit players.
For a completely different direction, if it were me Iād combine the threat of banning and occasional āsmartā updates with google searches. Look around for publicly known hacks and deal with them on a case by case basis.
you see thats easy like cheesy. just check for anomalies in your game.
solutions comes, solutions goes, but the idiot will stay. yes the live is strange, isnt it. sometimes its a shame to be a human.
peoples spend tons of money into poo, and they are wondering why the poo isnt working. then they going to spend more money into this poo, to bring the poo to work. and yes of course people will bue the poo, after they got brainwashed. but i dont believe that this is the right way. its just the way of manipulating idiots. and yes a idiot is also able to manipulate. if not, the reallity wouldnt be real.
Doing every calculation on the server wonāt solve the problem of FPS aimbots, because aimbots donāt break the programmed game/physics rules. They just simulate very fast reaction times, and very precise tracking.
I donāt think aimbots use image processing algorithms, they simply use a hacked client. So, the only cure is making your client hard to reverse engineer, and put some encryption into the network protocol as well.
However, you then have to make your game in C/C++ rather than in Python, as Python is much easier to reverse engineer (although you might try some code manglers too; i.e. they rename your functions/variables to randomly generated names; IIRC there are Python bytecode compilers as well, they increase obscurity as well).
For the record, if you pack your Python game into a .p3d archive, it will be compiled to optimised Python bytecode, which is significantly more difficult to reverse engineer than Python code.
Examples of how complex this topic can become:
http://en.wikipedia.org/wiki/Warden_(software)
en.wikipedia.org/wiki/Valve_Anti-Cheat
These are the big players and they know that this problem canāt be solved. You probably have to find case-by-case solutions based on your game and the potential for cheating or hacking.
Unfortunately this is not really a solveable problem. If you find a solution, Iād advise hitting the patent office, because some very big companies would like to know the answer to this.
Theres a good strategy however you can deploy to mitigate the issue.
Chances are you need to do this anyway to make sure player A and player B are looking at the same scene and not drifting out of synch.
Now within this , you might also want to throw in a few other sanity checks as well. Did a player just walk through a wall? Well thats not on. Is he floating 10 meters in the air? Thats not on either. Is his hit points not going down after being shot? Thats not on.
Unfortunately you can build in more and more exceptions, but players will keep coming up with newer and newer ways of exploiting it. However keeping a consensus between clients makes it difficult to do anything too egrarious.
Whatever you do, donāt even bother with āsecurity by obscurityā. Encrypting the communication wonāt work, because a hacker will just yoink out the private key from your binary. Compiling the python into .pyo files wont work, because they can just be decompiled. Believe me there are some very clever cats out there, and if client-side security giants like ilok and punk buster continuously get caught with their pants down, and those guys have intense security strategies, you donāt stand a chance, Iām afraid.