🎉 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!
Collision detection/movement in MMORPG
Author
It seems every MMORPG has chosen a different way to implement how you can move around and when you collide with things.
The one I hate the worst is the UO step-freeze-step-freeze method. They obviously get server side permission for each step you take. This isn''t bad if you have a very good connection, but what I ended up with most of the time is being frozen in mid-animation.
Then there is the "let the client go where he wants and rubberband him back when the sever says he hit something" method. This is the technique used in LostLogic''s book. It works really smoothly on my friends powerhouse computer with a cable modem. However, on my 400Mhz and 56K modem, I get severe problems with coliding at the wrong places, and zoning way out off the edge of the map. In MGP, LostLogic states that we can''t trust the client to send coordinates directly so instead we should use vectors to update the server to our location.
However, after much thought I have a third solution. As far as I can tell this has to be the method that Everquest uses. (In my opinion EQ has the smoothest handling for people with bad Internet connections). Let the player go where he wants to and have client side collision detection, and send position updates to the server. As long as the client hasn''t been hacked or the client side data corrupted there will be no problems with this system. The key to this system is to have a server side compare your last reported position with the new one and see if the move was a legal one or not. If it was legal, then the server updates the position and simply doesn''t respond. If it was illegal then it refuses to update the position, and sends a message back to the client to rubberband you back to where you should be. (And logs a message or notifies a GM to watch that player)
What do you all think of this method? Pros, cons, any situation I may not have thought through carefully?
I dont think Everquest would let the client handle something as important as position information. Sure it lets you display it and extrapalte, and interperlate when there is a difference between where your suppose to be and current are. The network coder for EQ worked for Id on Quakes network code, so it''s proablly using the same algorithims Quake and other FPS games use.
The requirements for MMORPGS is to reduce the bandwidth and minimize the apperance of latency. So any UI which can be done on the client side should be, only a few important network events need ever be sent to the server. Movement is partly UI, so it can be interperlated on the client side without server intervention, but every 5 secs the player does get a position packet which they then interperlate too. For a slow paced game like EQ you dont need to see the most current game state, 1 sec behind is good enough, and it allows you to interperlate smoothly between states.
Using the latency hiding technique most FPS games use, the client can spawn off inconsequential-events, such as spells and attacks, so they apprear instantanous to the client, but the server actually does the calcuations and determines its effects etc..
It''s possible using such techniques to get the bandwidth extermly low, perhaps 100 bytes/sec per player and have an enjoyable lag free experience.
Good Luck
-ddn
The requirements for MMORPGS is to reduce the bandwidth and minimize the apperance of latency. So any UI which can be done on the client side should be, only a few important network events need ever be sent to the server. Movement is partly UI, so it can be interperlated on the client side without server intervention, but every 5 secs the player does get a position packet which they then interperlate too. For a slow paced game like EQ you dont need to see the most current game state, 1 sec behind is good enough, and it allows you to interperlate smoothly between states.
Using the latency hiding technique most FPS games use, the client can spawn off inconsequential-events, such as spells and attacks, so they apprear instantanous to the client, but the server actually does the calcuations and determines its effects etc..
It''s possible using such techniques to get the bandwidth extermly low, perhaps 100 bytes/sec per player and have an enjoyable lag free experience.
Good Luck
-ddn
Author
After looking back at my message I realize that I didn''t explain my position well enough. I''ll try to do that in this followup.
Here are the characteristics of movement in EQ:
* Lag never freezes you in place. Even when you have lost connection you can move freely around the world. (You know how long it takes EQ to finally accept that it lost connection even after the fact)
* You never get rubberbanded back to a previous location. I have seen rubberbanding in UO and AO, but NEVER in EQ.
* You can never walk through a wall in EQ, no matter what, even during lag and complete disconnect.
The only solution that can fit all the above conditions is a movement system and collision detection not reliant on the server.
I''m not suggesting that the server is completely left out of the loop. Each time you move the client would send a message to the server informing of the current position. If the new position is at a location that you couldn''t possibly have gotten to at your current movement rate in the amount of time since the last received position, then you get rubberbanded back. (And ultimately kicked out of the game.)
Say for instance that you develop a hack to change your position across the zone instantly. The server knows that there is no way you could have done that legally, so you are bounced back. Any hack that moves you at a rate that won''t fail the servers validation ultimately gives you no benefit.
I guess the best way to sum the system I''m thinking of as having movement controlled and limited by both the client and the server.
I can think of no other system that explains the three characteristics I listed above.
Here are the characteristics of movement in EQ:
* Lag never freezes you in place. Even when you have lost connection you can move freely around the world. (You know how long it takes EQ to finally accept that it lost connection even after the fact)
* You never get rubberbanded back to a previous location. I have seen rubberbanding in UO and AO, but NEVER in EQ.
* You can never walk through a wall in EQ, no matter what, even during lag and complete disconnect.
The only solution that can fit all the above conditions is a movement system and collision detection not reliant on the server.
I''m not suggesting that the server is completely left out of the loop. Each time you move the client would send a message to the server informing of the current position. If the new position is at a location that you couldn''t possibly have gotten to at your current movement rate in the amount of time since the last received position, then you get rubberbanded back. (And ultimately kicked out of the game.)
Say for instance that you develop a hack to change your position across the zone instantly. The server knows that there is no way you could have done that legally, so you are bounced back. Any hack that moves you at a rate that won''t fail the servers validation ultimately gives you no benefit.
I guess the best way to sum the system I''m thinking of as having movement controlled and limited by both the client and the server.
I can think of no other system that explains the three characteristics I listed above.
The reason EQ does not have any rubberbanding, is because there are no dynamic objects that are transferred from the server to the client that would block you. Correct me if I''m wrong, but players, items, and monsters (most of the dynamic stuff that needs to be sent to the player) do not block the player. The only thing that blocks the player is the landscape, houses, and other static map data. Therefore, the client will do a pre-check to see if you can move before it sends the actual request to the server. This rules out any rubberbanding.
The problem with uo is there are a lot of dynamic objects that are sent to the client (housing, people, monsters, items, etc.). The client has (i believe) a 3 step buffer before it has to wait for the server to respond. This can cause rubberbanding if the tile you stepped on had something on it but your client didn''t know about it until after you already moved.
Which system is better? Well, what do you want? Dynamic or Static?
The problem with uo is there are a lot of dynamic objects that are sent to the client (housing, people, monsters, items, etc.). The client has (i believe) a 3 step buffer before it has to wait for the server to respond. This can cause rubberbanding if the tile you stepped on had something on it but your client didn''t know about it until after you already moved.
Which system is better? Well, what do you want? Dynamic or Static?
EverQuest has dynamic object collision detection.
It is calculated on the client.
It has been hacked.
It was detected.
It's the only solution that makes any sense for this sort of game. The client *must* alrady have geometry data in ram in order to display it. You perform pre-render culling by doing CD on the viewing frustum and the scene graph, so even already have the capibility to do CD on the client.
Just *try* to play AO. Even on cable or dsl it still sucks.
And I would never send additive vectors across the pipe for motion, that would never work - unless the server is authoritative as LostLogic suggest. That method would never work with the client doing the CD. The client needs to send absolute positions to the server, the server needs to remember the last position and the time so that it can calculate the velocity of the player. This is also what EverQuest does. Players have a speed limit, and if a player trips a speed limit, an admin is paged.
I'm not certain whether or not the EQ server's do thier own CD on all the players all the time. I suspect they allocate a short time block to it (say 10ms) each tick and round-robin the player checks. This way everyone is checked frequently, but it doesn't cause excessive lag, similar to the way saving occurs.
There is no way in hell the server can perform all the CD have any sort of decent gameplay. The latency alone would be disruptive, nevermind lag or dropped packets.
The downside to client-authoritative movement, is that dynamic object collision could be out-of-sync. And indeed it is. If you have ever played EQ on two computers in the same house, the movement of the characters is different on each machine. It's more important that what the player sees is realistic, rather than preserve the laws of relatively in the virtual world.
Quake must a different technique, perhaps like the one LostLogic suggest; lag and dropped packets seriously affect player movement in Quake3. This is also probably why the data rate needs to be so much higher in order to produce smooth movement. I'm fairly certain Quake does not use time-distortion to correct for lag/latency either, or uses a very short amount. In EQ the time distortion seems quite long.
Magmai Kai Holmlor
- Not For Rent
Edited by - Magmai Kai Holmlor on July 26, 2001 10:15:37 PM
It is calculated on the client.
It has been hacked.
It was detected.
It's the only solution that makes any sense for this sort of game. The client *must* alrady have geometry data in ram in order to display it. You perform pre-render culling by doing CD on the viewing frustum and the scene graph, so even already have the capibility to do CD on the client.
Just *try* to play AO. Even on cable or dsl it still sucks.
And I would never send additive vectors across the pipe for motion, that would never work - unless the server is authoritative as LostLogic suggest. That method would never work with the client doing the CD. The client needs to send absolute positions to the server, the server needs to remember the last position and the time so that it can calculate the velocity of the player. This is also what EverQuest does. Players have a speed limit, and if a player trips a speed limit, an admin is paged.
I'm not certain whether or not the EQ server's do thier own CD on all the players all the time. I suspect they allocate a short time block to it (say 10ms) each tick and round-robin the player checks. This way everyone is checked frequently, but it doesn't cause excessive lag, similar to the way saving occurs.
There is no way in hell the server can perform all the CD have any sort of decent gameplay. The latency alone would be disruptive, nevermind lag or dropped packets.
The downside to client-authoritative movement, is that dynamic object collision could be out-of-sync. And indeed it is. If you have ever played EQ on two computers in the same house, the movement of the characters is different on each machine. It's more important that what the player sees is realistic, rather than preserve the laws of relatively in the virtual world.
Quake must a different technique, perhaps like the one LostLogic suggest; lag and dropped packets seriously affect player movement in Quake3. This is also probably why the data rate needs to be so much higher in order to produce smooth movement. I'm fairly certain Quake does not use time-distortion to correct for lag/latency either, or uses a very short amount. In EQ the time distortion seems quite long.
Magmai Kai Holmlor
- Not For Rent
Edited by - Magmai Kai Holmlor on July 26, 2001 10:15:37 PM
From my experience, Players, monsters and objects do cause collision in Everquest. I''ve died several times in SolB because some ogre or troll was blocking the entrance when someone trained a bunch of baddies. No fun... Yes, some validation must take place on both client and server to present smooth gameplay and still not allow the client to be an authority.
And yes, AO blows currently (TCP for a MMORPG? hehehe). Such a shame, the game concept has such potential. *sigh*
Tim/Fingh
And yes, AO blows currently (TCP for a MMORPG? hehehe). Such a shame, the game concept has such potential. *sigh*
Tim/Fingh
An interesting point about AO is that you can walk wherever you want while the system is lagging. This allows players to complete the missions relatively easily during lag times (all they have to do is run through the place while lagged and find the objective.)
In Asheron''s Call, it warps you back to where the server "thinks" you should be.
In UO, I have never witnessed non-server-side authentication of movement. I tried changing the client-side data before to let me walk across mountain chains, but the server would not "hear" of it. The server would always reject the attempt even though the client machine thought the mountain was a grassy plain.
Another interesting note is the packet rate of AO and UO. I put up a sniffer and noticed that AO sends many more packets per second than UO. I have yet to decode them, but it is an interesting find. (Of course, AO''s use of TCP/IP is interesting in itself.)
I think the method you choose really depends on the game itself. If you dont mind players running "ahead" like they do in AO, then you do not need to check every position. But, if your game would be compromised from players running around while lagged, you may need ruber-banding or complete server-side checks. I believe it all boils down to how much security do you need from a player position standpoint. Then you can better determine the extent of position checking required.
LostLogic
www.lostlogic.com
Author, Multiplayer Game Programming
In Asheron''s Call, it warps you back to where the server "thinks" you should be.
In UO, I have never witnessed non-server-side authentication of movement. I tried changing the client-side data before to let me walk across mountain chains, but the server would not "hear" of it. The server would always reject the attempt even though the client machine thought the mountain was a grassy plain.
Another interesting note is the packet rate of AO and UO. I put up a sniffer and noticed that AO sends many more packets per second than UO. I have yet to decode them, but it is an interesting find. (Of course, AO''s use of TCP/IP is interesting in itself.)
I think the method you choose really depends on the game itself. If you dont mind players running "ahead" like they do in AO, then you do not need to check every position. But, if your game would be compromised from players running around while lagged, you may need ruber-banding or complete server-side checks. I believe it all boils down to how much security do you need from a player position standpoint. Then you can better determine the extent of position checking required.
LostLogic
www.lostlogic.com
Author, Multiplayer Game Programming
quote: Original post by LostLogic I have yet to decode them, but it is an interesting find. (Of course, AO''s use of TCP/IP is interesting in itself.)
I started some work on this, but didn''t get too far. I dropped AO like a rock rather quickly. Then spent over 3 weeks trying to get them to cancel my account prior to charging my credit card. I may come back in 6 months if it is still around.
I am still under the impression that Funcom has "green" developers turned "pro" working on the game code. The fact they chose TCP for a commercial MMORPG is almost laughable. They send so much garbage over the wire that it was a pain to log a single simple message and its appropriate response with ACK. I um, of course had only good intentions in sniffing their packets (if they are on my system, doesn''t that make them mine?
...You can sniff your friends, and you can sniff your packets. But don''t sniff your friends packets.
Hmmm. Nevermind, it''s late!
I''m sure this is an easy question for somebody but..
Why is it wrong to use tcp for a mmorpg and what protocol should AO have used instead?
Just curious.
-Sav
Why is it wrong to use tcp for a mmorpg and what protocol should AO have used instead?
Just curious.
-Sav
TCP creates a stream where ever packet is guarented to arrive and arrive in the order they were sent. This means the client has to acknowledge the packet sent by the server and visa versa else it will have to be re-sent. This causes problems as no further packets can be sent until delivery is made and if it fails the packet will have to be resent again.
Most online games (as far as I know) use UDP which uses datagrams and the packets are not guarented to arrive and can arrive out of order. This leaves you the ability to decide what packets you *have* to receive and also speeds up the process as no checking to see if the packet has been received is carried out so the server continues to send further packets.
TCP if often used though for systems where you need the packets to get though and in the right order (eg. Login authentication).
At least this is my interpretation of things.
Edited by - meh on August 5, 2001 7:26:17 AM
Most online games (as far as I know) use UDP which uses datagrams and the packets are not guarented to arrive and can arrive out of order. This leaves you the ability to decide what packets you *have* to receive and also speeds up the process as no checking to see if the packet has been received is carried out so the server continues to send further packets.
TCP if often used though for systems where you need the packets to get though and in the right order (eg. Login authentication).
At least this is my interpretation of things.
Edited by - meh on August 5, 2001 7:26:17 AM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
