Postmortem del juego de Cachicamoconcaspa

En este artículo hablaré un poco sobre los detalles de implementación del videojuego musical del grupo raspacanilla Cachicamoconcaspa, Imagine (Kuamasi mix), el cual deberías jugar si aún no lo has hecho.

El inicio

La propuesta fue de Gianko y Sergio en 2009 para hacer un juego que se pudiese jugar en el navegador, para el lanzamiento del disco de remixes del grupo. Por lo tanto la opción segura para entonces era hacer un juego en Flash. Sergio, que tiene ya tiempo haciendo cómics en su particular estilo pixel art, iba a hacer los gráficos manteniendo ese mismo estilo. Decidimos, por razones de tiempo, que el juego iba a tener en consecuencia una resolución muy baja.

Especificaciones

El juego fue hecho con Actionscript 3, utilizando el compilador del SDK de Flex, sin utilizar Flash Professional en ningún momento de su desarrollo, ni utilizar la librería de componentes que trae Flex por defecto. Tiene una resolución interna de 76 pixeles de ancho por 57 de alto. Todos los recursos gráficos del juego están hechos para este tamaño, en formato GIF o PNG (para los sprites que necesitaban un canal alfa). Esa resolución interna se multiplica por 10 para que se vea en una pantalla de 760×570.

Para el momento en que se inició el proyecto, no disponíamos de herramientas tan útiles como Flixel, así que el efecto de baja resolución lo implementé a mano (he aquí un post de la época en la que hice esa clase de experimentos). Utilicé la clase BitmapData para dibujar los sprites, y esa clase se asocia con un objeto Bitmap, cuyas dimensiones se extienden sobre el stage del Flash Player para visualizarlo al tamaño final.

Estructura del código

Para concentrar todos los recursos (gráficos y de sonido), los embebí en una película SWF separada de la principal. El SWF principal lo primero que hace es mostrar una pantalla de carga, y el progreso de la carga del SWF de los recursos. De esta manera, el SWF principal pesa 40KB, y el otro 2.5MB.

De haber investigado un poco más me hubiese enterado de que es posible crear un preloader indicándole al compilador que incluya un frame como preloader.

Cada una de las escenas del juego son literalmente clases que implementan la funcionalidad de esa escena. De esa manera, una partida es simplemente un arreglo de escenas que se reproducen ordenadamente. Cada escena implementa su lógica y su manera de leer el teclado independientemente de las demás.

Una ventaja de haber separado así las clases es que fue posible posteriormente hacer una versión del juego que utiliza el almacenamiento local para guardar las puntaciones, y otra versión para guardar las puntuaciones en Facebook.

REPRODUCIENDO ANIMACIONES EN GIFS

Una característica del compilador de Flex es que no embebe directamente animaciones en GIF. Las embebe pero solo las reproduce con el primer frame. Así que se hace necesario embeberlo como un archivo binario y reinterpretarlo con GIF Player, una librería que interpreta los bytes en binario para reproducir el GIF animado completo. Lo recomiendo 100% para proyectos en los que necesiten incluirlos.

Dibujando en la pantalla

Para dibujar en la pantalla utilicé la clase Bitmap, que junto con Sprite permite mostrar gráficos en Flash Player. La diferencia es que Bitmap muestra gráficos basados en mapas de bits (valga la redundancia), mientras que Sprite y otros se especializan en gráficos vectoriales. Los bitmaps puede provenir de un archivo (.PNG, .GIF, o .JPG) o pueden ser producidos a traves de codigo. Para ello, empleamos la clase BitmapData, que contiene tanto un mapa de bits listo para ser asociado a un Bitmap, como las funciones que necesitamos para manipularlo.

Después de asociar el mapa de bits al objeto Bitmap, hay darle a ese objeto las dimensiones reales de la ventana de juego para que agrandar ese bitmap de 76×57 a 760×570.

La ventaja que tiene esta aproximación a los gráficos es la rapidez de la manipulación de los pixeles.

La gran desventaja está en perder la facilidad para posicionar los elementos. Al utilizar BitmapData para dibujar los sprites a la imagen final, debo utilizar una matriz de transformaciones afines para trasladar y rotar las imágenes. Esto no es nada complicado, ya que la clase Matrix que implementa esta matriz ya tiene todas las funciones necesarias para especificar rápidamente esto. Pero puede espantar al no iniciado.

Lo bueno del proceso

Separar las responsabilidades desde un principio. Yo estuve a cargo de la programación del juego, Sergio a cargo de hacer los gráficos, y Gianko de la tabla de high scores y colocar el juego dentro de una aplicación de Facebook. Esto permite a cada uno concentrarse en lo que sabe y ser mucho más efectivo en su labor.

Lo malo del proceso

El proyecto tardó demasiado tiempo en completarse. Problemas de salud en el equipo hicieron que el proyecto quedase en el limbo durante mucho tiempo. Para un proyecto que no es comercial el costo no es monetario, pero para un proyecto comercial un tiempo de desarrollo así mata cualquier relación de negocios.

Conclusiones

El juego me permitió conocer a fondo las capacidades de ActionScript 3 para manipular bitmaps. Flash Player es una plataforma muy completa para hacer juegos, y es posible sacarle provecho de muchas maneras. Estuve muy satisfecho también con la manera cómo se desarrolló la historia (entre los 3 estuvimos agregándole elementos y gags al guión, incluso en sus fases finales).

Algunos datos puntuales

• Número de clases desarrolladas: 39 (La mayoría en lógica del juego)
• Tamaño del directorio con el proyecto: 45MB (Sin limpiar librerías y gráficos sin usar)
• Herramientas utilizadas: Adobe Flex Builder, FlashDevelop, Photoshop.
• Gracias a Cristian Caroli, Jorge Palacios, Julián Rojas, Txomin Gutiérrez, Carlos Briceño, José de Jesús y Maria Fabiola Ramírez por probar el juego y peinar bugs.