2

これは学校のプロジェクトです。コードを提供しないでください。正しい方向に導くためのヒントを探しているだけです。

クライアントがサブスクライブするゲーム サーバーを作成してテストします。サブスクライブすると、クライアントは現在プレイ中のゲーム (同じゲームで、その「インスタンス」が異なるだけ) のリストを受け取ります。その後、クライアントはゲームに参加するか、新しいゲームを開始するかを選択できます。実際にゲームを開始するには、少なくとも 2 人のプレイヤーが必要です。システムは、すべてが 1 つのゲームをプレイする複数のクライアント、または複数のゲームをプレイする複数のクライアントをサポートする必要があります。

このプロジェクトの目的は、Java、TCP、およびスレッド化の経験を積むことです。

私の現在の設計と実装には、server.java と client.java の 2 つのファイルがあります。

  1. サーバーファイルには、サーバー、ロビー、ゲームの 3 つのクラスがあります。
  2. クライアント ファイルには、クライアント クラスが 1 つあります。

「ゲーム」の実装は些細なことですが、それで問題ありません。

現在、サーバー クラスはクライアント クラスとの TCP 接続を確立します。クライアントがインスタンス化されるたびに、サーバー クラスでソケットが受け入れられ、プログラムが続行されます。

続いて、サーバー クラスはロビー クラスを作成します。

ロビー クラスは、私が問題を抱えている場所です。デフォルトでは、1 つの「ゲーム」オブジェクトを作成し、clientSocket に渡します。

game g = new game(clientSocket, playerID);                 
g.start();

ゲームクラスはスレッドを拡張します。これが正しい方法だと思います。各「ゲーム」はいわば個別のスレッドになるため、プレイヤー A と B は 1 つのスレッドを共有し、プレイヤー C と D は別のスレッドで新しいゲームを開始できます。

私はスレッドを初めて使用しますが、これは私が考えることができる最良の実装です。ロビー用に複数のスレッドを使用することはあまり意味がなく、クライアント用に複数のスレッドを使用するのも無意味なので、ゲーム クラスのマルチスレッド化は理想的だと思います。

現在、クライアントの 2 つのインスタンスを作成すると、両方とも同じ「スレッド」に参加しています (両方とも同じゲーム内にあり、互いに通信できます)。

新しいプレイヤーがロビーに「new」などと入力して、新しいスレッドである新しい「ゲーム」を作成できるようにするにはどうすればよいですか。

スレッド化などに関する特定の部分を誤解していると確信していますが、助けていただければ幸いです。

4

2 に答える 2

1

ゲームをスレッドにマップしません。代わりに、クライアントをスレッドにマップします。各クライアントには、そのクライアントからのコマンドの受信によって開始される作業を行う独自のスレッドがあります。新しいゲームを作成する必要がある場合は、ゲームの共有コレクションに新しいオブジェクトを作成するだけです。クライアント インスタンスで、関連付けられているゲームがある場合は、そのゲームを追跡します。

ゲームを管理するために本当にスレッドが必要であることがわかった場合は、スレッドを作成できます。クライアントが特定のゲームにコマンドを送信するときは、そのコマンドを、そのゲームを管理するスレッドによって読み取られるコマンドのキューに入れるだけです。ゲーム スレッドは、それが管理しているゲームを知る必要があるだけです。そのゲームが終了すると、それ自体を終了できます。

于 2013-02-09T01:53:13.547 に答える
0

まず、Java でのマルチプレイヤー ゲーム開発とネットワーキング (UDP/TCP) を読むことをお勧めします。私はゲーム開発者ではありませんが、たまたま大学で Java ネットワークのコースを受講し、同様のプロジェクト (ネットワーク ゲーム) を行っていました。

次に、複数のスレッドの処理は複雑さに比例します。複雑さを最小限に抑えたい。「スレッドを使用する場所を見つけなければならない」という考え方を放棄することをお勧めします。(丸い穴に四角いペグを無理に押し込まないでください;))

引き続き、要件に従ってください。

クライアントがサブスクライブするゲーム サーバーを作成してテストします。

IIRC さん、これはかなり簡単です (そして、おそらくこの部分は過ぎています)。

サブスクライブすると、クライアントは現在プレイ中のゲーム (同じゲーム、その「インスタンス」が異なるだけ) のリストを受け取ります。

サーバーとクライアント間の TCP 接続が既に確立されているため、これもかなり簡単です。

ただし、この時点で理解しておくべきことがいくつかあります。おそらく最も重要なのは、接続されているすべてのクライアントと既存のゲームに関する情報を保持する単一の中央サーバーが存在することです。つまり、システムの状態 (現在存在するゲームルームの追跡など)、クライアントの要求 (ゲームルームの作成/参加) を処理し、システムの状態に関する関連情報でクライアントを更新する必要があります (例:作成/閉鎖されたゲームルーム)。

この時点で考慮すべきもう 1 つの点は、システムにおけるクライアントの機能の範囲です。典型的な実装はおそらく、ファット サーバー、シン クライアントアーキテクチャです。基本的に、これはクライアントが（ユーザー入力からの）データの実際の処理を行わず、代わりにサーバーに依存することを意味します。ほとんどの場合、クライアントはユーザーからの入力またはサーバーからの応答のみを待っています。一方、サーバーは、クライアントからのデータの処理、システム状態 (個々のゲーム状態を含む) の更新、およびシステム/ゲーム状態の関連する変更の関係するクライアントへの通知を処理します。

その後、クライアントはゲームに参加するか、新しいゲームを開始するかを選択できます

ここで実際に行われているのは、クライアントが「ゲームに参加することを選択しました」または「ゲームを作成することを選択しました」というデータをサーバーに送信することです。サーバーはこれに基づいて動作し、懸念しているクライアントに通知します (一部のクライアントはプレイしている可能性があり、新しいゲームが生成されたかどうかを知る必要がないため、すべてではありません) 。

実際にゲームを開始するには、少なくとも 2 人のプレイヤーが必要です。

-

システムは、すべてが 1 つのゲームをプレイする複数のクライアント、または複数のゲームをプレイする複数のクライアントをサポートする必要があります。

ここでもクライアント/サーバー アーキテクチャに応じて、サーバーがすべての処理を行うか ( fat-server 、 thin-client )、クライアント ( thin-server 、 fat-client ) が処理を行い、サーバーは主にリレーとして機能します。他のクライアントを指します。ただし、可能な実装とその結果の膨大な数に圧倒されているため、これについて明確な（または自信のある）提案はありません。したがって、ネットワーキングとゲーム開発についてもっと読むことを強く勧めることはできません。個々に、これら 2 つのトピックは信じられないほど膨大であり、組み合わせるとさらに大きくなります。

最後に、スレッドの使用に関して。IIRC、開いているソケットに対して個別のスレッドをディスパッチすることは、アプリケーションが入力待ちでブロックされるのを防ぐのに役立ちます。スレッドでゲームを「ホスト」するというあなたの考えにはあまり同意できませんが、あなたは学校に通っているので、あなたがいろいろなことを試していることに感心することしかできません。

これはさらに役立つかもしれません:レッスン: ソケットのすべて。また、おそらくUDPにも興味があるかもしれません。

于 2013-02-09T05:24:05.850 に答える