Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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.

share|improve this question
add comment

4 Answers 4

up vote 19 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
Although the question isn't about whether or not player vs mob/player collision is bad game design, I would suggest looking at games like Darkfall Online where everything is solid. It adds a new dimension to gameplay and allows you to do very interesting things with the game. I would not worry about players blocking things like banks in my game because there will always be a small gap where players can see through to open the object. –  BarakatX2 Sep 17 '10 at 2:24
    
You could have players be blocked by anything it could attack and anything they cannot attack they can simply walk through. For instance, players would not be able to walk through mobs since they can attack mobs. They also would not be able to walk through players while they are flagged for PVP since they are flagged PVP. A player that is not flagged PVP could walk through any player, even those that are not flagged PVP, because they cannot attack those players. –  Azaral May 2 '12 at 21:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.