Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Question Can players be rematched into a game they were in before?

Discussion in 'Matchmaker' started by RyanALandmark, Jun 30, 2023.

  1. RyanALandmark

    RyanALandmark

    Joined:
    Aug 22, 2022
    Posts:
    2
    I am currently prototyping a game using Netcode for GO, Game Server Hosting and Matchmaker. Currently I have all these systems working nicely together, and have set it up so that when a game is started, backfill is used to allow players to continue joining the game while it is running. This all works fine.

    The issue I have is that once a player has been matched into a game, joins it, and then leaves it, they can no longer get matched back into that same game. I am removing the player from the backfill ticket when they disconnect, but this still doesn't seem to allow this. In the case where I am only allowing 1 server to be active at a time, after a player has left the running game, matchmaking then fails for them when they use it again, presumably because they are not being matched into that previous game, and matchmaker cannot allocate any more servers. Other players however can still join that running game.

    Is this just a limitation of matchmaker? Or is there something I'm not doing to allow players to be rematched into a previous game?
     
  2. guillaumedUnity

    guillaumedUnity

    Unity Technologies

    Joined:
    Apr 1, 2021
    Posts:
    36
    Be sure to set a a min number of players equals to the max number of players and then relax that number after a few seconds. This will ensure that Matchmaker will not try to create a new server for that player and instead get backfilled.
    Also make sure you have the latest Multiplay SDK.
     
  3. jackward84

    jackward84

    Joined:
    Jan 26, 2017
    Posts:
    87
    Players cannot be allocated via matchmaker to a match that they are already on the backfill ticket for.

    If you follow the example code in the multiplay sample on Github, it does this:

    * Server is allocated and the matchmaking ticket is read from the allocation payload
    * Backfill ticket is created right away using the data from the allocation, this includes putting the original players from the queue into the backfill even though they haven't joined yet.

    So now, if player with ID 1 was assigned into server with ID 1, but they never actually connect to the server, but instead start another matchmaking ticket, you begin to have a problem. Player with ID 1 is already on the backfill ticket for server 1 and as a result, the matchmaker won't assign that player into the existing match. Instead, it will create an entirely new allocation for that player. If the player does something like:

    * Queue in matchmaker
    * Queue pops
    * Cancel
    * Queue in matchmaker
    * Queue pops
    * Cancel
    * Repeat

    Now you have a major problem because player ID 1 is on the backfill ticket for many servers, and will continually spin up new servers until you remove them from the existing backfill tickets. The Unity example does not handle this situation at all - there is no timeout on a player joining and they will stay on the backfill tickets indefinitely until the server is deallocated. There isn't really any very graceful way to handle this that I can think of, outside of some kind of server-to-server model.

    The simplest and most obvious solution is to put a timeout on players not joining your match and scrub them off the backfill ticket after a certain number of seconds have elapsed. However this solution falls short in the fact that if the player spams matchmaking tickets, they will still allocate many servers (at least, in the case where only 1 player is needed to spin up a server).

    It may also be possible to just create the backfill ticket, but don't assign the playerID to it until they actually join the match (I have not yet tried this solution).

    I have posted about this issue several times but have not really gotten a satisfactory response, in terms of it being clear that UGS are aware of this problem or offering guidance on how it should be solved.