Edevi, el blog de Manuel F. Lara

Esta mañana he dado el pistoletazo de salida a la fase de Creación de los Recursos del juego, o al menos la mayoría de ellos. Por un lado, quizá sea más corta de la semana que planeé porque Jove se ha ofrecido a hacerme unos modelos personalizados que necesita el juego, mientras que he descubierto que los modelos del Glest que Tucho liberó para ser usados gratuitamente no tienen animaciones. Tendré que hablar con el animador del Glest a ver si se enrolla.

A parte de trastear con la importación de los modelos del Glest en Unity, he estado haciendo algunos bloques para el juego, he aquí el recurso (madera) verde y su catalizador (hacha).

Ya he comentado antes que Unity es un entorno realmente productivo. Una de las features que más tiempo ahorran y más simplifican el código son las corutinas. Es algo que también tiene UnrealScript y podría decirse que es uno de los pilares de la programación en DIV/Fenix.

Digamos que tengo un item que quiero que al colisionar con un jugador, desaparezca suavemente aumentando su transparencia. Y que al cabo de un minuto vuelta a aparecer, de nuevo suavemente. Esto en un motor convencional requeriría tener varias variables de la clase Item para llevar la cuenta del tiempo que llevamos haciendo fading del objeto, el sentido del fading (está apareciendo o desapareciendo?) o el tiempo de espera hasta el respawn. Y además, todo ese código estaría mezclado con el resto de la lógica que queramos que ese item ejecute cada frame, en algún método como Update() o algo similar. Todo eso disparado por algún confuso sistema de detección de colisiones.
En Unity sería algo así:

La sentencia yield es equivalente a frame; en DIV/Fenix. En Python tiene el mismo nombre, y en UnrealScript no me acuerdo, pero en todos funciona prácticamente del mismo modo (el contexto en el que pueda usarse ya es otra historia). Básicamente significa “sal de esta función pero mantén el contexto de la misma en memoria, para en el siguiente frame, retomarla justo donde la acabo de dejar”. De este modo puedes definir en una función una serie de eventos o comportamientos que ocurrirán sucesivamente uno detrás de otro en tu simulación, en vez de ejecutarse todos secuencialmente pero en el mismo frame.
Al principio no le veía demasiada utilidad. Después de usarlos me doy cuenta del gran potencial que tienen, sobretodo en cuanto a productividad y mantenimiento del código.

Después de varios meses de parón he decidido retomar este proyecto del que no había escrito nada desde mayo. Eso sí, la vuelta no está exenta de cambios de todo tipo. 

Por un lado, el logo. Siempre había visto el diseño de la palabra tycoon muy pobre y fuera de lugar respecto a nightclub, que sí me gustaba (efecto dorado vs. neón). Ahora ambas palabras tienen un efecto de neón típico de los letreros de clubs nocturnos, aunque distintos.

Por otro lado, he decidido que el diseño de la interfaz del juego no me convence del todo. Así que he decidido rehacerla desde cero. El problema es que no me convence ni la estética (muy minimalista, muy zen, en vez de temática.. cosas de no ser muy habilidoso artísticamente) ni la distribución de los controles (el tener un menú abajo con iconos y arriba otros datos importantes como el dinero o la fecha). En breve iré publicando los nuevos diseños que se me vayan ocurriendo. Tengo hecho uno que me gusta por funcional, pero parece más una aplicación de gestión que un juego…

En cuanto a la jugabilidad, el cambio más destacable es que ahora la simulación transcurrirá en tiempo real, constantemente, de fondo, mientras el jugador gestiona su club. Anteriormente iba por turnos: primero el jugador toqueteaba lo que quería, luego “ejecutaba” la simulación que sólo se paraba cuando tenía que tomar alguna decisión importante para la simulación.

El último cambio significativo del juego es en el lado técnico, pues he decidido que aunque el motor (que ya tengo hecho) será todo en C++, el juego lo programaré en Python, que es un lenguaje que ya tengo ganas de probar en un entorno más grande que una simple aplicación de unas cientos de líneas.

Tengo un nuevo proyecto entre manos para el que estoy portando mi motor de vuelta a PTK (ironías de la vida), mejorándolo en el proceso. Desde luego no estoy dispuesto a perder aquello que más me gustaba del PopCap Framework, su sistema de GUI, así que me he propuesto portarlo y mejorarlo en todo lo que pueda, pues el juego que tengo pensado es básicamente interfaz gráfica y necesito un sistema potente y flexible, con muchas características que el sistema del que ahora disponía, no tiene.

Dado que un sistema de GUI es algo bastante complejo y extenso voy a dedicarle varias entradas al mismo tema, a medida que lo voy desarrollando. En esta primera entrega discutiré las especificaciones. Es decir, los requisitos del resultado final del código, aquello que quiero que tenga y cómo debe funcionar.

Leer el resto de la entrada »

A petición de algunas personas he incluído una demo ejecutable de lo que hemos construído en el artículo sobre sistemas de partículas.

[ Descargar Demo (791 Kb) ]