엔터티 구성 요소 시스템 엔진에서 종속 엔터티 그룹을 어떻게 처리합니까?

몇 가지 게임 디자인 패턴을 살펴본 후, 나는 게임 엔진을 위해 Entity-Component-System (ES 시스템)으로 정착했습니다. 기사 (주로 T = Machine )를 읽고 일부 소스 코드를 검토 한 후 시작하기에 충분하다고 생각합니다.

내가 고투하고있는 기본 아이디어는 하나뿐입니다. 서로 의존하는 엔터티 그룹을 어떻게 처리합니까?

예를 들어 보겠습니다.

표준 오버 헤드 슈터 ( Jamestown 이라고 생각 )를 만들고 있고 여러 개의 별개이지만 연결된 부품으로 "보스 엔티티"를 만들고 싶다고 가정합니다. 분류는 다음과 같습니다.

• 선체 : 운동, 렌더링
• 대포 : 위치 (선체에 대해 고정됨), 영웅에서 추적 \ 화재, 비활성화 될 때까지 데미지
• 코어 : 위치 (선체를 기준으로 잠김), 영웅 추적 / 화재, 비활성화 될 때까지 피해 받기, 선박 그룹의 다른 모든 엔티티 비활성화 ((파괴))

내 목표는 새로운 집계 요소를 만들 때마다 하위 시스템을 다시 작성하지 않고도 별도의 게임 요소로 식별되고 조작되는 것입니다.

ES System에서 이러한 종류의 디자인을 어떻게 구현합니까?

1. 어떤 종류의 부모-자식 엔터티 관계 (엔터티에 자식이있을 수 있음)를 구현합니까? 이것은 엔티티가 단지 빈 컨테이너이고 더 OOP를 느끼게 만드는 방법론과 모순되는 것 같습니다.
2. 일종의 연결 컴포넌트 (BossComponent) 및 관련 시스템 (BossSubSystem)을 사용하여 별도의 엔티티로 구현합니까? 나는 도울 수는 없지만 구성 요소가 통신하는 방식이 큰 곰 함정 인 것처럼 보이기 때문에 이것이 구현하기가 어렵다고 생각합니다.
3. 구성 요소 컬렉션 (ShipComponent, CannonComponents, CoreComponent)을 사용하여 하나의 엔터티로 구현합니까? 이것은 ES 시스템 의도를 능가하는 것으로 보입니다 (여기의 구성 요소는 너무 무거운 엔티티와 너무 비슷해 보입니다). 나는 이것을 알고 있으므로 거기에 넣을 것이라고 생각했습니다.
4. 내가 언급 한 다른 것으로 구현합니까?

나는 이것이 OOP에서 매우 쉽게 구현 될 수 있다는 것을 알고 있지만 OOP 대신 ES를 선택하는 것이 내가 고수 할 것입니다. 이 디자인을 구현하기 위해 순수한 ES 이론을 깨야한다면 (이전에 순수한 디자인을 타협하지 않았을 것 같지는 않지만), 나쁜 디자인으로 시작하기보다는 성능상의 이유로 그렇게하는 것을 선호합니다.

추가적인 신용을 얻으려면 동일한 디자인을 생각하지만 각 "보스 엔티티"는 실제로 본체, 메인 코어 및 3 개의 "보스 엔티티"로 구성된 더 큰 "빅 보스 엔티티"에 연결되었습니다. 이것은 적어도 3 차원 (조부모-자녀)에 대한 해결책을 볼 수있게 해 줄 것입니다 ...

이 상황에 있다면 보스의 각 부분을 별도의 엔티티로 만들 것입니다. 이러한 "하위 개체는"어떤 종류의 포함 할 것이다 AttachmentPoint또는 ParentEntity구성 요소를. 이 구성 요소에는 상위 엔티티에 대한 참조와 상위 위치로부터의 오프셋이 포함됩니다. 위치를 업데이트 할 때 부모 위치를 확인하고 오프셋을 적용하여 자체 위치를 생성합니다. 또한 부모 엔터티가 여전히 존재하는지 확인합니다. 또한 SubEntity상위 엔터티에 대한 하위 엔터티의 존재를 추적 하는 구성 요소를 가질 수 있습니다 . 이를 통해 방패가있는 팔이 파괴 될 때 보스의 핵심을 취약하게 만드는 것과 같은 일을 할 수 있습니다.

저는 현재 TargetEntity게임에서 터렛 추적 및 고블린이 자원을 가져올 때 사용되는 구성 요소를 사용합니다. 대상 엔터티의 위치를 ​​확인하고 그에 따라 동작을 변경할 수 있습니다. 위치가없는 엔터티는 대상으로 추가되지 않으므로 걱정할 필요가 없습니다. 그러나 부모 또는 자식 엔터티의 상태, 실드, 파워 리저브 등을 확인하는 등 더 깊이있게되면 부모 또는 자식 엔터티에 실제로 관련 구성 요소가 있는지 확인해야합니다.

각 파트를 자체 엔티티로 만들면 보스의 각 파트에 다른 컴포넌트를 추가 할 수 있으므로 엔티티 / 컴포넌트 프레임 워크의 유연성이 유지됩니다. 예를 들어 보스의 한 부분에는 총 구성 요소와 건강 구성 요소가있을 수 있고 다른 한 부분에는 방패 구성 요소와 건강 구성 요소가있을 수 있습니다.

여기서이 주제에 대한 다른 토론을 찾았 습니다 . 사용자가 동일한 유형의 여러 구성 요소를 하나의 엔티티에 추가하는 것에 대해 논의하고 있습니다 (나에게 나쁜 생각 인 것 같습니다). 비록 전체 토론을 읽지는 않았지만 유용한 대화처럼 보입니다.

기존 시스템에 대한 세부 정보를 너무 많이 알지 못하면 모델링하는 방법 (및 자체 엔터티 시스템에서 어느 정도까지)은 AttachedTo (parentEntity)와 같은 구성 요소를 갖는 것입니다. 그런 다음 모든 하위 항목에 AttachedTo (boss) 구성 요소를 부여 할 수 있습니다.

그런 다음 렌더링 시스템 (또는 기타)은 Position, AttachedTo 등의 구성 요소를 사용하여 엔터티를 가져와 적절한 계층을 형성합니다.

ID로만 표시된 엔터티를 원하면 특수 구성 요소를 통해 엔터티를 포함시킬 수 있습니다. CompositeComponent라고 부를 수 있으며 여기에는 하위 항목 ID 목록과 해당 목록에서 하위 항목을 추가 / 제거하는 인터페이스가 포함됩니다.

분명히 위치 등에 의존하는 모든 구성 요소는 엔티티를 올바르게 배치하기 위해이 구성 요소와 함께 작동해야합니다. 이를 구현하는 방법은 현재 위치 지정을 구현하는 방법에 따라 다릅니다.

그건 그렇고, "순수한 ES 이론"은 없습니다. 구성 요소로 엔티티를 만드는 것은 보편적 인 접근 방법이지만 정확한 방법은 아직 표준화되지 않았습니다.