Consideraciones a la hora de desarrollar sobre AIR para la BlackBerry PlayBook

Click para ir a la página oficial de BlackBerry de Adobe AIR

Después de haber desarrollado un par de juegos para BlackBerry PlayBook utilizando la plataforma Adobe AIR tengo algunas reflexiones sobre la misma, y quisiera compartirlas con aquellos que están en ello para discutir y probablemente ayudarles a tomar decisiones.

En pocas palabras: para juegos más allá de lo más simple, Adobe AIR sobre PlayBook actualmente no es una buena opción. Explicado mejor: al momento de escribir este artículo, la versión de Adobe AIR sobre la PlayBook no ha llegado a la 3.2, que implementa Stage3D y permite acceder a la tarjeta gráfica de la tableta. Esto implica que el render gráfico con AIR lo hace el CPU. Los juegos no van a superar los 30 frames por segundo, y unos pocos sprites agregados irán llevando abajo esa velocidad.

Probablemente muchos de ustedes van a seleccionar la plataforma AIR para el desarrollo de sus juegos debido a la experiencia que tienen desarrollando con Flash. Sin embargo, la plataforma de AIR sobre PlayBook tiene algunas limitaciones con respecto al desarrollo sobre desktop que deberían tener en cuenta.

Principalmente, la versión actual de AIR en la PlayBook es la 3.1, previo a la 3.2 que tiene el soporte a Stage3D. Esto significa que actualmente no hay (o no he conseguido) manera de poder desarrollar en la PlayBook usando el GPU. Lo que deja al CPU todo el trabajo de render gráfico.

Por lo tanto, mi recomendación va a que Adobe AIR es una plataforma adecuada si tu juego o aplicación va a tener una baja interactividad, o si consiste en una serie de componentes estándar de interfaces gráficas, como Dope Wars. Algo más complejo que eso, y bien te podrías ir con desarrollo para la plataforma nativa con C/C++ de PlayBook, que sí ofrece acceso a la tarjeta gráfica y puedes alcanzar fácilmente 60 frames por segundo y un excelente rendimiento.

Finalmente, dejo algunos tips útiles para el desarrollo con AIR:

  • No utilizar Away3D u otros engines 3D. El rendimiento con ellos es muy pobre y no vale la pena utilizarlos más que para cosas muy sencillas. El rendimiento que he alcanzado, como máximo, usando Away3Dlite es de 15 a 20 frames por segundo. Eso no le hace justicia al poder del PlayBook, que puede correr a 60fps con el SDK nativo.
  • Eso nos deja usar el sistema de DisplayObject. Mantengamos al mínimo el uso de filtros de bitmaps. Si hace falta que lo utilices, precalcúlalo al momento de carga de tu aplicación, y muéstralo en el momento que lo necesites, pero evita crear el filtro y aplicarlo en el momento. Esto implica el uso fuerte de Bitmap y BitmapData.
  • Flex 4 ya trae una serie de componentes de interfaces gráficas interesantes para usar de una vez en tu juego. Eso ahorra mucho tiempo. Sin embargo, tengo entendido que puede tener su peso en el rendimiento de la aplicación. Hasta ahora yo no he tenido problemas, pero quizás alguien se atreva a desarrolar un juego desde cero usando MovieClip.
  • Los bitmaps grandes hacen peso en el desempeño. Ten cuidado con ellos.
  • Desconozco el rendimiento de la plataforma usando gráficos vectoriales. Si alguien ha trabajado con ellos puede mejorar esta entrada con sus comentarios.

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.

PlayPower lleva aprendizaje y entretenimiento a economías emergentes usando computadoras de bajo costo

Hay gente que definitivamente ve oportunidades donde los demás ven basura. Confieso que siempre he visto estas consolas de bajo costo,  como el PolyStation, entre otras, como reemplazos baratos de consolas establecidas, con nombres similares a éstas con el fin de confundir a compradores incautos que buscan un regalo para sus seres queridos y ven en esto una alternativa costeable. Estas consolas están basadas en procesadores de 8 bits, por lo que su calidad en gráficos y en interactividad dista mucho de los estándares de 2011, para acercarse más a los de 1985.

Y verán, la piratería, que es algo tan común en estos países latinoamericanos, en cierta forma implica que el producto pirateado es siempre de bajo costo, una alternativa «para enseñar» pero que muy probablemente no tiene la misma calidad que el original, y que por lo tanto no tiene la misma utilidad. Pero lo que no había observado es que en el caso de estos aparatos digitales hay tanto potencial para explorar, utilizándolos con un genuino propósito de llevar conocimiento y entretenimiento.

Como dice Derek Lomas, fundador de PlayPower.org y el expositor del video que les pasaré a continuación, estas computadoras de 8 bits suelen llevar juegos bastante cutres, y sin embargo, cuando nosotros vivimos la era de los 8 bits, jugamos juegos buenísimos: Carmen San Diego, Maniac Mansion, etc, etc, etc. Si la mayoría de estos juegos son considerados abandonware, en un estado del copyright que impide su libre distribución pero que ya no representan una fuente económica para sus creadores, ¿por qué no llevar estos juegos a estas computadoras de bajo costo? ¿por qué no incluir un intérprete de BASIC (o de algún otro lenguaje más moderno) que enseñe a los niños de países en desarrollo a programar?

Me pareció una idea tan genial que me veo obligado a compartir el video con ustedes. Una excelente idea expresada en solo 5 minutos:


(Vimeo en Poptech)