最佳做法與推出檢查清單

• 讓您的遊戲伺服器處理程序在其遊戲工作階段結束時結束，例如在比賽結束或最後一位連線的玩家離開時。如果您的遊戲允許玩家重新連線，請先等候一段短暫的寬限期。MPS 不會替您結束遊戲工作階段。伺服器會保持 Active 狀態，直到其處理程序結束為止。當您的組建縮減規模時，MPS 不會移除 Active 伺服器，因此永不結束的伺服器會持續使用您需付費的容量。當處理程序結束時，MPS 會以新伺服器取代它。如需詳細資訊，請參閱多人遊戲伺服器的生命週期。
• 在伺服器變成 Active 時啟動計時器，例如當 Game Server SDK (GSDK) 的 ReadyForPlayers 方法傳回 true 時。如果在幾分鐘內沒有玩家連線，請結束處理程序。如此一來，無論基於何種原因而沒有人加入的伺服器，都不會無限期地保持 Active 狀態。請根據玩家通常需要多久時間連線來設定逾時。
• 註冊 GSDK 關機回呼，執行伺服器所需的任何清除作業，然後結束處理程序。GSDK 不會替您結束處理程序。當您呼叫 ShutdownMultiplayerServer API 時，MPS 會呼叫您的回呼。請只在緊急情況下呼叫此 API，例如終止卡住的遊戲伺服器。在一般情況下，請勿用它來結束遊戲工作階段。您的遊戲伺服器應該自行結束，如本節前面所述。如果處理程序在關機要求後 15 分鐘仍在執行，MPS 會強制終止它。如需詳細資訊，請參閱正常關閉遊戲伺服器。

​

開發

• 使用 LocalMultiplayerAgent (LMA) 在本機工作站上進行反覆測試。這可節省時間和金錢，同時由於所有成品都在本機執行，也能簡化偵錯。此工具為開放原始碼，隨時歡迎貢獻與改進。如需使用方式的詳細資訊，請參閱這裡
• 使用排程設定具體的排程，以節省 standingBy 伺服器成本。例如，如果所有測試和驗證都在上班時間進行，可以將排程設定為只在上班時間保留 standingBy 伺服器。設定排程不需額外費用。
• 使用 VM 計量或您自己的分析工具，決定在您所選大小的一部 VM 上要執行多少個遊戲伺服器。請在 VM 上的每個伺服器都處於 Active 狀態且玩家滿載的情況下進行負載測試。同一部 VM 上的伺服器可能幾乎同時被配置並開始其遊戲工作階段，因此請在測試中包含這種情況。請保留 CPU 餘裕：在 CPU 飽和的 VM 上，配置可能會變慢或失敗。
• 使用伺服器記錄和當機傾印進行更深入的分析。

​

推出準備

• 讓您的配置要求以組建別名為目標。它們有助於在伺服器更新時將遊戲用戶端順暢地移轉到較新的遊戲伺服器，也有助於管理配額問題 (稍後討論)。
• 使用 QoS 信標追蹤離遊戲用戶端最近的區域，並將該區域用於配置。這些信標也可以與 PlayFab Matchmaking 結合使用，將延遲相近的用戶端分在同一組，並配置離他們最近的伺服器。
• 充分運用 PlayFab MPS 完整的地理涵蓋範圍，確保遊戲伺服器一律位於靠近玩家的位置。請考慮在一個地理區域中使用多個區域，以便在發生區域性故障時提供更高的可用性。例如，在 NorthEurope 和 WestEurope 都有伺服器，並在配置要求中指定這兩個區域 (依優先順序)，可讓在某個區域中失敗的配置在清單中的下一個區域成功。
• 當您針對組建別名進行配置時，請在 PreferredRegions 中依偏好順序列出每個能為玩家提供可接受體驗的區域。MPS 會依該順序嘗試您的區域，而組建權數只決定由哪個組建處理區域內的要求。權數為 0 的組建永遠不會被使用，即使作為回復也不會。如需詳細資訊，請參閱回復到其他組建和區域。
• 如果 RequestMultiplayerServer 失敗並傳回 MultiplayerServerTooManyRequests 錯誤，表示在任何要求的區域中都沒有組建具有 StandingBy 伺服器。儘管名稱如此，此錯誤並不表示您的要求受到節流。若要避免此錯誤：
  • 在 PreferredRegions 中列出數個鄰近區域。
  • 依照預期的尖峰設定待命伺服器。
  • 為每個組建區域設定伺服器數量上限，並在預期尖峰之上保留餘裕。即使待命伺服器用盡，MPS 也不會建立超過該上限的伺服器。
• 在推出前及早為組建使用的每個 VM 系列和區域要求配額。當您推出新組建時，在舊組建的伺服器清空之前，新舊組建會同時使用核心，因此請要求足以供兩者使用的配額。若要分散容量，請考慮將使用不同 VM 系列的組建放在同一個別名之後，讓配置可以回復到同一區域中的另一個 VM 系列。
• 在某些情況下，遊戲伺服器的虛擬機器 SKU 可能無法在遊戲預定推出的所有區域中使用。在這種情況下，請使用別名依 SKU 和區域分割組建，或在單一組建內使用區域覆寫，只為這些區域選擇不同的虛擬機器 SKU。
• 使用動態 StandingBy 根據需求擴展遊戲伺服器。將此功能與預設的靜態 standingBy 設定結合，可提供符合成本效益的方式來因應推出期間的高需求。
• 在推出前為遊戲伺服器設定監視。開啟 VM 計量，即可在 Game Manager 中查看 VM 的 CPU、記憶體、磁碟和網路計量。如需更進階的監視，請使用 VmStartupScript 在 VM 上安裝您自己的監視工具。VmStartupScriptGallery 存放庫提供範例，可將 VM 計量和遊戲伺服器記錄傳送到 Azure Monitor、Application Insights 和 Azure Data Explorer 等服務。

​

推出當天

• 使用 PlayFab Game Manager 中的儀表板和事件串流追蹤遊戲的成功推出。花點時間慶祝吧，這是您應得的！

​

推出後

• 遊戲通常會形成一種需求節奏，可以再次組合成排程。將排程與動態 StandingBy 搭配使用，以符合成本效益的方式在推出後調整遊戲規模。
• 使用組建別名進行遊戲伺服器更新，並將流量逐步導向新的遊戲體驗。
• 當您將別名移至新組建時，請將舊組建的待命伺服器設定為 0，讓 MPS 可以釋放其閒置的 VM。只有在舊組建的 Active 伺服器清空之後，才刪除舊組建。此外，請讓用戶端要求的區域與別名中組建所部署的區域保持同步。如果別名中沒有任何組建部署在任何要求的區域中，要求會失敗並傳回 MultiplayerServerNotFound。