C ++ Entity-Component-Systemsのコンポーネントに適切にアクセスするにはどうすればよいですか？

（私が説明しているのは、この設計に基づいています：エンティティシステムフレームワークとは何ですか？、下にスクロールすると見つかります）

C ++でエンティティコンポーネントシステムを作成するときに問題が発生します。コンポーネントクラスがあります。

class Component { /* ... */ };

これは実際には、他のコンポーネントを作成するためのインターフェースです。したがって、カスタムコンポーネントを作成するには、インターフェイスを実装し、ゲーム内で使用されるデータを追加するだけです。

class SampleComponent : public Component { int foo, float bar ... };

これらのコンポーネントはEntityクラス内に格納され、Entityの各インスタンスに一意のIDが付与されます。

class Entity {
     int ID;
     std::unordered_map<string, Component*> components;
     string getName();
     /* ... */
};

コンポーネントは、コンポーネントの名前をハッシュすることでエンティティに追加されます（これはおそらくそれほど素晴らしい考えではありません）。カスタムコンポーネントを追加すると、コンポーネントタイプ（ベースクラス）として保存されます。

一方、今では、内部にNodeインターフェースを使用するSystemインターフェースがあります。Nodeクラスは、単一のエンティティのコンポーネントの一部を格納するために使用されます（システムはエンティティのすべてのコンポーネントの使用に関心がないため）。システムがupdate()必要な場合、システムは異なるエンティティから作成されたノードを反復処理するだけです。そう：

/* System and Node implementations: (not the interfaces!) */

class SampleSystem : public System {
        std::list<SampleNode> nodes; //uses SampleNode, not Node
        void update();
        /* ... */
};

class SampleNode : public Node {
        /* Here I define which components SampleNode (and SampleSystem) "needs" */
        SampleComponent* sc;
        PhysicsComponent* pc;
        /* ... more components could go here */
};

問題は、エンティティをSampleSystemに渡すことでSampleNodesを構築するとしましょう。次に、SampleNodeは、エンティティにSampleSystemが使用する必要なコンポーネントがあるかどうかを「チェック」します。エンティティ内の目的のコンポーネントにアクセスする必要があるときに問題が発生します。コンポーネントはComponent（基本クラス）コレクションに格納されているため、コンポーネントにアクセスして新しいノードにコピーできません。私は一時的にComponent派生型にキャストすることで問題を解決しましたが、これを行うより良い方法があるかどうかを知りたかったのです。これがすでに持っているものを再設計することを意味するかどうかを理解しています。ありがとう。

あなたが保存しようとしている場合はComponent、すべて一緒にコレクションの中のを、あなたは、コレクションに保存されているタイプとして、共通の基本クラスを使用しなければならない、とあなたがアクセスしようとするので、あなたは正しい型にキャストする必要がありComponent、コレクションで秒。typeidただし、テンプレートと関数を巧妙に使用することで、間違った派生クラスにキャストしようとする問題を解消できます。

次のように宣言されたマップでは：

std::unordered_map<const std::type_info* , Component *> components;

次のようなaddComponent関数

components[&typeid(*component)] = component;

およびgetComponent：

template <typename T>
T* getComponent()
{
    if(components.count(&typeid(T)) != 0)
    {
        return static_cast<T*>(components[&typeid(T)]);
    }
    else 
    {
        return NullComponent;
    }
}

ミスキャストは発生しません。これはtypeid、コンポーネントのランタイム型（最も派生した型）の型情報へのポインターを返すためです。コンポーネントはその型情報をキーとして保存されるため、型の不一致が原因でキャストが問題を引き起こすことはありません。それはタイプが成分由来かなければならないとして、また、テンプレートの種類にコンパイル時の型チェックを取得するstatic_cast<T*>と型が異なるだろうunordered_map。

ただし、共通のコレクションに異なるタイプのコンポーネントを保存する必要はありません。Entityを含むという考えを放棄し、Component代わりに各Componentストアを持っている場合Entity（実際には、おそらく単なる整数IDになります）、各派生コンポーネントタイプをとしてではなく、派生タイプの独自のコレクションに格納できます共通の基本型、およびそのIDを介してComponents を見つけEntityます。

この2番目の実装は、最初の実装よりも少し直感的ではありませんが、システムのユーザーが気にする必要のないインターフェイスの背後に実装の詳細として隠されている可能性があります。2番目は実際に使用していないため、どちらが良いかについてはコメントしませんが、static_castを使用することは、最初の実装が提供するほど強力な型の保証を伴う問題としては見ていません。プラットフォームや哲学的信念に応じて問題となる場合とそうでない場合があるRTTIが必要なことに注意してください。

Chewyには問題はありませんが、C ++ 11を使用している場合は、使用できる新しい型がいくつかあります。

const std::type_info*マップでキーとして使用する代わりに、のラッパーであるstd::type_index（cppreference.comを参照）を使用できますstd::type_info。なぜそれを使用するのですか？std::type_index実際との関係格納std::type_infoポインタとしては、それは心配するあなたのための1つの少ないのポインタです。

実際にC ++ 11を使用している場合は、Componentスマートポインター内に参照を保存することをお勧めします。したがって、マップは次のようになります。

std::map<std::type_index, std::shared_ptr<Component> > components

新しいエントリを追加するには次のようにします。

components[std::type_index(typeid(*component))] = component

where componentはタイプstd::shared_ptr<Component>です。特定のタイプへの参照を取得すると、次のComponentようになります。

template <typename T>
std::shared_ptr<T> getComponent()
{
    std::type_index index(typeid(T));
    if(components.count(std::type_index(typeid(T)) != 0)
    {
        return static_pointer_cast<T>(components[index]);
    }
    else
    {
        return NullComponent
    }
}

の使用にも注意してください static_pointer_cast代わりのstatic_cast。