[Dev-Blog] [Proyecto Isekai] [#7]

    Por si aún no os habéis enterado, me encuentro ahora mismo en fase de concepción de un juego que quiero sacar para Game Boy (con su cartucho y todo) y en este blog quiero ir compartiendo mis avances y reflexiones sobre el diseño y desarrollo del juego, así como lo efectivas o desastrosas que van siendo las metodologías que voy utilizando.

     A nivel de planificación ya comenté en la entrada pasada que el modelo clásico en iteración estaba siendo nefasto. Se me hacía complicado conciliar mi vida personal y laboral con la realización de este proyecto y no veía viable ponerme a especificar todo.

    Así que este mes he intentado hacer algo parecido a SCRUM para ver si este método me iba mejor. Para empezar, creé una serie de "features" que fuí apilando en dos categorías: MVP (minimal value product) y backlog, colocando en el MVP lo que considero que puedo hacer en una única iteración y detallando (como si de una User Story fuera) los pequeños detalles que me gustaría mostrar en esas features.

    Una vez decidido qué incluir en esta iteración, hice un pequeño esquema que sirve como mapa de navegación entre las distintas pantallas del juego.

    Con las User Stories y el mapa definido, me puse a trabajar en las distintas reglas de gestión y de visualización (nada exótico, un simple fichero excel) en el que intenté darle una granulaidad por "Pantalla" y "Disparador" (evento necesario para accionarse). Aquí os dejo unos ejemplos:

 

    Estas reglas además iban evolucionando, puesto que conforme iba desarrollando me daba cuenta de determinadas limitaciones o que símplemente no resultaban "agradables para el jugador". Por ejemplo, inicialmente tenía pensado que sonara y destellara el logo al cabo de 5 segundos, pero al debuguear me dí cuenta que 5 segundos realmente parecen una eternidad en una pantalla de "Copyright" (la pantalla inicial donde muestras el logo del juego), por lo que decidí reducir los 5 segundos a sólo 1,5.

 

    Luego, conforme iba creando reglas, me di cuenta que resultaba necesario hacer una matriz de recursos (imágenes, sonidos, melodías, sprites), para ir creando los distintos place-holders (recursos temporales con los que ir trabajando mientras aún no has deifnido su "versión final").

 

    Una vez definidias las especificaciones iniciales, empecé a trabajar con un prototipo basándome en el proyecto por defecto que propone GB Studio, pero borrando todas las pantallas innecesarias (con innecesarias me refiero a las pantallas que no iba a dar uso).

    Realizando la pantalla de Copyright, estuve un tiempo bloqueado porque no sabía como implementar dos reglas de gestión de forma paralela. Me explico: Quería que se pasara a la pantalla de "Pulsa Start" al producirse una de las siguientes dos condiciones:

1. Al pulsar diréctamente algún botón.
2. Al pasar X segundos (que el juego cambie automáticamente la pantalla).

    El caso es que sobre el papel parecía lógico y simple, pero al plasmarlo me encontré con que realmente el framework no te deja trabajar con eventos que se encuentren en distintos hilos de ejecución: Al ejecutarse un evento (espera X segundos), no podía definir de forma simple que se cambiara la pantalla pulsando un botón, se tenía que esperar a que el primer evento parara.

    Intenté bypasear esto trabajando con un timer que se disparara cada 0.1 segundos y que verificara en cada momento si tenía que hacerse algo (por ejemplo disparar un fade-out, un fade-int, cambiar de escena, etc...) o si el usuario había pulsado un botón. Como ñapa servía, pero el problema es que provocaba cierto input-lag que hacía que la transición al pulsar un botón no luciera "natural".

    Así que me pregunté ¿cómo hacen en el ejemplo para que no haya ningún tipo de input-lag al pulsart "Start"? Para daros el contexto, al pulsar "Start" en el proyecto de ejemplo accedemos a una pantalla que lista las quests en curso... Y funciona níquel, sin ningún tipo de lag. Y al verificarlo me percaté de un truco muy ingenioso: Hacen uso de la acción de "Override default button action", que te permite machacar las acciones que realizan los botones. De esta forma, puedo decir de una forma límpia y transparente que al pulsarse start (o cualquier otro botón que quiera), se salte a la siguiente pantalla de forma instantánea.

    De esta forma, haciendo uso de un timer y del override de botones, conseguí paralelizar ambas reglas de gestión de manera satisfactoria.

    Luego, para la pantalla de "Copyright", estuve haciendo varias versiones del logo hasta dar con la que me gustaba. Parece una tontería, pero al manejar una paleta de 4 colores tienes menos margen de maniobra de lo que inicialmente pensaba y tienes que ir probando con distintos niveles de "dithering" (mezcla de píxeles para dar efecto de difuminado) hasta dar con una imagen resultona.

 

     Por cierto, el truco para poder degradar una imagen a 4 colores y que luzca estilo "Game Boy", es abrir una de las imágenes del ejemplo de GB Studio en Gimp, hacerte una paleta de forma manual e indexar la imagen deseada (a degradar) seleccionando dicha paleta (via "Imagen> Modo> Indexado"). Y ojito con la sección de difuminado, puesto que es la que nos sirve para ir jugando con los niveles de "dithering". Por cierto, la resolución de la Game Boy es 160x144, por lo que resulta últil escalar las imágenes antes de reducir su color.

    Una cosa guapa de GB Studio es que te permite además usar más de una paleta de colores simultánea: Tanto sprites como backgrounds están divididos en "tiles" y cada "tile" puede tener asignada una paleta de cuatro colores. Parece un poco absurdo, puesto que en Game Boy sólo hay 4 colores, pero esto está pensando para "Game Boy Color". De esta forma, si el juego se ejecuta desde una Game Boy Color, puedes definir una paleta verdosa para los arbustos, una paleta azul para el agua, una paleta celeste para el cielo, amarilla para la tierra, etc... Y si lo ejecutas desde una Game Boy tradicional verás los 4 colores verdosos para todo. Ahora bien, no puedes tener paletas infinitas, cada escena está limitada a 8 paletas para el background y a 8 paletas para sprites (personajes, objetos, etc).

 

 

El logo se vería de forma distinta en GB Color (imagen no definitiva).

La idea es que el dango, los pies y la nariz del hamster pasen a tener una paleta rosada.

 

 

    Y bueno, poco más tengo que mostrar. Para finalizar os diré que me puse a jugar un poco con la IA de DALL-E Mini para pensar en posibles diseños para mi protagonista, dando como resultado varios modelos curiosos que no me resultan desagradables.