No hace mucho tiempo hablaba en este blog de cómo las consolas se han abierto poco a poco a los pequeños desarrolladores. Mal que bien, este proceso se ha dado y hemos tenido excelentes títulos en las consolas de séptima generación.
Ahora, el análisis que hace Ron Carmel, de 2DBOY, en Is XBLA Past Its Prime? es crítico de cómo el XBLA ha dejado pasar una buena oportunidad de ser la mejor plataforma de desarrollo. Con números y tablas, se demuestran las dificultades para desarrollar en XBLA, citando las dificultades de negociación de contrato, lo difícil que es ser descubierto en la plataforma, y lo obsoleto que es requerir la exclusividad en un ambiente de negocio que hace rato dejó de exigirlo. Léanse el artículo.
P.D.: Según Ron, Steam, Facebook y iOS son las plataformas para las que es más sencillo desarrollar. Ténganlo en cuenta.
Esta charla de Santiago Siri de 14 minutos explica el poder de Internet para impulsar el sector tecnológico de Argentina. Santiago desarrolló videojuegos y actualmente desarrolla proyectos para la web, y su charla toca el tema de la mentalidad de consumidores y creadores, un tema que he tocado anteriormente, por lo que creo que se aplica claramente para nuestro caso venezolano.
El Prof. Esmitt Ramirez publicó los videos de unas partidas de los juegos que sus estudiantes han hecho para el curso de Computación Gráfica que se dicta en la Escuela de Ciencias de la UCV. (Revisen sus charlas sobre OpenGL y 3D y sobre Programación en GPU, son muy buenas)
A continuación les muestro los videos de juegos de 2010 y 2009 que salen en su página dedicada a los videojuegos. Nótese que los avisos que salen en los dos primeros videos se deben a la incertidumbre generada por la Ley de Prohibición de Videojuegos y Juguetes Bélicos, el cual no especifica el caso de creación de videojuegos en trabajos académicos.
En la UNEFA el Prof. José Loreto Romero finalizó en julio de 2011 un curso de programación de videojuegos como una electiva para los estudiantes de Ingeniería de Sistemas. Los juegos que resultaron del curso han sido publicados en el blog del curso, Mont ePython. A continuación un resumen de los juegos entregados, hechos todos en Python y PyGame.
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 760x570.
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 76x57 a 760x570.
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)
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.
