Oh dear god, no. I cannot think of anything that would utterly ruin the game experience more than "lag compensation". I know this is going to sound terribly harsh, but if anyone's having problems with leading their targets, I'd strongly recommend they try playing on more local server.
Lag compensation is the number one most frustrating thing ever introduced into multiplayer gaming, Ever. With a capital E. It's exploitable, it never works properly, it punishes players on low pings and it lowers the overall skill level required to play shooters.
Lets take an example. Call of Duty 2. This has two forms of lag compensation. The first was sv_antilag which was the most abysmal failure of a lag compensation system I have ever seen. So much so that it was almost instantly disabled on servers worldwide after the game's release. I'm sure it's great for a console where aiming
at someone is hard enough let alone ahead of them, but on a PC we have the precision and the skill (or at least that's the idea) to deal with it. This particular antilag setting simply set the hit detection to client side. All the calculations were done on the client's machine and it saw a hit, the server would confirm it a second later without question. This system was used in the past by primarily coop games like Serious Sam where the pace of the game makes it paramount that you see a kill straight away. It's incredibly easy to hack and exploit however and for that reason, in a PvP environment it fails immediately. In addition, it punishes non-lagging players for having the gall to have a low ping (how dare they!). I'll come back to this at the end however.
The second form of antilag employed by CoD2 is deliberately laggy hitboxes. So laggy in fact, that aiming behind a moving player will score a hit 9 times out of 10 and if someone sticks their head up from cover for even a fraction of a second, they're a dead man because the hitboxes remaing in the open long after you've ducked your head down again. It's so bad that even recordings of games clearly show players scoring kills on players well after they've disappeared from view. This system is clearly a big, fat, fail.
Another prime example would be the Half-Life engine and its successor, the Source engine. I'm going to make a big assumption here (and I'm pretty sure I'm right) that mbrooksay spends most of his gaming time on Source based games, hence this thread. Now don't misunderstand me, I'm not having a dig at him here, but I have not yet seen one of these discussions started by someone from any other background. People who play Source based games almost exclusively get so used to the way the engine handles hit detection that they really struggle when they play anything else. It's the same with anyone who plays on one particular game engine most of the time. You get used to it. It wouldn't be so much of a problem if it weren't for the fact that the Source engine's detection is off most of the time, resulting in the same problems as CoD 2, but with a few extras thrown in for good measure.
I'm going to quote a post I made in the Insurgency forums a few weeks back explaining why the Source engine's method of antilag is so flawed.
Me said:
What's he's referring to is the netcode problems that I keep bringing up. I know people don't like to believe that it's true, but the Source engine netcode is flawed. The concept is fantastic, but it just doesn't work as well as it's intended. The blood you're seeing everywhere is because you're shooting the player model, not the hitboxes. I should probably explain how Source hit detection works before I continue.
There's a value in your config called cl_interp and the number you give it is intended to be a representation of your ping time. When you shoot at a player, your game sends that number along with the firing angle and direction to the server. The server then checks the information, detects the point of impact and checks to see if there was a player there. Rather than check at the moment that it receives the information however, it looks at your interp value and then "rewinds" time by the amount that your setting says. It then checks whether there was a player at the point of impact earlier in time and if so, awards the hit.
The reason for this is to try and compensate for lag. If you have the variable set correctly for your ping, you should be able to shoot at the player model directly and even if they've moved by the time the information reaches the server, it'll look back in time to the exact moment you fired the shot and will correctly see that when you fired, a player was there. So long as interp is correctly set, the system works great (in theory anyway). No matter what your ping is, if your aim is good you'll be awarded the hit without having to lead your shot at all (even though it's incredibly frustrating to be killed long after you've taken cover). But what happens if the setting is not correct for your ping?
This is sadly where the whole thing comes apart. If you've got it wrong, then you can shoot a player and not be awarded the hit, whilst shooting behind or ahead of them _does_ result in impact. Now being awarded a hit for a shot in front of someone's not so much of a problem. To lead a shot is harder and this is really no different to a game with no lag compensation at all. It just means the setting's too low for your high ping. The reverse on the other hand, is quite nasty.
If your setting is too high for your ping, you'll only be able to hit someone by shooting where they just were. Doesn't sound all that bad, and in reality it's not - for you. You can kill people after they gone around corners. You'll see them disappear out of sight and not even fire until after they've taken cover, but the game still awards you with a hit. This effectively gives you super reactions. A person who flits across a doorway would be unhittable normally. No-one's reactions are that fast. With a high interp value however, if you panic and start spraying at the doorway just a fraction too slow to hit him, the lag compensation will think that you actually
did hit him and award it as such. It's not fair and in any other game, it'd be cheating.
So why is this a problem? If everyone sets it correctly, there should be no problem right? Well there's two problems with that. Firstly, what's the right setting? People's pings vary, no value is correct all of the time. You can get close, sure, but what's to say it's going to stay correct through the whole game? That's less of a problem though, the second issue is the biggy. Most people don't know the setting exists. They never set it because they don't know they can. Instead, they get the default setting and the default setting is still assuming that we're all on dialup. The Source engine carries the same netcode over from the HL1 days and the default is still the same - 100ms. If you ping 100 then no problems, but if you ping 30-50, you're going to be able to hit a running person far more easily without having to necessarily aim as well. There is a third problem of course - people deliberately exploiting the setting, but #2 reduces this one to a minor issue.
So what does this have to do with blood everywhere? Well if your interp is too high, you won't be awarded hits for a fast moving target that you've aimed accurately at. You'll only get the hit if you aim behind them. The game though, has another trick up its sleeve as part of its lag compensation. Since it assumes that everyone will have the correct interp setting, by its logic, every time you hit a player model, you're guaranteed a hit, so to save time and to give you the illusion that there's no lag at all, your client machine draws the blood decals the instant you shoot the model, confident that the server will award the hits a few dozen milliseconds later. Except that it doesn't. Your incorrect settings are leading the server to incorrectly believe that you've missed and it ignores the hits. The result is that people frequently take multiple hits, including to the face, with huge blood sprays, but they don't die. As far as they and everyone else is concerned, you missed, because that's what the server's telling them.
It's annoying, but it's part of the Source engine. There's only two ways to fix this, but Valve won't do either.
The first is to disable lag compensation. Stop client side prediction and since the server has the final say anyway, learn to lead shots for lag and wait for the server's response before you see bullet impacts and their subsequent effects. This is what most games do and I honestly prefer it. Yes, it's worse for people on high pings, but in slowed down realism games, it's not so much of an issue. I'm able to play RO on 350ms ping with few ill effects and still outdo the majority of players on low pings. It also stops the incredibly frustrating occurence of being killed after you've left a player's sight. Many long time Source gamers don't like this though. They're used to the anti-lag settings, so that brings me to the second option.
Take the client's ability to set interp away from them. It prevents deliberate exploitation and unintentional exploitation through ignorance. The interp value should be a dynamically updated variable that's calculated off your average ping over short time period. By doing this, it will be for the most part accurate regardless of player or ping and a correct interp value means correct hit effects for clients. This would be by far the preferred method for many people and I honestly can't understand why Valve didn't implement this in the Source engine from Day 1. It's not 1999 anymore, people's computers and broadband internet connections can handle it.
Now as an aside, there's still something wrong with the hit detection. Whilst blood decals from my own weapons are client generated, blood from other players is not. Hits made by other people are sent to me by the server and if I see blood from a teammate's shots, then the server has registered a hit. Hence the problem. The server is noting hits in the head and chest and telling other clients to draw the blood, but it's not dealing out the correct damage for it. That's why you can see players running around with up to 4 or 5 obvious wounds (the shotgun is especially notorious - 3 direct hits at close range will take anyone down) and no ill effects. Base netcode aside, something in this game's hit detection isn't right. There's no better evidence for that that the one-hit-to-the-foot kills and the 3-shots-to-the-stationary-target's-ribcage kills that are sadly so prevalent.
Personally, I'd like to see more servers experimenting with the sv_unlag 0 cvar. Although I can hear the screaming already. The only people who'd be able to hit anything would be the pros who set their interp to 0.01 regardless of ping and already lead their shots where necessary.
Now even if someone were to come up with a system of lag compensation which dynamically calculated the value of a server's "rewind time" variable, one problem still remains, which I mentioned earlier. Players on low pings are punished for the heinous crime of not lagging. They get killed after they round corners, after they duck behind cover, even by their own victims (who magically deal out death from beyond the grave). Not only that, but where a low pinging player sees a high pinging player is NOT where they actually are. An example:
The following is as seen by the players, not by the server.
Player A has a 50ms ping.
Player B has a 350ms ping.
Player A checks a corner, sees no-one, then runs across the street. Player B rounds a corner further down the street just as player A is making his run. As player A gets further and further across the street, player B is moving further round the corner. He only just manages to keep player A in sight as he goes. As he finishes rounding the corner, he fires a shot at player A just before player A disappears from sight. Player A is killed.
Sounds fair, right? Player B, the lagger, has spotted a target, aimed, fired and scored a hit. He's been rewarded for his aim and the fact that he's lagging has been ignored. Can't say fairer than that right? Wrong.
Player A never saw player B at all during the whole encounter. Because player B is "lagging", where
he thinks he is, is NOT where the
server thinks he is. Because the information from player B is taking an additional 300ms in its round trip and because player B only just keeps player A in view, player A would have to stop moving for an additional 300ms before he would see player B emerge from the sidestreet. If he doesn't stop, player B's position will always be (from player A's perspective) just out of sight. Player B on the other hand has his virtual eyes floating way out in front of his body (thanks to client prediction, another system entirely and one without which MP gaming would be nigh-on impossible to play) and can see player A the whole time, well before his actual body catches up. By the time he fires his gun, player A isn't even there anymore. He's out of sight.
As it is, player B's high latency means he's already seeing the world long after events have happened. This means he's effectively seeing a shade of player A in the past. None of this bodes well for A, because not only is he being seen as he was in the past, he effectively needs to be able to see into the future to know where the lagging player actually is and therefore to see him at all.
This scenario isn't as rare or unlikely as it sounds and it's certainly not the only one of its type. Antilag settings, while wonderful things for players on high pings, is a nightmare for those who aren't.
I honestly don't see what's so hard about leading a shot by a few cms. Almost every MP game ever released requires at least a tiny bit of leading to compensate for most players' small latencies anywhere up to 100ms) and it's really not a difficult thing to do. It promotes skill and a player who's able to be a crack shot on a higher ping is vastly more skilled than one who does it on a lower ping. RO is a perfect example. Once upon a time there were only about 3 populated servers worldwide and none were in Australia. The entire Australian community (all ~10 of us) would play exclusively on 250ms and up and I can tell you, though we couldn't match the top clanners, we were still in the upper 30% of players.
My point there, obscure as it may be, is that in a slower paced game like RO where precision is key, an anti-lag setting just isn't necessary. If you're a good shot, you'll learn to lead a little more and you start to forget that you're lagging at all. If on the other hand you're playing a fast paced DM game like UT, almost all the weapons either spray anywhere
but your aimpoint, meaning you'll hit pretty much anything in that general direction, or they explode, something for which a direct hit is completely unnecessary. Again, anti-lag just isn't necessary. If your ping is so high that you just can't realistically lead far enough ahead to score a hit, then either find a closer server or deal with it.
Right now, the Unreal Engine is my only refuge for "antilag" free gaming and should that change, it'll be a fantastic engine down the drain. Similarly, if TWI's next game included an in-house antilag solution, I honestly wouldn't waste my money on it. I'd be absolutely gutted, but I still would not pay money to experience yet another re-run of the paradoxes, ESP, corner-turning bullets and blood-out-of-thin-air bull**** that is so prevalent in other "big name" online games these days. I can assure you that the as-yet unmatched torrent of abuse and swearwords that I unload within minutes of joining a deliberately unrealistic CoD/Source based online game would be rapidly eclipsed by the avalanche these issues in a supposedly realistic game would start. Insurgency certainly rose to the challenge initially, but once I realised how badly the realism was lacking overall, my cursing faded to a dull roar. I'm confident however, that an antilagged RO would have me obliterating records within seconds.
</rant>
Wall of text crits you for 87987632495736451.
You die.
If there are any weird jumps or unfinished points in there, I apologise. It's been a good hour and a half since I began the reply, what with looking for my Ins post, getting easily distracted and typing an essay to rival a Tom Clancy book in length.
EDIT: I will concede that you can add all the antilag you like into console games like GoW. Consoles are useless for shooters and need autoaim as it is to make them playable. Trying to lead your shots as well is just too bloody hard, so by all means, antilag it up for the console, but as soon as you stick the feature in for the console, PC titles will latch onto it like leeches on an exposed leg and then it's all over. It may mean GoW has to remain lag-unfriendly, but if that's what it takes to keep the Unreal Engine pure, then it's a sacrifice I'm willing to make.
