This isn't a deficiency of LAN games, it's a deficiency of the observer mode Blizzard added to the game when they remastered it. The code they wrote to deal with stealthed units as an observer mistakenly changes the actual game state when you change player vision (i.e. set the game to only show one player's vision), which leads to the game state desyncing for the observer that does this. I run a project (ShieldBattery) where we've developed numerous patches to the game including a fix for this bug, but pro games don't use our stuff so they're stuck with the bug unless Blizzard decides to maintain the game again.

Oh, that's good to know. Shield battery is a great project. Thanks for your work.

It's there to help guarantee that the server the browser is connecting to actually understands websockets and isn't being "tricked" into opening a connection through clever request formulation. With that guarantee in place, browsers can trust servers to properly check for and limit cross-domain requests and the like and not need to use something like CORS to negotiate that stuff.

Why not skip all the hashing stuff? Why not just have Sec-Key: 'secret' and expect a reply with Sec-Accept: 'secret'. (where secret is hardcoded constant)

While this is a fairly good explanation of some interesting things about Starcraft, I think something truly interesting about mutalisk stacking in particular is its actual discovery date. It wasn't, in fact, discovered in the 'early 2000s', but rather in mid 2006, a good 7 years after the game was released.

Prior to this trick's discovery, players stacked mutalisks by right clicking the group onto a mineral patch or gas geyser, which causes them to clump up more than right-clicking onto the ground (July, who you mention, actually won at least the first 2 OSLs without the benefit of this trick). I would imagine that air units in Starcraft have a similar hack applied to their moving collision detection as the workers do with mining, as the exhibit a lot of the same behaviors (okay with being on top of each other while moving, spread out as soon as they stop moving).

Yeah, it does exist and is usable in current versions of Chrome if you change the flag for it. I'm not sure if the Chrome version of the API is what the final one will be though, since it seems to differ somewhat from the version documented on MDN: https://developer.mozilla.org/en/API/Pointer_Lock_API

Still it would probably be fairly easy to add support for it to this and replace the annoying click-drag camera movement when possible.