나는 남용하고 심지어 상속 재산을 남용하는 죄를 지었다는 것을 인정한다. OOP 과정을 수강 할 때 처음으로 만든 (텍스트) 게임 프로젝트는 "문"과 "문이있는 방", "2 개의 문이있는 방"에서 "잠금 문"및 "잠금 해제 문"까지 진행되었으며 "방"에서 등등.
최근에 작업 한 (그래픽) 게임을 통해 수업을 배우고 상속 사용을 제한한다고 생각했습니다. 그러나 문제가 곧 나타나기 시작했습니다. 루트 클래스가 점점 부풀어 오르기 시작했고 리프 클래스에는 중복 코드가 가득했습니다.
나는 여전히 잘못하고 있다고 생각했으며 온라인에서 찾은 후에 내가이 문제를 가진 유일한 사람이 아니라는 것을 알았습니다. 철저한 조사를 거친 후 엔터티 시스템을 발견 한 방법입니다 (읽기 : googlefu)
읽었을 때 구성 요소가있는 전통적인 OOP 계층 구조에서 발생하는 문제를 얼마나 명확하게 해결할 수 있는지 알 수있었습니다. 그러나 이것은 첫 번째 독서에있었습니다. 내가 더 우연히 만났을 때 ... T-machine 과 같은 "급진적 인"ES 접근 .
나는 그들이 사용하고있는 방법에 동의하지 않기 시작했다. 순수한 구성 요소 시스템은 과도하거나 직관적이지 않은 것으로 보였으며 이는 아마도 OOP의 강점입니다. 저자는 ES 시스템이 OOP의 반대라고 말하면서 OOP와 함께 사용할 수는 있지만 실제로는 안됩니다. 나는 그것이 틀렸다고 말하지는 않지만 구현하려는 솔루션처럼 느끼지 않았습니다.
그래서 나에게 직관을 어 기지 않고 게시물 시작 부분에서 겪었던 문제를 해결하는 것은 여전히 계층 구조를 사용하는 것이지만 이전에 사용했던 것과 같은 모 놀리 식 계층 구조는 아니지만 오히려 여러 개의 작은 나무로 구성된 다항식 (모 놀리 식과 반대되는 단어를 찾을 수 없음).
다음 예제는 내가 의미하는 바를 보여줍니다 (이는 14 장 Game Engine Architecture에서 찾은 예에서 영감을 얻었습니다).
나는 차량을위한 작은 나무를 가질 것입니다. 루트 비히클 클래스에는 렌더링 구성 요소, 충돌 구성 요소, 위치 구성 요소 등이 있습니다.
그런 다음 전차의 서브 클래스 인 전차는 전차에서 해당 구성 요소를 상속 받아 자체 "대포"구성 요소를받습니다.
캐릭터도 마찬가지입니다. 캐릭터는 자체 컴포넌트를 가지게되고, 플레이어 클래스는이를 상속 받아 입력 컨트롤러를 받게되고 다른 적 클래스는 캐릭터 클래스에서 상속 받아 AI 컨트롤러를받습니다.
이 디자인에는 아무런 문제가 없습니다. 순수한 엔터티 컨트롤러 시스템을 사용하지 않더라도 버블 링 효과와 큰 루트 클래스의 문제는 다중 트리 계층 구조를 사용하여 해결되며, 리프가 없어서 무거운 코드 복제 리프의 문제가 사라집니다. 구성 요소만으로 시작하는 코드가 있습니다. 리프 수준으로 변경해야하는 경우 코드를 모든 곳에 붙여 넣는 대신 단일 구성 요소를 변경하는 것만 큼 간단합니다.
물론, 나는 경험이 없어서 단일 계층 구조, 상속 무거운 모델을 처음 사용했을 때 아무런 문제도 보지 못했습니다. 따라서 현재 구현하려는 모델에 문제가 있으면 구현하지 않습니다. 그것을 볼 수 있습니다.
당신의 의견?
추신 : Java를 사용하고 있으므로 일반적인 구성 요소를 사용하는 대신 다중 상속을 사용하여이를 구현할 수 없습니다.
PPS : 구성 요소 간 통신은 종속 구성 요소를 서로 연결하여 수행됩니다. 이것은 커플 링으로 이어질 것이지만, 나는 그것이 괜찮은 거래라고 생각합니다.