Battle.net 2.0 seems to have severe netcode issues, meaning that commands take longer to be executed than they should. This is likely a result of preventing lag and dropped connections, but it comes at the cost of performance. Compared to games like Heroes of Newerth, Dota2, and Counter-Strike which have excellent latency, how long is StarCraft 2's delay?
There was a video done on this when SC2 first came out years ago but it's woefully out of date now; patches have supposedly fixed this, but the SC2 is still clearly slower than Brood War iCCup #LL. A simple example of this cross-comparison analysis between games can be seen here, but I don't know how to replicate it.
Is anyone capable of repeating the experiment for SC2 and possibly for other games as well?
Best Answer
Understanding why this question is somewhat meaningless requires an understanding of how Starcraft 2's network architecture works.
In most online games, you have a server and a number of clients. Every client will send all of its actions to the server, and the server will send the result of all those actions to every client. The server is the authority - the state of the game-world in the server's memory is the way the game-world "actually looks" at that moment. A client's game-world, however, is always out-of-date, because there is some latency (about one half of the ping) between when the server sends out updates and the client receives them. To combat this, the game will attempt to guess the real positions of objects. Keeping the game smooth when it guesses wrong is complicated, and more work must be done to account for latency in the other direction. In short, it's complicated.
However, this is not how Starcraft II's networking works.
The primary problem with the client-server model is that every server-tick (usually about 20 times a second), we need to send out the new position/velocity/health/etc. of every object that's changed. This is fine in a game like Counterstrike, where you might have upwards of 60 players and maybe a few physics-entities to update every tick. However, in an RTS like Starcraft II, where an 8-player game could easily have over 1000 units, this is simply not feasible.
Instead, Starcraft II (and every other mainstream RTS) takes a different approach. The idea is that the game should be completely deterministic, so that running the game with exactly the same inputs should always produce exactly the same results. Then all we need to do is make sure all players run the same inputs at the same time, and they should all see the same results. SCII does this by queuing up every command you give it to be done at some point in the future (typically, around 12 frames ie. 200ms). Everyone sends their commands to everyone else and then, when everyone has everyone's commands, everyone executes them all at once. Now instead of syncing thousands of units, the players only need a sync a handful of commands, a huge improvement. And because there is no need for a central authority, RTS games (including SCII) will usually just have players communicate directly with each other, rather than have a central-server. This sort of networking architecture is called peer-to-peer (P2P).
There are a number of problems with this peer-to-peer architecture:
Observable "lag". Because commands are queued and not executed immediately, there is an observable lag between when a player clicks the mouse and when the unit responds. This "lag" is not lag in the traditional sense, in that it is not due to the latency between players; rather, it is a fundamental and unavoidable consequence of how SCII's networking architecture works. It is not due to poor coding on Blizzard's part - there is nothing they can do to avoid it without switching to a client-server architecture (which would have its own, more severe issues; see above)
Every player is as slow as the slowest player. If the 200ms queue-time has passed and one player still hasn't sent out their latest commands, the game will freeze for everyone until everyone receives that player's commands. In SCII, after about one second of not receiving any commands from a player it will display the "waiting for player XXX" dialog. Also, when SCII detects that a player is consistently running behind on sending out their commands, the game will increase the queue-time to give the slower player more leeway. This is what the "XXX is slowing down the game" message means.
It's also why, when there is a laggy player, your units will take longer to respond to you, and why units will move slower or sometimes freeze altogether, even if your computer is more-than-capable of handling that many units.
Finally, it's also why I said your question is "somewhat meaningless" - it's not that SCII has "netcode issues," it's just that SCII has no choice but to increase the queue time, to compensate for the player not sending out commands fast enough. This is unavoidable, and every mainstream RTS has this same problem (Note that Counterstrike is client-server; and, due to not having as many units as an RTS, there is a good chance that HoN is client-server as well. Client-server games will not have this issue at all.)
Desyncs are possible. Under client-server, desyncing (that is, having a different game-state than everyone else) is not a problem, since the game is essentially always desynced, and always trying to compensate for it. However, in a P2P RTS game, since there is no actual authority, a desync is catastrophic - how do we know whose game-state is correct!? SCII is coded well enough that desyncs are exceedingly rare, and it will try its best to recover (eg. if two players agree and one doesn't, you can be pretty sure the two players have the correct state), but sometimes that is simply not possible. In SCII, this results with everyone being kicked from the game with the message "You have been desynced."
Cheating. In a client-server game, it's possible to give each client only the information it needs. In a P2P game, however, in order to run the entire simulation, every player must know the entire game-state at all times. This is why maphacks are possible in SCII - if the game were client-server, maphacks would be impossible. Also, players can lie about who won/lost a game (see "Stats Tracking" below). These facts are the reason many people are talking about making RTS games client-server in the future, as users' bandwidth goes up. All mainstream RTS's are still P2P, however.
Scaling. In a P2P game, the total amount of network traffic goes up quadratically with the number of players, unlike a client-server game where network traffic goes up linearly. What this means is, while P2P requires less traffic for a small number of players, it requires much more for a large number of players. You will probably never see a 64-player P2P game.
This list of drawbacks is why client-server is so much more popular. However, for games with a large number of objects (primarily RTS's), these drawbacks are not nearly as bad as trying to sync thousands of units per update.
For more info on P2P games, see the canonical article that essentially made networked RTS's possible, 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond
[Edit] There has been some confusion about the purpose of Battle.Net - after all, if there is no central server, why do we need Battle.Net? Battle.Net serves a few purposes:
Some people have claimed that, while the game is not actually run on Battle.Net's servers, the commands players send to each other are still routed through Battle.Net. This is possible, but highly unlikely: it would unnecessarily and enormously increase Blizzard's bandwidth costs, and increase the lag (possibly significantly) for all players. The only benefit would be to hide the players' IP-addresses from each other. I'll come back to this post when I learn more.