What is the architecture of something like B.net like?

[Slapshot136]

particularly how do they manage game lobbies, groups (parties), cross-game chat, friends, etc.

or if not b.net, lets say steam, or xbox live, etc.

I would like to know how they get a group/party into a single game - is there a concept of the "group" somewhere on a B.net server, or does each client form the group themselves?

 

[Accname]

I would guess it is the Host in a Host-Client architecture. A client requests to start a game and the BNet server will host it. Clients can join and at that point its much like a Chat-Server. Whatever one client does is broadcasted to all others within the game / lobby.
Its fairly simple to do this, the problem arises when you try to do it good and on a larger scale.

 

[Slapshot136]

I would guess it is the Host in a Host-Client architecture. A client requests to start a game and the BNet server will host it. Clients can join and at that point its much like a Chat-Server. Whatever one client does is broadcasted to all others within the game / lobby.
Its fairly simple to do this, the problem arises when you try to do it good and on a larger scale.

how does a "team" join the lobby at the same time then? (since it would suck if you had a party of 4, game accepts 3, and then a random person joins as the 4th instead of your last member).

 

[Accname]

I dont really use BNet much, could you elaborate?
Is it like people make a group and then they always join lobbies together?

I would guess if one person of the group joins the BNet server will send a message to all other members of the group and urge them to join too.

 

[Slapshot136]

I dont really use BNet much, could you elaborate?
Is it like people make a group and then they always join lobbies together?

I would guess if one person of the group joins the BNet server will send a message to all other members of the group and urge them to join too.

pretty much, except that the group joins as one - as in all at the same time (and also gets placed on the same team)

so an example would be there exists a game that is 4v4, with 2 players in the lobby already on team A - a party of 4 decides that they want to join the game - the party leader will attempt to join the game, party players 2,3,4 will OK the leader's proposal, and then the group joins the lobby and are all placed on team B (whereas if they joined individually, they would occupy 2 slots on team A and 2 slots on team B)

 

[Accname]

I cant see what the problem with that is? Both server and clients are controlled by blizzard.
The server can either place them automatically or make them send the required messages to join the game and a certain team.

It might be a lot of work to do, but it is not complicated work. Its simple, its just a lot of code to make everything work together.

 

[jonas]

I think blizzard doesn't do the hosting, they probably use UDP hole punching or something to make the clients do all of the data trafficking... No need to pollute the bnet servers with all of that data.

Joining the lobby as a team seems trivial. Simply have a datastructure for teams on the server which behaves like a collection of players, and if one of the players joins a game, put all of the other players into the same game, notifying their clients of the update... on the server this can be atomic, even if the clients see the change with a huge delay (between each other).

 

[Accname]

I think blizzard doesn't do the hosting, they probably use UDP hole punching or something to make the clients do all of the data trafficking... No need to pollute the bnet servers with all of that data.

I dont think so. If this was the case we would have LAN support for tournaments.
It would also be too easy for hackers to create their own Servers like they did in broodwar. I believe that blizzards wants to milk the player base as much as possible and so they were extra careful with keeping all the control in their hands.

 

[jonas]

I dont think so. If this was the case we would have LAN support for tournaments.
It would also be too easy for hackers to create their own Servers like they did in broodwar. I believe that blizzards wants to milk the player base as much as possible and so they were extra careful with keeping all the control in their hands.

Well, it's just a question of money and infrastructure...
Do you think it would be easy to include measures that keep the control, e.g., some small background traffic, without having to broadcast all of the game data of millions of players? Maybe I'm also overestimating the amount of data that is sent...

 

[Accname]

I dont think its too much data. They only have to transfer player inputs. Each single input is probably just a few bytes and the smallest package sizes are what, 64kb?
This should be absolutely no problem with a good connection. Its basically an echo server. Besides, BNet really is pretty laggy from time to time. Even at the larger tournaments the players often have to fight against the lag.


Lets just make a calculation.
Lets assume a single instruction of a player is like 20 bytes. Thats generous. You know, all you need, actually, is the playerID (1 byte), the time (8 bytes) and an ID for the action. But since we wanna be flexible and all, lets make it 20, just to be sure.

A good player has 300 actions per minute. The vast majority of players has much much less, but to keep it simple, lets assume we are all badass and do 300 APM like a BOSS.

For 1 million players we have:
300 * 20 * 1_000_000 == 6_000_000_000 bytes per minute.
That is:
6_000_000_000 / (1024 * 1024) == 5723 mb per minute.
That is:
5723 / 60 == 96 mb per second.

And that is not very much.
Now assume that they do not have one server but hundreds of servers. If you look at it this way, it really isnt that much work they need to put in.
Not in the 21st century for a multi-million dollar company.



Edit: Another point to consider:
If two koreans are playing against each other and they play on the european or NA servers they are still having high lag. This pretty much ensures that there is constant communication with the server involved or otherwise they would get the same speed as if they were playing on the korean servers.

 

[jonas]

They send a lot more than that... In fact I'm positive they send data about nearly every update that happens in the game, which is why creating units locally creates desynchs in the first place. Nevertheless, I don't think that your ballpark figure is off by more than 100 (even though just sending the data of a unit creation is at least 20 byte).

The effect that you describe could also be explained by sending just *some* packages over the blizzard servers.

 

[Slapshot136]

if one of the players joins a game, put all of the other players into the same game, notifying their clients of the update... on the server this can be atomic, even if the clients see the change with a huge delay (between each other).

so in other words the "group" needs to live on the server then

 

[Accname]

They send a lot more than that... In fact I'm positive they send data about nearly every update that happens in the game, which is why creating units locally creates desynchs in the first place. Nevertheless, I don't think that your ballpark figure is off by more than 100 (even though just sending the data of a unit creation is at least 20 byte).

Exactly not!
If they were sending all that data then no desyncs would happen! If all the data was available the game state could be reconstructed to match and desyncs would be no more.

I would guess that each object in the game, no matter what it is, gets a unique ID, probably some 64bit integer value. Whenever something is created it gets a new one.
If there is ever a point where 2 players have an object with a different ID then the game knows it has desynced and thats it.

 

[jonas]

Exactly not!
If they were sending all that data then no desyncs would happen! If all the data was available the game state could be reconstructed to match and desyncs would be no more.

This is not the case. There are two ways to deal with inconsistencies in the game states:
Reconstruct or disconnect. The first option only works if enough data is sent to detect inconsistencies immediately.

If there is ever a point where 2 players have an object with a different ID then the game knows it has desynced and thats it.

The game knows it has desynced if it knows that there are two players with different game states.
Maybe my memory is fooling with me, but as I recall, if you create a unit for a single player, the game desynchs immediately. Therefore, the game knows immediately that there is now an additional object on that machine, but not on the machine of the other players.
Otherwise, creating a different unit for each player would also not desynch.

 

[Accname]

I dont know how it is in SC2 because I never play, nor make custom maps there. I never bothered much about desyncs, I never attempted to create anything just for one player.
I would definitely recommend against doing that. Its pointless. There is absolutely nothing that you get from doing so.
The game should always assume that the other computer is doing the same thing. Only when it does not there should be a desync.
I mean, the human players will not notice a difference of a second or two before the desync, but for the game this can be a lot of messages going back and forth. So how exactly would you know how "immediately" the desync happened? Is 100 messages later still immediately? It might only be a second of real time after all.
We also dont know how these ID's would beconstructed, maybe they carry information that can be used to find errors.

Did you ever try to create a local unit for all players simultanously?

 

[jonas]

I dont know how it is in SC2 because I never play, nor make custom maps there. I never bothered much about desyncs, I never attempted to create anything just for one player.
I would definitely recommend against doing that. Its pointless. There is absolutely nothing that you get from doing so.

What if you want a single shop that sells different items to each player?

Did you ever try to create a local unit for all players simultanously?

I just did.

Custom script:   call CreateUnit(GetLocalPlayer(), 'Hpal', 0,0,0)

Desynchs.

Custom script:   call CreateUnit(GetLocalPlayer(), 'Hpal', GetPlayerId(GetLocalPlayer()) * 1000  - 2000,GetPlayerId(GetLocalPlayer()) * 1000  - 2000,0)

Desynchs.

(I reduced vision of the paladin to 100).

So how exactly would you know how "immediately" the desync happened? Is 100 messages later still immediately? It might only be a second of real time after all.

Probably it has to be the same message. Otherwise, things as the following could happen:
I create a different unit on each machine, one where the unit deals 10, one where it deals 9 damage.
The unit fights, until it kills one unit on the machine where it dealt 10 damage.
The killed unit is ordered stuff on the machine where it was dealt 9 damage -> desync detected, but in between lots of things happened... Basically the whole game state would have to be synchronized now.

I think there were such effects in Star Trek: Armada when we played it in LAN... Units starting to move different on different machines, desynch detected only after 20 minutes.

 

[Slapshot136]

(I reduced vision of the paladin to 100).

as maphacks have proven, each client has information regarding all of the unit data, even if they shouldn't have access to that information in-game

 

[jonas]

as maphacks have proven, each client has information regarding all of the unit data, even if they shouldn't have access to that information in-game

Well, so has the above experiment. Which just shows that there's a lot of extra synchronization going around.

The game should always assume that the other computer is doing the same thing.

It could, but in this case doesn't. I remember other things causing desynchs only at a later point, like adding items to a shop only for a local player - the desynch is caused only once the item is purchased...