hit detection
BloodyIron
Join Date: 2009-11-09 Member: 69321Members, Reinforced - Shadow
I've been playing this game for over 1.5yrs now. I must say, I'm still irked by the hit detection.
I'm not sure if how it is now is intentional or not, but coming from competitive TF2 the hit detection in this game blows my mind.
There are times I will be running around a corner and about 500ms later I'll die, when it was clearly a safe retreat. This isn't laggy people shooting me either, and it happens quite frequently.
Another time happened just a few minutes ago. I run up behind an afk marine, get 2 chomps off and on the third they give me a quick burst (machinegun) which instantly brings me down to 1hp. While I made it away, there's no way a marine should be able to burst me down like this, ever; especially considering i was behind them the whole time.
I'm not sure what part of the hit detection mechanism it is, but I haven't seen it change much for the better since I got into the beta. There have been changes with shotguns and other elements, but it doesn't seem to be where it should be.
I'm not sure if how it is now is intentional or not, but coming from competitive TF2 the hit detection in this game blows my mind.
There are times I will be running around a corner and about 500ms later I'll die, when it was clearly a safe retreat. This isn't laggy people shooting me either, and it happens quite frequently.
Another time happened just a few minutes ago. I run up behind an afk marine, get 2 chomps off and on the third they give me a quick burst (machinegun) which instantly brings me down to 1hp. While I made it away, there's no way a marine should be able to burst me down like this, ever; especially considering i was behind them the whole time.
I'm not sure what part of the hit detection mechanism it is, but I haven't seen it change much for the better since I got into the beta. There have been changes with shotguns and other elements, but it doesn't seem to be where it should be.
Comments
if you're getting around 500ms delay though then it could be the server or you.
2) shotguns are random
3) damage draw doesn't always draw damage
4) hit registry probably isn't that good on top of all of these
everything you need to know
L4D and L4D2's server tick rate (not the same as the client update rate in Source engine games, although the update rate can't exceed the server tick rate) is fixed at 30 ticks per second.
It all sounds pretty similar to NS2's networking parameters. :)
Maybe you think you feel a difference because NS2 can be a bit faster paced in combat.
In short, client-side hit detection grants the benefit of "What you see is what you get." This generally results in the best play experience. On the other hand, this not only makes it easier to cheat, but also gives the impression of dying behind cover, because your client occasionally needs to "catch up" to the server.
Server-side hit detection alleviates those issues. However, it also necessitates player compensation for latency, which results in a variable need to lead your shots according to how much lag is occuring.
From what I know, most multiplayer shooters use client-side hit detection, and it's unanimously considered the superior option. Red Orchestra 2 used to use server-side hit detection, but it led to a lot of problems that client-side detection ultimately solved.
In short, client-side hit detection grants the benefit of "What you see is what you get." This generally results in the best play experience. On the other hand, this not only makes it easier to cheat, but also gives the impression of dying behind cover, because your client occasionally needs to "catch up" to the server.
Server-side hit detection alleviates those issues. However, it also necessitates player compensation for latency, which results in a variable need to lead your shots according to how much lag is occuring.
From what I know, most multiplayer shooters use client-side hit detection, and it's unanimously considered the superior option. Red Orchestra 2 used to use server-side hit detection, but it led to a lot of problems that client-side detection ultimately solved.<!--QuoteEnd--></div><!--QuoteEEnd-->
Basically all multiplayer games use server side hit detection. The only big one I can think of that doesn't is BF3, which results in hackers being able to kill people who aren't even alive, and other laughable scenarios.
I may be completely wrong though, it appears. I assumed nobody else used client side because few other games have cheating as rampant as BF3, but maybe they just truly screwed it up. Still pretty sure that server side is the norm though.
In short, client-side hit detection grants the benefit of "What you see is what you get." This generally results in the best play experience. On the other hand, this not only makes it easier to cheat, but also gives the impression of dying behind cover, because your client occasionally needs to "catch up" to the server.
Server-side hit detection alleviates those issues. However, it also necessitates player compensation for latency, which results in a variable need to lead your shots according to how much lag is occuring.
From what I know, most multiplayer shooters use client-side hit detection, and it's unanimously considered the superior option. Red Orchestra 2 used to use server-side hit detection, but it led to a lot of problems that client-side detection ultimately solved.<!--QuoteEnd--></div><!--QuoteEEnd-->
It's not really accurate to say "client-side hit detection" vs "server-side hit detection." Most modern games, including NS2 and TF2, rewind time on the server to where everything was when someone fired a weapon (using the ping and interpolation values of the <i>player who fired</i>), and determine whether it hits based on that. This eliminates the need to 'lead' targets when you have > ~50 ping, but gives an advantage to a player with high ping firing a weapon at someone who is running out of sight.
Latency is completely unavoidable in online games, and it <i>has</i> to show up somewhere.
L4D and L4D2's server tick rate (not the same as the client update rate in Source engine games, although the update rate can't exceed the server tick rate) is fixed at 30 ticks per second.
It all sounds pretty similar to NS2's networking parameters. :)
Maybe you think you feel a difference because NS2 can be a bit faster paced in combat.<!--QuoteEnd--></div><!--QuoteEEnd-->
in other games you're able to adjust all of those values for ideal settings
NS2 locks them all on top of having faster-paced combat and random weapons that creates a disaster
NS2 locks them all on top of having faster-paced combat and random weapons that creates a disaster<!--QuoteEnd--></div><!--QuoteEEnd-->
Which games are these?
Games which I won't accept:
Quake 3
Any version of the source engine older than the one used in L4D1
Games which I won't accept:
Quake 3
Any version of the source engine older than the one used in L4D1<!--QuoteEnd--></div><!--QuoteEEnd-->
you've always been able to set server ticrate in source
interp has been changeable since hl1, source games have modified it to interp_ratio iirc, but it's still just as changeable
I don't see why it matters what games they are though or what the age of the game is
"The -tickrate command line parameter is not available on CSS, DoD S, TF2, L4D and L4D2 because changing tickrate causes server timing issues. The tickrate is set to 66 in CSS, DoD S and TF2, and 30 in L4D and L4D2." - <a href="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking#Basic_networking" target="_blank">Valve developer Wiki</a>
interp has been changeable since hl1, source games have modified it to interp_ratio iirc, but it's still just as changeable
I don't see why it matters what games they are though or what the age of the game is<!--QuoteEnd--></div><!--QuoteEEnd-->
The problem is that these highly customisable games are typically more scaffolding than actual full blown games. Games like Quake 3 and counter strike, and in fact a lot of games which are strictly "death match". I could probably throw together a game in vanilla openGL in a day that would have more actual game mechanics than these titles do (an exaggeration, but not a big one). They have no overhead to speak of, and as such the customisation of their core settings really doesn't affect much at all, its just a case of tailoring your deathmatch experience to your liking.
Not so with games that have actual structure, and which involve processing past the obvious "DID I HIT HIM"? You think BF3 servers have customisable core settings? With the amount of overhead that goes on in that game outside of the simple player/player interactions, the settings are probably tailor made, down to the second decimal place, with any changes likely resulting in catastrophic failure.
66 is much more forgiving than NS2's 30 though, so my point remains. for example in Dystopia mod, low ticrates completely broke bunnyhopping. I wouldn't be surprised if some problems in NS2 are caused by this same thing
100ms interp is also very large
edit: Imbalanxd your post is kind of really vague and doesn't really give any specifics. it just seemed like some kind of bash on CS / Quake, and general assumptions on why it can't be done. it's also pretty insulting to Quake and CS considering they had a massive amount of competitive strategic depth in comparison to NS2 currently
Perhaps... unfortunately it isn't really personal opinion, its quantifiable fact. The Quake 3 engine is opensource now (I think?) so you could probably go check the game loop for yourself. It probably looks like this.
updatestufflol()
{
hitDetection();
spawnDaHealth();
spawnDaArmor();
rocketJump!("awwww yeah");
}
Oh, and I'm not saying playing the game is simple. I'm saying the game itself is simple. Competition determines gameplay complexity. Even pong would become a highly skillful game with enough people playing it.
Halflife was a beautiful engine when it came to this type of stuff. For the most part we've had backwards progress in gaming in the last several years.
way too hard to hit lerks/fades/leaping skulks
brightskins would help though
Oh right, gldSrc... where the definition of physics was a binary active vector.
Processing demands have increased a lot since then, and hey, so has processing <b>power</b>. One thing that hasn't increased, however, is the speed of light, which leaves online games in a bit of a jam.
updatestufflol()
{
hitDetection();
spawnDaHealth();
spawnDaArmor();
rocketJump!("awwww yeah");
}
Oh, and I'm not saying playing the game is simple. I'm saying the game itself is simple. Competition determines gameplay complexity. Even pong would become a highly skillful game with enough people playing it.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm quite sure the only similarity the game loop in the quake 3 engine has to your snippit is that it's also written in C++ syntax.
I'm not sure you even understand what you're arguing...
Quake is simple, but it's fundamentally running the same hitreg and prediction algorithms modern games use today. You just had far more access to the interacting variables.
That's why scientists increased the speed of light in 2208. For online games.
Yes, but that's <b>ALL </b>its running. The games primary mechanic <u>IS</u> hit detection. It has absolutely nothing else going on. It is literally nothing else than WASD bound to some camera transforms, and then a bunch of hit detection algorithms. That's all it has to do. Is it really any wonder that you can customize the ###### out of that process?
Once again, I'm saying the game is simple, not necessarily the gameplay.
leads to lots of questionable circumstances for hit registry.
obviously I'm not suggesting that it's a quick and simple fix considering the amount of server performance NS2 already demands.
edit: although I do recall Dragon testing lower interp values with pretty favorable results so who knows
Prime examples of whacky hitreg are found in pub servers, where you sometimes can sneak up to unsuspecting lerks/fades which are sitting there attacking something with a shotgun, just to deal very little damage at point blank range.
Also there is that flinching animation bug... especailly noticeable with harvester, not sure whether this is fixed in this version thouh.
Second, the source engine runs differently for different "mods" loaded for it (mods being css/dod/tf2/l4d/hl2dm). I've been running source servers since hl2dm came out, and I've been running tf2 servers since it came out. Tickrate on TF2 servers in particular has been a big deal for a while, and about a year or two ago they actually removed the ability to change the tickrate and forced the value to 66. I know this because VALVe stated this in mailing lists I subscribe to, and because knowing these things are vital to tuning a tf2 server properly.
In the source engine, specifically tf2, it's actually a combination of server and client side hit detection. It is also worth noting that it actually favors the client. This can be observed most easily by watching very laggy snipers still landing shots, because they hit on their client.
Back to NS2, the issue is hit detection with the machine gun. As my original example, the marine turned around and in less than half a second tore me down to exactly 1 hitpoint, when I was at full health and armor. Would anyone actually declare this fair, balanced and working as intended? I sure dont.
Despite the naysayers, TF2 is actually quite fast paced at the higher ends of competition, and I've played at those levels. I'm not going to say it's faster or slower paced than NS2, because that doesn't really accomplish anything.
The fact of the matter is that the game is not balanced considering this discrepancy in hit detection. It is irrelevant whether it was intentional, or not, or even if it was just left in by mistake. What is relevant is that it is present and should be corrected.