Mysteries of the Universe

So if you’ve played with me in the opening days of BF3 you know I had a ton of complaints. (Not that it’s unusual that I bitch and moan, just more then usual.). Anyway I looked up some issues. Here is what I found.

MYSTERY 1:
If you’ve ever been killed by a gun in one shot that was NOT a OHK (One hit kill) weapon and you were at or close to 100% health here’s why.

LAG LAG LAG. But let me go into a little more detail. Essentially the person with the faster connection is at a disadvantage because the enemy sees you at normal speed. You however see the other person’s ghost image. You were essentially shooting at where the guy was a ½ a sec ago.

But Ser9ph I already knew that what’s the point. Well here’s the kicker. While it did happen in BFBC2 it was less prevalent than in BF3. So why?

DICE decided to move hit detection to client side (meaning us) as opposed to server side in BFBC2. In the old game the server would decide who won the fight. Now it’s who has the crappier connection. If you’ve ever played MW you know the host has the advantage over everyone. We are basically “hosting” our own deaths.

But that doesn’t explain how it was one shot.

Ok well GTA and I did an experiment once seeing who could shoot faster between a Grach and a Burst. We both fired at each other. I said why did you fire only 2 shots. He said why did I only fire 3. We tried this over and over. Even though we both emptied our clips in seconds the animation showed us literally shooting…….1……..bullet………at………a……….time.

The server cannot handle how fast our fingers can fire plus lag = WTF. The guy who killed you was probably shooting you for awhile but the server was too slow in telling you.

MYSTERY 2:
You ever ran from fire around a corner only to die after you made it. Here’s why. You have a shadow.

Even with the best net code (which EA is the worst) plus good servers, programmers have to account for lag. To do this they extend your hit box beyond your actual character. Don’t assume the figure standing is the entire hit box. You actually have a shadow trailing behind you. Assume it’s anywhere from half to a whole person hit box extra.

So I believe you, you made it around the corner. Too bad your shadow didn’t.

I get that, but, seriously, how fast does my connection have to be? If I start jacking up the bandwidth much more (currently 12 Mbps), my internet bill is going to hell in a handbasket.

Your reading it wrong. It's better to have a CRAPPIER connection. You're at a disadvantage because you're at normal speed. They see you as it's suppose to play. You're fighting ghost images of laggers.

I don't blame laggers I blame DICE. The servers should balance that out as it did in BFBC2. The way it is now is an unfair advantage. Like hosts had in MW.

Sorry I was not trying to say anyone here has lag issues. I don't judge, I know you get whatever is available in your area. That has nothing to do with you. The best way to test this out is go play MW. Find out who the host is. Fight him one on one. Assuming you both see and fire at each other at the same time. He will always win. I don't care if you are the god of videogames. It's not something you can make up for.

So I wanted to expand a little more on this as I've been getting a little more WTF moments lately. This was an article posted about BF3 going client side hit detection. If you just want the long story short move on to the next post.

This is written by a guy who writes netcode, specifically for RO HOS

There is no "disadvantage" to the net code of UE3. It works quite similar to UE2, and Red Orchestra 1 was widely regarded as having some of the best net-code around - with the game being very playable even up to a ping of 200ms. And considering I'm the guy that did the multiplayer network coding for RO1 and I'm doing a lot of it for RO2, you should see similar results in the end. Regarding AA3, I can't speak to it's network code since when I tried to play it it was back when the game wouldn't even function online right after it was released.

When it comes to visual representation of hits (i.e. displaying hit effects/particles) there are two methods possible, and both have their advantages/disadvantages.

Method 1) Calculate hit effects on the client. With this method you get instant feedback on where your bullet would hit (with hitscan weapons). This is great but there is one major flaw - where you see your bullet hit on the client doesn't actually represent where your bullet hit on the server since they are both calculated independently. This was the system that was used in Americas Army 2.X (which I worked on). This system is exasperated by randomness or cone fire, since to simulate the shot on the client you have to simulate the randomness you would also have on the server. The problem is, since it is random the client and the server will have different locations where the bullet will go. This is why in AA2.X you would very often actually see puffs of blood coming off of an enemy that you were shooting, but in reality you didn't hit them at all. Your client side simulated shot had hit them, but your server shot had not.

Method 2) Display hit effects on the client in the proper place by sending the information from the server on where the "real" hit actually happened. The disadvantage of this system is that there is a slight delay between when your shot is replicated to the server and when the hit location is replicated back down to your client. The advantage of this system is that when you see a hit effect appear it actually appears where the real hit happened on the server. In other words, when you see that you blood puffs appearing on an enemy that you shot, you are ACTUALLY damaging them.

In the original RO and since then I have been using method 2. I find the slight delay until the hit effect appears is far outweighed by never getting "false positives" and knowing where my bullets actually hit. Combine this with a non-hitscan system with full bullet ballistics where even if you are playing a non-network game there is a slight delay between when you fire and when your bullet hits, then the delay when playing online is almost not noticeable with a ping < 100 ms.

Also, in your case where you say your ping is 60 ms, but there is a delay 0.3 to 0.5 seconds (300-500ms) either there has to be something wrong with your network, the network between you and the server, or the people coding that particular game. Because in the standard "Method 2" system above, with a 60ms ping it would be about 120ms (or .12 seconds) before you saw the hit effects. Most likely it is a problem with your network, your computer, or your perception of time.

Finally, there are the games with the so called "lag compensation". I've never been a fan of this so called lag compensation because of the side effects it causes. If you have ever been playing an online game and walked completely around a corner only to die when noone could possibly have shot you, it was likely do to lag compensation. With these systems the server stores a list of locations and where a player was at a particular time. Then when a player shoots on his client it sends the firing info and a timestamp to the server. So when the server receives this information it basically "rewinds" back to the point in time when the client fired and checks to see if the shot from some time in the past would hit the player back then. The problem with this system is, that depending upon players ping everyone playing the game has a different view of where the other players are at a particular time. This is why on your machine you could be behind a wall, but the player (who you may not even be able to see on your machine) who has a higher ping than you sees you where you were a short time ago and shoots and kills you. So this is why I think lag compensation sucks

I prefer the Unreal net code methodology which uses client side prediction instead of lag compensation. When a programmer knows what they are doing and uses the Unreal net code properly client side prediction gives all of the clients connected to a server a very very close picture of where the other players are actually at on the server at all times. It does this by predicting the physics and movement of the other players. It does this pretty good for super-fast games like UT, and when you slow this down to real world movement speeds like in Red Orchestra this system is rock solid. In other words, in RO when you shoot at someone you can pretty much guarantee they are at where you see them at (up to a ping of 200ms). Likewise when you get SHOT by someone on RO, it was because they could see where you are currently at, not where you WERE a short time ago.

After coding MP network games for nearly ten years, this area is a bit near and dear to my heart, so I'll stop ranting now

To shorten this long ass post I will be using abbreviations CS: Client side hit detection SS: Server side hit detection
Ping: How long it takes your console to send and receive info from the server and other players.

Ok so why did DICE go from server side hit detection to client side. The answer is less ominous that I thought it would be.

If you played BC2 since the beginning you will remember a period when rubber banding was at it's worst. Everyone was constantly getting snapped back to positions they were previously at. This was due to BC2 using SS. SS more accurately represents where you are in relation to others and on the server. What 1 person on his/her screen is what everyone else on the server would see. The drawback is that when the server gets a lag spike you get hiccups or rubber banding because the server has to correct itself. This is why ppl in BC2 would moan about KSA players. Because their pings would generally be higher then most other countries they would end up "lagging up" the server.

BF3 uses CS. This eliminates rubber banding because it predicts where you are and where you are going/shooting. This allows for smoother gameplay VISUALLY. CS relies on the belief that the info being sent from player to player are reliable. The problem lies when the info is not reliable. What you see on your screen may not accurately be what's happening. You may be shooting a guy and getting hit markers galore. But that's just your console assuming the enemy is at that position. If said enemy is far away from you in RL (geographically) or has slower internet speeds that info will take longer to reach you. Thus the game is trying to guess what is happening.

This is exasperated by the suppression effect. Because a player under suppression will fire randomly all over the place even if you are on target.

This can also be further exploited by jumping around or zig zagging in wild patterns. Because the game has a hard time predicting these movements it essentially makes the console make bad guesses.

Sad panda