FlexMatchdéfinitions des propriétés d'un ensemble 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, consultezCréation d'un ensemble de FlexMatch règles.

name

Une étiquette descriptive pour l'ensemble de règles. Cette valeur n'est pas associée au nom attribué à la GameLift MatchmakingRuleSetressource Amazon. Cette valeur est incluse dans les données de matchmaking décrivant une correspondance terminée, mais elle n'est utilisée par aucun GameLift processus Amazon.

Valeurs autorisées : chaîne

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 qui est 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 de l'attribut du joueur référencé dans les demandes de matchmaking.

Valeurs autorisées : chaîne

Obligatoire ? Oui

type

Le type de données de la valeur de l'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 pour 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 pour créer des allumettes. Si cette propriété n'est pas définie, le comportement par défaut est « ExhaustiveSearch ».

Valeurs autorisées :

• « Recherche exhaustive » — Méthode de correspondance standard. FlexMatchforme un match 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, vous batchingPreference devez la régler sur « aléatoire » ou « trié ».

• « équilibrée » : méthode optimisée pour former rapidement de grandes allumettes. Cette stratégie n'est utilisée que pour les matchs de 41 à 200 joueurs. Il organise les matchs en triant à l'avance le pool de tickets, en créant des matchs potentiels et en affectant les joueurs à des équipes, puis en équilibrant chaque équipe lors d'un match à l'aide d'un attribut de joueur spécifié. 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és ne sont pas reconnus avec cette stratégie.

Obligatoire ? Oui

batchingPreference

La méthode de tri préalable à utiliser avant de regrouper les tickets pour la construction de matchs. Le tri préalable du pool de billets entraîne le regroupement des billets 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 billets du pool sont regroupés de manière aléatoire. 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 » — Valable uniquement avec strategy = « balanced ». Le pool de tickets est pré-trié par région dans laquelle 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é par région dans laquelle les joueurs signalent leur plus faible niveau de latence. Les parties qui en résultent prennent plus de temps à se terminer, mais la latence pour tous les joueurs a tendance à être faible.

Obligatoire ? Oui

balancedAttribute

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

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

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

sortByAttributes

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 tri préalable avec la stratégie de recherche exhaustive. L'ordre de la liste d'attributs détermine l'ordre de tri. FlexMatchutilise une convention de tri standard pour les valeurs alphanumériques et numériques.

Valeurs autorisées : n'importe quel 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 à quel moment FlexMatch les tickets de remblayage sont traités par lot. Il n'est utilisé que lors du tri préalable 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 (remplissage ou nouveau match) 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 tente d'abord de faire correspondre les tickets de remplissage.

• « faible » : un lot de tickets est trié par type de demande (puis par âge) et FlexMatch tente d'abord de faire correspondre les tickets non renvoyés.

Obligatoire ? Non

expansionAgeSelection

Méthode de calcul du temps d'attente pour l'extension d'une règle de correspondance. Les extensions sont utilisées pour assouplir les exigences des matchs si un match n'est pas terminé après un certain laps de temps. Le temps d'attente est calculé en fonction de l'âge des billets qui sont déjà partiellement remplis pour le match. 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é sur la base du ticket dont l'horodatage de création est le plus récent lors d'un 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é sur la base 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 : chaîne

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 lors d'un match. Les équipes dont les quantités sont supérieures à 1 sont désignées par un chiffre 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

Un ensemble d'énoncés de règles qui définissent comment évaluer les joueurs lors d'un match.

Obligatoire ? Non

name

Un nom unique pour la règle. Toutes les règles d'un ensemble de règles doivent porter des noms uniques. Les noms des règles sont référencés dans les journaux d'événements et les mesures qui permettent de suivre l'activité liée à la règle.

Valeurs autorisées : chaîne

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 : chaîne

Obligatoire ? Non

type

Type d'énoncé 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, consultezFlexMatchtypes de règles.

Valeurs autorisées :

• « AbsoluteSort » : trie à l'aide d'une méthode de tri explicite qui classe les tickets d'un 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 qui est 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 d'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 une valeur d'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 d'un lot en fonction de la comparaison entre un attribut de joueur spécifié doté d'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 dernier ticket ajouté à un match. Vous pouvez modifier la façon dont les temps d'attente d'expansion sont calculés à l'aide de la propriété de l'algorithmeexpansionAgeSelection.

Les temps d'attente pour l'extension sont des valeurs absolues, de sorte que chaque étape doit avoir un temps d'attente plus long que l'étape précédente. Par exemple, pour planifier une série d'extensions graduelles, 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é de déclaration 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 un énoncé de règle de comparaison nommé « 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 d'ensemble de règles cible.