Get Room List...While *IN* a room

Per testing and your comment above "GetRoomList"...
/// Gets an array of (currently) known rooms as RoomInfo.
/// This list is automatically updated every few seconds while this client is in the lobby (on the Master Server).
/// Not available while being in a room.

it does just that. However, I'd like to be able to get that functionality so that I can have a virtual lobby (i.e instantiate avatars and also get a rooms list)...is there an easy work around for this~?

Comments

  • You have 2 options for this:
    a) If you are using Photon Server and not Photon Cloud, then you could modify the game server code to request that list from the master server
    b) You could create 2 peer instances in your client. The main instance would actually join the game rooms, while the second instance would stay in the lobby on the master server and just be responsible for receiving the game list updates. The downside of this approach is, that each connected peer counts as one CCU.
  • I am using the cloud so 2 CCU a pop seems some what harsh. Knowing the code base, as a Client Engineer, could you inform me as to what actually stops the service from continuing to poll (i.e is it just the `insideLobby` bool?)
  • The client does not poll the server for these updates. The master server automatically sends out these updates to every client, that is in the lobby. The clients can control this by just not joining the lobby, if the don't wish to receive this information, so that they can avoid unneeded traffic.

    The game servers do not have the needed information available, so they can't send it to the clients. Therefor it is simply technically impossible for the clients to receive these information without being connected to the master server, at least as long as one does not modify the game server code to request this info from the master (and modifying server side code, isn't currently supported on the cloud (we plan to make server side code modifications available on the cloud in the future, but these will be sandboxed, so that bugs in such modifications can't affect other games and I doubt that this kind of change will be possible from within the sandbox)).

    One other option, that comes to my mind, is: Run your own self hosted Photon server and run a Photon client, that is conneted to the cloud, on that server. That client would stay in the lobby all the time and your clients could then request the game lists from from that Photon server. That way the second peer instances of the normal clients would connect to that self hosted server and won't count as CCU on the cloud - there would just be one single additional CCU overall for that single client that runs on the self hosted Photon server.
  • One further question: although I've connected via photon network, am I able to get the room list by calling unity's Network.poll for host list?

    Sorry for the continued questions, we've recently decided we wanted to go the virtual lobby path before we do our first release in November. If we're unable to accomplish this with photon, I'm sad to say we'll have to rip it out for the core networking from unity. I don't feel this issue warrants big architecture changes. The cloud seemed like a great scalable solution while we got feedback on actual numbers but this little dent seems to be quite the derailer.
  • Kaiserludi wrote:
    You have 2 options for this:
    a) If you are using Photon Server and not Photon Cloud, then you could modify the game server code to request that list from the master server

    May i get a rough idea on where in the code should i look at to achieve this? What i found is that once a client connects to the room, it cannot communicate with the server.
  • You could pretend that your Game Server is simply another client. Modify the OutgoingGameServerPeer: add a call to "JoinLobby" (similar to the "Register" call), and modify it's OnEvent method to handle the game list update events that it receives from the master (e.g.: put them into a cache).

    Then make sure that your "real" clients can access that cached data: either add a "GetRoomList" operation to the GameClientPeer, so that your clients can poll for that information, or schedule a method that broadcasts the data to all connected clients in certain intervals.
  • You could pretend that your Game Server is simply another client. Modify the OutgoingGameServerPeer: add a call to "JoinLobby" (similar to the "Register" call), and modify it's OnEvent method to handle the game list update events that it receives from the master (e.g.: put them into a cache).

    Then make sure that your "real" clients can access that cached data: either add a "GetRoomList" operation to the GameClientPeer, so that your clients can poll for that information, or schedule a method that broadcasts the data to all connected clients in certain intervals.


    Possible using the cloud or would that be server only?
  • OnResolve wrote:
    You could pretend that your Game Server is simply another client. Modify the OutgoingGameServerPeer: add a call to "JoinLobby" (similar to the "Register" call), and modify it's OnEvent method to handle the game list update events that it receives from the master (e.g.: put them into a cache).

    Then make sure that your "real" clients can access that cached data: either add a "GetRoomList" operation to the GameClientPeer, so that your clients can poll for that information, or schedule a method that broadcasts the data to all connected clients in certain intervals.


    Possible using the cloud or would that be server only?

    definitely your own custom server only. its really easy to set up photon on amazon cloud actually.
  • OnResolve:
    The Photon Cloud only runs a fixed feature set. To sync the room lists while in a room, you would have to host the servers yourself.

    The reason why we don't sync room lists with every server is scalability. We run a lot of servers for the actual games and those only communicate with a master server. In turn, to distribute players across the game servers, they have to disconnect the game servers from time to time, to be matched again by the master (probably ending up somewhere else). Not having to sync room lists reduces traffic and makes it a lot more manageable to enforce player limits on join (rooms can be full) and room states for matchmaking.

    Why you need the room list in a room? What's the workflow you want to achieve?
  • I tried to modify the master server to do the matchmaking and create a room when a match is made, then send to the players to join the room. However, all the clients fail at joining the room. May I know what did I miss out to do?
  • I managed to get the system working =)
  • squirr3l could you tell me how you did it?
    I want to create a new room while in room and get 2 players into a new room.
  • how do u want the 2 new players to join? the server decides?

    On client: look at op code create, u could create a new op code and tell the server to inform the 2 other client to join the new game based on the new op code

    On server: modify to include the new op code. copy the server create game op code, additionally send response to the other 2 peers(use their name to get their peer reference) to join the new game name.
  • Why you need the room list in a room? What's the workflow you want to achieve?

    I want a virtual lobby.

    Desired Workflow:
    PlayerA logins and and they have an avatar in a scene with all the other players. PlayerA initiates a game from within the lobby. PlayerB logins in and is in the lobby. After a while they look for an existing game, sees PlayerA's game and joins.

    I tried to use the actual lobby, but PhotonNetwork.Instantiate gives odd view Id's like -999 and no updates to the view appear to be working.
  • So you want the players to be able to chat and hang out before they actually try to find any match (or create one)?
    In the Photon Lobby, we only list rooms. You can't actually use it to instantiate or communicate in it, cause we muted it.
    We usually assume people want to meet others to play. The flow for this is: Get them into a room asap, where they could chat while waiting for others or they could start the game early. This is easily achieved if everyone joins a random game immediately after connect. Or if none is available: Create a room and wait in it or others to find you. Chat and everything is possible and when enough players are there, they just play.
  • There are other reasons why it'd be desirable to be able to query a room list whilst inside a room. Such as making a matchmaking system that uses player ratings to match players up, and is robust enough to work with any load of players.
    When a player is in a room they initially want a player with a very similar rank to them. But as time ticks by the acceptable variance in ratings increases, because you don't want to wait forever.
    But here is a problem case when using Photon Cloud. Two players choose to play at roughly the same time. Their ratings differ more than the starting acceptable rating variance so they end up in different rooms. But no other players happen to be online at this time so they wait a little while and the matchmaking algorithm is becoming more and more accepting of other players rating difference. It's not long before the players ought to be matched with anyone, and so they should be matched together immediately so the game can begin. But there's no way that either of these player cases can know about the other player waiting, because whilst in a room the room list can not be retrieved from the master server.

    We're tied into using PhotonCloud, at least for now. So the solution I'm interested in is the 2nd clientside peer that connects to the lobby whilst the first peer is inside a room. I'm not entirely sure how to get this working though. I've created the following script, but the networkingPeer object is forever in the "Connecting" state. Any help you can give me regarding implementing a second peer connection would be greatly appreciated.

    [code2=csharp]using UnityEngine;
    using System.Collections;
    using ExitGames.Client.Photon;

    public class MatchmakingPhotonConnecter : Photon.MonoBehaviour, IPhotonPeerListener {

    NetworkingPeer networkingPeer;

    void OnEnable () {

    networkingPeer = new NetworkingPeer(this, "matchmakingPeer", ConnectionProtocol.Tcp);
    networkingPeer.mAppVersion = PhotonNetwork.networkingPeer.mAppVersion;
    networkingPeer.MasterServerAddress = PhotonNetwork.networkingPeer.MasterServerAddress;
    networkingPeer.Connect(PhotonNetwork.ServerAddress, ParseServerSettings.PhotonId());
    }

    void OnGUI(){
    GUILayout.Box(networkingPeer.State.ToString());
    }

    #region Implementation of IPhotonPeerListener
    public void DebugReturn(DebugLevel level, string message)
    {
    if (level == DebugLevel.ERROR)
    {
    Debug.LogError(message);
    }
    else if (level == DebugLevel.WARNING)
    {
    Debug.LogWarning(message);
    }
    else if (level == DebugLevel.INFO && PhotonNetwork.logLevel >= PhotonLogLevel.Informational)
    {
    Debug.Log(message);
    }
    else if (level == DebugLevel.ALL && PhotonNetwork.logLevel == PhotonLogLevel.Full)
    {
    Debug.Log(message);
    }
    }

    public void OnOperationResponse(OperationResponse operationResponse)
    {
    Debug.Log(operationResponse.DebugMessage);
    }

    public void OnStatusChanged(StatusCode statusCode)
    {
    Debug.Log(statusCode.ToString());
    }

    public void OnEvent(EventData photonEvent)
    {
    Debug.Log(photonEvent.ToStringFull());
    }
    #endregion
    }[/code2]
  • @Matkins:
    Is there any reason, why you let your players already create a room, if they don't immediately find a match? Just lets them stay inside the lobby until the matchmaking is accepting an opponent. There is no advantage of being in a room, if there is no one else in that room anyway.
  • Fully avoiding the case that two players might miss each other by mere seconds is a tough one. Photon does not handle this case in the best way possible. But it's really a rare case and hopefully your game is more successful.
    We know for a fact: If we implement one matchmaking workflow, the very next game will require some other solution. Or an option. Or doesn't like the timing.
    This happened before, so we decided to turn things around. Your client implements the workflow. You can do more than one request get a random match. And we provide hints how busy your game is. Combined you can minimize issues.
    Example: The server tells you 10000 players are online in your game. Use our "SQL Lobby" for matchmaking and try to find a perfect match first. Try again in a few seconds. Try a more relaxed filter next. You will get a match within seconds or create a new one behind the scenes with your skill and let others do the search. Someone will find you when there are 10000 players.
    When there are 2 players, skip all skill matchmaking and just try to find any room. If it's not existing: Create it. Anyone who looks for a game will match, cause every client dynamically drops skill filters due to inactivity.

    This is possible out of the box. Granted: It does not solve the problem if 2 players miss each other but ... that's just 2 players.

    In worst case: We now got Photon Chat as well. You can have a chat group for those 2 players now, even if they are not in the same room. They could meet this way.
  • @ Kaiserludi
    Someone has to be in a room, there's no way to query lobby players right?
    I suppose we could make a system on our own data server to provide a list of logged in players, their ratings, and whether they're looking for a game. And then a unique room name code could be issued to the matching players. Is that what you're suggesting?
  • Valaren
    Valaren
    edited March 2020
    So there's still no solution to do that ?

    We have a multiplayer VR FPS that create a room when we join or create a squad so we can discuss with voice chat and see each other before joining a game. But doing so prevent us to update the room list and it's really annoying for the players.

    Is there a workaround for this ? It doesn't seem possible to create a second peer to do that.

    Sorry for digging out this topic, but I didn't wanted to create another one if there's no solution.

    Edit :

    We still use PUN 1