3

Photon Serverの公式フォーラムで質問しましたが、このウェブサイトほど活発ではないので、私が話していることを理解している人もいるかもしれませんので、時間と知識があれば共有してください。ありがとうございました!

ここに来る...

だから、私はPhoton上のサーバーの非常にうまく機能するプロトタイプと、サーバーと通信する基本的なUnity3Dクライアントを持っています。これは、cjrgamingの例から作成されました。

クライアントは次のことができます:接続、リクエストの送信、暗号化されたリクエストの確立と送信サーバーは次のことができます:ピアの作成、操作リクエストの受信、クライアントへの操作応答またはイベントの送信、私の小さな追加は次のとおりです:ゲームに多くの操作がある場合、巨大なswitch caseステートメントを使用する必要はありませんが、操作をカテゴリ(クラス)に分割し、デリゲートとディクショナリを使用してそれらを呼び出します。

投稿の準備ができたら、その実例を投稿しますが、実際の質問に答えます。(長い投稿で申し訳ありませんが、私が知っていることとこれまでに持っていることを説明する必要がありました):

クライアントからサーバーに送信される実際の操作は何ですか?または、サーバーからクライアントに発生したイベント(すべてのクライアントを一度に?)?

最初は、それぞれの操作がゲーム内の特定のユーザーフローだと思っていました。たとえば、操作コード「1」は、プレーヤーXがプレーヤーYを撃ち、何かをしたいことを意味します。しかし、その後、バイト制限に従って、short intなどに拡張せずに、すべてのゲームロジックを255回の操作だけに入れることはできないことに気付きました。

次に、同じ操作コード要求で異なる可能性があるchannelIDもあることがわかりました...つまり、操作コードはユーザーフローではなく、クライアント間の同じ/類似のアクションのデータストリームですおよびserverであり、channelIDを使用して、サーバーで計算される要求された操作を区別できます。

それで...!私は(ダミーの私)、クライアントからサーバーに、またはその逆に送信されるパラメーターが辞書にあることに気付きました。これにより、可能なユーザーフローの別のレイヤーが追加されます。

だから..今、私は物事を理解していると思いますが、彼らは私をさらに混乱させました。

誰かが操作/イベント/channelIDの目的を簡単に説明できますか?たとえば、小さなマルチプレーヤーゲームを行う場合、ユーザー(ゲーム)フローを作成するために使用するものは、次のようになります。->プレーヤーがターゲットに当たる、プレーヤーが世界のアイテムを拾う、プレーヤーがメッセージを送信する。このフローごとに一意のオペコードを使用しますか、それとも操作を意味ごとにグループ化し、チャネルを使用してリクエストを区別しますか、それともここでも、多くのユーザーフローに同じchannelIDを使用し、パラメーター内のIDでそれらを異なりますか?

私が意味をなしたことを願っています。

少なくとも時間はありますが、助けてくれてありがとう!

4

1 に答える 1

14

1)チャネルはまったく異なるトピックであり、トリガーしたいさまざまな種類のゲームロジックを区別することとは関係ありません。代わりに、優先順位を決定し、操作が別の操作に依存している場合は状態を示すためのチャネルがあります。

a)シュート操作と2つのチャット操作を送信し、クライアントのネットワーク接続が最適ではないため、最初のチャットメッセージは途中で失われますが、送信すると述べたとおりです。サーバーがそれを受信したことをサーバーが確認していない場合、Photonクライアントは確実にそれを自動的に再送信します。これで、最初のチャットメッセージが正常に送信されるまで、他のチャットメッセージはPhotonによって保留されます。そうしないと、同じ作成者から表示されたチャットメッセージの順序が、それらが書き込まれた順序ではなくなります。ここで問題となるのは、同じタイプの操作を抑制するだけでなく、失われた操作が繰り返された後にのみ送信する必要がある他の操作がある可能性があることです(たとえば、「ユーザーがチャット" 彼が去る前に彼が送った最後のチャットメッセージの後まで、操作は画面に表示されるべきではありません)。一方、同じタイプのすべての操作を抑制する必要はありません。たとえば、プレーヤーは2人の異なる他のユーザーとプライベートで話すことができ、そのうちの1人へのメッセージがすぐに伝わらない場合、他の1人へのすべてのメッセージを保留する理由はありません。この問題に対するフォトンの解決策はチャネルです。相互に依存するすべての操作を同じチャネルで送信しますが、それらから独立している操作は別のチャネルで送信します。ここで操作の1つを繰り返す必要がある場合、他のチャネルでの操作は抑制されませんが、同じチャネルでの操作は抑制されます。一方、同じタイプのすべての操作を抑制する必要はありません。たとえば、プレーヤーは2人の異なる他のユーザーとプライベートで話すことができ、そのうちの1人へのメッセージがすぐに伝わらない場合、他の1人へのすべてのメッセージを保留する理由はありません。この問題に対するフォトンの解決策はチャネルです。相互に依存するすべての操作を同じチャネルで送信しますが、それらから独立している操作は別のチャネルで送信します。ここで操作の1つを繰り返す必要がある場合、他のチャネルでの操作は抑制されませんが、同じチャネルでの操作は抑制されます。一方、同じタイプのすべての操作を抑制する必要はありません。たとえば、プレーヤーは2人の異なる他のユーザーとプライベートで話すことができ、そのうちの1人へのメッセージがすぐに伝わらない場合、他の1人へのすべてのメッセージを保留する理由はありません。この問題に対するフォトンの解決策はチャネルです。相互に依存するすべての操作を同じチャネルで送信しますが、それらから独立している操作は別のチャネルで送信します。ここで操作の1つを繰り返す必要がある場合、他のチャネルでの操作は抑制されませんが、同じチャネルでの操作は抑制されます。そうすれば、他のメッセージへのすべてのメッセージを差し控える理由はありません。この問題に対するフォトンの解決策はチャネルです。相互に依存するすべての操作を同じチャネルで送信しますが、それらから独立している操作は別のチャネルで送信します。ここで操作の1つを繰り返す必要がある場合、他のチャネルでの操作は抑制されませんが、同じチャネルでの操作は抑制されます。そうすれば、他のメッセージへのすべてのメッセージを差し控える理由はありません。この問題に対するフォトンの解決策はチャネルです。相互に依存するすべての操作を同じチャネルで送信しますが、それらから独立している操作は別のチャネルで送信します。ここで操作の1つを繰り返す必要がある場合、他のチャネルでの操作は抑制されませんが、同じチャネルでの操作は抑制されます。

b)チャネルの別の手段は、優先順位を決定することです。チャネルIDが低いほど、優先順位は高くなります。したがって、優先度の低いデータやその他のデータが少量あり、それがたまたま大量に表示される可能性がある場合は、優先度の高いデータを低いチャネルで送信することをお勧めします。チャネルID。この方法では、IDが高いチャネルでは、まだ送信されていない大量のデータが送信用にキューに入れられている可能性がありますが、それでもすぐに送信されます。

2)操作とイベントは両方ともメッセージです。実際には、operationRequest、operationResponse、eventの3種類のメッセージがあります。

a)クライアントは、PhotonPeer.opCustom()を介して、特定の操作コードを含むoperationRequestをサーバーに送信できます。部屋への参加や退室などの一般的な操作は、LiteやLoadBalancingアプリケーションなどのPhotonアプリケーション層からのアプリケーションによってすでに実装されています。Photonアプリケーション用にクライアント側APIが提供されている場合、このAPIは、前述のアプリケーションのクライアント側APIのように、opCustom()への正しいパラメーターで呼び出しをラップするopJoin()などの関数をすぐに提供できます。行う。

b)特定のコードを使用した操作がアプリケーションレベルでどのように実装されているかに応じて、サーバーは、operationReqeustを受信したクライアントにoperationResponseを送信する場合があります。たとえば、LitePeer.opJoin()はサーバーからの参加応答をトリガーしますが、LitePeer.opRaiseEventは応答をトリガーしません。

c)アプリケーションレベルでの操作の実装方法に応じて、サーバーは特定のクライアントにイベントを送信する場合と送信しない場合があります。たとえば、LitePeer.opJoin()は参加イベントをトリガーし、その部屋のすべてのプレーヤーに送信されます。LitePeer.opRaiseEvent()は、デフォルトで、送信側を除く同じルーム内のすべてのクライアントに対して、サーバーに渡されたペイロードを保持しているイベントをサーバーに発生させます。ただし、opRaiseEvent()は、呼び出し元のクライアントに受信側のクライアントを指定する可能性を提供します。

3)「プレイヤーがターゲットにヒットし、プレイヤーが世界のアイテムを拾い上げ、プレイヤーがメッセージを送信する」これらに特別なサーバー側ロジックが必要な場合は、異なるコードを使用して独自の操作として実装します。そうでない場合は、opRaiseEvent()を使用してこれらの情報を送信しますが、これらの情報ごとに異なるeventCodeを指定します。ただし、operation-およびeventCodesは、異なる種類の情報間で異なるように使用することを目的としています。チャットメッセージ、ピックアップヒット、位置の更新などのように。したがって、プレーヤーaはプレーヤーbにプレーヤーcをヒットしたことを伝え、プレーヤーbはプレーヤーdにプレーヤーdをヒットしたことを伝えます。どちらも同じコードを使用します。どのプレイヤーが攻撃されたかに関する情報は、どの程度の強さで攻撃されたか、どの武器で攻撃されたかと同じように、操作のペイロードに属します。

于 2012-07-25T15:36:00.627 に答える