Edevi, el blog de Manuel F. Lara

Ya han sido anunciados los ganadores del IGF 2008. Por desgracia, Galaxy Scraper no se llevó el premio al mejor juego en la categoría de estudiantes. Otro año, amigos!

Bueno, ya es oficial que PuzzleCraft no ha sido finalista en el Top DOG contest de OTEE -la empresa creadora del motor que uso, Unity-, ni del artFutura de este año. Una pena, la verdad es que creo que el juego tiene potencial para haber llegado a al menos la final de artFutura.

He estado viendo videos de la mayoría de finalistas de artFutura (los tenéis en un post más abajo en el hilo del enlace) y la verdad es que hay verdaderas joyas. Mi favorito de lejos es Extreme Table Soccer. Como aficionado al futbolín que soy, me encanta este juego, además de que creo que es el que mejor acabado tiene, 100% profesional.

¿Qué le depara el futuro a PuzzleCraft? Bueno, sólo el tiempo lo dirá, pero me gustaría terminarlo como se merece y ponerlo libremente disponible para que lo disfrute quien quiera. Os mantendré informato de todos los avances.

Bueno, los que hayáis ido siguiendo el progreso del juego en Edevi, que sepan que PuzzleCraft no cayó en el olvido, de hecho después de una semana de pocas horas de sueño, pude entregarlo el día 20.

Aquí tenéis un video, 15 MB: http://www.puzzlecraftgame.com/puzzlecraft-ingame.mov 

Y cómo habrá algún listo que acabe dando con la URL de la versión jugable, la pongo directamente. Los que quieran jugar a la beta (os recuerdo que es un juego para dos personas en el mismo teclado), podéis probarlo aquí:

http://www.puzzlecraftgame.com/artfutura

Si os creáis una cuenta de usuario os podréis loggear al entrar en el juego, y si jugáis dos usuarios loggeados, la victoria y derrota quedará registrada para ambos. Sin embargo, antes de nada os recomiendo que leáis el LEEME que adjunté a la build de artfutura, con los controles, alguna que otra nota importante, known issues y demás:

http://www.puzzlecraftgame.com/artfutura/LEEME.txt

Por último decir que aunque el juego funcione tanto en Mac como en Windows, la plataforma recomendada es la primera. Se aceptan comentarios

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).