Edevi, el blog de Manuel F. Lara

Bueno, bueno, bueno. Parece que el juego ya va tomando forma, ya ni siquiera daña la vista. Los que hayáis seguido el progreso del juego notaréis una ligera diferencia respecto a hace un par de semanas. La verdad es que el juego tenía esa misma pinta hace tres días. ¿A qué se debe tan tremendo y rápido cambio? Un lavado de cara tan brutal es pan comido si trabajamos con buenas herramientas y disponemos de recursos de primera. Y es que como dice el dicho, con buena polla bien se jode, amigos.

Por un lado, he echado mano del RTS Environment Pack de Shapes & Lines. Si véis el video de preview que hay en la página veréis que a $40, el pack es un robo. La otra mitad del trabajo se la debo al genial editor de terrenos que lleva Unity en su versión 2.0, que aunque aún no está terminada, unos cuantos usuarios del genial motor ya usamos en versión beta desde hace unas semanas. Y pese a los bugs que aún quedan por solventar y alguna que otra pequeña feature por añadir, la verdad es que pinta muy bien, sobretodo el nuevo sistema de GUI (del que hablaré próximamente) y el motor de terrenos. Una de las ventajas de Torque respecto a Unity dejará de serlo próximamente.

Por cierto, la imagen que encabeza el post corresponde a la posición de la cámara una vez estemos jugando, pero cuando estemos en los menús, estará algo más alejada. Aquí podéis ver una vista desde más atrás.

Una de las formas de putear al contrario en PuzzleCraft es con avalanchas. Las avalanchas son bloques (muchos o pocos) que caen de golpe al jugador contrario después de que tú hagas explotar varios bloques en tu campo. Hay un número determinado de bloques que debes detonar para que se produzca un avalancha en el campo contrario. Si superas ese número, se le enviarán al contrario la mitad de los bloques que hayas detonado.

Por ejemplo, digamos que el valor mínimo de bloques a detonar son diez. Al poner un par de bloques en mi campo hago que detonen diez bloques de golpe, que al desaparecer crean un hueco en medio de mis “parrilla”. Así pues, los que quedan flotando, caen. Estos, mira tú qué majos, también detonan, produciéndose un combo, que multiplica la puntuación obtenida en esta explosión por dos. Ahora detonan cinco bloques, pero como tenemos el multiplicador, realmente es como si explotaran diez otra vez. Así que hemos explotado “veinte” bloques. Como pasamos del mínimo de diez, el jugador contrario recibirá una avalancha de diez bloques, la mitad de los que detonamos.

Al principio implementé esta avalancha de bloques de forma aleatoria, es decir que caían en cualquier sitio y de cualquier tipo. Esto tenía dos problemas. Por un lado, podía darse el caso de que el jugador tuviese, por ejemplo, la mitad de las columnas muy llenas y la otra mitad muy vacías, y los bloques de la avalancha cayeran en las más llenas, lo cual no es nada óptimo de cara a no fastidiar demasiado al jugador. El otro problema era que como el tipo del bloque también era aleatorio, en muchas ocasiones la avalancha provocaba que unos cuantos bloques explotaran, con lo que el efecto “puteo” no era tal, sino que a veces era casi una ayuda.

Esto de las avalanchas ya estaba presente en Baku Baku Animals, y ahí recuerdo que esos bloques enviados por tu enemigo nunca hacían detonar los tuyos, con lo que tenía que encontrar la forma de que esto no pasara.

A la derecha tenéis un gráfico que muestra la evolución del tablero mientras se ejecuta el algoritmo. En un primer momento sólo sabemos cuántos bloques queremos poner en juego, en este caso veinte.

Para determinar de una forma óptima en qué columnas los meteremos, he utilizado un algoritmo de selección por ruleta, algo que aprendí de rebote mientras me miraba hace un tiempo todo el tema de algoritmos genéticos. Básicamente se trata de asignar un peso a cada columna en base a su “fitness”, es decir a lo mucho que nosotros queramos que esa columna sea seleccionada. Seleccionada para la siguiente generación en algoritmos genéticos, o para meter un bloque en PuzzleCraft. En este caso la forma de obtener el fitness es bastante clara: cantidad de espacios vacíos en la columna dividido por los espacios vacíos de toda la parrilla. Al hacerlo de esta forma observé que la diferencia entre pesos no era demasiado grande y no obtenía el resultado que quería, así que elevo a cinco la cantidad de espacios de una columna antes de sumarla al total, de forma que la diferencia entre pesos sea más brusca y realmente se note a la hora de ver donde caen los bloques la mayoría de veces. Después de eso simplemente meto los veinte bloques en las categorías que van saliendo, que resulta en la segunda imagen.

Ahora sólo falta darles un tipo determinado de forma que no hagan matching con sus vecinos. Essto es muy sencillo. Se le da un tipo aleatorio. Si no colisiona con ningún vecino, perfecto. Si lo hace, se le asigna el siguiente tipo (los tengo todos en un enum), y a volver a probar. Uno acabará sirviendo, pues hay cinco colores distintos
y cada bloque sólo tiene cuatro vecinos.

Después de esos dos pasos, ya sólo tenemos que lanzar los bloques como si cayeran del cielo cual castigo divino y la frustración de quien los recibe está garantizada (y la satisfacción del contrario, claro).

Este fin de semana terminé con la lógica básica del juego tal y como estaba previsto. Sin embargo, esta semana he estado más por la interfaz del juego que por la creación del escenario, con lo que estoy cambiando un poco el calendario previsto. Pero a grandes rasgos, voy siguiendo el planning inicial.
A la derecha podéis ver un gráfico que muestra los estados de interfaz por los que pasará el usuario mientras está en el juego, todo bastante simple. En una versión ampliada del juego podría haber selección de mapa o raza, pantalla de opciones, tabla de puntuaciones, etc. pero el tiempo que tengo no da más de si.

En cuanto a los modelos del Glest, ya he conseguido las versiones animadas de las unidades (gracias a Félix!), aunque ahora el problema es conseguir exportarlas correctamente a .FBX para cargarlas en Unity. Las animaciones están hechas usando el modificador Physique de 3D Studio Max, y parece ser que el exporter sólo soporta el modificador Skin (o cosas más básicas, pero no Physique). Además, parece que al torso del modelo se le hizo un mirror y ahora tiene un escalado negativo, y eso tampoco le gusta (me salta un warning al exportar, pero falta ver si cambiando lo del Physique, ya funciona todo y se queda lo del escalado en un susto). Si alguien sabe cómo arreglar esto sin rehacer la animación, estaría tremendamente agradecido.

Por otro lado, da la casualidad que la gente de Over The Edge, los creadores de Unity, han anunciado un concurso para “juegos web casuales hechos en Unity”, con $2.000 y una licencia de Unity 2.0 Pro como primer premio. No está nada mal, y ya que PuzzleCraft tenía pensado hacerlo como juego web (más que nada porque con la versión indie no puedo exportar a Windows), me viene que ni pintado. Y además la fecha límite de entrega es pocos días antes que la de artFutura. Así que si no voy muy ajustado, mataré dos pájaros de un tiro.

Después de hacer una llamada para encontrar algún músico español que hiciera la música de PuzzleCraft y no encontrar a nadie que me diera la suficiente confianza, acabé contactando con un veterano de la escena indie, el sueco Staffan Melin.

Le bastaron un par de indicaciones bastante vagas por mi parte (es lo que tiene no tener ni idea de música) para clavar prácticamente a la primera un par de temas que a mí personalmente me encantan para el juego.

Os dejo ambas canciones para que juzguéis por vosotros mismos:

• La canción que sonará en los menús: puzzlecraft-menu.ogg
• La canción que sonará durante las partidas del juego: puzzlecraft.ogg

Estoy ya metido con la programación del proyecto, principalmente con la de las entidades básicas de la lógica de juego, las que se muestran en la figura de la derecha. Esta fase, que dura un par de semanas, no actualizaré tanto como he hecho hasta ahora por el simple hecho de que los avances en programación no siempre vienen acompañados de algo visual que pueda ser enseñado.

De todos modos, en cuanto al calendario de desarrollo todo va según lo previsto. Bueno, casi todo. Al final he dejado el tema de recursos de audio y los modelos personalizados a personas expertas en la materia, con lo que se retrasarán un par o tres de semanas, pero sin duda merecerá la pena. Tampoco me iban a hacer falta hasta entonces, o incluso una semana más tarde, así que no habrá problema si no hay retrasos en la entrega.