I’ve built FPS frameworks before and used to work on cheats for hvhing, so I know the kinds of exploits clientside cheaters look for.
But how do I hide my code / prevent cheaters from abusing it in my framework?
1 Like
As long as you validate on the server, anything the client modifies should only affect their screen and not the game.
For instance, let’s say we store the number of bullets they have. They shoot, they subtract the number of bullets locally, and then the server does the same. Now, let’s say they have 0 bullets left. Using their leet haxxor skid exploits they change the bullets they have back to 1. They shoot again. On their screen, they shoot. On the server? Absolutely nothing happened. Meaning they’re actually just a schizophrenic kid in their mom’s basement who thinks they shot a gun while everyone else looks at them funny.
Now, that’s just one topping on the pizza—the cheese, if you will. But a good pizza has more than just cheese. You also need the pepperoni. And in this case, the pepperoni is making sure RemoteEvents can’t be arbitrarily fired with whatever data the client decides is correct. Now, if you do the above properly, this won’t be as big of an issue, but it will still be a problem if you don’t validate the exact data the client sends. For instance, let’s say a client sends the position they click. You don’t trust that entirely and say “well, that’s where they said they hit!” No! You treat that as the direction they’re shooting in, and then raycast from their gun. This way, they might SAY they’re shooting at this guy behind a wall, and according to their their leet haxxor skid exploits, they hit him good! But actually, they’re still just living in la-la land: The server knows they didn’t actually shoot through the wall.
That’s as much as you can do in your FPS system itself. Outside that is just plain old anti-cheat and good programming habits.
3 Likes
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.