Después de las pruebas desarrollando aplicaciones Android se me ocurrió hacer un juego. El último que hice fue Janus, en 1995 y era una mezcla de Pascal y Assembler. En uno dibujaba pixel a pixel en Assembler y en este iba a tener que usar OpenGL con Java. Una diferencia abismal entre los dos.
Como iba a ser una prueba de concepto no me interesó tanto crear un juego nuevo sino ver el proceso de que necesitaba para llevar el juego hasta el market. Para eso elegí algo que fuera simple de hacer: Que el nivel/mapa actual entre en toda la pantalla asi me evito hacer scroll; Sin muchos gráficos, animaciones ni sonidos. Uno de los juegos que estaba usando en mi telefono era Shoot Bubble Deluxe, uno de los miles (?!) de clones derivados del Puzzle Bobble y me pareció que ese juego tenía las características que estaba buscando.
El juego que hice se llama Frutiblop y reemplaza las bolas que todos los clones tienen por frutas (que original!). Todos los gráficos fueron hechos por Silvia.
Pueden clickear sobre la imagen para instalarlo o usar este código:
Esta primera versión tiene algunos “detallecitos”, que en algún momento arreglaré (o no!).
Desarrollo
Empecé a buscar librerías que ayuden a desarrollar el juego. Primero vi andengine, que parece bastante completa aunque cuando encontré libgdx no dudé en usarla. Es un poco de más bajo nivel y sin algunas de las funcionalidades que ofrece andengine. Pero se puede correr el juego como una app Android o como una aplicación desktop en cualquier maquina que tenga Java, con un mínimo de cambios. Y con esto me evité usar el emulador de Android el 90% de las veces que corrí el juego (ya dije que el emulador es muuy lento?). Esto tiene la ventaja de que quien haga los gráficos puede tener una copia en su maquina e ir ajustando los gráficos y sólo hace falta un jre y el juego.
A medida que fui desarrollando empecé a darme cuenta que hay muchisimas resoluciones de pantalla posibles. ¿Cómo se vería el juego en diferentes resoluciones? De la manera en que lo venía programando los graficos se resizean automáticamente a la resolución del teléfono. Lo cual es bueno pero también es malo porque no siempre despues del resize los gráficos quedan con buena calidad. Además de que puede pasar que la relación ancho/alto de la pantalla sea muy diferente a la de la resolución usada en los gráficos.
La solución (que no se que tan buena es todavía) fue que Silvia haga todos los gráficos con vectores y después generar imágenes para varias resoluciones comunes de teléfonos. En tiempo de ejecución se calcula la relación ancho/alto de la resolución actual y se selecciona el conjunto de gráficos que esté diseñado para un resolución similar. La desventaja es el tamaño resultante del juego, con todas las resoluciones soportadas. Algo que empezó con 1MB, y donde la mayoria de este espacio es lo usado por libgdx, terminó en 4.5MB que para este tipo de juegos es muchísimo.
Categorías: Investigacion
RSS
En el motorola atrix anda bastante bien. la resolucion es buena (si observas con MUCHO detalle ves los pixelitos).