View a markdown version of this page

使用無伺服器後端託管工作階段型遊戲伺服器 - 遊戲產業鏡頭

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

使用無伺服器後端託管工作階段型遊戲伺服器

為您的遊戲開發架構時，請考慮您需要的特性和功能，以及您準備擁有的操作管理開銷層級。為了在操作簡單性和靈活性之間取得最佳平衡，您可以使用雲端供應商的受管服務來建置遊戲。受管服務可讓您控制開發和自訂自己的自訂遊戲功能，同時減輕部署和管理基礎設施的負擔。

託管以工作階段為基礎的多玩家遊戲需要伺服器基礎設施來託管遊戲伺服器程序，以及可擴展的後端以進行配對和工作階段管理。下列參考架構顯示如何使用 Amazon GameLift 受管託管和無伺服器後端來管理您的工作階段型遊戲。

適用於工作階段型遊戲的 Amazon GameLift 受管託管

適用於工作階段型遊戲的 Amazon GameLift 受管託管

圖表說明讓玩家進入在 GameLift 受管遊戲託管上執行之遊戲的程序。它包含下列步驟：

  1. 遊戲用戶端會從 Amazon Cognito 身分集區請求 Amazon Cognito 身分。這可以選擇性地連接到外部身分提供者。

  2. 遊戲用戶端會收到臨時存取登入資料，並使用 Amazon Cognito 登入資料簽署請求，透過 Amazon API Gateway 請求遊戲工作階段。 Amazon Cognito

  3. API Gateway 會叫用 AWS Lambda 函數。

  4. Lambda 函數會從 Amazon DynamoDB 資料表請求玩家資料。Amazon Cognito 身分用於安全地請求正確的玩家資料，因為已驗證的身分是在請求內容資料中提供。

  5. 使用正確的玩家資料取得其他資訊 （例如玩家技能等級），Lambda 函數會透過 GameLift FlexMatch 配對來請求配對。您可以使用 JSON 型組態文件來定義 FlexMatch 配對組態。遊戲用戶端可以透過 ping 各個區域中的伺服器端點來產生延遲指標，而且延遲資料可用於支援以延遲為基礎的配對。

  6. FlexMatch 將具有適當延遲的適當玩家群組配對至區域後，會透過 GameLift 佇列請求遊戲工作階段放置。佇列包含具有一或多個已註冊區域位置的機群。

  7. 當工作階段放置在其中一個機群的位置時，事件通知會傳送至 Amazon SNS 主題。

  8. Lambda 函數將接收並處理 Amazon SNS 事件。

  9. 如果 Amazon SNS 訊息是 MatchmakingSucceeded 事件，Lambda 函數會使用伺服器連接埠和 IP 地址將結果寫入 DynamoDB。time-to-live (TTL) 值用於確保在不再需要配對票證時從 DynamoDB 中刪除。

  10. 遊戲用戶端向 API Gateway 發出簽署請求，以在特定間隔檢查配對票證的狀態。

  11. API Gateway 會叫用 Lambda 函數，以檢查配對票證狀態。

  12. Lambda 函數會檢查 DynamoDB，以判斷票證是否成功。如果成功，Lambda 函數會將 IP 地址、連接埠和玩家工作階段 ID 傳回用戶端。如果票證失敗，Lambda 函數會傳送回應，宣告相符項目尚未就緒。

  13. 遊戲用戶端會使用後端提供的連接埠和 IP 地址，使用 TCP 或 UDP 連線至遊戲伺服器。它會將玩家工作階段 ID 傳送至遊戲伺服器，而遊戲伺服器會使用 Amazon GameLift Server SDK 進行驗證。

或者，您可以修改上述架構，將 API Gateway WebSockets 與 Amazon GameLift 搭配使用。在此方法中，遊戲用戶端與遊戲後端服務之間的通訊會使用以 WebSocket 為基礎的實作進行。可以使用此實作，讓遊戲後端 Lambda 函數透過 WebSocket 向遊戲用戶端啟動伺服器端訊息，而不是實作輪詢模型。