João Xavier avatar image
João Xavier asked

Problem with Matchmaking with TagFilter

I'm exploring the usage of TagFilter in the Matchmake request to filter out some game server instances which started under some conditions.

The tag is not immediately set when the game server instance starts, and not in every case.

My Matchmake request is as follows:

        Excludes: [
            {Data: {GameMode: "pvai"}}

It works fine in the scenarios where no game is created (it just creates a new game). For the 2nd player (or more), however, there are two scenarios:

- If I issue a matchmaking request after the first server has been tagged, I don't want both to be matched. It works fine, and a new game server instance is created for the second player;

- If I issue a matchmaking request *before* the first server has been tagged, the matchmaking service replies with a 500: Internal Server Error. Example response below:

"errorMessage":"An unexpected error occured while processing the request.",

I believe this is a bug?

The behavior I'm expecting is for the user to be matched with any existing game server instance that doesn't fulfil the criteria I've defined in excludes (and matches the BuildVersion, GameMode and Region).

If it helps, for traceability, the title where this happened was C6B9.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan answered

Can you help to clarify your scenario? The Tags cannot be set on a server instance when it starts, since you have to call SetGameServerInstanceTags to set them. When are you calling that, in your scenario?

Also, since you already are filtering on the actual game mode in the Matchmake call via the GameMode parameter, I'm not sure what your "GameMode" Tag is meant for - it seems potentially confusing to name a Tag the same way as a base match parameter, so I'd recommend changing that, to clarify what you're actually trying to search on (or exclude).

Also, there is no statistic "mmr" defined in that Title ID ( I can't really predict what the results would be for using the call with a statistic that doesn't actually exist, so I'd also recommend changing to use one that has been created in your title.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

João Xavier avatar image
João Xavier answered

Sure. We have a game mode of minimum and maximum 2 players.

However, when a 2nd player doesn't join after a while, we want to convert it into a game of 1 against the AI.

One option that we previously had was closing the game server instance, but since we want to allow reconnection with the same flow (client uses Matchmake call with an existing Lobby ID), I've seen it was not possible to reconnect to an ongoing game after the SetGameServerInstanceState was set to closed; the Matchmake service wouldn't allow.

So the workaround we were trying, was to tag a running gameserver instance (about after ~10 seconds) it has been running, and have the matchmaker filter those instances through the client's Matchmake call.

I didn't really understand the part where we cannot set the tags on a game server after it starts. Is it specified on the documentation? If so, how can we even set them before it starts, since its creating is triggered by the Matchmake call.

In the end, our desired behavior would be to be able to connect directly to an ongoing game as long as we have the Lobby ID for it through the Matchmake call, regardless of whether it has been set to closed or not.

I've had the game server tagging "Running": "true" instead to dispel potential issues with name collision, and the client now calls:


Also without the statistic. However, we get exactly the same error as described above, a 500 Internal Server Error when the Matchmake attempts to match 2 players in the same game before any tag has even been set at all.
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan answered

Correct - the purpose of the Server Instance State is to allow you to remove that server from matchmaking. This serves multiple purposes: One is to allow you to close a server to new players after a game session starts. Another is so that you can start server instances for specific groups (we have games that spawn "instance dungeons" for player parties, and they use closed servers for that). So, the "city" server starts the "dungeon" server (using the Matchmaker API), telling it the PlayFab IDs of users that are allowed to join, then sends the connection information to the players who will be playing in it, so that they can join it. So in the former case, you're setting it to closed at some point after it starts, while in the latter you're starting the server closed. In either case, the server could set itself to be open to matchmaking later, if you want to do that.

I should point out that we also don't return any server that hasn't reached the "Running" state (as shown in the Game Manager) from a matchmaking call. But if your server has a lot of things it has to do after the executable starts (which is what we consider the "Running" state), it may be worth adding a tag for this. However, one question - why is your logic to exclude a server which you've tagged as "Running"? Does "Running" in your tagging logic refer to a server which is now running a session, and so players cannot join? If so, I'd just use the instance state for that.

But yes, you can set tags after the server starts - sorry if my statement above was confusing. What I said was that you cannot set tags on a server until it has started. So if you want the server to always have the right tags, so that your matchmaking works exactly how you need it, you should start the server in the closed state (you set this in the Game Mode configuration), and only set it to open after you set the tags.

If you choose to do that, the one caution I would give is that this should not be your only Game Mode. Otherwise, if you have a bunch of players all trying to join games in a short period, you could wind up consuming many server instance slots unnecessarily, when all your current instances are at capacity. The same is true of your tagging. If you're looking for specific tags, and you have no servers running with that tag, you're going to try to spin up a new server instance.

The most common cause of the 500 error on matchmaking is when you're at capacity on your running server host(s) and need to start a new server to support more instances. That shouldn't be the case here, since you've set the max instances to 100. But can you tell me specifically when you got this error when you weren't specifying the "mmr" statistic? We log all 500 errors, and all the most recent ones I'm seeing for your title had that statistic in the Matchmake call.

For "reconnection" to a server, I would just keep the info on all players who legitimately joined, so that they can reconnect later, if you want to allow that. The client could then keep the info on any server it joined previously and reconnect to it, since the IP/Port won't have changed.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

João Xavier avatar image
João Xavier answered

Thank you for your help Brendan.

I forgot to say, that happened in another testing server (21FE) if you are interested to look at the logs of that.

In the end I followed your suggestion of relaxing the validation on a reconnection. This way I could just set the game server instance state to closed, and bypass the matchmaker on the case of a reconnection.

For every player we were requesting he would provide the Matchmaker Ticket and the Lobby ID.

Since we were storing their authenticated PlayFab ID anyway, a reconnecting user providing just the Lobby ID and his PlayFab ID is just as valid. I guess requesting a valid Matchmaking ticket per reconnection was overkill for this solution.

Thanks again!

1 comment
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image brendan ♦♦ commented ·

I can certainly have a look - which session was it (Lobby ID)?

But yes, the matchmaker ticket expires after two minutes, so trying to re-use it for re-connection is likely to be problematic.

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.