# Cheat prevention - how far to go?

This topic is 3624 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

In the context of making an MMORPG, how far should I go with cheat prevention? One of the issues I'm thinking about is walking through walls. To prevent that on the server side would require a lot of number crunching. It's not a simple teleportation issue where we can just check the magnitude of the displacement. If the gameplay was 2D (which is often the case in 3D looking games), it wouldn't be too much of a strain on the server. How important is this anyway? It's certainly not an problem that puts development on hold until it's solved, but I'm curious about it nevertheless.

##### Share on other sites
Quote:
 Original post by SteveTaylorIn the context of making an MMORPG, how far should I go with cheat prevention? One of the issues I'm thinking about is walking through walls. To prevent that on the server side would require a lot of number crunching. It's not a simple teleportation issue where we can just check the magnitude of the displacement. If the gameplay was 2D (which is often the case in 3D looking games), it wouldn't be too much of a strain on the server.How important is this anyway? It's certainly not an problem that puts development on hold until it's solved, but I'm curious about it nevertheless.

Cheating is not entirely a bad thing in single player games but with any multi player game it becomes much worse. I'd fixed it later though since thats not really important right now, or in other words wait until you have players who do cheat.

##### Share on other sites
Well, "Yes" to fixing it later, as I already said. But I'm not sure it's a good idea to wait until people are cheating. There's not much time between one person discovering the cheat and lots of people doing it. I'd rather not be patching under that pressure.

I'm really interested to find out how other games deal with this, particularly the more popular ones as they'd take a more practical approach.

##### Share on other sites
when the client tells the server its new position, at least make sure that the distance is sane.

For our game we tried to use pathfinding data initially, but that turned out to be a really bad idea. Pathfinding data was not good enough and it was expensive. so at least avoid that idea :D

An idea could be to check if the client position that is reported is inside collision, and make the walls thick enough so that the client will have to report positions inside geometry to avoid rubber banding back to org pos due to teleport/speed hack.

If strain is too high, you can do this sample based.

It also depends on how much of the simulation you are doing on the server.

##### Share on other sites
That's an interesting strategy, but the client could also just report a fake path to the destination.

I guess this problem is not completely preventable in a game where the client reports player positions, such as the type of game where players use the keyboard to move around. In a game where players click their destination, the server can control player movement so that this doesn't become an issue.

##### Share on other sites
Quote:
 That's an interesting strategy, but the client could also just report a fake path to the destination.

true, but to reach there in the timeframe, they would have to move a greater distance.. and that should trigger your speedhack detection ;)

##### Share on other sites
To reduce most of the stress on the server first check on the client if that move is possible. After that then you can then send a request to the server if that move is possible. The server would also check if that move is possible and then report back.

While people could still edit the client to send the request still, this method will easily eliminate most of these requests to the server. And even if a person does edit the client to send it, it still will not effect the game since the server still does a check. Since most people will not know how to edit the client you shouldn't have to worry.

##### Share on other sites
Can you describe how your game works, specifically movement and physics? How do you handle collisions currently, just client side? Are your environments tightly packed like an urban city or do you have larger areas? Are there any areas that are stacked on top of each other? Does your client keep the player "on the ground" or is that managed by the server? Can players reach high velocities moving or do they move relatively slow. Are you using TCP or UDP?

There are a lot of factors that you have to consider when trying to consider cheat prevention. Let's say you perform some simple mesh collision detections between walls and players. That might seem like it would work well, but what happens if the player fakes their height coordinate as well on the move, screwing up your collision detection. If you don't factor in the height aspect and just process entities in a 2D space, you cannot have any stacked areas since legitimate moves might be blocked by obstacles on another height.

There are plenty of implementations that are susceptible to being hacked, so I'll describe one that I've seen used that you just can't "hack". This is used in a F2P MMORPG. The process goes along the lines of:
1. Client sends a move command to the server (The client does not actually move yet)
2. Server validates the movement command by checking collisions server side and sends a result.
3a. If the result is valid, server sends a packet containing the movement packet for the player for the client to replicate and the client will then move.
3b. If the result is invalid, server will send a packet containing the current position of the player so the client can resync itself into the server position.
4. If a collision happens, the server will send a different type of movement packet that tells the entity to stop and will set a new position.

The downside to this approach is that it requires the extra calculations on the server, but the positive side is that players cannot hack this approach. A client with absolutely no geometry in it to collide with will still be bound by the world that exists on the server. They can try to fake their movement height, but the player is bounded by the height at the position the player is on the server, so all you can do is screw up your own client view. The game uses a dead reckoning approach, so you cannot speed hack either by sending movement packets faster, it's all server simulated.

This sort of approach is what you really want to prevent arbitrary movement cheating. You want players to be bound by the server, not the client. That might not be easily doable in some types of games though, so that's why all the questions in the beginning. That is not to say the approach is fool proof though, the system still is bound by the rest of your game server.

If an exploit is found where players can legitimately increase their speed on the server, then there is no way to prevent that "speed hack" unless you have coded in other checks to verify max velocities for players or movement deltas.

From a gamer perspective, cheaters ruin games. Invest the time and effort to solve this problem now before you get further along. Having to upgrade your server to be able to handle extra calculation will cost you a lot less in the long run than skimping out and having your reputation ruined and player based destroyed by hackers. I've seen bugs in games where I'm sure developers told themselves, "we can fix it later" and forgot or didn't and it was exploited and they had to spend a lot more time and money later on addressing the issue after the game went live.

In my opinion, handling cheating should be handled at the design stage and propagated through the game design rather than added on later as a feature. However, that is not yet realistic nowadays because how many programmers understand cheating in games from a programming perspective? Not many. It's not a part of nomenclature and the software security domain is very specialized (and intimidating) in such a way it's just an afterthought for game developers. Most game developers learn the cheating problem the hard way, hope you won't have to [wink]

##### Share on other sites
DarkZlayer: Please read again the part where I said that this isn't an issue where the server can control moves before they happen.

Drew: Thanks, a lot to think about.

The movement system is what you'd typically expect from an FPS, except that the view is 3rd person (mostly chase view) and players can't run as fast as in some FPSs. It's not an FPS and there is nothing special in the physics department. On the client side it uses Irrlicht's builtin collision detection, with the player bound by an ellipsoid. Most of the gameplay would occur in outdoor areas, but there are definitely stacked areas indoors so the gameplay isn't 2D.

I guess what i'm looking for is not the perfect solution, but something effective in most cases. Perhaps it might be feasible to model the scene graph on the server and just check that the line between position[T] and position [T-1] doesn't intersect any walls. It's not perfect because it doesn't replicate the client side bounding ellipsoid collision detection, but it just might be feasible. And it's something that could be added on later, because it's detection, not prevention. But I get the importance of designing the world from the beginning in a way that's more conducive to cheat detection.

[Edited by - SteveTaylor on January 12, 2009 6:38:38 PM]

##### Share on other sites
Quote:
 Original post by SteveTaylorWhat I really want to know is the feasibility and strategies relating to the detection of walking through walls in the situation that the player moves without waiting for approval to do so (eg. keyboard control).

Consider the problem first. Why would wall-hacking matter:
P --+--- |D <-+
To go from P to D, player could wallhack, but why. It just saves them a detour of 2 meters.

Wall-hacking for this purpose would mean preventing people from going into areas they are not allowed to. That is much simpler.

On client, do full collision detection + topology check.
On server, perform topology check from previous to current position. This requires a simple graph search over an area with radius of several meters.

Inside of house is region A. Doorway is region B. Outside of house is region C. To go into a house, player must go from C through B into A.

Topology check now is:
If player moves within same region, do nothing, do velocity check between old and new position.
If player moves between regions, check if there is path between those. The only path from C-A goes through B.
First test if player can enter B. If not, server ignores move request.
If they can, test if length(C->B->A) is less than what player could possibly walk since last update.
If no, something is weird, don't allow movement.

With each rejection, player's server-side position doesn't change. So they don't receive data about what is inside the building, they can't interact with objects inside, etc.

The above tests aren't as much concerned with whether player is precisely where they claim to be down to an inch. It's simply about testing for important stuff.

It checks for speed-hacks over long term (calculate the path player walked, check every few frames), completely prevents players from entering restricted areas and supports overlapping floors.

Jumping between regions can be checked as well.

However, full inter-character collision with full 3D movement is a different story.

Quote:
 There are plenty of implementations that are susceptible to being hacked, so I'll describe one that I've seen used that you just can't "hack". This is used in a F2P MMORPG. The process goes along the lines of:

How does that work with normal MMORPG latency of 50-350ms?

1. 1
2. 2
Rutin
19
3. 3
4. 4
5. 5

• 13
• 26
• 10
• 11
• 9
• ### Forum Statistics

• Total Topics
633736
• Total Posts
3013598
×