현재 프로젝트를 위해 기본적으로 구성 요소 / 엔티티 기반 시스템을 구현했습니다 . 기본적으로 대부분의 모범 사례에 따라이 정의되지 않은 영역에 있습니다 .
그래서 기본적으로 ID, 사람이 읽을 수있는 이름, 구성 요소 및 구성 요소가 무엇인지 나타내는 데 사용되는 "유형 표시기"인 (약간 확장 된) 엔티티를 얻었습니다 ( 모든 구성 요소에 대해 2의 거듭 제곱이 있습니다) 유형과 구성 요소가 엔티티에 추가 될 때마다 비트 단위 연산을 통해 해당 길이를 자동으로 변경 하고이 답변을 비교 하십시오 ).intstd::maplongenum
그런 다음 거기에 구성 요소 도 비교적 간단 : intID, enum구성 요소 유형, 부모 엔티티 포인터와 같은 std::map이 구성 요소가 보유하고있는 모든 속성.
마지막으로 실제 논리 처리를 처리하는 일부 시스템 / 관리자 . 먼저 현재 처리 된 엔터티에 일치하는 long"유형 표시기" 가 있는지 확인합니다. = 해당 시스템에 필요한 모든 구성 요소가 있는지 확인합니다. 그런 다음 필요한 경우 일부 속성에 액세스하고 해당 구성 요소의 일부 함수를 직접 호출하거나 메시지 발송자를 통해 일부 메시지를 보냅니다.
결론 : 지금까지 데이터 중심 방식과 결합 된 다소 표준적인 이벤트 중심 컴포넌트 / 엔티티 기반 시스템 (컴포넌트에는 하드 코딩 된 데이터 변수가 없지만 대신 (일부) 컴포넌트로 일반 맵이 있음) 구성 요소의 / archetypes는 나중에 실제 구성 요소 코드의 일부가 아닌 추가 데이터를 추가 할 수있는 옵션으로 파일에서 읽습니다.
이제 그 프로젝트 에 Behavior Trees ( AiGameDev BTSK 기반)를 소개 하고 싶지만 , 기존 컴포넌트와 어떻게 연결해야하는지, 그리고 이러한 디자인을 일반적으로 통합하는 방법은 확실하지 않습니다.
몇 가지 관련 아이디어 / 포인트 / 질문이 떠 오릅니다.
내 BT를 파일에서 다시 읽습니다. 나는 현재
BT Action그 트리의 인과 내 응용 프로그램의 실제 코딩 사이의 연결을 가장 잘 만드는 방법을 보는 데 어려움을 겪고 있습니다. BT 파일에 사용 된 동작 이름과 실제 논리 구현에 대한 함수 포인터 사이에 일종의 맵을 작성해야합니까? 이를 해결하기위한 일반적인 접근 방법은 무엇입니까?필자는 모든 다른
Entity유형에 대해 BT를 만들어야한다고 가정합니다 (따라서 여러 번 언급 한 긴 "유형 표시기"로 표시되는 각 게임 논리 / AI 관련 구성 요소 조합에 대해). 결과적으로BT Action액션 당 많은 구성 요소가 관련 될 가능성이 높 으므로 구성 요소에 구현 을 적용하는 것이 합리적 이지 않습니까?그렇다면
BT Action논리는 여러 개별 시스템에 있어야 합니까 (아이디어 # 1의지도가 가리키는 방법)? 시스템은 BT가 현재 점검되고 특정 조치를 실행하도록 지시받은 (= 시스템의 방법) 실제로 수행 할 수 있는지 (= 필요한 구성 요소가long있는지) 내 "유형 표시기"에 따라Entity점검합니다. 그러나 BT 제작자가 특정 상황을 간과했기 때문에 필요한 구성 요소가 더 이상 런타임에 엔티티에 연결되지 않을 수 있기 때문에 아무 일도 일어나지 않습니다.
질문 :
- 이러한 종류의 통합에 대한 입증 된 개념이 있습니까?
- 위의 3 점을 어떻게 받습니까?
- 구성 요소 / 엔티티 기반 디자인과 관련하여 염두에 두어야 할 다른 사항이 있습니까?