Should collision detection be done server-side or cooperatively between client/server?

Question

I am working on an online game that will have very heavy collision detection processing. Player models will collide with other players, mobs, structures, terrain, and solid objects that only exist server side (not stored in client data files).

For security purposes, should I do all collision detection server-side? Or should I have the client do the detection and have the server follow up on it somehow? I feel like it will be too much for the server to do by itself (I am designing the engine for hundreds of players on one server).

Does anyone know how mainstream MMOs do it? I know that almost all MMOs right now are susceptible to physics hacks and usually deal with them by detecting hacks and banning people. I would rather the hacks did not work at all, at least for the physics component.

Answer 1

It seems like the obvious answer is to do most of your detection client-side (for smoothness), and then you interpolate to what the server says if your client is too far off. The server will tick at a less frequent rate than the client (like, say, 10hz), and would probably need to have some basic "can this player have reached where he says he currently is from his last known location" code, which implies some kind of nav mesh-type solution and pathfinding.

That might be prohibitively slow depending on what your needs are. You might make a design decision, for example, to not care about player-player collision on the server. Most games, as far as I know, don't even care about that on the client. It really depends on what your needs are.

But the rule of thumb is that you should never trust the client. It if impacts gameplay, you have to at least verify it on the server.

Answer 2

So, a few answers here.

• Client-side collision is ideal from a performance point of view and from a player feel point of view. You don't want collision to be laggy, you want players to run into a solid object and stop. If you do it server-side, you're either looking at rubberbanding players all over the place or giving players noticable lag when they try to move. Bad mojo, in both cases.

• Server-side collision is ideal from a security point of view. The closer your clients get to "dumb terminals", the less exploitable your game is. There's a reason that nobody playing a text-based MUD has to worry about wallhacks or speedhacks - it's because the client isn't doing anything worth mentioning.

• Doing both is "ideal" in almost every case. Let the clients do their thing, then doublecheck on the server to make sure people aren't cheating. The downsides are complexity, synchronization (what exactly do you do if the two disagree), and sheer server CPU usage.

• What I recommend is to do it almost entirely client-side. The client is authoritative about its position, just like in a full client-side system, and does all its own processing. On top of that, you randomly have the server check various players once in a while. Keep the server load low, but this will root out cheaters surprisingly fast.

Alternatively, do it client-side for now, add the server-side verification at some point in the future if your game gets popular enough that people are cheating in it. Which, let's be honest, it probably won't, so there's no point in spending the coder time on it right now.

Answer 3

World of Warcraft doesn't do collision detection between players/mobs. There may or may not be technical reasons behind this decision, but really, this has to be more of a game design decision than a technical decision:

Imagine how exploitable it could be in player-vs-player situations. Or how hard it would be to use the bank/auction house/mailboxes if other (often idle) players blocked your movement!

As for client vs server based collision detection - really, unless movement is very slow, it has to be primarily client-side, so it looks right to each client. Laggy/delayed collision response, and/or colliding with 'invisible' objects would be quite unpleasant.

Answer 4

If you are concerned about the hacks and that has big impact in the game play then the answer is YES.

In my browser based game which is a "city building" kind of game, I am not bothered about the hacks because the client engine is not going to fail when I layout the saved game state.

However it could potentially abuse the gameplay as the player needs to spend game coins (or premium cash) to expand the playable area in order to build more houses/buildings. So, I am going to implement a simple check of number of tiles occupied by the newly added building agains how many free tiles are available.