5

これはゲームのビジネス ロジックの一部であるため、モデルの一部である可能性があります。

コントローラーの一部と見なされるプレーヤー入力をシミュレートしていると見なされる可能性があるため、コントローラーの一部である可能性があります。それとも？

マリオのクリボーのような普通の敵はどうですか？

更新:うわー、それは私が期待していた答えではありません。私が知る限り、AI は自律型ゲーム システムの内部部分であり、したがってモデルです。私はまだ確信が持てません。

4

9 に答える 9

10

MVC は、多数のアプリケーションのアーキテクチャとして非常にうまく機能します。一部のアプリケーションでは、MVC が外部インターフェース、特により複雑なアーキテクチャの一部としてのユーザー インターフェースに適している場合があります。

問題をパターンに「無理やりはめ込もう」としていることに気付いた場合、それはおそらく適切なパターンではありません。UI に MVC を使用する - 他のパターン (メッセージ バス、またはオブザーバー/リスナーなど) または AI に他の OO 手法を使用します (@Bill the Lizard の戦略の提案は引き続き適用されます)。

ハンマーだけでなく、ツールボックス全体を使用してください。;-)

于 2008-12-10T18:19:40.310 に答える
7

三目並べのような単純なゲームを考えてみてください。さまざまなコンピューターの難易度レベルで対戦する必要があります。各難易度をStrategyにすると、さまざまな実装に簡単にドロップできます。

于 2008-12-10T17:19:21.290 に答える
7

敵の AIにはモデル(ゲームのプレイ方法を指定するインテリジェントな内部構造) があり、人間のプレイヤーと NPC の両方が使用できるコントローラーを使用して、ゲーム環境での状態を操作します。

于 2008-12-10T17:20:24.597 に答える
5

MVC はもともと純粋な GUI アーキテクチャ パターンであったことを思い出してください。したがって、AI やネットワーキングなどにうまく対応できないことは当然のことです。しかし、ここでそれを使用することにはまだいくつかの利点があります。しかし、コードが何を達成するかは、コードがチェーンのどこに位置するかほど重要ではありません。何かが内部にあるように見えるからといって、そうであるとは限りません。

例えば。ボットを作成している場合、基本的には文字を操作するためのスクリプトを作成するだけである可能性が高くなります。その意味で、スクリプト インターフェイスは既存のコントローラーであり、スクリプトは完全にコントローラーの外部にあります。その高レベルの AI を記述するためにモデルの近くに行くことさえありません..

あなたが元のプログラマーで、プレイヤーの操作 (例えば、どこかをクリックしてそこを歩き始める) またはボット スタイルのスクリプトによってトリガーされる低レベルの AI 機能を書かなければならなかったとしたら、あなたはそれを書いていたでしょう。モデルに。

「AI」などの単一の概念を、モデルからコントローラーを介して、コントローラーを操作する人または何かにまで広げることは直感的ではないように思えるかもしれませんが、2 つの非常に異なる概念をお互い。開発者がプレイヤー キャラクターと同じインターフェースをノンプレイヤー キャラクターに提供しようとしているという観点から見ると、それは明らかです。システム内のプレーヤーと非プレーヤーの両方に通常存在する低レベルの実装に加えて、システムは作成します。

于 2009-01-09T12:23:48.790 に答える
1

人間のプレイヤーをシミュレートしているように見えるので、人間のプレイヤーと同じ位置にあるはずです。つまり、コントローラーとやり取りするのは外部要素です。(明らかな理由から、ディスプレイは実際には必要ありません。)

編集：実際、私はそれを取り戻します。人間が読めるものではなく、ディスプレイがあります。「ディスプレイ」は、シリアル化されたデータを AI にストリーミングすることを意味する場合でも、ゲームの状態情報を AI に伝達する役割を果たします。

パート 2: なるほど…それは、私が考えていたのとまったく同じタイプの AI ではありません。同じ方法で処理できると思いますが、そうすると、意味をなさない可能性のある新しい機能がコントローラーに公開されることになります。(たとえば、コントローラーは、プレイヤーのユニットとコンピューターのユニットの両方の移動を公開する必要があります。)

モデルに動作を入れます：

Goomba.move()
{
    /* Move Goomba forward one unit. */
}

そして、その動作の呼び出しはコントローラーに入ります。

Controller.advanceTime()
{
    foreach(Goomba goomba in state.getGoombas())
    {
        goomba.move();
    }
}
于 2008-12-10T17:11:08.390 に答える
1

敵の AI モデルはゲームのルールを知っており、それらのルールに従って内部状態を変更します。ゲーム コントローラーは、内部状態をどのように変更するかを決定するために使用できる、外部ゲームの状態に関する知識を AI に提供します。

(私が最初にここに書いたもの:)

ゲームの世界と対話する AI の部分は、コントローラーにあります。自律的なエージェントとして意思決定を行う AI の部分は、モデルに含まれます。コントローラーは、AI のモデルを、その決定の基礎となる必要がある状態で更新し、コントローラーはゲームを変更し、AI モデルの変更に基づいてビューをレンダリングします。

クリボーの場合、ゲーム コントローラーはクリボー モデルをマリオの位置 (視界内にある場合) で更新し、クリボー モデルは移動しようとしている場所を更新します。コントローラーは、障害物がなければクリボーを動かし (つまり、モデルの位置を更新し)、クリボーの新しい状態でビューをレンダリングします。

于 2008-12-10T17:21:18.993 に答える
0

私の意見では、どの MVC 実装でも、モデルはドメイン ロジックを保持する必要があります。それが自律型オブジェクト (ロジックがメソッド内に組み込まれている) またはソケット ストリーム ラッパー (ロジックが外部リソースを介して実行される場合) の場合は常に、マルチプレイヤーについて考えてください)。 . コントローラーは、いくつかの外部変数 (例: CLI パラメーター、イベント ディスパッチャー) に基づいて、モデルの呼び出し元/ハンドラーとして使用する必要があります。次に、必要なデータ (配列、シリアル化された変数、またはある種のデータ転送オブジェクトとして) を適切なビュー (ゲーム画面、コンソール ターミナル) に返します。

乾杯、アラン

于 2008-12-12T18:09:47.230 に答える
0

MVC のどこに収まるかはわかりません。この疑似コードは、私が A* パス検索 AI を行った方法を非常に単純化したものです。

sprite {
  x,y
  image // this object contains everything about drawing
  path[] // an array of path nodes generated by my AI
  onNode(node) {
    if (x == node.x) && (y == node.y) return true
    return false
  }
  update () {
    moveto(path.last())
    if (onNode(path.last())) path.pop()
    if (path.empty()) path = doAI()
  }
  doAI() {
    ...
    return newPath
  }
  moveto(node) {
    ...
  }
  draw (screen) {
    if (screen.over(x, y)) image.draw(x-screen.x, y-screen.y)
  }
}

screen = //something the platform would create
spriteCollection = //my game objects

foreach (sprite in spriteCollection) {
  sprite.update()
  sprite.draw(screen)
}
于 2008-12-10T18:52:16.797 に答える
-1

ない。コントローラーを介してモデルと通信する独立したエージェントとして AI をプログラムします。または、必要に応じて、AI はAモデルですが、モデルではありません。

于 2009-01-05T13:41:16.710 に答える