FlexMatch規則集性質定義

本節定義規則集結構描述中的每個屬性。如需建立規則集的其他說明，請參閱建置 FlexMatch 規則集。

name

規則集的描述性標籤。此值與指派給 Amazon GameLift MatchmakingRuleSet資源的名稱無關聯。此值包含在描述完成比對的配對資料中，但不會被任何 Amazon GameLift 程序使用。

允許的值：字串

是否為必要？ 否

ruleLanguageVersion

所使用的FlexMatch屬性表示式語言版本。

允許的值：「1.0」

是否為必要？ 是

playerAttributes

包含在配對要求中的玩家資料集合，並在配對過程中使用。您也可以在此處宣告屬性，讓玩家資料包含在傳送至遊戲伺服器的配對資料中，即使資料並未在配對過程中使用。

是否為必要？ 否

name

分房系統使用的玩家屬性的唯一名稱。此名稱必須與配對要求中參照的玩家屬性名稱相符。

允許的值：字串

是否為必要？ 是

type

播放器屬性值的數據類型。

允許的值：「字符串」，「數字」，「字符串列表」，「字符串數字 _ 映射」

是否為必要？ 是

default

配對請求未提供給玩家時所使用的預設值。

允許的值：播放程式屬性允許的任何值。

是否為必要？ 否

algorithm

用於自訂配對程序的選擇性組態設定。

是否為必要？ 否

strategy

建立相符項目時要使用的方法。如果未設定此屬性，預設行為是「詳盡搜尋」。

允許的值：

• 「詳盡搜索」— 標準匹配方法。FlexMatch透過根據一組自訂比對規則評估池中的其他工單，圍繞批次中最舊的工單組成比對。此策略用於 40 名以下玩家的比賽。使用此策略時，batchingPreference應設置為「隨機」或「排序」。

• 「平衡」— 優化以快速形成大型比賽的方法。此策略僅用於 41 至 200 名玩家的比賽。它通過預先排序彩票池，建立潛在的比賽並將球員分配給團隊，然後使用指定的球員屬性在比賽中平衡每個球隊來形成比賽。例如，此策略可用於平衡一場比賽中所有隊伍的平均技能水平。使用此策略時，balancedAttribute必須設置，並且batchingPreference應該設置為「最大人口」或「最大人口」。大多數自訂規則類型無法透過此策略辨識。

是否為必要？ 是

batchingPreference

在將票證分組以進行比賽建立之前使用的預先排序方法。預先排序彩票池會導致彩票根據特定特徵進行批次處理，這往往會增加最終比賽中各玩家的一致性。

允許的值：

• 「隨機」-僅在 strategy =「詳盡搜索」時有效。沒有預先排序; 池中的門票是隨機批量的。這是詳盡搜尋策略的預設行為。

• 「排序」-僅適用於 strategy =「詳盡搜索」。彩票池根據中sortbyAttributes列出的玩家屬性進行預先排序。

• 「人口最大」-僅在 strategy =「平衡」的情況下有效。彩票集區會依玩家報告可接受延遲等級的地區進行預先排序。這是平衡策略的預設行為。

• 「快速傳統」— 僅在 strategy =「平衡」的情況下有效。彩票集區會依玩家報告其最低延遲等級的地區進行預先排序。由此產生的比賽需要更長的時間才能完成，但所有玩家的延遲時間往往很低。

是否為必要？ 是

balancedAttribute

使用平衡策略建立大型比賽時要使用的玩家屬性名稱。

允許的值：在中宣告playerAttributes的任何屬性 type =「數字」。

是否為必要？ 是的，如果 strategy =「平衡」。

sortByAttributes

在批次處理之前預先排序票證池時要使用的玩家屬性列表。只有在使用詳盡搜尋策略進行預先排序時，才會使用此屬性。屬性清單的順序決定了排序順序。FlexMatch使用字母和數值的標準排序慣例。

允許的值：在中宣告的任何屬性playerAttributes。

是否為必要？ 是的，如果 batchingPreference =「排序」。

backfillPriority

比對回填工單的優先順序排列方法。此屬性決定何時FlexMatch處理批次回填工單。僅在使用詳盡搜索策略進行預排序時使用。如果未設定此屬性，則預設行為為為「normal」。

允許的值：

• 「一般」— 在組成比賽時，不會考慮票券的請求類型（回填或新配對）。

• 「高」— 工單批次會依請求類型 (然後按年齡) 排序，並FlexMatch嘗試先比對回填票證。

• 「low」— 工單批次會依要求類型 (然後按年齡排序) 排序，並FlexMatch嘗試先比對非回填票證。

是否為必要？ 否

expansionAgeSelection

用於計算比對規則擴充等待時間的方法。如果在一段時間過後仍未完成比賽，資料片將用於放鬆對戰需求。等待時間是根據已在部分填寫的比賽中的門票年齡計算的。如果未設定此屬性，預設行為是「最新」。

允許的值：

• 「最新」— 擴充等待時間是根據在部分完成比賽中具有最新建立時間戳記的工單來計算。擴充的觸發速度往往較慢，因為一個較新的工單可以重新啟動等待時間時鐘。

• 「最舊」— 擴充等待時間是根據比賽中建立時間戳記最早的票證來計算。資料片往往會更快地觸發。

是否為必要？ 否

teams

比賽中團隊的配置。為每個團隊提供團隊名稱和大小範圍。規則集必須至少定義一個群組。

name

專案團隊的唯一名稱。專案團隊名稱可以在規則和展開中參照。在成功的對戰中，玩家會在配對資料中依隊伍名稱指派。

允許的值：字串

是否為必要？ 是

maxPlayers

可以分配給團隊的玩家數量上限。

允許的值：數字

是否為必要？ 是

minPlayers

比賽開始前必須分配給球隊的最低球員數量。

允許的值：數字

是否為必要？ 是

quantity

要在一場比賽中建立的此類型的隊伍數量。數量大於 1 的專案團隊會附加一個數字 (「Red_1」、「Red_2」等)。如果未設定此屬性，預設值為「1」。

允許的值：數字

是否為必要？ 否

rules

規則語句的集合，用於定義如何評估比賽的玩家。

是否為必要？ 否

name

規則的唯一名稱。規則集中的所有規則都必須具有唯一的名稱。規則名稱會在追蹤與規則相關活動的事件記錄檔和量度中參照。

允許的值：字串

是否為必要？ 是

description

規則的文字描述。此資訊可用於識別規則的用途。它不會在配對過程中使用。

允許的值：字串

是否為必要？ 否

type

規則陳述式的類型。每個規則類型都有其他必須設定的屬性。如需每種規則類型結構和使用方式的詳細資訊，請參閱FlexMatch規則類型。

允許的值：

• 「AbsoluteSort」— 使用明確排序方法排序，該方法會根據指定的播放器屬性是否與批次中最舊的工單進行比較，以批次排序工單。

• 「收藏」— 評估集合中的值，例如收藏的玩家屬性，或多個玩家的一組值。

• 「比較」-比較兩個值。

• 「複合」— 使用規則集中其他規則的邏輯組合來定義複合配對規則。僅支援 40 人以下玩家的比賽。

• 「距離」— 測量數值之間的距離。

• 「批次距離」— 測量屬性值之間的差異，並使用它來分組比對請求。

• 「DispanceSort」— 使用明確的排序方法進行排序，該方法會根據具有數值的指定玩家屬性與批次中最舊票證的比較，在批次中排序票證。

• 「延遲」— 評估配對要求所報告的區域延遲資料。

是否為必要？ 是

expansions

在比賽無法完成時隨著時間的推移放寬比賽要求的規則。將資料片設定為逐步套用的一系列步驟，以便更容易找到相符項目。根據預設，FlexMatch會根據新增至比賽的最新票券的年齡計算等待時間。您可以使用 algorithm 屬性變更擴充等待時間的計算方式expansionAgeSelection。

擴充等待時間是絕對值，因此每個步驟的等待時間都應該比上一個步驟長。例如，若要排程逐步擴充系列，您可以使用 30 秒、40 秒和 50 秒的等待時間。等待時間不能超過匹配請求允許的最長時間，這是在配對配置中設置的。

是否為必要？ 否

target

要放鬆的規則集元素。您可以放鬆群組大小屬性或任何規則陳述式屬性。語法為 "<component name>[<rule/team name>]。 <property name>」. 例如，要更改團隊的最小規模：teams[Red, Yellow].minPlayers。若要變更名為「minSchle」的比較規則陳述式中的最低技能需求，請執行下列動作：rules[minSkill].referenceValue

是否為必要？ 是

steps

waitTimeSeconds

在套用目標規則集元素的新值之前等待的時間長度 (以秒為單位)。

是否為必要？ 是

value

目標規則集元素的新值。