Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Construisez un FlexMatch ensemble de règles
Chaque FlexMatch le système de matchmaking doit avoir un ensemble de règles. L'ensemble de règles détermine les deux éléments clés d'une mise en relation : la structure et la taille de l'équipe, et le mode de regroupement des joueurs pour la meilleure expérience possible.
Par exemple, un ensemble de règles peut décrire une mise en relation comme suit : Créer une mise en relation avec deux équipes de 5 joueurs chacune, une équipe jouant le rôle du défenseur et l'autre celle de l'envahisseur. Une équipe peut avoir des joueurs novices et expérimentés, mais l'habileté moyenne des deux équipes doit se situer à moins de 10 points l'une de l'autre. Si aucune correspondance n'est trouvée après 30 secondes, assouplissez progressivement les exigences de compétence.
Les rubriques de cette section décrivent comment concevoir et créer un ensemble de règles de mise en relation. Lorsque vous créez un ensemble de règles, vous pouvez utiliser soit le Amazon GameLift Servers console ou AWS CLI.
**Topics**
+ [Concevoir un ensemble de FlexMatch règles](match-design-ruleset.md)
+ [Concevez un ensemble FlexMatch de règles de correspondance important](match-design-rulesets-large.md)
+ [Tutoriel : Créer un ensemble de règles de matchmaking](match-create-ruleset.md)
+ [FlexMatchexemples d'ensembles de règles](match-examples.md)
# Concevoir un ensemble de FlexMatch règles
Cette rubrique décrit la structure de base d'un ensemble de règles et explique comment créer un ensemble de règles pour les petits matchs comptant jusqu'à 40 joueurs. Un ensemble de règles de matchmaking fait deux choses : définir la structure et la taille de l'équipe d'un match et indiquer au système de matchmaking comment choisir les joueurs pour former le meilleur match possible.
Mais votre ensemble de règles de matchmaking peut faire plus. Par exemple, vous pouvez effectuer les actions suivantes :
+ Optimisez l'algorithme de matchmaking pour votre jeu.
+ Définissez des exigences de latence minimale pour les joueurs afin de protéger la qualité du jeu.
+ Assouplissez progressivement les exigences de l'équipe et les règles des matchs au fil du temps afin que tous les joueurs actifs puissent trouver un match acceptable quand ils le souhaitent.
+ Définissez le traitement des demandes de jumelage de groupe à l'aide de l'agrégation des parties.
+ Organisez de grands matchs de 40 joueurs ou plus. Pour plus d'informations sur la création d'allumettes de grande taille, consultez[Concevez un ensemble FlexMatch de règles de correspondance important](match-design-rulesets-large.md).
Lorsque vous créez un ensemble de règles de matchmaking, considérez les tâches facultatives et obligatoires suivantes :
+ [Décrire l'ensemble de règles (obligatoire)](match-rulesets-components-set.md)
+ [Personnalisez l'algorithme de correspondance](match-rulesets-components-algorithm.md)
+ [Déclarer les attributs des joueurs](match-rulesets-components-attributes.md)
+ [Définissez les équipes de match](match-rulesets-components-teams.md)
+ [Définissez des règles pour le jumelage des joueurs](match-rulesets-components-rules.md)
+ [Permettre aux exigences de s'assouplir au fil du temps](match-rulesets-components-expansion.md)
Vous pouvez créer votre ensemble de règles à l'aide de la Amazon GameLift Servers console ou de l'`[CreateMatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_CreateMatchmakingRuleSet.html)`opération.
# Décrire l'ensemble de règles (obligatoire)
Fournissez les détails relatifs à l'ensemble de règles.
+ *name* (facultatif) — Une étiquette descriptive pour votre usage personnel. Cette valeur n'est pas associée au nom de l'ensemble de règles que vous spécifiez lors de la création de l'ensemble de règles avecAmazon GameLift Servers.
+ *ruleLanguageVersion*— Version du langage d'expression de propriété utilisée pour créer des FlexMatch règles. La valeur doit être `1.0`.
# Personnalisez l'algorithme de correspondance
FlexMatchoptimise l'algorithme par défaut pour la plupart des jeux afin de permettre aux joueurs de participer à des matchs acceptables avec un temps d'attente minimal. Vous pouvez personnaliser l'algorithme et ajuster le matchmaking pour votre jeu.
Voici l'algorithme de FlexMatch matchmaking par défaut :
1. FlexMatchplace tous les tickets de matchmaking ouverts et les tickets de remplissage dans un pool de tickets.
1. FlexMatchregroupe de manière aléatoire les tickets du pool en un ou plusieurs lots. Au fur et à mesure que le pool de tickets augmente, FlexMatch forme des lots supplémentaires pour conserver une taille de lot optimale.
1. FlexMatchtrie les billets par âge, au sein de chaque lot.
1. FlexMatchcrée un match en fonction du ticket le plus ancien de chaque lot.
Pour personnaliser l'algorithme de correspondance, ajoutez un `algorithm` composant au schéma de votre ensemble de règles. Voir [FlexMatch schéma d'ensemble de règles](match-ruleset-schema.md) pour les informations de référence complètes.
Utilisez les personnalisations facultatives suivantes pour avoir un impact sur les différentes étapes de votre processus de matchmaking.
+ [Ajouter un tri avant le lot](#match-rulesets-components-algorithm-presort)
+ [Formez des lots basés sur les attributs BatchDistance](https://docs.aws.amazon.com//gameliftservers/latest/flexmatchguide/match-rules-reference-ruletype.html#match-rules-reference-ruletype-batchdistance)
+ [Prioriser les tickets de remblayage](#match-rulesets-components-algorithm-backfill)
+ [Privilégiez les anciens billets avec des extensions](#match-rulesets-components-algorithm-expansion)
## Ajouter un tri avant le lot
Vous pouvez trier le pool de tickets avant de former des lots. Ce type de personnalisation est particulièrement efficace pour les jeux comportant de gros pools de tickets. Le tri avant le lot peut aider à accélérer le processus de matchmaking et à augmenter l'uniformité des joueurs dans les caractéristiques définies.
Définissez les méthodes de tri avant le lot à l'aide de la propriété `batchingPreference` de l'algorithme. Le paramètre par défaut est `random`.
Les options de personnalisation du tri avant lot sont les suivantes :
+ **Trier par attributs du joueur.** Fournissez une liste des attributs des joueurs pour prétrier le pool de tickets.
Pour trier par attributs de joueur, définissez `batchingPreference` et définissez votre liste d'attributs de joueur dans`sortByAttributes`. `sorted` Pour utiliser un attribut, déclarez d'abord l'attribut dans le `playerAttributes` composant de l'ensemble de règles.
Dans l'exemple suivant, FlexMatch trie le pool de tickets en fonction de la carte de jeu préférée des joueurs, puis en fonction de leurs compétences. Les lots qui en résultent sont plus susceptibles de contenir des joueurs aux compétences similaires qui souhaitent utiliser la même carte.
```
"algorithm": {
"batchingPreference": "sorted",
"sortByAttributes": ["map", "player_skill"],
"strategy": "exhaustiveSearch"
},
```
+ **Triez par latence.** Créez des correspondances avec la latence disponible la plus faible ou créez rapidement des correspondances avec une latence acceptable. Cette personnalisation est utile pour les ensembles de règles formant de grands matchs de plus de 40 joueurs.
Définissez la propriété de l'algorithme `strategy` sur`balanced`. La stratégie équilibrée limite les types d'énoncés de règles disponibles. Pour de plus amples informations, veuillez consulter [Concevez un ensemble FlexMatch de règles de correspondance important](match-design-rulesets-large.md).
FlexMatchtrie les tickets en fonction des données de latence signalées par les joueurs de l'une des manières suivantes :
+ *Emplacements où la latence est la plus faible* Le pool de tickets est pré-trié en fonction des emplacements où les joueurs signalent leurs valeurs de latence les plus faibles. FlexMatchregroupe ensuite les tickets avec une faible latence aux mêmes endroits, créant ainsi une meilleure expérience de jeu. Cela réduit également le nombre de tickets dans chaque lot, donc le matchmaking peut prendre plus de temps. Pour utiliser cette personnalisation, définissez cette `batchingPreference` option sur`fastestRegion`, comme indiqué dans l'exemple suivant.
```
"algorithm": {
"batchingPreference": "fastestRegion",
"strategy": "balanced"
},
```
+ *La latence acceptable correspond rapidement.* Le pool de tickets est pré-trié en fonction des emplacements où les joueurs signalent une valeur de latence acceptable. Cela permet de réduire le nombre de lots contenant davantage de tickets. Avec un plus grand nombre de tickets par lot, il est plus rapide de trouver des correspondances acceptables. Pour utiliser cette personnalisation, définissez la propriété `batchingPreference` sur` largestPopulation`, comme indiqué dans l'exemple suivant.
```
"algorithm": {
"batchingPreference": "largestPopulation",
"strategy": "balanced"
},
```
**Note**
La valeur par défaut de la stratégie équilibrée est`largestPopulation`.
## Prioriser les tickets de remblayage
Si votre jeu implémente le remblayage automatique ou manuel, vous pouvez personnaliser le traitement des tickets de matchmaking FlexMatch en fonction du type de demande. Le type de demande peut être une nouvelle demande de correspondance ou de remplacement. Par défaut, FlexMatch traite les deux types de demandes de la même manière.
La priorisation du remblayage a un impact sur la façon dont FlexMatch les tickets sont gérés une fois qu'ils sont groupés. La priorisation du remblayage nécessite des ensembles de règles pour utiliser une stratégie de recherche exhaustive.
FlexMatchne correspond pas à plusieurs tickets de remblayage.
Pour modifier la priorité des tickets de remblayage, définissez la propriété. `backfillPriority`
+ **Faites d'abord correspondre les tickets de remblayage.** Cette option essaie de faire correspondre les tickets de remplacement avant de créer de nouveaux matchs. Cela signifie que les nouveaux joueurs ont plus de chances de rejoindre une partie existante.
Il est préférable de l'utiliser si votre jeu utilise le remplissage automatique. Le remblayage automatique est souvent utilisé dans les jeux où les sessions de jeu sont courtes et où le taux de rotation des joueurs est élevé. Le remplissage automatique permet à ces jeux de former un minimum de matchs viables et de les lancer tout en FlexMatch recherchant plus de joueurs pour occuper les places disponibles.
Définissez `backfillPriority` sur `high`.
```
"algorithm": {
"backfillPriority": "high",
"strategy": "exhaustiveSearch"
},
```
+ **Les tickets Match Backfill sont les derniers.** Cette option ignore les tickets de remblayage jusqu'à ce qu'elle évalue tous les autres tickets. Cela signifie que les joueurs FlexMatch entrants sont redirigés vers des jeux existants lorsqu'il n'est pas possible de les associer à de nouveaux jeux.
Cette option est utile lorsque vous souhaitez utiliser le remblayage comme option de dernière chance pour faire participer des joueurs à une partie, par exemple lorsqu'il n'y a pas assez de joueurs pour former un nouveau match.
Définissez `backfillPriority` sur `low`.
```
"algorithm": {
"backfillPriority": "low",
"strategy": "exhaustiveSearch"
},
```
## Privilégiez les anciens billets avec des extensions
Les règles d'extension assouplissent les critères de match lorsque les matchs sont difficiles à terminer. Amazon GameLift Serversapplique les règles d'extension lorsque les tickets d'un match partiellement terminé atteignent un certain âge. L'horodatage de création des tickets détermine le moment où les Amazon GameLift Servers règles sont appliquées ; par défaut, il FlexMatch suit l'horodatage du dernier ticket correspondant.
Pour modifier le moment où les règles d'extension FlexMatch s'appliquent, définissez la propriété `expansionAgeSelection` comme suit :
+ **Développez en fonction des nouveaux tickets.** Cette option applique les règles d'extension en fonction du ticket le plus récent ajouté au match potentiel. Chaque fois qu'un nouveau ticket FlexMatch correspond, l'horloge est réinitialisée. Avec cette option, les correspondances obtenues ont tendance à être de meilleure qualité, mais leur mise en correspondance prend plus de temps ; les demandes de correspondance peuvent expirer avant d'être terminées si elles mettent trop de temps à correspondre. `expansionAgeSelection`Réglé sur`newest`. `newest`est la valeur par défaut.
+ **Développez en fonction des tickets les plus anciens.** Cette option applique des règles d'extension basées sur le ticket le plus ancien du match potentiel. Cette option permet d'FlexMatchappliquer les extensions plus rapidement, ce qui améliore les temps d'attente pour les premiers joueurs, mais réduit la qualité des matchs pour tous les joueurs. Définissez `expansionAgeSelection` sur `oldest`.
```
"algorithm": {
"expansionAgeSelection": "oldest",
"strategy": "exhaustiveSearch"
},
```
# Déclarer les attributs des joueurs
Dans cette section, listez les attributs individuels des joueurs à inclure dans les demandes de matchmaking. Vous pouvez déclarer les attributs d'un joueur dans un ensemble de règles pour deux raisons :
+ Lorsque l'ensemble de règles contient des règles basées sur les attributs du joueur.
+ Lorsque vous souhaitez transmettre un attribut de joueur à la session de jeu par le biais de la demande de match. Par exemple, vous souhaiterez peut-être transmettre les choix de personnages des joueurs à la session de jeu avant que chaque joueur ne se connecte.
Lorsque vous déclarez un attribut de joueur, incluez les informations suivantes :
+ *nom* (obligatoire) — Cette valeur doit être unique pour l'ensemble de règles.
+ *type* (obligatoire) — Type de données de la valeur de l'attribut. Les types de données valides sont les suivants : nombre, chaîne, liste de chaînes ou table de chaînes.
+ *par défaut* (facultatif) — Entrez une valeur par défaut à utiliser si une demande de matchmaking ne fournit pas de valeur d'attribut. Si aucune valeur par défaut n'est déclarée et qu'une demande n'inclut aucune valeur, FlexMatch impossible de répondre à la demande.
# Définissez les équipes de match
Décrivez la structure et la taille des équipes pour une partie. Chaque partie doit être associée à au moins une équipe. Le nombre total d'équipes n'est pas limité. Vos équipes peuvent avoir le même nombre de joueurs ou être asymétriques. Par exemple, vous pouvez définir une équipe d'une seule personne pour jouer le monstre face à une équipe de 10 joueurs comme chasseurs.
FlexMatch traite les demandes de mise en relation selon que la partie implique un nombre de joueurs faible ou élevé, comme défini dans l'ensemble de règles. Les matchs potentiels réunissant jusqu'à 40 joueurs sont des petits matchs, les matchs avec plus de 40 joueurs sont des matchs de grande envergure. Pour déterminer la taille d'une partie potentielle dans un ensemble de règles, ajoutez les paramètres *maxPlayer* pour toutes les équipes définies dans cet ensemble de règles.
+ *nom* (obligatoire) — Attribuez un nom unique à chaque équipe. Vous utilisez ce nom dans les règles et les extensions, et les FlexMatch références pour les données de matchmaking dans une session de jeu.
+ *MaxPlayers* (obligatoire) — Spécifiez le nombre maximum de joueurs à affecter à l'équipe.
+ *MinPlayers* (obligatoire) — Spécifiez le nombre minimum de joueurs à affecter à l'équipe.
+ *quantité* (facultatif) — Spécifiez le nombre d'équipes à former avec cette définition. Lors de la FlexMatch création d'un match, il donne à ces équipes le nom fourni avec un numéro ajouté. Par exemple `Red-Team1``Red-Team2`, et`Red-Team3`.
FlexMatchtente de remplir les équipes jusqu'à la taille maximale de joueurs, mais crée des équipes avec moins de joueurs. Si vous souhaitez que toutes les équipes de la partie soient de taille égale, vous pouvez créer une règle à cette fin. Consultez la [FlexMatchexemples d'ensembles de règles](match-examples.md) rubrique pour un exemple de `EqualTeamSizes` règle.
# Définissez des règles pour le jumelage des joueurs
Créez un ensemble de règles qui évaluent l'acceptation des joueurs dans un match. Les règles peuvent définir des exigences qui s'appliquent aux joueurs individuels, à des équipes ou à une partie entière. Lorsque Amazon GameLift Servers traite une demande de mise en relation, il commence par le joueur qui est dans le pool de joueurs disponibles depuis le plus de temps et crée une partie en fonction de cette personne. Pour obtenir de l'aide détaillée sur la création de FlexMatch règles, consultez[FlexMatchtypes de règles](match-rules-reference-ruletype.md).
+ *nom* (obligatoire) : nom significatif qui identifie de manière unique la règle au sein d'un ensemble de règles. Les noms de règle sont également référencés dans les journaux des événements et les métriques qui suivent l'activité associée à cette règle.
+ *description* (facultatif) — Utilisez cet élément pour joindre une description sous forme de texte libre.
+ *type* (obligatoire) — L'élément type identifie l'opération à utiliser lors du traitement de la règle. Chaque type de règle nécessite un ensemble de propriétés supplémentaires. Pour consulter la liste des types de règles et des propriétés valides, voir [FlexMatch langage des règles](match-rules-reference.md).
+ Propriété du type de règle (peut être obligatoire) — Selon le type de règle défini, vous devrez peut-être définir certaines propriétés de règle. Pour en savoir plus sur les propriétés et sur l'utilisation du langage d'expression des propriétés FlexMatch, voir [FlexMatch langage des règles](match-rules-reference.md).
# Permettre aux exigences de s'assouplir au fil du temps
Les extensions vous permettent d'assouplir les critères des règles au fil du temps lorsque FlexMatch vous ne trouvez pas de correspondance. Cette fonctionnalité FlexMatch garantit la disponibilité d'un produit lorsqu'il ne peut pas être parfaitement adapté. En assouplissant vos règles à l'aide d'une extension, vous élargissez progressivement le pool de joueurs compatibles.
Les extensions commencent lorsque l'âge du ticket le plus récent d'un match incomplet correspond à un délai d'attente pour l'extension. Lors de l'FlexMatchajout d'un nouveau ticket au match, le temps d'attente pour l'extension peut être réinitialisé. Vous pouvez personnaliser le début des extensions dans la `algorithm` section de l'ensemble de règles.
Voici un exemple d'extension qui augmente progressivement le niveau de compétence minimum requis pour le match. L'ensemble de règles utilise une déclaration de règle de distance, nommée de *SkillDelta*manière à exiger que tous les joueurs d'un match aient moins de 5 niveaux de compétence les uns des autres. Si aucune nouvelle partie n'est créée pendant quinze secondes, cette extension recherche une différence de niveau de compétence de 10, puis dix secondes plus tard, une différence de 20.
```
"expansions": [{
"target": "rules[SkillDelta].maxDistance",
"steps": [{
"waitTimeSeconds": 15,
"value": 10
}, {
"waitTimeSeconds": 25,
"value": 20
}]
}]
```
Avec les matchmakers qui ont activé le remblayage automatique, n'assouplissez pas trop rapidement vos exigences en matière de nombre de joueurs. Quelques secondes peuvent être nécessaire pour que la nouvelle session de jeu démarre et commence le remplissage automatique. Une meilleure approche consiste à démarrer votre extension une fois que le remblayage automatique a tendance à se produire pour vos jeux. Le calendrier d'extension varie en fonction de la composition de votre équipe. Faites donc des tests pour trouver la meilleure stratégie d'extension pour votre jeu.
# Concevez un ensemble FlexMatch de règles de correspondance important
Si votre ensemble de règles crée des matchs qui accueillent de 41 à 200 joueurs, vous devez apporter quelques modifications à la configuration de votre ensemble de règles. Ces ajustements optimisent l'algorithme de match afin qu'il puisse créer de grands matchs viables tout en réduisant les temps d'attente des joueurs. Par conséquent, les grands ensembles de règles de match remplacent les règles personnalisées fastidieuses par des solutions standard optimisées pour les priorités de matchmaking courantes.
Voici comment déterminer si vous devez optimiser votre ensemble de règles pour les correspondances de grande taille :
1. Pour chaque équipe définie dans votre ensemble de règles, obtenez la valeur de *MaxPlayer*,
1. Additionnez toutes les valeurs de *MaxPlayer.* Si le total est supérieur à 40, vous disposez d'un ensemble de règles de correspondance important.
Pour optimiser votre ensemble de règles pour les grandes correspondances, effectuez les ajustements décrits ci-dessous. Consultez le schéma pour une règle de correspondance étendue définie dans [Schéma d'ensemble de règles pour les matchs de grande taille](match-ruleset-schema-large.md) et des exemples d'ensembles de règles dans[Exemple : créer une correspondance de grande taille](match-examples-7.md).
# Personnalisez l'algorithme de correspondance pour les grandes correspondances
Ajoutez un composant d'algorithme à l'ensemble de règles, s'il n'en existe pas déjà un. Définissez les propriétés suivantes.
+ `strategy`(obligatoire) — Définissez la `strategy` propriété sur « équilibré ». Ce paramètre déclenche FlexMatch des vérifications supplémentaires après le match afin de trouver l'équilibre optimal de l'équipe en fonction d'un attribut de joueur spécifié, défini dans la `balancedAttribute` propriété. La stratégie équilibrée remplace le besoin de règles personnalisées pour constituer des équipes égales.
+ `balancedAttribute`(obligatoire) — Identifiez un attribut de joueur à utiliser pour équilibrer les équipes lors d'un match. Cet attribut doit avoir un type de données numérique (double ou entier). Par exemple, si vous choisissez d'équilibrer les compétences des joueurs, essayez FlexMatch d'attribuer des joueurs de manière à ce que toutes les équipes aient des niveaux de compétence agrégés aussi égaux que possible. L'attribut d'équilibrage doit être déclaré dans les attributs du joueur de l'ensemble de règles.
+ `batchingPreference`(facultatif) — Choisissez dans quelle mesure vous souhaitez mettre l'accent sur la création de matchs avec le moins de latence possible pour vos joueurs. Ce paramètre affecte la manière dont les tickets de match sont triés avant la création des matchs. Voici les options :
+ La plus grande population. FlexMatchautorise les matchs en utilisant tous les tickets du pool présentant des valeurs de latence acceptables à au moins un endroit en commun. Par conséquent, le pool de tickets potentiel a tendance à être important, ce qui permet de remplir les matchs plus rapidement. Les joueurs peuvent être placés dans des jeux avec une latence acceptable, mais pas toujours optimale. Si la `batchingPreference` propriété n'est pas définie, il s'agit du comportement par défaut lorsqu'elle `strategy` est définie sur « équilibré ».
+ Emplacement le plus rapide. FlexMatchtrie à l'avance tous les tickets du pool en fonction de l'endroit où ils indiquent les valeurs de latence les plus faibles. Par conséquent, les matchs ont tendance à être organisés avec des joueurs qui signalent une faible latence aux mêmes endroits. Dans le même temps, le nombre de tickets potentiels pour chaque match est réduit, ce qui peut augmenter le temps nécessaire pour terminer un match. En outre, étant donné qu'une priorité plus élevée est accordée à la latence, les joueurs participant aux matchs peuvent varier davantage en ce qui concerne l'attribut d'équilibrage.
L'exemple suivant configure l'algorithme de match pour qu'il se comporte comme suit : (1) Pré-triez le pool de tickets pour regrouper les tickets par lieu où les valeurs de latence sont acceptables ; (2) Formez des lots de tickets triés pour les faire correspondre ; (3) Créez des matchs avec des tickets par lot et équilibrez les équipes pour égaliser les compétences moyennes des joueurs.
```
"algorithm": {
"strategy": "balanced",
"balancedAttribute": "player_skill",
"batchingPreference": "largestPopulation"
},
```
# Déclarer les attributs des joueurs
Assurez-vous de déclarer l'attribut de joueur utilisé comme attribut d'équilibrage dans l'algorithme d'ensemble de règles. Cet attribut doit être inclus pour chaque joueur dans une demande de matchmaking. Vous pouvez fournir une valeur par défaut pour l'attribut du joueur, mais l'équilibrage des attributs fonctionne mieux lorsque des valeurs spécifiques au joueur sont fournies.
# Définissez les équipes
Le processus de définition de la taille et de la structure des équipes est le même que pour les parties de petite envergure, mais la façon dont FlexMatch remplit les équipes est différente. Cela affecte l'apparence probable des correspondances lorsqu'elles ne sont que partiellement remplies. Vous souhaiterez peut-être ajuster la taille minimale de votre équipe en conséquence.
FlexMatch utilise les règles suivantes lors de l'affectation d'un joueur à une équipe. Premièrement, il recherche les équipes qui ne comptent pas encore le nombre minimal de joueurs requis. Deuxièmement, parmi ces équipes, il identifie celle qui a le moins de joueurs.
Pour les parties définissant des équipes de taille égale, les joueurs sont ajoutés de manière séquentielle pour chaque équipe jusqu'à ce qu’elles soient pleines. Par conséquent, les équipes d'un match ont toujours un nombre presque égal de joueurs, même lorsque le match n'est pas complet. Actuellement, il n'est pas possible d’imposer des équipes de taille égale dans les partie à grande échelle. Pour les parties dont les tailles d’équipes sont asymétriques, le processus est un peu plus complexe. Dans ce scénario, les joueurs sont initialement affectés aux plus grandes équipes qui ont le plus de places ouvertes. Au fur et à mesure que le nombre de places libres est réparti de manière plus uniforme entre toutes les équipes, les joueurs sont répartis dans les plus petites équipes.
Supposons, par exemple, que vous ayez un ensemble de règles composé de trois équipes. Les équipes rouge et bleue sont toutes deux réglées à `maxPlayers` =10, `minPlayers` =5. L'équipe verte est définie sur `maxPlayers` =3, `minPlayers` =2. Voici la séquence de remplissage :
1. Aucune équipe n'est arrivée`minPlayers`. Les équipes rouge et bleue ont 10 emplacements ouverts, tandis que l’équipe verte en compte 3. Les 10 premiers joueurs sont affectés aux équipes rouge et bleue, à hauteur de 5 joeurs par équipe. Les deux équipes ont désormais atteint le score`minPlayers`.
1. L'équipe verte n'est pas encore arrivée`minPlayers`. Les 2 prochains joueurs sont attribués à l'équipe verte. L'équipe verte est maintenant arrivée`minPlayers`.
1. Toutes les équipes étant réunies`minPlayers`, des joueurs supplémentaires sont désormais assignés en fonction du nombre de places disponibles. Les équipes rouge et bleue ont chacune 5 places libres, tandis que l'équipe verte en a une. Les 8 joueurs suivants sont affectés (4 chacun) aux équipes rouge et bleue. Toutes les équipes ont désormais 1 place libre.
1. Les 3 places restantes sont attribuées (1 chacune) aux équipes sans ordre particulier.
# Établissez des règles pour les matchs de grande envergure
Le matchmaking pour les matchs de grande envergure repose principalement sur la stratégie d'équilibrage et les optimisations du traitement par lots de latence. la plupart des règles personnalisées ne sont pas disponibles. Vous pouvez toutefois intégrer les types de règles suivants :
+ Règle qui fixe une limite stricte à la latence des joueurs. Utilisez le type de `latency` règle avec la propriété`maxLatency`. Voir la [Règle de latence](match-rules-reference-ruletype.md#match-rules-reference-ruletype-latency) référence. Voici un exemple qui définit une latence maximum de 200 millisecondes pour les joeurs :
```
"rules": [{
"name": "player-latency",
"type": "latency",
"maxLatency": 200
}],
```
+ Règle permettant de regrouper les joueurs en fonction de la proximité d'un attribut de joueur spécifié. Cela est différent de la définition d'un attribut d'équilibrage dans le cadre de l'algorithme des matchs importants, qui met l'accent sur la constitution d'équipes égales. Cette règle regroupe les tickets de matchmaking en fonction de la similitude des valeurs d'attribut spécifiées, telles que les compétences de débutant ou d'expert, ce qui a tendance à conduire à des matchs entre des joueurs étroitement alignés sur l'attribut spécifié. Utilisez le type de `batchDistance` règle, identifiez un attribut numérique et spécifiez la plage la plus large à autoriser. Voir la [Règle de distance par lots](match-rules-reference-ruletype.md#match-rules-reference-ruletype-batchdistance) référence. Voici un exemple qui demande aux joueurs d'un match de se situer à un niveau de compétence les uns des autres :
```
"rules": [{
"name": "batch-skill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 1
```
# Assoudez les exigences relatives aux gros matchs
Comme pour les parties de petite envergure, vous pouvez utiliser des extensions pour assouplir progressivement les exigences de mise en relation lorsqu’aucune partie ne correspond. Lors de matchs de grande envergure, vous avez la possibilité d'assouplir les règles de latence ou d'assouplir le nombre de joueurs de l'équipe.
Si vous utilisez le remplissage automatique des parties à grande échelle, patientez un peu avant d'assouplir le nombre de joueurs requis. FlexMatch ne commence à générer les demandes de remplissage qu’après le démarrage d’une session de jeu, ce qui peut ne pas se produire pendant plusieurs secondes après la création d’une partie. Parallèlement, FlexMatch permet de créer plusieurs sessions de jeu partiellement remplies, notamment lorsque les règles liées au nombre de joueurs sont abaissées. Dans ce cas, vous pouvez vous retrouver avec plus de sessions de jeu que nécessaire et une trop faible répartition des joueurs entre eux. Une bonne pratique consiste ici à attribuer à la première étape de l’extension du nombre de joueurs un délai d'attente suffisamment long pour que la session de jeu puisse démarrer. Dans la mesure où les demandes de remplissage sont prioritaires dans les parties à grande échelle, les joueurs entrants sont placés dans les jeux existants avant le démarrage de nouveaux jeux. Vous devrez peut-être effectuer plusieurs tests afin de déterminer le temps d'attente idéal pour votre jeu.
Voici un exemple qui réduit progressivement le nombre de joueurs de l'équipe jaune, avec un temps d'attente initial plus long. Gardez à l'esprit que les délais d'attente des extensions dans les ensembles de règles sont des valeurs absolues, et non composées. Par conséquent, la première extension se produit à cinq secondes, tandis que la seconde extension se produit cinq secondes plus tard, à savoir au bout de dix secondes.
```
"expansions": [{
"target": "teams[Yellow].minPlayers",
"steps": [{
"waitTimeSeconds": 5,
"value": 8
}, {
"waitTimeSeconds": 10,
"value": 5
}]
}]
```
# Tutoriel : Créer un ensemble de règles de matchmaking
Avant de créer un ensemble de règles de matchmaking pour votre Amazon GameLift Servers FlexMatch entremetteur, nous vous recommandons de vérifier la [syntaxe du jeu de règles](match-rules-reference.md). Une fois que vous avez créé un ensemble de règles à l'aide de la Amazon GameLift Servers console ou du AWS Command Line Interface (AWS CLI), vous ne pouvez pas le modifier.
Notez qu'il existe un [quota de service](https://console.aws.amazon.com/servicequotas/home/services/gamelift/quotas/) pour le nombre maximum d'ensembles de règles que vous pouvez avoir dans une AWS région. Il est donc conseillé de supprimer les ensembles de règles non utilisés.
**Topics**
------
#### [ Console ]
**Création d'un ensemble de règles**
1. Ouvrez la console Amazon GameLift Servers à l’adresse [https://console.aws.amazon.com/gamelift/](https://console.aws.amazon.com/gamelift/).
1. Passez à la AWS région dans laquelle vous souhaitez créer votre ensemble de règles. Définissez des ensembles de règles dans la même région que la configuration de matchmaking qui les utilise.
1. Dans le volet de navigation, choisissez **FlexMatch**, **Ensembles de règles de matchmaking**.
1. Sur la page **Ensembles de règles de matchmaking**, choisissez **Créer un ensemble de règles**.
1. Sur la page **Créer un ensemble de règles de matchmaking**, procédez comme suit :
1. Dans **Paramètres de l'ensemble de règles**, pour **Nom**, entrez un nom descriptif unique que vous pouvez utiliser pour l'identifier dans une liste ou dans des tableaux d'événements et de statistiques.
1. Pour **Ensemble de règles**, entrez votre ensemble de règles en JSON. Pour plus d'informations sur la conception d'un ensemble de règles, consultez[Concevoir un ensemble de FlexMatch règles](match-design-ruleset.md). Vous pouvez également utiliser l'un des exemples d'ensembles de règles de[FlexMatchexemples d'ensembles de règles](match-examples.md).
1. Choisissez **Valider** pour vérifier que la syntaxe de votre ensemble de règles est correcte. Vous ne pouvez pas modifier les ensembles de règles une fois qu'ils ont été créés. Il est donc conseillé de les valider au préalable.
1. (Facultatif) Sous **Balises**, ajoutez des balises pour vous aider à gérer et à suivre vos AWS ressources.
1. Choisissez **Créer**. Si la création est réussie, vous pouvez utiliser l'ensemble de règles avec un entremetteur.
------
#### [ AWS CLI ]
**Création d'un ensemble de règles**
Ouvrez une fenêtre de ligne de commande et utilisez la commande [create-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-rule-set.html).
Cet exemple de commande crée un ensemble de règles de matchmaking simple qui permet de configurer une seule équipe. Assurez-vous de créer l'ensemble de règles dans la même AWS région que les configurations de matchmaking qui l'utilisent.
```
aws gamelift create-matchmaking-rule-set \
--name "SampleRuleSet123" \
--rule-set-body '{"name": "aliens_vs_cowboys", "ruleLanguageVersion": "1.0", "teams": [{"name": "cowboys", "maxPlayers": 8, "minPlayers": 4}]}'
```
Si la demande de création aboutit, Amazon GameLift Servers renvoie un [MatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingRuleSet.html)objet qui inclut les paramètres que vous avez spécifiés. Un entremetteur peut désormais utiliser le nouvel ensemble de règles.
------
------
#### [ Console ]
**Supprimer un jeu de règles**
1. Ouvrez la console Amazon GameLift Servers à l’adresse [https://console.aws.amazon.com/gamelift/](https://console.aws.amazon.com/gamelift/).
1. Basculez vers la région dans laquelle vous avez créé l'ensemble de règles.
1. Dans le volet de navigation, choisissez **FlexMatch**, **Ensembles de règles de matchmaking**.
1. Sur la page **Ensembles de règles de matchmaking**, sélectionnez l'ensemble de règles que vous souhaitez supprimer, puis choisissez **Supprimer**.
1. Dans la boîte de dialogue **Supprimer l'ensemble de règles**, choisissez **Supprimer** pour confirmer la suppression.
**Note**
Si une configuration de matchmaking utilise l'ensemble de règles, Amazon GameLift Servers affiche un message d'erreur (**Impossible de supprimer l'ensemble de règles**). Si cela se produit, modifiez la configuration de matchmaking pour utiliser un ensemble de règles différent, puis réessayez. Pour savoir quelles configurations de matchmaking utilisent un ensemble de règles, choisissez le nom d'un ensemble de règles pour afficher sa page de détails.
------
#### [ AWS CLI ]
**Supprimer un ensemble de règles**
Ouvrez une fenêtre de ligne de commande et utilisez la commande [delete-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/delete-matchmaking-rule-set.html)pour supprimer un ensemble de règles de matchmaking.
Si une configuration de matchmaking utilise l'ensemble de règles, Amazon GameLift Servers renvoie un message d'erreur. Si cela se produit, modifiez la configuration de matchmaking pour utiliser un ensemble de règles différent, puis réessayez. Pour obtenir une liste des configurations de matchmaking utilisant un ensemble de règles, utilisez la commande [describe-matchmaking-configurations](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-matchmaking-configurations.html)et spécifiez le nom de l'ensemble de règles.
Cet exemple de commande vérifie l'utilisation de l'ensemble de règles de matchmaking, puis le supprime.
```
aws gamelift describe-matchmaking-rule-sets \
--rule-set-name "SampleRuleSet123" \
--limit 10
aws gamelift delete-matchmaking-rule-set \
--name "SampleRuleSet123"
```
------
# FlexMatchexemples d'ensembles de règles
Les ensembles de règles FlexMatch peuvent couvrir différents scénarios de mise en relation. Les exemples suivants sont conformes à la structure de la configuration et du langage d'expression de propriété FlexMatch. Copiez entièrement ces ensembles de règles ou choisissez des éléments en fonction de vos besoins.
Pour plus d'informations sur l'utilisation de règles et d'ensembles de règles FlexMatch, consultez les rubriques suivantes :
**Note**
Lorsque vous évaluez une demande de mise en relation incluant plusieurs joueurs, tous les joueurs de la demande doivent satisfaire aux exigences de mise en relation.
**Topics**
+ [Exemple : créer deux équipes avec des joueurs identiques](match-examples-1.md)
+ [Exemple : créer des équipes inégales (chasseurs contre monstres)](match-examples-2.md)
+ [Exemple : définir les exigences et les limites de latence au niveau de l'équipe](match-examples-3.md)
+ [Exemple : utilisez un tri explicite pour trouver les meilleures correspondances](match-examples-4.md)
+ [Exemple : trouver des intersections entre les attributs de plusieurs joueurs](match-examples-5.md)
+ [Exemple : comparez les attributs de tous les joueurs](match-examples-6.md)
+ [Exemple : créer une correspondance de grande taille](match-examples-7.md)
+ [Exemple : créer un grand match entre plusieurs équipes](match-examples-8.md)
+ [Exemple : créer un match de grande envergure avec des joueurs aux attributs similaires](match-examples-9.md)
+ [Exemple : utilisez une règle composée pour créer un match avec des joueurs ayant des attributs similaires ou des sélections similaires](match-examples-10.md)
+ [Exemple : créer une règle qui utilise la liste de blocage d'un joueur](match-examples-11.md)
# Exemple : créer deux équipes avec des joueurs identiques
Cet exemple illustre la configuration de deux équipes ayant un nombre identique de joueurs mis en relation avec les instructions suivantes.
+ Créez deux équipes de joueurs.
+ Inclure entre quatre et huit joueurs dans chaque équipe.
+ Au final, les équipes doivent avoir le même nombre de joueurs.
+ Inclure un niveau de compétence pour les joueurs (si aucune valeur n'est fournie, la valeur par défaut est 10).
+ Choisissez les joueurs en fonction de leur niveau de compétences, qui doit être similaire à celui d'autres joueurs. Assurez-vous que le niveau moyen de compétence des deux équipes diffère de 10 points maximum.
+ Si la mise en relation n'est pas effectuée rapidement, assouplissez les exigences du niveau de compétences pour que la mise en relation soit réalisée dans un délai raisonnable.
+ Après 5 secondes, étendez la recherche pour autoriser un écart moyen de compétences des joueurs de 50 points maximum.
+ Après 15 secondes, étendez la recherche pour autoriser un écart moyen de compétences des joueurs de 100 points maximum.
Remarques sur l'utilisation de cet ensemble de règles :
+ Cet exemple permet de disposer d'équipes composées de 4 à 8 joueurs (même si elles doivent être de même taille). Pour les équipes offrant plusieurs tailles valides, le matchmaker fait de son mieux pour mettre en relation le nombre maximal de joueurs autorisés.
+ La règle `FairTeamSkill` garantit que les équipes sont mises en relation de façon uniforme en fonction de la compétence des joueurs. Pour évaluer cette règle pour chaque nouveau joueur potentiel, FlexMatch ajoute provisoirement le joueur à une équipe et calcule les moyennes. Si la règle échoue, le joueur potentiel n'est pas ajouté à la mise en relation.
+ Étant donné que les deux équipes ont des structures identiques, vous pouvez choisir de créer une seule définition d'équipe et de définir la quantité de l'équipe sur « 2 ». Dans ce scénario, si vous avez nommé l'équipe « extra-terrestres », vos équipes recevront les noms « extra-terrestres\$11" et « extra-terrestres\$12".
```
{
"name": "aliens_vs_cowboys",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
}],
"teams": [{
"name": "cowboys",
"maxPlayers": 8,
"minPlayers": 4
}, {
"name": "aliens",
"maxPlayers": 8,
"minPlayers": 4
}],
"rules": [{
"name": "FairTeamSkill",
"description": "The average skill of players in each team is within 10 points from the average skill of all players in the match",
"type": "distance",
// get skill values for players in each team and average separately to produce list of two numbers
"measurements": [ "avg(teams[*].players.attributes[skill])" ],
// get skill values for players in each team, flatten into a single list, and average to produce an overall average
"referenceValue": "avg(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10 // minDistance would achieve the opposite result
}, {
"name": "EqualTeamSizes",
"description": "Only launch a game when the number of players in each team matches, e.g. 4v4, 5v5, 6v6, 7v7, 8v8",
"type": "comparison",
"measurements": [ "count(teams[cowboys].players)" ],
"referenceValue": "count(teams[aliens].players)",
"operation": "=" // other operations: !=, <, <=, >, >=
}],
"expansions": [{
"target": "rules[FairTeamSkill].maxDistance",
"steps": [{
"waitTimeSeconds": 5,
"value": 50
}, {
"waitTimeSeconds": 15,
"value": 100
}]
}]
}
```
# Exemple : créer des équipes inégales (chasseurs contre monstres)
Cet exemple décrit un mode de jeu dans lequel un groupe de joueurs chasse un seul monstre. Les joueurs choisissent un rôle de chasseur ou un rôle de monstre. Les chasseurs spécifient le niveau minimal de compétence du monstre qu'ils souhaitent affronter. La taille minimale de l'équipe de chasseurs peut être assouplie au fil du temps pour réaliser la mise en relation. Ce scénario établit les instructions suivantes :
+ Créez une équipe comportant exactement cinq chasseurs.
+ Créez une équipe distincte comportant un seul monstre.
+ Définissez les attributs suivants pour les joueurs :
+ Un niveau de compétence pour les joueurs (si aucune valeur n'est fournie, la valeur par défaut est 10).
+ Un niveau de compétence souhaité pour le monstre (si aucune valeur n'est fournie, la valeur par défaut est 10).
+ Si le joueur souhaite être le monstre (si cette valeur n'est pas renseignée, la valeur par défaut est 0 ou false).
+ Choisissez le joueur qui sera le monstre en fonction des critères suivants :
+ Le joueur doit demander le rôle de monstre.
+ Le niveau de compétence du joueur doit correspondre ou être supérieur au niveau de compétence le plus élevé souhaité par les joueurs qui ont déjà intégré l'équipe de chasseurs.
+ Choisissez les joueurs de l'équipe de chasseurs en fonction des critères suivants :
+ Les joueurs qui demandent le rôle de monstre ne peuvent pas être intégrés à l'équipe de chasseurs.
+ Si le rôle de monstre est déjà attribué, le joueur doit vouloir un niveau de compétence pour le monstre qui soit inférieur à la compétence du monstre proposé.
+ Si la mise en relation n'est pas effectuée rapidement, assouplissez les critères de taille minimale de l'équipe des chasseurs de la manière suivante :
+ Après 30 secondes, autorisez le démarrage du jeu avec seulement quatre joueurs dans l'équipe des chasseurs.
+ Après 60 secondes, autorisez le démarrage du jeu avec seulement trois joueurs dans l'équipe des chasseurs.
Remarques sur l'utilisation de cet ensemble de règles :
+ En utilisant deux équipes distinctes pour les chasseurs et le monstre, vous pouvez évaluer les membres en fonction de différents ensembles de critères.
```
{
"name": "players_vs_monster_5_vs_1",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
},{
"name": "desiredSkillOfMonster",
"type": "number",
"default": 10
},{
"name": "wantsToBeMonster",
"type": "number",
"default": 0
}],
"teams": [{
"name": "players",
"maxPlayers": 5,
"minPlayers": 5
}, {
"name": "monster",
"maxPlayers": 1,
"minPlayers": 1
}],
"rules": [{
"name": "MonsterSelection",
"description": "Only users that request playing as monster are assigned to the monster team",
"type": "comparison",
"measurements": ["teams[monster].players.attributes[wantsToBeMonster]"],
"referenceValue": 1,
"operation": "="
},{
"name": "PlayerSelection",
"description": "Do not place people who want to be monsters in the players team",
"type": "comparison",
"measurements": ["teams[players].players.attributes[wantsToBeMonster]"],
"referenceValue": 0,
"operation": "="
},{
"name": "MonsterSkill",
"description": "Monsters must meet the skill requested by all players",
"type": "comparison",
"measurements": ["avg(teams[monster].players.attributes[skill])"],
"referenceValue": "max(teams[players].players.attributes[desiredSkillOfMonster])",
"operation": ">="
}],
"expansions": [{
"target": "teams[players].minPlayers",
"steps": [{
"waitTimeSeconds": 30,
"value": 4
},{
"waitTimeSeconds": 60,
"value": 3
}]
}]
}
```
# Exemple : définir les exigences et les limites de latence au niveau de l'équipe
Cet exemple illustre la configuration d’équipes de joueurs et l'application d'un ensemble de règles à chacune d’elles plutôt qu'à chaque joueur. Il utilise une seule définition pour créer trois équipes de taille égale. Il établit également une latence maximale pour tous les joueurs. Les valeurs maximales de latence peuvent être assouplies au fil du temps pour réaliser la mise en relation. Cet exemple présente les instructions suivantes :
+ Créez trois équipes de joueurs.
+ Inclure entre trois et cinq joueurs dans chaque équipe.
+ Au final, les équipes doivent avoir le même nombre de joueurs ou un joueur d'écart.
+ Définissez les attributs suivants pour les joueurs :
+ Un niveau de compétence pour les joueurs (si aucune valeur n'est fournie, la valeur par défaut est 10).
+ Un rôle pour chaque joueur (si aucune valeur n'est fournie, la valeur par défaut est « paysan »).
+ Choisissez les joueurs en fonction de leur niveau de compétences, qui doit être similaire à celui d'autres joueurs de la relation.
+ Assurez-vous que le niveau moyen de compétence de chaque équipe diffère de 10 points maximum.
+ Limitez le nombre de personnages « médecin » dans chaque équipe :
+ Le nombre maximum de médecins d'une relation complète est 5.
+ Seuls les joueurs dont la latence est de 50 millisecondes ou moins doivent être pris en compte.
+ Si la mise en relation n'est pas effectuée rapidement, assouplissez le critère de latence pour les joueurs de la manière suivante :
+ Après 10 secondes, autoriser les valeurs de latence pour les joueurs jusqu'à 100 ms.
+ Après 20 secondes, autoriser les valeurs de latence pour les joueurs jusqu'à 150 ms.
Remarques sur l'utilisation de cet ensemble de règles :
+ L'ensemble de règles garantit que les équipes sont mises en relation de façon uniforme en fonction de la compétence des joueurs. Pour évaluer la règle `FairTeamSkill`, FlexMatch ajoute provisoirement le joueur potentiel à une équipe et calcule le niveau de compétence moyen des joueurs de l'équipe. Ensuite, il le compare au niveau de compétence moyen des joueurs dans les deux équipes. Si la règle échoue, le joueur potentiel n'est pas ajouté à la mise en relation.
+ Pour respecter les exigences au niveau de l'équipe et de la mise en relation (nombre total de médecins) un ensemble de règles est utilisé. Ce type de règle vérifie la liste des attributs de personnages pour tous les joueurs par rapport au nombre maximum. Utilisez `flatten` pour créer une liste pour tous les joueurs dans toutes les équipes.
+ Lors de l'évaluation basée sur la latence, notez les éléments suivants :
+ Les données de latence sont fournies dans la demande de mise en relation dans le carte de l'objet Player (joueur). Il ne s'agit pas d'un attribut de joueur, il n'a donc pas besoin d'être répertorié en tant que tel. Pour obtenir des mesures de latence précises, utilisez Amazon GameLift Servers les balises ping UDP. Ces points de terminaison vous permettent de mesurer la latence réelle du réseau UDP entre les appareils des joueurs et chacun des sites d'hébergement potentiels, ce qui permet de prendre des décisions de placement plus précises que l'utilisation de pings ICMP. Pour plus d'informations sur l'utilisation des balises ping UDP pour mesurer la latence, reportez-vous à la section Balises ping [UDP.](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html)
+ Le matchmaker évalue la latence par région. Toute région dont la latence est plus élevée que la latence maximale est ignorée. Pour être accepté pour une mise en relation, un joueur doit avoir au moins une région avec une latence inférieure au maximum.
+ Si une demande de mise en relation omet les données de latence pour un ou plusieurs joueurs, la demande est rejetée pour toutes les relations.
```
{
"name": "three_team_game",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
},{
"name": "character",
"type": "string_list",
"default": [ "peasant" ]
}],
"teams": [{
"name": "trio",
"minPlayers": 3,
"maxPlayers": 5,
"quantity": 3
}],
"rules": [{
"name": "FairTeamSkill",
"description": "The average skill of players in each team is within 10 points from the average skill of players in the match",
"type": "distance",
// get players for each team, and average separately to produce list of 3
"measurements": [ "avg(teams[*].players.attributes[skill])" ],
// get players for each team, flatten into a single list, and average to produce overall average
"referenceValue": "avg(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10 // minDistance would achieve the opposite result
}, {
"name": "CloseTeamSizes",
"description": "Only launch a game when the team sizes are within 1 of each other. e.g. 3 v 3 v 4 is okay, but not 3 v 5 v 5",
"type": "distance",
"measurements": [ "max(count(teams[*].players))"],
"referenceValue": "min(count(teams[*].players))",
"maxDistance": 1
}, {
"name": "OverallMedicLimit",
"description": "Don't allow more than 5 medics in the game",
"type": "collection",
// This is similar to above, but the flatten flattens everything into a single
// list of characters in the game.
"measurements": [ "flatten(teams[*].players.attributes[character])"],
"operation": "contains",
"referenceValue": "medic",
"maxCount": 5
}, {
"name": "FastConnection",
"description": "Prefer matches with fast player connections first",
"type": "latency",
"maxLatency": 50
}],
"expansions": [{
"target": "rules[FastConnection].maxLatency",
"steps": [{
"waitTimeSeconds": 10,
"value": 100
}, {
"waitTimeSeconds": 20,
"value": 150
}]
}]
}
```
# Exemple : utilisez un tri explicite pour trouver les meilleures correspondances
Cet exemple montre la configuration d'une mise en relation simple avec deux équipes de trois joueurs. Il montre comment utiliser les règles de tri explicite pour aider à trouver les meilleures mises en relation possibles aussi rapidement que possible. Ces règles trient tous les tickets de matchmaking actifs pour créer les meilleurs matchs en fonction de certaines exigences clés. Cet exemple est implémenté avec les instructions suivantes :
+ Créez deux équipes de joueurs.
+ Inclure exactement trois joueurs dans chaque équipe.
+ Définissez les attributs suivants pour les joueurs :
+ Niveau d'expérience (si aucune valeur n'est fournie, la valeur par défaut est 50).
+ Modes de jeu préférés (peut contenir plusieurs valeurs) (si aucune valeur n'est fournie, les valeurs par défaut sont « coop » et « deathmatch »).
+ Relations de jeu préférées, indiquant le nom de la mise en relation et la pondération des préférences (si aucune valeur n'est fournie, la valeur par défaut est `"defaultMap"` avec une pondération de 100).
+ Configurez le tri préalable :
+ Triez les joueurs en fonction de leurs préférences pour la même relation de jeu en tant que joueur d'ancrage. Les joueurs peuvent avoir plusieurs relations de jeu préférées, c'est pourquoi cet exemple utilise une valeur de préférence.
+ Triez les joueurs en fonction du degré de correspondance de leur niveau d'expérience avec celui du joueur d'ancrage. Ce tri permet de rapprocher le mieux possible les niveaux d'expérience de tous les joueurs de toutes les équipes.
+ Tous les joueurs dans toutes les équipes doivent avoir sélectionné au moins un mode de jeu en commun.
+ Tous les joueurs dans toutes les équipes doivent avoir sélectionné au moins une relation de jeu en commun.
Remarques sur l'utilisation de cet ensemble de règles :
+ Le tri de la relation de jeu utilise un tri absolu qui compare la valeur d'attribut mapPreference. Comme il s’agit de la première valeur dans l'ensemble de règles, ce tri est effectuée en premier.
+ Le tri utilise un paramètre de distance pour comparer le niveau de compétence d'un joueur potentiel par rapport à celui du joueur d'ancrage.
+ Les tris sont exécutés dans l'ordre dans lequel ils sont répertoriés dans un ensemble de règles. Dans ce scénario, les joueurs sont triés par préférence de relation de jeu, puis par niveau d'expérience.
```
{
"name": "multi_map_game",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "experience",
"type": "number",
"default": 50
}, {
"name": "gameMode",
"type": "string_list",
"default": [ "deathmatch", "coop" ]
}, {
"name": "mapPreference",
"type": "string_number_map",
"default": { "defaultMap": 100 }
}, {
"name": "acceptableMaps",
"type": "string_list",
"default": [ "defaultMap" ]
}],
"teams": [{
"name": "red",
"maxPlayers": 3,
"minPlayers": 3
}, {
"name": "blue",
"maxPlayers": 3,
"minPlayers": 3
}],
"rules": [{
// We placed this rule first since we want to prioritize players preferring the same map
"name": "MapPreference",
"description": "Favor grouping players that have the highest map preference aligned with the anchor's favorite",
// This rule is just for sorting potential matches. We sort by the absolute value of a field.
"type": "absoluteSort",
// Highest values go first
"sortDirection": "descending",
// Sort is based on the mapPreference attribute.
"sortAttribute": "mapPreference",
// We find the key in the anchor's mapPreference attribute that has the highest value.
// That's the key that we use for all players when sorting.
"mapKey": "maxValue"
}, {
// This rule is second because any tie-breakers should be ordered by similar experience values
"name": "ExperienceAffinity",
"description": "Favor players with similar experience",
// This rule is just for sorting potential matches. We sort by the distance from the anchor.
"type": "distanceSort",
// Lowest distance goes first
"sortDirection": "ascending",
"sortAttribute": "experience"
}, {
"name": "SharedMode",
"description": "The players must have at least one game mode in common",
"type": "collection",
"operation": "intersection",
"measurements": [ "flatten(teams[*].players.attributes[gameMode])"],
"minCount": 1
}, {
"name": "MapOverlap",
"description": "The players must have at least one map in common",
"type": "collection",
"operation": "intersection",
"measurements": [ "flatten(teams[*].players.attributes[acceptableMaps])"],
"minCount": 1
}]
}
```
# Exemple : trouver des intersections entre les attributs de plusieurs joueurs
Cet exemple illustre comment utiliser une règle de collection pour rechercher des intersections dans deux attributs de joueur ou plus. Lorsque vous utilisez des collections, vous pouvez utiliser l'opération `intersection` pour un attribut unique, et l'opération `reference_intersection_count` pour plusieurs attributs.
Pour illustrer cette approche, cet exemple évalue les joueurs d'une mise en relation en fonction de leurs préférences de personnages. L'exemple de jeu est un style free-for-all « » dans lequel tous les joueurs d'un match sont des adversaires. Chaque joueur est invité à (1) choisir un personnage pour lui-même, et (2) à choisir les personnages contre lesquels il veut jouer. Nous avons besoin d'une règle qui garantit que chaque joueur d'une mise en relation utilise un personnage figurant sur la liste des adversaires préférés de tous les autres joueurs.
L'exemple d'ensemble de règles décrit une mise en relation avec les caractéristiques suivantes :
+ Structure de l'équipe : une équipe de cinq joueurs
+ Attributs du joueur :
+ *myCharacter* : personnage choisi par le joueur.
+ *preferredOpponents* : liste des personnages contre lesquels le joueur veut jouer.
+ Règles de mise en relation : une mise en relation potentielle est acceptable si chaque personnage en cours d'utilisation figure sur la liste des adversaires préférés de chaque joueur.
Pour implémenter la règle de mise en relation, cet exemple utilise une règle de collection avec les valeurs de propriété suivantes :
+ Opération — Utilise une `reference_intersection_count` opération pour évaluer la manière dont chaque liste de chaînes de la valeur de mesure intersecte la liste de chaînes de la valeur de référence.
+ Mesure — Utilise l'expression de `flatten` propriété pour créer une liste de listes de chaînes, chaque liste de chaînes contenant la valeur d'attribut *MyCharacter* d'un joueur.
+ *Valeur de référence — Utilise l'expression de `set_intersection` propriété pour créer une liste de chaînes contenant toutes les valeurs d'attribut PreferredAdversaires communes à tous les joueurs du match.*
+ Restrictions : `minCount` est définie sur 1 pour garantir que le personnage choisi par chaque joueur (une liste de chaînes dans la mesure) correspond à au moins un des adversaires préférés communs à tous les joueurs. (une chaîne dans la valeur de référence).
+ Expansion — Si une correspondance n'est pas remplie dans les 15 secondes, assouplissez l'exigence minimale d'intersection.
Le processus pour cette règle se présente comme suit :
1. Un joueur est ajouté à la mise en relation potentielle. La valeur de référence (une liste de chaînes) est recalculée afin d'inclure les intersections avec la liste des adversaires préférés du nouveau joueur. La valeur de mesure (une liste de listes de chaînes) est recalculée pour ajouter le caractère choisi par le nouveau joueur en tant que nouvelle liste de chaînes.
1. Amazon GameLift Servers vérifie que chaque liste de chaînes de la valeur de mesure (les personnages choisis par le joueur) interagisse avec au moins une chaîne de la valeur de référence (les adversaires préférés du joueur). Comme dans cet exemple, chaque liste de chaînes de la mesure ne contient qu'une seule valeur, l'intersection est 0 ou 1.
1. Si aucune liste de chaînes de la mesure n'interagit avec la liste de chaînes de la valeur de référence, la règle échoue et le nouveau joueur est supprimé de la mise en relation potentielle.
1. Si une mise en relation n'est pas remplie dans un délai de 15 secondes, abandonnez l'exigence de mise en relation de l'adversaire afin de remplir les emplacements restants du joueur dans la mise en relation.
```
{
"name": "preferred_characters",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "myCharacter",
"type": "string_list"
}, {
"name": "preferredOpponents",
"type": "string_list"
}],
"teams": [{
"name": "red",
"minPlayers": 5,
"maxPlayers": 5
}],
"rules": [{
"description": "Make sure that all players in the match are using a character that is on all other players' preferred opponents list.",
"name": "OpponentMatch",
"type": "collection",
"operation": "reference_intersection_count",
"measurements": ["flatten(teams[*].players.attributes[myCharacter])"],
"referenceValue": "set_intersection(flatten(teams[*].players.attributes[preferredOpponents]))",
"minCount":1
}],
"expansions": [{
"target": "rules[OpponentMatch].minCount",
"steps": [{
"waitTimeSeconds": 15,
"value": 0
}]
}]
}
```
# Exemple : comparez les attributs de tous les joueurs
Cet exemple illustre la façon de comparer les attributs d'un joueur à un groupe de joueurs.
L'exemple d'ensemble de règles décrit une mise en relation avec les caractéristiques suivantes :
+ Structure des équipes : deux équipes à un seul joueur
+ Attributs du joueur :
+ *gameMode* : type de jeu choisi par le joueur (si aucune valeur n'est fournie, la valeur par défaut est « turn-based »).
+ *gameMap* : monde du jeu choisi par le joueur (si aucune valeur n'est fournie, la valeur par défaut est 1).
+ *character* : personnage choisi par le joueur (l'absence de valeur par défaut signifie que les joueurs doivent indiquer un personnage).
+ Règles de mise en relation : les joueurs mis en relation doivent répondre aux exigences suivantes :
+ Les joueurs doivent choisir le même mode de jeu.
+ Les joueurs doivent choisir la même relation de jeu.
+ Les joueurs doivent choisir des personnages différents.
Remarques sur l'utilisation de cet ensemble de règles :
+ Pour implémenter la règle de mise en relation, cet exemple utilise des règles de comparaison permettant de vérifier les valeurs d'attribut de tous les joueurs. Pour le mode et la relation de jeu, la règle vérifie que les valeurs sont identiques. Pour le personnage, la règle vérifie que les valeurs sont différentes.
+ Cet exemple utilise une seule définition de joueur avec une propriété de quantité pour créer les deux équipes de joueurs. Les équipes se voient attribuer les noms suivants : « joueur\$11 » et « joueur\$12 ».
```
{
"name": "",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "gameMode",
"type": "string",
"default": "turn-based"
}, {
"name": "gameMap",
"type": "number",
"default": 1
}, {
"name": "character",
"type": "number"
}],
"teams": [{
"name": "player",
"minPlayers": 1,
"maxPlayers": 1,
"quantity": 2
}],
"rules": [{
"name": "SameGameMode",
"description": "Only match players when they choose the same game type",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[gameMode])"]
}, {
"name": "SameGameMap",
"description": "Only match players when they're in the same map",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[gameMap])"]
}, {
"name": "DifferentCharacter",
"description": "Only match players when they're using different characters",
"type": "comparison",
"operation": "!=",
"measurements": ["flatten(teams[*].players.attributes[character])"]
}]
}
```
# Exemple : créer une correspondance de grande taille
Cet exemple illustre comment configurer un ensemble de règles pour une partie pouvant impliquer plus de 40 joueurs. Lorsqu'un ensemble de règles décrit les équipes avec une valeur maxPlayer totale supérieure à 40, on parle de partie à grande échelle. Pour en savoir plus, voir [Concevez un ensemble FlexMatch de règles de correspondance important](match-design-rulesets-large.md).
Cet exemple d’ensemble de règles crée une partie avec les instructions suivantes :
+ Créer une équipe pouvant compter jusqu'à 200 joueurs, avec un minimum de 175 joueurs.
+ Critères d’équilibrage : sélectionner les joueurs en fonction d’un niveau de compétence similaire. Tous les joueurs doivent indiquer leur niveau de compétence pour pouvoir être mis en relation.
+ Préférence de traitement par lots : regrouper les joueurs en fonction de critères d’équilibrage similaires lors de la création des parties.
+ Règles de latence : définir une latence maximum acceptable de 150 millisecondes pour les joueurs.
+ Si la mise en relation n'est pas effectuée rapidement, assouplissez les exigences pour que la partie puisse se remplir dans un délai raisonnable.
+ Après 10 secondes, accepter une équipe avec 150 joueurs.
+ Après 12 secondes, augmenter la latence maximum acceptable en la faisant passer à 200 millisecondes.
+ Après 15 secondes, accepter une équipe avec 100 joueurs.
Remarques sur l'utilisation de cet ensemble de règles :
+ Étant donné que l'algorithme utilise la préférence de traitement par lots largestPopulation, les joueurs sont d'abord triés en fonction des critères d’équilibrage. Par conséquent, les parties ont tendance à accueillir plus de joueurs aux compétences similaires. Tous les joueurs répondent aux exigences de latence acceptables, mais n’ont pas forcément la meilleure latence possible pour leur emplacement.
+ La stratégie d'algorithme utilisée dans cet ensemble de règles, « largest population », est le paramètre par défaut. Pour utiliser la valeur par défaut, vous pouvez choisir d'omettre le paramètre.
+ Si vous avez activé le remplissage des parties, patientez un peu avant d’assouplir les exigences relatives au nombre de joueurs. Dans le cas contraire, vous risquez de vous retrouver avec un trop grand nombre de sessions de jeu partiellement remplies. Pour en savoir plus, voir [Assoudez les exigences relatives aux gros matchs](match-design-rulesets-large-relax.md).
```
{
"name": "free-for-all",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number"
}],
"algorithm": {
"balancedAttribute": "skill",
"strategy": "balanced",
"batchingPreference": "largestPopulation"
},
"teams": [{
"name": "Marauders",
"maxPlayers": 200,
"minPlayers": 175
}],
"rules": [{
"name": "low-latency",
"description": "Sets maximum acceptable latency",
"type": "latency",
"maxLatency": 150
}],
"expansions": [{
"target": "rules[low-latency].maxLatency",
"steps": [{
"waitTimeSeconds": 12,
"value": 200
}],
}, {
"target": "teams[Marauders].minPlayers",
"steps": [{
"waitTimeSeconds": 10,
"value": 150
}, {
"waitTimeSeconds": 15,
"value": 100
}]
}]
}
```
# Exemple : créer un grand match entre plusieurs équipes
Cet exemple illustre comment configurer un ensemble de règles pour une partie entre plusieurs équipes pouvant impliquer plus de 40 joueurs. Il indique comment créer plusieurs équipes identiques avec une seule définition et présente comment les équipes de taille asymétrique sont remplies au cours de la création d’une partie.
Cet exemple d’ensemble de règles crée une partie avec les instructions suivantes :
+ Créer dix équipes « chasseur » identiques avec jusqu'à 15ˆjoueurs, et une équipe « monstre » avec exactement 5 joueurs.
+ Critères d’équilibrage : sélectionner les joueurs en fonction du nombre de monstres tués. Si les joueurs ne rapportent pas leur nombre de monstres tués, utiliser la valeur par défaut 5.
+ Préférence de traitement par lots : regrouper les joueurs en fonction des régions où la latence est la plus rapide possible pour les joueurs.
+ Règle de latence : définir une latence maximum acceptable de 200 millisecondes pour les joueurs.
+ Si la mise en relation n'est pas effectuée rapidement, assouplissez les exigences pour que la partie puisse se remplir dans un délai raisonnable.
+ Après 15 secondes, accepter les équipes avec 10 joueurs.
+ Après 20 secondes, accepter les équipes avec 8 joueurs.
Remarques sur l'utilisation de cet ensemble de règles :
+ Cet ensemble de règles définit les équipes pouvant contenir jusqu'à 155 joueurs, ce qui en fait un match important. (10 x 15 chasseurs\$15 monstres = 155)
+ Étant donné que l'algorithme utilise la préférence de traitement par lots fastestRegion, les joueurs ont tendance à être placés dans les régions où ils signalent une latence plus rapide et non dans celles où ils signalent une latence élevée (mais acceptable). Parallèlement, les parties sont susceptibles d'avoir moins de joueurs, et les critères d'équilibrage (nombre de monstres tués) peuvent varier plus largement.
+ Lorsqu'une extension est spécifiée pour une définition d'équipe (quantité > 1), elle s'applique à toutes les équipes créées avec cette définition. Par conséquent, en assouplissant le paramètre lié au nombre minimum de joueurs d’une équipe de chasseurs, les dix équipes de chasseurs sont affectées de manière égale.
+ Étant donné que cet ensemble de règles est optimisé pour réduire la latence des joueurs, la règle de latence exclut tous les joueurs qui n'ont pas d'options de connexion acceptables. Il n'est pas nécessaire d'assouplir cette exigence.
+ Voici comment FlexMatch remplit les parties pour cet ensemble de règles avant l'entrée en vigueur des extensions :
+ Aucune équipe n'a encore atteint le nombre minimum de joueurs requis. Les équipes de chasseurs ont 15 emplacements ouverts, tandis que l'équipe Monstre compte 5 emplacements ouverts.
+ Les 100 premiers joueurs sont affectés aux dix équipes de chasseurs (10 joueurs pour chaque équipe).
+ Les 22 joueurs suivants seront affectés de manière séquentielle (2 joueurs pour chaque équipe) aux équipes de chasseurs et à l’équipe Monstre.
+ Les équipes de chasseurs ont chacune atteint le nombre minimum requis de 12 joueurs. L’équipe Monstre a 2 joueurs et n'a pas atteint le nombre minimum de joueurs requis.
+ Les trois joueurs suivants sont donc attribués cette équipe.
+ Toutes les équipes ont maintenant le nombre minimum de joueurs requis. Les équipes de chasseurs ont chacune trois emplacements ouverts. L’équipe Monstre est au complet.
+ Les 30 derniers joueurs sont affectés de manière séquentielle aux équipes de chasseurs, en s'assurant qu’elles ont toutes presque la même taille (à un joueur près).
+ Si vous avez activé le remplissage des parties créées avec cet ensemble de règles, patientez un peu avant d’assouplir les exigences relatives au nombre de joueurs. Dans le cas contraire, vous risquez de vous retrouver avec un trop grand nombre de sessions de jeu partiellement remplies. Pour en savoir plus, voir [Assoudez les exigences relatives aux gros matchs](match-design-rulesets-large-relax.md).
```
{
"name": "monster-hunters",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "monster-kills",
"type": "number",
"default": 5
}],
"algorithm": {
"balancedAttribute": "monster-kills",
"strategy": "balanced",
"batchingPreference": "fastestRegion"
},
"teams": [{
"name": "Monsters",
"maxPlayers": 5,
"minPlayers": 5
}, {
"name": "Hunters",
"maxPlayers": 15,
"minPlayers": 12,
"quantity": 10
}],
"rules": [{
"name": "latency-catchall",
"description": "Sets maximum acceptable latency",
"type": "latency",
"maxLatency": 150
}],
"expansions": [{
"target": "teams[Hunters].minPlayers",
"steps": [{
"waitTimeSeconds": 15,
"value": 10
}, {
"waitTimeSeconds": 20,
"value": 8
}]
}]
}
```
# Exemple : créer un match de grande envergure avec des joueurs aux attributs similaires
Cet exemple montre comment configurer un ensemble de règles pour les matchs où deux équipes utilisent`batchDistance`. Dans l'exemple :
+ La `SimilarLeague` règle garantit que tous les joueurs d'un match ont `league` moins de 2 % des autres joueurs.
+ La `SimilarSkill` règle garantit que tous les joueurs d'un match ont `skill` moins de 10 % des autres joueurs. Si un joueur attend 10 secondes, la distance passe à 20. Si un joueur attend depuis 20 secondes, la distance passe à 40.
+ La `SameMap` règle garantit que tous les joueurs d'un match en ont fait la même demande`map`.
+ La `SameMode` règle garantit que tous les joueurs d'un match en ont fait la même demande`mode`.
```
{
"ruleLanguageVersion": "1.0",
"teams": [{
"name": "red",
"minPlayers": 100,
"maxPlayers": 100
}, {
"name": "blue",
"minPlayers": 100,
"maxPlayers": 100
}],
"algorithm": {
"strategy":"balanced",
"balancedAttribute": "skill",
"batchingPreference":"fastestRegion"
},
"playerAttributes": [{
"name": "league",
"type": "number"
},{
"name": "skill",
"type": "number"
},{
"name": "map",
"type": "string"
},{
"name": "mode",
"type": "string"
}],
"rules": [{
"name": "SimilarLeague",
"type": "batchDistance",
"batchAttribute": "league",
"maxDistance": 2
}, {
"name": "SimilarSkill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 10
}, {
"name": "SameMap",
"type": "batchDistance",
"batchAttribute": "map"
}, {
"name": "SameMode",
"type": "batchDistance",
"batchAttribute": "mode"
}],
"expansions": [{
"target": "rules[SimilarSkill].maxDistance",
"steps": [{
"waitTimeSeconds": 10,
"value": 20
}, {
"waitTimeSeconds": 20,
"value": 40
}]
}]
}
```
# Exemple : utilisez une règle composée pour créer un match avec des joueurs ayant des attributs similaires ou des sélections similaires
Cet exemple montre comment configurer un ensemble de règles pour les matchs où deux équipes utilisent`compound`. Dans l'exemple :
+ La `SimilarLeagueDistance` règle garantit que tous les joueurs d'un match ont `league` moins de 2 % des autres joueurs.
+ La `SimilarSkillDistance` règle garantit que tous les joueurs d'un match ont `skill` moins de 10 % des autres joueurs. Si un joueur attend 10 secondes, la distance passe à 20. Si un joueur attend depuis 20 secondes, la distance passe à 40.
+ La `SameMapComparison` règle garantit que tous les joueurs d'un match en ont fait la même demande`map`.
+ La `SameModeComparison` règle garantit que tous les joueurs d'un match en ont fait la même demande`mode`.
+ La `CompoundRuleMatchmaker` règle garantit une correspondance si au moins l'une des conditions suivantes est vraie :
+ Les joueurs participant à un match ont demandé la même chose `map` et la même chose`mode`.
+ Les joueurs d'un match ont des `league` attributs `skill` et des attributs comparables.
```
{
"ruleLanguageVersion": "1.0",
"teams": [{
"name": "red",
"minPlayers": 10,
"maxPlayers": 20
}, {
"name": "blue",
"minPlayers": 10,
"maxPlayers": 20
}],
"algorithm": {
"strategy":"balanced",
"balancedAttribute": "skill",
"batchingPreference":"fastestRegion"
},
"playerAttributes": [{
"name": "league",
"type": "number"
},{
"name": "skill",
"type": "number"
},{
"name": "map",
"type": "string"
},{
"name": "mode",
"type": "string"
}],
"rules": [{
"name": "SimilarLeagueDistance",
"type": "distance",
"measurements": ["max(flatten(teams[*].players.attributes[league]))"],
"referenceValue": "min(flatten(teams[*].players.attributes[league]))",
"maxDistance": 2
}, {
"name": "SimilarSkillDistance",
"type": "distance",
"measurements": ["max(flatten(teams[*].players.attributes[skill]))"],
"referenceValue": "min(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10
}, {
"name": "SameMapComparison",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[map])"]
}, {
"name": "SameModeComparison",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[mode])"]
}, {
"name": "CompoundRuleMatchmaker",
"type": "compound",
"statement": "or(and(SameMapComparison, SameModeComparison), and(SimilarSkillDistance, SimilarLeagueDistance))"
}],
"expansions": [{
"target": "rules[SimilarSkillDistance].maxDistance",
"steps": [{
"waitTimeSeconds": 10,
"value": 20
}, {
"waitTimeSeconds": 20,
"value": 40
}]
}]
}
```
# Exemple : créer une règle qui utilise la liste de blocage d'un joueur
Cet exemple illustre un ensemble de règles qui permet aux joueurs d'éviter d'être jumelés à certains autres joueurs. Les joueurs peuvent créer une liste de blocage, que le système de matchmaking évalue lors de la sélection des joueurs pour un match. Pour plus d'informations sur l'ajout d'une fonctionnalité de liste de blocage ou de liste à éviter, consultez [AWS le blog sur les jeux](https://aws.amazon.com/blogs/gametech/category/game-development/amazon-gamelift/).
Cet exemple présente les instructions suivantes :
+ Créez deux équipes de cinq joueurs exactement.
+ Transmettez la liste de blocage d'un joueur, qui est une liste de joueurs IDs (jusqu'à 100).
+ Comparez tous les joueurs à la liste de blocage de chaque joueur et rejetez un match proposé si un joueur IDs bloqué est trouvé.
Remarques sur l'utilisation de cet ensemble de règles :
+ Lors de l'évaluation d'un nouveau joueur à ajouter à un match proposé (ou pour remplacer une place dans un match existant), le joueur peut être rejeté pour l'une des raisons suivantes :
+ Si le nouveau joueur figure sur la liste des joueurs déjà sélectionnés pour le match.
+ Si des joueurs déjà sélectionnés pour le match figurent sur la liste de blocage du nouveau joueur.
+ Comme indiqué, cet ensemble de règles empêche de faire correspondre un joueur à un joueur figurant sur sa liste de blocage. Vous pouvez remplacer cette exigence par une préférence (également appelée liste « à éviter ») en ajoutant une extension des règles et en augmentant la `maxCount` valeur.
```
{
"name": "Player Block List",
"ruleLanguageVersion": "1.0",
"teams": [{
"maxPlayers": 5,
"minPlayers": 5,
"name": "red"
}, {
"maxPlayers": 5,
"minPlayers": 5,
"name": "blue"
}],
"playerAttributes": [{
"name": "BlockList",
"type": "string_list",
"default": []
}],
"rules": [{
"name": "PlayerIdNotInBlockList",
"type": "collection",
"operation": "reference_intersection_count",
"measurements": "flatten(teams[*].players.attributes[BlockList])",
"referenceValue": "flatten(teams[*].players[playerId])",
"maxCount": 0
}]
}
```