跳轉到主要內容
使用本主題了解多人遊戲工作階段的進階概念。 本主題涵蓋下列內容:

工作階段概觀

多人遊戲工作階段目錄 (MPSD) 中的工作階段具有工作階段名稱,並被識別為工作階段範本的執行個體。 工作階段範本是為工作階段提供預設設定的 JSON 文件。 工作階段範本是服務設定的一部分,該服務設定具有服務設定識別碼 (SCID),也就是一個 GUID。 工作階段範本位於 Partner Center 上。 服務設定是面向開發人員的資源,用於擷取、管理與安全性原則。 透過 MPSD 存取工作階段時,會根據開發人員透過 Partner Center 設定的存取原則,對服務設定執行主體授權。 在服務設定的存取獲得授權並載入工作階段之後,會在工作階段層級執行次要存取檢查,例如工作階段成員資格驗證。
透過範本設定的功能,無法藉由寫入 MPSD 來變更。若要變更這些值,您必須建立並提交包含必要變更的新範本。任何未透過範本設定的項目,都可以藉由寫入 MPSD 來變更。

合約版本號碼

本主題假設您的範本使用合約版本 107,這是目前適用於 XBOX One (或更新版本) 的 MPSD 所使用的版本。

工作階段參考

每個 MPSD 工作階段都由工作階段參考唯一識別,在多人遊戲 API 中以 XblMultiplayerSessionReference 結構表示。 工作階段參考包含下列字串值。
  • 服務設定識別碼 (SCID)
  • 工作階段範本名稱
  • 工作階段名稱
工作階段參考會對應至用於識別工作階段的 URI,如下所示。 在下列範例對應中,authority 為 sessiondirectory.xboxlive.com。

工作階段的元素

每個工作階段都包含強制執行可變性與安全性規則的元素群組。這些規則因工作階段元素而異,此外還有唯讀的管理資訊 (中繼資料)。 本節說明設定工作階段的 JSON 檔案中,以及您所選範本的 JSON 檔案中所包含的工作階段元素群組。
如果您為 HTTP/REST 實作使用自訂包裝函式,您的工作階段與範本必須定義能精確反映實作功能的 JSON 物件。
每個元素群組內都有兩個內部物件。
  • 系統物件: 這些物件具有由 MPSD 強制執行並解譯的固定結構描述。它們會經過驗證與合併。由於 MPSD 定義並了解其意義,因此可以據以執行動作。如需每個系統物件的完整定義,請參閱 XblMultiplayerSession 首碼與 Session Directory URI 的參考。
  • 自訂物件: 這些物件是選擇性的,沒有結構描述。它們用於儲存與多人遊戲相關的中繼資料。由於 MPSD 無法解譯這些資料,因此不會據以執行動作。遊戲資料或儲存的資訊應該儲存在 Title-Managed Storage (TMS) 中。如需 TMS 的詳細資訊,請參閱 XBOX 服務 Title Storage 概觀。
以下是自訂 JSON 物件的範例。

工作階段常數

工作階段常數只會在建立時由建立者或工作階段範本設定。 /constants/system 物件用於定義 MPSD 所知之多人遊戲系統的常數。 與此物件相關聯的包裝函式,以 XblMultiplayerSessionConstants 結構表示。 /constants/system 物件可以定義許多項目,包括 capabilities 物件、metrics 物件、managedInitialization (範本合約版本 104 或 105) 或 memberInitialization (合約版本 107) 物件、peerToPeerRequirements 物件、peerToHostRequirements 物件以及 measurementsServerAddresses 物件。

工作階段屬性

使用 /properties/system 物件為 MPSD 定義工作階段屬性。 與此物件相關聯的包裝函式是 XblMultiplayerSessionProperties 結構。 工作階段成員可隨時寫入工作階段屬性。 JSON 格式的工作階段屬性範例包括 joinRestriction、initializationSucceeded 與 matchmaking 物件。 如需使用此元素群組的範例,請參閱目標工作階段初始化與 QoS。

成員常數

在加入時為每個工作階段成員設定成員常數。 JSON 物件為 /members/{index}/constants/system。 代表工作階段成員的包裝函式類別是 XblMultiplayerSessionMember 結構。 返回本主題頂端。

成員屬性

成員屬性只能由工作階段成員寫入。 它們設定於 /members/{index}/properties/system 物件中,並反映 XblMultiplayerSessionMember 結構的元素。 以下是一個範例。

伺服器元素

伺服器是已加入或受邀加入工作階段的非使用者。 相關聯的 JSON 物件為 /servers/{server-name}/constants/system 與 /servers/{server-name}/properties/system。 這些物件只能由伺服器寫入。
目前未使用 /servers/{server-name}/constants/system 物件。

工作階段設定

您可以透過下列方式控制工作階段的設定。
  • 使用透過 Partner Center 擷取的工作階段範本。
  • 呼叫多人遊戲與配對 API 或 REST API。您仍然必須使用範本,但範本不必包含您要設定的值。請注意,您的遊戲無法覆寫範本中已設定的常數。
另外會提供個別的 JSON 文件來定義工作階段本身。 此外,您必須實作特定遊戲所需的任何包裝函式功能。 JSON 文件的內容與任何包裝函式程式碼必須精確地相互反映,且必須反映最新的範本合約版本。 工作階段的結構描述會以工作階段版本 (主要版本) 與通訊協定修訂 (次要版本) 進行版本控制。 這兩個版本會以「100 * major + minor」的形式合併至 X-Xbl-Contract-Version 標頭中。 例如,假設最新的範本合約版本為 107,v1.7 遊戲會在每個 REST 要求中包含下列標頭:X-Xbl-Contract-Version: 107。
建議大多數 (使用 XBOX Services API (XSAPI) 的) 遊戲使用合約版本 105 與工作階段範本版本 107。

工作階段範本

每個工作階段範本都是一份 JSON 文件,屬於服務設定的一部分,用於定義要建立之工作階段的架構,並為新的工作階段提供常數。 如需詳細資訊,請參閱多人遊戲工作階段範本。 返回本主題頂端。

工作階段功能

功能是 MPSD 工作階段中的常數,用於設定 MPSD 應套用至該工作階段的行為。 您最常使用 Partner Center 在工作階段範本中設定功能。 功能設定於 /constants/system/capabilities 物件中。 如果不需要任何功能,請使用空的 capabilities 物件。
遊戲幾乎不會使用多人遊戲 API 或配對 API 變更或存取工作階段功能。
工作階段功能以 XblMultiplayerSessionCapabilities 結構表示。 它們是表示工作階段可支援哪些功能的布林值。
  • 連線
  • 遊戲進行
  • 大型大小
  • 作用中成員需要連線
XblMultiplayerSessionConstants 結構包含 SessionCapabilities 成員 (其類型為 XblMultiplayerSessionCapabilities),用於定義下列與工作階段功能相關的屬性。
  • CapabilitiesConnectivity
  • CapabilitiesGameplay
  • CapabilitiesLarge
如果遊戲定義了動態工作階段功能,工作階段常數的對應屬性會設為 true。
返回本主題頂端。

工作階段大小

MPSD 工作階段的大小取決於該工作階段中的成員數目。

工作階段大小上限

工作階段大小上限是工作階段可容納的最大工作階段成員數目。 它以 XblMultiplayerSessionConstants::MaxMembersInSession 屬性表示。 成員大小上限設定於 /constants/system 物件中。 工作階段大小上限介於 1 到 100 位工作階段成員之間,如果建立時未設定,則預設為 100。 如果所需的大小超過 100,則該工作階段稱為「大型」工作階段,並以特殊方式設定。

中斷連線

為工作階段設定大小上限,可能會導致開放的位置在某些中斷連線情境下顯示為已滿。 例如,如果玩家因網路或電源故障而中斷連線,此延遲不會立即反映在工作階段中。 成員會透過中斷連線偵測功能被設為非作用中。如需詳細資訊,請參閱「多人遊戲工作階段目錄概觀」主題中的 MPSD 變更通知處理與中斷連線偵測一節。 相較之下,使用活動訊號偵測中斷連線的對等網格,通常能在兩到三秒內察覺中斷連線,並可立即開放該玩家位置。 不過,仲裁者無法移除其他成員。

大型工作階段

大型 MPSD 工作階段最多可以有 1,000 位成員,但會停用部分工作階段功能,例如取得所有成員的清單。 工作階段是否為大型,以 XblMultiplayerSessionCapabilities::Large 屬性表示。 此屬性設為 true 表示大型工作階段。「large」功能在 /constants/system/capabilities 物件中指出。 如需詳細資訊,請參閱工作階段功能。 返回本主題頂端。

工作階段使用者狀態

MPSD 將使用者狀態定義為已新增至工作階段之使用者的狀態。 可能的使用者狀態由 XblMultiplayerSessionStatus 列舉定義。 使用者在新增至工作階段之前,也被視為處於「available」狀態。 您可以使用 XblMultiplayerSessionCurrentUserSetStatus 變更工作階段使用者狀態。 若使用 REST,請在遊戲工作階段 JSON 文件中正確設定 /members/{index}/properties/system 來進行此變更。

Reserved 使用者狀態

當仲裁者選取使用者來填補工作階段中的其中一個開放位置時,使用者會處於 Reserved 使用者狀態。 在此狀態下,使用者尚未正式接受工作階段邀請,也尚未加入工作階段以開始與對等節點連線。

Active 使用者狀態

當使用者處於 Active 狀態時,遊戲已代表使用者加入工作階段,且使用者正積極參與工作階段。 只要使用者還在玩遊戲,就會持續處於此狀態。 遊戲首次啟動時,應該檢查使用者是否已是任何工作階段的成員,通常是透過檢查工作階段狀態。 如果使用者是工作階段成員,遊戲可以直接進入遊戲,並將任何參與的本機成員設為 Active 使用者狀態。 使用者在工作階段中遊玩時,應該保持在 Active 狀態。 如果使用者透過遊戲內 UI 離開工作階段,應該呼叫 XblMultiplayerSessionLeave 將其從工作階段中移除。 如果使用者只是暫時離開遊戲 (例如遊戲受限時),遊戲應該在合理的時間內讓使用者保持在 Active 狀態。 如果使用者在遊戲指定的時間期間後仍未返回,就適合將使用者狀態變更為 Inactive。

Inactive 使用者狀態

在 Inactive 狀態下,使用者目前並未參與遊戲,但在工作階段中仍保有一個位置。 換句話說,使用者處於「非作用中」。 負責將使用者在工作階段中設為 Inactive 使用者狀態的,是使用者自己的主機。 仲裁者無法執行此動作。 將使用者設為 Inactive 狀態的範例情境包括下列各項:
  • 遊戲收到 Suspending 事件。
  • 使用者在遊戲定義的時間期間內處於非作用中 (沒有輸入或控制器回應)。對於競技型多人遊戲,建議設為兩分鐘。
  • 遊戲處於受限模式超過兩分鐘或遊戲定義的時間期間。此受限模式逾時期間,是使用者可能因使用相關應用程式或與遊戲相關的其他體驗而離開遊戲的預期時間。
  • 使用者已從工作階段非正常中斷連線。如需詳細資訊,請參閱「多人遊戲工作階段目錄概觀」主題中的 MPSD 變更通知處理與中斷連線偵測一節。
如果遊戲啟動時,特定工作階段成員的使用者狀態設為 Inactive,表示遊戲已被暫停,或使用者在工作階段中非作用中的時間過長。 由於遊戲再次啟動,這表示使用者想要繼續其所屬的遊戲工作階段。 如果遊戲啟動時使用者的狀態為 Active,這種情況可能是由於網路中斷連線,或遊戲在中斷之前無法將使用者設為 Inactive 的其他情境所致。 在上述兩種情況下,您的遊戲都應該嘗試讓使用者重新連線至遊戲,並允許其他使用者繼續遊玩,或將使用者從工作階段中移除。

工作階段結束時的使用者狀態

工作階段結束時,遊戲進行就會停止。 遊戲必須允許所有使用者使用 XblMultiplayerSessionLeave 將自己移除。 使用者離開工作階段時,與其相關聯的工作階段活動會自動清除。 返回本主題頂端。

可見度與可加入性

在 MPSD 層級,工作階段存取由兩項設定控制:工作階段可見度與工作階段可加入性。 我們在本主題中提出的可見度與可加入性建議,適用於最常見的遊戲情境。 遊戲應盡可能遵循這些設定。它們應該使用遊戲內邏輯,對新玩家是否可進入工作階段做出最終的權威判斷。

工作階段可見度

工作階段可見度以在建立工作階段時設定的常數表示。 它通常在工作階段範本中定義,並決定哪些類型的使用者具有工作階段的讀取與寫入權限。 工作階段可見度的可能值由 XblMultiplayerSearchHandleGetVisibility 定義。 JSON 檔案中可見度常數允許的設定為 open、visible 與 private。

建議的遊戲工作階段可見度:open

開放的遊戲工作階段不需要玩家保留,這可簡化邀請流程。 傳送邀請後,仲裁者不會在 MPSD 中保留玩家,而只會在本機追蹤受邀的玩家。 因此,玩家可以立即連線至仲裁者,並判斷自己是否應加入工作階段、被拒絕,或應該等待 (如果支援等待中的玩家)。 仲裁者擁有最終決定權。仲裁者會回應並指示新成員留在工作階段中或離開工作階段。 使用開放的遊戲工作階段可見度時,受邀的玩家必須在做出最終決定之前啟動遊戲並連線至仲裁者。 如果工作階段已滿或邀請遭拒,您可以向使用者顯示錯誤訊息。 若要與仲裁者建立連線,需要安全裝置位址。 XblMultiplayerSessionProperties::HostDeviceToken 屬性用於找出哪個工作階段成員是工作階段目前的仲裁者,以及受邀的玩家應使用哪個安全裝置位址進行連線。

工作階段可加入性

工作階段可加入性決定哪些類型的使用者可以加入工作階段。 它可以在工作階段期間動態設定。 工作階段可加入性的可能值如下。
  • None (預設值): 對於誰可以加入工作階段沒有任何限制。
  • Local: 只有本機使用者可以加入工作階段。
  • Followed: 只有本機使用者以及被其他工作階段成員追蹤的使用者,才能在沒有保留的情況下加入工作階段。
工作階段仲裁者可以透過可加入性設定建立私人工作階段。 將可加入性設為 local 或 followed 會限制工作階段的存取,並使其成為私人工作階段。 仲裁者也應該追蹤工作階段可加入性,以便在必要時於主機層級拒絕較舊的工作階段邀請。 例如,如果任何受邀玩家直到工作階段已滿時才到達並加入工作階段,仲裁者可以告知加入的玩家工作階段已鎖定,他們需要自動離開工作階段。 返回本主題頂端。

工作階段逾時

工作階段可以由計時器與其他外部事件變更。 工作階段逾時定義工作階段成員在自動變成非作用中或從工作階段中移除之前,可以維持在特定狀態的期間。 MPSD 也支援用於管理工作階段存留期的逾時。
對於範本合約版本 104 或 105,逾時設定位於 /constants/system/timeouts 或受管理的初始化物件中。對於版本 107 或更新版本,這些設定會個別位於 /constants/system 或受管理的初始化物件中。
計時器到期時,MPSD 不會在那一刻自動更新工作階段,並將任何變更通知仲裁者。 工作階段與逾時狀態只會在傳送讀取或寫入要求之前立即更新。 立即更新可確保傳回的資料是最新的。
工作階段逾時不會堆疊。每次更新時,針對每個工作階段成員的狀態轉換只會套用一個逾時。

目前定義的逾時

本節說明 MPSD 目前定義的逾時。
  • 所有逾時都以毫秒為單位指定。
  • 允許使用值 0,表示立即逾時。
  • 沒有值的逾時被視為無限。
由於逾時有預設值,您應該為無限逾時明確指定 null。

evaluationTimeout

此逾時表示工作階段成員做出並上傳評估決策的時間長度。 如果未收到任何決策,該決策會被視為失敗。 此逾時位於受管理的初始化物件中。

inactiveRemovalTimeout

此逾時是為已加入工作階段但目前未參與遊戲的工作階段成員設定的。 根據預設,成員會在兩小時後從工作階段中移除。
對於範本合約版本 104 或 105,此逾時被指定為 inactive 逾時。
在許多情況下,建議將 inactive 逾時設為 0。這會讓任何被設為 Inactive 狀態的使用者立即從工作階段中移除,並清除對應的位置。 對於大多數競技型多人遊戲而言,這種行為是理想的,因為如果使用者已變成非作用中或進入 Inactive 狀態,就可以快速新增新玩家。 對於合作或其他多人遊戲設計,您可能希望遊戲在使用者中斷連線或一段時間未參與遊戲時,給予他們更多時間重新連線。 請注意,沒有單一解決方案適用於所有設計情境。

joinTimeout

此逾時表示使用者加入工作階段的毫秒數。 未能加入工作階段之使用者的保留會被移除。 此逾時位於受管理的初始化物件中。

measurementTimeout

此逾時表示工作階段成員上傳測量結果的時間長度。 未能上傳測量結果的成員會被標記為失敗原因「timeout」。 此逾時位於受管理的初始化物件中。
在配對期間,會強制執行 45 秒的 QoS 測量逾時。因此,建議您在配對期間使用小於或等於 30 秒的測量逾時。

readyRemovalTimeout

此逾時是為已加入工作階段並嘗試進入遊戲的工作階段成員設定的。 這通常表示殼層已代表遊戲加入使用者,且遊戲正在啟動。 根據預設,成員會在三分鐘後從工作階段中移除並被設為 Inactive 狀態。
對於合約版本 104 或 105,此逾時被指定為 ready 逾時。

reservedRemovalTimeout

此逾時是為已被他人新增至工作階段、但尚未加入工作階段的工作階段成員設定的。 逾時到期時,保留會被刪除,且成員會被視為非作用中。 預設值為 30 秒。
對於合約版本 104 或 105,此逾時被指定為 reserved 逾時。

sessionEmptyTimeout

此逾時表示工作階段變成空的之後,經過多少毫秒會被刪除。 預設值為 0。
對於合約版本 104 或 105,此逾時被指定為 sessionEmpty 逾時。

工作階段逾時範例

  1. 一個工作階段以四位玩家開始。
  2. 兩位玩家 A 與 B 因電源故障而中斷連線。他們在遊戲中的狀態仍為 Active。
  3. 另外兩位玩家 C 與 D 使用 XblMultiplayerSessionLeave 正確地退出。
  4. 工作階段保持開啟。玩家 A 與 B 已中斷連線,但仍處於 Active 狀態。
  5. 幾天後,玩家 A 回來並啟動遊戲。
  6. 玩家 A 的遊戲檢查玩家 A 所屬的工作階段 (執行讀取),並找到幾天前遺留的工作階段。
  7. 工作階段對仍在工作階段中的兩位玩家 (A 與 B) 執行目前狀態檢查。
    1. 由於玩家 A 正在執行遊戲,對玩家 A 的目前狀態檢查成功。該玩家在對戰中的 Active 狀態維持不變。
    2. 玩家 B 未執行遊戲。因此,對玩家 B 的目前狀態檢查失敗。服務會將玩家 B 的狀態設為 Inactive。此時,玩家 B 的 inactive 逾時開始計時。
  8. 玩家 A 使用 XblMultiplayerSessionLeave 方法正確地退出工作階段。
  9. 玩家 B 的 inactive 逾時到期,並在任何人執行下一次讀取或寫入時從工作階段中移除。
  10. 工作階段現在沒有任何成員,並從服務中移除。
如果範例工作階段的 inactive 逾時設為 0,玩家 B 會在步驟 7.1 的目前狀態檢查之後立即逾時,且可能會被工作階段寫入移除。 在此情況下,工作階段會關閉,而不需要對工作階段進行額外的讀取或寫入。 返回本主題頂端。

單一主機上有多位已登入的使用者

當多位使用者在同一部主機上登入時,可能會有部分使用者在遊戲工作階段中,而其他使用者不在工作階段中或未在目前的遊戲中處於作用中狀態。 多位使用者也可能收到並接受遊戲邀請,進而影響遊戲工作階段的成員資格。 請為您的遊戲考量這些資訊,讓它能夠正確處理所有工作階段成員資格情境。 在常見的情境中,新玩家登入、在遊戲中變成作用中,並需要新增至現有的遊戲工作階段。 與建立新的遊戲工作階段一樣,遊戲只應在遊戲進行期間適當的時機新增使用者。 有多位已登入的使用者時,一或多位使用者也可能收到另一個遊戲工作階段的邀請。 遊戲不需要以任何特定方式處理這些情境。 工作階段狀態與成員事件會通知遊戲有關遊戲工作階段與使用者成員資格的任何更新。 若要為線上工作階段處理多位已登入的使用者,遊戲會為所有使用者訂閱肩拍通知,並為每位使用者使用個別的 XboxLiveContext Class 物件。 遊戲會使用 XblMultiplayerSessionInfo::ChangeNumber 屬性判斷工作階段中的特定變更,並忽略重複的肩拍通知。 返回本主題頂端。

處理程序生命週期管理

就像非多人遊戲一樣,多人遊戲工作階段中的遊戲也可能遇到遊戲暫停與終止等處理程序生命週期事件。 因此,工作階段仲裁者應該定期儲存工作階段狀態。 如果仲裁者被暫停,遊戲應該嘗試移轉仲裁者,並適當地儲存遊戲狀態。新的仲裁者接著可以還原工作階段狀態。 這樣一來,如果工作階段在 MPSD 中仍然有效,整個多人遊戲工作階段就可以暫停並在稍後繼續。 只有一個指定的對等節點 (通常是遊戲主機) 應該更新全域遊戲狀態。

遊戲中繼資料的儲存

遊戲會將遊戲中繼資料儲存在 MPSD 工作階段中。 遊戲中繼資料是顯示工作階段資料,以及讓遊戲找到並加入遊戲工作階段所需的資訊。 遊戲會將玩家特定的中繼資料儲存在工作階段成員的自訂屬性區段中,例如玩家在該工作階段中的顏色與偏好的武器。 整個工作階段的中繼資料 (例如目前的地圖) 則儲存在 MPSD 工作階段的全域自訂屬性區段中。

遊戲狀態的儲存

遊戲狀態會使用 Title Storage 服務儲存在 TMS 中。 使用此位置進行儲存,可讓遊戲在沒有權限顧慮的情況下移轉仲裁者。 如需詳細資訊,請參閱移轉仲裁者。
除非遊戲正在被暫停,否則不應嘗試以高於每五分鐘一次的頻率將遊戲狀態儲存至 TMS。
返回本主題頂端。

清除非作用中的工作階段

如果 sessionEmptyTimeout 設為 0,當最後一位玩家離開工作階段時,MPSD 工作階段就會自動刪除。 若要了解如何防止未使用的工作階段在當機或中斷連線後仍包含玩家,請參閱「多人遊戲工作階段目錄概觀」主題中的 MPSD 變更通知處理與中斷連線偵測一節。 在當機或中斷連線後未正確處理未使用的工作階段,可能會在遊戲查詢玩家的工作階段時造成問題。 建議您讓遊戲呼叫 XblMultiplayerGetSessionAsync 查詢特定使用者的所有工作階段並加以評估,藉此清除非作用中的工作階段。 當遊戲遇到過時的工作階段時,遊戲會為工作階段中的所有本機玩家呼叫 XblMultiplayerSessionLeave。 此呼叫最終會將成員數降為 0,並清除這些工作階段。 返回本主題頂端。

工作階段仲裁者

某些多人遊戲方法只應由遊戲工作階段中的一個用戶端呼叫。 此用戶端是參與工作階段的其中一部主機,稱為仲裁者或主機。 如果至少有一位工作階段成員在遊戲中,工作階段就應該有一個仲裁者來監視中途加入。

設定仲裁者

當用戶端建立工作階段時,會指定一部主機作為仲裁者。 如需詳細資訊,請參閱「多人遊戲工作」主題中的為 MPSD 工作階段設定仲裁者一節。

儲存工作階段狀態

如處理程序生命週期管理一節所述,仲裁者應該定期儲存工作階段狀態。 在遊戲移轉仲裁者的情況下,新的仲裁者必須能夠還原工作階段狀態。 如需詳細資訊,請參閱移轉仲裁者。

管理遊戲工作階段成員與中途加入

工作階段仲裁者最重要的角色,是管理進入遊戲工作階段遊玩的使用者。 這包括處理遊戲邀請、通知等待中的玩家,以及處理退出遊戲的玩家。

接收通知

仲裁者必須使用 XblMultiplayerSessionChangedHandler 接聽想要加入遊戲工作階段的新玩家。

尋找玩家填補空的遊戲工作階段位置

仲裁者會使用下列其中一項作業,尋找玩家來填補空的遊戲工作階段位置。
  • 如果您的遊戲使用大廳工作階段或其他機制來允許延遲加入,請使用該機制尋找新的工作階段成員。
  • 建立另一個對戰票證工作階段。
如需詳細資訊,請參閱「多人遊戲工作」主題中的在配對期間填補開放的工作階段位置一節。

處理受邀的工作階段成員

仲裁者必須監視受邀的工作階段成員,並對傳送給單一使用者的邀請套用最小間隔。 如需詳細資訊,請參閱「多人遊戲工作」主題中的傳送遊戲邀請一節。
最後修改於 2026年10月8日