Player to player collision in MMOs

Started by
5 comments, last by DarkAltar 5 years, 11 months ago

I wanted to get some thoughts on player character collisions in MMOs for my project.   As I recall the original Everquest had them, however WoW didn’t. I also remember Age of Conan had them but I’m guessing they were done on the server which was highly annoying because you could collide with things that were unseen. I’m not sure how EQ did them but I don’t remember having this problem in EQ, but it was a long time ago.

My general idea as to do player collisions on the client side. A collision would only affect a given clients player character as seem from that client. On the server, characters would pass right through each other.  This means that because of lag, two players might see different things during a collision or one may think there was a collision while the other doesn’t, but I figure that’s less annoying than colliding with something you can’t see and everything should resolve at some point.

There is one more case which I can see being a bit problematic but I think there might be a solution (actually my friend suggested it).  Suppose two characters run to the same spot at the same time.  At the time they reached the spot it was unoccupied but once the server updates each other’s position, they both occupy the same space. In this case after the update, a force vector is applied to each character that tries to push them away from each other. The vector is applied by each client to its own player. So basically player to player collisions aren’t necessarily absolute.

I was also thinking you could generalize this and allow players to push each other.  When two players collide their bounding capsule would be slightly smaller than the radius where the force vector would come into play. So if you stood next to another player and pushed he would move.  By the vector rules he is pushing back on you (or rather your own client is pushing) but since your movement vector could overcome the collision force vector, only he moves unless he decides to push back. You could add mass calculation to this, so larger characters could push around smaller characters more easily.

Of course there are griefing aspects to this, but I was thinking I would handle that with a reputation/faction system. Any thoughts?

 

 

Advertisement

The way collision works in most networked titles, including MMO-s, is two-fold:

1) the client side code performs its collision tests to provide immediate feedback to the end user, removing lag from the equation

2) to avoid any third party intervention and potentially mitigate player-to-player lag, the server always performs its own collision checks and syncs its state to all players periodically

You cannot defer this check to any single client, because doing so is prone to both cheating and technical issues, like rounding errors specific to different systems, which can easily desync the game state.

Keep your gameplay code on the server, always. Emulate it on the client to make the local user experience more immediate and responsive, but always, always validate it based on the server state.

https://gamedev.stackexchange.com/questions/48815/online-mmo-collision-detection-for-players-walls?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

 

16 hours ago, irreversible said:

The way collision works in most networked titles, including MMO-s, is two-fold:

1) the client side code performs its collision tests to provide immediate feedback to the end user, removing lag from the equation

2) to avoid any third party intervention and potentially mitigate player-to-player lag, the server always performs its own collision checks and syncs its state to all players periodically

You cannot defer this check to any single client, because doing so is prone to both cheating and technical issues, like rounding errors specific to different systems, which can easily desync the game state.

Keep your gameplay code on the server, always. Emulate it on the client to make the local user experience more immediate and responsive, but always, always validate it based on the server state.

I'm aware of the potential for cheating but the way I look at it is this...... I'm going to have full resolution terrain data on the server also. Since I'm using run time procedural generation it has to be there for pathing.  It will be a kind of JIT (Just in time) terrain, the same way I do it on the client. In any case I can do cursory checks on player movement with it. I won't do full mesh collision but for instance I can take the center point of one end of the player capsule, and send down that point's path to the server. Then I just check to see if it passes though any faces. It's a lot easier than actual collision and response. If something seems off,  I can flag that player to see if it continues to happen, and if so just disconnect them. As for rounding errors I'm not sure why that's a problem, at least for collision.  It might be a problem with the procedural generation but I was under the impression that IEEE floating-point was pretty standard.

I don't think rounding errors would be an issue for a typical MMO where clients are not expected to maintain a 100% replicated copy of the server state. (The IEEE aspect isn't relevant however - different computers can handle operations differently.)

Getting back to the actual policy decisions - this is more about game design than programming, because whether you need players to be able to block each other, or shove each other, is entirely about how you want things to play. Personally I would probably just allow players to pass through each other because the alternative is open to too much abuse. And even if you wanted to allow player-to-player pushing physics, the latency on it would make it pretty awkward anyway.

In Final Fantasy XI online, if you touched another player that had been idle for a few seconds, you will not collide with them. If 2 players are moving and touch each other, they stop each other for about 1.5 seconds, and then they can run through each other.

This topic is closed to new replies.

Advertisement