I'm sure many of you have heard the term host advantage through out your time playing action video games. However, I was curious if this was a real studied and proven concept in game design, computer science, and network programming? I tried looking it up on Google, but all I saw was just some gamers ranting back and forth on a forum (none of them even seem to bring up client-server concepts in their babbling...).
The essence of the "host advantage" is having a low ping (round trip time to the server). If you are the server, you'd have no ping time, but even being really close to the server would result in a small ping and still have a large "host advantage", so I'm just going to call it a "low ping advantage" instead.
It really depends on the game and how the networking code is written. Some games/engines will publish this information, but many more won't, so I'll take a few examples:
First person shooters (FPS) are likely where the vast majority of low ping complaints come from because you always shoot first, right? Valve describes how the Source Engine handles networking (Counter-Strike:Source, Left 4 Dead, Titan Fall, etc.). The article goes into great depth, so I will attempt to gloss over some of the details:
Entity interpolation causes a constant view "lag" of 100 milliseconds by default
Command Execution Time = Current Server Time - Packet Latency - Client View Interpolation
In effect, all clients are looking slightly into the past in order to help compensate for reasonable ping times. In theory, if clients are looking 100ms into the past, and if all players can get their actions to the server & other players within that time frame, then everyone should be looking at the same picture of the world at all times and everyone will be happy. But what happens when two players shoot within 100ms of each other? It will still take time for the shot information to reach the other clients, so both players may still see themselves shoot, even though there can only be one survivor. This likely creates a lot of false-positives. Since ping times aren't going anywhere anytime soon, there will always be "who shot first" arguments.
This still leaves the question: is it better to have a low ping? In the case of the Source Engine, I would argue that there's no advantage to have pings lower than ~50ms (about half of the interpolation time with default settings), but it will vary by game and can be affected by many external factors like packet jitter.
The answer gets a bit fuzzy when you start to consider high pings though. Those high ping players may not have an accurate view of the world, AND the other players may not have an accurate picture of the high-ping player. This can cause a variety of issues for everyone. Games handle this situation in various ways, and there is no clear solution. You can increase the interpolation time to make it more fluid for high-ping players, but then there will be more situations where one player thinks they did something before another. Decreasing the interpolation time will make it worse for high-pings, but fewer Hans shot first situations. Until ping times are non-existent, there will always real-time communication issues.
Age of Empires uses a what I'll dub a "buffered lock-step approach" as described in this article. There is some debate, but StarCraft and other modern strategy games likely use a similar method. Again, it's quite detailed and technical, so I'll gloss over it.
The game would tend to pause or slow only at the very worst spikes- command latency would go up but would stay smooth
There is no advantage for a low ping in games that use this method because each block of commands is executed in-order, at the same time, on all machines. You can read the article for more details on how.
Only real-time games are affected by a low ping advantage, and most real-time games will fall into one of the two categories above, which leads me to conclude that extremely low pings are no better off than medium to low pings.