SmartMatch 配對執行階段作業的設定
所有 SmartMatch 配對設定都是透過 Partner Center 進行的。配對工作階段範本設定
配對有兩種相關的工作階段類型。- 比賽票證工作階段，這是配對服務的輸入
- 比賽目標工作階段，這是輸出
票證工作階段不得啟用服務品質 (QoS) 檢查，且不得標記為具有 “gameplay” 功能。
配對的基本漏斗設定
本節定義用來設定基本漏斗欄位的欄位。 完成此設定之後，您必須設定漏斗規則，如本主題稍後的「漏斗規則的設定」一節所述。下列螢幕擷取畫面顯示漏斗編輯器。下列各節將說明它。
名稱 (Name)
將工作階段提交至配對時所使用的漏斗名稱。 此名稱必須與建立比賽票證期間作為參數傳遞給 XblMatchmakingCreateMatchTicketAsync 方法的值相符。群組大小下限/上限 (Min/Max Group Size)
要從漏斗中的工作階段建立之玩家群組的最小和最大大小。 配對服務會嘗試建立盡可能大的配對群組，最多到群組大小上限。 不過，如果能夠集結足夠的玩家來達到群組大小下限，它就會建立配對群組。SHOULD 規則擴充週期 (Should Rule Expansion Cycles)
對於 SHOULD 規則，如果找不到成功的配對，配對服務會嘗試隨著時間增加搜尋空間並放寬所提供的配對規則。 此程序會依照使用 Should Rule Expansion Cycles 欄位所指定的多個週期執行。 在最後一個擴充週期時，SHOULD 規則會被捨棄，使其不再阻止票證配對。 不過，如果有多個票證可用，它們仍會用來決定最佳配對。 只有數值和 QoS 類型會在被捨棄之前擴充。 如需詳細資訊，請參閱本主題稍後的「漏斗規則的設定」一節。 增加 Should Rule Expansion Cycles 設定的值會為 SHOULD 規則擴充提供更多週期。不過，這也會增加配對持續時間。 預設值為 3，這通常足以應付大多數設定。擴充週期以五秒的固定時間間隔發生。在最後一個擴充週期時，在剩餘的配對嘗試期間將不再考慮所有 SHOULD 規則。
排名漏斗 (Ranked hopper)
一般而言，SmartMatch 會防止被封鎖的玩家被配對。 如果選取了 Ranked Hopper，就會略過此邏輯，以防止玩家使用此系統來避開技術較高的玩家。漏斗規則的設定
本節定義用來設定漏斗規則的欄位。一般規則欄位
本節中定義的欄位是所有漏斗規則共有的。- **Rule Name：**為設定目的而顯示的規則易記名稱。
-
**Rule Type：**規則類型。選項為 MUST 和 SHOULD。
- 必須滿足 MUST 規則才能成功配對。
- 可以放寬或移除 SHOULD 規則以找到成功的配對。 如需此程序的詳細資料，請參閱本主題稍早的「SHOULD 規則擴充週期」一節。
-
**Data Type：**配對規則屬性的資料類型。
可能的值如下。
- **Number：**指定簡單的 32 位元數值。
- **String：**指定最多 128 個字元的 Unicode 字串。
- **Collection：**指定字串陣列。使用此值來識別玩家的可下載內容 (DLC)、小隊成員資格或角色偏好。
- **Quality of Service：**指定在配對中包含延遲 QoS 資料的自訂資料類型。每個配對漏斗只應使用一個此類規則。
[!NOTE] 如果此限制對您的遊戲造成問題，請連絡您的開發人員客戶經理 (DAM)。
- **Total Value：**指定加總所提交之配對值的自訂資料類型。您可以使用此值來確保產生的總和位於特定範圍內或為確切值。
- **Team：**指定配對要求中所包含之玩家隊伍的自訂資料類型。您可以使用此值來避免將單一比賽票證中的玩家拆分到多個隊伍中。
資料類型特定的規則欄位
本節定義用來定義適用於某些資料類型但不適用於其他資料類型之規則的欄位。UI 應能釐清哪些資料類型適用於特定規則。- **Allow Wildcards：**指出比賽票證中是否可以省略該屬性的值。 如果省略，無論此屬性的值為何，該票證都會與任何其他票證相容。
-
**Attribute Source：**資料類型值的來源。可能的來源如下。
- **Title provided：**資料值在比賽票證中提交。
- **User stat instance：**資料值會自動從
UserStatistics服務擷取。
- **Attribute Name：**屬性值來源的名稱。 它是比賽票證中的屬性名稱，或使用者統計資料的名稱。
- **Default Value：**如果未為配對要求指定或提供任何值，則為資料類型的預設值。 當選取 Allow Wildcards 欄位且未指定任何值時，不會套用預設值。
- **Weight：**規則的重要性。 權重可用來指出在配對和規則擴充期間優先處理哪些規則。 權重值必須是正數，預設值為 1。
-
**Flatten Method：**僅限數值資料類型。
指出如何合併多個值以滿足配對的值。
它適用於單一比賽票證中不同玩家的多個值，以及跨多個票證的多個值。可能的值如下。
- **Min/Max：**使用來自不同比賽票證之多個值的最小值或最大值。
- **Average：**使用來自不同比賽票證之多個值的平均值。
- **Max Diff：**僅限數值資料類型。 兩個比較值之間可接受的最大數值差異，以滿足規則。對於 SHOULD 規則，此值是規則擴充的起點。
-
**Set Operation：**僅限集合資料類型。
在比對集合值群組時要執行的作業。可能的選項如下。
- **Intersection：**根據兩個集合之間的交集量來比對它們。此設定會產生相似或相同的集合值。
- **Difference：**根據兩個集合之間的差異量來比對它們。
- **Role Preference：**根據以角色為基礎之遊戲模式中玩家角色的偏好來比對集合。
- **Target Intersection：**Set Operation 設定的一部分。 兩個集合在配對之前的最小交集或最大差異。
- **Network Topology：**僅限 Quality of Service 資料類型。 用於 QoS 的網路拓撲。 可能的值為 Peer to Peer、Peer to Host 和 Client/Server。
-
**Maximum Latency/Scaling Maximum：**僅限 Quality of Service 資料類型。
在指定的網路拓撲內成功配對的最大延遲。
使用 Client/Server Quality of Service SHOULD 規則時，此值會被視為縮放值 (而非必要的延遲)。
[!NOTE] 此外，預設的信譽規則也會套用至漏斗。這些規則無法移除，用於確保在配對期間正確處理信譽。
- **Allow Waiting for Roles：**僅限 Collection Role Preferences 資料類型。 指定配對服務是否保留配對票證以填滿所有可用的角色。
擴充差異
指出每個擴充世代要將所提交之規則放寬多少的值。 擴充差異會在 Max Diff 值之外額外套用。 如需詳細資料，請參閱本主題稍後的範例 1 (規則擴充)。 您也可以使用擴充差異以不同的速度擴充多個數值。 這無法透過擴充週期設定來達成，因為該設定會套用至所有規則。 相反地，方法是使用小數擴充值；例如 0.4。 只有在達到新的整數時才會發生擴充，因此即使擴充週期數目相同，也能實現不同的擴充速度。QoS 擴充 (點對點、對等對主機)
對於對等遊戲的 QoS 類型擴充，無法設定擴充差異。 相反地，您應該使用下列其中一種擴充策略。- MaxLatency 小於 256 擴充會以 MaxLatency × 擴充週期執行。 例如，如果初始值為 200，則第一個週期使用 200，第二個週期使用 400。
- MaxLatency 大於或等於 256 擴充會從 50 線性縮放到 MaxLatency - 256。 例如，如果初始值為 556，則值會在週期數內從 50 線性縮放到 300。 也就是說，如果選擇了六個週期，值會是 50、100、150、200、250 和 300。 如果選擇了五個週期，值會是 50、112.5、175、237.5 和 300。
QoS 擴充 (用戶端/伺服器)
使用專用伺服器時，擴充是以相對偏好為基礎的。 在早期的擴充週期中，只會考慮最偏好的伺服器。 隨著時間推移，會使用其他較不偏好的伺服器。 為了確保適當的擴充，我們需要一個類似於 MaxLatency 的值，稱為 Scaling Maximum。它仍應設定為可接受的最大 Ping 時間。不過，此值會為玩家所提供之不同伺服器 Ping 時間提供相對的比例，而不是提供 Ping 時間的絕對需求。 您可以從要求中的清單移除 Ping 時間無法接受的伺服器，以將其排除。 返回本主題頂端。範例 1 (規則擴充)
玩家等級用於配對，玩家會根據其等級的接近程度寬鬆地配對。 等級差異最小的玩家會優先配對。- 玩家等級規則
- Rule Type：SHOULD
- Data Type：Number
- Max Diff：1
- Expansion Delta：2
- Flatten Method：Average
- 如果在此差異內找到配對，玩家就會被配對。
- 如果找不到初始配對，玩家等級值會在每次反覆運算時擴充 2 (根據預設，有三次反覆運算)。
範例 2 (集合規則)
遊戲發行了三種可供玩家使用的 DLC 類型。 此配對規則套用至「僅限 DLC」的遊戲配對，玩家應至少擁有一個 DLC 才能與其他玩家配對。- 玩家 DLC 規則
- Rule Type：MUST
- Data Type：Collection
- Set Operation：Intersection
- Target Intersection：1
在下表中，集合值表示 DLC 的擁有權。如果玩家可以使用該 DLC，值會設定為 1。如果不能，則設定為 0。|
如果此範例中的目標交集設定為 2，玩家 1 和 3 將不會被配對，因為他們之間的交集只有 1。
範例 3 (避開先前的玩家)
遊戲偏好避免與最近一起遊玩過的玩家進行遊戲。- Rule Type：MUST
- Data Type：Collection
- Set Operation：Difference
- Target Intersection：0
在 SmartMatch 設定期間定義隊伍規則
設定隊伍規則
若要設定隊伍規則，請先在 Partner Center 中建立一個。 填寫您的遊戲預期從此漏斗中配對之票證建立的隊伍大小。 例如，如果您的遊戲預期四對四，您應該建立兩個項目，每個預期的大小上限為四，且名稱不同。 還有隊伍大小下限。如果遊戲可以在隊伍中玩家較少的情況下進行，請使用它。 否則，下限和上限應該是相同的值。使用隊伍規則
設定隊伍規則之後，如果無法在不造成拆分的情況下將漏斗內票證的群組分配到隊伍中，就會阻止這些票證配對。 此規則會將產生的隊伍配置寫入目標工作階段的 members/constants/custom/matchmakingresult/initialTeam 下。這只是建議的配置。遊戲可能會發現透過重新安排玩家，可以建立更好的遊戲，同時仍能防止票證被拆分到不同的隊伍中。
PreserveSession 欄位設定為 always 的票證表示。
在這種情況下，由於隊伍已經分配給玩家，遊戲必須指定目前的隊伍配置，讓 Match 知道每個隊伍有多少空位。
為了提供每位玩家所屬隊伍的名稱，每位玩家都會將其隊伍名稱寫入遊戲工作階段的 members/me/properties/system/groups 下。
此欄位是 JArray。
將前述屬性寫入遊戲工作階段之後，一位玩家會為該工作階段建立票證，以嘗試尋找更多玩家。
當票證完成時，Match 會再次將加入之任何玩家的建議隊伍寫入 members/constants/custom/matchmakingresult/initialTeam。
偏好平均的隊伍
此外，配對會先從最大的隊伍開始進行。 這表示在假設的四對四漏斗中，四位玩家的票證會先配對在一起，直到沒有剩餘的四人票證為止。 接著繼續處理三人票證，視需要拉入單人票證，依此類推。 以這種方式，如果存在大小相似的票證且未受其他規則阻止，它們通常會彼此對戰。這讓隊伍規則相較於其他規則具有相當強的優先順序。