ターンベースおよび非同期ゲーム
Photon Realtimeを使用すると、他のゲームと同様に非同期ゲームを構築することができます。
おもな違いは、サーバー側の設定の変更によってルームが保存される点です。保存されたルームは読み込むことができ、後で継続することが可能です。
Photonには、数分ではなく数日から数週間プレイされるゲームのための特別な一連の機能があります。
ルームのステートを持続するには外部のWebサービスが必要です。
プレイヤーはいつでもゲームを再開でき、非同期的に参加することも可能です。
システム概観
Photon Realtimeでは、アプリケーションを外部Webサービスとリンクできます。
このサービスはラップされ、Photon Serverは特別なタスクのために使用されます。
クライアントがサービスと直接通信する必要はありません。
Webサービス
保存、読み込み、データの一覧表示はWebサービスの一般的なタスクであるため、Photonはこれらの機能をデータの持続に使用します。
ダッシュボードの「Webhook」タブでWebサービスを構成すると、以下の2つの方法で使用されます:
「Webhook」としてのイベント駆動、または「WebRPC」と「イベント転送」によるクライアント操作駆動です。
Webhooks
Photon Webhookはゲームを保存し、読み込むために、Webサービスのインターフェースを確立します。
各タスクは必要に応じて自動的にPhotonによって呼び出されるので、クライアント側での処理は必要はありません。
**例:**ルームステートの保存は、すべてのプレイヤーが切断した際におこなわれます。Photonは"<BaseUrl>\GameClose"を呼び出し、ステートをPOSTデータとして渡します。
ホストでイベントを受信するには、必要に応じてフックのパスを構成します。
構成を設定するには、ダッシュボードのアプリケーションリストから 詳細 リンクをたどり、 Webhook を選択します。
詳細については、「Photon Webhooks」を参照してください。
WebRPC
WebRPCはWebhookの概念を一般化して使用できるようにしたものです。
独自のオペレーション(基本的にはRPC)を構成し、Webサービス上でそれらを呼び出すことができます。
パラメータの送受信やWebサービスのスクリプトの実装を自由におこなうことが可能です。
例:
MemoryDemoでは、ユーザーが以前プレイした(および保存した)ルームのリストを取得するためにWebRPCを使用しています。
適切なスクリプトを使用すれば、ユーザーのIDを使用してデータベースからリストを取得できます。
独自のWebRPCを構築するには、Webサービス上でスクリプトを実装する必要があります。
スクリプトのパス(ダッシュボードで構成されたベースURLを除く)は、クライアントで使用するWebRPCの名前を定義します。
JSON対応の形式では、両方向のパラメータを渡す必要があります。
詳細については、「Photon WebRPCs」をご覧ください。
「非同期」ルームの作成
ダッシュボードでアプリケーションを「isPersistent」として設定すると、実際のルームは他のルームと同じように「ルーム作成」オペレーションで作成されます。設定にはいくつかのオプションがあります。
「非同期」のルームは、すべてのプレイヤーが切断したタイムアウトの後に自動的に持続されます。
このタイムアウトは、「room time to live」(room TTL)と呼ばれ、ルーム作成時にクライアントによって設定できます(OpCreateRoom
を参照)。
ベストプラクティスの値は12秒です。
ルームを保存して読み込む方法の詳細は、「ルーム持続性ガイド」を参照してください。
ルームの退室と放棄
「非同期」のゲームでは、クライアントが切断したり、ゲームから退出するとプレイヤーをインアクティブとしてフラグします。
インアクティブとしてマークされたプレイヤーは、後から戻ることができます。必要に応じて、プレイヤーは明示的にゲームを「放棄」することができます。
これをおこなうには、適切なパラメータ値で退出オペレーションを使用します。
Photonはルーム内のすべてのアクティブおよびインアクティブのプレイヤーをリストしますが、プレイヤーがゲームを放棄したら、そのプレイヤーはゲームで認識されなくなります。また、デフォルトで、そのプレイヤーのすべてのイベントとプロパティがクリーンアップされます。
ルームの読み込み
ルームでのプレイを再開するには、ルームの名前を知っている必要があります。
クライアント側でOpReJoinRoom(name)
を使用します。
クライアントの観点からいえば、ルームがPhotonのメモリに残っているか読み込まれているかのちがいはありません。
ルームが見つからなくなった場合や、その中のアクターが期限切れになった場合に、オペレーションは失敗します。
ルームの保存や読み込みの方法の詳細については、「ルーム持続性ガイド」を参照してください。
保存されたルームのリストを取得
デモとサーバースクリプトのサンプルは、ユーザーIDごとのルームのオンラインリストを維持します。
「カスタム認証」 を使用してユーザーをログインさせ、そのユーザーのルームのリストを取得することが、基本的な概念となっています。
詳細については、GetGameList WebRPCを確認してください。
ゲームのステートを維持
プレイヤーがルームに再入室すると、プレイヤー(アクティブおよびインアクティブ)のプロパティとバッファリングされたすべてのイベントを取得します。
このデータによって、ステートの再現やプレイの再開が実現されます。
プロパティ
ルームやプレイヤーのプロパティを設定できます。
変更の履歴は不要だがステートを維持する必要がある場合、プロパティを使用するのが最適です。
ゲームボードのステートやターン番号をプロパティとして簡単に保存することができます。
すべてのプレイヤーがルームプロパティを設定することができるので、問題なく非同期的にターンを交代できます。
プレイヤーがゲームを放棄(またはタイムアウト)するとプレイヤーのプロパティがクリーンアップされます。
イベントキャッシュ
各ルームには、オンデマンドでイベントを格納するキャッシュがあります。
イベントをキャッシュする際、それらが発生した順番が保持されます。この順番は、格納するものが以前の操作やデータに依存する場合に必要です。
デフォルトでは、イベントはキャッシュされませんが、OpRaiseEvent
にはイベントのキャッシュを制御するためのパラメータがあります。
通常通りイベントを送信して、それを格納するためにEventCaching.AddToRoomCache
を使用します。
また、オプションEventCaching.RemoveFromRoomCache
を使ってキャッシュからイベントを削除することができます。
その場合、eventCode、"sender actorNumber "、"content "ハッシュテーブルをフィルタとして使用します。
特定のアクターのイベント、同じeventCodeのすべてのイベント、または特定のコンテンツのイベントを削除することができます。
なんらかの「タグ」をイベントと一緒に意図的に送信する場合、コンテンツによるイベントの削除は非常に有効です。
「MemoryDemo」は、各イベントで「ターン」を送信し、それを使用して古いターンのイベントを削除し、イベント履歴を短く保ちます(長く続くゲームの場合に適しています)。
詳細については、「キャッシュされたイベント」を参照してください。
イベント転送
イベントのキャッシュ以外に、イベントをWebサービスに転送する方法があります。
この場合も、クライアント上のOpRaiseEvent
がWebFlagsを使用して、イベントをGameEventのWebhookとしてWebサーバに転送する必要があるかを定義します。
転送されたイベントには、ゲームに戻るためのチャンネルがありませんが、ゲーム内の行動や結果を追跡する際に有用です。
マッチの結果を計算したり、ユーザーのELOの調整に使用することができます。
これは「MemoryDemo」では使用されません。
Back to top