확인이 게시물에 당신이 연결 다이어그램과 관련된 많은 질문이있을 것 같다. 이 질문들에 대한 답은 '그것이 달려있다'이다. 귀하의 모든 질문에 대한 한 줄의 답이 아닌 CBSE 주제에 대한 지침을 원하신다 고 생각합니다. 유사한 쿼리를 기반으로 토론을 시도하고 회피하기보다는 여기에 몇 가지 링크를 게시하여 이러한 문제에 대해 더 많이 생각하게해야합니다.
처음에는 ES wiki가 있습니다. 이 위키는 아직 초기 단계이지만 엔티티 시스템에 대한 훌륭한 토론이 있습니다.
다음으로 gamedev stack exchange에 대한 매우 생산적인 토론이 있습니다 (아마도이 질문도 함께 옮겨야 할 것입니다). 먼저 this question을 살펴보십시오. ES 디자인의 명확한 추세가 (그 대답이 쓰여졌을 때) 왜 여전히 보이지 않는지를 설명하기 때문에 좋은 출발점입니다. 그렇다면 Byte56에 의해 주어진 absolutely amazing answer이 있습니다. 시스템 구성 요소 접근법의 기본 사항을 매우 잘 설명하며, 이미 사용자가 처리했다고 생각하는 경우에도 읽을만한 가치가 있습니다. 다음으로 도움이되는 일련의 질문이 Yannbane입니다. 이 질문들은보다 세밀한 점들을 좀더 자세하게 다룹니다. 여기에 allthreequestions입니다. 또한 input 및 GameStates을 통합하는 방법에 대한 몇 가지 질문이 있습니다.
마지막으로 Artemis과 같이 많은 주목을받은 오픈 소스 엔티티 시스템을 자바로 작성해야합니다 (해당 링크에 대해서는 현재 서버 문제가있는 것으로 보이지만 this article은 좋은 소개입니다. c# 및 c++ 리포지토리가 있으므로 일부 코드를 파헤칠 수 있습니다. AS3으로 작성된 ash도 있습니다.
지금 내가 직접 질문 중 하나를 대답해야 기분 :
그리고 메이크업 인 CollisionComponent 또는 Physik 구성 요소의 경우
의 Physik과 MoveComponent 의사 소통을해야하며, 그렇지?
링크 된 다이어그램에서 시스템 기반 접근 방식을 사용하는 것으로 보입니다 (예 : artemis와 유사). 저의 독서에서 저는 이것이 공동체가 일반적으로 합의한 한 영역이라고 생각합니다. 시스템 접근법에서 아이디어는 구성 논리를 중앙 집중화하여 (Yannabe's second question에 대한 답변에서 언급 한 몇 가지 간단한 방법을 제외하고) 컴포넌트는 데이터 컨테이너 이상입니다. 따라서 구성 요소가 엔티티에 저장되면 시스템은 모든 엔티티를 탐색해야합니다. 둘 이상의 구성 요소가 필요한 시스템은 각 엔터티에 작업을 수행하는 데 필요한 모든 구성 요소를 요청해야합니다.에이 없으면 시스템을 계속 이동해야합니다. 그래서 지금까지 답을 '아니오'로 결정한 것을 토대로 구성 요소는 서로 통신하지 않아야합니다.
어쨌든, 행운을 빈다.
