FlexMatchEigenschaftsdefinitionen von Regelsätzen

In diesem Abschnitt wird jede Eigenschaft im Regelsatzschema definiert. Weitere Hilfe beim Erstellen eines Regelsatzes finden Sie unterErstellen Sie einen FlexMatch Regelsatz.

name

Eine beschreibende Bezeichnung für den Regelsatz. Dieser Wert ist nicht mit dem Namen verknüpft, der der GameLift MatchmakingRuleSetAmazon-Ressource zugewiesen wurde. Dieser Wert ist in den Matchmaking-Daten enthalten, die ein abgeschlossenes Match beschreiben, wird aber von keinen GameLift Amazon-Prozessen verwendet.

Erlaubte Werte: String

Erforderlich? Nein

ruleLanguageVersion

Die Version der verwendeten FlexMatch Eigenschaftsausdruckssprache.

Erlaubte Werte: „1.0"

Erforderlich? Ja

playerAttributes

Eine Sammlung von Spielerdaten, die in Matchmaking-Anfragen enthalten sind und im Matchmaking-Prozess verwendet werden. Du kannst hier auch Attribute deklarieren, damit die Spielerdaten in den Matchmaking-Daten enthalten sind, die an die Spielserver weitergegeben werden, auch wenn die Daten nicht für den 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 das in Matchmaking-Anfragen verwiesen wird.

Erlaubte Werte: String

Erforderlich? Ja

type

Der Datentyp des Spieler-Attributwerts.

Erlaubte Werte: „string“, „number“, „string_list“, „string_number_map“

Erforderlich? Ja

default

Ein Standardwert, der verwendet wird, wenn eine Matchmaking-Anfrage keinen für einen Spieler bereitstellt.

Zulässige Werte: Jeder zulässige Wert für das Spielerattribut.

Erforderlich? Nein

algorithm

Optionale Konfigurationseinstellungen zur Anpassung des Matchmaking-Prozesses.

Erforderlich? Nein

strategy

Die Methode, die beim Erstellen von Streichhölzern verwendet werden soll. Wenn diese Eigenschaft nicht gesetzt ist, lautet das Standardverhalten „Erschöpfungssuche“.

Zulässige Werte:

• „Erschöpfende Suche“ — Standardmethode für den Abgleich. FlexMatchbildet anhand des ältesten Tickets in einem Stapel ein Match, indem andere Tickets im Pool anhand benutzerdefinierter Spielregeln bewertet werden. Diese Strategie wird für Spiele mit 40 oder weniger Spielern angewendet. Bei Verwendung dieser Strategie batchingPreference sollte 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 angewendet. Es erstellt Matches, indem es den Ticketpool vorsortiert, potenzielle Spiele erstellt und Spieler Teams zuweist und dann jedes Team in einem Spiel anhand eines bestimmten Spielerattributs ausbalanciert. Diese Strategie kann beispielsweise verwendet werden, um die durchschnittlichen Fähigkeiten aller Teams in einem Spiel auszugleichen. Wenn diese Strategie verwendet wird, balancedAttribute muss und batchingPreference sollte entweder auf „LargestPopulation“ oder „FastestRegion“ gesetzt werden. Die meisten benutzerdefinierten Regeltypen werden bei dieser Strategie nicht erkannt.

Erforderlich? Ja

batchingPreference

Die Methode zur Vorsortierung, die verwendet werden muss, bevor Tickets für das Matchbuilding gruppiert werden. Durch die Vorsortierung des Ticketpools werden die Tickets auf der Grundlage eines bestimmten Merkmals zusammengefasst, wodurch die Einheitlichkeit der Spieler in den Endspielen tendenziell erhöht wird.

Zulässige Werte:

• „random“ — Gültig nur mit strategy = „Erschöpfende Suche“. Es erfolgt keine Vorsortierung; die Tickets im Pool werden nach dem Zufallsprinzip gebündelt. Dies ist das Standardverhalten für eine umfassende Suchstrategie.

• „sorted“ — Gültig nur mit strategy = „Erschöpfende Suche“. Der Ticketpool ist anhand der unter aufgeführten Spielerattribute vorsortiert. sortbyAttributes

• „LargestPopulation“ — Gültig nur mit strategy = „balanced“. Der Ticketpool ist vorsortiert nach Regionen, in denen Spieler akzeptable Latenzwerte angeben. Dies ist das Standardverhalten für eine ausgewogene Strategie.

• „FastestRegion“ — Gültig nur mit strategy = „balanced“. Der Ticketpool ist vorsortiert nach Regionen, in denen die Spieler ihre niedrigsten Latenzwerte angeben. Das Abschließen von Matches dauert länger, 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 der ausgewogenen Strategie verwendet werden soll.

Zulässige Werte: Jedes Attribut, das playerAttributes mit type = „Zahl“ deklariert ist.

Erforderlich? Ja, wenn strategy = „ausgewogen“.

sortByAttributes

Eine Liste von Spielerattributen, die bei der Vorsortierung des Ticketpools vor dem Stapeln verwendet werden sollen. Diese Eigenschaft wird nur bei der Vorsortierung mit der umfassenden Suchstrategie verwendet. Die Reihenfolge der Attributliste bestimmt die Sortierreihenfolge. FlexMatchverwendet die Standardsortierkonvention für Alpha- und Zahlenwerte.

Zulässige Werte: Jedes in deklarierte AttributplayerAttributes.

Erforderlich? Ja, if batchingPreference = „sortiert“.

backfillPriority

Die Priorisierungsmethode für übereinstimmende Backfill-Tickets. Diese Eigenschaft bestimmt, wann die Backfill-Tickets in einem Stapel FlexMatch verarbeitet werden. Es wird nur bei der Vorsortierung mit der umfassenden Suchstrategie verwendet. Wenn diese Eigenschaft nicht gesetzt ist, ist das Standardverhalten „normal“.

Zulässige Werte:

• „normal“ — Die Art der Anfrage eines Tickets (Backfill oder neuer Treffer) wird bei der Bildung von Matches nicht berücksichtigt.

• „hoch“ — Ein Ticketstapel wird nach Anfragetyp (und dann nach Alter) sortiert und FlexMatch versucht zunächst, aufgefüllte Tickets abzugleichen.

• „niedrig“ — Ein Ticketstapel wird nach Anfragetyp (und dann nach Alter) sortiert und FlexMatch versucht zunächst, Tickets ohne Backfill 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 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 gesetzt ist, ist das Standardverhalten „am neuesten“.

Zulässige Werte:

• „neueste“ — Die Wartezeit der Erweiterung wird auf der Grundlage des Tickets mit dem letzten Erstellungszeitstempel des teilweise abgeschlossenen Spiels berechnet. Erweiterungen werden in der Regel langsamer ausgelöst, da ein neueres Ticket die Wartezeit neu starten kann.

• „älteste“ — Die Wartezeit der Erweiterung wird auf der Grundlage des Tickets mit dem ältesten Erstellungszeitstempel im Spiel berechnet. 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 einzigartiger Name für das Team. Teamnamen können in Regeln und Erweiterungen erwähnt werden. Bei einem erfolgreichen Spiel werden die Spieler in den Matchmaking-Daten nach Teamnamen zugewiesen.

Erlaubte Werte: String

Erforderlich? Ja

maxPlayers

Die maximale Anzahl von Spielern, die dem Team zugewiesen werden können.

Zulässige Werte: Zahl

Erforderlich? Ja

minPlayers

Die Mindestanzahl an Spielern, die der Mannschaft zugewiesen werden müssen, bevor das Spiel ausgetragen werden kann.

Zulässige Werte: Zahl

Erforderlich? Ja

quantity

Die Anzahl der Teams dieses Typs, die in einem Spiel erstellt werden sollen. Teams mit Mengen von mehr als 1 werden mit einer angehängten Zahl gekennzeichnet („Red_1", „Red_2" usw.). Wenn diese Eigenschaft nicht gesetzt ist, ist der Standardwert „1".

Zulässige Werte: Zahl

Erforderlich? Nein

rules

Eine Sammlung von Regelbestimmungen, 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. Regelnamen werden in Ereignisprotokollen und Metriken referenziert, die Aktivitäten im Zusammenhang mit der Regel verfolgen.

Erlaubte Werte: String

Erforderlich? Ja

description

Eine Textbeschreibung für die Regel. Diese Informationen können verwendet werden, um den Zweck einer Regel zu identifizieren. Es wird im Matchmaking-Prozess nicht verwendet.

Erlaubte Werte: String

Erforderlich? Nein

type

Die Art der Regelaussage. Jeder Regeltyp hat zusätzliche Eigenschaften, die festgelegt werden müssen. Weitere Informationen zur Struktur und Verwendung der einzelnen Regeltypen finden Sie unterFlexMatchRegeltypen.

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 verglichen wird.

• „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. Richte Erweiterungen als eine Reihe von Schritten ein, die schrittweise angewendet werden, damit Matches leichter zu finden sind. FlexMatchBerechnet standardmäßig die Wartezeit auf der Grundlage des Alters des neuesten Tickets, das einem Spiel hinzugefügt wurde. Sie können mithilfe der Algorithmuseigenschaft ändern, wie die Wartezeiten für Erweiterungen berechnet werdenexpansionAgeSelection.

Bei den Wartezeiten für Erweiterungen handelt es sich um absolute Werte, sodass für jeden Schritt eine längere Wartezeit als für den vorherigen Schritt gelten sollte. 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 nicht überschreiten, die in der Matchmaking-Konfiguration festgelegt ist.

Erforderlich? Nein

target

Das Regelsatzelement, das gelockert werden soll. Sie können die Eigenschaften für die Teamgröße oder jede Eigenschaft mit Regelanweisungen 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 Vergleichsregel mit dem Namen „minSkill“ zu ändern:rules[minSkill].referenceValue.

Erforderlich? Ja

steps

waitTimeSeconds

Die Wartezeit in Sekunden, bevor der neue Wert auf das Zielregelsatzelement angewendet wird.

Erforderlich? Ja

value

Der neue Wert für das Zielregelsatzelement.