Originally Posted by SKYeXile
err people dying around corners is experenced with serverside hit prediction...
|
On a low latency server that's highly unlikely. I assume you're imagining a case with high latency and the extrapolation client-side shows you in the safe while the event hasn't occurred yet on the server or propagated to the clients?
This is more of a pen and paper problem. You can imagine a player being a little outside a corner. He presses strafe and sends a packet to the server with his input. Depending on the game, but usually, the client-side will begin simulating the change immediately even as the packet propagates to the server which takes round trip time (RTT) aka Latency / 2. On the server even when it gets the packet it doesn't immediately act on it. It must wait until the next server update. At that point it processes the input packets and performs and update then builds packets for each player and sends them. However during the update it has a few choices. It can assume the action just happened at this update. Or it can assume the action occurred Latency / 2 time in the past relative to when the packet was received. This gives us a time dilation of -((ServerTimeNow - PacketReceivedServerTime) + ClientLatency / 2).
There's a whole level of statistics for this, but we'll keep it simple. We'll say the server updates 20 times per seconds and sends packets at that rate which is pretty good. That gives us an update frequency every 50 ms. We'll assume on average the arrival of a packet is between updates so the wait time for a packet before it's processed is 25 ms. We'll make another assumption. The user has a horrible latency of 150 ms. (Anything below 70 ms is generally considered okay). So when a person presses a key assuming they send the packet immediately asynchronous of any game loop on the client-side (big assumption) it would take 150 / 2 + 25 ms until the packet is processed. That is 100 ms delay.
Okay before I continue I want to point out that multiplayer games generally add momentum to characters so they feel sluggish. This is not a realism/gameplay thing so much as it's a way to soften lag usually. If it takes you a while to change direction then players won't see a sudden jump when extrapolating.
Okay anyway so extrapolating. On the client-side lets assume there is no inertia so the player instantly starts moving with a velocity of 1.5 m/s. Now by the time the server has gotten the packet to even consider allowing the movement the player has moved 1.5 m/s * 100 ms = 15 cm. However, no one else knows that yet!
So the server updates which we'll assume to take < 1 ms so it's negligible to our calculations. During this update it sees the player's input packet and goes "this player requested to strafe 100 ms ago. Okay we'll allow that and assume that action started 100 ms ago and move their position 15 cm and also set their velocity to 1.5 m/s in a direction." So this information is sent out to the clients. Each client has it's own latency so when it gets the packet and sees the position update. (Again this timing can get complicated since the client usually processes packet synchronously before updating and not asynchronous, but we'll ignore that since the update could be 60 ms making the delay negligible). Okay so the clients see the position data for the player and its new velocity. However that data is old. It's their latency / 2 old. If their latency is 30 ms then it's 15 ms old information. If their latency is 150 ms also then it's 75 ms old. So when it gets the data it must extrapolate using the velocity to an estimated server position. So lets go with 150 ms and assume everyone is far from the server. That means the player is no offset 1.5 m/s * 75 ms = 11 cm. So on total the player has "jumped" 11 cm + 15 cm 26 cm since the last update. That's essentially 0.3 meters or 1 foot.
The same effect happens to projectiles when the user is firing. So the projectiles might be created
That's pretty bad. So you might be thinking "okay if everyone has 150 ms" then you'd expect a lot of corner kills as players quickly jump back since there's a possible 75 + 25 + 75 = 175 ms delay between when an enemy actually shoots and you see the update and you could already be taking damage. You'll also notice that this system rewards players with a high latency since it's essentially rewinding the simulation on the server to create bullets in the past and firing them.
So is this system flawed? Not really. There's a number of tricks. One of the biggest is assumed latency. If you know all your players are generally playing with over 50 ms latency you can play the simulation on the server in the past.
Another thing is to perform the input updates at the server-time without going back in time using the client's latency. This is nice because there's less perceived lag; however this hurts players with latency issues since they'll perform an action like "fire weapon" then it would occur in our problem 175 ms later and other players would only see a delay of their own latency / 2. This can be annoying for players that lag since it feels like their lagging. Players that don't lag wouldn't even notice if other players lag and would gain a slight advantage since their actions would be performed faster. (If that doesn't make sense. Imagine a user with 30 ms latency. It takes 15 ms to get to the server so they have a higher chance of inserting their packet and getting it processed in the newest server update while a player with 150 ms latency might see their input processed on the next update).
Someone else can do some other calculations, but that's one general approach. There are a lot of trade-offs which give either players with a high latency an advantage or players with a low latency an advantage. Ideally you want a system that is "fair". Like I said the "assumed latency" system does that by assuming a given latency for all players even if they don't have latency issues. It's generally the best system and doesn't have to use any client-side hit detection information. However it does make it slightly harder to get headshots when a player is quickly changing directions constantly unless there is inertia to smooth out the extrapolation.
You see with client-side the idea is to make everyone happy and hope that no one with a high latency exploits their advantage. That's a big assumption. One I don't feel SOE should make. I just hope they have skilled network programmers.
Originally Posted by SKYeXile
is it a FACT BF3's hit detection is CS or are people simply presuming because they're dying around corners?
|
EA said in the forums in one of the more
heated debates that it is indeed client-side.
2011-10-06, 09:25 PM
Don't feed the trolls, unless it's funny to do so...
Linear Mode
