컴포넌트 기반 아키텍처에 적합한 레벨의 세분성은 무엇입니까?

26

컴포넌트 기반 아키텍처로 게임을하고 있습니다. 은 Entity세트 소유 Component의 세트가 각각의 경우, Slot저장, 전송, 및 값을 수신 할 수있는 인스턴스. Player필수 구성 요소 및 슬롯 연결이있는 엔티티를 생성하는 등의 공장 기능 .

구성 요소에 대한 최상의 세부 수준을 결정하려고합니다. 예를 들어, 지금 Position, Velocity그리고 Acceleration직렬로 연결된 모든 별도의 구성 요소입니다. Velocity그리고 Acceleration쉽게 균일 재기록 될 수있는 Delta구성 요소, 또는 Position, Velocity와 Acceleration같은 구성 요소와 함께 결합 될 수 Friction와 Gravity일체형으로 Physics구성.

구성 요소가 가능한 최소한의 책임을 가져야합니까 (많은 상호 연결 비용) 또는 관련 구성 요소를 모 놀리 식 구성 요소 (유연성 비용)로 결합해야합니까? 나는 전자에 대해 기울고 있지만 두 번째 의견을 사용할 수 있습니다.

architecture entity-system component-based

— 존 퍼디
소스

비슷한 질문 : gamedev.stackexchange.com/questions/4914/…

— Den

자신의 물리 엔진을 사용하거나 기존 엔진을 통합 하시겠습니까?

— Den

@ 덴 : 물리 코드를 작성하고 있지만 결코 엔진 이 아닙니다 . 평범한 2D 운동학.

— 존 퍼디

14

완전한 세분성으로 인해 코드 낭비 또는 얼룩 모양의 상태 (구성 요소 아키텍처가 선호되는 이유)와 사용 편의성 사이에 선이 있습니다.

분명히 가지가있을 수 Position있지만, 반드시 동적 아니에요 (왜이 Velocity와 Acceleration?). 그러나 a Velocity가있는 것은 움직이는 물체가 될 것이므로 Acceleration그룹화 하는 것도 합리적 입니다.

당신은 경우가 건가요 절 및 A는 필요할거야,하지만 당신은 그들을 위해 물리 시뮬레이션을 싶지 않아? 마찬가지로, Gravity물리적 물체가 아니라면 어떤 점이 있습니까?

tl; dr 의미가있는 그룹.

— 공산주의 오리
소스

1

공정하게 들립니다. 내 시스템은 약간의 중앙 집중화가 있습니다이 경우 Entity가 Position그하고 일부 구성 요소 Position물리학에 참여를, 다음은 Entity이다 사실상 물리적. 내가 할 수있는 일은 논리 그룹화를 위해 일부 구성 요소를 추가하고 모든 기본 구성 요소를 단일 책임으로 유지하는 것입니다. 추가 말하자면, 소위 Movable로는 Entity추가, 것과 같은 효과 것 Position, Velocity등을 Acceleration.

— 존 퍼디

6

무거운 시작으로 제안하는 각각의 모든 변수를 미세 관리하지 않으려면 책임 주위의 부서를 선택하고 상황이 논리적으로 나타날 때 리팩터링하십시오. 종이에서 첫 번째 디자인을 시작할 수 있습니다. 어떤 시점에서 이러한 총 책임 분담은 기업의 빌딩 블록이 될 것입니다.

서두른 예를 들어 게임이 있습니다. 게임은 환경 + 상태로 나뉩니다. 환경이 StaticWorld + MovingStuff로 분할됩니다. 상태는 AIControlled + PlayerControlled로 분할됩니다. 데미지에 대한 총체적인 아이디어는 TakesDamage + GivesDamage로 나뉩니다.

등등.

"엔진이 아닌 게임을 만들어라!"에 대한 일반적인 조언과 비슷합니다. 새로운 실무자를 위해 "정교한 구성 요소 시스템이 아닌 게임 제작"을 권장합니다. 실행중인 게임에 대한 개인적인 경험만으로도 정교한 구성 요소 시스템이 향후 작업에서 요구되는지 알 수 있기 때문입니다.

— 패트릭 휴즈
소스

나는 새로운 개발자가 아닙니다. 동작이 아닌 개념을 기반으로하는 구성 요소 (예 : 하향식과 상향식)가있는 경우 내 아키텍처가 더 취성 적이고 정교하지 않습니까? 작은 구성 요소에서 원하는 동작을 구현할 수 있지만 항상 사전 조합 된 동작에서 원하는 동작을 얻을 수있는 것은 아닙니다. 한 게임의 맥락에서도 달성하고자하는 모든 것을 예측할 수는 없습니다.

— 존 퍼디

상향식의 단점은 구성 요소 간의 통신이 문제가되고 사람들이 모델링하는 규모에 비해 너무 미미한 경향이 있다는 것입니다. 나는 주로 미숙 한 사람을 위해 슈퍼 마이크로 "xyz는 구성 요소" "회전은 구성 요소" "rgb는 구성 요소"수준에서 벗어나려고했다.

— Patrick Hughes

충분합니다. 나는 단지 당신을 올바르게 이해하고 싶었습니다. 내가 보유한 슬롯 시스템을 사용하면 구성 요소가 간단하고 효율적으로 통신 할 수 있으므로 "초소형"스케일에 대한 결점을 볼 수 없습니다. 나는 이것을 독립형 엔진으로 리팩토링하려고하지 않지만, 그렇게하면 공산주의 오리의 답변에 대한 언급에서 언급 한 컴포넌트 그룹과 같은 추상화를 항상 소개 할 수있다.

— 존 퍼디

4

제 생각에는 상호 작용이 많은 구성 요소를 결합하는 것입니다. 귀하의 경우, 나는 단일 구성 요소에 위치를 유지하고 속도 및 가속도를 물리 구성 요소에 함께 유지합니다.

그러나 특정 게임을 염두에두고 프레임 워크를 작성하지 않는 한 게임 기능에 따라 다릅니다.

— XGouchet
소스

2

구성 요소를 많은 상호 작용과 결합하는 문제는 때로는 다른 부분이 필요하지 않다는 것입니다.

— 공산주의 오리

4

나는 이것이 오래된 질문이라는 것을 알고 있지만 누군가이 대답이 유용하다고 생각할 것입니다.

나는 이것이 Systems구성 요소를 구성하는 방법을 이해하는 데 더 도움 이 될 것이라고 믿습니다 . 시스템은 간단한 getter / setter 및 도우미 함수 외에도 구성 요소에 자체 논리가 포함되어 있지 않은 아키텍처에 존재합니다. 시스템은 구성 요소 요구 사항을 충족하는 엔티티에서 작동합니다. 그렇기 때문에 다른 데이터없이 해당 데이터를 처리 할 수있을 정도로 구성 요소 데이터를 분리하는 것이 가장 좋습니다.

예를 들어, 당신은있을 수 있습니다 MovementSystem그 엔티티 '업데이트하는 Position자신에 기반을 Velocity. 이것은 게임에서 간단한 엔티티를위한 것일 수 있습니다. 그러나 플레이어 와 적의 경우Acceleration 에서 처리되는 움직임을 원할 수 있습니다 AcceleratedMovementSystem. 그러나 장애물의 경우 원할 수 있습니다 Friction. 지형 마찰이있을 수 있지만, 그것은 속도 성분이 없습니다. 그러나 어떻 Gravity습니까? Player, Enemy 및 Obstacle을 추가하고 GravitySystem처리하기 위해 를 만드 십시오.

결론은 더 있다는 것입니다 분리 당신이 Components더있는 확장 (가) Entities사용하면됩니다 Systems.

편집 : 마지막 진술을 명확하게했습니다.

편집 : 좋아, 나는 내 자신의 시스템에서 일하고 있었고이 실현에왔다. 위치와 속도를 분할하는 예는 속도를 조작하면 이동 시스템에 따라 위치가 변경되는 것입니다. 결과적으로, 'InputMovementSystem'에는 MovementSystem이 Velocity의 변경 사항을 적용하여 Position에 적용하기 때문에 Player가 사용자 입력에서 이동하게하는 Position이 필요하지 않습니다. 물론, 그것들을 합치면 여전히 잘 작동하지만 이것이 필요하지 않은 이유의 예입니다.

최근에 다음과 같은 블로그 게시물을 읽었습니다.

"2 개의 다른 구성 요소로 그룹화 할 수있는 데이터가있는 경우 해당 데이터로 세 번째 구성 요소를 작성하는 것이 가장 좋습니다."

— Dan H.
소스