Client VS. Server Side Collision Reporting
StriderNS2
Join Date: 2012-12-22 Member: 175867Members
Join Date: 2012-12-22 Member: 175867Members
<div class="IPBDescription">The reason why you are being killed around corners</div>Server-side hit detection is where one, authoritative server decides whether or not a hit has registered. The server knows the exact location of each player and is responsible for processing the bulk of the gaming logic. Since the client is behind the server in time, a server-side system requires the player to predict enemy movements and therefore lead targets when firing.
A client-side model allows the player's client to determine whether or not hits have registered. This allows the player to shoot at what he sees, instead of leading a target. Client-side hit registration, however, is more susceptible to hacks and cheats as the server is depending on the honesty of the client. Most games use a modification of the two, allowing the client to report hits, while the server polices the data reported from the clients.
Client side hit detection is also effected by lag compensation methods, such as interpolation and extrapolation.
Interpolation is where the client operating in a buffered state (slightly in the past). The client receives updates in intervals from the server and fills in the gaps, so to speak, in between the intervals. This prevents jerky movements from point A to B, providing a smoother graphical experience. The problem with this method is that where a player sees an object on his screen is not necessarily where it is on the server, making objects more difficult to hit.
Extrapolation is where the client predicts the location of an object. This works well with ballistics, but with player movements it can be far from accurate, as players do not move in a deterministic fashion.
The main problem with hit detection is that what the player sees happening and what the server sees happening will always be out of sync by the time it takes for the data to transmit from the client to the server. This video does an excellent job demonstrating this discrepancy.
<a href="http://www.youtube.com/watch?feature=player_embedded&v=0HRtdHmXEjs" target="_blank">"Lag" - Client vs. Host (Server) Comparison</a> (Yes I know it's a COD example but it's still valid).
So, should the game determine hits based on what the server sees or what the player sees? Some ways to rectify this are as follows:
<!--sizeo:3--><span style="font-size:12pt;line-height:100%"><!--/sizeo--><b>No! Let me figure it out.</b><!--sizec--></span><!--/sizec-->
Allow the players to do the predictions themselves by leading their targets. Problem with this is the lower ping players will generally see lagging players first and have a time advantage when responding.
<!--sizeo:3--><span style="font-size:12pt;line-height:100%"><!--/sizeo--><b>Yes! I want to shoot at what I see!</b><!--sizec--></span><!--/sizec-->
Rewinding time by using time stamps from client data, the server compares the data and decides whether a hit should be registered. This allows the players to shoot at what they see, instead of having to lead their targets to compensate for lag. The effects of this can be seen when a player runs behind cover and then dies because the server is adjusting for the lag of the shooter. It can also be seen when a shooter registers a kill after a player has run behind cover.
<!--sizeo:3--><span style="font-size:12pt;line-height:100%"><!--/sizeo--><b>Yes! My connection sucks but I still want to play!</b><!--sizec--></span><!--/sizec-->
Extrapolation allows the client to compensate for its lag and extrapolate the location of objects. The problem with this method is that, as noted before, players do not move in a ballistic or linear fashion. Often, players make erratic movements. The effects of this method can be seen when a player gets shot and killed before exiting a doorway or before breaking cover.
It appears to me that BF3 does a combination of rewinding time and extrapolating depending on the player's latency (???). The effects of both can be seen in the video below. It is also important to note that in the BF3 beta hit damage is increased on moving players.
<a href="http://www.youtube.com/watch?feature=player_embedded&v=YGaP5wTYLtQ" target="_blank">Battlefield 3 Client-side Hit Registration Issues</a>
<b>TL;DR It is my opinion that Client Side Collision Reporting is terrible for a competitive environment. Especially in a game such as NS2. Where people with higher pings are able to kill players with better connections. It is an attempt by UWE to even the playing field but what is actually happening is an extreme imbalance. Server-side Collision Reporting is the lesser of the two evils, in which players with higher latency feel the consequences of playing on a server outside of their range against people with better latency. It is more balanced to let the server handle the logic and positioning of clients rather then having the client do the reporting, resulting in what you would expect. Those with lower latency receiving the benefit. Rather then having the server battle over whom's predictions are correct.</b>
A client-side model allows the player's client to determine whether or not hits have registered. This allows the player to shoot at what he sees, instead of leading a target. Client-side hit registration, however, is more susceptible to hacks and cheats as the server is depending on the honesty of the client. Most games use a modification of the two, allowing the client to report hits, while the server polices the data reported from the clients.
Client side hit detection is also effected by lag compensation methods, such as interpolation and extrapolation.
Interpolation is where the client operating in a buffered state (slightly in the past). The client receives updates in intervals from the server and fills in the gaps, so to speak, in between the intervals. This prevents jerky movements from point A to B, providing a smoother graphical experience. The problem with this method is that where a player sees an object on his screen is not necessarily where it is on the server, making objects more difficult to hit.
Extrapolation is where the client predicts the location of an object. This works well with ballistics, but with player movements it can be far from accurate, as players do not move in a deterministic fashion.
The main problem with hit detection is that what the player sees happening and what the server sees happening will always be out of sync by the time it takes for the data to transmit from the client to the server. This video does an excellent job demonstrating this discrepancy.
<a href="http://www.youtube.com/watch?feature=player_embedded&v=0HRtdHmXEjs" target="_blank">"Lag" - Client vs. Host (Server) Comparison</a> (Yes I know it's a COD example but it's still valid).
So, should the game determine hits based on what the server sees or what the player sees? Some ways to rectify this are as follows:
<!--sizeo:3--><span style="font-size:12pt;line-height:100%"><!--/sizeo--><b>No! Let me figure it out.</b><!--sizec--></span><!--/sizec-->
Allow the players to do the predictions themselves by leading their targets. Problem with this is the lower ping players will generally see lagging players first and have a time advantage when responding.
<!--sizeo:3--><span style="font-size:12pt;line-height:100%"><!--/sizeo--><b>Yes! I want to shoot at what I see!</b><!--sizec--></span><!--/sizec-->
Rewinding time by using time stamps from client data, the server compares the data and decides whether a hit should be registered. This allows the players to shoot at what they see, instead of having to lead their targets to compensate for lag. The effects of this can be seen when a player runs behind cover and then dies because the server is adjusting for the lag of the shooter. It can also be seen when a shooter registers a kill after a player has run behind cover.
<!--sizeo:3--><span style="font-size:12pt;line-height:100%"><!--/sizeo--><b>Yes! My connection sucks but I still want to play!</b><!--sizec--></span><!--/sizec-->
Extrapolation allows the client to compensate for its lag and extrapolate the location of objects. The problem with this method is that, as noted before, players do not move in a ballistic or linear fashion. Often, players make erratic movements. The effects of this method can be seen when a player gets shot and killed before exiting a doorway or before breaking cover.
It appears to me that BF3 does a combination of rewinding time and extrapolating depending on the player's latency (???). The effects of both can be seen in the video below. It is also important to note that in the BF3 beta hit damage is increased on moving players.
<a href="http://www.youtube.com/watch?feature=player_embedded&v=YGaP5wTYLtQ" target="_blank">Battlefield 3 Client-side Hit Registration Issues</a>
<b>TL;DR It is my opinion that Client Side Collision Reporting is terrible for a competitive environment. Especially in a game such as NS2. Where people with higher pings are able to kill players with better connections. It is an attempt by UWE to even the playing field but what is actually happening is an extreme imbalance. Server-side Collision Reporting is the lesser of the two evils, in which players with higher latency feel the consequences of playing on a server outside of their range against people with better latency. It is more balanced to let the server handle the logic and positioning of clients rather then having the client do the reporting, resulting in what you would expect. Those with lower latency receiving the benefit. Rather then having the server battle over whom's predictions are correct.</b>
Comments
Most gamers have never played with the netcode where everything was done Server side. IT WAS BAD and I gaurantee you would have far more complaining about it than client side lag compensation netcode.
I remember playing Team Fortress Classic that started out with server side hit detection, then Valve later released a patch with new netcode for client side, pretty much everyone loved it.
Yes, you may get killed when it seemed like you just rounded a corner or on your screen it may seem like you were far enough away from that melee swing, however, the benefits FAR outweigh the downsides.
Thats the only response this thread deserves tbh, half the points are wrong or are incorrectly phrased.
Play some old HLDM on a good server at 100u/s and 0.01 interp, if you still think lag compensation is a bad idea then you should just quit gaming tbh, if thats even what you are trying to say in your post as your choice of words regarding the topics leaves alot to question.
The other (old and crappy) method would mean that if you shoot at a target and the server disagrees (because of lag or incorrect prediction) then you miss. So what you get is 100X as many "hit reg sucks" threads because you have to lead your targets based on your own lag and do the predicting yourself.
If the interpolated prediction is wrong on the client side, the server says no. In the end the server is the boss
Yes, yes, and yes. There was absolutely nothing wrong with server side hit detection. If anything it's better and that point has been made in the post. Most gamers have played with that netcode. And I don't count the CoD generation as gamers.
@xDragon
It actually is phrased correctly and obviously you have no idea what you're talking about. If you're referring to the CS:S rates of 30000, cl_updaterate 101 and cl_cmdrate 101, cl_interp 0.01. You would never want to set cl_lagcompensation 1. Therefore what you are saying is incorrect.
@SixtyWattMan
Has nothing to do with the amount of players or if Battlefield 3 was in beta at that current time. The netcode was poor and ultimately fixed. The video is relevant to NS2's current netcode situation.
@Agiel
It doesn't. It uses Client Side Collision Reporting. The server ultimately decides the end result. But the client may or may not send the server false or late information. Resulting in someone with 200 ping remaining unscathed and someone with a good connection to die. Just because the person was being hit on the laggy client side doesn't mean that his hits registered first, or that the client with decent latency was actually at that current spot at that time. The server just accepts the faulty information and runs with it.
@Desther
Not necessarily at all. If both clients have a stable, low latency then there is no issue regarding the hit-reg. Why? Because rates are capped by the server, and two players functioning at low latency, on the same rates equals more accurate registration on both ends.
@Kouji_San
The server is not the boss with Client Side Collision Reporting. At best it's the mediator. <i><b>"A client-side model allows the player's client to determine whether or not hits have registered. This allows the player to shoot at what he sees, instead of leading a target. Client-side hit registration, however, is more susceptible to hacks and cheats as the server is depending on the honesty of the client."</b></i>
However, that doesn't mean that BF3s approach isn't horrendous. The single greatest problem with the amount of client side information that they use is keeping synchronisation. That game can become extremely messed up, and I mean EXTREMELY.
<a href="http://www.youtube.com/watch?v=t9o5wiMoH_Q" target="_blank">http://www.youtube.com/watch?v=t9o5wiMoH_Q</a>
However, that doesn't mean that BF3s approach isn't horrendous. The single greatest problem with the amount of client side information that they use is keeping synchronisation. That game can become extremely messed up, and I mean EXTREMELY.
<a href="http://www.youtube.com/watch?v=t9o5wiMoH_Q" target="_blank">http://www.youtube.com/watch?v=t9o5wiMoH_Q</a><!--QuoteEnd--></div><!--QuoteEEnd-->
That used to be an issue in NS2 Build189 as well <a href="http://www.youtube.com/watch?v=mfcBx6J-k2I" target="_blank">http://www.youtube.com/watch?v=mfcBx6J-k2I</a>
It doesn't. It uses server-side hit detection with backwards reconciliation (just like GldSrc/Source) which seems to be what you describe as preferable in the OP. I'm still interested to know what could have made you confused about this.
BF3 actually takes it a step beyond that, and doesn't only affect fire rate.
If you watch the video I posted, at 3:58, in the small screen view, you can see one player defib the other to death. Then if you skip to 4:52 and watch the main screen view, you will see that kill play out in the background. The player who set his FPS to 1 desyncs from the server by a full minute, even after returning to a normal frame rate. Its such a mind ######.
Your comments on cl_lagcomp make no sense, i never said anything about that command, all I said was a well configured client/server architecture is almost unnoticeable in terms of hit detection flaws, offers vastly superior security, and evens the playing field for ping differences. It in no way benefts players with high ping any more than a Client side game does, arguably it actually benefits them less (not even going to attempt to explain this).
If your complaining about getting killed by someone with 200 ping, well thats most likely because they either had a bad connection (doesnt matter what architecture you use there, people are gonna be warpy on bad internet), or you just got outskilled.
Honestly I have no idea if your for or against the Client/Server architecture... nor do I think you understand at all what your attempting to describe. NS2 uses Client/Server just like goldsrc... There are almost 0 differences between the high level design of both anymore.
It has not changed. The firerate in NS2 is limited by your FPS.
BF3 goes much further though, hit detection is entirely client side. Search youtube for BF3 knife hack/cheat/aimbot for some of the reasons why that's a bad idea.
Has nothing to do with the amount of players or if Battlefield 3 was in beta at that current time. The netcode was poor and ultimately fixed. The video is relevant to NS2's current netcode situation.<!--QuoteEnd--></div><!--QuoteEEnd-->
It's official. You have no clue what you are talking about.
No it doesn't even remotely reflect the netcode behavior of GLDSRC or Source. The developers even said this. The engine won't allow the servers to behave as servers do in games such as CS 1.6, or CS:S. The server's will not be able to handle the load of the engine and the network updates. It's a flaw in the engine. The servers couldn't possibly handle it at the current state.
1. Client-sided movement / Collision
Pro: Less lag, because less information between client and server needs to be exchanged, much more fluent movement and faster movement possible.
Con: It makes rate hacking easy. Also favors someone with high latency over someone with less latency.
2. Server-sided movement / Collision
Pro: Rate Hacking is not possible (unless you hack into the server which is basically impossible except for elite hackers, but those will rather hack something important than risking getting into jail for a game).
Con: There will be a lot of lag for those who live far away from the server, because for every single action you do, the server first needs to respond and send your new coordinates back to you. This causes latency, meaning that if you press a key, the actual action might takes place up to 1 second later depending on how far you live away from the server.
That being said. The only people who I can imagine would be interested in having Client Side Collision Reporting are the Euros who plague our NA servers, or those with terrible internet connections that figure they deserve some sort of upper hand for playing on a server they have no business playing on in the first place.
@xDragon
What engine do you think HLDM runs on? lol GLDSRC engine. And as far as the lag compensation comment it makes perfect sense. What lag is there to compensate for when everybody is forced to the same rates and has a decent connection? Decent being a ping under 90. There is none or if there is it's irrelevant at such a minor level.
@SixtyWattMan
You're wrong. Netcoding can be faulty regardless of how many players there are on a server. How many players is more of a hardware/engine problem if anything. NS2 doesn't utilize anything over 24 man servers as far as I have seen. And as far as the lag increasing with how many players, that is not a rate problem, that is a coding problem regarding the engine and server load.
1. Client-sided movement / Collision
Pro: Less lag, because less information between client and server needs to be exchanged, much more fluent movement and faster movement possible.
Con: It makes rate hacking easy. Also favors someone with high latency over someone with less latency.
2. Server-sided movement / Collision
Pro: Rate Hacking is not possible (unless you hack into the server which is basically impossible except for elite hackers, but those will rather hack something important than risking getting into jail for a game).
Con: There will be a lot of lag for those who live far away from the server, because for every single action you do, the server first needs to respond and send your new coordinates back to you. This causes latency, meaning that if you press a key, the actual action might takes place up to 1 second later depending on how far you live away from the server.<!--QuoteEnd--></div><!--QuoteEEnd-->
?
I was under the impression spark predicted everything client AND server side. So you should have smooth client side movement for the most part. Only case you get jittery movement/collision is when you have prediction errors from the client (not matching up with server)?
I was under the impression spark predicted everything client AND server side. So you should have smooth client side movement for the most part. Only case you get jittery movement/collision is when you have prediction errors from the client (not matching up with server)?<!--QuoteEnd--></div><!--QuoteEEnd-->
The spark engine would be the first engine in the history of gaming to do so. It's not possible. There is no engine that can properly predict everything client and server-side all at the same time. That's complete rubbish. The engine would have to be omnipotent. Servers with top of the line hardware can barely handle basic spark engine function let alone what you're suggesting. And I highly doubt an indie developer would be the one to come up with such a model. Have you played the game? It's about as smooth as throwing a handful of pebbles into your computer case and then putting it on spin cycle.
Er, i didnt say it properly predicted everything. Prediction error = client side 'prediction' mismatches server side prediction. Server side prediction overules, you or other objects get snapped back to the correct position. You seem to have misread what people are saying.
<!--QuoteBegin-Agiel+--><div class='quotetop'>QUOTE (Agiel)</div><div class='quotemain'><!--QuoteEBegin-->It uses server-side hit detection with backwards reconciliation (just like GldSrc/Source) which seems to be what you describe as preferable in the OP.<!--QuoteEnd--></div><!--QuoteEEnd-->
Not really. You're talking about extrapolation. That's exactly what that is. The only problem with that is that players do not move in a ballistic or linear fashion. Often, players make erratic movements. The effects of this method can be seen when a player gets shot and killed before exiting a doorway or before breaking cover.
It actually is phrased correctly and obviously you have no idea what you're talking about.<!--QuoteEnd--></div><!--QuoteEEnd-->
<img src="http://www.reactiongifs.com/wp-content/uploads/2011/05/MichealJacksonPopcorn.gif" border="0" class="linked-image" />
Try PC-compatible hardware.
That and being 22 whilst using a characters name invented by a man with an amazing understanding of the human condidtion, who fought in ww1 and translated Beowulf. So don't expect people to take you seriously :)
cs 1.6 is still one of the most played shooters, for 13 years now.
how come?
most fair game out there, right after quake :)
u get what you deserve - you got a perfect setup and skill, you win, fair, finish.
everything else is just not FAIR!
making bad people good, makes a bad community,
kills the game i guess and no one is remembering it 13 yrs later.
but over 100.000 of people will still play cs 1.6 :P
Basically, backwards reconciliation is when the game figures how much you are lagging, and goes back in time to see when your shot should have hit, and then tells the clients that it hit then. This also has the effect of being killed while behind a wall, because if you run behind a wall, and someone shoots you right before, by the time the server tells you that you were shot, you are behind that wall.
So do tell me where this is beneficial in a competitive environment? Seems like a bad attempt at putting people with bad latency on fair grounds with people whom have good latency. Only thing is the people with good latency suffer.
The idea that server-side netcode would be better is laughable.
The idea that server-side netcode would be better is laughable.<!--QuoteEnd--></div><!--QuoteEEnd-->
Being shot around walls has nothing to do with hitboxes. So you're saying that a scenario where the server accepts packets from someone with a better connection and updates accordingly is worse than someone with 100+ ping getting the favor? Do explain.
With CSHD, when you hit you hit. Your client sees that you landed a shot because your weapon was aimed correctly, and the shot deals damage. Precisely what the player expects. But sometimes (rarely) the victim is briefly around the corner, and so they feel a bit bad about it. A small price to pay for reliable netcode.
Without CSHD, when you hit you ask the server if you actually hit. Your client sees that you landed a shot, but there's a delay before damage is or isn't dealt. This can result in bullets causing plenty of blood but not actual damage (because even though the client insists it hits, and you actually did skillfully land the shot, the server says otherwise.) But nobody gets hit around a corner.
CSHD is flat-out the better user experience. The downsides are minimal (except with fatter player models) and the upsides massive.
Not having CSHD is terrible. The upsides are minimal (players can't be shot around corners, and it's more secure) and the downsides are devastating (quite frequently -- almost constantly -- you'll shoot perfectly but not actually deal damage.)
Go play some Quake 1 and Mechwarrior 3 if you really need to remind yourself how terrible pre-CSHD netcode was. In Mechwarrior 3 in particular it was laughably bad -- you actually shot lasers 250ms in front of where the enemy mech was in order to successfully land shots.
The entire point of CSHD is for your connection speed <b><i>not to matter</i></b>, and to provide no significant advantage.
<b><i>The entire point of PVP multiplayer games is skillful competition. </i></b> It's actually a massive mistake if a developer allows connection or computer speed to be a significant factor in who wins or loses.
Pretty much <b>every</b> modern engine does this, it's called client side prediction. As someone said, it doesn't necessarily mean the prediction is always correct, but that it's what <i>should</i> happen.
For example, in Team Fortress 2 when you fire a rocket as soldier, the rocket launcher's animation is the client predicting "Hey, he pressed mouse1... while I wait for the server to respond [it most likely will!], let me begin the firing animation to make it look more responsive to the client". If the server responds and says "No, you can't fire" then nothing happens. It's just a animation that goes off.
Without CSHD, when you hit you ask the server if you actually hit. Your client sees that you landed a shot, but there's a delay before damage is or isn't dealt. This can result in bullets causing plenty of blood but not actual damage (because even though the client insists it hits, and you actually did skillfully land the shot, the server says otherwise.) But nobody gets hit around a corner.
CSHD is flat-out the better user experience. The downsides are minimal (except with fatter player models) and the upsides massive.
Not having CSHD is terrible. The upsides are minimal (players can't be shot around corners, and it's more secure) and the downsides are devastating (quite frequently -- almost constantly -- you'll shoot perfectly but not actually deal damage.)
Go play some Quake 1 and Mechwarrior 3 if you really need to remind yourself how terrible pre-CSHD netcode was. In Mechwarrior 3 in particular it was laughably bad -- you actually shot lasers 250ms in front of where the enemy mech was in order to successfully land shots.
The entire point of CSHD is for your connection speed <b><i>not to matter</i></b>, and to provide no significant advantage.
<b><i>The entire point of PVP multiplayer games is skillful competition. </i></b> It's actually a massive mistake if a developer allows connection or computer speed to be a significant factor in who wins or loses.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well said.
Also to the OP, have you ever actually played a competitive match where one team had 200+ average ping while the other team had say 80 or less average ping?
I have and let me tell you that the higher ping team is always at a disadvantageous when considering skill of both teams are equal. Not everything is done client side.