オブジェクトの更新、内部か外部か？

タイトルは少しわかりにくいですが、質問を短いフレーズで説明する方法は考えられません。だからここにあります：

物理/タイルベースなど、ゲームエンジンを作成しているときはいつでも、物事をどのように管理すればよいかわからないところにいつも行きます。世界のエンティティは自分で処理する必要がありますか、それとも管理するグローバルシステムが必要ですか？

簡単な例を次に示します。各オブジェクトが彼の周りの世界を見て（衝突をチェック）、それに基づいて移動する必要があります。

[注、これはオブジェクトがタイルごとに移動するタイルベースのゲームなので、物理を使用してタイル間を移動していません]

public class Actor : GameObject
    {
        private void MoveTo(Vector2 location)
        {
            if (world.getTile(location) != solid && world.objAtTile(location) == null)
            {
                Tweener.addTween(this, location);
            }
          }
        }

または、各オブジェクトの動きは、世界がすべてをチェックする世界で操作する必要がありますか？

public class Actor : GameObject
    {
        private void MoveTo(Vector2 location)
        {
            world.moveTo(location);
          }
        }

public class World
{

    public void moveObject(GameObject obj, Vector2 location)
    {
      //called from object

      if (getTile(location) != solid && objAtTile(location) == null)
         {
                Tweener.addTween(obj, location);
         }
    }
}

この例ではそれほど重要ではありませんが、後で問題が発生するのがわかります。前もって感謝します。

例はJavaですが、タグで言語が指定されていません。C ++では、答えはありませんどちらも - あなたはこのためにメンバ関数を使用するべきではありません！

void move_to(actor *a, world *w, vec2 location);

簡単な答えはありません。

プログラミングにおけるほとんどのものと同様に、それはトレードオフです。個々のオブジェクトにより多くの電力を与えると、オブジェクトが大きくなり、したがって遅くなりますが、エンジンの理解と拡張が容易になります。すべてを一緒に処理できるメガクラスを用意する方が高速かもしれませんが、メガクラスを用意する必要があります。つまり、超大規模なクラスを作成することは、一般に悪い形と考えられています。

特定のタイプのすべてのオブジェクトを表す単一のクラスがあり、それらのデータをリストに格納し、インデックスのみを渡して個々のオブジェクトのプロパティを取得する、コンポーネントおよびデータ駆動型設計に関するいくつかの記事を読みました。私はこれを実行可能なタイプのアーキテクチャーと見なすことができますが、オブジェクト指向の全体のポイントにややこしいと感じ、批判もかなりの割合で受けています。

個人的にはオブジェクトにもっと力を与えることをお勧めします。それはオブジェクト指向言語でより理に適っており、（私は想像するでしょうが）時間の経過とともに理解し、維持するのが容易になります。

コメントの前に多くのことが不明確だったので、私は私の答えを更新しています。私の考えを説明する間、私と一緒に裸になってください。

一般的に、設計で考慮すべき2つの重要な側面は、凝集と結合です。より再利用可能で拡張可能な設計を作成するには、高い凝集性と低い結合が必要であることは誰もが知っています。

したがって、世界がすべてを管理する必要がある場合、それは凝集度が低く、結合が密であることを意味します（すべてを知り、実行する必要があるため）。ただし、ゲームエンティティがすべてを実行する必要がある場合も同様です。彼の場所の更新、テクスチャのレンダリングなど。

あなたが本当に興味を持っているのは、エンティティの1つの側面に焦点を当てたシステムを作成することです。たとえば、ゲームエンティティはテクスチャを持つことができますが、レンダラーはそのテクスチャを画面にレンダリングする必要があります。レンダラーは、エンティティが持っている他のプロパティを気にしません。

少し詳しく言えば、ゲームエンティティは単なるプロパティのバッグです。これらのプロパティは、特定のプロパティに焦点を当てたシステムによって操作されます。そして、これがコンポーネントベースのエンティティシステム（CBES）の出番であり、プロパティ=コンポーネントです。

具体的には、システム（またはサブシステム）を使用したCBES 。この設計では、エンティティが持つ他のコンポーネントを気にせずに、エンティティの特定のコンポーネントに焦点を当てたいくつかのシステムを使用する傾向があります。また、システムは、これらのコンポーネントを処理するために必要な情報のみと結合されます。

あなたの例を見てみましょう。エンティティを移動する場所の入力はプレーヤーのコントローラーに基づいているため、おそらくPlayerControllerSystemが存在します。このシステムは、他の多くのものとは別に、エンティティのPositionComponentを制御します。この場合、PlayerControllerSystemはLevelとPositionComponentを認識する必要があります。後で衝突検出を追加することにした場合は、エンティティの位置を再び使用するCollisionSystemを作成しますが、今回はバウンディングボックスを計算します（またはBoundingBoxComponentを呼び出してください）。実際、コンポーネントを追加/削除するだけで、動作を（オンザフライであっても）簡単にオンまたはオフに切り替えることができます。したがって、より多くの動作は、より多くのシステムがエンティティのコンポーネントを操作していることを意味しますが、それらはすべて、低結合で明確に定義されたクラスにあります。スクリプトが必要ですか？ScriptComponentを追加します。バム！2つのクラスでスクリプト機能を追加しました。物理？音？また同じ。

したがって、私がSubSystemsでCBESを推奨しているのは、それが完全にOOであり、全体的に保守/拡張が容易なシステムであるためです。動作をエンティティに追加するのは、動作に必要なデータと必要なエンティティを決定するのと同じくらい簡単です。

サブシステムを備えたコンポーネントベースのエンティティシステムの詳細については、エンティティシステムの T = Machineによる優れた一連のブログ投稿がMMOG開発の未来です。著者は、Entity Systems Projectという名前のさまざまな実装を収集するためのWikiを作成することさえしました

一般的なコンポーネントベースのエンティティシステムに関する一般的な（そしてよく知られている）投稿は、 Tony Hawk Proのシステムを作成したEvolve階層です。

最後に、サンプルコードを含むライブラリを探している場合は、Artemisライブラリ以外に進めないでください。Artemisは主にJavaですが、これはC＃のポートです（これは現在、XNAプロジェクトで使用しています）。

私は通常、オブジェクトがそれ自体を処理するデザインを使用します（結局のところ、それがメソッドの目的です）が、ベースワールドにはすべてのオブジェクトのリストがあり、それらのリストを使用してそれらを調整します。したがって、次のようなもの：

class World {
  var walls = [];
  var actors = [];
  function update() {
    for each (actor in actors) {
      actor.update(walls);
    }
  }
}

class Actor {
  function update(walls) {
    this.move();
    for each (wall in walls) {
      this.collide(wall);
    }
  }
}

それを乾いた状態に保ち、恥ずかしがり屋で、他の人に話しなさい。

あなたが行きたい場所に移動できるかどうかを世界に尋ねるよりも、世界にあなたの俳優を動かすように依頼する方が良いです。これにより、ワールドクラスなどでパスファインディングアルゴリズムを簡単に変更できます。もちろん、これをアクターのベースクラスに任せることもできますが、それが私が取る方向と理由です。

編集：元の質問に対するこの回答のために十分に明確な線を引かなかったと述べたフィードバックのために書き直されました。

できれば質問をもう少し明確にしたいと思います。オブジェクトに作用するロジックは、そのオブジェクトの内部または外部である必要があります。投稿の最後の部分では、後でトラブルを回避するために、質問をするための基礎としてデザインの寿命について具体的に言及しています。

私の簡単な高レベルの答えは、オブジェクトに作用するすべてのロジックをそのオブジェクト内に保持することです。

オブジェクトを移動するのにワールドは必要ありません。必要なのは、移動するオブジェクトと移動先の場所を表すベクトルだけです。目的地が選択されているとき、または衝突のために環境への反応が必要なときに、世界が作用する可能性がありますが、それらは作業するために与えられた例の外です。

質問の根本的な部分に対処し、設計の寿命を延ばすために、コンポーネント指向のアーキテクチャを提案します。コンポーネントアーキテクチャは、オブジェクトをデータと機能の個別のセットに分解します（データのロジックを維持するための上記の私の答えに進むと仮定します）。構造がCEntity-> CHuman-> CSoldier-> CPlayerCharacterのようになっている場合は、ロジックを変更する必要があり、そのツリーのどこにあるかに応じて、常に問題が発生します（たとえば、人間のタイプは他にいくつありますか？）複数のオブジェクトタイプに影響を与える可能性があります。

代わりに、コンポーネントシステムには、ICompRenderable、ICompMoveable、ICompHealth、ICompInventoryなどのCEntityオブジェクトの構成を定義する一連のインターフェイスがあります。CCompMoveableHumanと、場合によってはCCompMoveableSoldierとCCompMoveablePlayerを使用して、個々の移動パターンを別々に保つ場所。兵士がフォーメーションで実行するように変更されたとしましょう。この変更は、そのコンポーネントを使用して構築されたエンティティにのみ影響します。

まとめると、ロジックを適用するデータとロジックを含めることをお勧めします。また、オブジェクトを個別のコンポーネントに分割して、「どこに配置すればよいですか」を削減することをお勧めします。質問し、メンテナンスの容易さとその拡張性により、将来への安定性を提供します。

お役に立てれば。

コンポーネントベースのアーキテクチャについて読むことをお勧めします。ブログの投稿、プレゼンテーション、それらについての書き込みはかなり多く、私がこれまで以上に優れた仕事をすることができます。

AltDevBlogADayにはそれに関するかなりの数の投稿があり、ゲームエンティティに関するこのシリーズは非常に良いものです：http://altdevblogaday.com/2011/07/10/the-game-entity-–-part-ia-retrospect/解決しようとしている問題に焦点を当てた複数の部分。