Better understanding how automatic backfill works

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:

• Use short lived, in memory credentials that aren't accessible to the player
• Have a UI 'cool-downs' or similar that prevent the player spamming matchmaking tickets (ie they can only have one request in flight at a time).
• Or call a back end service to make requests (https://aws.amazon.com/blogs/gametech/fitting-the-pattern-serverless-custom-matchmaking-with-amazon-gamelift/) which limits player requests etc.

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.

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.