Better understanding how automatic backfill works

I was able to play around with matchmaking and thought I would ask a few questions. For example, if I had a rule that on minimum, required two players to be in a game and on maximum four players to be in a game. I know that once two players find a match successfully, an auto backfill ticket is created. When this backfill ticket gets fulfilled after another two people join, if one of these 4 players leave, is there supposed to be another backfill ticket to replace the player who left? From what I have found, automatic backfill only gets fulfilled once.

Also, I have found that when a player leaves a game and tries joining a new match, the auto backfill ticket associated with the game session that the old player left gets cancelled. Why does this happen? Or is this not supposed to happen?

Thirdly, if a player leaves a game session with an open backfill matchmaking ticket, does the matchmaking ticket get updated with the information that a player left?

Lastly, has anyone come across this message associated with a backfill ticket and knows what it means?

The game session null was not found, or was in a state which wouldn’t accept new player sessions.

Thanks in advance once again.

Quick stab at your questions

  1. Automatic backfill currently only handles bringing players to your game. If players drop post FlexMatch, then automatic backfill doesn’t backfill the player. There are backlog items for FlexMatch to fix this on PlayerSessionTerminate etc as it makes certain game modes harder to support.

    • Also note that theres only ever one automatic backfill ticket in flight at a time.
  2. A player (identified by their player ID) can only be included in one active matchmaking request at a time. When you create a new request for a player, any active matchmaking tickets with the same player ID are automatically canceled.

  3. FlexMatch is not updated on players leaving a game session. See #1

  4. The game session null, means that theres no longer an active game session id associated (most likely terminated or crashed has been removed) or it could be full if you have max player limits or allowing players in manually.

Hopefully that helps a little.

1 Like

Thank you Pip, that was very helpful. If you don’t mind me asking a couple more questions, you said that there is only ever one automatic backfill ticket in flight at a time, does this mean that once a backfill ticket reaches one of these status:

  • MatchmakingSucceeded
  • MatchmakingTimedOut
  • MatchmakingCancelled
  • MatchmakingFailed

that automatic backfill is officially over? And please correct me if I am either missing or incorrectly included certain statuses. Also, can that be generally said about any matchmaking request?

Lastly, with regards to matchmaking tickets with statuses of PotentialMatchCreated, do these tickets ever get updated if let’s say the max number of game sessions is running, but one of the players in the PotentialMatchCreated ticket drops, will the ticket get updated or cancelled?

Sorry to bug you again, but another question did pop into my mind. You mentioned that a player can only be included in one active matchmaking request. Currently, I use the player’s username for the playerId field when creating a new matchmaking request. The reason for this was to prevent a user from spamming GameLift with a bunch of matchmaking requests as well as making it easier to assign wins and losses when a match ends. I saw a blog before that they used the uuid npm package for making the player id, so I am wondering if this and just adding the player’s username as additional data to the matchmaking request is a better approach? My only worry with this approach is that players can theoretically spam GameLift with matchmaking requests considering a new uuid will be generated randomly per each request. Of course, we can also do other things such as restricting players to one running client instance on one device per account, but I just want to make sure that this is a legitimate concern or if at this point I should just go with manual backfill instead.

player id is generally thought of as an opaque private piece of data known only internally to your game/server (ie player user name -> playerid).

Typically a game will:

I see, sorry for asking this but I just want to confirm, is it ok to use the player’s Cognito username for the player id in matchmaking requests then? I am technically doing all three practices that you are mentioning, and I have come to the realization that for my purposes, I may have to do backfill manually.

Also, do backfill tickets expire like regular matchmaking tickets in the sense that the request timeout value specified in the matchmaker configuration applies to backfill tickets the same way they do to regular matchmaking tickets? I have found oddly, that backfill tickets do not seem to expire the way regular matchmaking tickets do unless I did not see something or it works differently for manual vs automatic.

I can’t think of any particular reason against using cognito id as player id. I would ensure player can’t easily see/know it or if logged its an opaque id (rather than something that contains anything that identifies it as a cognito id - I remember they are typically REGION:GUID)

Backfill requests should be like any other FlexMatch request, the only difference is that they have pre-formed partial or full team(s). They should obey the same timeout rules

If you are talking automatic backfil, you may be seeing new requests but using the same ticket id (code may even retry with same ticket id on certain failures). So you may see the tickets ‘living longer’ due to reused ticket id (but these are effectively new requests). You should be able to see the ticket transition states to see this.

My recollection of automatic backfill may be a little hazy here, will try and do some digging for you.

1 Like

Hey Pip, just want to clarify this statement,

I would ensure player can’t easily see/know it or if logged its an opaque id (rather than something that contains anything that identifies it as a cognito id - I remember they are typically REGION:GUID)

I wasn’t necessarily referring to the cognito id, but rather the cognito username value. Since you said that the playerId should be opaque, would it better to use the cognito id rather than a player’s cognito username? Also, I’m not even sure what a cognito id is, excuse me for my ignorance. I know that users in Cognito have a sub value, is this what you meant by cognito id, but this does not have the REGION:GUID format? Or were you talking about cognito username this whole time, because I was confused when you mentioned REGION:GUID.

Also, if you have any other recommendations for what to use for the playerId field, please let me know. I think some kind of unique value tied to Cognito or a user’s account is good because it can prevent players from spamming matchmaking requests.