(Hopefully this will post quicker than the last post I submitted)
I'm that friend Mekhazzio mentioned as no longer playing the game because of the networking. That video shows only the second time I've started up the game in the past month, simply to give a clear-cut demonstration of how the "dying behind cover" illusion exists in RO2 -- the other time this month being to join an empty server to get a Steam winter-sale achievement.
It's really dissapointing. RO2 has, essentially, become the best game I would not recommend to someone. And I love good-but-flawed games in general, some of my favorites still have plenty of odd quirks and outright bugs, but I play them anyway. RO2 has the distinction, however, of having its flaw not be a bug or oversight, but an intentional design decision. Even when my friend is playing RO2, I might stop and watch for a bit, even think of playing, but every time I know that it's going to end with disappointment.
What's really surprising is the general lack of understanding as to what is going on with networking.
In any multiplayer game, there will be a disparity between what the shooter sees, what the server sees, and what the target sees. There is, quite literally, no practical way to avoid this. The delay in the transmission of data makes this inevitable. Instead, we can only design games to attempt to give the illusion of simultaneous action for certain situations. The choice of networking model determines what point-of-view is going to be given this illusionary effect. You've got three choices here (Technically four, though two of them are effectively the same for this purpose):
Target-side hit-detection: This model has no dying-behind-cover illusion, because the target in the shooter-and-target relation judges all shots, and replies to the server that it got hit. The downside of this model? The shooter has to have his shot hit the target on the target's machine. This means he has to lead for both his own latency, and that of the target. For an internet game, where you will not know the precise latency of the target, this makes it almost impossible to hit a moving target with a pin-point weapon. I can think of only one game to ever use this model, and it was never intended to be played outside of a LAN.
Client-side hit-detection (Or latency-compensated server-side hit-detection): This model presents the most natural and accurate shooter-side appearance, as all of his shots are processed (Or appear to be processed) exactly the same as they would in single-player. Network conditions have no effect on this model under most circumstances, barring major packet loss or the like. The downside of this model? The dying-behind-cover illusion. Since the shot is processed either on the client or the server's rolled-back record, the target has a slight delay between when he is actually hit and when his computer gets the message. While he actually got hit while, say, running past a window, he doesn't receive the message until a moment later. He might see himself behind cover by then, but it's effectively an illusion. He's been dead a hundred or two milliseconds, when he was in the open, he just got to the appearance of living a little longer. Mind, the shooter did not have any longer of a time when the target was visible, he just doesn't have to lead for his own latency. The target was visible on the shooter's screen for the exact same amount of time.
And finally, the server-side hit-detection, with no latency compensation (What we have in RO2): This is, essentially, a compromise between the two. Unfortunately, as a compromise it has the flaws of both. Shooters do not get natural shooting, and targets can "die behind cover." The illusion of smooth and simultaneous action does not exist for any player in the game. It works acceptably for games that use lots of explosive/area attacks, cone attacks (Flak-cannon type, or cinematically-wide-spread shotguns), or ubiquitous high-rate-of-fire weapons with forgiving hit-detection, which is why UT used it (And nobody else recently). In a game that features slow-firing pin-point weapons like a bolt-action rifle as the standard and by far most common armament, this model works poorly.
So which do we go with? We want the one that breaks immersion the least, the one that will least frequently give results different than we would expect if everything were actually simultaneous, whether single-player or on a LAN. For the shooter-to-target relation, we have two possibilities that break from that expectation: Shooting at a moving target, or being shot in the last 1/5 to 1/4 of a second before arriving behind non-penetrable cover. The former is exceedingly common, likely about half the shots made in the game, maybe more, while the later is so uncommon people do not even recognize that it happens now. Even after a video demonstrating how it happens now, people still do not recognize that it happens. If it happens so rarely that you don't even recognize it happening now, how bad could it really be? Is double of "never" going to make a big difference?
Further, the current model encourages many of the tactics that so many people complain about on these forums. The run-and-gun, the MG hip-fire rushes, etc. Those are strong because the networking model gives an advantage to moving targets, particularly when competing against slow-firing pin-point weapons like riflemen. Someone with a MG or SMG is, thanks to the network model, less likely to get hit by bolt-action fire while running in the open than he is taking near-total cover. If we had a model where the shooter gets accurately-simulated firing, the viability of run-and-gun hip-fire tactics would be sharply curbed. Instead we get silly stuff where wiggling side-to-side as a rifleman is safer than bracing carefully behind cover. If you get ambushed in the open, you are safer continuing to run through that wide-open field than you are to take cover in an attempt to return fire. And if you're in close-range, never stop moving, particularly if you're trying to kill a rifleman.
As for the video itself, I'd like to give a few details, since some people seem to misunderstand what is happening. We set up the situation as best we could to show the "dying-behind-cover" illusion with as few variables as possible. We gave an establishing shot to show where I was shooting from. We showed the player list to note that we were the only players on the server, to show that I was, indeed, the one making the shot. He moved behind each side of the window to let me fire a burst into the wall, to demonstrate that the particular wall could not be penetrated by fire -- you can even see the particle effects clipping through the wall where my bullets hit, directly in front of him, yet none penetrate (It actually took us longer to find a suitable wall than it did anything else). Then we quickly go from that to a run-across while I fire into the window. Finally, after his body hit the ground, he looks around with the third-person camera, showing clearly that he died 1.5-2 meters past the last possible place he could be hit. It is as clearly as possible a demonstration of the dreaded dying-behind-cover illusion that people don't want "introduced" by any latency-friendly method.
Yet people complain that they don't want client-side or latency-compensated shot handling, completely willing to let the accurate simulation of shooting be trashed while not gaining anything in return.
