View a markdown version of this page

FlexMatch définitions des propriétés des ensembles de règles - GameLift Serveurs Amazon

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.

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

Une étiquette descriptive pour l'ensemble de règles. Cette valeur n'est pas associée au nom attribué à la Amazon GameLift Servers MatchmakingRuleSet ressource. Cette valeur est incluse dans les données de matchmaking décrivant une correspondance terminée, 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 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 des joueurs soient incluses dans les données de matchmaking qui sont 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 de joueur à utiliser par le matchmaker. 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 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 une pour un joueur.

Valeurs autorisées : toute valeur autorisée pour l'attribut joueur. Une chaîne vide est considérée comme ne fournissant pas de valeur par défaut.

Obligatoire ? Non

algorithm

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

Obligatoire ? Non

strategy

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 :

  • « ExhaustiveSearch » — Méthode de correspondance standard. FlexMatchforme une correspondance autour du ticket le plus vieux d'un lot en évaluant les autres billets 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 gros matchs. Cette stratégie n'est utilisée que pour les matchs de 41 à 200 joueurs. Il organise les matchs en triant au préalable la liste des tickets, en créant des matchs potentiels et en affectant les joueurs aux équipes, puis en équilibrant chaque équipe lors d'un match en utilisant 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ées ne sont pas reconnus avec cette stratégie.

Obligatoire ? Oui

batchingPreference

Méthode de pré-tri à utiliser avant de regrouper les tickets pour la création de matchs. Pre-sorting le pool de billets permet de regrouper les billets en fonction d'une caractéristique spécifique, ce qui tend à accroître l'uniformité entre les joueurs lors des derniers matchs.

Valeurs autorisées :

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

  • « sorted » — Valable uniquement avec strategy = « exhaustiveSearch ». La liste des billets est pré-triée 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égions où 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égions où les joueurs signalent leurs niveaux de latence les plus faibles. Les matchs qui en résultent prennent plus de temps à 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 la stratégie équilibrée.

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

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

sortByAttributes

Liste des attributs des joueurs à utiliser lors du pré-tri du pool de tickets avant le regroupement. 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. FlexMatchutilise 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

Méthode de priorisation pour faire correspondre les tickets de remplacement. Cette propriété détermine à quel moment FlexMatch les tickets de remblayage sont traités 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 tente d'abord de faire correspondre les tickets de remplacement.

  • « 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 remplissables.

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 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 qui figurent déjà dans le 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 de l'extension est calculé en fonction du ticket dont l'horodatage de création est le plus récent 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 de 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. Lors d'un 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 lors d'un match. Les équipes dont les quantités sont supérieures à 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 comment évaluer les joueurs pour un match.

Obligatoire ? Non

name

Un 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 mesures 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 billets 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, comme 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 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 billets par lot en fonction de la comparaison entre un attribut de joueur spécifié avec une valeur numérique et le billet le plus ancien du lot.

  • « latence » : évalue les données de latence régionales qui sont signalées pour une demande de matchmaking.

Obligatoire ? Oui

expansions

Règles pour 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'extension sont calculés à l'aide de la propriété algorithmexpansionAgeSelection.

Les temps d'attente d'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 correspondance, 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 toute autre propriété relative à l'énoncé des règles. La syntaxe est "<component name>[< rule/team nom>]. <property name>». Par exemple, pour modifier la taille minimale des équipes :teams[Red, Yellow].minPlayers. Pour modifier les compétences minimales requises dans une instruction de règle de comparaison nommée « MinSkill » :rules[minSkill].referenceValue.

Obligatoire ? Oui

steps
waitTimeSeconds

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

Obligatoire ? Oui

value

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