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.
# Construire un entremetteur Amazon GameLift Servers FlexMatch
Cette section décrit les éléments clés d'un système de matchmaking et explique comment en créer un et le personnaliser pour votre jeu. Cela inclut la mise en place d'une configuration de matchmaking et d'un ensemble de règles de matchmaking.
La création de votre système de matchmaking est la première étape des FlexMatch feuilles de route :
+ [Feuille de route : Ajouter le matchmaking à une solution Amazon GameLift Servers d'hébergement](match-tasks.md)
+ [Feuille de route : Créez une solution de matchmaking autonome avec FlexMatch](match-tasks-safm.md)
Un FlexMatch entremetteur fait le travail de construction d'un match de jeu. Il gère le pool de demandes de matchmaking reçues, traite et sélectionne les joueurs pour trouver les meilleurs groupes de joueurs possibles, et forme des équipes pour un match. Pour les jeux utilisés à Amazon GameLift Servers des fins d'hébergement, il place et démarre également une session de jeu pour le match.
FlexMatch associe le service de mise en relation avec un moteur de règles personnalisables. Vous pouvez ainsi concevoir la façon de mettre en relation des joueurs en fonction d'attributs et de modes de jeu adaptés à votre jeu, et vous appuyer sur FlexMatch pour gérer les détails pratiques de la formation de groupes de joueurs et de leur placement dans des jeux. Voir plus de détails sur la mise en relation personnalisée dans [FlexMatchexemples d'ensembles de règles](match-examples.md).
Après avoir formé un match, FlexMatch fournit les données du match pour le placement de la session de jeu. Pour les jeux utilisés à des Amazon GameLift Servers fins d'hébergement, FlexMatch envoie une demande de placement de session de jeu avec des joueurs correspondants à une file d'attente de session de jeu. La file d'attente recherche alors les ressources d'hébergement disponibles sur vos flottes Amazon GameLift Servers et débute une nouvelle session de jeu. Pour les jeux qui utilisent une autre solution d'hébergement, FlexMatch fournit les données de match à fournir à votre propre composant de placement de session de jeu.
Pour une description détaillée de la façon dont un matchmaker FlexMatch traite les demandes de mise en relation qu'il reçoit, consultez [FlexMatchprocessus de matchmaking](gamelift-match-howitworks.md).
**Topics**
+ [Concevez un FlexMatch entremetteur](match-configuration.md)
+ [Construisez un FlexMatch ensemble de règles](match-rulesets.md)
+ [Créer une configuration de matchmaking](match-create-configuration.md)
+ [Configurer les notifications FlexMatch d'événements](match-notification.md)
# Concevez un FlexMatch entremetteur
Cette rubrique fournit des conseils sur la façon de concevoir un système de matchmaking adapté à votre jeu.
**Topics**
+ [Configurer un système de matchmaking de base](#match-configuration-elements)
+ [Choisissez un lieu pour l'entremetteur](match-configuration-regions.md)
+ [Ajouter des éléments facultatifs](match-configuration-options.md)
## Configurer un système de matchmaking de base
Au minimum, un entremetteur a besoin des éléments suivants :
+ L'**ensemble de règles **détermine la taille et le périmètre des équipes pour une mise en relation et définit un ensemble de règles à utiliser lors de l'évaluation des joueurs d'une mise en relation. Chaque matchmaker est configuré pour utiliser un seul ensemble de règles. Consultez [Construisez un FlexMatch ensemble de règles](match-rulesets.md) et [FlexMatchexemples d'ensembles de règles](match-examples.md).
+ La **cible de notification** reçoit toutes les notifications d'événements de matchmaking. Vous devez configurer un sujet Amazon Simple Notification Service (SNS), puis ajouter l'ID du sujet au système de jumelage. Pour plus d'informations sur la configuration des notifications, consultez [Configurer les notifications FlexMatch d'événements](match-notification.md).
+ Le **délai d'attente** détermine la durée pendant laquelle des demandes de mise en relation peuvent rester dans le pool de demandes et être évaluée pour des mises en relation potentielles. Une fois qu'une demande a dépassé le délai, elle a échoué à créer une mise en relation et elle supprimée du pool.
+ Lors de l'utilisation FlexMatch avec un hébergement Amazon GameLift Servers géré, la **file d'attente des sessions de jeu** trouve les meilleures ressources disponibles pour héberger une session de jeu pour le match et démarre une nouvelle session de jeu. Chaque file d'attente est configurée avec une liste d'emplacements et de types de ressources (y compris les instances ponctuelles ou à la demande) qui déterminent où les sessions de jeu peuvent être placées. Pour plus d'informations sur les files d'attente, consultez la section [Utilisation de files d'attente multisites.](https://docs.aws.amazon.com/gamelift/latest/developerguide/queues-intro.html)
# Choisissez un lieu pour l'entremetteur
Décidez où vous souhaitez que l'activité de matchmaking ait lieu et créez votre configuration de matchmaking et votre ensemble de règles à cet endroit. Amazon GameLift Serversgère des pools de tickets pour les demandes de match de votre jeu, où ils sont triés et évalués pour des matchs viables. Après avoir fait un match, Amazon GameLift Servers envoie les détails du match pour le placement de la session de jeu. Vous pouvez exécuter les sessions de jeu correspondantes dans n'importe quel endroit compatible avec votre solution d'hébergement.
Consultez [FlexMatchpris en charge Régions AWS](match-regions.md) les emplacements où vous pouvez créer des FlexMatch ressources.
Lorsque vous choisissez un match Région AWS pour votre système de matchmaking, réfléchissez à l'impact de l'emplacement sur les performances et à la manière dont il peut optimiser l'expérience de match pour les joueurs. Nous recommandons les bonnes pratiques suivantes :
+ Placez un entremetteur dans un endroit proche de vos joueurs et de votre service client qui envoie des demandes de FlexMatch matchmaking. Cette approche réduit l'effet de latence sur votre flux de travail de demande de matchmaking et le rend plus efficace.
+ Si votre jeu atteint un public mondial, pensez à créer des entremetteurs à plusieurs endroits et à acheminer les demandes de match vers le système de matchmaking le plus proche du joueur. En plus d'améliorer l'efficacité, cela entraîne la formation de pools de tickets avec des joueurs géographiquement proches les uns des autres, ce qui améliore la capacité du système de matchmaking à associer des joueurs en fonction des exigences de latence.
+ Lorsque vous utilisez FlexMatch un hébergement Amazon GameLift Servers géré, placez votre système de matchmaking et la file d'attente de session de jeu qu'il utilise au même endroit. Cela permet de réduire la latence des communication entre le matchmaker et la file d'attente.
# Ajouter des éléments facultatifs
En plus de ces exigences minimales, vous pouvez configurer votre matchmaker avec les options supplémentaires suivantes. Si vous utilisez FlexMatch une solution Amazon GameLift Servers d'hébergement, de nombreuses fonctionnalités sont intégrées. Si vous l'utilisez en FlexMatch tant que service de jumelage autonome, vous voudrez peut-être intégrer ces fonctionnalités à votre système.
**Acceptation des joueurs**
Vous pouvez configurer un système de matchmaking pour exiger que tous les joueurs sélectionnés pour un match acceptent de participer. Si votre système exige une acceptation, tous les joueurs doivent avoir la possibilité d'accepter ou de rejeter un match proposé. Une mise en relation doit recevoir les acceptations de tous les joueurs avant d'être effective. Si un joueur refuse ou n'accepte pas un match, le match proposé est annulé et les tickets sont traités comme suit. Les tickets pour lesquels tous les joueurs figurant sur le ticket ont accepté le match sont renvoyés au matchmaking pool pour un traitement ultérieur. Les tickets pour lesquels au moins un joueur a refusé le match ou n'a pas répondu sont considérés comme un échec et ne sont plus traités. L'acceptation des joueurs nécessite une limite de temps ; tous les joueurs doivent accepter un match proposé dans le délai imparti pour que le match puisse continuer.
**Mode de remplissage**
Utilisez FlexMatch le remblayage pour que vos sessions de jeu soient remplies de nouveaux joueurs parfaitement adaptés pendant toute la durée de la session de jeu. Lors du traitement des demandes de remplacement, FlexMatch utilise le même système de matchmaking que celui utilisé pour associer les joueurs d'origine. Vous pouvez personnaliser la façon dont les tickets de remblayage sont priorisés avec des tickets pour les nouveaux matchs, en plaçant les tickets de remblayage en première ou en fin de file. Cela signifie que, lorsque de nouveaux joueurs entrent dans le matchmaking pool, ils sont plus ou moins susceptibles d'être placés dans un jeu existant que dans un jeu nouvellement créé.
Le remplissage manuel est disponible, que votre jeu soit utilisé FlexMatch avec un Amazon GameLift Servers hébergement géré ou avec d'autres solutions d'hébergement. Le remplissage manuel vous offre la flexibilité dont vous avez besoin pour déterminer quand déclencher une demande de remplissage. Par exemple, vous souhaiterez peut-être ajouter de nouveaux joueurs uniquement pendant certaines phases de votre jeu ou uniquement lorsque certaines conditions sont réunies.
Le remblayage automatique n'est disponible que pour les jeux utilisant un Amazon GameLift Servers hébergement géré. Lorsque cette fonctionnalité est activée, si une session de jeu commence avec des machines à sous ouvertes, elle Amazon GameLift Servers commence à générer automatiquement des demandes de remplacement pour celle-ci. Cette fonctionnalité vous permet de configurer le matchmaking afin que les nouvelles parties commencent avec un nombre minimum de joueurs, puis soient rapidement remplies au fur et à mesure que de nouveaux joueurs entrent dans le pool de matchmaking. Vous pouvez désactiver le remblayage automatique à tout moment pendant la durée de vie de la session de jeu.
**Propriétés du jeu**
Pour les jeux utilisant FlexMatch un hébergement Amazon GameLift Servers géré, vous pouvez fournir des informations supplémentaires à transmettre à un serveur de jeu chaque fois qu'une nouvelle session de jeu est demandée. Cela peut être un moyen utile de transmettre les configurations du mode jeu nécessaires au démarrage d'une session de jeu pour le type de matchs en cours de création. Toutes les sessions de jeu pour les matchs créées par un système de matchmaking reçoivent le même ensemble de propriétés de jeu. Vous pouvez modifier les informations sur les propriétés du jeu en créant différentes configurations de matchmaking.
**Emplacements de joueur réservés**
Vous pouvez définir certains emplacements de joueur comme étant réservés et remplis ultérieurement. Pour cela, vous devez configurer la propriété « additional player count » d'une configuration de mise en relation.
**Données d'événement personnalisées**
Utilisez cette propriété pour inclure un ensemble d'informations personnalisées dans tous les événements liés à l'activité de mise en relation et destinés au matchmaker. Cette fonction peut être utile pour le suivi d'une activité spécifique à votre jeu, y compris le suivi des performances de vos matchmakers.
# 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
}]
}
```
# Créer une configuration de matchmaking
Pour configurer un Amazon GameLift Servers FlexMatch système de matchmaking pour traiter les demandes de matchmaking, créez une configuration de matchmaking. Utilisez la Amazon GameLift Servers console ou le AWS Command Line Interface (AWS CLI). Pour plus d'informations sur la création d'un système de matchmaking, consultez[Concevez un FlexMatch entremetteur](match-configuration.md).
**Topics**
+ [Tutoriel : créer un système de jumelage pour l'hébergement Amazon GameLift Servers](match-create-configuration-withqueue.md)
+ [Tutoriel : créer un système de matchmaking pour le mode autonome FlexMatch](match-create-configuration-standalone.md)
+ [Tutoriel : Modifier une configuration de matchmaking](match-create-configuration-edit.md)
# Tutoriel : créer un système de jumelage pour l'hébergement Amazon GameLift Servers
Avant de créer une configuration de matchmaking, [créez un ensemble de règles](match-create-ruleset.md) et une [file d'attente de session de Amazon GameLift Servers jeu](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/queues-creating.html) à utiliser avec le système de matchmaking.
------
#### [ Console ]
1. Dans la [Amazon GameLift Serversconsole](https://console.aws.amazon.com/gamelift/), dans le volet de navigation, choisissez **Configurations de matchmaking**.
1. Passez à la AWS région dans laquelle vous souhaitez créer votre entremetteur.
1. Sur la page **Configurations de matchmaking**, choisissez **Créer une configuration de matchmaking**.
1. Sur la page **Définir les détails de configuration**, sous **Détails de configuration du matchmaking**, procédez comme suit :
1. Dans **Nom**, entrez le nom du système de matchmaking qui pourra vous aider à l'identifier dans une liste et dans les statistiques. Le nom de l'entremetteur doit être unique dans la région. Les demandes de matchmaking identifient le matchmaker à utiliser par son nom et sa région.
1. (Facultatif) Dans **Description**, ajoutez une description pour aider à identifier le système de jumelage.
1. Pour **Ensemble de règles**, choisissez un ensemble de règles dans la liste à utiliser avec le système de matchmaking. La liste contient tous les ensembles de règles que vous avez créés dans la région actuelle.
1. Pour **FlexMatchle mode**, choisissez **Géré** pour l'hébergement Amazon GameLift Servers géré. Ce mode invite FlexMatch à transmettre les matchs réussis à la file d'attente de session de jeu spécifiée.
1. Pour **AWS Région**, choisissez la région dans laquelle vous avez configuré la file d'attente de session de jeu que vous souhaitez utiliser avec le système de matchmaking.
1. Pour **Queue**, choisissez la file d'attente des sessions de jeu que vous souhaitez utiliser avec le système de matchmaking.
1. Choisissez **Suivant**.
1. Sur la page **Configurer les paramètres**, sous **Paramètres de matchmaking**, procédez comme suit :
1. Pour le **délai d'expiration des demandes**, définissez le délai maximum, en secondes, pendant lequel le système de jumelage doit effectuer une correspondance pour chaque demande. FlexMatchannule les demandes de matchmaking qui dépassent ce délai.
1. Pour le **mode Remblayage, choisissez un mode de gestion des remblais** assortis.
+ Pour activer la fonction de remblayage automatique, choisissez **Automatique**.
+ **Pour créer votre propre gestion des demandes de remblayage ou pour ne pas utiliser la fonction de remblayage, choisissez Manuel.**
1. (Facultatif) Pour le **nombre de joueurs supplémentaires**, définissez le nombre de places à garder ouvertes pendant un match. FlexMatchpourra remplir ces emplacements avec des joueurs à l'avenir.
1. (Facultatif) Sous **Options d'acceptation des matchs**, pour **Acceptation requise**, si vous souhaitez demander à chaque joueur participant à un match proposé d'accepter activement de participer au match, sélectionnez **Obligatoire**. Si vous sélectionnez cette option, définissez le **délai d'acceptation**, en secondes, pendant lequel vous souhaitez que le système de matchmaking attende les acceptations des joueurs avant d'annuler le match.
1. (Facultatif) Sous **Paramètres de notification d'événements**, procédez comme suit :
1. (Facultatif) Pour le **sujet SNS**, choisissez un sujet Amazon Simple Notification Service (Amazon SNS) pour recevoir les notifications d'événements de matchmaking. Si vous n'avez pas encore configuré de sujet SNS, vous pourrez le choisir ultérieurement en modifiant la configuration du matchmaking. Pour de plus amples informations, veuillez consulter [Configurer les notifications FlexMatch d'événements](match-notification.md).
1. (Facultatif) Pour les **données d'événement personnalisées**, entrez les données personnalisées que vous souhaitez associer à ce matchmaker dans la messagerie événementielle. FlexMatchinclut ces données dans chaque événement associé au système de matchmaking.
1. (Facultatif) Développez **les données de jeu supplémentaires**, puis procédez comme suit :
1. (Facultatif) Pour les **données de session de jeu**, saisissez toutes les informations supplémentaires relatives au jeu que vous souhaitez fournir FlexMatch aux nouvelles sessions de jeu démarrées avec des matchs effectués à l'aide de cette configuration de matchmaking.
1. (Facultatif) Pour les **propriétés du jeu**, ajoutez des propriétés de paire clé-valeur contenant des informations sur une nouvelle session de jeu.
1. (Facultatif) Sous **Balises**, ajoutez des balises pour vous aider à gérer et à suivre vos AWS ressources.
1. Choisissez **Suivant**.
1. Sur la page **Réviser et créer**, passez en revue vos choix, puis choisissez **Créer**. Une fois la création réussie, le matchmaker est prêt à accepter les demandes de matchmaking.
------
#### [ AWS CLI ]
Pour créer une configuration de matchmaking avec le AWS CLI, ouvrez une fenêtre de ligne de commande et utilisez la [create-matchmaking-configuration](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-configuration.html)commande pour définir un nouveau système de matchmaking.
Cet exemple de commande crée une nouvelle configuration de matchmaking qui nécessite l'acceptation du joueur et active le remblayage automatique. Il réserve également des emplacements à deux joueurs FlexMatch pour ajouter des joueurs ultérieurement, et fournit certaines données de session de jeu.
```
aws gamelift create-matchmaking-configuration \
--name "SampleMatchamker123" \
--description "The sample test matchmaker with acceptance" \
--flex-match-mode WITH_QUEUE \
--game-session-queue-arns "arn:aws:gamelift:us-west-2:111122223333:gamesessionqueue/MyGameSessionQueue" \
--rule-set-name "MyRuleSet" \
--request-timeout-seconds 120 \
--acceptance-required \
--acceptance-timeout-seconds 30 \
--backfill-mode AUTOMATIC \
--notification-target "arn:aws:sns:us-west-2:111122223333:My_Matchmaking_SNS_Topic" \
--additional-player-count 2 \
--game-session-data "key=map,value=winter444"
```
Si la demande de création de la configuration de matchmaking est réussie, Amazon GameLift Servers renvoie un [MatchmakingConfiguration](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingConfiguration.html)objet avec les paramètres que vous avez demandés pour le système de matchmaking. Le nouveau système de matchmaking est prêt à accepter les demandes de matchmaking.
------
# Tutoriel : créer un système de matchmaking pour le mode autonome FlexMatch
Avant de créer une configuration de matchmaking, [créez un ensemble de règles](match-create-ruleset.md) à utiliser avec le système de matchmaking.
------
#### [ Console ]
1. Ouvrez la Amazon GameLift Servers console à la [https://console.aws.amazon.com/gamelift/maison](https://console.aws.amazon.com/gamelift/).
1. Passez à la AWS région dans laquelle vous souhaitez créer votre entremetteur. Pour une liste des régions qui prennent en charge les configurations de FlexMatch matchmaking, voir[Choisissez un lieu pour l'entremetteur](match-configuration-regions.md).
1. Dans le volet de navigation **FlexMatch**, choisissez **Configurations de matchmaking**.
1. Sur la page **Configurations de matchmaking**, choisissez **Créer une configuration de matchmaking**.
1. Sur la page **Définir les détails de configuration**, sous **Détails de configuration du matchmaking**, procédez comme suit :
1. Dans **Nom**, entrez le nom du système de matchmaking qui pourra vous aider à l'identifier dans une liste et dans les statistiques. Le nom de l'entremetteur doit être unique dans la région. Les demandes de matchmaking identifient le matchmaker à utiliser par son nom et sa région.
1. (Facultatif) Dans **Description**, ajoutez une description pour aider à identifier le système de jumelage.
1. Pour **Ensemble de règles**, choisissez un ensemble de règles dans la liste à utiliser avec le système de matchmaking. La liste contient tous les ensembles de règles que vous avez créés dans la région actuelle.
1. Pour **FlexMatchle mode**, choisissez **Standalone.** Cela indique que vous disposez d'un mécanisme personnalisé pour démarrer de nouvelles sessions de jeu sur une solution d'hébergement externe àAmazon GameLift Servers.
1. Choisissez **Suivant**.
1. Sur la page **Configurer les paramètres**, sous **Paramètres de matchmaking**, procédez comme suit :
1. Pour le **délai d'expiration des demandes**, définissez le délai maximum, en secondes, pendant lequel le système de jumelage doit effectuer une correspondance pour chaque demande. Les demandes de matchmaking qui dépassent ce délai sont rejetées.
1. (Facultatif) Sous **Options d'acceptation des matchs**, pour **Acceptation requise**, si vous souhaitez demander à chaque joueur participant à un match proposé d'accepter activement de participer au match, sélectionnez **Obligatoire**. Si vous sélectionnez cette option, définissez le **délai d'acceptation**, en secondes, pendant lequel vous souhaitez que le système de matchmaking attende les acceptations des joueurs avant d'annuler le match.
1. (Facultatif) Sous **Paramètres de notification d'événements**, procédez comme suit :
1. (Facultatif) Pour le **sujet SNS**, choisissez un sujet Amazon SNS pour recevoir les notifications d'événements de matchmaking. Si vous n'avez pas encore configuré de sujet SNS, vous pourrez le choisir ultérieurement en modifiant la configuration du matchmaking. Pour de plus amples informations, veuillez consulter [Configurer les notifications FlexMatch d'événements](match-notification.md).
1. (Facultatif) Pour les **données d'événement personnalisées**, entrez les données personnalisées que vous souhaitez associer à ce matchmaker dans la messagerie événementielle. FlexMatchinclut ces données dans chaque événement associé au système de matchmaking.
1. (Facultatif) Sous **Balises**, ajoutez des balises pour vous aider à gérer et à suivre vos AWS ressources.
1. Choisissez **Suivant**.
1. Sur la page **Réviser et créer**, passez en revue vos choix, puis choisissez **Créer**. Une fois la création réussie, le matchmaker est prêt à accepter les demandes de matchmaking.
------
#### [ AWS CLI ]
Pour créer une configuration de matchmaking avec le AWS CLI, ouvrez une fenêtre de ligne de commande et utilisez la [create-matchmaking-configuration](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-configuration.html)commande pour définir un nouveau système de matchmaking.
Cet exemple de commande crée une nouvelle configuration de matchmaking pour un système de matchmaking autonome qui nécessite l'acceptation du joueur.
```
aws gamelift create-matchmaking-configuration \
--name "SampleMatchamker123" \
--description "The sample test matchmaker with acceptance" \
--flex-match-mode STANDALONE \
--rule-set-name "MyRuleSetOne" \
--request-timeout-seconds 120 \
--acceptance-required \
--acceptance-timeout-seconds 30 \
--notification-target "arn:aws:sns:us-west-2:111122223333:My_Matchmaking_SNS_Topic"
```
Si la demande de création de la configuration de matchmaking est réussie, Amazon GameLift Servers renvoie un [MatchmakingConfiguration](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingConfiguration.html)objet avec les paramètres que vous avez demandés pour le système de matchmaking. Le nouveau système de matchmaking est prêt à accepter les demandes de matchmaking.
------
# Tutoriel : Modifier une configuration de matchmaking
Pour modifier une configuration de matchmaking, choisissez **Configurations de matchmaking** dans la barre de navigation et choisissez la configuration que vous souhaitez modifier. Vous pouvez mettre à jour n'importe quel champ d'une configuration existante, à l'exception de son nom.
Lors de la mise à jour d'un ensemble de règles de configuration, un nouvel ensemble de règles peut être incompatible s'il existe des tickets de matchmaking actifs pour les raisons suivantes :
+ Noms d'équipes ou nombre d'équipes nouveaux ou différents
+ Attributs des nouveaux joueurs
+ Modifications apportées aux types d'attributs de joueur existants
Pour apporter l'une de ces modifications à votre ensemble de règles, créez une nouvelle configuration de matchmaking avec le jeu de règles mis à jour.
# Configurer les notifications FlexMatch d'événements
Vous pouvez utiliser les notifications d'événements pour suivre l'état des demandes de matchmaking individuelles. Tous les jeux en production ou en pré-production avec un volume élevé d'activités de matchmaking doivent utiliser les notifications d'événements.
Il existe deux options pour configurer les notifications d'événements.
+ Demandez à votre entremetteur de publier des notifications d'événements sur une rubrique Amazon Simple Notification Service (Amazon SNS).
+ Utilisez les EventBridge événements Amazon publiés automatiquement et sa suite d'outils pour gérer les événements.
Pour obtenir la liste des FlexMatch événements qui Amazon GameLift Servers émettent, consultez[FlexMatchévénements de matchmaking](match-events.md).
**Important**
Pour les systèmes de matchmaking à volume élevé, nous recommandons d'utiliser des rubriques Amazon SNS standard (non FIFO) plutôt que des rubriques FIFO. Les rubriques FIFO ont des limites de publication inférieures à celles des rubriques standard, ce qui peut entraîner des exceptions de limitation en cas de charge élevée. Si vous rencontrez des difficultés avec les sujets FIFO, vous risquez de perdre des notifications. FlexMatch
**Note**
Amazon GameLift Serversgère automatiquement les échecs de livraison et les limitations d'Amazon SNS grâce à une logique de nouvelle tentative intégrée. Lorsqu'Amazon SNS renvoie des erreurs de régulation ou des échecs temporaires, recommence à envoyer les notifications avec des délais progressifs entre les Amazon GameLift Servers tentatives. Cela permet de garantir que les notifications d'événements sont transmises de manière fiable. Cependant, les notifications peuvent être perdues si les échecs persistent après toutes les tentatives, ou en cas d'erreurs non réessayables, telles que des échecs d'autorisation ou des sujets manquants.
**Topics**
+ [Configurez EventBridge des événements](#match-notification-cwe)
+ [Tutoriel : Configuration d'une rubrique Amazon SNS](match-notification-sns.md)
+ [Configuration d'une rubrique SNS avec chiffrement côté serveur](queue-notification-sns-sse.md)
+ [Configurer un abonnement à une rubrique pour appeler une fonction Lambda](match-notification-lambda.md)
## Configurez EventBridge des événements
Amazon GameLift Serverspublie automatiquement tous les événements de matchmaking sur Amazon EventBridge. Avec EventBridge, vous pouvez configurer des règles pour que les événements de matchmaking soient acheminés vers des cibles pour traitement. Par exemple, vous pouvez définir une règle pour acheminer l'événement « PotentialMatchCreated » vers une AWS Lambda fonction qui gère les acceptations des joueurs. Pour plus d'informations, consultez [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
**Note**
Lorsque vous configurez vos matchmakers, laissez le champ cible de notification vide ou faites référence à une rubrique SNS si vous souhaitez utiliser à la fois Amazon SNS EventBridge et Amazon SNS.
# Tutoriel : Configuration d'une rubrique Amazon SNS
Vous pouvez avoir Amazon GameLift Servers publié tous les événements générés par un FlexMatch entremetteur sur un sujet Amazon SNS.
**Pour créer une rubrique SNS pour les notifications d'Amazon GameLift Serversévénements**
1. Ouvrez la [console Amazon SNS](https://console.aws.amazon.com/sns).
1. Dans le volet de navigation, choisissez **Rubriques**.
1. Sur la page **Rubriques**, choisissez **Créer une rubrique**.
1. Créez une rubrique dans la console . Pour plus d'informations, consultez [To create a topic using the AWS Management Console in the](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html#create-topic-aws-console) *Amazon Simple Notification Service Developer Guide*.
1. Sur la page **Détails** de votre sujet, choisissez **Modifier**.
1. (Facultatif) Sur la page d'**édition** de votre sujet, développez la **politique d'accès**, puis ajoutez la syntaxe en gras de la déclaration de politique Gestion des identités et des accès AWS (IAM) suivante à la fin de votre politique existante. (La politique complète est présentée ici pour plus de clarté.) Assurez-vous d'utiliser les informations Amazon Resource Name (ARN) pour votre propre sujet SNS et votre configuration de Amazon GameLift Servers matchmaking.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"SNS:GetTopicAttributes",
"SNS:SetTopicAttributes",
"SNS:AddPermission",
"SNS:RemovePermission",
"SNS:DeleteTopic",
"SNS:Subscribe",
"SNS:ListSubscriptionsByTopic",
"SNS:Publish"
],
"Resource": "arn:aws:sns:us-east-1:111122223333:your_topic_name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333"
}
}
},
{
"Sid": "__console_pub_0",
"Effect": "Allow",
"Principal": {
"Service": "gamelift.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-1:111122223333:your_topic_name",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:gamelift:us-east-1:111122223333:matchmakingconfiguration/your_configuration_name"
}
}
}
]
}
```
------
1. Sélectionnez **Enregistrer les modifications**.
# Configuration d'une rubrique SNS avec chiffrement côté serveur
Vous pouvez utiliser le chiffrement côté serveur (SSE) pour stocker des données sensibles dans des rubriques chiffrées. SSE protège le contenu des messages dans les rubriques Amazon SNS à l'aide de clés gérées dans AWS Key Management Service ()AWS KMS. Pour plus d'informations sur le chiffrement côté serveur avec Amazon SNS, [consultez la section Encryption at](https://docs.aws.amazon.com/sns/latest/dg/sns-server-side-encryption.html) rest du manuel *Amazon Simple Notification* Service Developer Guide.
Pour configurer une rubrique SNS avec chiffrement côté serveur, consultez les rubriques suivantes :
+ [Création d'une clé](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *guide du AWS Key Management Service développeur*
+ [Activation de SSE pour un sujet](https://docs.aws.amazon.com/sns/latest/dg/sns-enable-encryption-for-topic.html) du manuel *Amazon Simple Notification Service Developer Guide*
Lorsque vous créez votre clé KMS, utilisez la stratégie de clé KMS suivante :
```
{
"Effect": "Allow",
"Principal": {
"Service": "gamelift.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:gamelift:your_region:your_account:matchmakingconfiguration/your_configuration_name"
},
"StringEquals": {
"kms:EncryptionContext:aws:sns:topicArn": "arn:aws:sns:your_region:your_account:your_sns_topic_name"
}
}
}
```
# Configurer un abonnement à une rubrique pour appeler une fonction Lambda
Vous pouvez appeler une fonction Lambda à l'aide des notifications d'événements publiées sur votre rubrique Amazon SNS. Lorsque vous configurez le système de matchmaking, veillez à définir l'ARN de votre sujet SNS comme cible de notification.
Le AWS CloudFormation modèle suivant configure un abonnement à une rubrique SNS nommée `MyFlexMatchEventTopic` pour appeler une fonction Lambda nommée. `FlexMatchEventHandlerLambdaFunction` Le modèle crée une politique d'autorisation IAM qui permet d'Amazon GameLift Serversécrire sur la rubrique SNS. Le modèle ajoute ensuite des autorisations permettant à la rubrique SNS d'invoquer la fonction Lambda.
```
FlexMatchEventTopic:
Type: "AWS::SNS::Topic"
Properties:
KmsMasterKeyId: alias/aws/sns #Enables server-side encryption on the topic using an AWS managed key
Subscription:
- Endpoint: !GetAtt FlexMatchEventHandlerLambdaFunction.Arn
Protocol: lambda
TopicName: MyFlexMatchEventTopic
FlexMatchEventTopicPolicy:
Type: "AWS::SNS::TopicPolicy"
DependsOn: FlexMatchEventTopic
Properties:
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: gamelift.amazonaws.com
Action:
- "sns:Publish"
Resource: !Ref FlexMatchEventTopic
Topics:
- Ref: FlexMatchEventTopic
FlexMatchEventHandlerLambdaPermission:
Type: "AWS::Lambda::Permission"
Properties:
Action: "lambda:InvokeFunction"
FunctionName: !Ref FlexMatchEventHandlerLambdaFunction
Principal: sns.amazonaws.com
SourceArn: !Ref FlexMatchEventTopic
```