Acabo de publicar en Edevi
el primer artículo de una serie que tratará sobre el desarrollo de un sistema de GUI bastante completito que estoy programando para mi próximo juego.
Este primer artículo sirve de introducción pues presenta los requisitos del sistema y todas las features que pretendo implementar, esperemos que quede tan cojonudo como lo es en mi cabeza.
Por supuesto, todo tipo de ideas, sugerencias y críticas son bienvenidas :)
Offtopic: ¿Que te ha llevado a dejar el PopCap Framework ? ¿ Y has dejado del tanki ?
Sobre el GUI, por experiencia, tres consejos sobre los detalles de implementación:
1. A la larga me ha resultado más práctico almacenar las coordenadas absolutas que relativas respecto al widget padre. Cuando se mueva el padre, que propague la orden a los hijos y que estos se actualicen. Probé con relativas y acabé volviendo a absolutas.
2. Delegar todo el dibujado a una clase skin que reciba el area a pintar, el tipo de elemento y su estado (boton pulsado, opcion marcada, etc...). Que proporcione métodos para consultar dimensiones según estado y tipo de elemento y que los widgets no asuman nada, pregunten siempre al skin. En un GUI de aplicación sería un engorro, sobre todo al tener que conocer el skin todos los tipos de widgets a dibujar, pero en el de un juego, con widgets limitados, ayuda mucho.
3. El area que define el widget (x,y,ancho, alto), que incluya el borde externo. Que tu clase skin incluya un metodo para calcular el area "cliente" interna.
¿ Has pensado en como redimensionar automáticamente los widgets ? Si cambias en tu XML el tamaño de la fuente, o si el botón "Ok" se convierte en "Actualizar", el texto ya no cabrá en el botón original. Si el botón cambia de tamaño, puede que haya que remaquetar todo el cuadro de dialogo.
Parece una labor titánica O_O . Ánimo con ello (aunque yo, personalmente, me preguntaría seriamente si merece la pena dedicar tanto tiempo a éso. Usando la frase típica de este foro ;), ¿no estarás reinventando la rueda? Seguramente exista algún sistema semejante ya hecho por ahi)
PS: me uno a las dos preguntas offtopic de senior wapo
Cita de: "senior wapo"1. A la larga me ha resultado más práctico almacenar las coordenadas absolutas que relativas respecto al widget padre.
Yo la verdad es que siempre he utilizado coordenadas relativas (no es el primer sistema de GUI que hago, sólo que esta vez lo quiero hacer mejor y más completo), y nunca he tenido problemas en este sentido.
Citar2. Delegar todo el dibujado a una clase skin que reciba el area a pintar, el tipo de elemento y su estado (boton pulsado, opcion marcada, etc...).
Nunca lo he hecho así y nisiquiera lo había pensado. Normalmente la clase Style (skin, theme..) sólo carga el XML correspondiente de disco y guarda una copia de la descripción del estilo del widget en un formato más adecuado (ints, Rect's, Font's, Image's, etc.) para leerlo fácil y rápidamente desde el Widget, pero siempre es este último el que se dibuja a sí mismo. Más que nada porque los skins no van a ser "completamente diferentes" en el sentido de que lo único que va a cambiar son las propiedades del mismo (borde del botón, imagen de fondo, etc.) y no la forma de dibujar el widget.
Citar3. El area que define el widget (x,y,ancho, alto), que incluya el borde externo. Que tu clase skin incluya un metodo para calcular el area "cliente" interna.
Siempre suelo incluir el borde en ese área, y lo del área cliente, normalmente sólo la tengo para la clase Dialog, pues es la única que normalmente hace de contenedor visual de widgets, y queda feo que se dibujen por encima del borde del mismo.
Citar¿ Has pensado en como redimensionar automáticamente los widgets ?
Hasta ahora siempre había indicado las dimensiones manualmente (o respecto a otro widget, usando la etiqueta Layout que se puede ver en el artículo), pero nunca lo había dejado redimensionarse en base al contenido. La verdad es que todavía no se lo que hacer, porque si se redimensiona automáticamente el widget habría que hacer, como dices, un remaqueteo de todos los layouts que lo referencien, para mantener la estructura. Estaría bien tenerlo, y además no creo que sea demasiado costoso computacionalmente porque el juego será lento y en ese aspecto irá sobradillo.
Citar¿no estarás reinventando la rueda?
Hay algunas librerías para crear GUI para juegos, como CeGUI, la que usa OGRE, pero la verdad es que después de mirarlas no me convence en absoluto ninguna.
Citar¿Que te ha llevado a dejar el PopCap Framework?
Que no está disponible para Mac, principalmente. Cuando haces un juego orientado a los portales esto no importa mucho, pero si no es así, es muy recomendable tener una versión para Mac también.
Citar¿ Y has dejado el tanki ?
Sí. Ahora mismo puede haber como unos 30 juegos tipo Zuma en el mercado. Yo creo que este subgénero ya está sobresaturado, no me compensa el esfuerzo para el escaso beneficio que le podría sacar, que era el principal motivo de hacerlo. Así que he preferido dejar el camino de los juegos orientados a portales y tirar más por algo que me guste de verdad tanto hacer como jugar (un juego tipo tycoon), aunque me lleve más hacerlo. Además, el mercado casual cambia demasiado rápido para el tiempo libre que yo puedo dedicarle a estos asuntos (como habréis visto con lo del Tanki).
La verdad es que hay que darte la enhorabuena por la capacidad de sintetizar todo un sistema de GUI en tan poco y tan bien y por la valentía al enfrentarte a algo tan pesado y repugnante como es programar el GUI. Es aburrido y lento programarlo en un lenguaje flexible com python no me quiro ni imaginar como será en C++.
Yo me he creado unas cuantas librerías para Flash, ya que los "Componentes" que trae en las librerías para estas cosas son PESADISIMOS.
La verdad es que es algo adictivo... empiezas haciendo una librería para hacer un Boton, luego ves que ese mismo boton lo usas para una Scrollbar con "algo" mas de codigo... luego unos Checkbox, un Combobox, un InputText, un ... y así hasta el infinito! jeje
Cita de: "josepzin"Yo me he creado unas cuantas librerías para Flash, ya que los "Componentes" que trae en las librerías para estas cosas son PESADISIMOS.
La verdad es que es algo adictivo... empiezas haciendo una librería para hacer un Boton, luego ves que ese mismo boton lo usas para una Scrollbar con "algo" mas de codigo... luego unos Checkbox, un Combobox, un InputText, un ... y así hasta el infinito! jeje
Tu no eras grafo ? :P
Ja! pues apenas publique mi cutre-blog te enterarás de mi historia!! :)
Reinventar la rueda!!! Pues si, desde que se invento el coche siempre se ha querido fabricar un coche mejor, pero no deja de ser un coche. Si no fuera por gente como CoLSoN2 todavía iríamos con coches de vapor!! (ole)