Skip to main content
GameDev.net gamedev.net
🔒 Locked

Which method to implement?

Started by granat Sep 25, 2006 at 6:52 PM 5 replies 1.2k views
Original Post
granat
granat
Assume latency of 50ms. 1. Player presses key and begins to move. Keys are sent to server. Server moves the player, 50ms too late. Server is 50ms behind. Server sends other players the position and velocity of moving player. This takes another 50 ms. Other players see moving player 100ms in the past. Moving player stops. Sends stop to server. Server gets message 50ms later and stops player. Player on server stops at the right place (in theory at least). Server sends stop message to other players. They receive the message 50ms later, which is 100ms after the moving player stopped. This also works out. Player stops at correct position on other players screen (in theory). 2. player moves. Keys are sent to server. Server know that latency is 50ms and moves the player for 50ms worth of movement(prediction) and sends position and velocity to other players. Other players know that latency is 50 ms and predicts how far player would have moved in that time frame. So Everywhere moving player is at the right position. This is great..BUT. Now player stops. Keys are sent to server. Server knows that latency is 50ms so he must move player back a little. Calculated position and velocity is sent to other players. Other players know that latency to server is 50ms, and they also know that for the message to go from moving player to server first is another 50ms. So 100ms in all. Moving player(now stopped) is moved back ALOT. So which method is more widely used today? I believe Delta Force Landwarrior used method 1. I talked to an experienced DFLW player and he had to aim taking the latency into account. So other players must have been in the "past" on his screen. I have tried to implement method two which is what I assumed new games use. Problem is, when I turn the spaceship and suddenly stop, then it must be counter rotated a little on the other clients because it takes a while for the stop message to reach them and this look really bad. The problem with method one is of course that you have to aim in front of moving targets (more than the time for bullet to arrive at target). But at least the movement looks good.
-------------Ban KalvinB !
kvp
kvp
There are two problems with method 2:
-when compensated for start lag, each player will start with a jump forward of 50 plus 50 ms
-when compensated for stop lag, each player will stop with a jump backward of 100 ms

In any case you will have 100 ms worth of compensation, calculated either on the server and the client or on the server alone. The total sum doesn't change and when you are using client side prediction this can't be avoided.

The typical use for client side prediction is to avoid the round trip time between the client who moves and the server. The server should have the primary copy of the game state, so each client must accept positions sent from the server. The idea is to make the game more responsive to keyboard commands, not to defeat lag.
granat
granat
So are you saying nobody uses method two?
-------------Ban KalvinB !
Ozymandias42
Ozymandias42
Method 2 is best, but it introduces a world of hurt. There are 1000 situations retroactively changing state brings about, the least of which is cheating.

Imagine your server's scripting. A player is standing next to a laser. He moved 50ms ago to the other side of the laser. Great, work out whether at any point he crossed the laser. Okay, he was destroyed by the laser. Now you get a message that 10ms ago, the laser turned off. Okay, um, back up and undestroy the player. Oh, wait, 20ms ago, the player turning off the laser was hit by a missile. Now recreate the laser. Now redestroy the player. It becomes very very painful very very quickly. Take the double lag.
Ozymandias42
Ozymandias42
Also, method 1 doesn't preclude letting you aim in the right spot. That's the beauty of client prediction. The client's not seeing "now," he's seeing X timesteps into the future, where X is a guess of how many timesteps will go by in the time it takes to get a message to the server.
granat
granat
Quote:
Original post by Ozymandias42
Imagine your server's scripting. A player is standing next to a laser. He moved 50ms ago to the other side of the laser. Great, work out whether at any point he crossed the laser. Okay, he was destroyed by the laser. Now you get a message

The server has the final say. If laser was off at the time (even if a turn-on-laser message is underway from a client) then laser was off. I don't want to un-kill players and stuff. Once players are dead, they are dead. PERIOD.

Quote:
Original post by Ozymandias42
Also, method 1 doesn't preclude letting you aim in the right spot. That's the beauty of client prediction. The client's not seeing "now," he's seeing X timesteps into the future, where X is a guess of how many timesteps will go by in the time it takes to get a message to the server.

What do you mean? The client will se other players as they were 100 ms ago. If client tries to predict where they MIGHT be then the issue of moving things back all the time to correct will happen.

-------------Ban KalvinB !
Ozymandias42
Ozymandias42
Quote:
Original post by granat
What do you mean? The client will se other players as they were 100 ms ago. If client tries to predict where they MIGHT be then the issue of moving things back all the time to correct will happen.


This is true. Snapping is the price of prediction. Nonetheless, it does allow you to aim where they are instead of where they are going to be in 100 ms.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.