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?

  • 7
    iirc starcraft 2 has an inbuilt delay of 200ms (that is if your lag is 50ms, your command will take a total of 200ms to begin, if your lag is 300ms, your command will take 300ms to begin). if I find a link that confirms this i'll post it as an answer, with a clearer explanation.
    – chobok
    Commented May 4, 2012 at 2:05
  • It may be worth editing the question to reduce the scope. Perhaps, just ask about the input delay for Starcraft 2, and create new questions if you want information on input delay for other games.
    – chobok
    Commented May 4, 2012 at 7:23
  • Not sure why this would get downvoted; every game has a very small delay between when you click the mouse physically and when the action is executed in game. It will vary game-to-game based on your framerate and how the game is designed with respect to frames and multiplayer synchronization. But there's no way this is as high as 200ms; that would make most micro impossible. I think of it like a MIDI keyboard; delays of only 30ms make it impossible to play. Comfortable is <10ms. Whatever the delay is, it's vastly shorter than network latency.
    – tenfour
    Commented May 4, 2012 at 12:12
  • Oh wait you're asking about the total latency including network? If that's the case, there's no way to answer this. There are many bnet servers in many locations, nuances in the match-making system, etc. It sounds like you just want to complain in the form of a question, to which the answer is just to say what that youtube video says.
    – tenfour
    Commented May 4, 2012 at 12:21
  • @tenfour there is clearly a way to answer this as both of the videos that I've linked to have done so. The problem is that the video for SC2 is nearly two years old and changes have been made since.
    – Decency
    Commented May 4, 2012 at 17:47

2 Answers 2


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:

  • Matchmaking. The players communicate directly with each other in-game, but they need some way of discovering each other to begin with.
  • Stats tracking. Keeping track of wins/losses/achievements/etc. Of course, since the game is not actually running on Blizzard's servers, Blizzard must rely on each player honestly reporting when they win/lose, which could lead to cheating. But this sort of cheat is easy to detect, since two players disagreeing on a win or loss should be rare, and when it happens to the same player over and over...
  • Nat Punch-through. This is why you don't need to open any ports in your firewall to play Starcraft II.
  • Anti-piracy. There is no technical reason why the game should quit when Battle.Net goes down for repairs; or why you should need an Internet connection to play single-player. They only do this as an (misguided, in my opinion) attempt to combat piracy.

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.

  • 1
    This info might or might not be true for Starcraft 2. But this 12 fram or 200ms stuff is not correct. You make it sound as if this value depends on the players in the game, but it does not. Try this: Open Marine Micro in your World Editor and play, afterwards open a "single player" Battle.net game with Marine Micro. You will notice a huge difference and it has nothing to do with your P2P stuff as there is no other player. The point is Battle.net forces this delay. Prove me wrong.
    – ayckoster
    Commented May 10, 2012 at 22:28
  • I forgot to mention that Starcraft 1 has almost the same amount of information floating through the network and iccup has way lower latency. The graphics might be crappy but the production / damage calculation needs similar inputs from all players.
    – ayckoster
    Commented May 10, 2012 at 22:30
  • 2
    Thanks for the level of detail. My only problem with this answer is that StarCraft 1 simply didn't have this issue and so I don't understand why SC2 does. People were able to play online SC1 with very good response times (either through a modified Battle.net like iCCup or by using 3rd party programs like Chaos Launcher). Your argument is that it's not feasible to run a P2P structure like this, and yet a game nearly 15 years old is capable of it. The differences between RTS architecture and that used in games like DotA helps clarify slightly, but that issue remains.
    – Decency
    Commented May 10, 2012 at 22:31
  • @Decency: Those modified launchers likely just reduce the time between command executions, so that commands are executed much sooner after you give them. This is obviously only a good idea if you can guarantee you'll have low latency to every other player. My argument was that it's not feasible to run SC1/2 as a client-server, which still stands; those alternate clients do not change the fact that SC is P2P (doing so would require a complete rewrite of the game, from the ground-up). Commented May 10, 2012 at 22:37
  • 1
    @BlueRaja-DannyPflughoeft Right, which is perhaps now how you can understand my claim that SC2 has poor netcode. Even something as simple as TCP has a period where it determines what the connection is capable of; and even StarCraft 1 allowed you to modify the interval of "command executions" through the latency setting. I'm not advocating a client-server architecture, merely a P2P architecture that can correctly utilize the resources available to it.
    – Decency
    Commented May 10, 2012 at 22:41

Starcraft 2 has an input delay of 200 ms, like Starcraft 1 (Battle.net) Reference. This is not due to the netcode but the servers force this delay to make it more competative.

This example goes for every server / client layout, even if the server is a client (player):

This delay is forced to make the game more balanced. Suppose I live next to the servers and you live on the other end of the country. I have a super good connection as I live in a big city and your connection is poor because there are no good providers where you live. My delay is 10 ms and yours is 190 ms.

While I cannot prove how the games are hosted or what network engine Blizzard uses it should suffice to say there is a set lower bound. Have you ever tried to play 1v1 with a buddy in the very same room? I mean even the worst possible netcode / network transfer with as many units as the game is possible to support should be nothing compared to 1 gigabit Ethernet.

If there is some kind of P2P GSL should have no lag as everybody is on the same switch (connected to the internet). Well, they still have lag issues.

The same is true if one player is selected to be host, they are still on the same subnet, so there should still be no delay.

In other games, say HoN, I would have a huge advantage, because my delay would be significantly lower than yours. Starcraft 2 tries to compensate this by forcing 200 ms delay. If your delay is bigger then that it's your problem and you have to suffer the consequences.

There is no point in comparing the delays as you cannot go below 200 ms, at least not in Battle.net.

iccup circumvented the 200 ms Starcraft 1 delay by providing an own server (not Battle.net) without Blizzards consent, this worked fine because there no policies and the game was pretty old, so Blizzard accepted it. But now there are hefty fines for reverse engineering the Battle.net.

During Beta DarkBliz tried to hack the Battle.net and the founder got threatened with law suits and backed of.

So basically there will not be a no/low delay version of Starcraft 2 until Blizzards says so. Please do not think that Blizzard implemented a poor netcode. I mean they are a multi-billion dollar company and if they wanted Starcraft 2 to have a smaller delay they would hire the right people if they do not already have them.

Here are the facts dictated by logic:

  • There must be a lower bound for latency, no Starcraft 2 game can go below that. It might be 200 ms, as many sources suggest this value and this is the confirmed value for Starcraft 1. (See reasoning above)
  • Blizzard must have their own reasons for this forced delay, as they have introduced this delay in every RTS they have released and every RTS was very popular.
  • Even if you knew their code or software design is flawed (read bad) you cannot change that.
  • "the servers force this delay to make it more competitive" - this is not true. The delay is due to the way network communications work in SC2 and all other RTS games. I'll write up a more detailed answer later. Commented May 10, 2012 at 19:25
  • 3
    The problem with having no minimum queue-time is that even a small network hiccup will cause the game to completely freeze for everyone - and intermittently freezing completely causes a MUCH worse experience for players than having a little bit of command-lag. Keep in mind that the minimum-delay (200ms) is still less than the average human reaction time (about 215 ms), so it's really not that bad. Commented May 19, 2012 at 0:50
  • 1
    @BlueRaja-DannyPflughoeft That's been clear for quite some time. SC1 mods detected and set this threshold in some fashion, often as low as ~30ms. It had minimal hiccups. This is an absolutely enormous difference in any sort of micro situation. Playing a micro intense game with that kind of latency is nearly impossible, which is one contributor behind why SC2 right now is so macro-heavy.
    – Decency
    Commented May 20, 2012 at 18:05
  • 2
    "iccup circumvented the 200 ms Starcraft 1 delay by providing an own server" That's nonsense too. ICCup having their own server is unrelated to latency. SC1 gameplay is entirely p2p. It's their client that reduces the latency. Commented Jul 31, 2012 at 16:17
  • 2
    @BlueRaja SC2 is p2p in the sense that every client simulates a full independent copy of the game. But game commands are relayed through blizzard servers. This is unlike SC1 where messages where p2p. 200ms delay is fine but noticeable if you pay attention. Commented Jul 31, 2012 at 16:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .