Design a FlexMatch large-match rule set

If your rule set creates matches that allow 41 to 200 players, you need to make some adjustments to your rule set configuration. These adjustments optimize the match algorithm so that it can build viable large matches while also keeping player wait times short. As a result, large match rule sets replace time-consuming custom rules with standard solutions that are optimized for common matchmaking priorities.

Here's how to determine if you need to optimize your rule set for large matches:

1. For each team defined in your rule set, get the value of maxPlayer,

2. Add up all the maxPlayer values. If the total exceeds 40, you've got a large match rule set.

To optimize your rule set for large matches, make the adjustments described as follows. See the schema for a large match rule set in Rule set schema for large matches and rule set examples in Example 7: Create a large match.

Customize match algorithm for large matches

Add an algorithm component to the rule set, if one doesn't already exist. Set the following properties.

• strategy (required) – Set the strategy property to “balanced”. This setting triggers FlexMatch to do additional post-match checks to find the optimal team balance based on a specified player attribute, which is defined in the balancedAttribute property. The balanced strategy replaces the need for custom rules to build evenly matched teams.

• balancedAttribute (required) – Identify a player attribute to use when balancing the teams in a match. This attribute must have a numerical data type (double or integer). For example, if you choose to balance on player skill, FlexMatch tries to assign players so that all teams have aggregate skill levels that are as evenly matched as possible. The balancing attribute must be declared in the rule set's player attributes.

• batchingPreference (optional) – Choose how much emphasis you want to put on forming the lowest latency matches possible for your players. This setting affects how match tickets are sorted prior to building matches. Options include:

  • Largest population. FlexMatch allows matches using all tickets in the pool that have acceptable latency values in at least one location in common. As a result, the potential ticket pool tends to be large, which makes it easier to fill matches more quickly. Players might be placed in games with acceptable, but not always optimal, latency. If the batchingPreference property isn't set, this is the default behavior when strategy is set to "balanced".

  • Fastest location. FlexMatch pre-sorts all tickets in the pool based on where they report the lowest latency values. As a result, matches tend to be formed with players that report low latency in the same locations. At the same time, the potential ticket pool for each match is smaller, which can increase the time needed to fill a match. In addition, because a higher priority is placed on latency, players in matches may vary more widely with regard to the balancing attribute.

The following example configures the match algorithm to behave as follows: (1) Pre-sort the ticket pool to group tickets by location where they have acceptable latency values; (2) Form batches of sorted tickets for matching; (3) Create matches with tickets in a batch and balance the teams to even out the average player skill.

"algorithm": {
    "strategy": "balanced",
    "balancedAttribute": "player_skill",
    "batchingPreference": "largestPopulation"
},

Declare player attributes

Make sure that you declare the player attribute that is used as a balancing attribute in the rule set algorithm. This attribute should be included for each player in a matchmaking request. You can provide a default value for the player attribute, but attribute balancing works best when player-specific values are provided.

Define teams

The process of defining team size and structure is the same as with small matches, but the way FlexMatch fills the teams is different. This affects how matches are likely to look like when only partially filled. You may want to adjust your minimum team sizes in response.

FlexMatch uses the following rules when assigning a player to a team. First: look for teams that haven't yet reached their minimum player requirement. Second: of those teams, find the one with the most open slots.

For matches that define multiple equally sized teams, players are added sequentially to each team until full. As a result, teams in a match always have a nearly equal number of players, even when the match is not full. There is currently no way to force equally sized teams in large matches. For matches with asymmetrically sized teams, the process is a bit more complex. In this scenario, players are initially assigned to the largest teams that have the most open slots. As the number of open slots become more evenly distributed across all teams, players are slotted into the smaller teams.

For example, let's say you have a rule set with three teams. The Red and Blue teams are both set to maxPlayers=10, minPlayers=5. The Green team is set to maxPlayers=3, minPlayers=2. Here's the fill sequence:

1. No team has reached minPlayers. Red and Blue teams have 10 open slots, while Green has 3. The first 10 players are assigned (5 each) to the Red and Blue teams. Both teams have now reached minPlayers.

2. Green team has not yet reached minPlayers. The next 2 players are assigned to the Green team. The Green team has now reached minPlayers.

3. With all teams at minPlayers, additional players are now assigned based on the number of open slots. The Red and Blue teams each have 5 open slots, while the Green team has 1. The next 8 players are assigned (4 each) to the Red and Blue teams. All teams now have 1 open slot.

4. The remaining 3 player slots are assigned (1 each) to teams in no particular order.

Set rules for large matches

Matchmaking for large matches relies primarily on the balancing strategy and latency batching optimizations. Most custom rules are not available. However, you can incorporate the following types of rules:

• Rule that sets a hard limit on player latency. Use the latency rule type with the property maxLatency. See Latency rule reference. Here's an example that sets maximum player latency to 200 milliseconds:

  "rules": [{
          "name": "player-latency",
          "type": "latency",
          "maxLatency": 200
      }],

• Rule to batch players based on closeness in a specified player attribute. This is different than defining a balancing attribute as part of the large-match algorithm, which focuses on building evenly matched teams. This rule batches matchmaking tickets based on similarity in the specified attribute values, such as beginner or expert skill, which tends to lead to matches players who are closely aligned on the specified attribute. Use the batchDistance rule type, identify a numerically-based attribute, and specify the widest range to allow. See Batch distance rule reference. Here's an example that calls for a match's players to be within one skill level of each other:

  "rules": [{
          "name": "batch-skill",
          "type": "batchDistance",
          "batchAttribute": "skill",
          "maxDistance": 1

Relax large match requirements

As with small matches, you can use expansions to relax match requirements over time when no valid matches are possible. With large matches, you have the option to relax either the latency rules or the team player counts.

If you're using automatic match backfill for large matches, avoid relaxing your team player counts too quickly. FlexMatch starts generating backfill requests only after a game session starts, which may not happen for several seconds after a match is created. During that time, FlexMatch can create multiple partially filled new game sessions, especially when the player count rules are lowered. As a result, you end up with more game sessions than you need and players spread too thinly across them. Best practice is to give the first step in your player count expansion a longer wait time, long enough for your game session to start. Since backfill requests are given higher priority with large matches, incoming players will be slotted into existing games before new game are started. You may need to experiment to find the ideal wait time for your game.

Here's an example that gradually lowers the Yellow team's player count, with a longer initial wait time. Keep in mind that wait times in rule set expansions are absolute, not compounded. So the first expansion occurs at five seconds, and the second expansion occurs five seconds later, at ten seconds.

"expansions": [{
        "target": "teams[Yellow].minPlayers",
        "steps": [{
            "waitTimeSeconds": 5,
            "value": 8
        }, {
            "waitTimeSeconds": 10,
            "value": 5
        }]
    }]