ゲーム サーバーのコンテナー化とパッケージ化
Windows
Windows では、通常、ゲーム サーバー実行可能ファイルとその他のファイルを ZIP ファイルとしてパッケージ化し、ゲーム アセットとしてアップロードします。アセットはコンテナー イメージと組み合わされ、ゲーム サーバー ビルドが作成されます。ベース コンテナー イメージは、Windows オペレーティング システム ファイルと、ゲームを実行できる実行環境を提供します。PlayFab は、Windows ビルドで使用するマネージド コンテナー イメージのセットを提供します。 Game Manager または CreateBuildWithManagedContainer() などの API を介して Windows ビルドを作成する際、アセットと、それらをコンテナーのファイル システム内のどこにマウントするかを指定します。また、ゲームを起動するシェル コマンド (StartGameCommand) も指定します。これは以下のようになります。
StartGameCommand は、PlayFab Game Server SDK を使用するアプリケーションを起動し、ゲーム クライアントに応対する準備ができたら ReadyForPlayers を呼び出す必要があります。アプリケーション プロセスが終了すると、コンテナーは終了しリサイクルされます。
Linux
Linux では、ゲーム実行可能ファイルとアセットをパッケージ化して、コンテナー イメージを自分で作成します。実行時にコンテナー イメージと組み合わされるアセットの使用は任意です。 Game Manager または CreateBuildWithCustomContainer() などの API を介して Linux ビルドを作成する際、アセットと、それらをコンテナーのファイル システム内のどこにマウントするかを任意で指定できます。ゲームを起動するシェル コマンド (StartGameCommand) の指定も任意です。このコマンドはコンテナー イメージ内に含めることもできるためです。
PlayFab Multiplayer Servers 用の Linux コンテナー イメージの作成に関する詳細については、こちら を参照してください。
Windows 用のマネージド コンテナー
PlayFab は現在、Windows Server Core をベースとした PlayFab Multiplayer コンテナー イメージという 1 つのマネージド コンテナーをサポートしています。このコンテナーは Docker Hub からダウンロードでき、ローカル環境を Azure の実行時環境に一致させることができます。 開発機上でマルチプレイヤー サーバーのステート マシンをローカルにステップスルーできるデバッグ ツールもあります。 詳細については、ゲーム サーバーのローカル デバッグと PlayFab との統合 を参照してください。 以下の図は、ゲーム サーバーのアップロードと、このパッケージを選択したコンテナーと結合する主要なフローを示しています。マネージド コンテナーの更新
マネージド コンテナーは Windows プロジェクトにおける最も簡単な統合オプションであり、コンテナーに慣れていない場合の出発点として最適です。 マネージド コンテナーの主要な機能として、PlayFab は信頼性の高いプレイを保証するために、重要なセキュリティ修正を含むベース イメージを自動的に更新します。一般的に、セキュリティ更新は毎月行われ、サービスの中断は発生しません。詳細については、Windows 用の OS パッチ更新 を参照してください。 アップグレード中、自然にリサイクルされているスタンバイ中のセッションは、更新されたコンテナー イメージと同じゲーム サーバー パッケージに置き換えられます。 PlayFab が使用中のマネージド コンテナー イメージを更新する予定がある場合、PlayStream イベントを受け取ります。PlayFab Game Server SDK の統合
詳細は次を参照: PlayFab Game Server SDK (GSDK) を使用したゲーム サーバーの統合 PlayFab Game Server SDK (GSDK) は、C++、C#、Java などの複数のプログラミング言語で提供されます。GSDK は、ゲーム サーバーを VM 上にインストールされたローカル エージェントに接続します。このエージェントは、PlayFab コントロール インフラストラクチャとの主要なサーバー間の相互作用を仲介します。 ゲーム サーバーが初期化されると、preparing 状態 に入り、PlayFab はゲーム サーバーがReadyForPlayers() を呼び出すのを待ちます。
これが呼び出されると、ゲーム サーバーは standing by 状態 に入り、RequestMultiplayerServer メソッド経由でマッチメイキング サービスから PlayFab への割り当てリクエストを待機します。
以下の図は、PlayFab マルチプレイヤー サーバーの状態を示しています。
表面上、ゲーム サーバーを実行し、動作を継続させるための唯一の要件は ReadyForPlayers() の呼び出しです。ただし、最良のユーザー エクスペリエンスを提供するために処理したいコールバックやイベントがいくつかあります。
サーバー スクリプトと PlayFab で構成された環境変数
場合によっては、ゲーム サーバーで CMD、PowerShell、または bash スクリプト (「ブートストラッパー」) を実行してから、コンパイル済みのゲーム サーバー実行可能ファイルを起動したいことがあります。このスクリプトは、コンテナーの内部環境を構成したり、実行可能ファイルにコマンドライン引数を渡したり、ゲーム サーバー実行可能ファイル自体で実行したくないタスクを行ったりできます。 利便性のため、PlayFab は一部のビルド情報を以下の環境変数としてコンテナー内に設定します。これらは GSDK 経由でもアクセスできますが、スクリプトからは環境変数を使用する方が簡単です。- PF_TITLE_ID - セッション ホストのタイトル ID
- PF_BUILD_ID - セッション ホストのビルド ID
- PF_REGION - セッション ホストの Azure リージョン
- PUBLIC_IPV4_ADDRESS - VM のパブリック IP アドレス
- PF_VM_ID - VM の一意識別子 (例: ‘xcloudeau4u4yyxj4xymu:AustraliaEast:1E03_6f27ad88-9bc3-4ea3-8d16-75480aba4637:tvmps_0e05c37e0bbdca298a09fb0d597bd666eb7c5fd0ebcf1fed4c52e608a39a7c9c_d’)
- CERTIFICATE_FOLDER - ゲーム証明書を含むフォルダー
- PF_SERVER_LOG_DIRECTORY - ゲーム ログを含むフォルダー
- PF_SERVER_INSTANCE_NUMBER - サーバーのインスタンス番号。VM 上の最初のサーバーは 0、2 番目は 1、3 番目は 2、以降同様です。