遊戲工作階段可見度與可加入性

在 XBOX One (或更新版本) 上，遊戲工作階段與遊戲派對的可見度與可加入性設定，控制著多人遊戲體驗的存取。 若要為加入工作階段，以及邀請玩家加入遊戲工作階段與派對提供絕佳的使用者體驗，您需要了解這些設定。 本主題將檢視可見度與可加入性之間的差異。本主題也會討論我們建議遊戲使用的特定設定，以便為使用者提供最佳的多人遊戲使用者流程。

​

遊戲工作階段可見度

多人遊戲工作階段目錄 (MPSD) 的工作階段存取由兩項設定把關：工作階段可見度與工作階段可加入性。 這些設定可用來在 MPSD 層級限制工作階段存取。 存取控制的第一個層面是工作階段可見度。 工作階段可見度是在建立工作階段時設定的常數。 工作階段可見度通常在工作階段範本中定義，並決定哪些類型的使用者具有工作階段的讀取與寫入權限。 可見度設定的值如下。

• Open： 所有使用者都可以讀取與寫入工作階段。
• Visible： 所有使用者都可以讀取，但只有已加入與已保留的玩家可以寫入工作階段。
• Private： 只有已加入與已保留的玩家可以讀取或寫入工作階段。

​

遊戲工作階段可加入性

存取控制的第二個層面是可加入性。 它可以在工作階段存留期間動態設定，並決定哪些類型的使用者可以加入工作階段。 工作階段可加入性的值如下。

• None： (預設值) 對於誰可以加入工作階段沒有任何限制。
• Local： 只有本機使用者可以加入工作階段。
• Followed： 只有本機使用者以及被其他工作階段成員追蹤的使用者，才能在沒有保留的情況下加入工作階段。

工作階段仲裁者或主機可以透過可加入性設定建立「private」工作階段：將可加入性設為 local 或 followed 會限制遊戲工作階段的存取，並使其成為私人工作階段。 此外，工作階段仲裁者或主機應該追蹤工作階段的可加入性，以便在必要時於主機層級拒絕較舊的工作階段邀請。 例如，如果任何受邀玩家直到工作階段已滿時才到達並加入工作階段或派對，仲裁者或主機可以告知任何加入的玩家工作階段已鎖定。他們需要自動離開工作階段或派對。

​

遊戲派對可加入性

除了控制 MPSD 工作階段之外，遊戲也可以控制遊戲派對的可加入性狀態。 此設定可用來在派對層級限制遊戲派對的存取。 建立遊戲派對時，可以動態變更派對可加入性。 遊戲派對的可加入性狀態會反映在派對邀請 UI 中。 可加入性狀態可以設為下列值：

• Invite-only： 此設定需要邀請才能加入遊戲派對。
• Joinable by Friends： (預設值) 此設定需要好友關係，玩家才能加入遊戲派對 (若要加入派對，派對成員必須追蹤加入的玩家)。

可加入性可用來建立僅限邀請的遊戲派對。 若要限制派對的存取，並要求玩家必須收到邀請才能加入，應將可加入性設為「invite-only」。

​

建議

下列建議適用於最常見的遊戲情境。 遊戲應盡可能遵循這些設定，並應使用遊戲內邏輯，對新玩家是否可進入工作階段做出最終的權威判斷。

​

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

開放的遊戲工作階段不需要玩家保留。這可簡化邀請的流程。 傳送邀請後，工作階段仲裁者或主機不會在工作階段文件中保留玩家。 相反地，工作階段仲裁者或主機只會在本機追蹤受邀的玩家。 這讓玩家可以立即連線至主機，並判斷自己是否應加入工作階段、被拒絕，或應該等待 (如果支援等待中的玩家)。 仲裁者或主機擁有最終決定權，會回應並指示新成員留在工作階段中或離開工作階段。

​

建議的遊戲工作階段可加入性：預設 (未設定)

目前遊戲工作階段可加入性不會影響 Party App UI，也不會向使用者顯示。 為了簡化遊戲流程，遊戲可加入性應保持預設值，所有加入的決定權都應透過仲裁者或主機處理。

​

建議的遊戲派對可加入性

遊戲派對可加入性取決於遊戲想要為使用者提供的工作階段類型。 兩種情境如下。

• 開放遊戲： 對於開放遊戲，遊戲派對可加入性應保持預設值：「Joinable by Friends」。這讓好友可以在沒有邀請的情況下加入遊戲派對 (並進而加入遊戲工作階段)。
• 私人遊戲： 對於私人或封閉的遊戲，遊戲派對可加入性應設為「invite only」。這會限制其他玩家在沒有邀請的情況下加入派對 (並進而加入遊戲工作階段)。

對於這兩種遊戲類型，仲裁者或主機仍應保有決定誰可以進入工作階段的最終權限。 這可以解決將遊戲流程從開放切換為私人時可能發生的任何競爭條件。 如果仲裁者或主機拒絕某位玩家，被拒絕的遊戲執行個體應將該玩家從工作階段中移除，並顯示遊戲內 UI，讓玩家也可以離開派對。

​

工作階段大小上限

工作階段的成員大小上限可用來限制加入遊戲工作階段的玩家人數。 不過，此限制可能會導致開放的位置在某些中斷連線情境下仍顯示為已滿。 例如，如果玩家因網路或電源故障而中斷連線，此延遲不會立即反映在工作階段中。 一旦目前狀態服務偵測到中斷連線 (最多 20 秒)，成員就會被設為非作用中。接著，在非作用中逾時到期後，玩家就會被移除。 相較之下，使用活動訊號偵測中斷連線的對等網格，通常能在兩到三秒內察覺中斷連線，並可立即開放該玩家位置。 不過，仲裁者或主機無法移除其他成員。 為了解決此問題，工作階段的成員大小上限應一律設定為高於遊戲實際支援的最大玩家人數。 例如，如果玩家人數為 8，遊戲應將工作階段大小上限設為 12。 如此一來，即使先前的玩家尚未逾時，新玩家仍然可以加入。 仲裁者或主機會判斷工作階段是否已滿，然後設定一個自訂工作階段屬性，以決定新玩家是否仍可加入 (IsFull : “true”)。 這讓加入的玩家可以快速檢查工作階段是否可加入。 仲裁者或主機也應維護一個自訂屬性，依索引指出哪些成員已逾時 (例如 TimedOutPlayers : “3, 5, 9”)。 這讓新玩家可以正確識別目前的工作階段成員。

​

通知等待中的玩家

遊戲可以在遊戲派對之外管理一份排隊玩家清單，以支援等待中的玩家。 當玩家連線至主機而遊戲工作階段已滿時，該玩家會被新增至主機上的內部等候清單。 排隊的玩家不會加入遊戲工作階段，但會留在遊戲派對中。 為了將網路流量降至最低，等待中的玩家此時會中斷與主機的連線。

1. 當遊戲工作階段中有位置為等待中的玩家開放時，仲裁者或主機會呼叫 XblMultiplayerSessionAddMemberReservation 為該玩家新增保留。
2. 此時，等待中的玩家還不知道這項保留。因此，仲裁者或主機必須呼叫 PullReservedPlayersAsync 方法。 這會根據通知設定與遊戲焦點狀態，為所有已保留的玩家觸發 UI 通知或 GameSessionReady 通知。
3. 收到此通知時，新玩家會重新連線至主機，並加入工作階段。

或者，玩家也可以保持與主機的連線，並在主機通知玩家有可用位置時加入工作階段。 不過，在此流程中，無法在遊戲外顯示 UI 通知。

​

用戶端多人遊戲流程