本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 綁定Amazon GameLift Servers FlexMatch配對建構器
本節說明配對建構器的關鍵元素，以及如何為您的遊戲建立和自訂。這包括設定配對組態和配對規則集。
建立配對建構器是FlexMatch藍圖中的第一個步驟：
+ [路線圖：將配對新增至Amazon GameLift Servers託管解決方案](match-tasks.md)
+ [路線圖：使用 建立獨立的配對解決方案 FlexMatch](match-tasks-safm.md)
FlexMatch 配對建構器會執行建立遊戲配對的工作。它會管理收到的配對請求集區、處理和選取玩家以尋找最佳的可能玩家群組，並組成隊伍進行配對。對於使用 Amazon GameLift Servers 託管的遊戲，它也會放置並啟動配對的遊戲工作階段。
FlexMatch 會將配對服務與自訂規則引擎結合在一起。這樣您就可以設計如何依據對遊戲合理的玩家屬性及遊戲模式，將玩家配對在一起，並仰賴 FlexMatch 管理細節形成玩家群組，並將其置於遊戲之中。請參閱[FlexMatch 規則集範例](match-examples.md)中的自訂配對詳細資訊。
形成配對後， FlexMatch會提供遊戲工作階段放置的配對資料。對於使用 Amazon GameLift Servers託管的遊戲， FlexMatch 會將具有配對玩家的遊戲工作階段置放請求傳送至遊戲工作階段佇列。佇列會搜尋 Amazon GameLift Servers 機群可用的託管資源，並針對配對啟動新的遊戲工作階段。對於使用其他託管解決方案的遊戲， FlexMatch 會提供配對資料，供您提供給自己的遊戲工作階段置放元件。
如需 FlexMatch 配對建構器如何處理收到的配對請求詳細說明，請參閱 [FlexMatch 配對程序](gamelift-match-howitworks.md)。
**Topics**
+ [設計FlexMatch配對建構器](match-configuration.md)
+ [建置FlexMatch規則集](match-rulesets.md)
+ [建立配對組態](match-create-configuration.md)
+ [設定FlexMatch事件通知](match-notification.md)
# 設計FlexMatch配對建構器
本主題提供如何設計適合您遊戲的配對建構器的指引。
**Topics**
+ [設定基本配對建構器](#match-configuration-elements)
+ [選擇配對建構器的位置](match-configuration-regions.md)
+ [新增選用元素](match-configuration-options.md)
## 設定基本配對建構器
配對建構器至少需要下列元素：
+ **規則集**會為配對決定團隊的大小和範圍，並定義在為配對評估玩家時要使用的規則集。會將每個配對建構器設定為使用一個規則集。請參閱 [建置FlexMatch規則集](match-rulesets.md) 和 [FlexMatch 規則集範例](match-examples.md)。
+ **通知目標**會收到所有配對事件通知。您需要設定 Amazon Simple Notification Service (SNS) 主題，然後將主題 ID 新增至配對建構器。如需有關設定通知的詳細資訊，請參閱 [設定FlexMatch事件通知](match-notification.md)。
+ **請求逾時**會決定配對建構請求在請求集區中保留的時間，並評估可能的配對。一旦請求已逾時，即無法進行配對並從集區中移除。
+ FlexMatch 搭配Amazon GameLift Servers受管託管使用 時，**遊戲工作階段佇列**會尋找最佳可用資源來託管配對的遊戲工作階段，並啟動新的遊戲工作階段。每個佇列都會設定位置和資源類型清單 （包括 Spot 或隨需執行個體），以決定遊戲工作階段可以放置的位置。如需佇列的詳細資訊，請參閱[使用多位置佇列](https://docs.aws.amazon.com/gamelift/latest/developerguide/queues-intro.html)。
# 選擇配對建構器的位置
決定您希望配對活動在何處進行，並在該位置建立配對組態和規則集。 Amazon GameLift Servers會維護遊戲配對請求的票證集區，在其中進行排序和評估是否有可行的配對。進行配對後， 會Amazon GameLift Servers傳送遊戲工作階段放置的配對詳細資訊。您可以在託管解決方案支援的任何位置執行相符的遊戲工作階段。
如需可建立FlexMatch資源的位置，[FlexMatch 支援 AWS 區域](match-regions.md)請參閱 。
AWS 區域 為您的配對建構器選擇 時，請考慮位置如何影響效能，以及它如何最佳化玩家的配對體驗。建議遵循下列最佳實務：
+ 將配對建構器放置在靠近您的玩家和傳送FlexMatch配對請求的用戶端服務的位置。此方法可減少配對請求工作流程的延遲影響，並使其更有效率。
+ 如果您的遊戲觸及全球觀眾，請考慮在多個位置建立配對建構器，並將配對請求路由到最接近玩家的配對建構器。除了提高效率之外，這還會導致票證集區與地理位置接近的玩家形成，這改善了配對建構器根據延遲要求配對玩家的能力。
+ FlexMatch 搭配Amazon GameLift Servers受管託管使用 時，請將您的配對建構器及其使用的遊戲工作階段佇列放在相同的位置。這有助於將配對建構器和佇列之間的通訊延遲降到最低。
# 新增選用元素
除了這些最低要求以外，您可以使用下列額外選項來設定配對建構器。如果您使用 FlexMatch搭配 Amazon GameLift Servers託管解決方案，則會內建許多功能。如果您使用 FlexMatch做為獨立配對服務，建議您將這些功能建置到您的系統中。
**玩家接受**
您可以設定配對建構器，要求所有選擇配對的玩家都必須接受參與。如果您的系統需要接受，所有玩家都必須選擇接受或拒絕提議的配對。配對必須接收到來自提議配對中所有玩家的接受，才能完成。如果任何玩家拒絕或無法接受配對，則會捨棄提議的配對，並依照下列方式處理票證。票證中所有玩家都接受配對的票證會傳回配對集區以繼續處理。至少有一個玩家拒絕配對或無法回應的票證會進入失敗狀態，且不再處理。玩家接受需要時間限制；所有玩家都必須在時間限制內接受提議的配對，配對才能繼續。
**回填模式**
使用FlexMatch回填，讓您的遊戲工作階段在遊戲工作階段的整個生命週期內都充滿配對良好的新玩家。處理回填請求時， FlexMatch會使用與用來比對原始玩家的相同配對建構器。您可以自訂回填票證的優先順序，以及新配對的票證，將回填票證放在行的前面或結尾。這表示，當新玩家進入配對集區時，他們被放置在現有遊戲的可能性高於或低於新形成的遊戲。
無論您的遊戲FlexMatch搭配 受管Amazon GameLift Servers託管或其他託管解決方案使用 ，都可以手動回填。手動回填可讓您靈活地決定何時觸發回填請求。例如，您可能只想在遊戲的特定階段或特定條件存在時新增玩家。
自動回填僅適用於使用受管Amazon GameLift Servers託管的遊戲。啟用此功能後，如果遊戲工作階段從開啟的玩家位置開始， 會Amazon GameLift Servers開始自動為其產生回填請求。此功能可讓您設定配對，讓新遊戲以最少玩家數量開始，然後在新玩家進入配對集區時快速填滿。您可以在遊戲工作階段生命週期期間隨時關閉自動回填。
**遊戲屬性**
對於使用 FlexMatch搭配 Amazon GameLift Servers受管託管的遊戲，您可以提供其他資訊，以便在請求新的遊戲工作階段時傳遞至遊戲伺服器。這可能是傳遞遊戲模式組態的有用方法，這些組態是為要建立的配對類型啟動遊戲工作階段所需的。配對建構器建立的所有配對遊戲工作階段都會收到相同的一組遊戲屬性。您可以透過建立不同的配對組態來改變遊戲屬性資訊。
**預留玩家空位**
您可以指定要在每個配對中保留的特定玩家空位，並在稍後補上。您可以透過設定配對建構組態的「額外玩家數目」進行。
**自訂事件資料**
使用此屬性來為配對建構器包含在所有配對建構相關事件中的一組自訂資訊。在追蹤遊戲特定活動時 (包含追蹤配對建構器的效能)，此功能非常有用。
# 建置FlexMatch規則集
每個 FlexMatch 配對建構器都必須具有規則集。規則集判定配對的兩項關鍵要素：您的遊戲團隊結構及規模，以及如何將玩家分組在一起以達到最佳的配對。
例如規則集可能以下列方式說明配對：以兩個團隊建立配對，每個團隊各有五位玩家，其中一隊是防守者，另一隊則是入侵者。團隊可以有新手和經驗豐富的玩家，但兩個團隊的平均技能必須彼此相距 10 點以內。如果 30 秒後沒有找到配對，請逐漸放寬技巧要求。
本節主題說明如何設計和建置配對規則集。建立規則集時，您可以使用 Amazon GameLift Servers主控台或 AWS CLI。
**Topics**
+ [設計FlexMatch規則集](match-design-ruleset.md)
+ [設計FlexMatch大型相符規則集](match-design-rulesets-large.md)
+ [教學課程：建立配對規則集](match-create-ruleset.md)
+ [FlexMatch 規則集範例](match-examples.md)
# 設計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
}]
}]
```
啟用自動回填的配對建構器不會太快放寬玩家計數要求。新的遊戲工作階段需要花幾秒鐘的時間才能啟動，並開始自動回填作業。更好的方法是在自動回填傾向於為您的遊戲啟動後開始擴展。擴展時間會根據您的團隊組成而有所不同，因此測試可以為您的遊戲尋找最佳的擴展策略。
# 設計FlexMatch大型相符規則集
如果您的規則集建立允許 41 到 200 名玩家的相符項目，則需要對規則集組態進行一些調整。這些調整會最佳化配對演算法，使其可以建立可行的大型配對，同時讓玩家等待時間縮短。因此，大型配對規則集會使用針對常見配對優先順序最佳化的標準解決方案來取代耗時的自訂規則。
以下是如何判斷是否需要針對大型比對最佳化規則集的方法：
1. 對於規則集中定義的每個團隊，取得 *maxPlayer* 的值，
1. 新增所有 *maxPlayer* 值。如果總計超過 40，表示您有一個大型比對規則集。
若要針對大型比對最佳化您的規則集，請進行如下所述的調整。請參閱 中大型比對規則集的結構描述，[大型比對的規則集結構描述](match-ruleset-schema-large.md)以及 中的規則集範例[範例：建立大型比對](match-examples-7.md)。
# 自訂大型比對的比對演算法
如果尚未存在演算法元件，請將演算法元件新增至規則集。設定下列屬性。
+ `strategy` （必要） – 將 `strategy` 屬性設定為「平衡」。此設定會觸發 FlexMatch進行額外的配對後檢查，以根據 `balancedAttribute` 屬性中定義的指定玩家屬性來尋找最佳團隊平衡。平衡策略取代了自訂規則建置平均配對團隊的需求。
+ `balancedAttribute` （必要） – 識別在配對中平衡隊伍時要使用的玩家屬性。此屬性必須具有數值資料類型 （雙或整數）。例如，如果您選擇平衡玩家技能， FlexMatch 會嘗試指派玩家，讓所有隊伍擁有盡可能平均配對的彙總技能等級。平衡屬性必須在規則集的玩家屬性中宣告。
+ `batchingPreference` （選用） – 選擇您希望為玩家設定最低延遲配對的重點程度。此設定會影響在建置相符項目之前，配對票證的排序方式。選項包括：
+ 最大人口。 FlexMatch 允許配對使用集區中具有可接受延遲值的所有票證，在至少一個共同位置。因此，潛在的票證集區往往很大，因此更容易更快地填滿相符項目。玩家可能會放置在具有可接受但不一定最佳延遲的遊戲中。如果未設定 `batchingPreference` 屬性，則當 `strategy` 設定為「平衡」時，這是預設行為。
+ 最快的位置。 會根據報告最低延遲值的位置，FlexMatch預先排序集區中的所有票證。因此，配對通常會與在同一位置報告低延遲的玩家形成。同時，每個配對的潛在票證集區較小，這可能會增加填滿配對所需的時間。此外，由於延遲的優先順序較高，因此配對中的玩家在平衡屬性方面可能會有更大的差異。
下列範例會將比對演算法設定為行為如下：(1) 預先排序票證集區，以依其具有可接受延遲值的位置分組票證；(2) 形成排序票證的批次以進行比對；(3) 建立與批次票證的比對，並平衡團隊以平衡平均玩家技能。
```
"algorithm": {
"strategy": "balanced",
"balancedAttribute": "player_skill",
"batchingPreference": "largestPopulation"
},
```
# 宣告玩家屬性
請務必宣告在規則集演算法中用作平衡屬性的玩家屬性。配對請求中應包含每個玩家的此屬性。您可以為玩家屬性提供預設值，但在提供玩家特定值時，屬性平衡效果最好。
# 定義團隊
在定義隊伍大小和結構時，其程序與小型配對相同，但 FlexMatch 填滿隊伍的方式會不同。這會影響只有部分填滿時配對可能看起來的樣子。您可能需要調整團隊大小下限以回應。
FlexMatch 在將玩家指派給隊伍時，會使用以下規則。首先：尋找尚未達到其玩家要求下限的隊伍。其次：在這些隊伍中，尋找有最多空位的隊伍。
若配對定義了多個大小一樣的隊伍，系統會循序地將玩家新增到每個隊伍，直到隊伍填滿。因此，配對中的隊伍一定有近乎相等的玩家人數，即使配對不完整也一樣。目前無法強制讓大型配對中的隊伍都有一樣的大小。若配對的隊伍大小不對稱，則程序會更複雜一些。在此案例中，玩家一開始會指派給擁有最多開放位置的最大隊伍。隨著開放的空位數量在所有隊伍中變得更加平均，玩家會進入較小的隊伍。
例如，假設您有一個規則集，其中包含三個團隊。紅色和藍色團隊都設定為 `maxPlayers`=10， `minPlayers`=5。綠色團隊設定為 `maxPlayers`=3， `minPlayers`=2。以下是填充順序：
1. 沒有團隊達到 `minPlayers`。紅色和藍色隊伍有 10 個空位，綠色隊伍則有 3 個。前 10 名玩家會指派給紅色和藍色隊伍 (每個隊伍各 5 名)。兩個團隊現在都已達到 `minPlayers`。
1. 綠色團隊尚未達到 `minPlayers`。接下來的 2 名玩家會指派給綠色隊伍。綠色團隊現在已達到 `minPlayers`。
1. 在 的所有隊伍中`minPlayers`，現在會根據開放的空位數指派其他玩家。紅色和藍色團隊各有 5 個開放插槽，而綠色團隊則有 1 個。接下來的 8 名玩家 （各 4 名） 會指派給紅藍隊伍。所有團隊現在都有 1 個開放槽。
1. 其餘的 3 個玩家位置會 （每個 1 個） 指派給團隊，沒有特定順序。
# 設定大型比對的規則
大型配對的配對主要依賴平衡策略和延遲批次最佳化。因此大多數的自訂規則都無法使用。不過，您可以納入下列類型的規則：
+ 設定玩家延遲硬性限制的規則。使用`latency`規則類型搭配 屬性 `maxLatency`。請參閱[延遲規則](match-rules-reference-ruletype.md#match-rules-reference-ruletype-latency)參考。以下範例會將玩家延遲上限設定為 200 毫秒：
```
"rules": [{
"name": "player-latency",
"type": "latency",
"maxLatency": 200
}],
```
+ 根據指定玩家屬性中的親近度批次玩家的規則。這與將平衡屬性定義為大型相符演算法的一部分不同，該演算法著重於建置平均相符的團隊。此規則會根據指定屬性值中的相似性批次處理配對票證，例如初學者或專家技能，這往往會導致與指定屬性上緊密一致的配對玩家。使用`batchDistance`規則類型，識別以數字為基礎的屬性，並指定要允許的最寬範圍。請參閱[批次距離規則](match-rules-reference-ruletype.md#match-rules-reference-ruletype-batchdistance)參考。以下是呼叫配對玩家彼此處於一個技能水準的範例：
```
"rules": [{
"name": "batch-skill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 1
```
# 放寬大型比對需求
和小型配對一樣，您也可以使用擴展，在無法達成有效配對時，隨時間放寬配對要求。對於大型配對，您可以選擇放寬延遲規則或隊伍玩家計數。
如果您對大型配對使用自動配對回填功能，請避免過於快速地放寬玩家人數。FlexMatch 只會在遊戲工作階段開始後，才開始產生回填請求，因此可能不會在建立配對後的幾秒鐘就發生。在這段時間內，FlexMatch 可能會建立多個部分填滿的新遊戲工作階段，尤其是當玩家人數規則調降時。因此，您最終會有比所需數量還多的遊戲工作階段，而讓玩家稀疏地分散到這些工作階段。最佳實務是讓玩家人數擴展的第一個步驟有較長的等待時間，且時間長到足以讓遊戲工作階段開始。由於大型配對的回填請求有較高的優先順序，因此在新的遊戲開始之前，系統會將進入的玩家安插到現有遊戲。您可能需要進行實驗以找出遊戲的理想等待時間。
以下範例會使用較長的初始等待時間來逐步降低黃色隊伍的玩家人數。請記住，規則集擴展的等待時間是絕對值，不能使用複合值。因此，第一個擴展發生在 5 秒時，第二個擴展則發生在 5 秒之後，也就是 10 秒時。
```
"expansions": [{
"target": "teams[Yellow].minPlayers",
"steps": [{
"waitTimeSeconds": 5,
"value": 8
}, {
"waitTimeSeconds": 10,
"value": 5
}]
}]
```
# 教學課程：建立配對規則集
在您為配對Amazon GameLift ServersFlexMatch建構器建立配對規則集之前，建議您檢查[規則集語法](match-rules-reference.md)。使用Amazon GameLift Servers主控台或 AWS Command Line Interface (AWS CLI) 建立規則集後，您無法變更規則集。
請注意，您可以在 區域中擁有的規則集數目上限有[服務配額](https://console.aws.amazon.com/servicequotas/home/services/gamelift/quotas/) AWS ，因此最好刪除未使用的規則集。
**Topics**
------
#### [ Console ]
**建立規則集**
1. 在 https：//[https://console.aws.amazon.com/gamelift/](https://console.aws.amazon.com/gamelift/) 開啟 Amazon GameLift Servers主控台。
1. 切換到您要建立規則集 AWS 的區域。在與使用規則的配對組態相同的區域中定義規則集。
1. 在導覽窗格中，選擇 **FlexMatch**、**配對規則集**。
1. 在**配對規則集**頁面上，選擇**建立規則集**。
1. 在**建立配對規則集**頁面上，執行下列動作：
1. 在**規則集設定**下，針對**名稱**輸入唯一的描述性名稱，可用於在清單或事件和指標資料表中識別它。
1. 針對**規則集**，以 JSON 輸入您的規則集。如需設計規則集的資訊，請參閱 [設計FlexMatch規則集](match-design-ruleset.md)。您也可以從 使用其中一個範例規則集[FlexMatch 規則集範例](match-examples.md)。
1. 選擇**驗證**以驗證規則集的語法是否正確。您無法在規則集建立後對其進行編輯，因此最好先進行驗證。
1. （選用） 在**標籤**下，新增標籤以協助您管理和追蹤 AWS 資源。
1. 選擇**建立**。如果建立成功，您可以搭配配對建構器使用規則集。
------
#### [ AWS CLI ]
**建立規則集**
開啟命令列視窗，並使用命令 [create-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-rule-set.html)。
此範例命令會建立簡單的配對規則集，以設定單一團隊。請務必在與使用它的配對組態相同的 AWS 區域中建立規則集。
```
aws gamelift create-matchmaking-rule-set \
--name "SampleRuleSet123" \
--rule-set-body '{"name": "aliens_vs_cowboys", "ruleLanguageVersion": "1.0", "teams": [{"name": "cowboys", "maxPlayers": 8, "minPlayers": 4}]}'
```
如果建立請求成功， 會Amazon GameLift Servers傳回包含您指定設定的 [MatchmakingRuleSet](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingRuleSet.html) 物件。配對建構器現在可以使用新的規則集。
------
------
#### [ Console ]
**刪除規則集**
1. 在 https：//[https://console.aws.amazon.com/gamelift/](https://console.aws.amazon.com/gamelift/) 開啟 Amazon GameLift Servers主控台。
1. 切換到您在其中建立規則集的區域。
1. 在導覽窗格中，選擇 **FlexMatch**、**配對規則集**。
1. 在**配對規則集**頁面上，選取您要刪除的規則集，然後選擇**刪除**。
1. 在**刪除規則集**對話方塊中，選擇**刪除**以確認刪除。
**注意**
如果配對組態正在使用規則集， Amazon GameLift Servers會顯示錯誤訊息 (**無法刪除規則集**)。如果發生這種情況，請將配對組態變更為使用不同的規則集，然後再試一次。若要了解哪些配對組態正在使用規則集，請選擇規則集的名稱以檢視其詳細資訊頁面。
------
#### [ AWS CLI ]
**刪除規則集**
開啟命令列視窗，並使用命令 [delete-matchmaking-rule-set](https://docs.aws.amazon.com/cli/latest/reference/gamelift/delete-matchmaking-rule-set.html) 刪除配對規則集。
如果配對組態正在使用規則集， 會Amazon GameLift Servers傳回錯誤訊息。如果發生這種情況，請將配對組態變更為使用不同的規則集，然後再試一次。若要取得哪些配對組態正在使用規則集的清單，請使用 命令 [describe-matchmaking-configurations](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-matchmaking-configurations.html) 並指定規則集名稱。
此範例命令會檢查配對規則集的使用情況，然後刪除規則集。
```
aws gamelift describe-matchmaking-rule-sets \
--rule-set-name "SampleRuleSet123" \
--limit 10
aws gamelift delete-matchmaking-rule-set \
--name "SampleRuleSet123"
```
------
# FlexMatch 規則集範例
FlexMatch 規則集可以涵蓋各種配對案例。下列的範例遵循 FlexMatch 組態架構和屬性表達式語言。請根據需要完整複製這些規則集，或選擇其中的元件。
關於使用 FlexMatch 規則與規則集，詳細資訊請參閱下列主題：
**注意**
在評估包含多個玩家的配對單時，請求中的所有玩家皆必須符合配對要求。
**Topics**
+ [範例：建立兩個具有平均配對玩家的隊伍](match-examples-1.md)
+ [範例：建立不均勻的團隊 （獵人與怪物）](match-examples-2.md)
+ [範例：設定團隊層級需求和延遲限制](match-examples-3.md)
+ [範例：使用明確排序來尋找最佳相符項目](match-examples-4.md)
+ [範例：尋找跨多個玩家屬性的交集](match-examples-5.md)
+ [範例：比較所有玩家的屬性](match-examples-6.md)
+ [範例：建立大型比對](match-examples-7.md)
+ [範例：建立多團隊大型配對](match-examples-8.md)
+ [範例：與具有類似屬性的玩家建立大型配對](match-examples-9.md)
+ [範例：使用複合規則來建立與具有類似屬性或類似選擇之玩家的配對](match-examples-10.md)
+ [範例：建立使用玩家封鎖清單的規則](match-examples-11.md)
# 範例：建立兩個具有平均配對玩家的隊伍
此範例說明如何利用下列的指示，設定兩個勢均力敵的玩家隊伍。
+ 建立兩個玩家隊伍。
+ 在每個隊伍中加入 4 到 8 個玩家。
+ 最終確定的隊伍必須擁有相同的玩家人數。
+ 納入玩家的技能等級 (如果未提供，預設為 10)。
+ 根據其技能等級是否類似於其他玩家的這項條件，來選擇玩家。確保兩個隊伍的玩家平均技能值落差在 10 點之內。
+ 如果未能快速地完成配對，請放寬對玩家技能的要求，以在合理的時間內完成配對。
+ 經過 5 秒之後，請展開搜尋，以允許玩家平均技能值在 50 點之內的隊伍。
+ 經過 15 秒之後，請展開搜尋，以允許玩家平均技能值在 100 點之內的隊伍。
使用此規則集的注意事項：
+ 此範例可讓隊伍的人數介於 4 到 8 名玩家之間 (雖然每個隊伍的人數必須相同)。對於人數在有效範圍內的隊伍，配對建構器會盡力嘗試，來配對最多的允許玩家人數。
+ `FairTeamSkill` 規則可確保隊伍根據玩家的技能均衡配對。為了針對每個潛在的新玩家評估此項規則，FlexMatch 會暫時性地將玩家加入隊伍，並計算平均值。如果不符規則，則不會將潛在的玩家加入配對。
+ 由於這兩個隊伍有相同結構，您可以選擇只建立一個隊伍定義，並將隊伍數量設定為「2」。在這個案例中，如果您將隊伍命名為「aliens」，則系統會對這兩個隊伍指派「aliens\$11」和「aliens\$12」名稱。
```
{
"name": "aliens_vs_cowboys",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
}],
"teams": [{
"name": "cowboys",
"maxPlayers": 8,
"minPlayers": 4
}, {
"name": "aliens",
"maxPlayers": 8,
"minPlayers": 4
}],
"rules": [{
"name": "FairTeamSkill",
"description": "The average skill of players in each team is within 10 points from the average skill of all players in the match",
"type": "distance",
// get skill values for players in each team and average separately to produce list of two numbers
"measurements": [ "avg(teams[*].players.attributes[skill])" ],
// get skill values for players in each team, flatten into a single list, and average to produce an overall average
"referenceValue": "avg(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10 // minDistance would achieve the opposite result
}, {
"name": "EqualTeamSizes",
"description": "Only launch a game when the number of players in each team matches, e.g. 4v4, 5v5, 6v6, 7v7, 8v8",
"type": "comparison",
"measurements": [ "count(teams[cowboys].players)" ],
"referenceValue": "count(teams[aliens].players)",
"operation": "=" // other operations: !=, <, <=, >, >=
}],
"expansions": [{
"target": "rules[FairTeamSkill].maxDistance",
"steps": [{
"waitTimeSeconds": 5,
"value": 50
}, {
"waitTimeSeconds": 15,
"value": 100
}]
}]
}
```
# 範例：建立不均勻的團隊 （獵人與怪物）
此範例說明一種遊戲模式，其中由一組玩家獵殺一隻怪物。玩家可選擇獵人或怪物的角色。獵人們會針對想要面對的怪物，指定怪物的最低技能等級。獵人隊伍的人數下限可隨時間放寬，以完成配對。此情境會產生下列指示：
+ 建立一個包含 5 位獵人的隊伍。
+ 建立一個單獨的隊伍，其中只包含 1 隻怪物。
+ 加入下列的玩家屬性：
+ 玩家的技能等級 (如果未提供，預設為 10)。
+ 玩家偏好的怪物技能等級 (如果未提供，預設為 10)。
+ 玩家是否想要擔任怪物 (如果未提供此屬性，預設為 0 或 false)。
+ 根據下列的條件，選擇一位玩家來擔任怪物：
+ 玩家必須請求怪物的角色。
+ 此玩家必須符合或超過已加入獵人隊伍的玩家所偏好的最高技能等級。
+ 根據下列的條件，選擇獵人隊伍的玩家：
+ 申請擔任怪物角色的玩家，無法加入獵人隊伍。
+ 如果怪物角色已找到人選，玩家所要求的怪物技能等級必須低於建議怪物的技能。
+ 如果未能快速完成配對，請放寬獵人隊伍的人數下限，如下所示：
+ 超過 30 秒後，可讓遊戲在獵人隊伍只包含 4 個玩家的情況下開始。
+ 超過 60 秒後，可讓遊戲在獵人隊伍只包含 3 個玩家的情況下開始。
使用此規則集的注意事項：
+ 透過建立獵人和怪物兩個不同的隊伍，您就可以根據不同的一組條件來評估成員資格。
```
{
"name": "players_vs_monster_5_vs_1",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
},{
"name": "desiredSkillOfMonster",
"type": "number",
"default": 10
},{
"name": "wantsToBeMonster",
"type": "number",
"default": 0
}],
"teams": [{
"name": "players",
"maxPlayers": 5,
"minPlayers": 5
}, {
"name": "monster",
"maxPlayers": 1,
"minPlayers": 1
}],
"rules": [{
"name": "MonsterSelection",
"description": "Only users that request playing as monster are assigned to the monster team",
"type": "comparison",
"measurements": ["teams[monster].players.attributes[wantsToBeMonster]"],
"referenceValue": 1,
"operation": "="
},{
"name": "PlayerSelection",
"description": "Do not place people who want to be monsters in the players team",
"type": "comparison",
"measurements": ["teams[players].players.attributes[wantsToBeMonster]"],
"referenceValue": 0,
"operation": "="
},{
"name": "MonsterSkill",
"description": "Monsters must meet the skill requested by all players",
"type": "comparison",
"measurements": ["avg(teams[monster].players.attributes[skill])"],
"referenceValue": "max(teams[players].players.attributes[desiredSkillOfMonster])",
"operation": ">="
}],
"expansions": [{
"target": "teams[players].minPlayers",
"steps": [{
"waitTimeSeconds": 30,
"value": 4
},{
"waitTimeSeconds": 60,
"value": 3
}]
}]
}
```
# 範例：設定團隊層級需求和延遲限制
此範例說明如何設置玩家隊伍，並針對每個隊伍而非每個玩家套用一組規則。範例中使用單一定義來建立三個勢均力敵的隊伍。範例中也會建立所有玩家的最大延遲。延遲最大值可隨時間放寬，以完成配對。此範例會列出下列指示：
+ 建立三個玩家隊伍。
+ 在每個隊伍中加入 3 到 5 個玩家。
+ 最終確定的隊伍，必須包含相同或幾乎相同的玩家人數 (落差在一個人以內)。
+ 加入下列的玩家屬性：
+ 玩家的技能等級 (如果未提供，預設為 10)。
+ 玩家的遊戲角色 (如果未提供，預設為「農夫」)。
+ 根據其技能等級是否接近配對中其他玩家的這項條件，來選擇玩家。
+ 確保每個隊伍的玩家平均技能值落差在 10 點之內。
+ 根據下列的「medic (醫生)」角色人數來限制隊伍：
+ 整個配對最多可有 5 個醫生 (medic)。
+ 僅限回報的延遲時間在 50 毫秒以內的配對玩家。
+ 如果未能快速完成配對，請放寬玩家延遲的要求，如下所示：
+ 超過 10 秒後，允許玩家的延遲值最高可到 100 ms。
+ 超過 20 秒後，允許玩家的延遲值最高可到 150 ms。
使用此規則集的注意事項：
+ 此規則集可確保隊伍根據玩家的技能均衡配對。為了評估 `FairTeamSkill` 規則，FlexMatch 會暫時性地在隊伍中新增候選玩家，並計算隊伍玩家的平均技能。然後，會與兩個隊伍中玩家的平均技能進行比較。如果不符規則，則不會將潛在的玩家加入配對。
+ 隊伍和配對層級的要求 (medic 的總人數) 會透過集合規則滿足。此規則類型需要所有玩家的角色屬性清單，並針對數目上限進行比對。利用 `flatten` 來建立所有隊伍中所有玩家的清單。
+ 根據延遲來進行評估時，請注意下列事項：
+ 延遲資料會在配對請求中提供，此請求是 Player (玩家) 物件的一部分。此資料並非玩家屬性，所以不需要列為屬性。若要取得準確的延遲測量，請使用 Amazon GameLift Servers的 UDP ping 信標。這些端點可讓您測量玩家裝置與每個潛在託管位置之間的實際 UDP 網路延遲，從而做出比使用 ICMP ping 更準確的置放決策。如需使用 UDP ping 信標測量延遲的詳細資訊，請參閱 [UDP ping 信標](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html)。
+ 配對建構器會根據區域來評估延遲。配對建構器會略過延遲值高於上限值的任何區域。若要符合配對接受的資格，玩家必須至少擁有一個延遲值低於上限值的區域。
+ 如果配對請求略過一個或多個玩家的延遲資料，則該請求會遭到所有配對拒絕。
```
{
"name": "three_team_game",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number",
"default": 10
},{
"name": "character",
"type": "string_list",
"default": [ "peasant" ]
}],
"teams": [{
"name": "trio",
"minPlayers": 3,
"maxPlayers": 5,
"quantity": 3
}],
"rules": [{
"name": "FairTeamSkill",
"description": "The average skill of players in each team is within 10 points from the average skill of players in the match",
"type": "distance",
// get players for each team, and average separately to produce list of 3
"measurements": [ "avg(teams[*].players.attributes[skill])" ],
// get players for each team, flatten into a single list, and average to produce overall average
"referenceValue": "avg(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10 // minDistance would achieve the opposite result
}, {
"name": "CloseTeamSizes",
"description": "Only launch a game when the team sizes are within 1 of each other. e.g. 3 v 3 v 4 is okay, but not 3 v 5 v 5",
"type": "distance",
"measurements": [ "max(count(teams[*].players))"],
"referenceValue": "min(count(teams[*].players))",
"maxDistance": 1
}, {
"name": "OverallMedicLimit",
"description": "Don't allow more than 5 medics in the game",
"type": "collection",
// This is similar to above, but the flatten flattens everything into a single
// list of characters in the game.
"measurements": [ "flatten(teams[*].players.attributes[character])"],
"operation": "contains",
"referenceValue": "medic",
"maxCount": 5
}, {
"name": "FastConnection",
"description": "Prefer matches with fast player connections first",
"type": "latency",
"maxLatency": 50
}],
"expansions": [{
"target": "rules[FastConnection].maxLatency",
"steps": [{
"waitTimeSeconds": 10,
"value": 100
}, {
"waitTimeSeconds": 20,
"value": 150
}]
}]
}
```
# 範例：使用明確排序來尋找最佳相符項目
此範例會設定兩個隊伍的簡單配對，這兩個隊伍各包含三個玩家。此範例說明如何利用明確排序的規則，來協助您盡快找到最佳的可能配對。這些規則會排序所有作用中的配對票證，以根據特定金鑰需求建立最佳相符項目。此範例會依照下列指示實作：
+ 建立兩個玩家隊伍。
+ 在每個隊伍中加入 3 個玩家。
+ 加入下列的玩家屬性：
+ 體驗等級 (如果未提供，預設為 50)。
+ 偏好的遊戲模式 (可以列出多個值) (如果未提供，預設為「coop (合作)」和「deathmatch (死鬥)」)。
+ 偏好的遊戲地圖，包括地圖名稱和偏好的加權 (如果未提供，預設為 `"defaultMap"`，使用加權 100)。
+ 設定預先排序：
+ 根據玩家對於和主錨玩家相同遊戲地圖的偏好，來將玩家排序。玩家可以擁有多個最愛的遊戲地圖，所以這個範例使用偏好設定值。
+ 根據玩家的經驗等級與主錨玩家的接近程度，來將玩家排序。利用此種排序法，所有隊伍中的所有玩家就能夠盡可能地擁有相近的經驗值。
+ 所有隊伍的所有玩家必須至少選擇一個共同的遊戲模式。
+ 所有隊伍的所有玩家必須至少選擇一個共同的遊戲地圖。
使用此規則集的注意事項：
+ 遊戲地圖的排序，會使用比較 mapPreference 屬性值的絕對排序法。由於這是規則集內的第一個規則，所以會優先執行此排序。
+ 體驗排序則會使用距離排序來比較候選玩家的技能等級與主錨玩家的技能。
+ 排序會依其在規則集內的列出順序來執行。在此情境中，會先根據遊戲地圖的偏好設定，然後再根據經驗等級，來將玩家排序。
```
{
"name": "multi_map_game",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "experience",
"type": "number",
"default": 50
}, {
"name": "gameMode",
"type": "string_list",
"default": [ "deathmatch", "coop" ]
}, {
"name": "mapPreference",
"type": "string_number_map",
"default": { "defaultMap": 100 }
}, {
"name": "acceptableMaps",
"type": "string_list",
"default": [ "defaultMap" ]
}],
"teams": [{
"name": "red",
"maxPlayers": 3,
"minPlayers": 3
}, {
"name": "blue",
"maxPlayers": 3,
"minPlayers": 3
}],
"rules": [{
// We placed this rule first since we want to prioritize players preferring the same map
"name": "MapPreference",
"description": "Favor grouping players that have the highest map preference aligned with the anchor's favorite",
// This rule is just for sorting potential matches. We sort by the absolute value of a field.
"type": "absoluteSort",
// Highest values go first
"sortDirection": "descending",
// Sort is based on the mapPreference attribute.
"sortAttribute": "mapPreference",
// We find the key in the anchor's mapPreference attribute that has the highest value.
// That's the key that we use for all players when sorting.
"mapKey": "maxValue"
}, {
// This rule is second because any tie-breakers should be ordered by similar experience values
"name": "ExperienceAffinity",
"description": "Favor players with similar experience",
// This rule is just for sorting potential matches. We sort by the distance from the anchor.
"type": "distanceSort",
// Lowest distance goes first
"sortDirection": "ascending",
"sortAttribute": "experience"
}, {
"name": "SharedMode",
"description": "The players must have at least one game mode in common",
"type": "collection",
"operation": "intersection",
"measurements": [ "flatten(teams[*].players.attributes[gameMode])"],
"minCount": 1
}, {
"name": "MapOverlap",
"description": "The players must have at least one map in common",
"type": "collection",
"operation": "intersection",
"measurements": [ "flatten(teams[*].players.attributes[acceptableMaps])"],
"minCount": 1
}]
}
```
# 範例：尋找跨多個玩家屬性的交集
此範例說明如何使用集合規則來尋找兩個或多個玩家屬性中的交集。使用集合規則時，您可以分別針對單一屬性和多個屬性，使用 `intersection` 操作和 `reference_intersection_count` 操作。
為了說明這項方法，此範例會根據玩家的角色偏好，來評估配對中的玩家。此範例的遊戲是「自由戰」的模式，配對中的所有玩家都是對手。每個玩家都會被要求 (1) 選擇自己的角色，以及 (2) 選擇自己想要對抗的角色。我們需要規則，來確保配對中每個玩家所使用的角色，都在其他所有玩家的偏好對手清單中。
範例規則集利用下列的角色來說明配對：
+ 隊伍結構：一個隊伍 5 個玩家
+ 玩家屬性：
+ *myCharacter*：玩家所選擇的角色。
+ *preferredOpponents*：列出玩家想要對抗的角色。
+ 配對規則：如果每個使用中的角色，出現在每個玩家偏好的對手清單中，即可接受可能的配對。
為了實行配對規則，此範例使用具有下列屬性值的集合規則：
+ 操作 – 使用 `reference_intersection_count`操作來評估測量值中的每個字串清單如何與參考值中的字串清單相交。
+ 測量 – 使用 `flatten` 屬性表達式來建立字串清單，每個字串清單都包含一個玩家的 *myCharacter* 屬性值。
+ 參考值 – 使用 `set_intersection` 屬性表達式來建立所有 *preferredOpponents* 屬性值的字串清單，這些值對配對中的每個玩家都是常見的。
+ 限制 – `minCount` 設定為 1，以確保每個玩家選擇的字元 （測量中的字串清單） 至少符合所有玩家通用的其中一個偏好對手。 （參考值中的字串）。
+ 擴展 – 如果配對未在 15 秒內填滿，請放寬最小交集要求。
此規則的流程如下：
1. 將玩家加入配對候選中。會重新計算參考值 (字串清單)，以納入與新玩家偏好對手清單的交集。會重新計算衡量值 (字串清單)，以將新玩家所選擇的角色新增為字串清單。
1. Amazon GameLift Servers 會確認衡量值 (玩家所選擇的角色) 中的每個字串清單，是否與參考值 (玩家偏好的對手) 中至少一個字串有交集。在此範例中，由於衡量值中的每個字串清單中只包含一個值，因此交集為 0 或 1。
1. 如果衡量值中的任何字串清單並未和參考值的字串清單有交集，則不符此規則，會從候選配對中將此一新玩家移除。
1. 如果未能在 15 秒內完成配對，請放寬對手的配對標準，以補滿配對中剩下的玩家空位。
```
{
"name": "preferred_characters",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "myCharacter",
"type": "string_list"
}, {
"name": "preferredOpponents",
"type": "string_list"
}],
"teams": [{
"name": "red",
"minPlayers": 5,
"maxPlayers": 5
}],
"rules": [{
"description": "Make sure that all players in the match are using a character that is on all other players' preferred opponents list.",
"name": "OpponentMatch",
"type": "collection",
"operation": "reference_intersection_count",
"measurements": ["flatten(teams[*].players.attributes[myCharacter])"],
"referenceValue": "set_intersection(flatten(teams[*].players.attributes[preferredOpponents]))",
"minCount":1
}],
"expansions": [{
"target": "rules[OpponentMatch].minCount",
"steps": [{
"waitTimeSeconds": 15,
"value": 0
}]
}]
}
```
# 範例：比較所有玩家的屬性
此範例說明如何在一組玩家之間比較玩家的屬性。
範例規則集利用下列的角色來說明配對：
+ 隊伍結構：兩個單一玩家的隊伍
+ 玩家屬性：
+ *gameMode* (遊戲模式)：玩家所選擇的遊戲類型 (如果未提供，預設為「回合制」)。
+ *gameMap* (遊戲地圖)：玩家所選擇的遊戲世界 (如果未提供，預設為 1)。
+ *character* (角色)：玩家所選擇的角色 (無預設值表示玩家必須指定角色)。
+ 配對規則：配對的玩家必須符合下列要求：
+ 玩家必須選擇相同的遊戲模式。
+ 玩家必須選擇相同的遊戲地圖。
+ 玩家必須選擇不同的角色。
使用此規則集的注意事項：
+ 為了實行配對規則，此範例使用比較規則來檢查所有玩家的屬性值。針對遊戲模式和地圖，該規則會驗證值是否相同。針對角色，該規則會驗證值是否不同。
+ 此範例使用一個有數量屬性的玩家定義來建立這兩個玩家隊伍。隊伍會獲得以下名稱：「player\$11」和「player\$12」。
```
{
"name": "",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "gameMode",
"type": "string",
"default": "turn-based"
}, {
"name": "gameMap",
"type": "number",
"default": 1
}, {
"name": "character",
"type": "number"
}],
"teams": [{
"name": "player",
"minPlayers": 1,
"maxPlayers": 1,
"quantity": 2
}],
"rules": [{
"name": "SameGameMode",
"description": "Only match players when they choose the same game type",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[gameMode])"]
}, {
"name": "SameGameMap",
"description": "Only match players when they're in the same map",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[gameMap])"]
}, {
"name": "DifferentCharacter",
"description": "Only match players when they're using different characters",
"type": "comparison",
"operation": "!=",
"measurements": ["flatten(teams[*].players.attributes[character])"]
}]
}
```
# 範例：建立大型比對
此範例說明如何為可以超過 40 名玩家的配對設定規則集。當規則集描述隊伍的 maxPlayer 計數總和大於 40 時，便會視為大型配對來處理。請至 [設計FlexMatch大型相符規則集](match-design-rulesets-large.md) 進一步了解。
範例規則集使用以下指示來建立配對：
+ 建立一個有玩家人數多達 200 名的隊伍，且玩家人數下限要求為 175 名。
+ 平衡條件：根據類似技能等級來選取玩家。所有玩家都必須回報其技能等級才能進行配對。
+ 批次處理偏好設定：在建立配對時，依照類似的平衡條件來將玩家群組在一起。
+ 延遲規則：將可接受的玩家延遲上限設定為 150 毫秒。
+ 如果未能快速填滿配對，則放寬要求以在合理的時間內完成配對。
+ 在 10 秒後，接受有 150 名玩家的隊伍。
+ 在 12 秒後，將可接受的延遲上限提高到 200 毫秒。
+ 在 15 秒後，接受有 100 名玩家的隊伍。
使用此規則集的注意事項：
+ 由於演算法使用「最大人口」批次處理偏好設定，系統會先根據平衡條件來對玩家進行排序。因此，配對內往往會填滿玩家，並包含技能更類似的玩家。所有玩家皆符合可接受的延遲要求，但可能無法在所在位置獲得最佳的延遲。
+ 這個規則集內所使用的演算法策略「最大人口」為預設設定。若要使用預設設定，您可以選擇省略該設定。
+ 如果您已啟用配對回填，則請勿太快放寬玩家人數要求，否則最終可能會有太多部份填滿的遊戲工作階段。請至 [放寬大型比對需求](match-design-rulesets-large-relax.md) 進一步了解。
```
{
"name": "free-for-all",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "skill",
"type": "number"
}],
"algorithm": {
"balancedAttribute": "skill",
"strategy": "balanced",
"batchingPreference": "largestPopulation"
},
"teams": [{
"name": "Marauders",
"maxPlayers": 200,
"minPlayers": 175
}],
"rules": [{
"name": "low-latency",
"description": "Sets maximum acceptable latency",
"type": "latency",
"maxLatency": 150
}],
"expansions": [{
"target": "rules[low-latency].maxLatency",
"steps": [{
"waitTimeSeconds": 12,
"value": 200
}],
}, {
"target": "teams[Marauders].minPlayers",
"steps": [{
"waitTimeSeconds": 10,
"value": 150
}, {
"waitTimeSeconds": 15,
"value": 100
}]
}]
}
```
# 範例：建立多團隊大型配對
此範例說明如何為有多個可以超過 40 名玩家的隊伍配對設定規則集。此範例說明如何使用一個定義建立多個相同隊伍，以及在建立配對期間會如何填滿大小不對稱的隊伍。
範例規則集使用以下指示來建立配對：
+ 建立十個有多達 15 名玩家的相同「獵人」隊伍，以及一個有正好 5 名玩家的「怪物」隊伍。
+ 平衡條件：根據擊殺怪物的數量來選取玩家。如果玩家未回報擊殺數量，則使用預設值 (5 個)。
+ 批次處理偏好設定：根據回報的玩家延遲最快的區域來將玩家群組在一起。
+ 延遲規則：將可接受的玩家延遲上限設定為 200 毫秒。
+ 如果未能快速填滿配對，則放寬要求以在合理的時間內完成配對。
+ 在 15 秒後，接受有 10 名玩家的隊伍。
+ 在 20 秒後，接受有 8 名玩家的隊伍。
使用此規則集的注意事項：
+ 此規則集定義了可以容納最多 155 名玩家的隊伍，這使其成為大型配對。(10 x 15 獵人 \$1 5 怪物 = 155)
+ 由於演算法會使用「最快區域」批次處理偏好設定，系統可能會將玩家放到回報的延遲最快的區域，而非回報的延遲較高 (但可接受) 的區域。同時，配對可能會有較少的玩家，且平衡條件 (怪物技能數字) 可能會有更大的變化。
+ 如果多隊伍定義 (數量 > 1) 已定義了擴展，擴展便會適用於使用該定義所建立的所有隊伍。因此，透過放寬獵人隊伍玩家人數下限設定，這十個獵人隊伍全部會受到同樣的影響。
+ 由於此規則集已經過優化而能盡量減少玩家延遲，因此延遲規則可以一網打盡地排除連線選項未達接受標準的玩家。我們不需要放寬此要求。
+ 以下是 FlexMatch 在擴展生效前針對此規則集填滿配對的方式：
+ 還沒有任何隊伍達到 minPlayers 人數。獵人隊伍有 15 個空位，怪物隊伍則有 5 個空位。
+ 前 100 名玩家會指派給十個獵人隊伍 (每個隊伍各 10 名)。
+ 接下來的 22 名玩家則會循序指派給獵人隊伍和怪物隊伍 (每個隊伍各 2 名)。
+ 獵人隊伍已達到 minPlayers 人數，也就是每個隊伍皆有 12 名玩家。怪物隊伍有 2 名玩家，且尚未達到 minPlayers 人數。
+ 接下來的三名玩家會指派給怪物隊伍。
+ 所有隊伍皆已達到 minPlayers 人數。獵人隊伍各有三個空位。怪物隊伍人數已滿。
+ 最後 30 名玩家會循序指派給獵人隊伍，以確保所有獵人隊伍的大小幾乎相同 (多一名玩家或少一名玩家)。
+ 如果您已針對使用此規則集所建立的配對啟用回填，則請勿太快放寬玩家人數要求，否則最終可能會有太多部份填滿的遊戲工作階段。請至 [放寬大型比對需求](match-design-rulesets-large-relax.md) 進一步了解。
```
{
"name": "monster-hunters",
"ruleLanguageVersion": "1.0",
"playerAttributes": [{
"name": "monster-kills",
"type": "number",
"default": 5
}],
"algorithm": {
"balancedAttribute": "monster-kills",
"strategy": "balanced",
"batchingPreference": "fastestRegion"
},
"teams": [{
"name": "Monsters",
"maxPlayers": 5,
"minPlayers": 5
}, {
"name": "Hunters",
"maxPlayers": 15,
"minPlayers": 12,
"quantity": 10
}],
"rules": [{
"name": "latency-catchall",
"description": "Sets maximum acceptable latency",
"type": "latency",
"maxLatency": 150
}],
"expansions": [{
"target": "teams[Hunters].minPlayers",
"steps": [{
"waitTimeSeconds": 15,
"value": 10
}, {
"waitTimeSeconds": 20,
"value": 8
}]
}]
}
```
# 範例：與具有類似屬性的玩家建立大型配對
此範例說明如何使用 為兩個隊伍的配對設定規則集`batchDistance`。在範例中：
+ 此`SimilarLeague`規則可確保配對中的所有玩家在 2 個其他玩家`league`中都有 。
+ 此`SimilarSkill`規則可確保配對中的所有玩家在其他玩家中都有 10 `skill` 個內的 。如果玩家正在等待 10 秒，則距離會擴展到 20 秒。如果玩家正在等待 20 秒，則距離會擴展到 40 秒。
+ 此`SameMap`規則可確保配對中的所有玩家都請求相同的 `map`。
+ 此`SameMode`規則可確保配對中的所有玩家都請求相同的 `mode`。
```
{
"ruleLanguageVersion": "1.0",
"teams": [{
"name": "red",
"minPlayers": 100,
"maxPlayers": 100
}, {
"name": "blue",
"minPlayers": 100,
"maxPlayers": 100
}],
"algorithm": {
"strategy":"balanced",
"balancedAttribute": "skill",
"batchingPreference":"fastestRegion"
},
"playerAttributes": [{
"name": "league",
"type": "number"
},{
"name": "skill",
"type": "number"
},{
"name": "map",
"type": "string"
},{
"name": "mode",
"type": "string"
}],
"rules": [{
"name": "SimilarLeague",
"type": "batchDistance",
"batchAttribute": "league",
"maxDistance": 2
}, {
"name": "SimilarSkill",
"type": "batchDistance",
"batchAttribute": "skill",
"maxDistance": 10
}, {
"name": "SameMap",
"type": "batchDistance",
"batchAttribute": "map"
}, {
"name": "SameMode",
"type": "batchDistance",
"batchAttribute": "mode"
}],
"expansions": [{
"target": "rules[SimilarSkill].maxDistance",
"steps": [{
"waitTimeSeconds": 10,
"value": 20
}, {
"waitTimeSeconds": 20,
"value": 40
}]
}]
}
```
# 範例：使用複合規則來建立與具有類似屬性或類似選擇之玩家的配對
此範例說明如何使用 為兩個隊伍的配對設定規則集`compound`。在範例中：
+ 此`SimilarLeagueDistance`規則可確保配對中的所有玩家在其他玩家的 2 `league` 個內都有 。
+ 此`SimilarSkillDistance`規則可確保配對中的所有玩家在 10 個其他玩家`skill`中有 。如果玩家正在等待 10 秒，則距離會擴展到 20 秒。如果玩家正在等待 20 秒，則距離會擴展到 40 秒。
+ 此`SameMapComparison`規則可確保配對中的所有玩家都請求相同的 `map`。
+ 此`SameModeComparison`規則可確保配對中的所有玩家都請求相同的 `mode`。
+ 如果至少符合下列其中一個條件，則`CompoundRuleMatchmaker`規則可確保相符：
+ 配對中的玩家已請求相同的 `map`和相同的 `mode`。
+ 配對中的玩家具有相當的 `skill`和 `league` 屬性。
```
{
"ruleLanguageVersion": "1.0",
"teams": [{
"name": "red",
"minPlayers": 10,
"maxPlayers": 20
}, {
"name": "blue",
"minPlayers": 10,
"maxPlayers": 20
}],
"algorithm": {
"strategy":"balanced",
"balancedAttribute": "skill",
"batchingPreference":"fastestRegion"
},
"playerAttributes": [{
"name": "league",
"type": "number"
},{
"name": "skill",
"type": "number"
},{
"name": "map",
"type": "string"
},{
"name": "mode",
"type": "string"
}],
"rules": [{
"name": "SimilarLeagueDistance",
"type": "distance",
"measurements": ["max(flatten(teams[*].players.attributes[league]))"],
"referenceValue": "min(flatten(teams[*].players.attributes[league]))",
"maxDistance": 2
}, {
"name": "SimilarSkillDistance",
"type": "distance",
"measurements": ["max(flatten(teams[*].players.attributes[skill]))"],
"referenceValue": "min(flatten(teams[*].players.attributes[skill]))",
"maxDistance": 10
}, {
"name": "SameMapComparison",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[map])"]
}, {
"name": "SameModeComparison",
"type": "comparison",
"operation": "=",
"measurements": ["flatten(teams[*].players.attributes[mode])"]
}, {
"name": "CompoundRuleMatchmaker",
"type": "compound",
"statement": "or(and(SameMapComparison, SameModeComparison), and(SimilarSkillDistance, SimilarLeagueDistance))"
}],
"expansions": [{
"target": "rules[SimilarSkillDistance].maxDistance",
"steps": [{
"waitTimeSeconds": 10,
"value": 20
}, {
"waitTimeSeconds": 20,
"value": 40
}]
}]
}
```
# 範例：建立使用玩家封鎖清單的規則
此範例說明規則集，可讓玩家避免與其他特定玩家配對。玩家可以建立封鎖清單，配對建構器會在玩家選擇配對期間評估該清單。如需新增封鎖清單或避免清單功能的更多指引，請參閱[AWS 遊戲部落格的](https://aws.amazon.com/blogs/gametech/category/game-development/amazon-gamelift/) 。
此範例會列出下列指示：
+ 建立兩個隊伍，只有五個玩家。
+ 傳入玩家的封鎖清單，這是玩家 IDs的清單 （最多 100 個）。
+ 將所有玩家與每個玩家的封鎖清單進行比較，如果找到任何封鎖的玩家 IDs，則會拒絕提議的配對。
使用此規則集的注意事項：
+ 評估新玩家以新增至提議配對 （或回填現有配對中的位置） 時，玩家可能會因為下列其中一個原因遭到拒絕：
+ 如果新玩家位於已為配對選取的任何玩家的封鎖清單上。
+ 如果任何已為配對選取的玩家，都在新玩家的封鎖清單中。
+ 如圖所示，此規則集可防止將玩家與區塊清單上的任何玩家配對。您可以新增規則擴展並增加`maxCount`值，將此需求變更為偏好設定 （也稱為「避免」清單）。
```
{
"name": "Player Block List",
"ruleLanguageVersion": "1.0",
"teams": [{
"maxPlayers": 5,
"minPlayers": 5,
"name": "red"
}, {
"maxPlayers": 5,
"minPlayers": 5,
"name": "blue"
}],
"playerAttributes": [{
"name": "BlockList",
"type": "string_list",
"default": []
}],
"rules": [{
"name": "PlayerIdNotInBlockList",
"type": "collection",
"operation": "reference_intersection_count",
"measurements": "flatten(teams[*].players.attributes[BlockList])",
"referenceValue": "flatten(teams[*].players[playerId])",
"maxCount": 0
}]
}
```
# 建立配對組態
若要設定Amazon GameLift ServersFlexMatch配對建構器來處理配對請求，請建立配對組態。使用 Amazon GameLift Servers主控台或 AWS Command Line Interface (AWS CLI)。如需建立配對建構器的詳細資訊，請參閱 [設計FlexMatch配對建構器](match-configuration.md)。
**Topics**
+ [教學課程：建立用於Amazon GameLift Servers託管的配對建構器](match-create-configuration-withqueue.md)
+ [教學課程：為獨立 建立配對建構器 FlexMatch](match-create-configuration-standalone.md)
+ [教學課程：編輯配對組態](match-create-configuration-edit.md)
# 教學課程：建立用於Amazon GameLift Servers託管的配對建構器
在建立配對組態之前，[請建立規則集](match-create-ruleset.md)和Amazon GameLift Servers[遊戲工作階段佇列](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/queues-creating.html)，以便與配對建構器搭配使用。
------
#### [ Console ]
1. 在[Amazon GameLift Servers主控台](https://console.aws.amazon.com/gamelift/)的導覽窗格中，選擇**配對組態**。
1. 切換到您要建立配對建構器 AWS 的區域。
1. 在**配對組態**頁面上，選擇**建立配對組態**。
1. 在**定義組態詳細資訊**頁面的**配對組態詳細資訊**下，執行下列動作：
1. 在**名稱**中，輸入配對建構器名稱，協助您在清單和指標中識別它。配對建構器名稱在 區域中必須是唯一的。配對請求會依名稱和區域識別要使用的配對建構器。
1. （選用） 針對**描述**，新增描述以協助識別配對建構器。
1. 針對**規則集**，從清單中選擇要與配對建構器搭配使用的規則集。清單包含您在目前區域中建立的所有規則集。
1. 針對 **FlexMatch 模式**，選擇**受管**以進行Amazon GameLift Servers受管託管。此模式FlexMatch會提示將成功配對傳遞至指定的遊戲工作階段佇列。
1. 針對 **AWS 區域**，選擇您設定要與配對建構器搭配使用之遊戲工作階段佇列的區域。
1. 針對**佇列**，選擇您要與配對建構器搭配使用的遊戲工作階段佇列。
1. 選擇**下一步**。
1. 在**設定設定**頁面的**配對設定**下，執行下列動作：
1. 針對**請求逾時**，設定配對建構器完成每個請求配對的時間上限，以秒為單位。 會FlexMatch取消超過此時間的配對請求。
1. 針對**回填模式**，選擇處理配對回填的模式。
+ 若要開啟自動回填功能，請選擇**自動**。
+ 若要建立您自己的回填請求管理或不使用回填功能，請選擇**手動**。
1. （選用） 對於**其他玩家計數**，設定在配對中保持開啟的玩家位置數量。 FlexMatch可以在未來向玩家填滿這些位置。
1. （選用） 在**配對接受選項**下，對於**需要接受**，如果您想要要求提議配對中的每個玩家主動接受配對，請選取**需要**。如果您選取此選項，則對於**接受逾時**，請設定配對建構器在取消配對之前等待玩家接受的時間，以秒為單位。
1. （選用） 在**事件通知設定**下，執行下列動作：
1. （選用） 針對 **SNS 主題**，選擇 Amazon Simple Notification Service (Amazon SNS) 主題以接收配對事件通知。如果您尚未設定 SNS 主題，稍後可以透過編輯配對組態來選擇此選項。如需詳細資訊，請參閱[設定FlexMatch事件通知](match-notification.md)。
1. （選用） 對於**自訂事件資料**，請在事件傳訊中輸入任何您想要與此配對建構器相關聯的自訂資料。 會在與配對建構器相關聯的每個事件中FlexMatch包含此資料。
1. （選用） 展開**其他遊戲資料**，然後執行下列動作：
1. （選用） 對於**遊戲工作階段資料**，輸入FlexMatch您希望交付給新遊戲工作階段的任何其他遊戲相關資訊，這些工作階段是從使用此配對組態建立的配對開始。
1. （選用） 對於**遊戲屬性**，新增包含新遊戲工作階段相關資訊的鍵/值對屬性。
1. （選用） 在**標籤**下，新增標籤以協助您管理和追蹤 AWS 資源。
1. 選擇**下一步**。
1. 在**檢閱和建立**頁面上，檢閱您的選擇，然後選擇**建立**。成功建立後，配對建構器已準備好接受配對請求。
------
#### [ AWS CLI ]
若要使用 建立配對組態 AWS CLI，請開啟命令列視窗，並使用 [create-matchmaking-configuration](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-configuration.html) 命令來定義新的配對建構器。
此範例命令會建立新的配對組態，需要玩家接受並啟用自動回填。它還保留兩個玩家位置FlexMatch供 稍後新增玩家，並提供一些遊戲工作階段資料。
```
aws gamelift create-matchmaking-configuration \
--name "SampleMatchamker123" \
--description "The sample test matchmaker with acceptance" \
--flex-match-mode WITH_QUEUE \
--game-session-queue-arns "arn:aws:gamelift:us-west-2:111122223333:gamesessionqueue/MyGameSessionQueue" \
--rule-set-name "MyRuleSet" \
--request-timeout-seconds 120 \
--acceptance-required \
--acceptance-timeout-seconds 30 \
--backfill-mode AUTOMATIC \
--notification-target "arn:aws:sns:us-west-2:111122223333:My_Matchmaking_SNS_Topic" \
--additional-player-count 2 \
--game-session-data "key=map,value=winter444"
```
若配對組態建立請求成功，Amazon GameLift Servers 即會傳回 [MatchmakingConfiguration](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingConfiguration.html) 物件，其涵蓋您所請求的配對建構器設定。新的配對建構器已準備好接受配對請求。
------
# 教學課程：為獨立 建立配對建構器 FlexMatch
建立配對組態之前，[請建立規則集](match-create-ruleset.md)以搭配配對建構器使用。
------
#### [ Console ]
1. 在 https：//[https://console.aws.amazon.com/gamelift/home](https://console.aws.amazon.com/gamelift/) 開啟 Amazon GameLift Servers主控台。
1. 切換到您要建立配對建構器 AWS 的區域。如需支援FlexMatch配對組態的區域清單，請參閱 [選擇配對建構器的位置](match-configuration-regions.md)。
1. 在導覽窗格中，選擇 **FlexMatch**、 **Matchmaking 組態**。
1. 在**配對組態**頁面上，選擇**建立配對組態**。
1. 在**定義組態詳細資訊**頁面的**配對組態詳細資訊**下，執行下列動作：
1. 在**名稱**中，輸入配對建構器名稱，協助您在清單和指標中識別它。配對建構器名稱在 區域中必須是唯一的。配對請求會依名稱和區域識別要使用的配對建構器。
1. （選用） 針對**描述**，新增描述以協助識別配對建構器。
1. 針對**規則集**，從清單中選擇要與配對建構器搭配使用的規則集。清單包含您在目前區域中建立的所有規則集。
1. 針對 **FlexMatch 模式**，選擇**獨立**。這表示您有自訂機制，可在 外部的託管解決方案上啟動新的遊戲工作階段Amazon GameLift Servers。
1. 選擇**下一步**。
1. 在**設定設定**頁面的**配對設定**下，執行下列動作：
1. 針對**請求逾時**，設定配對建構器完成每個請求配對的時間上限，以秒為單位。超過此時間的配對請求會遭到拒絕。
1. （選用） 在**配對接受選項**下，對於**需要接受**，如果您想要要求提議配對中的每個玩家主動接受配對，請選取**需要**。如果您選取此選項，則對於**接受逾時**，請設定配對建構器在取消配對之前等待玩家接受的時間，以秒為單位。
1. （選用） 在**事件通知設定**下，執行下列動作：
1. （選用） 針對 **SNS 主題**，選擇 Amazon SNS 主題以接收配對事件通知。如果您尚未設定 SNS 主題，稍後可以透過編輯配對組態來選擇此選項。如需詳細資訊，請參閱[設定FlexMatch事件通知](match-notification.md)。
1. （選用） 對於**自訂事件資料**，請在事件傳訊中輸入任何您想要與此配對建構器相關聯的自訂資料。 會在與配對建構器相關聯的每個事件中FlexMatch包含此資料。
1. （選用） 在**標籤**下，新增標籤以協助您管理和追蹤 AWS 資源。
1. 選擇**下一步**。
1. 在**檢閱和建立**頁面上，檢閱您的選擇，然後選擇**建立**。成功建立後，配對建構器已準備好接受配對請求。
------
#### [ AWS CLI ]
若要使用 建立配對組態 AWS CLI，請開啟命令列視窗，並使用 [create-matchmaking-configuration](https://docs.aws.amazon.com/cli/latest/reference/gamelift/create-matchmaking-configuration.html) 命令來定義新的配對建構器。
此範例命令會為需要玩家接受的獨立配對建構器建立新的配對組態。
```
aws gamelift create-matchmaking-configuration \
--name "SampleMatchamker123" \
--description "The sample test matchmaker with acceptance" \
--flex-match-mode STANDALONE \
--rule-set-name "MyRuleSetOne" \
--request-timeout-seconds 120 \
--acceptance-required \
--acceptance-timeout-seconds 30 \
--notification-target "arn:aws:sns:us-west-2:111122223333:My_Matchmaking_SNS_Topic"
```
若配對組態建立請求成功，Amazon GameLift Servers 即會傳回 [MatchmakingConfiguration](https://docs.aws.amazon.com/gameliftservers/latest/apireference/API_MatchmakingConfiguration.html) 物件，其涵蓋您所請求的配對建構器設定。新的配對建構器已準備好接受配對請求。
------
# 教學課程：編輯配對組態
若要編輯配對組態，請從導覽列中選擇**配對組態**，然後選擇您要編輯的組態。您可以更新現有組態中的任何欄位，但其名稱除外。
更新組態規則集時，如果有現有的作用中配對票證，新的規則集可能會不相容，原因如下：
+ 新的或不同的團隊名稱或團隊數量
+ 新的玩家屬性
+ 現有玩家屬性類型的變更
若要對規則集進行任何這些變更，請使用更新的規則集建立新的配對組態。
# 設定FlexMatch事件通知
您可以使用事件通知來追蹤個別配對請求的狀態。生產中或生產前具有大量配對活動的所有遊戲都應使用事件通知。
設定事件通知有兩種選項。
+ 讓您的配對建構器將事件通知發佈至 Amazon Simple Notification Service (Amazon SNS) 主題。
+ 使用自動發佈的 Amazon EventBridge 事件及其工具套件來管理事件。
如需 Amazon GameLift Servers 發出的FlexMatch事件清單，請參閱 [FlexMatch 配對事件](match-events.md)。
**重要**
對於大量配對系統，我們建議使用標準 （非 FIFO) Amazon SNS 主題，而不是 FIFO 主題。FIFO 主題的發佈限制低於標準主題，這可能會導致在高負載期間調節例外狀況。如果您使用 FIFO 主題遇到限流，您可能會遺失FlexMatch通知。
**注意**
Amazon GameLift Servers 會使用內建的重試邏輯自動處理 Amazon SNS 交付失敗和限流。當 Amazon SNS 傳回限流錯誤或暫時失敗時， Amazon GameLift Servers 會在嘗試之間以漸進式延遲重試通知交付。這有助於確保可靠地傳送事件通知。不過，如果在所有重試嘗試後仍持續失敗，或是授權失敗或遺失主題等無法重試的錯誤，則通知可能會遺失。
**Topics**
+ [設定 EventBridge 事件](#match-notification-cwe)
+ [教學課程：設定 Amazon SNS 主題](match-notification-sns.md)
+ [使用伺服器端加密設定 SNS 主題](queue-notification-sns-sse.md)
+ [設定主題訂閱以叫用 Lambda 函數](match-notification-lambda.md)
## 設定 EventBridge 事件
Amazon GameLift Servers 會自動將所有配對事件發佈至 Amazon EventBridge。使用 EventBridge，您可以設定規則，將配對事件路由到目標進行處理。例如，您可以設定規則，將事件 "PotentialMatchCreated" 路由到處理玩家接受度的 AWS Lambda 函數。如需詳細資訊，請參閱[什麼是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
**注意**
當您設定配對建構器時，請保持通知目標欄位空白，或者如果您想要同時使用 EventBridge 和 Amazon SNS 主題。
# 教學課程：設定 Amazon SNS 主題
您可以讓 Amazon GameLift Servers 將FlexMatch配對建構器產生的所有事件發佈至 Amazon SNS 主題。
**建立Amazon GameLift Servers事件通知的 SNS 主題**
1. 開啟 [Amazon SNS 主控台](https://console.aws.amazon.com/sns)。
1. 在導覽窗格中，選擇 **Topics** (主題)。
1. 在 **Topics** (主題) 頁面上，選擇 **Create topic** (建立主題)。
1. 在 主控台中建立主題。如需詳細資訊，請參閱[《Amazon Simple Notification Service 開發人員指南》中的使用 建立主題 AWS 管理主控台](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html#create-topic-aws-console)。 **
1. 在主題**的詳細資訊**頁面上，選擇**編輯**。
1. （選用） 在主題的**編輯**頁面上，展開**存取政策**，然後從下列 AWS Identity and Access Management (IAM) 政策陳述式將粗體語法新增至現有政策的結尾。（為了清楚起見，此處會顯示整個政策。) 請務必將 Amazon Resource Name (ARN) 詳細資訊用於您自己的 SNS 主題和Amazon GameLift Servers配對組態。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"SNS:GetTopicAttributes",
"SNS:SetTopicAttributes",
"SNS:AddPermission",
"SNS:RemovePermission",
"SNS:DeleteTopic",
"SNS:Subscribe",
"SNS:ListSubscriptionsByTopic",
"SNS:Publish"
],
"Resource": "arn:aws:sns:us-east-1:111122223333:your_topic_name",
"Condition": {
"StringEquals": {
"AWS:SourceAccount": "111122223333"
}
}
},
{
"Sid": "__console_pub_0",
"Effect": "Allow",
"Principal": {
"Service": "gamelift.amazonaws.com"
},
"Action": "SNS:Publish",
"Resource": "arn:aws:sns:us-east-1:111122223333:your_topic_name",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:gamelift:us-east-1:111122223333:matchmakingconfiguration/your_configuration_name"
}
}
}
]
}
```
------
1. 選擇**儲存變更**。
# 使用伺服器端加密設定 SNS 主題
您可以使用伺服器端加密 (SSE) 將敏感資料存放在加密主題中。SSE 使用在 AWS Key Management Service () 中管理的金鑰來保護 Amazon SNS 主題中的訊息內容AWS KMS。如需使用 Amazon SNS 進行伺服器端加密的詳細資訊，請參閱《*Amazon Simple Notification Service 開發人員指南*》中的[靜態加密](https://docs.aws.amazon.com/sns/latest/dg/sns-server-side-encryption.html)。
若要使用伺服器端加密設定 SNS 主題，請檢閱下列主題：
+ 《 *AWS Key Management Service 開發人員指南*》中的[建立金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)
+ 《*Amazon Simple Notification Service 開發人員指南*》中的[為主題啟用 SSE](https://docs.aws.amazon.com/sns/latest/dg/sns-enable-encryption-for-topic.html)
建立 KMS 金鑰時，請使用下列 KMS 金鑰政策：
```
{
"Effect": "Allow",
"Principal": {
"Service": "gamelift.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:gamelift:your_region:your_account:matchmakingconfiguration/your_configuration_name"
},
"StringEquals": {
"kms:EncryptionContext:aws:sns:topicArn": "arn:aws:sns:your_region:your_account:your_sns_topic_name"
}
}
}
```
# 設定主題訂閱以叫用 Lambda 函數
您可以使用發佈至 Amazon SNS 主題的事件通知來叫用 Lambda 函數。設定配對建構器時，請務必將通知目標設定為 SNS 主題的 ARN。
下列 AWS CloudFormation 範本會將名為 的 SNS 主題訂閱設定為`MyFlexMatchEventTopic`叫用名為 的 Lambda 函數`FlexMatchEventHandlerLambdaFunction`。範本會建立 IAM 許可政策，Amazon GameLift Servers允許 寫入 SNS 主題。範本接著會新增 SNS 主題的許可，以叫用 Lambda 函數。
```
FlexMatchEventTopic:
Type: "AWS::SNS::Topic"
Properties:
KmsMasterKeyId: alias/aws/sns #Enables server-side encryption on the topic using an AWS managed key
Subscription:
- Endpoint: !GetAtt FlexMatchEventHandlerLambdaFunction.Arn
Protocol: lambda
TopicName: MyFlexMatchEventTopic
FlexMatchEventTopicPolicy:
Type: "AWS::SNS::TopicPolicy"
DependsOn: FlexMatchEventTopic
Properties:
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: gamelift.amazonaws.com
Action:
- "sns:Publish"
Resource: !Ref FlexMatchEventTopic
Topics:
- Ref: FlexMatchEventTopic
FlexMatchEventHandlerLambdaPermission:
Type: "AWS::Lambda::Permission"
Properties:
Action: "lambda:InvokeFunction"
FunctionName: !Ref FlexMatchEventHandlerLambdaFunction
Principal: sns.amazonaws.com
SourceArn: !Ref FlexMatchEventTopic
```