# Game Loop design that is speed hack proof

I'm not sure if this is possible, but it's worth a shot asking. How does one design a game loop in such a way that hooking and enabling a speed hack app to the game(dx11) doesn't matter?

I found this in stackoverflow:

I think the reason why i does not work in some applications (mostly games) is because some games link the in game clock to the frames per second. Therefore your game will either tank or crash altogether if you try to speedhack it

• Just for reference, currently I'm using timeGetTime. Mar 28 '16 at 13:26

You can't.

Whatever code runs on the computer owned by the user is under the users control. Anything you program can be circumvented or patched by a determined enough hacker.

The only solution to avoid cheating in an online game is by calculating all game mechanics on the server. When the game is offline, then you have no chance at all.

• The game is online and I just want to have a simple anti-script kiddie protection. I know, you can't protect it from the real cheaters, but at-last I can stop people from just downloading things like CE. Mar 28 '16 at 13:48
• @majidarif But where do you draw the line between "script kiddie" and "real cheater"? If you want a solution which only works against the stock speed hack Cheat Engine, you should have stated that in the question. But your question asks for a solution which is "speed hack proof", which is impossible without server-sided movement handling. Mar 28 '16 at 13:51
• Sorry, I was under the impression that it is possible to fix it that way. But yes, something along the lines of those simple speed hack programs. I'd draw the line by one who downloads and the other who actually reverse engineers the game. I do have server side movement handling but it is failing too. As seen on this question: stackoverflow.com/questions/36258755/… Mar 28 '16 at 13:54
• @majidarif That line is not useful because the people in the first group download the hacks made by the people in the second group. Mar 28 '16 at 14:36
• I doubt my game would get enough attention, to get the attention of the second group :D Mar 29 '16 at 3:47

If you build a networked game, never trust a player more than you trust their controller, just treat them as remote inputs as if they were another controller plugged into the local machine, run all of your final game state simulations on a trusted machine (the host). Most games where speedhacks and other hacks negatively affect players and ruin gameplay only rely on client side simulation for local rendering/sound/reference for state changes sent to server, if the client tells the server something that the server knows isn't true it doesn't matter.

Only trust the host to make authoritative simulations and issue game state corrections to players, it complicates your engine design, but if you want to mitigate hacking, it's a great option.

Client 2 (Non-host): Player is flying through the air majestically at (100, 0, 100) with 200% health.

Host: Client 2 is sprinting forward at (5, 0, 0) with 20% health.

Host: Client 2 kicked for cheating.