Understanding lobby heirachy

Danthekilla

Hey,

We've just gotten a simple chat application running, using our own dedicated server and are moving on to creating networking for our FPS. However we are having some trouble with key concepts of Photon.

1) Is it true that it is impossible to obtain information about rooms and peers by directly contacting the server without being in any form of room?

2) When using the Lobby system, how does it's hierarchy work? This is what I have gleaned (Please correct me):
a) There is only one lobby, and clients know it's name as it is a hardcoded constant. Server side code, is able to collect information about the hundreds of potential rooms, and return this in an event/packet to any of the unlimited number of people/peers in the lobby room.
b) Within this in event/packet, there can be room names, and quantities of players I can display and ultimately use to join a game room.
c) A second lobby, would contain within it, a completely separate set of potentially thousands of games. Each lobby will return different results.

What we are trying to achieve:

- Client requests a list of 50 "Best" active sessions/rooms
- Server based on ping/language/preferences sifts through 1000 rooms/sessions, and returns that best 50
- Client displays results of search to user, who selects a currently running session, and joins game

This is how XNA on Xbox 360 works, and what we are familiar with.

Thankyou for your time!

Tobias

I assume you run "LoadBalancing (MyCloud)" on the server side. That means we distribute rooms across several "Game Server" machines (or processes if you run all on one machine).

1) You get the room list on the Master Server. The Game Servers don't know each other and we don't sync the room list across them.
We don't track users, except for "Find Friends". This operation (again) is only available on the Master Server to keep syncing low.
This can be modified when running your own servers. It's a trade-off between "more info available" and "less stuff gets synced or outdated".

2) Right. Lobbies are distinct and separated. Each room "belongs" to one lobby (there's a default lobby, too). In best case, rooms get closed or at least set to "invisible".
Sending thousands of rooms to a client is likely to be overkill.

Your idea to get 50 rooms is "traditional" for picking a host. Most likely your players will just pick the top 10 rooms and ignore the rest of the list. This creates a "race" for these rooms, they get filled and users get rejected. They have to pick another room out of 50. Again, they compete for the free spots with others.

If you customize the list per player, you do quite a lot of work on the server.

We think it's better to use room properties and server-side "random" matchmaking with filters. This way, the server fills up the rooms quickly but players will be able to join a room with "map X" or "mode Y" or both.

Nice side-effect (as you host yourself): Less Bandwidth usage. This is going to be a big cost factor when your servers are full. We have terabytes of data each month, despite avoiding to send lists per player.