3

私のグループが大学で行っている「ゲーム」プロジェクト用の戦艦ゲームを作成しようとしています。以前はほとんどすべての出力が Eclipse コンソールにあったため、これまで GUI を実際に使用したことはありませんでした。

まず、GUI クラスを作成しました。これは実質的に「ランナー」クラスです。JFrame をロードします。
表示される 2 つのゲーム ボードのディメンションを設定し、ネストされた for ループを使用して GUICells からグリッドを作成する 2 つ目のクラス、GUIGrid があります。
これには、マウスの動作を検出し、各セルの x 座標と y 座標を格納するためのリスナーなどが含まれます。テスト コードの一部を実行して、どちらのグリッドでもクリックできるようにしました。ポップアップで、そのセルがどの座標であるかが正確にわかります。

これらのクラスに加えて、船の種類の 5 つのサブクラスを持つ Ship クラスと、プレーヤーの名前を格納し、使用する Ship オブジェクトの配列を作成する Player クラスがあります。

最後に、論理クラスがあります。GridLogic クラスと CellLogic クラスがあります。前者はネストされた for ループを使用して、CellLogic オブジェクトの 2D 配列を作成します。次に、CellLogic クラスは、セルが攻撃されたかどうかに関する座標や情報などを格納します。

私の質問 (ついに!) は、これはシステムをモデル化する正しい方法ですか? CellLogic と CellGUI のクラスを見ると、かなり似ているように見えます。さらに、GUI をマウス クリックに応答させることはできますが、GUI をロジックに接続するのに非常に苦労しています。たとえば、船をグリッドに追加して、どの位置に船を格納するかを 2D 配列に格納する方法がわかりません。膨大な量のコードを投稿することなく、誰かが私が少なくとも正しい軌道に乗っているかどうか、またはシステムを分離しすぎているかどうかを教えてくれることを望んでいました.

4

4 に答える 4

3

分離は良いと思いますが、もっと明確にすることができます。MVC パターンを使用すると、モデル (船とグリッド)、コントローラー (ロジック)、およびビュー (グリッドを描画する jframe) を明確に定義できます。

基本的に、モデルは他に何も知りません。コントローラーはビューとモデルを認識し、ビューはモデルの描画方法を認識し、ユーザー入力に対する反応としてコントローラーを呼び出します。つまり、ユーザーがクリックすると、ビューは座標と発生したイベントを使用してコントローラーを呼び出すだけです。このコントローラーはグリッドを変更し、再描画を発行します。

したがって、私の視点では、おそらく cellGUI クラスは必要なく、すべてを描画するビューだけが必要です (ただし、x、y を cellgui クラスに格納すると、このようにモデル化できます...)。しかし、セルロジッククラスは必要ありません。グリッド全体を変更する方法と、すでに何かがある場合などに何が起こるかを知っている「より高い」コントローラーが必要です。

于 2013-04-24T09:03:09.457 に答える
2

The tendency of over-using sub-classing is very common to university projects. Subclassing is a thing which mostly is avoided today. In your example there won't be a real benefit of using sub-classes for ship types. A better design would be to just use a Ship class which has an enum ShipType. This will also make the evaluation easier later.

To answer your comment: Well your approach misses some kind of GridModel which contains the 2D grid and the Player objects (all game data). This GridModel is known in GridGUI and GridLogic. The GridLogic modifies the GridModel and tells the GridGui to repaint the changed model. The GridGUI doesn't modify the model it just informs the GridLogic that a click at the grid-coordinate x, y happened. Then it's on the logic to modify the model and let the GUI refresh itself. See the Model-View-Controller-Pattern for more details.

于 2013-04-24T08:55:26.363 に答える
1

ここで1つの答えが得られないと思いますが、これが私の見解です。明らかにMVC。特に、メインの GUI を 1 つのクラス (JFrame、メニューなど) に保ちます。ボードを別の場所に保管します。Cells & Ships を使用して自分自身を描画します。セルには情報 (x,y、どの船が乗っているか、爆撃されているかどうか) が含まれ、船のクラスには、x,y から x,y まで、レンダリングする画像の型があります。次に、部分的に透明な爆弾の画像を作成して、その下に船が見えるようにします。

ボードは正方形、船、そして最終的にそれらの上に爆弾を描きます。

ポップアップの代わりに、(ラベルに) いくつかの重要な情報を表示できるデバッグ フレームがあると役立ちます。実行ログ以外に

コントローラーは、モデル (セルと船) の助けを借りて BattleShip クラスになります。誰がプレイしたか、どこでプレイしたかなどのコミュニケーションを別々に保ちます -> インターフェースを介して Board と話すので、新しいビューを備えた Web コミュニケーションに変更できます。

于 2013-04-24T09:04:45.770 に答える