Sistema de entidad / componente y "Entidades" de UI

14

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)

cenizas999
fuente
3
Creo que te parece lógico solo porque estás haciendo un juego en 2D. Imagina que harías un juego en 3D (con 2d gui) casi ninguna lógica de renderizado podría reutilizarse, y los componentes de 2d gui dentro del mundo 3d no tendrían mucho sentido. Debe compilar una GUI sobre el sistema de componentes. Como hacer que tu GameplayScreen cree un mundo de entidades con componentes, y uno de los componentes será una cámara con "lienzo" al que dibujará tu renderizador. Y ese lienzo se convertirá en el fondo de esa pantalla.
Kikaimaru
1
@Kikaimaru tienes un punto sobre 2D. Quizás estoy demasiado interesado en MVC, pero parece una mezcla de "modelo" (entidades de juego) y vista / controlador (componentes de la interfaz de usuario). Funciona, claro, pero ¿es así como debería funcionar? ¿Hay mejores formas? ¿Cómo lo hacen los demás?
cenizas999
@ ashes999 tu comentario y pregunta inicial es de lo más profundo de mi corazón :)
Narek
@Armen, nunca obtuve una respuesta satisfactoria a esto.
cenizas999
@ cenizas999 a mí. En todas partes la gente dice que no debes mezclar MVC con ECS, pero ¿por qué? ¿No sería bueno? Diferentes armas para diferentes tareas, ¿no estás de acuerdo?
Narek

Respuestas:

4

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.

cenizas999
fuente
¿Dónde pones la lógica de los elementos avanzados de la interfaz de usuario? Es decir. una barra de salud que necesita saber cuándo el jugador recibe un golpe y cuánto disminuir la barra. No puedo darme cuenta si necesita un sistema específico, o un script o algo más ...
Emir Lima
@EmirLima por algo así, pondría la mayor parte de la lógica de la interfaz de usuario en la barra de salud (cambiar el tamaño de la barra de salud), y hacer que el jugador genere un evento cuando sea golpeado, indicando cuál es el valor de salud nuevo / modificado. (La barra de salud puede capturar este evento y reaccionar adecuadamente.)
cenizas999
Pero, ¿cuál es el objeto de barra de salud en esa arquitectura? ¿Es una entidad con un componente de "barra de salud"? ¿Una clase que hereda de la entidad? ¿Un objeto normal con llamadas de actualización codificadas?
Emir Lima
1
@EmirLima Modelaría la barra de salud como una entidad y el jugador como una entidad. Puedes hacer lo que tenga sentido para ti.
cenizas999
1

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.

MichaelHouse
fuente
Parece que el sistema que tengo es bastante diferente del que describiste. Tengo clases de entidades como las TouchButtonque se componen de una hoja de sprites y un oyente de toque y clic. Para la unidad emergente, probablemente implementaría eso como una combinación de componente sprite + componente de escucha de mouse. Hmm
ashes999