How does FlexMatch rule set with minPlayers expansions work?

Question

We are setting up a Gamelift FlexMatch rule set with expansion on minPlayers. What we want to achieve:
- at the beginning, minPlayers as 4
- give first step 30s to have more chance to group 4 players into the same match
- after 30s, minPlayers are gradually reduced

We have defined the following rule set with expansions.
```
{
    "name": "FlexMatchRuleSet",
    "ruleLanguageVersion": "1.0",

"playerAttributes": [{
        "name": "gameMode",
        "type": "string"
    }],

"teams": [{
        "name": "player",
        "minPlayers": 4,
        "maxPlayers": 4,
        "quantity": 1
    }],

"rules": [{
        "name": "SameGameMode",
        "description": "Only match players when they choose the same game mode",
        "type": "comparison",
        "operation": "=",
        "measurements": ["flatten(teams[*].players.attributes[gameMode])"]
    }],
    
    "expansions": [{
        "target": "teams[player].minPlayers",
        "steps": [{
            "waitTimeSeconds": 30,
            "value": 3
        },{
            "waitTimeSeconds": 40,
            "value": 2
        },{
            "waitTimeSeconds": 45,
            "value": 1
        }]
    }]
}
```

**What we expect:**
- At 0s, player1 start matchmaking
- At 10s, player2 start matchmaking
- player1 and player2 will be grouped into the same match

**Actual result:**
- At 0s, player1 start matchmaking
- At 10s, player2 start matchmaking
- At 45s, only player1 was grouped into a match
- At 55s, only player2 was grouped into another match

And we have an interesting finding. If we change the expansions as like it:
```
"expansions": [{
    "target": "teams[player].minPlayers",
    "steps": [{
        "waitTimeSeconds": 5,
        "value": 3
    },{
        "waitTimeSeconds": 15,
        "value": 2
    },{
        "waitTimeSeconds": 45,
        "value": 1
    }]
}]
```

**The actual results:**

**case 1)**
- At 0s, player1 start matchmaking
- At 10s, player2 start matchmaking
- At 35s, player1 and player2 were grouped into the same match

**case 2)**
- At 0s, player1 start matchmaking
- At 10s, player2 start matchmaking
- At 20s, player3 start matchmaking
- At 25s, player1, player2, player3 were grouped into the same match

**case 3)**
- At 0s, player1 start matchmaking
- At 10s, player2 start matchmaking
- At 21s, player3 start matchmaking
- At 25s, player1 and player2 were grouped into the same match
- At 66s, only player3 was grouped into a match

It looks like that the wait time refer to the difference of waitTimeSeconds between expansion steps.

The difference of waitTimeSeconds first 2 steps is 10.

So after player2 start matchmaking, it starts expansion and wait for 10s.

```
{
    "waitTimeSeconds": 5,
    "value": 3
},{
    "waitTimeSeconds": 15,
    "value": 2
}
```

We are not sure if our understanding is correct. We also tested expansions for "rules" that it works straight forward.

Is there any misconfiguration? Is it the expected behaviour?

Appreciated if someone can help and explain the logic behind!

ShashankJ_AWS · Answer

Hi!

Expansions are based on the age of the newest ticket in the potential match being formed. If you want expansions to happen based on the oldest ticket you'd have to use the `expansionAgeSelection` attribute.

For the first rule set:
1. At 45s, a match with `player1` and `player2` is evaluated. Since expansion is based on the age of the newest ticket which is 35s, the `minPlayers` allowed is 2 and a mach cannot be formed.
2. At 45s, a match with `player1` is also evaluated. Since expansion is now based on the age of the newest ticket in the potential match, the `minPlayers` allowed is 1, and a match is formed. 
3. At 55s, a match with `player2` is evaluated and formed. The reasoning being similar to the previous step.

If the requirement is to prioritize matches of higher size, it would be better to wait for longer before applying the expansion. You could alternatively base the expansion on the oldest ticket in the potential match formed, which would guarantee the behavior you are expecting. In this case FlexMatch applies expansions faster, which improves wait times for the earliest matched players, but could potentially lower the match quality for all players (in case there are other attributes outside of team size you are looking at).

This should help explain the behavior for the 3 further cases listed.  For any match that is concerned the expansion is evaluated based on the age of the newest (or oldest ticket based on `expansionAgeSelection`) ticket in the match. So after `player2` has been added, any match which includes `player2` will have expansion evaluated based on the age of that ticket.

Please let us know if you have any other questions. Thanks!

How does FlexMatch rule set with minPlayers expansions work?

Relevant content