0

自分のゲームに一種のユニバーサル ゲーム要素クラスを設定する最善の方法を見つけようとしています。作ってみたいのも似たような構造です..

GameElementPositionMovement (ルート クラス) ->GameElementVisual (すべてのグラフィックスを処理) ->GameElementPersonality (ゲーム ロジックを処理)

次に、GameElementPersonality のインスタンスを作成するだけで、さまざまなパーソナリティ (モンスター、ヒーロー、アイコンなど) を設定できるようにしたいと考えていますが、そのコンストラクターでは、ビジュアルおよび配置/移動の側面も設定できます。

別の質問でこれについて言及しましたが、返された答えは...

ロジックとビジュアル（「ビュー」）クラスを保存するには、一種の「データモデル」クラスが必要なようです。ビジュアル クラスはデータ モデルから継承するべきではなく、それを使用する必要があります。これは OOP 関連の問題です: IS と HAS (継承と合成)

しかし、それを理解しているかどうかはわかりません。視覚データのない位置/動きは、適切な最初のルート クラスのようです。次に、視覚的な側面 (GameElementVisual) を追加し、最後に、鎧、ダメージ、健康などのパーソナリティの「特性」 (GameElementPersonality) を追加します。

したがって、私はポジショニング/移動、ビジュアルとロジックを分離したままにしており、私がレイアウトした階層がそれを行うための最良の方法であると推測しましたが、これはこれを行うための良い方法ではありませんか? もっとフラットにすべき？GameElementPositionMovement を使用して、ビジュアル インスタンスとロジック インスタンスの両方を作成し、それ自体を格納しますか?

4

2 に答える 2

2

次のような構造を作成できます。

(疑似コード)
ElementData

//it doesn't have to extend any particular class
//however it would be nice if it could  dispatch events and register listeners
class ElementData implements IEventDispatcher
{
    public function ElementData() //constructor 
    {
        //do some stuff
    }

    public function setSomeProperty(value:int):void
    {
        //
    }

    public function doSomeCrazyStuff():void
    {
        //
    }
}

ElementVisual

class ElementVisual extends MovieClip //or just Sprite or even DiplayObjectContainer
{
    public function ElementVisual(elementData)
    {
        //constructor takes an instance of ElementData class

        elementData.addEventListener(CHANGE, onDataChange)

        elementData.doSomeCrazyStuff();
        if (userCliked)
        {
            elementData.setSomeProperty(15);
        }   

        //you can have here some interactions with user (keyboard, mouse)
        //then it can communicate with elenemtData and 'listen' what it says.
    }

    function onDataChange
    {
        //react accordingly
    }
}

いくつかの視覚的表現 (これらの多くが必要になる場合があります)

class Monster extends ElementVisual
{
    //do all the graphic, animations etc
}

次に、すべてのデータ、ビジュアルなどを設定するためのクラスが必要です。最も単純な実装では、「ドキュメント クラス」にすることができます。

これは適切な MVC モデルではありません。視覚化からロジックを切り離す概念を示す単純な例です。

MVC が唯一の解決策ではありません。他にも役立つ「デザイン パターン」と呼ばれるものがあります...

于 2012-06-08T16:39:31.213 に答える
0

ええ、MVC のアイデアは、物事を分離しておくことです。あなたの場合、最終的にすべてを 1 つの継承チェーンに分割し、最終的には、すべてのプロパティを継承する別のオブジェクトからすべてのプロパティを継承する 1 つのタイプのオブジェクトになります。別のオブジェクトなので、すべてを表すこのもののインスタンスが得られます。そのため、これは使用するのに適したパターンではありません。

代わりに、GameElementPositionMovement クラス (メイン クラス) がある場合は、GameElementVisual のインスタンスと、GameElementPersonality のインスタンス (または必要に応じて複数のインスタンス) を作成します。次に、プロパティへの変更が GameElementPersonality (またはコレクションを作成することを選択した場合はコレクション内) で行われるたびに、イベントをディスパッチできます。メイン クラスの GameElementPositionMovement は、ディスパッチされたイベントをリッスンし、取得したときにそれを設定/渡すことができます。 GameElementPersonality インスタンスまたは配列を GameElementVisual に渡します。次に、GameElementVisual では、常に現在のモデルに基づいて描画するだけです。モデルはビュー ロジックから分離されています。おそらく、別のクラスまたは GameElementPositionMovement でコントロールを処理することも必要になるでしょう。(制御はモデルの修正であり、

このようにして、モデルは制御ロジックとビュー ロジックのクリーンなままになります。何がどこに行くのかが明確に分離され、実際にはビューの種類のみがモデルに依存し、コントローラーの種類はビューに依存しますが、インターフェイスがモデルに対して確立されている場合ビュー コントローラーはそれぞれ、この方法で相互に通信する必要があります。これらのパーツのいずれかを、インターフェイスを実装する新しいクラスと交換できます (小さなゲームでは問題になる可能性は低いですが、設計はこの機能に適しているため、将来のスケーラビリティに役立ちます)。 ）。

于 2012-06-08T15:53:03.407 に答える