Los Gráficos.

Hoy vamos a hablar del apartado gráfico, y a dejar los mismos preparados para que nuestro programa los maneje. En nuestro caso ya tenemos los gráficos definitivos (Matriax suele ser más rápido haciendo los gráficos que yo comenzando a programar), pero esto puede no ser así, en esta situación podemos hacer uso de bloques rudimentarios que representen determinados gráficos, para luego sustituirlos por los finales.

Los dos "pantallazos" que podéis ver están generados por el motor del juego. Falta algún retoque a determinados gráficos, ajustar alguna cosilla, pero el aspecto es más o menos definitivo. También tenemos dudas sobre el espacio vacío que queda debajo de la zona de juego. Hay varias ideas sobre ello: Poner un rótulo con la palabra "Saimazoom", mostrar mensajes de ayuda sobre el juego (te quedan 'x' sacos, se te acaba el agua...) o centrar la zona de juego y extender las "ramas" superior e inferior del interface hasta el lateral izquierdo. El amarillo "doloroso" del fondo del interface es provisional. Velamos por vuestros ojos y será sustituido :)

Lo primero que tenemos que tener claro es como vamos a representar el juego en pantalla: resolución, si vamos a permitir cambiarla, pantalla completa o no, etc. En nuestro caso nos hemos inclinado por una resolución de 640x480 a pantalla completa. Teniendo en cuenta que la resolución del juego en su versión Spectrum era de 256x192, nos da que tenemos que escalar los gráficos a 2’5 veces su tamaño original.

Esto nos lleva a que cada ‘tile’ o bloque gráfico que en el juego original ocupaba 24x24 pixels, en nuestro caso ocupará 60x60, y de este tamaño será cada uno de los bloques gráficos, tanto de los decorados como de los sprites.

Vamos a comenzar viendo la forma en la que vamos a almacenar los gráficos del juego. Fenix pone a nuestro servicio su propio sistema de fichero (FPG) como contenedor para almacenar los gráficos y disponer de ellos y dos herramientas : FPG y MAP para manipularlos.

Los gráficos están creados en formato PNG, y el primer paso que vamos a realizar es portarlos a formato MAP, el que utiliza Fenix. Además le asignaremos las coordenadas de impresión en el centro del gráfico, que será el punto que se tome como referencia para imprimir el gráfico en la pantalla.

Para portar a MAP lo hacemos con la siguiente orden:

MAP –m fichero.png

Y para asignar un punto de control en el centro:

MAP +center=30,30 fichero.map

Notaremos como la extensión del fichero ha cambiado, mejor dicho, se ha creado un fichero nuevo con el mismo nombre del original pero con la extensión MAP apropiada.

Los valores que le damos como parámetro (en esta ocasión 30,30) equivalen a la medida del gráfico dividida por dos, para que sean el centro exacto del mismo.

En el manual de referencia de Fenix tenemos una descripción más amplia de todos los parámetros que se pueden asignar a un MAP y también podemos hacer que el programa muestre una relación de ellos ejecutando MAP sin ningún parámetro. Entre ellos el nombre, puntos de control, animaciones, etcétera. Siempre es bueno añadir al menos un nombre que identifique claramente a nuestro gráfico, ya que en otro caso tendremos que identificarlo por el nombre del archivo.

Una vez que tenemos los gráficos en el formato apropiado, tenemos que introducirlos en un archivo contenedor FPG. Esta tarea es muy sencilla utilizando la utilidad FPG.

El primer paso es crear el archivo contenedor FPG vacio, para ello invocamos al programa con el parámetro ‘n’:

FPG –n fichero.fpg

Le podemos dar el nombre que deseemos, en nuestro caso el fichero será 01.fpg

A continuación añadimos los gráficos MAP al archivo FPG:

FPG –a 01.fpg 01:fichero.map

Con esta orden añadimos al fichero saimazoom.fpg el archivo MAP en la posición indicada antes del nombre del archivo, y separándolos con dos puntos. Si no lo hiciéramos así, se sustituiría el primer gráfico por el recién añadido. Además este código se utilizará para referirnos al gráfico cada vez que tengamos necesidad de ello para mostrarlo en pantalla, por ejemplo.

Como en el caso de MAP, FPG tiene muchas más opciones, os remito de nuevo al manual de Fenix. Una bastante útil es ‘-l’, que nos listará todos los archivos MAP contenidos en el FPG mostrando datos interesantes como el código del gráfico, nombre del archivo MAP, el nombre que le hemos asignado en caso de que así fuera, y el tamaño del mismo.

Un archivo FPG puede contener hasta 999 gráficos y se pueden ir añadiendo sobre la marcha los que deseemos y con el número de código que nos apetezca, que no tiene porque ser correlativo. En lo que sí deberemos tener mucho cuidado es en no asignar el mismo código a dos gráficos, ya que el segundo que añadamos eliminará al primero.

En nuestro caso vamos a asignar los códigos de la siguiente manera:

Del 1 al 49 para “Tiles” del decorado y objetos.
Del 50 al 99 para los sprites.
Del 100 en adelante para rótulos, interface y gráficos varios.

Nos sobrarán muchos códigos entre zona y zona, pero así los tenemos organizados y es fácil añadir más gráficos sobre la marcha sin que queden desperdigados por el fichero FPG. Estos códigos son los que meteremos luego en el fichero con el esquema del mapeado para que el proceso correspondiente genere cada pantalla. Hablaremos de ello en la siguiente entrega.

También tenemos la opción de tener varios ficheros FPG, por ejemplo para el caso de que nuestro juego tenga demasiados gráficos y queramos dividirlos por clases en cada fichero. O para dar la posibilidad de que el usuario seleccione entre varios sets diferentes.

Bueno, ahora ya tenemos los gráficos metidos en su contenedor FPG correspondiente, numerados y con el centro asignado. Hasta la siguiente entrega en la que podremos navegar por las pantallas y ver todo el mapeado..

Lenguaje y herramientas.

El lenguaje con el que vamos a programar el juego es Fenix.

¿Por qué Fenix y no C + Allegro o SDL, DarkBasic, o cualquier otro? Sin entrar a profundizar demasiado, básicamente Fenix tiene un equilibrio entre sencillez de uso y potencia enorme, comparativamente hablando, para crear cualquier juego rápidamente. Lógicamente tiene sus inconvenientes, como puede ser el trabajar como lenguaje interpretado, con lo que supone en carga de máquina; la falta de un entorno de desarrollo avanzado integrado y alguna cosilla más que iremos descubriendo sobre la marcha. Que quede claro que Fenix no es la panacea, pero para lo que queremos desarrollar sobra (y para juegos mucho más avanzados). Además cuento con la ventaja de que ya creé otro juego bajo este lenguaje: el remake del Babaliba. Y esto va a hacer que gran parte del trabajo lo tengamos realizado de antemano, y que la experiencia esté de nuestro lado.

Otra ventaja, quizá la que más me ayudó a inclinarme por este lenguaje, es la posibilidad de compilarlo para diferentes plataformas sin necesidad de modificar el código escrito. Así pues podemos hacer versiones de nuestro juego para Linux, Windows, BeOS, Power PC o Mac OS x.

No esperéis encontrar un estilo de programación “de libro”, seguro que hay varias formas de programar lo mismo, algunas mejores y otras peores.. No soy un programador profesional ni pretendo que sirva como ejemplo para enseñar en una universidad. La única meta que persigo es que el juego funcione bien, que cumpla su cometido de divertir y el mío de aprender cada vez más y de rendir un pequeño homenaje a los programadores que nos hicieron pasar buenos ratos en nuestra niñez.

Tampoco es un curso de programación desde cero. Doy por supuesto que el lector que desee seguir el curso tendrá nociones sobre ello, en el lenguaje que sea, aunque Fenix se parece bastante a C a la hora de programar. Solo se van a resolver determinadas situaciones que se darán a la hora de programar el juego. No se va a explicar que es un entero, un puntero, o un proceso. Para cualquier referencia específica sobre las funciones del lenguaje os remito al manual en formato PDF que trae el propio Fenix y que, aunque la versión es del año 2000, es lo bastante completo y detallado como para poder progresar con él.

Dejado sentado el lenguaje a emplear, vamos a ver con que editor escribiré el código. Anteriormente dije que Fenix no trae un entorno integrado, y es cierto. Pero existen varios proyectos, por desgracia parece que parados desde hace tiempo y solo ejecutables desde Windows, para crear un IDE. En concreto yo he utilizado dos de ellos: Fénix Desktop y Firebird, el primero más profusamente que el segundo, aunque este parece más completo. La instalación de cualquiera de ellos es muy sencilla y la configuración es tan simple, básicamente, como indicar al programa el PATH de los ejecutables de Fenix. Estos entornos están disponibles en la misma WEB de Fenix.

Yo particularmente no voy a utilizar ninguno de ellos. Para escribir el código usaré el editor VIM y compilaré invocando a Fenix desde la línea de comandos. Para mi es más cómodo y servirá de guía tanto para los que trabajen en Windows (yo habitualmente programo en Linux) como para los usuarios de otros sistemas operativos en los que no están disponibles estos IDE’s.

Respecto al tema gráfico voy a emplear GIMP para lo poco que tenga que retocar, ya que el trabajo artístico recae sobre Davit y él emplea sus herramientas favoritas.

Como podéis ver todo el software que se utiliza es libre o gratuito. No tendremos que realizar ningún desembolso monetario para programar nuestro juego, cosa que no sucedería si deseáramos emplear otros lenguajes de programación orientados a juegos como DIV, Dark o BlitzBasic. Además, si el curso lo sigues desde otros sistemas operativos, estos programas tienen versiones para muchos de ellos, y en el peor de los casos está disponible el código fuente para que los compiles para ellos.

Los enlaces a cada programa que utilicemos o domentación a la que hagamos referencia estarán en su correspondiente columna de “herramientas” en el lateral. Así mismo intentaré colgar el documento en formato PDF para facilitar su descarga.

Quiero aclarar que no empezamos de cero, aunque en este blog si lo hagamos. Los gráficos del juego están terminados en un 90% aproximadamente, y el programa va bastante avanzado.

En la siguiente entrega nos meteremos de lleno en la programación, explicando cómo es el mapeado del juego, introduciéndolo y programando las funciones que van a hacer uso de él.

Propósitos de programación para un nuevo año.

Hoy inicio un proyecto que espero se vea finalizado en no mucho tiempo: La programación de un video juego y su explicación y seguimiento, paso a paso, desde un blog. Básicamente el juego corre a cargo de tres personas:

- Al teclado yo mismo, a cargo de la programación: Miguel A. García Prada.
- A los gráficos Davit Masiá Coscollar "Matriax".
- En la música y FX Federico J. Álvarez Valero.


Para empezar, no pretendo ser original, la idea es realizar el ‘remake’ de un juego ya existente, en concreto de uno programado en el año 84 para la máquina puntera en aquellos momentos: el Sinclair ZX Spectrum. El juego es Saimazoom, una de las primeras producciones de los hermanos Ruiz en su sello Dinamic. Casa que luego tuvo un auge espectacular en la programación de juegos de 8 bits y creó más tarde el famoso PC Fútbol entre otros muchos. Ahora se dedican a distribuir juegos para PC bajo su sello FX Interactive.

Como comentaba, el juego a realizar es el Saimazoom. El funcionamiento del mismo es muy simple, pero adictivo. Se trata de recorrer cien pantallas, distribuidas en una matriz de 10x10, con un entramado laberíntico y encontrar cuatro sacos de café. Pero la tarea no resultará sencilla. En cada pantalla diferentes animales, habitantes de la jungla donde se desarrolla la acción, intentarán evitar que consigamos nuestro propósito. La sed también hace aparición para complicárnoslo un poco más, aunque hay cantimploras repartidas con aleatoriamente que la calmarán por el momento. El tiempo tampoco corre a nuestro favor, ya que lo tenemos limitado y este no hay manera de hacer que pase más despacio. Por el contrario tenemos algunas ayudas que nos facilitarán la tarea: una piragua para poder cruzar los ríos, una pistola que evitará que los enemigos nos maten al contactar con nosotros, las citadas cantimploras, un pico para abrirnos paso a través de las montañas y un machete para hacer lo propio a través de la selva.

Bueno, en la próxima entrega veremos en que lenguaje lo vamos a programar, para qué plataformas, las herramientas que vamos a necesitar y alguna cosilla más.