Go to original post
-
Think of it this way. Since there is no dedicated server, one of the 12 xboxes is chosen to be the "host". So on that xbox that is the host, a listen server process is started to watch/oversee the game and send status frames to every client. For 11 of the players, their game will be a client of the 12th xbox and will send frames to and receive frames from the 12th xbox. On the 12th xbox, the player will also be a client - to himself. The theatre records the frames received from the server which may be slightly different from how the game was rendered by the client.
This is typically where the host would have a significant advantage barring any lag compensation algorithm, because the player on the xbox acting as server would have essentially no client delay to the server, therefore this player can interact with the sever faster - receiving updates from and sending updates to the server while the same status frame may still be in transit to another client.
Let's have an example. Say I am hosting a game of COD with no lag compensation mechanism whatsoever. In this scenario I am a client of my own xbox, which is running a server process, to which I have essentially 0 (< 3ms) ping. Suppose the match I am hosting is full of players whose client xboxes have a 150 ms ping to my xbox, the server. That means it takes 150ms for their xbox to send the frame to my xbox, and 150ms for my server's frame to get back to them. In this scenario, I am essentially 300ms ahead of everyone else in the game. This is where the advantage comes in, because say I and someone else are about to round a corner at each other. The server message "enemey rounding corner" will get to my 150ms faster then "me rounding corner" gets to my enemy. Accordingly, I see the enemy and shoot him dead. Depending on my reflexes and how many bullets it takes to kill, my client message "i killed that guy" will potentially get to the server while the "me rounding corner" message is still en route to the enemy. The server will then send my enemy a "you're dead" frame. From his perspective he will see me come around the corner, and 100 ms later he will be dead. Because of the delay, he might see me and shoot me, but no amount of shooting me would do any good because the server already has him marked dead on my end. When my xbox receives his "hey i'm shooting you!!!" frame about 200 ms after the server already has him marked dead, the frame would be discarded.
May I also add that in the example above, with no lag compensation, the host would experience the only "normal" gameplay. To the other clients in the game, they would experience increasing amount of "wtf" and "bs" the higher their ping got - clients within a ping <50ms would likely experience an almost normal game, and few hosts have human reflexes that fast, but once you start getting into ping > 150ms the clients would be having a situation where the killcam noticably does not match the reality they saw - the host and other high-ping players would "come out of nowhere", "killed me instantly", "my bullets didn't register" kind of events. If hitboxes are rendered seperately from player models (most games are this way so I think so but I don't work for IW), while you are running your player model around the map you are dragging your hitbox around behind you like a big suitcase. So the higher the ping is the longer the strap can be on that suitcase, and while you think you just ducked behind a wall, your hitbox might still be out in the open from some other client's perspective. You would typically notice this at match end when your player model "rubber-bands" back to where your hitbox is.
This is where lag compensation (all games have some form of it) comes into play. Essentially, to "even out" the connection disparity between high, low, and no(host) ping players, compensation is applied - artificially inducing a client delay in the host (and potentially other) players. This means that in effect the goal is to artifically delay the frams from the server, or hold frames from a client in a queue, according to some sort of tickrate that can be synchronized across all clients. In the example above, to even out the play for instance, the server would intentially delay the "enemy rounding corner" frame to me by some ms, and would intentially not process the "i killed that guy" from me to my own xbox by some ms.
Now the issue with not having dedicated servers is, a dedicated server can be an impartial host. All clients would have a compensation applied that may or may not dynamically adjust during game play, but any variance in a client connection would only impact gameplay for that particular client. Unfortunately in a P2P hosted game, particularly one without dynamic compensation algorithms, any variance in the host connection affects all players. This is where we could get into the detail of connection modification during the compensation calculation but to prevent cheaters taking advantage I'm going to leave that part out
PS Let me just add something about connection characteristics. Bandwidth is really not the most important factor for gameplay. Game frames are very very small pieces of data. What you are interested in is connection saturation and latency (ping) - how fast those frames get somewhere. Different types of connections (FIOS, ADSL, Uverse, Cable) have different characteristics under stress that can impact your gameplay. Uverse for instance uses an interleaved asynchronous DSL line, meaning that upstream latency (the most important part of gameplay, as it's your message to the server saying who you shot at) will suffer greatly when the connection is under stress. You can test your connection yourself. On windows which many of you may have, run the command "ping google.com -t" and note the stability of your ping in ms. Then open a youtube video and play it on a higher quality and see how your latency is affected. In this instance your bandwidth is typically not saturated but your latency is suffering due to the nature of asynchronous communications.
