Edevi, el blog de Manuel F. Lara

Uno de los principales problemas a la hora de abarcar un proyecto como programador, es encontrar a alguien que esté lo suficientemente capacitado, motivado y con tiempo libre para trabajar en el apartado gráfico de tu juego. Y que le guste tu idea. Ah, sí, y que trabaje gratis. Ese pequeño detalle de corte económica suele ser el que da al traste con todas tus ilusiones de encontrar a alguien que cumpla las condiciones mencionadas antes.

Seamos francos, hay muchos artistas freelance que te harán los gráficos que quieras -seguramente mejores que los que tenías en mente- pero eso sí, a un precio nada desdeñable para alguien que no tenga un presupuesto abultado. También está la opción de de tirar por grafistas de segunda liga o amigos, que aún cobrándote, te harán mejor precio. Aún así, si tu juego tiene más de tres botones y cuatro sprites, también te saldrá todo por un ojo de la cara. Y lo mismo se aplica cuando lo que necesitas son efectos de sonido y música.
Ahí es donde entran en juego los packs de contenidos. Normalmente, cuando contratas a un artista para que te haga un trabajo determinado, existen una serie de condiciones que se dan:

• Tu le dices al artista lo que quieres, él te dice lo que tardará y lo que te cobrará en base a ese tiempo que él dedica a tu proyecto.
• Hay una comunicación directa y constante entre el artista y tú.
• Obtienes derechos exclusivos sobre el trabajo por el que pagas.

Debido a esa personalización que el artista debe hacer, y del tiempo que te dedica exclusivamente a ti, esta opción siempre será más cara a la vez que te da recursos más acordes con tus proyectos y necesidades. Por otro lado, cuando compras un pack , hay otras circunstancias:

• Encuentas un pack que te es útil para esa idea que tienes en mente o proyecto que ya tienes comenzado; lo pagas y lo obtienes al momento.
• Tienes que conformarte con lo que hay en cuanto a cantidad y calidad de los modelos, sin embargo hay muchos grafistas que están abiertos a realizar personalizaciones a modelos que hayan hecho para packs (como añadir alguna animación) a un bajo precio, pues les sirve para aumentar la calidad del pack.

Pese a que la mayoría de modelos de stock que pueden encontrarse en sitios como TurboSquid son, en mi opinión, carísimos y en ocasiones de muy baja calidad, hay otros lugares donde se pueden encontrar auténticos chollos. Packs tan bien hechos que te hacen salivar de lo que podrías hacer con ellos, y tan baratos que muchas veces los compras sin tener siquiera un objetivo concreto para ellos.

Este es el caso de algunos de los packs de 3DRT, muy conocidos por sus packs de naves y sci-fi, aunque tienen otros packs igualmente estupendos de otros géneros. En GarageGames también podemos encontrar una sección de content packs bastante chulos y de todo tipo, por supuesto con modelos precompilados para el Torque Game Engine (amén de otros formatos). También en cuanto a audio se encuentran buenas ofertas, como los packs de efectos de sonido de IndieSFX, algunos de los cuales usaré en PuzzleCraft.
Sin embargo, el pack que me ha inspirado para escribir este post, dado el curro que hay detrás y su alto valor calidad/precio es el Warriors and Commoners de Frogames, que por sólo $150 (que con el cambio al euro, es un precio de risa) nos proporciona un completísimo kit de elaboración de personajes de índole medieval para RPGs y MMOs.

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