🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Player-to-Player and Player-to-NPC collision in a MMORPG

Started by
2 comments, last by Daedalus 23 years, 8 months ago
Hi, I''ve been working on a MMORPG game engine for a while now (isn''t everyone?) and I have a question about collision detection. Me and my friend, with whom I''m doing this, have agreed that all collision between the player and landscape/static objects can be off-loaded to the client''s system. However, we disagree on whether player-to-player and player-to-NPC collision detection should be done on the Client systems or on the server. I tend to think that the latency between the client and the server (in the Player-NPC collisions check) much less the combined latency between the client, the server and a second client (player-to-player collision) would be too much to effectively allow for the clients to determine collisions in this case. The only way I can see to get any consistency in collision checks would be to make the server responsible for them. My friend, on the other hand, doesn''t think it would be all that tought. He advocates letting the client do all collision detection and then having the server do some sort of check when two clients disagree over whether a collision occurs. My biggest problem with this approach is that both clients could be so lagged behind the real state of the world that neither one realizes that a collision has occured and thus there is no way for the server to correct them. So, what do you guys think? -Daedalus
DM's Rules:Rule #1: The DM is always right.Rule #2: If the DM is wrong, see rule #1.
Advertisement
Here''s a little story. Ignore if your engine is in 2d, because most of the problems I describe won''t come up.

In DeusEx, you can get pass some trip wires by hitting the auto-save button and running forward. The game gets so choppy that the collision detection skips the frames that you''re intersecting with the trip wires.

My point is that unless you do a fixed maximum motion per frame lock on the client side (highly unrecommended) the client can put a bubble in his execution (accidental or otherwise) that can let him walk through people or other dynamic objects, just by stalling the frame for a few milliseconds, in the game equivalent to quantom mechanical tunnelling. Now a smart collision detection algorithm will probably prevent crossing through walls, doors, or whatever, but if for example an NPC is supposed to block a corridor, but has just enough side to side motion, the client might forward project him out of the way enough to slide by. So even if you let the client handle some of the collision detections with dynamic objects, you still need to verify most of them. And if you''re going to verify them, you might as well just handle them completely on the server end.
If you want to avoid cheating in the game as much as possible, you better do server-side checks for all collisions.

The first thing I did in Ultima Online was flatten out the terrain (mountains and such) and attempted to walk over it. Well, guess what, they do a server side check to see if you can walk across something. If they had not done this check then I would have been able to cross otherwise non-passable terrain.

If your engine is 2D then you will have less problems with server-side checks. But if the engine is 3d then you are going to have some issues.

Take for instance Asheron''s Call. You can pass through some locked doors in that game by just rammming through them. I''m not sure if the server or the client is failing here. I do know that my client sometimes lets me through things only to get popped back (I assume by the server.)

Bottom line, check everything unless you want players doing all sorts of illegal things.

-AG


Hi again,

First I want to say thanks for responding, any help

To answer the first question, yes my engine is going to be full 3D.

SiCrane: Thats exactly the conclusion I came up with. I figured that collision with static objects could be done on the client pretty well and could be pretty easy to check cheating on. As for the collision with dynamic objects, by the time you implemented a cheat-proof system you''d pretty much be doing the collision on the server anyway.

arrogantgod: I was planning on doing the simplest 3d collision checking (bounding spheres) I could do just to make sure that people couldn''t space shift themselves throught objects like SiCrane said. Then, once the server reports a collision to the client the client could be responsible for calculating the specifics of the collsion. It seems like a good compromise to me and it would be pretty cheap computationally.

As for AC, I''m sure they do some of the collision checking on the server. What your seeing with the ruberbanding is probably the client side "dead-reckoning" making mistakes. Like you said, the server then send the client a "reality check" and you are summarily sent back to the other ide of the object.

-Daedalus
DM's Rules:Rule #1: The DM is always right.Rule #2: If the DM is wrong, see rule #1.

This topic is closed to new replies.

Advertisement