Questions about matchmaking (cant find it in the docs)

Hello all! I have a couple quick questions about the Room-related functions in PUN. I didn't see them on so I was hoping to get some answers or links.

Basically everything I need to know now revolves around how Rooms can be filtered/returned. I'm making an mmo-style game, mainly with instanced zones. For the 'hub' area, I want to spawn new Rooms when the current ones are all full (maxPlayers is set to 20 as of now). So my pseudocode would be like this:
foreach(RoomInfo r in GetRoomList())
  if(isHubRoom( && r.playerCount < r.maxPlayers)
//add a check here to see if we didn't find any room. if so,
The isHubRoom and getNewHubName funcs will use a common stub with a timestamp to unique-ify it.

For actual gameplay rooms, the process is similar except I want to give players the option to name their room (with a check to prevent them from making it with a hub-name), along with visibility options for public vs private rooms.

From the link I put above, it seems that filtering only happens for JoinRandom. This could work for hub rooms (obviously I'll have to give them a property to distinguish), however I need at least a partial list for games. It would be most efficient to have an 'activity-id' property that I can filter on, showing the player just the games relative to what they want to do.

Now, questions!

Does GetRoomList have an upper limit of rooms it will return at once? If I have to manually search the full list it will be inefficient, but acceptable.

Is there any way to get filtered roominfo's, since players won't need to know all rooms at all times?

More generally, is there a different approach I should take that will work better with Photon's design, or am I mostly on the right track?

Is CreateRoom deprecated? Vis Studio is saying that in the intellitype function list, but once I get to entering params, none of the overloads say they are deprecated.

I've only done xbox360 net code before, and while it is similar, the differences are enough that I don't want to make lots of assumptions and dig myself into a hole ;)

Thanks a ton everyone!


  • Hi,

    GetRoomList returns list of all rooms existing and visible in currently joined lobby. This list is local. It created once on lobby join and updated regularly as something changes in lobby. But checking dynamic properties as maxPlayers may fail for you since updates are not instant. Use JoinRandomRoom with custom properties filter and different matchmaking modes to achieve result. If random JoinRandomRoom fails call CreateRoom with optional name. This is standard Photon approach. It's not quite clear why it does not work for your actual room list.

    CreateRoom has several deprecated overloads and 2 up-to-date:
    public static bool CreateRoom(string roomName)
    public static bool CreateRoom(string roomName, RoomOptions roomOptions, TypedLobby typedLobby)
  • Thank you for the reply, but I'm not sure it answered my most pressing questions. You said GetRoomList returns 'all' rooms - even if there are hundreds of them? I'm guessing there's a way for the server to only send the added/removed/changed rooms for bandwidth (like it does with lots of other things that need sync), but I want to make sure.

    As I said, I cannot use JoinRandomRoom, as I want my players to be able to select the room they enter - but with the caveat that they can only join rooms doing the same activity they are also doing (activity like story mission, pvp room, hub-town, etc). This is why filtering would help, but if I can rely on having all the rooms all the time it should be easy enough for me to do the filtering locally.

    So I guess where I'm at now is, I know that while in the lobby the room list is updated on the back-end every few seconds (IIRC from the docs). What I need to know is, after an update, am I guaranteed to have all the RoomInfo's the server knew about when the op was sent, or is it possible to get an incomplete/partial list, or any other limitation?

    Thanks again!
  • Hi callen.
    Yes, you have guessed correctly.
    The server initially on entering the lobby sends a roomlist event and afterwards for bandwidth reasons it will only send roomlistupdate events, which only contain changes like added and removed rooms and rooms, for which some properties have changed. However you could consider this an implementation detail as you don't have to deal about differences between these two event types yourself. The clients will automatically apply the update events to their local room lists.
    after an update, am I guaranteed to have all the RoomInfo's the server knew about when the op was sent
  • "after an update, am I guaranteed to have all the RoomInfo's the server knew about when the op was sent"
    At the moment, this is the case. With thousands of rooms, this becomes a problem so we think about changing this.

    A better approach would depend on what you want.
    We prefer NOT to show a room list at all. In most cases, this is useless. There is only one host (the Photon Cloud Region) and no "best ping server". You only list a lot of rooms with the same ping and almost no useful criteria to pick one.
    Better: Don't join the lobby. Use Op JoinRandomRoom and maybe use some filtering to select a room with some game type, map, duration or whatever. You can make up categories and filters any way you like.

    See "Not so Random Matchmaking" here: ... -and-lobby
  • Thank you so much everyone, I think I have enough info now.

    Tobias, my issue is that I'm not sure I want to get rid of player-facing rooms. For something like a versus mode this would be good, but not so much for co-op play. For example, someone looking for a group might see a player that he's enjoyed playing with before, in a room doing the same activity he wants to do (eg "quest #3"), and join it based on that. Maybe the player wants to only join a room with more than 3 people, or, conversely only a room with 1 or 2 people. Maybe a player sees one room called "L33Tskllz4LYFE" and decides that group name best fits his personality.

    I do see the merits of random, or somewhat-random, matchmaking (great for my hub-room issue, versus matchups, and other cases). However having direct access to a room list is required for the scenarios above (unless I'm missing something).

    Maybe in the future you could add something like PhotonNetwork.filterProperties, and after setting them the client only gets room updates matching the filter?

    But the way it works now will be just fine for me. Thanks again!
  • Thanks for the feedback. You have some points there.
    We are just so intent about the lists, cause we know how much performance and bandwidth they cost while their benefit is often not so great.

    You could use FindFriends to find games of players you played with recently. Just keep a short list of them, count how often you play with each of them and find them before matchmaking.
    As Photon doesn't have a full blown Friend list, there is no rule to include a few players you met recently in the lookup.