FlexMatch Definitionen von Regelsatzeigenschaften

In diesem Abschnitt werden alle Eigenschaften im Regelsatzschema definiert. Weitere 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 dem zugewiesen wurde Amazon GameLift Servers MatchmakingRuleSet Ressource. Dieser Wert ist in den Matchmaking-Daten enthalten, die ein abgeschlossenes Spiel beschreiben, wird aber von keinem verwendet Amazon GameLift Servers Prozesse.

Zulässige Werte: Zeichenfolge

Erforderlich? Nein

ruleLanguageVersion

Die Version der Sprache für den FlexMatch Eigenschaftsausdruck, die verwendet wird.

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, damit die Spielerdaten in den Matchmaking-Daten enthalten sind, die an die Spieleserver weitergegeben werden, auch wenn die Daten nicht für den Matchmaking-Prozess verwendet werden.

Erforderlich? Nein

name

Ein eindeutiger Name für das Spielerattribut, der 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 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 Matches verwendet werden soll. Wenn diese Eigenschaft nicht festgelegt ist, ist das Standardverhalten „ExhautiveSearch“.

Zulässige Werte:

• „ExhautiveSearch“ — Standard-Suchmethode. FlexMatch bildet eine Übereinstimmung mit dem ältesten Ticket in einem Stapel, indem andere Tickets im Pool anhand einer Reihe von benutzerdefinierten Abgleichsregeln ausgewertet werden. Diese Strategie wird für Spiele mit 40 Spielern oder weniger verwendet. Wenn Sie diese Strategie verwenden, batchingPreference sollte sie entweder auf „zufällig“ oder „sortiert“ gesetzt werden.

• „ausgewogen“ — Methode, die für die schnelle Bildung großer Treffer optimiert ist. Diese Strategie wird nur für Spiele mit 41 bis 200 Spielern verwendet. Dabei werden Spiele gebildet, indem der Ticketpool vorab sortiert, potenzielle Spiele erstellt und Spieler Teams zugewiesen werden. Anschließend wird jedes Team in einem Spiel anhand eines bestimmten Spielerattributs ausbalanciert. Diese Strategie kann beispielsweise verwendet werden, um das durchschnittliche Qualifikationsniveau aller Teams in einem Spiel auszugleichen. Wenn Sie diese Strategie verwenden, balancedAttribute muss und batchingPreference sollte entweder „LargestPopulation“ oder „FastestRegion“ festgelegt werden. Die meisten benutzerdefinierten Regeltypen werden mit dieser Strategie nicht erkannt.

Erforderlich? Ja

batchingPreference

Die Methode der Vorsortierung, die vor der Gruppierung von Tickets für die Spielzusammenstellung verwendet werden sollte. 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“ — Nur gültig mit strategy = „ExhautiveSearch“. Es erfolgt keine Vorsortierung; die Tickets im Pool werden nach dem Zufallsprinzip gestaffelt. Dies ist das Standardverhalten für eine umfassende Suchstrategie.

• „sorted“ — Nur gültig mit strategy = „ExhautiveSearch“. Der Ticketpool ist anhand der Spielerattribute vorsortiert, die unter aufgeführt sind. sortbyAttributes

• „LargestPopulation“ — Nur gültig mit strategy = „balanced“. Der Ticketpool ist nach Regionen vorsortiert, in denen Spieler akzeptable Latenzzeiten melden. Dies ist das Standardverhalten für eine ausgewogene Strategie.

• „FastestRegion“ — Nur gültig mit strategy = „balanced“. Der Ticketpool ist nach Regionen vorsortiert, in denen Spieler ihre niedrigsten Latenzzeiten melden. Die resultierenden Spiele dauern länger, bis sie abgeschlossen sind, aber die Latenz für alle Spieler ist tendenziell 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 Batching verwendet werden sollen. Diese Eigenschaft wird nur bei der Vorsortierung mit der umfassenden Suchstrategie verwendet. Die Reihenfolge der Attributliste bestimmt die Sortierreihenfolge. FlexMatch verwendet die Standardsortierkonvention für alphanumerische und numerische Werte.

Zulässige Werte: Jedes Attribut, das in deklariert istplayerAttributes.

Erforderlich? Ja, wenn batchingPreference = „sortiert“.

backfillPriority

Die Priorisierungsmethode für den Abgleich von Backfill-Tickets. Diese Eigenschaft bestimmt, wann FlexMatch verarbeitet die Backfill-Tickets stapelweise. 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“ — Der Anfragetyp eines Tickets (Auffüllen oder neuer Treffer) wird bei der Zusammenstellung von Matches nicht berücksichtigt.

• „hoch“ — Ein Ticketstapel wird nach der Art der Anfrage (und dann nach Alter) sortiert und FlexMatch versucht zuerst, Backfill-Tickets zuzuordnen.

• „niedrig“ — Ein Ticketstapel ist nach Anfragetyp (und dann nach Alter) sortiert und FlexMatch versucht zuerst, Tickets zuzuordnen, die noch nicht aufgefüllt wurden.

Erforderlich? Nein

expansionAgeSelection

Die Methode zur Berechnung der Wartezeit für eine Erweiterung der Vergleichsregel. Erweiterungen werden verwendet, um die Spielanforderungen zu lockern, wenn ein Spiel nach Ablauf einer bestimmten Zeit nicht abgeschlossen wurde. Die Wartezeit wird auf der Grundlage des Alters der Tickets berechnet, die bereits für das teilweise ausgefüllte Spiel verfügbar sind. Wenn diese Eigenschaft nicht festgelegt ist, ist das Standardverhalten „neuestes“.

Zulässige Werte:

• „neuestes“ — Die Wartezeit für die Erweiterung wird auf der Grundlage des Tickets mit dem letzten Erstellungszeitstempel im teilweise abgeschlossenen Spiel berechnet. Erweiterungen werden in der Regel langsamer ausgelöst, da mit einem neueren Ticket die Wartezeituhr neu gestartet werden kann.

• „ältestes“ — Die Wartezeit für Erweiterungen 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 Zusammensetzung 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. Auf Teamnamen kann in Regeln und Erweiterungen Bezug genommen werden. Bei einem erfolgreichen Spiel werden die Spieler in den Matchmaking-Daten nach ihrem Teamnamen zugewiesen.

Zulässige Werte: Zeichenfolge

Erforderlich? Ja

maxPlayers

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

Zulässige Werte: Zahl

Erforderlich? Ja

minPlayers

Die Mindestanzahl von Spielern, die der Mannschaft vor dem Spiel zugewiesen werden müssen, ist durchführbar.

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 gesetzt 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 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 nach einer expliziten Sortiermethode, bei der Tickets stapelweise 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.

• „Verbund“ — Definiert eine zusammengesetzte Matchmaking-Regel unter Verwendung einer logischen Kombination anderer Regeln im Regelsatz. Wird nur für Spiele mit 40 oder weniger Spielern unterstützt.

• „Entfernung“ — Misst den Abstand zwischen Zahlenwerten.

• „BatchDistance“ — Misst den Unterschied zwischen einem Attributwert und verwendet ihn, um Abgleichsanfragen zu gruppieren.

• „DistanceSort“ — Sortiert mithilfe einer expliziten Sortiermethode, bei der Tickets stapelweise sortiert werden, basierend darauf, 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 für die 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, um das Auffinden von Matches zu erleichtern. Standardmäßig FlexMatch berechnet die Wartezeit auf der Grundlage des Alters des neuesten Tickets, das zu einem Spiel hinzugefügt wurde. Mithilfe der Algorithmuseigenschaft expansionAgeSelection können Sie ändern, wie die Wartezeiten für Erweiterungen berechnet werden.

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 Erweiterungsserie zu planen, können Sie Wartezeiten von 30 Sekunden, 40 Sekunden und 50 Sekunden verwenden. Die Wartezeiten dürfen die für eine Suchanfrage zulässige Höchstzeit nicht überschreiten, die in der Matchmaking-Konfiguration festgelegt ist.

Erforderlich? Nein

target

Das Element des Regelsatzes, das gelockert werden soll. Sie können die Eigenschaften der Teamgröße oder jede andere Eigenschaft der Regelaussage 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 Wartezeit in Sekunden, bis der neue Wert für das Zielregelsatzelement angewendet wird.

Erforderlich? Ja

value

Der neue Wert für das Zielregelsatzelement.