I specifically need the user that I specify to be the creator of the matchmaking match, so that that person is identified in the game as the 'host' - there's narrative around this. I do not see how to make it so that one player creates a ticket and the rest can join. It seems that all players create tickets, and Playfab assigns one to be the creator of the match once they've been matched, but it seems random in testing. How could I achieve this?
Another thing is that this will need to be in place to prevent hosts from matching with hosts.
One idea I have is to make it so there is a match total rule, and set that to host = 1. All "hosts" will have a value there, guests will have 0, and hopefully that will prevent hosts from matching with hosts. But, I still need to specify the resulting match creator.
I believe you’d want to implement the “Multiple user ticket matchmaking” scenario described in this section: https://docs.microsoft.com/en-us/gaming/playfab/features/multiplayer/matchmaking/quickstart#multiple-user-ticket-matchmaking, where the creator creates a matchmaking ticket using CreateMatchmakingTicket and other members then calls JoinMatchmakingTicket to join the creator’s ticket. If that’s not the case for you, please let me know.
I found this example and it's what I was describing:
The other way I've tried that also works is to use CloudScript to do a CreateServerBackfillTicket. I use the ipv4 property to send the photon room name in ServerDetails.
The reason the serverbackfillticket is better is because there is some data that can be attached to the ticket, as opposed to just attributes (I have to create an attribute for the photon room name in the normal ticket, then search through the members of a ticket on GetMatch() to find the "isHost ==1" and THEN read the roomName attribute.) Three steps instead of one. If tickets could be configured in a queue to have attributes beforehand, that are written by a rule, it would save a few steps.
One thing to note is that CreateServerBackfillTicket is mainly used for searching additional players in a already running match though.
I see that is how it's designed, but regardless of that design, it is the only way to attach persistent data to a *ticket* and not attributes, which is FAR more convenient. If I could attach some persistent data to a regular CreateMatchmakingTicket, it would be the best of all worlds.
2 People are following this question.
