Sistema de entidad / componente y "Entidades" de UI

Todavía soy verde para los sistemas de entidades / componentes. Encuentro que, dado que tengo componentes útiles para dibujar sprites (u hojas de sprites) y manejar la entrada (mouse / clics táctiles), naturalmente quiero reutilizarlos para crear componentes UI (como botones, por ejemplo, pantalla de selección de nivel).

Esto me parece muy extraño. Siempre entendí las entidades como cosas de "modelo de juego" como jugadores, enemigos, potenciadores, etc. Por otro lado, desde una perspectiva de reutilización de código, reutilizar componentes para la interfaz de usuario tiene mucho sentido.

¿Cómo (y dónde) encajan las preocupaciones de UI / GUI en un sistema de entidad / componente?

(Nota: esta pregunta es independiente de la plataforma, ya que se aplica a múltiples plataformas / idiomas)

Después de usar varios sistemas de componentes de entidad, especialmente CraftyJS, obtuve la respuesta a mi pregunta más o menos: sí, puede reutilizar componentes (especialmente sprites o imágenes y controladores de clic del mouse en juegos 2D) para la GUI.

La mayor parte del tiempo, solo tiene acceso a la ECS, y no a los sistemas subyacentes (por ejemplo, el sistema de dibujo). En este caso, está bien usar componentes, ya que no tiene otra opción.

Si tiene acceso al sistema subyacente (por ejemplo, Ruby roguelike con acceso directo a Maldiciones), puede encontrar que dibujar / renderizar directamente en ese sistema es más efectivo (menos código, menos frágil, más natural) que usar un montón de entidades y componentes.

En 2D o 3D, un sistema de componentes de entidad (ECS) debe tener al menos acceso al sistema GUI, si no es parte del mismo ECS.

Personalmente, no mezclaría los dos. La reutilización del código para una GUI solo ocurre realmente en el nivel superior. Respondiendo al mouse / teclado, renderizado, etc. Las funciones que toman los diferentes botones, o la información que muestran ciertas listas no es realmente algo que pueda ser lo suficientemente genérico como para reutilizar.

Por ejemplo, me imagino que los componentes para entidades GUI serían algo así como position, rendery gui. Donde el componente GUI definiría el tipo de acción que toma la entidad GUI. Sin embargo, esa acción será bastante única y específica del contexto. Esto da como resultado que el sistema que maneja los componentes de la GUI es muy grande y está esencialmente diseñado para manejar cada una de las funciones de la GUI (cargar juego, guardar juego, buscar servidor, etc.). Suena desordenado

Prefiero hacer un archivo de clase estándar para cada "pantalla" GUI. Tenga toda la funcionalidad para esa pantalla en un solo lugar (con referencias a una clase de funcionalidad común). Es mucho más ordenado y más fácil de administrar.

Sin embargo, como dije, el ECS debería tener acceso al sistema GUI. Necesita poder suministrar información a la GUI basada en entidades en sus sistemas. Por ejemplo, al pasar el mouse sobre una unidad aliada, aparecerá una ventana GUI con toda la información sobre esa unidad. Cuando se cierne sobre una unidad enemiga, aparecerá una ventana GUI con información limitada. Es probable que no desee programar la GUI para conocer la diferencia entre los dos, desea solicitar a la entidad que muestre su información.

Por lo tanto, es probable que las entidades tengan algún tipo de componente GUI, pero serán entidades "en el juego", no entidades GUI. Este componente utilizará el sistema GUI externo para crear su interfaz GUI.