random matchmaking based on map type and player's class

Hello!

What would be the best approaches to implement:
1. random room joining (with filtering by "map type" - if user wants to play a specific game mode or on a specific map)?
2. random room joining (but with taking in account player properties (class, level))?

Did you think about some kind of such built-in functionality if this is not currently possible while being on photon cloud?

thanks,
Slav

Comments

  • It is possible. Answering out of my head now, looking up stuff tomorrow.

    I think JoinRandom already has a parameter "expected game properties". This works like a filter for room properties in the lobby.
    So, in PUN 1.9, you can set properties for rooms and define which of those will be known in the lobby.
    Say you have a prop "map" and it's value is some number, then you could set it per room and the filter would be a Hashtable that contains the required props and their values. Like so: JoinRandom(new Hashtable() {{"map", 1}})
  • Hello!

    I'm using the following code and my 2nd client still enters the room with 1st client in it although
    room's customProperties and expectedGameProperties don't match. Is there anything I'm doing wrong?

    thanks,
    Slav
    public static Hashtable GetDefaultRoomProps()
        {
                Hashtable customProps = new Hashtable();
                customProps["map"] = "angar";//on the 2nd client the value is "111angar", for example
                customProps["level"] = "1-5";   //on the 2nd client the value is different too
                return customProps;
        }
    
        string[] GetDefaultPropsToList()
        {
            string[] exposedProps = new string[2];
            exposedProps[0] = "map";
            exposedProps[1] = "level";
    
            return exposedProps;
        }
    
    PhotonNetwork.CreateRoom(roomName, true, true, 16, GetDefaultRoomProps(), GetDefaultPropsToList());
    
    networkingPeer.OpJoinRandom(MainMenu.GetDefaultRoomProps());
    
  • You should pass a hashtable with key-VALUE to OpJoinRandom. Now you're not filtering by value and all your rooms have map and level as properties (but different values maybe).
  • Tobias wrote:
    You should pass a hashtable with key-VALUE to OpJoinRandom. Now you're not filtering by value and all your rooms have map and level as properties (but different values maybe).

    Sorry, I don't get it completely yet.

    I have user1 with
    "level" = "1"
    and user2 with
    "level" = "2"

    and I wouldn't like them to get into the same room.

    What should I pass to OpJoinRandom exactly? :oops:

    thanks,
    Slav
  • I wrote it up there somewhere.
    Hashtable filter = new Hashtable() {{"map", 1}};
    networkingPeer.OpJoinRandom(filter);
    

    This should do it, if one room has "map" set to 1 and the other to 2.
    You can use 1 and 2 also like a string or use "de_dust" or whatever you like as map name. It should be short (to minimize traffic and keep speed up).
  • Unfortunately this doesn't work for me.

    Maybe it's because I have only one room online and OpJoinRandom() decides to join unmatching room because of that... instead of creating a new one?

    :(
  • OpJoinRandom will fail, if no room has fitting properties. Maybe you instantiate your rooms with those properties and never change them? It will match if your rooms and filters just use default hashtables...

    Which client are you using? As server you use the cloud?
  • Tobias wrote:
    OpJoinRandom will fail, if no room has fitting properties. Maybe you instantiate your rooms with those properties and never change them? It will match if your rooms and filters just use default hashtables...

    Which client are you using? As server you use the cloud?

    I'm using cloud and PUN 1.15.
    I tried passing different hashtables when creating a room and when joining it (on two different clients) - this doesn't seem to work for me.

    thanks,
    Slav
  • Did you extend JoinRandomRoom? I just found that PhotonNetwork.JoinRandomRoom has no parameters.
  • Oh, well!

    I've downloaded the 1.15 from the asset store into an empty project and I indeed get
    "joinrandom failed, client stays on masterserver: OperationResponse 225: ReturnCode: 32760 (No match found). Parameters: {}."

    So there's something wrong with my bigger project then!

    thanks for help! :)
  • I reupgraded my big project to PUN 1.15 and now everything works as expected :)
  • Good to read that. Thanks for the heads up.
    I probably should tell everyone to refresh the files they imported when there's trouble.
  • Hello again!

    What would be the best approach to store social network's IDs of players that are in a room? (can I change "room props to show in lobby" after the room has already been created? I could probably store a string with a concatenated list of IDs, then random join with "expected room props" won't work - but I'll be able to process PUN's room list, find rooms with player's friend and then join one of such rooms).

    ...I'm trying to figure out what would be the easiest way to put a player in a room with his friends via pressing only one button in the game ).

    I know that matchmaking queue is possible by creating a special room type, but I'm not sure how complex would it be to implement that. (do you happen to have any secret matchmaking technology or example? :) )

    thanks,
    Slav
  • do you happen to have any secret matchmaking technology or example?
    Hehe. Sadly, no.
    the easiest way to put a player in a room with his friends
    As user IDs are not supported, we don't have friend matchmaking either in Photon. It can be added with our server SDK but this in turn means you have to get into hosting.
    If you want to stay in the Photon Cloud, then the properties are the only way to do this. It's not a great way, however, as it will add a lot of IDs to be sent to each client in the lobby and whenever someone joins or leaves a room, the props will be sent around. This can overwhelm mobile clients with large counts of rooms.
    Random matchmaking also won't support this: The order of the IDs is not defined and we don't support searching in the filter parameters (would be a lot of extra work).

    One of the problems why we don't do friend matchmaking is that your friends lists can become really long and then it gets complex. Which game do you join, if your friends are in multiple ones, playing with friends you don't even know?

    You could implement such a service externally and use it from the client side. If you want to be visible for friends, set your game's name and your friends can join those rooms.
  • Thanks!

    Is it possible to change room's name on MasterClient's switch?

    Is it possible to do a random join by "expected game properties" with OR logic... ehhh... so player could join either a room with map="A" or a room with map="B"?
  • Is it possible to change room's name on MasterClient's switch?
    No. Room names are treated like IDs and never change.
    Then better use a property.
    Is it possible to do a random join by "expected game properties" with OR logic... ehhh... so player could join either a room with map="A" or a room with map="B"?
    There is no "or" logic. All values you pass in must be found. Any additional listed properties can have any value.

    Why would you match "a or b" at all? You could match "a" and if that fails match "b".
  • Tobias wrote:
    Why would you match "a or b" at all? You could match "a" and if that fails match "b".

    Oh, I didn't think about that :)
  • 8-)