This document is about: QUANTUM 1
SWITCH TO

Quantum Game 初期化

以下は、Artūras Šlajus(arturaz)、Erick Passos(erickpassos)、およびFredrik Holmström(fholm)との会話の抜粋です。

arturaz

私が思うQuantumの仕組みを説明しますので、間違っていたら指摘してください。

Quantumセッションを開始し、最大プレイヤー数を設定します。モードがローカルの場合、Quantumはネットワークを使用せず、マルチプレイヤーの場合は、他のQuantumインスタンス間で通信するためにPhotonを使用します。他のQuantumインスタンスをどのように特定するのかは分かりませんが、入っているPhotonルームを使用しているのではないかと思います。リプレイの役割はよく分かりません。

Quantumが動いているとき、Frame.playerCountは、あなたがQuantumに与えた最大プレイヤー数と同じになります。

ローカルモードの場合、すべてのプレイヤーは即座に接続され、f.GetPlayerInputFlags(idx)はRepeatableを返します。マルチプレイヤーモードの場合、プレイヤーがルームに接続してQuantumセッションを開始するまで、プレイヤー入力フラグはPlayerNotPresentを返します。接続後は、そのプレイヤーに対してRepeatableまたはReplacedByServerが返されるようになります。

PhotonクライアントにQuantumプレイヤーIDをどのように割り当てるのか、またQuantumプレイヤーIDが割り当てられた後にそのIDが空きになることがあるのかは分かりません。おそらく、接続が切れた場合にプレイヤーが同じスロットに再接続できるように、常にロックされていると推測します。離脱機能があるのかどうかもわかりません。

接続された後は、プレイヤーは常にquantum.SetPlayerData(quantumIdx, player);を送信する自由があります。これはセッション中の任意のタイミングで発生する可能性があります。私が見る限り、これは単なるRPCメソッドで、あなたが開発の後半で私たちに公開すると言った、基盤となる同期RPCメカニズムを利用しています。

これについて私の考えは遠からず正しいのでしょうか?

erickpassos

その理解でほぼ正しいです。

IDの割り当てについて… よく見ると、各クライアントが送信するGUIDがあります… これは割り当てられたプレイヤーインデックスを「保持」するために使用されているので、クライアントが再接続する場合には、同じインデックスが再割り当てされます。

サーバーのコールバックを使えば、その動作をオーバーホールすることができます…

基本的なPhotonルームの機能からも、ある程度のコントロールが可能です… たとえば、再接続専用にルームをロックするためには、それをオープンに保ちつつ、VISIBLEをfalseにします。

これにより、新しいクライアントは接続できなくなりますが、再接続が必要なクライアントにはまだ利用可能です。

それが興味深いのは、カスタムプラグインを必要としないことです(マッチを作成したクライアントから見えなくすることができます)。

しかし、サーバーの新しいコールバックを使えば、どのようなプレイヤーが決定論的セッションに参加できるかを制御することもできます(1.2.1でカスタムQuantumサーバープラグインプロジェクトをリリースします)。

私はここで数日間それを動かしており、サーバー側のシミュレーションもすべて完了しています…

SetPlayerDataを複数回呼び出すことも可能で、制御したい場合はサーバーコールバックがあります… :)

あなたの理解は基本的に正確でした。私はこのすべてに対してどのようなコントロールがあるかを説明しています。

良い例:

  • クライアントから送信されたこのアイテムを購入… サーバーがこれを intercept し、クライアントに送信しない…
  • サーバーがその情報を使ってバックエンドサーバーを呼び出す;
  • バックエンドが応答すると、サーバーのコードが購入したアイテムを使ってSetPlayerDataを注入します…

arturaz

質問:セッション開始時にQuantumへ情報を渡したい場合、ランタイムコンフィグを使うべきですか?

ランタイムコンフィグがシリアライズされているのは分かります。しかし、すべてのクライアントがローカルで実行しているのに、なぜシリアライズする必要があるのでしょうか?

erickpassos

はい

シリアライズされ、セッション参加時にサーバーに送信されます(サーバーは最初のものを使用します)。他のすべてのクライアントはサーバーからこの情報を受け取り、デシリアライズします。

fholm

多くのゲーム(競技用など)では、サーバーやプラグインからRuntimeConfigとRuntimePlayerの両方を送信したい場合がありますが、これが今できるようになっています。

そして、プレイヤーに自分でスロットを割り当てたり、データを送信させたりしないようにすることができます。

Back to top