엔티티 / 컴포넌트 시스템 및 UI“엔티티”

엔터티 / 구성 요소 시스템에 여전히 녹색입니다. 스프라이트를 그리거나 입력을 처리하는 데 유용한 구성 요소가 있기 때문에 (마우스 / 터치 클릭) UI 구성 요소 (예 : 레벨 선택 화면)와 같은 UI 구성 요소를 만드는 데 자연스럽게 재사용하고 싶습니다.

이것은 나를 매우 이상하게 생각합니다. 나는 항상 엔터티를 플레이어, 적, 파워 업 등과 같은 "게임 모델"로 이해했다. 반면에, 코드 재사용 관점에서 UI를 위해 구성 요소를 재사용하는 것은 완벽하다.

UI / GUI 관련 사항이 엔티티 / 컴포넌트 시스템에 어떻게 (그리고 어디에) 관련되어 있습니까?

(참고 :이 질문은 여러 플랫폼 / 언어에 적용되므로 플랫폼에 구애받지 않습니다)

몇 가지 엔터티 구성 요소 시스템, 특히 CraftyJS를 사용한 후, 나는 내 질문에 대한 답을 얻었습니다. 그렇습니다. GUI의 구성 요소 (특히 2D 게임의 스프라이트 또는 이미지 및 마우스 클릭 처리기)를 재사용 할 수 있습니다.

대부분의 경우 기본 시스템 (예 : 도면 시스템)이 아닌 ECS에만 액세스 할 수 있습니다. 이 경우 다른 선택 사항이 없으므로 구성 요소를 사용하는 것이 좋습니다.

기본 시스템 (예 : Curses에 직접 액세스 할 수있는 Ruby roguelike)에 액세스 할 수있는 경우 해당 시스템에서 직접 그리기 / 렌더링을 사용하는 것이 엔터티 및 구성 요소

2D 또는 3D에서 ECS (Entity Component System)가 동일한 ECS에 속하지 않는 경우 GUI 시스템에 액세스 할 수 있어야합니다.

개인적으로, 나는 두 가지를 섞지 않을 것입니다. GUI의 코드 재사용 성은 실제로 최상위 수준에서만 발생합니다. 마우스 / 키보드에 응답, 렌더링 등 다른 버튼이 취하는 기능 또는 특정 목록이 표시하는 정보는 실제로 재사용하기에 충분히 일반적인 것이 아닙니다.

예를 들어, 내가 좋아하는 뭔가 될 것 GUI 개체에 대한 구성 요소를 상상하는 것 position, render하고 gui. GUI 구성 요소가 GUI 엔티티가 수행하는 조치 유형을 정의하는 위치. 그러나 그 행동은 매우 독특하고 상황에 따라 다릅니다. 그 결과 GUI 구성 요소를 처리하는 시스템이 매우 커서 본질적으로 각 GUI 기능 (게임로드, 게임 저장, 서버 찾기 등)을 처리하도록 설계되었습니다. 지저분한 소리.

각 GUI "화면"에 대해 표준 클래스 파일을 선호합니다. 해당 화면에 대한 모든 기능을 한곳에 두십시오 (공통 기능 클래스 참조). 훨씬 깔끔하고 관리하기 쉽습니다.

그러나 내가 말했듯이 ECS는 GUI 시스템에 액세스 할 수 있어야합니다. 시스템의 엔티티를 기반으로 GUI에 정보를 제공 할 수 있어야합니다. 예를 들어, 연합 유닛 위로 마우스를 가져 가면 해당 유닛에 대한 모든 정보가있는 GUI 창이 나타납니다. 적의 화합 위에 마우스를 올리면 제한된 정보가있는 GUI 창이 나타납니다. GUI의 차이점을 알기 위해 GUI를 프로그래밍하지 않으려는 경우, 엔티티에 정보를 표시하도록 요청하려고합니다.

따라서 엔터티에는 여전히 일종의 GUI 구성 요소가있을 수 있지만 GUI 엔터티가 아닌 "게임"엔터티가됩니다. 이 구성 요소는 외부 GUI 시스템을 사용하여 GUI 인터페이스를 만듭니다.