물리 또는 그래픽 구성 요소는 일반적으로 구성 요소 지향 시스템에 어떻게 구축됩니까?


19

지난 48 시간 동안 Object Component 시스템을 읽었으며 구현을 시작할 준비가되었다고 생각합니다. 기본 Object 및 Component 클래스를 만들었지 만 실제 구성 요소를 작성해야하므로 혼란 스럽습니다. HealthComponent 또는 기본적으로 속성 일 것이라고 생각할 때 완벽하게 이해됩니다. 물리 / 그래픽 구성 요소보다 일반적인 것이면 약간 혼란스러워집니다.

내 Object 클래스는 지금까지와 같이 보입니다 (변경 사항을 발견하면 알려주세요. 여전히 새로운 내용입니다).

typedef unsigned int ID;

class GameObject
{
public:

    GameObject(ID id, Ogre::String name = "");
    ~GameObject();

    ID &getID();
    Ogre::String &getName();

    virtual void update() = 0;

    // Component Functions
    void addComponent(Component *component);
    void removeComponent(Ogre::String familyName);

    template<typename T>
    T* getComponent(Ogre::String familyName)
    {
        return dynamic_cast<T*>(m_components[familyName]);
    }

protected:

    // Properties
    ID m_ID;
    Ogre::String m_Name;
    float m_flVelocity;
    Ogre::Vector3 m_vecPosition;

    // Components
    std::map<std::string,Component*> m_components;
    std::map<std::string,Component*>::iterator m_componentItr;
};

이제 내가 겪고있는 문제는 일반 인구가 물리 / 그래픽과 같은 구성 요소에 넣는 것입니까? Ogre (내 렌더링 엔진)의 경우, 보이는 오브젝트는 장면에 부착하기 위해 여러 개의 Ogre :: SceneNode (아마도 여러 개)로 구성되며, 보이는 메시를 표시하기 위해 Ogre :: Entity (아마도 여러 개) 등으로 구성됩니다. Object에 여러 GraphicComponent를 추가하고 각 GraphicComponent가 하나의 SceneNode / Entity를 처리하도록하는 것이 가장 좋습니까? 아니면 각 Component 중 하나를 필요로하는 아이디어입니까?

물리학의 경우 더욱 혼란스러워합니다. RigidBody를 생성하고 질량 / interia / 등을 추적한다고 가정합니다. 말이 될 것입니다. 그러나 실제로 구성 요소에 세부 정보를 넣는 방법을 생각하는 데 문제가 있습니다.

이러한 "필수"구성 요소가 완성되면 훨씬 더 의미가 있다고 생각합니다. 현재로서는 여전히 조금 혼란스러워합니다.

답변:


32

우선, 당신은 빌드 컴포넌트 기반 시스템, 당신은하지 않는 경우 선회 접근 취할 모든 구성 요소로한다. 사실, 당신은 일반적으로해서는 안됩니다-그것은 신 생애의 실수입니다. 내 경험상 컴포넌트 기반 아키텍처에서 렌더링과 물리 시스템을 함께 연결하는 가장 좋은 방법은 해당 컴포넌트를 실제 렌더링 또는 물리 기본 오브젝트를위한 바보 같은 컨테이너로 만드는 것입니다.

이는 렌더링 및 물리 시스템을 컴포넌트 시스템과 분리 된 상태로 유지하는 이점이 있습니다.

예를 들어 물리 시스템의 경우 물리 시뮬레이터는 일반적으로 틱할 때마다 조작하는 강체 오브젝트의 큰 목록을 유지합니다. 당신의 컴포넌트 시스템은 그것을 엉망으로 만들지 않습니다 – 물리 컴포넌트는 단순히 컴포넌트가 속한 객체의 물리적 측면을 나타내는 강체에 대한 참조를 저장하고 컴포넌트 시스템의 모든 메시지를 강체의 적절한 조작으로 변환합니다.

렌더링과 마찬가지로 렌더러에는 렌더링 할 인스턴스 데이터를 나타내는 무언가가 있으며 시각적 구성 요소는 단순히 이에 대한 참조를 유지합니다.

사람들을 혼란스럽게하는 이유가 무엇이든간에 비교적 간단합니다. 그러나 종종 사람들이 그것을 너무 열심히 생각하기 때문입니다. 거기에는 많은 마법이 없습니다. 그리고 완벽한 디자인에 대해 고민하는 것보다 일을 끝내는 것이 가장 중요하기 때문에 momboco가 제안한 것처럼 최소한 일부 구성 요소가 인터페이스를 정의하고 게임 객체의 직접적인 구성원 인 접근 방식을 강력하게 고려해야합니다. 그것은 유효한 접근 방식과 동일하며 쉽게 이해하는 경향이 있습니다.

기타 의견

이것은 직접적인 질문과 관련이 없지만 다음은 코드를 볼 때주의해야 할 사항입니다.

왜 게임 객체에서 Ogre :: String과 std :: string을 혼합합니까? 이것은 그래픽이 아닌 객체이므로 Ogre에 의존해서는 안됩니까? 렌더링 구성 요소 자체를 제외하고는 Ogre에 대한 모든 직접 참조를 제거하는 것이 좋습니다.

update ()는 순수한 가상으로, GameObject를 서브 클래스로 만들어야한다는 것을 의미합니다. 실제로는 실제 컴포넌트 구성 요소와 반대되는 방향입니다. 구성 요소 사용의 주요 요점은 상속보다는 기능의 집계를 선호하는 것입니다.

일부 const참조 (특히 참조로 돌아 오는 위치)를 사용하면 도움이 될 수 있습니다 . 또한 속도가 스칼라가되기를 정말로 확신하지 못합니다 (또는 속도와 위치가 게임 객체에 지나치게 일반적인 구성 요소 방법론으로 표시되어야하는 경우).

큰 구성 요소 맵을 사용 update()하고 게임 오브젝트에서 호출을 사용하는 방법 은 매우 적합하지 않습니다 (그리고 이러한 종류의 시스템을 처음 구축하는 사람들에게는 일반적인 함정). 업데이트하는 동안 캐시 일관성이 매우 떨어지며 동시성 및 대량의 데이터 일괄 처리 또는 동작의 SIMD 스타일 프로세스 경향을 한 번에 사용할 수 없습니다. 게임 개체가 구성 요소를 업데이트하지 않는 대신 디자인 자체를 담당하는 하위 시스템이 한 번에 모두 업데이트하는 디자인을 사용하는 것이 좋습니다. 이것은 가치가 읽기 수 있습니다.


이 답변은 훌륭했습니다. 나는 여전히 의견에 단락을 배치하는 방법을 찾지 못했지만 (키는 제출 만하면됩니다)이 답변을 다루겠습니다. 객체 / 컴포넌트 시스템에 대한 설명은 의미가 있습니다. 따라서 PhysicsComponent의 경우 구성 요소의 생성자에서 명확히하기 위해 PhysicsManager의 CreateRigidBody () 함수를 호출 한 다음 구성 요소에 참조를 저장할 수 있습니까?
Aidan Knight

"기타 의견"부분까지는 이것에 감사합니다. 나는 일반적으로 모든 오우거 기능을 오우거를 사용하는 프로젝트의 기초로 사용하기를 원하기 때문에 문자열을 혼합했지만 맵 / 쌍 등이 없기 때문에 객체 / 구성 요소 시스템에서 전환하기 시작했습니다. 당신은 옳습니다. 나는 그들을 오우거에서 분리하기 위해 std 회원으로 전환했습니다.
Aidan Knight

1
+1 그것은 제가 여기서 읽은 구성 요소 기반 모델에 관한 첫 번째 정답입니다. 과다 생성과는 대조적입니다
Maik Semder

5
일관성이 향상되고 (데이터와 명령 캐시 모두에서) 업데이트를 별개의 스레드 또는 작업자 프로세스 (예 : SPU)로 거의 사소하게 오프로드 할 수 있습니다. 어떤 경우에는 구성 요소를 업데이트하지 않아도되므로 update () 메서드에 대한 no-op 호출의 오버 헤드를 피할 수 있습니다. 또한 데이터 지향 시스템을 구축하는 데 도움이됩니다. 이는 대량 처리에 관한 것이며 CPU 아키텍처의 최신 트렌드를 활용합니다.

2
"완벽한 디자인을 고민하는 것보다 일을 끝내는 것이 가장 중요합니다"
Trasplazio Garzuglio

5

구성 요소 아키텍처는 동일한 노드에서 모든 요소를 ​​상속받는 큰 계층 구조와 그로 인한 연결 문제를 피하기위한 대안입니다.

"일반"구성 요소가 포함 된 구성 요소 아키텍처를 보여줍니다. "일반적인"구성 요소를 연결 및 분리하는 기본 로직이 있습니다. 어떤 구성 요소인지 모르기 때문에 일반 구성 요소가 포함 된 아키텍처를 달성하기가 더 어렵습니다. 이점은이 접근 방식이 확장 가능하다는 것입니다.

정의 된 구성 요소를 사용하여 유효한 구성 요소 아키텍처를 얻을 수 있습니다. 정의 된 의미는 인터페이스가 구현이 아니라 정의 된 것입니다. 예를 들어, GameObject는 IPhysicInstance, Transformation, IMesh, IAnimationController를 가질 수 있습니다. 인터페이스를 알고 GameObject가 각 구성 요소를 처리하는 방법을 알고 있다는 이점이 있습니다.

과잉 일반화라는 용어에 대한 대응

나는 개념이 명확하지 않다고 생각합니다. 컴포넌트라고 할 때 게임 오브젝트의 모든 컴포넌트가 컴포넌트 인터페이스 나 그와 유사한 것을 상속 받아야한다는 의미는 아닙니다. 그러나 이것이 일반 구성 요소에 대한 접근 방식이므로 구성 요소라는 개념이라고 생각합니다.

컴포넌트 아키텍처는 런타임 오브젝트 모델에 존재하는 또 다른 아키텍처입니다. 모든 경우에 유일하고 최상의 것은 아니지만 경험에 따르면 낮은 커플 링과 같은 많은 이점이 있습니다.

컴포넌트 아키텍처를 구별하는 주요 기능은 관계를 is-a로 변환하는 것입니다. 예를 들어 객체 아키텍처는 다음과 같습니다.

건축

객체 아키텍처 대신 (components) :

하스 건축

속성 중심 아키텍처도 있습니다.

예를 들어 일반적인 객체 아키텍처는 다음과 같습니다.

  • Object1

    • 위치 = (0, 0, 0)
    • 방향 = (0, 43, 0)
  • Object2

    • 위치 = (10, 0, 0)
    • 방향 = (0, 0, 30)

속성 중심 아키텍처 :

  • 위치

    • Object1 = (0, 0, 0)
    • Object2 = (10, 0, 0)
  • 정위

    • Object1 = (0, 43, 0)
    • Object2 = (0, 0, 30)

객체 모델 아키텍처가 더 낫습니까? 성능 측면에서는 캐시 친화적이기 때문에 속성 중심이 더 좋습니다.

구성 요소는 has-a 대신 is-a 관계를 참조합니다. 컴포넌트는 변환 행렬, 쿼터니언 등일 수 있습니다. 그러나 게임 오브젝트와의 관계는 관계입니다. 게임 오브젝트는 상속 되었기 때문에 변환이 없습니다. 게임 오브젝트는 변형을가집니다. 그런 다음 변환은 구성 요소입니다.

게임 오브젝트는 허브와 같습니다. 항상 존재하는 구성 요소를 원한다면 매트릭스와 같은 구성 요소가 포인터가 아닌 객체 내부에 있어야합니다.

모든 경우에 완벽한 게임 오브젝트는 없으며 엔진, 엔진이 사용하는 라이브러리에 따라 다릅니다. 메쉬가없는 카메라를 원할 수도 있습니다. is-a 아키텍처의 문제점은 게임 오브젝트에 메시가있는 경우 게임 오브젝트에서 상속 된 카메라에 메시가 있어야한다는 것입니다. 컴 포넷을 사용하면 카메라에 변형, 이동 컨트롤러 및 필요한 모든 것이 있습니다.

자세한 내용은 "Jason Gregory"의 "Game Engine Architecture"책에서 "14.2. Runtime Object Model Architecture"장을 참조하십시오.

거기에서 UML 다이어그램이 추출됩니다.


나는 마지막 단락에 동의하지 않습니다. 지나치게 일반화하는 경향이 있습니다. 컴포넌트 기반 모델은 각각의 모든 기능이 컴포넌트라는 것을 의미하지는 않지만 여전히 기능과 데이터의 관계를 고려해야합니다. 메시가없는 AnimationController는 쓸모가 없으므로 메시에 속합니다. 변형이없는 Game-Object는 Game-Object가 아니며, 3D 세계에 대한 정의에 속하므로 Game-Object의 일반 멤버로 지정합니다. 캡슐화 기능 및 데이터의 일반적인 규칙이 여전히 적용됩니다.
Maik Semder 2016 년

@Maik Semder : 일반적인 용어로 지나치게 일반화하는 데 동의하지만 구성 요소라는 용어가 명확하지 않다고 생각합니다. 내 답변을 편집했습니다. 그것을 읽고 당신의 인상을 줘.
momboco 2016 년

@momboco 글쎄, 당신은 동일한 점을 더 적게 반복합니다.) Transform과 AnimationController는 여전히 구성 요소로 설명되어 있습니다. 핵심은 구성 요소에 넣을 것과 그렇지 않은 것을 정의하는 것입니다.
Maik Semder

GO (Game-Object)가 먼저 작동하도록하는 것이 필요합니다. 다시 말해 선택 사항이 아니라 필수 인 경우 구성 요소가 아닙니다. 구성 요소는 선택 사항입니다. Transform은 좋은 예입니다. GO에는 전혀 옵션이 아니며 Transform이없는 GO는 의미가 없습니다. 반면에 모든 GO가 물리를 필요로하는 것은 아니므로 구성 요소가 될 수 있습니다.
Maik Semder 2018 년

AnimationController (AC)와 Mesh 사이처럼 두 기능 사이에 강한 관계가 있다면 AC를 구성 요소로 눌러도이 관계를 끊지 않습니다. 반면 메쉬는 완벽한 구성 요소이지만 AC는 메쉬에.
Maik Semder 2018 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.