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 클래스는 단일 엔터티의 일부 구성 요소를 저장하는 데 사용됩니다 (시스템이 모든 엔터티의 구성 요소 사용에 관심이 없기 때문에). 시스템이 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에 전달하여 SampleNode를 빌드한다고 가정 해 봅시다. 그런 다음 SampleNode는 엔티티에 SampleSystem에서 사용할 필수 구성 요소가 있는지 "확인"합니다. Entity 내부의 원하는 구성 요소에 액세스해야 할 때 문제가 나타납니다. 구성 요소가 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구성 요소의 런타임 유형 (가장 파생 된 유형)의 유형 정보에 대한 포인터를 리턴 하기 때문 입니다. 구성 요소는 키로 해당 유형 정보와 함께 저장되므로 유형이 일치하지 않아 캐스트로 인해 문제가 발생할 수 없습니다. 또한 Component에서 파생 된 형식이거나 static_cast<T*>형식이 일치하지 않으므로 템플릿 형식에서 컴파일 시간 형식 검사를 수행 합니다 unordered_map.

그러나 다른 유형의 구성 요소를 공통 콜렉션에 저장할 필요는 없습니다. Entity포함 하는 아이디어를 버리고 Component대신 각 Component저장소에 Entity(실제로 정수 ID 일 것입니다) 각 저장소를 갖는 경우 각 파생 구성 요소 유형을 원래 형식 대신 자체 파생 형식 컬렉션에 저장할 수 있습니다 공통 기본 유형을 찾고 해당 ID Component를 "포함"하는 것을 찾습니다 Entity.

이 두 번째 구현은 첫 번째보다 생각하기에 다소 직관적이지 않지만 인터페이스 뒤에 구현 세부 정보로 숨겨져 시스템 사용자가 신경 쓸 필요가 없습니다. 나는 실제로 두 번째를 사용하지 않았으므로 어느 것이 더 낫다고 언급하지는 않지만 static_cast를 첫 번째 구현이 제공하는 유형에 대한 강력한 보증 문제로 보지 않습니다. 플랫폼 및 / 또는 철학적 신념에 따라 문제가 될 수도 있고 아닐 수도있는 RTTI가 필요합니다.

Chewy가 맞지만 C ++ 11을 사용하는 경우 사용할 수있는 새로운 유형이 있습니다.

const std::type_info*지도에서 키로 사용하는 대신 std::type_index( cppreference.com 참조 )를 사용할 수 있습니다 std::type_info. 왜 사용하겠습니까? 는 std::type_index사실과의 관계 저장 std::type_info포인터 등을,하지만 걱정에 당신을 위해 하나의 포인터 덜합니다.

실제로 C ++ 11을 사용하는 경우 Component스마트 포인터 안에 참조를 저장하는 것이 좋습니다 . 따라서지도는 다음과 같습니다.

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

다음과 같이 새 항목을 추가 할 수 있습니다.

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

여기서 componenttype은입니다 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.