FlexMatch définitions des propriétés des ensembles de règles

Cette section définit chaque propriété du schéma de l'ensemble de règles. Pour obtenir de l'aide supplémentaire sur la création d'un ensemble de règles, consultezConstruisez un FlexMatch ensemble de règles.

name

Libellé descriptif de l'ensemble de règles. Cette valeur n'est pas associée au nom attribué au Amazon GameLift Servers MatchmakingRuleSet ressource. Cette valeur est incluse dans les données de matchmaking décrivant un match terminé, mais elle n'est utilisée par aucun Amazon GameLift Servers processus.

Valeurs autorisées : String

Obligatoire ? Non

ruleLanguageVersion

Version du langage d'expression de FlexMatch propriété utilisé.

Valeurs autorisées : « 1,0 »

Obligatoire ? Oui

playerAttributes

Une collection de données sur les joueurs incluse dans les demandes de matchmaking et utilisée dans le processus de matchmaking. Vous pouvez également déclarer des attributs ici pour que les données du joueur soient incluses dans les données de matchmaking transmises aux serveurs de jeu, même si les données ne sont pas utilisées dans le processus de matchmaking.

Obligatoire ? Non

name

Un nom unique pour l'attribut du joueur à utiliser par le système de matchmaking. Ce nom doit correspondre au nom d'attribut du joueur référencé dans les demandes de matchmaking.

Valeurs autorisées : String

Obligatoire ? Oui

type

Type de données de la valeur d'attribut du joueur.

Valeurs autorisées : « string », « number », « string_list », « string_number_map »

Obligatoire ? Oui

default

Une valeur par défaut à utiliser lorsqu'une demande de matchmaking n'en fournit pas à un joueur.

Valeurs autorisées : n'importe quelle valeur autorisée pour l'attribut du joueur.

Obligatoire ? Non

algorithm

Paramètres de configuration facultatifs pour personnaliser le processus de matchmaking.

Obligatoire ? Non

strategy

La méthode à utiliser lors de la création d'allumettes. Si cette propriété n'est pas définie, le comportement par défaut est « ExhaustiveSearch ».

Valeurs autorisées :

• « ExhaustiveSearch » — Méthode de correspondance standard. FlexMatch forme une correspondance autour du ticket le plus ancien d'un lot en évaluant les autres tickets du pool sur la base d'un ensemble de règles de match personnalisées. Cette stratégie est utilisée pour les matchs de 40 joueurs ou moins. Lorsque vous utilisez cette stratégie, elle batchingPreference doit être définie sur « aléatoire » ou « triée ».

• « équilibré » — Méthode optimisée pour former rapidement de grandes correspondances. Cette stratégie n'est utilisée que pour les matchs de 41 à 200 joueurs. Il forme les matchs en triant au préalable le pool de tickets, en créant des matchs potentiels et en assignant des joueurs à des équipes, puis en équilibrant chaque équipe dans un match en utilisant un attribut de joueur spécifique. Par exemple, cette stratégie peut être utilisée pour égaliser les niveaux de compétence moyens de toutes les équipes lors d'un match. Lorsque vous utilisez cette stratégie, elle balancedAttribute doit être définie et batchingPreference doit être définie sur « LargestPopulation » ou « FastestRegion ». La plupart des types de règles personnalisées ne sont pas reconnus avec cette stratégie.

Obligatoire ? Oui

batchingPreference

La méthode de pré-tri à utiliser avant de regrouper les tickets pour le match building. Le tri préalable du pool de tickets entraîne le regroupement des tickets en fonction d'une caractéristique spécifique, ce qui tend à améliorer l'uniformité entre les joueurs lors des matchs finaux.

Valeurs autorisées :

• « random » — Valable uniquement avec strategy = « exhaustiveSearch ». Aucun tri préalable n'est effectué ; les tickets du pool sont regroupés au hasard. Il s'agit du comportement par défaut pour une stratégie de recherche exhaustive.

• « sorted » — Valable uniquement avec strategy = « exhaustiveSearch ». Le pool de tickets est pré-trié en fonction des attributs des joueurs répertoriés danssortbyAttributes.

• « largestPopulation » — Valide uniquement avec strategy = « balanced ». Le pool de tickets est pré-trié en fonction des régions dans lesquelles les joueurs signalent des niveaux de latence acceptables. Il s'agit du comportement par défaut pour une stratégie équilibrée.

• « FastestRegion » — Valable uniquement avec strategy = « balanced ». Le pool de tickets est pré-trié en fonction des régions dans lesquelles les joueurs signalent leurs niveaux de latence les plus faibles. Les matchs qui en résultent prennent plus de temps, mais le temps de latence est généralement faible pour tous les joueurs.

Obligatoire ? Oui

balancedAttribute

Le nom d'un attribut de joueur à utiliser lors de la construction de matchs de grande envergure avec une stratégie équilibrée.

Valeurs autorisées : Tout attribut déclaré playerAttributes avec type = « number ».

Obligatoire ? Oui, si strategy = « équilibré ».

sortByAttributes

Une liste des attributs des joueurs à utiliser lors du tri préalable du pool de tickets avant le traitement par lots. Cette propriété n'est utilisée que lors du pré-tri avec la stratégie de recherche exhaustive. L'ordre de la liste d'attributs détermine l'ordre de tri. FlexMatch utilise la convention de tri standard pour les valeurs alphabétiques et numériques.

Valeurs autorisées : Tout attribut déclaré dansplayerAttributes.

Obligatoire ? Oui, si batchingPreference = « trié ».

backfillPriority

La méthode de priorisation pour faire correspondre les tickets de remblayage. Cette propriété détermine quand FlexMatch traite les tickets de remblayage par lots. Il n'est utilisé que lors du pré-tri avec la stratégie de recherche exhaustive. Si cette propriété n'est pas définie, le comportement par défaut est « normal ».

Valeurs autorisées :

• « normal » — Le type de demande d'un ticket (remplacement ou nouvelle correspondance) n'est pas pris en compte lors de la création de matchs.

• « élevé » — Un lot de tickets est trié par type de demande (puis par âge), et FlexMatch essaie d'abord de faire correspondre les tickets de remblayage.

• « faible » — Un lot de tickets est trié par type de demande (puis par âge), et FlexMatch essaie d'abord de faire correspondre les tickets non remblayés.

Obligatoire ? Non

expansionAgeSelection

Méthode de calcul du temps d'attente pour une extension des règles de match. Les extensions sont utilisées pour assouplir les conditions de match si un match n'est pas terminé après un certain temps. Le temps d'attente est calculé en fonction de l'âge des billets déjà inscrits au match partiellement rempli. Si cette propriété n'est pas définie, le comportement par défaut est « le plus récent ».

Valeurs autorisées :

• « le plus récent » : le temps d'attente pour l'extension est calculé en fonction du ticket dont l'heure de création est la plus récente dans le match partiellement terminé. Les extensions ont tendance à être déclenchées plus lentement, car un nouveau ticket peut relancer le temps d'attente.

• « le plus ancien » : le temps d'attente pour l'extension est calculé en fonction du ticket dont l'horodatage de création est le plus ancien du match. Les extensions ont tendance à être déclenchées plus rapidement.

Obligatoire ? Non

teams

La configuration des équipes lors d'un match. Indiquez un nom d'équipe et une fourchette de taille pour chaque équipe. Un ensemble de règles doit définir au moins une équipe.

name

Un nom unique pour l'équipe. Les noms des équipes peuvent être mentionnés dans les règles et les extensions. En cas de match réussi, les joueurs sont assignés par nom d'équipe dans les données de matchmaking.

Valeurs autorisées : String

Obligatoire ? Oui

maxPlayers

Le nombre maximum de joueurs pouvant être affectés à l'équipe.

Valeurs autorisées : Nombre

Obligatoire ? Oui

minPlayers

Le nombre minimum de joueurs qui doivent être affectés à l'équipe avant le match est viable.

Valeurs autorisées : Nombre

Obligatoire ? Oui

quantity

Le nombre d'équipes de ce type à créer dans un match. Les équipes dont le nombre est supérieur à 1 sont désignées par un numéro ajouté (« Red_1 », « Red_2 », etc.). Si cette propriété n'est pas définie, la valeur par défaut est « 1 ».

Valeurs autorisées : Nombre

Obligatoire ? Non

rules

Ensemble d'énoncés de règles qui définissent la manière d'évaluer les joueurs pour un match.

Obligatoire ? Non

name

Nom unique pour la règle. Toutes les règles d'un ensemble de règles doivent avoir des noms uniques. Les noms des règles sont référencés dans les journaux d'événements et les métriques qui suivent l'activité liée à la règle.

Valeurs autorisées : String

Obligatoire ? Oui

description

Description textuelle de la règle. Ces informations peuvent être utilisées pour identifier l'objectif d'une règle. Il n'est pas utilisé dans le processus de matchmaking.

Valeurs autorisées : String

Obligatoire ? Non

type

Type de déclaration de règle. Chaque type de règle possède des propriétés supplémentaires qui doivent être définies. Pour plus de détails sur la structure et l'utilisation de chaque type de règle, consultezFlexMatch types de règles.

Valeurs autorisées :

• « AbsoluteSort » — Trie à l'aide d'une méthode de tri explicite qui classe les tickets par lot en fonction de la comparaison entre un attribut de joueur spécifié et le ticket le plus ancien du lot.

• « collection » — Évalue les valeurs d'une collection, par exemple un attribut de joueur correspondant à une collection ou un ensemble de valeurs pour plusieurs joueurs.

• « comparaison » — Compare deux valeurs.

• « composé » — Définit une règle de matchmaking composée en utilisant une combinaison logique des autres règles de l'ensemble de règles. Pris en charge uniquement pour les matchs de 40 joueurs ou moins.

• « distance » — Mesure la distance entre les valeurs numériques.

• « BatchDistance » — Mesure la différence entre la valeur d'un attribut et l'utilise pour regrouper les demandes de correspondance.

• « DistanceSort » : trie à l'aide d'une méthode de tri explicite qui classe les tickets par lots en fonction de la comparaison entre un attribut de joueur spécifié avec une valeur numérique et le ticket le plus ancien du lot.

• « latence » — Évalue les données de latence régionales signalées pour une demande de matchmaking.

Obligatoire ? Oui

expansions

Règles visant à assouplir les exigences relatives aux matchs au fil du temps lorsqu'un match ne peut pas être terminé. Configurez les extensions sous la forme d'une série d'étapes qui s'appliquent progressivement afin de faciliter la recherche de correspondances. Par défaut, FlexMatch calcule le temps d'attente en fonction de l'âge du billet le plus récent ajouté à un match. Vous pouvez modifier le mode de calcul des temps d'attente pour l'expansion à l'aide de la propriété de l'algorithmeexpansionAgeSelection.

Les temps d'attente d'extension étant des valeurs absolues, le temps d'attente de chaque étape doit être plus long que celui de l'étape précédente. Par exemple, pour planifier une série progressive d'extensions, vous pouvez utiliser des temps d'attente de 30 secondes, 40 secondes et 50 secondes. Les temps d'attente ne peuvent pas dépasser le temps maximum autorisé pour une demande de match, qui est défini dans la configuration du matchmaking.

Obligatoire ? Non

target

L'élément de l'ensemble de règles à assouplir. Vous pouvez assouplir les propriétés relatives à la taille de l'équipe ou à n'importe quelle propriété d'énoncé de règle. La syntaxe est "<component name>[<rule/team name>]. <property name>». Par exemple, pour modifier la taille minimale des équipes :teams[Red, Yellow].minPlayers. Pour modifier la compétence minimale requise dans une instruction de règle de comparaison nommée « MinSkill » :rules[minSkill].referenceValue.

Obligatoire ? Oui

steps

waitTimeSeconds

Durée, en secondes, à attendre avant d'appliquer la nouvelle valeur à l'élément de l'ensemble de règles cible.

Obligatoire ? Oui

value

La nouvelle valeur de l'élément de l'ensemble de règles cible.