本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 設計FlexMatch規則集
本主題涵蓋規則集的基本結構，以及如何為最多 40 名玩家的小型配對建置規則集。配對規則集會執行兩件事：配置配對的團隊結構和大小，並告知配對建構器如何選擇玩家以形成最佳的可能配對。
但您的配對規則集可以執行更多操作。例如，您可以：
+ 最佳化遊戲的配對演算法。
+ 設定最低玩家延遲要求，以保護遊戲品質。
+ 隨著時間逐漸放寬團隊要求和配對規則，讓所有作用中的玩家都能在需要時找到可接受的配對。
+ 使用方彙總定義群組配對請求的處理。
+ 處理 40 名或更多玩家的大型配對。如需建置大型配對的詳細資訊，請參閱 [設計FlexMatch大型相符規則集](match-design-rulesets-large.md)。
建置配對規則集時，請考慮下列選用和必要的任務：
+ [描述規則集 （必要）](match-rulesets-components-set.md)
+ [自訂比對演算法](match-rulesets-components-algorithm.md)
+ [宣告玩家屬性](match-rulesets-components-attributes.md)
+ [定義配對團隊](match-rulesets-components-teams.md)
+ [設定玩家配對的規則](match-rulesets-components-rules.md)
+ [允許隨著時間的推移放寬需求](match-rulesets-components-expansion.md)
您可以使用 Amazon GameLift Servers主控台或 `[CreateMatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_CreateMatchmakingRuleSet.html)`操作來建置規則集。
# 描述規則集 （必要）
提供規則集的詳細資料。
+ *name* （選用） – 供您自己使用的描述性標籤。此值與您使用 建立規則集時指定的規則集名稱無關Amazon GameLift Servers。
+ *ruleLanguageVersion* – 用來建立FlexMatch規則的屬性表達式語言版本。值必須為 `1.0`。
# 自訂比對演算法
FlexMatch 最佳化大多數遊戲的預設演算法，讓玩家以最短的等待時間進入可接受的配對。您可以自訂演算法並調整遊戲的配對。
以下是預設FlexMatch配對演算法：
1. FlexMatch 會將所有開啟的配對票證和回填票證放入票證集區。
1. FlexMatch 會將集區中的票證隨機分組為一或多個批次。隨著票證集區變大， 會FlexMatch形成額外的批次，以維持最佳的批次大小。
1. FlexMatch 會根據年齡在每個批次中排序票證。
1. FlexMatch 根據每個批次最舊的票證來建置相符項目。
若要自訂比對演算法，請將 `algorithm`元件新增至規則集結構描述。如需完整的參考資訊，[FlexMatch 規則集結構描述](match-ruleset-schema.md)請參閱 。
使用以下選用的自訂來影響配對程序的不同階段。
+ [新增批次前排序](#match-rulesets-components-algorithm-presort)
+ [根據 batchDistance 屬性形成批次 ](https://docs.aws.amazon.com//gameliftservers/latest/flexmatchguide/match-rules-reference-ruletype.html#match-rules-reference-ruletype-batchdistance)
+ [排定回填票證的優先順序](#match-rulesets-components-algorithm-backfill)
+ [偏好具有擴展的舊票證](#match-rulesets-components-algorithm-expansion)
## 新增批次前排序
您可以在形成批次之前排序票證集區。這種類型的自訂對具有大型票證集區的遊戲最有效。批次前排序有助於加速配對程序，並提高玩家在定義特性中的一致性。
使用演算法屬性 定義批次前排序方法`batchingPreference`。預設設定為 `random`。
自訂批次前排序的選項包括：
+ **依玩家屬性排序。**提供玩家屬性清單，以預先排序票證集區。
若要依玩家屬性排序，請將 `batchingPreference`設定為 `sorted`，並在 中定義玩家屬性清單`sortByAttributes`。若要使用 屬性，請先在規則集的 `playerAttributes`元件中宣告 屬性。
在下列範例中， 會根據玩家偏好的遊戲地圖來FlexMatch排序票證集區，然後依玩家技能來排序。產生的批次更有可能包含想要使用相同映射的類似熟練玩家。
```
"algorithm": {
"batchingPreference": "sorted",
"sortByAttributes": ["map", "player_skill"],
"strategy": "exhaustiveSearch"
},
```
+ **依延遲排序。**建立具有最低可用延遲的相符項目，或快速建立具有可接受延遲的相符項目。此自訂適用於規則集形成超過 40 名玩家的大型配對。
將演算法屬性`strategy`設定為 `balanced`。平衡策略會限制規則陳述式的可用類型。如需詳細資訊，請參閱[設計FlexMatch大型相符規則集](match-design-rulesets-large.md)。
FlexMatch 根據玩家報告的延遲資料，以下列其中一種方式排序票證：
+ *最低延遲位置。*票證集區會依玩家報告其最低延遲值的位置預先排序。FlexMatch然後， 會將相同位置中低延遲的票證批次處理，進而提供更佳的遊戲體驗。它也會減少每個批次中的票證數量，因此配對可能需要更長的時間。若要使用此自訂，請將 `batchingPreference`設定為 `fastestRegion`，如下列範例所示。
```
"algorithm": {
"batchingPreference": "fastestRegion",
"strategy": "balanced"
},
```
+ *可接受的延遲會快速相符。*票證集區會依玩家回報可接受延遲值的位置預先排序。這會形成包含更多票證的較少批次。隨著每個批次中有更多票證，尋找可接受的相符項目更快。若要使用此自訂，請將 屬性設定為 `batchingPreference`` largestPopulation`，如下列範例所示。
```
"algorithm": {
"batchingPreference": "largestPopulation",
"strategy": "balanced"
},
```
**注意**
平衡策略的預設值為 `largestPopulation`。
## 排定回填票證的優先順序
如果您的遊戲實作自動回填或手動回填，您可以根據請求類型自訂FlexMatch處理配對票證的方式。請求類型可以是新的比對或回填請求。根據預設， 會將這兩種類型的請求FlexMatch視為相同。
回填優先順序會影響 FlexMatch如何處理批次處理票證。回填優先順序需要規則集才能使用詳盡的搜尋策略。
FlexMatch 不符合多個回填票證。
若要變更回填票證的優先順序，請設定 屬性 `backfillPriority`。
+ **先比對回填票證。**在建立新的相符項目之前，此選項會嘗試比對回填票證。這表示傳入玩家加入現有遊戲的機率較高。
如果您的遊戲使用自動回填，最好使用此項目。自動回填通常用於具有短遊戲工作階段和高玩家周轉率的遊戲。自動回填有助於這些遊戲形成最少的可行配對，並使其開始，同時FlexMatch搜尋更多玩家來填滿開放的插槽。
將 `backfillPriority` 設定為 `high`。
```
"algorithm": {
"backfillPriority": "high",
"strategy": "exhaustiveSearch"
},
```
+ **最後比對回填票證。**此選項會忽略回填票證，直到評估所有其他票證為止。這表示當傳入玩家無法將其配對至新遊戲時， 會將他們FlexMatch回填至現有遊戲。
當您想要使用回填做為最後機會選項，讓玩家進入遊戲時，例如沒有足夠的玩家來組成新的配對時，此選項非常有用。
將 `backfillPriority` 設定為 `low`。
```
"algorithm": {
"backfillPriority": "low",
"strategy": "exhaustiveSearch"
},
```
## 偏好具有擴展的舊票證
當配對難以完成時，擴展規則會放寬配對條件。當部分完成配對中的票證達到特定年齡時， 會Amazon GameLift Servers套用擴展規則。票證的建立時間戳記會決定何時Amazon GameLift Servers套用規則；根據預設， 會FlexMatch追蹤最近相符票證的時間戳記。
若要在 FlexMatch 套用擴展規則時變更 ，請設定 屬性`expansionAgeSelection`，如下所示：
+ **根據最新的票證展開。**此選項會根據新增至潛在配對的最新票證套用擴展規則。每次FlexMatch符合新的票證時，就會重設時鐘。使用此選項時，產生的配對品質通常較高，但需要更長的時間才能配對；如果配對請求花費太長的時間才能配對，則配對請求可能會在完成之前逾時。`expansionAgeSelection` 設定為 `newest`。`newest`預設為 。
+ **根據最舊的票證展開。**此選項會根據潛在配對中最舊的票證套用擴展規則。使用此選項時， 會更快速地FlexMatch套用擴展，從而改善最早配對玩家的等待時間，但會降低所有玩家的配對品質。將 `expansionAgeSelection` 設定為 `oldest`。
```
"algorithm": {
"expansionAgeSelection": "oldest",
"strategy": "exhaustiveSearch"
},
```
# 宣告玩家屬性
在本節中，列出要在配對請求中包含的個別玩家屬性。您可能會在規則集中宣告玩家屬性的兩個原因：
+ 當規則集包含依賴玩家屬性的規則時。
+ 當您想要透過配對請求將玩家屬性傳遞至遊戲工作階段時。例如，您可能想要在每個玩家連線之前，將玩家角色選擇傳遞至遊戲工作階段。
宣告玩家屬性時，請包括下列資訊：
+ *name* （必要） – 此值對於規則集必須是唯一的。
+ *type* （必要） – 屬性值的資料類型。有效資料類型為數字、字串、字串清單或字串映射。
+ *default* （選用） – 如果配對請求不提供屬性值，請輸入要使用的預設值。如果未宣告預設值，且請求不包含值，則 FlexMatch 無法履行請求。
# 定義配對團隊
描述配對隊伍的結構和大小。每個配對都必須有至少一個隊伍，而且您可依需要定義任意數量的隊伍。所有隊伍可以有相同數量的玩家，也可以有數量不對等的玩家。例如，您可以定義一個單一玩家的怪物隊伍和一個有 10 名玩家的獵人隊伍。
FlexMatch 會根據規則集定義隊伍大小的方式，將配對請求處理為小型配對或大型配對。最多 40 名玩家的潛在配對是小型配對，超過 40 名玩家的配對是大型配對。若要確定規則集的潛在配對大小，請為規則集內定義的所有隊伍新增 *maxPlayer* 設定。
+ *name* （必要） – 為每個團隊指派唯一的名稱。您可以在規則和擴展中使用此名稱，以及遊戲工作階段中配對資料的FlexMatch參考。
+ *maxPlayers* （必要） – 指定要指派給團隊的玩家數量上限。
+ *minPlayers* （必要） – 指定要指派給團隊的玩家人數下限。
+ *quantity* （選用） – 指定使用此定義建立的團隊數量。當 FlexMatch建立配對時，它會為這些團隊提供具有附加號碼的名稱。例如 `Red-Team1`、 `Red-Team2`和 `Red-Team3`。
FlexMatch 會嘗試將隊伍填滿到玩家大小上限，但會建立較少玩家的隊伍。如果您希望配對內的所有隊伍有相同的大小，則可以對此建立規則。如需 `EqualTeamSizes`規則的範例，請參閱 [FlexMatch 規則集範例](match-examples.md)主題。
# 設定玩家配對的規則
建立一組規則陳述式，評估玩家是否接受配對。規則可能會設定適用於個別玩家、隊伍或整個配對的要求。Amazon GameLift Servers 在處理配對請求時，一開始會先在有空玩家集區中尋找停留時間最久的玩家，並圍繞該玩家來建置配對。如需建立FlexMatch規則的詳細說明，請參閱 [FlexMatch 規則類型](match-rules-reference-ruletype.md)。
+ *name* （必要） – 有意義的名稱，可唯一識別規則集中的規則。規則名稱也會於事件記錄及指標之中參照，追蹤與此規則相關的活動。
+ *description* （選用） – 使用此元素附加任意格式的文字描述。
+ *type* （必要） – 類型元素可識別處理規則時要使用的操作。每個規則類型都需要一組額外的屬性。請至 [FlexMatch 規則語言](match-rules-reference.md) 參閱有效規則類型和屬性的清單。
+ 規則類型屬性 （可能需要） – 視定義的規則類型而定，您可能需要設定特定規則屬性。請至 [FlexMatch 規則語言](match-rules-reference.md) 進一步了解屬性以及如何使用 FlexMatch 屬性運算式語言。
# 允許隨著時間的推移放寬需求
當 FlexMatch 找不到相符項目時，擴展可讓您放寬一段時間內的規則條件。此功能可確保 FlexMatch 在無法進行完美配對時提供最佳的 。透過擴展放寬規則，您可以逐步擴展可接受的玩家集區。
當不完整配對中最新票證的存留期符合擴展等待時間時，擴展就會開始。當 將新票證FlexMatch新增至配對時，擴展等待時鐘可能會重設。您可以在規則集的 `algorithm`區段中自訂擴展開始的方式。
以下是逐步增加配對所需最低技能水準的擴展範例。規則集使用名為 *SkillDelta* 的距離規則陳述式，要求配對中的所有玩家彼此在 5 個技能層級內。如果十五秒內沒有進行新的配對，則此擴展會尋找 10 的技能水準差異，十秒後則會尋找 20 的差異。
```
"expansions": [{
"target": "rules[SkillDelta].maxDistance",
"steps": [{
"waitTimeSeconds": 15,
"value": 10
}, {
"waitTimeSeconds": 25,
"value": 20
}]
}]
```
啟用自動回填的配對建構器不會太快放寬玩家計數要求。新的遊戲工作階段需要花幾秒鐘的時間才能啟動，並開始自動回填作業。更好的方法是在自動回填傾向於為您的遊戲啟動後開始擴展。擴展時間會根據您的團隊組成而有所不同，因此測試可以為您的遊戲尋找最佳的擴展策略。