Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
FlexMatch Definitionen von Regelsatzeigenschaften
In diesem Abschnitt wird jede Eigenschaft im Regelsatzschema definiert. Zusätzliche Hilfe beim Erstellen eines Regelsatzes finden Sie unterBaue ein FlexMatch Regelsatz.
name-
Eine beschreibende Bezeichnung für den Regelsatz. Dieser Wert ist nicht mit dem Namen verknüpft, der der Amazon GameLift Servers MatchmakingRuleSet Ressource zugewiesen wurde. Dieser Wert ist in den Matchmaking-Daten enthalten, die ein abgeschlossenes Spiel beschreiben, wird aber von keinem Amazon GameLift Servers Prozess verwendet.
Zulässige Werte: Zeichenfolge
Erforderlich? Nein
ruleLanguageVersion-
Die Version der verwendeten FlexMatch Eigenschaftsausdruckssprache.
Zulässige Werte: „1.0"
Erforderlich? Ja
playerAttributes-
Eine Sammlung von Spielerdaten, die in Matchmaking-Anfragen enthalten sind und im Matchmaking-Prozess verwendet werden. Sie können hier auch Attribute angeben, um die Spielerdaten in die Matchmaking-Daten aufzunehmen, die an die Spielserver weitergegeben werden, auch wenn die Daten nicht im Matchmaking-Prozess verwendet werden.
Erforderlich? Nein
name-
Ein eindeutiger Name für das Spielerattribut, das vom Matchmaker verwendet werden soll. Dieser Name muss mit dem Namen des Spielerattributs übereinstimmen, auf den in Matchmaking-Anfragen verwiesen wird.
Zulässige Werte: Zeichenfolge
Erforderlich? Ja
type-
Der Datentyp des Spielerattributwerts.
Zulässige Werte: „string“, „number“, „string_list“, „string_number_map“
Erforderlich? Ja
default-
Ein Standardwert, der verwendet wird, wenn eine Matchmaking-Anfrage keinen Wert für einen Spieler bereitstellt.
Zulässige Werte: Jeder Wert, der für das Spielerattribut zulässig ist. Eine leere Zeichenfolge wird so behandelt, als ob sie keinen Standardwert enthält.
Erforderlich? Nein
algorithm-
Optionale Konfigurationseinstellungen zur Anpassung des Matchmaking-Prozesses.
Erforderlich? Nein
strategy-
Die Methode, die beim Erstellen von Matches verwendet werden soll. Wenn diese Eigenschaft nicht festgelegt ist, lautet das Standardverhalten „ExhautiveSearch“.
Zulässige Werte:
-
„ExhaustiveSearch“ — Standardmethode für den Abgleich. FlexMatchbildet ein Match rund um das älteste Ticket einer Charge, indem andere Tickets im Pool anhand einer Reihe von benutzerdefinierten Spielregeln bewertet werden. Diese Strategie wird für Spiele mit 40 Spielern oder weniger verwendet. Wenn Sie diese Strategie verwenden,
batchingPreferencesollte sie entweder auf „zufällig“ oder „sortiert“ gesetzt werden. -
„ausgewogen“ — Methode, die optimiert ist, um schnell große Matches zu bilden. Diese Strategie wird nur für Spiele mit 41 bis 200 Spielern verwendet. Sie bildet Spiele, indem sie den Ticketpool vorsortiert, potenzielle Spiele erstellt und Spieler den Teams zuweist und dann jedes Team in einem Spiel anhand eines bestimmten Spielerattributs ausbalanciert. Diese Strategie kann zum Beispiel verwendet werden, um das durchschnittliche Spielniveau aller Teams in einem Spiel auszugleichen. Wenn Sie diese Strategie verwenden,
balancedAttributemuss undbatchingPreferencesollte entweder „LargestPopulation“ oder „FastestRegion“ ausgewählt werden. Die meisten benutzerdefinierten Regeltypen werden bei dieser Strategie nicht erkannt.
Erforderlich? Ja
-
batchingPreference-
Die Methode zur Vorsortierung, die vor der Gruppierung von Tickets für den Spielaufbau verwendet werden soll. Pre-sorting Der Ticketpool sorgt dafür, dass Tickets auf der Grundlage eines bestimmten Merkmals zusammengefaßt werden, was die Einheitlichkeit der Spieler in den Endspielen tendenziell erhöht.
Zulässige Werte:
-
„random“ — Nur gültig mit
strategy= „ExhautiveSearch“. Es erfolgt keine Vorsortierung; die Tickets im Pool werden nach dem Zufallsprinzip gestapelt. Dies ist das Standardverhalten für eine umfassende Suchstrategie. -
„sortiert“ — Nur gültig mit
strategy= „ExhautiveSearch“. Der Ticketpool ist anhand der unter aufgeführten Spielerattribute vorsortiert.sortbyAttributes -
„LargestPopulation“ — Nur gültig mit
strategy= „balanced“. Der Ticketpool ist vorsortiert nach Regionen, in denen Spieler akzeptable Latenzwerte melden. Dies ist das Standardverhalten für eine ausgewogene Strategie. -
„FastestRegion“ — Nur gültig mit
strategy= „balanced“. Der Ticketpool ist vorsortiert nach Regionen, in denen Spieler ihre niedrigsten Latenzwerte melden. Es dauert länger, bis die Matches abgeschlossen sind, aber die Latenz für alle Spieler ist in der Regel gering.
Erforderlich? Ja
-
balancedAttribute-
Der Name eines Spielerattributs, das beim Aufbau großer Matches mit einer ausgewogenen Strategie verwendet werden soll.
Zulässige Werte: Jedes Attribut, das
playerAttributesmittype= „Zahl“ deklariert ist.Erforderlich? Ja, wenn
strategy= „ausgewogen“. sortByAttributes-
Eine Liste von Spielerattributen, die bei der Vorsortierung des Ticketpools vor dem Batching verwendet werden sollen. Diese Eigenschaft wird nur bei der Vorsortierung im Rahmen der umfassenden Suchstrategie verwendet. Die Reihenfolge der Attributliste bestimmt die Sortierreihenfolge. FlexMatchverwendet die Standardsortierkonvention für alphanumerische und numerische Werte.
Zulässige Werte: Jedes Attribut, das in deklariert ist
playerAttributes.Erforderlich? Ja, wenn
batchingPreference= „sortiert“. backfillPriority-
Die Priorisierungsmethode für übereinstimmende Backfill-Tickets. Diese Eigenschaft bestimmt, wann die Backfill-Tickets stapelweise FlexMatch verarbeitet werden. Sie wird nur bei der Vorsortierung mit der umfassenden Suchstrategie verwendet. Wenn diese Eigenschaft nicht festgelegt ist, ist das Standardverhalten „normal“.
Zulässige Werte:
-
„normal“ — Der Anfragetyp eines Tickets (Auffüllen oder neues Spiel) wird bei der Bildung von Matches nicht berücksichtigt.
-
„hoch“ — Ein Ticketstapel wird nach Anfragetyp (und dann nach Alter) sortiert und FlexMatch versucht zuerst, die aufgefüllten Tickets abzugleichen.
-
„niedrig“ — Ein Ticketstapel wird nach Anfragetyp (und dann nach Alter) sortiert und FlexMatch versucht zuerst, Tickets, die nicht aufgefüllt sind, abzugleichen.
Erforderlich? Nein
-
expansionAgeSelection-
Die Methode zur Berechnung der Wartezeit für eine Erweiterung der Spielregeln. Erweiterungen werden verwendet, um die Spielanforderungen zu lockern, wenn ein Spiel nach Ablauf einer bestimmten Zeit nicht abgeschlossen wurde. Die Wartezeit wird anhand des Alters der Tickets berechnet, die sich bereits für das teilweise ausgefüllte Spiel befinden. Wenn diese Eigenschaft nicht festgelegt ist, ist das Standardverhalten „neueste“.
Zulässige Werte:
-
„neueste“ — Die Wartezeit für die Erweiterung wird auf der Grundlage des Tickets mit dem Zeitstempel der letzten Erstellung des teilweise abgeschlossenen Spiels berechnet. Erweiterungen werden in der Regel langsamer ausgelöst, da ein neueres Ticket die Wartezeituhr neu starten kann.
-
„ältestes“ — Die Wartezeit für Erweiterungen wird auf der Grundlage des Tickets berechnet, das im Spiel den ältesten Erstellungszeitstempel hat. Erweiterungen werden in der Regel schneller ausgelöst.
Erforderlich? Nein
-
teams-
Die Konfiguration der Teams in einem Spiel. Geben Sie für jedes Team einen Teamnamen und einen Größenbereich an. Ein Regelsatz muss mindestens ein Team definieren.
name-
Ein eindeutiger Name für das Team. Teamnamen können in Regeln und Erweiterungen verwendet werden. Bei einem erfolgreichen Spiel werden die Spieler in den Matchmaking-Daten anhand des Teamnamens zugewiesen.
Zulässige Werte: Zeichenfolge
Erforderlich? Ja
maxPlayers-
Die maximale Anzahl an Spielern, die dem Team zugewiesen werden können.
Zulässige Werte: Zahl
Erforderlich? Ja
minPlayers-
Die Mindestanzahl an Spielern, die dem Team vor dem Spiel zugewiesen werden müssen, ist realisierbar.
Zulässige Werte: Zahl
Erforderlich? Ja
quantity-
Die Anzahl der Teams dieses Typs, die in einem Spiel gebildet werden sollen. Teams mit einer Anzahl von mehr als 1 werden mit einer angehängten Zahl gekennzeichnet („Red_1", „Red_2" usw.). Wenn diese Eigenschaft nicht festgelegt ist, ist der Standardwert „1".
Zulässige Werte: Zahl
Erforderlich? Nein
rules-
Eine Sammlung von Regelaussagen, die definieren, wie Spieler für ein Spiel bewertet werden.
Erforderlich? Nein
name-
Ein eindeutiger Name für die Regel. Alle Regeln in einem Regelsatz müssen eindeutige Namen haben. Auf Regelnamen wird in Ereignisprotokollen und Metriken verwiesen, die die Aktivitäten im Zusammenhang mit der Regel verfolgen.
Zulässige Werte: Zeichenfolge
Erforderlich? Ja
description-
Eine Textbeschreibung für die Regel. Diese Informationen können verwendet werden, um den Zweck einer Regel zu identifizieren. Es wird nicht im Matchmaking-Prozess verwendet.
Zulässige Werte: Zeichenfolge
Erforderlich? Nein
type-
Der Typ der Regelanweisung. Jeder Regeltyp hat zusätzliche Eigenschaften, die festgelegt werden müssen. Weitere Informationen zur Struktur und Verwendung der einzelnen Regeltypen finden Sie unterFlexMatch Regeltypen.
Zulässige Werte:
-
„absoluteSort“ — Sortiert mithilfe einer expliziten Sortiermethode, bei der Tickets in einem Stapel danach sortiert werden, ob ein bestimmtes Spielerattribut mit dem ältesten Ticket im Stapel vergleichbar ist.
-
„Sammlung“ — Wertet die Werte in einer Sammlung aus, z. B. ein Spielerattribut, das eine Sammlung ist, oder eine Reihe von Werten für mehrere Spieler.
-
„Vergleich“ — Vergleicht zwei Werte.
-
„Compound“ — Definiert eine zusammengesetzte Matchmaking-Regel, die eine logische Kombination anderer Regeln im Regelsatz verwendet. Wird nur für Spiele mit 40 oder weniger Spielern unterstützt.
-
„Abstand“ — Misst den Abstand zwischen Zahlenwerten.
-
„BatchDistance“ — Misst den Unterschied zwischen einem Attributwert und verwendet ihn, um Match-Anfragen zu gruppieren.
-
„DistanceSort“ — Sortiert mithilfe einer expliziten Sortiermethode, bei der Tickets in einem Stapel danach sortiert werden, wie ein bestimmtes Spielerattribut mit einem numerischen Wert im Vergleich zum ältesten Ticket im Stapel abschneidet.
-
„Latenz“ — Wertet die regionalen Latenzdaten aus, die für eine Matchmaking-Anfrage gemeldet werden.
Erforderlich? Ja
-
expansions-
Regeln zur Lockerung der Spielanforderungen im Laufe der Zeit, wenn ein Spiel nicht abgeschlossen werden kann. Richten Sie Erweiterungen als eine Reihe von Schritten ein, die schrittweise angewendet werden, damit Spiele leichter zu finden sind. FlexMatchBerechnet die Wartezeit standardmäßig anhand des Alters des neuesten Tickets, das einem Spiel hinzugefügt wurde. Mithilfe der Algorithmuseigenschaft
expansionAgeSelectionkönnen Sie ändern, wie die Wartezeiten für Erweiterungen berechnet werden.Die Wartezeiten für Erweiterungen sind absolute Werte, daher sollte für jeden Schritt eine längere Wartezeit als für den vorherigen Schritt gelten. Um beispielsweise eine schrittweise Reihe von Erweiterungen zu planen, können Sie Wartezeiten von 30 Sekunden, 40 Sekunden und 50 Sekunden verwenden. Die Wartezeiten dürfen die maximal zulässige Zeit für eine Spielanfrage, die in der Matchmaking-Konfiguration festgelegt ist, nicht überschreiten.
Erforderlich? Nein
target-
Das Regelsatzelement, das gelockert werden soll. Sie können die Eigenschaften der Teamgröße oder jede Eigenschaft einer Regelanweisung lockern. Die Syntax lautet "<component name>[< rule/team name>]. <property name>“. Zum Beispiel, um die Mindestgröße von Teams zu ändern:
teams[Red, Yellow].minPlayers. Um die Mindestanforderung an Fähigkeiten in einer Vergleichsregelanweisung mit dem Namen „minSkill“ zu ändern:rules[minSkill].referenceValue.Erforderlich? Ja
steps-
waitTimeSeconds-
Die Zeitdauer in Sekunden, die gewartet werden muss, bevor der neue Wert für das Zielregelsatzelement angewendet wird.
Erforderlich? Ja
value-
Der neue Wert für das Zielregelsatzelement.
