DevSpace #11 “Desarrollo de videojuegos para Android”

Hoy ha tenido lugar el DevSpace #11, que ha girado entorno al desarrollo de videojuegos sobre la plataforma Android, la charla ha sido impartida por el grupo The Flying Cortijo quienes han estado promocionando y repartiendo copias de su juego Tile Land, un juego de puzles que consiste en formar parejas de tiles idénticos.

En cuestión de programación, hay que evitar en la medida de lo posible el garbage collector, este proceso puede llegar a consumir 600 ms y salta cuando hay del orden de 2000 objetos en memoria, lo que puede llegar a ser un performance killer.

Las técnicas para evitar este problema son la delegación de actividades costosas en memoria y proceso al código nativo, para lo que hay que utilizar el ndk de android y en general cualquier tipo de creación o eliminación de referencias, almacenar los objetos en listas para no perderlas.

Sobre el sonido, se recomienda el formato ogg y el uso de la clase SoundPool para almacenar los efectos del tipo disparos, explosiones, etc de la aplicación.

A nivel de gráficos la aplicación está construida con archivos pequeñitos en peso, el proceso de construcción básico es la creación de un boceto en coreldraw para la posterior edición con alguna herramienta de dibujo vectorial, ha dado tiempo a hacer una pequeña demo de como se realizaría una animación.

El vídeo de presentación se ha mostrado tras unas nociones de creación de sonidos, como aplicar efectos y como componer un theme en general.

Editado (3/5/10):

Aqui tenemos un enlace a algunos recursos más sobre la ponencia, donde podemos encontrar fotos y un vídeo del evento.
http://www.desea.es/?p=328

BulletJni rules

Al final conseguí poner en pié la biblioteca jbox2d portada a android y la verdad es que el rendimiento no era nada del otro mundo, la probé con canvas y el código era android (no nativo) pero aún así el rendimiento era muy pobre, 1 o 2 frames con 10 objetos en pantalla colisionando en forma de pirámide.

Así es que estube probando otras opciones, una de ellas que es la que al final me convenció fué BulletJni, que es una biblioteca que hace uso de métodos nativos en c para el cálculo de colisiones y movimientos físicos, por ahora lo que se puede ver es una aplicación en la que 10 sprites se mueven por la pantalla al son del acelerómetro, pero rinde entre 25-50 fps, lo cual me la pone muy gorda.

Se puede ver el código fuente en http://code.google.com/p/android-2d-engine/source/browse/#svn/branches/bullet_jni

Engine para juegos android

Estoy buscando la forma de hacer un jueguecillo para android y necesito un engine 2d, así es que a buscar tocan, hay poco esto es todo lo que estuve viendo

Si quieres desarrollar no puedes dar la espalda a la comunidad, así es que no te olvides de pasarte por anddev.org


Rokon es una biblioteca para desarrollo de juegos 2d, actualmente tiene un problema con la herencia entre Sprites y objetos dinámicos, un poco floja en dinámicas

ProAndEngine no tiene documentación pero lo único que hace es lo que se ve.

JBox2D tiene un sistema de colisiones y otro de físicas completo, está basado en box2d, una biblioteca c++, es genérico, así es que supongo que necesitará alguna biblioteca gráfica, y la lógica de negocio del juego.

Uhm... rokon + jbox2d = jRox2d, a ver que tal.

Problema número 1:
Rokon tiene una herencia desde mi punto de vista no correcta y eso crea problemas en los behaviours de los sprites, solución: todo objeto que hay en la pantalla es un sprite, pero sólo los objetos que no son una isla son objetos dinámicos, la herencia está al revés y ahora no se puede usar el tipo primitivo que es sprite y colarle un DinamicObject cuando sea necesario, no puede haber islas, por que el tipo más básico en la herencia es el objeto más complejo.

Update:
He tenido que tocar todo el sistema de sprites y ya sólo falta por funcionar la gravedad que la he incluido en el dynamicObject, tengo algún problemilla con la temporización de los eventos :S

Update:
Problemas solucionados relativamente, se quedan los Sprites como clase base, pero la he liado un poco invirtiendo las clases, así es que hay que revisar las responsabilidades de BasicSprite, DynamicObject y Sprite, es probable que sustituya esa parte del sistema por jbox2d.
https://code.google.com/p/blasters/source/checkout

Los fotones como energía

Comentan en ciencia kanija que comentan en nature photonics que los fotones se pueden atraer o repeler, dependiendo de la "phase" con que se envíen, entiendo como phase la diferencia de tiempo con que entran con la misma amplitud y frecuencia.

Bueno, en física teórica un fotón es simplemente un mediador para cualquier tipo de iteracción electromagnética, por lo que en principio, lo único que han conseguido es demostrar que la teoría es cierta, es un pequeño gran paso para conocer a los fotones, se ha teorizado mucho sobre ellos y esto es una consolidación de un importante principio teórico.

Entiendo que al ser energía (mientras no se demuestre lo contrario) habría alguna iteracción entre las dos cargas en movimiento, la gracia de lo que han conseguido es que básicamente se ve que dependiendo de la diferencia con la que se mandan las dos ondas se atraen y se repelen y hasta se puede controlar la fuerza de atracción / repulsión, a mi personalmente esto me lleva a pensar que en definitiva son dos partes de un mismo haz de luz, si coges esa onda y la desfasas x grados con respecto a si misma puedes conseguir dos cargas (entiendo que en este punto interesa que una de las dos sea conocida) y lo que han conseguido es hacer un cálculo por el que se obtendrá una cantidad de empuje positivo o negativo en base a la amplitud de la fase con que se separan.

Un concepto realmente interesante, aunque no se hasta qué punto cierra esto el círculo de utilizar este nuevo descubrimiento para sustituir al actual transistor de silicio.

Buildlog sukoi 31

Este fin de semana ha sido productivo, he recortado y pegado un plano de 5x5 folios A4 (unicamente durante los anuncios de una película en los anuncios de chocolate), he cortado las 8 costillas y las 6 semicostillas de deprom ñiajajaja los largueros de madera de balsa con un corta-listones que compré en TowerHobbies, canela en rama, ahorra una pasta, bueno, el caso es que tengo montada el ala en modo dry fit y no puedo subir una foto por que mi cámara no me permite sacar una foto si no es en la tarjeta :( así que otro día será.

Otro día subiré las fotos y el plano.

Bueno, la cosa va lenta y no por el avión sino por un proyectito que estoy haciendo he hecho. Pero lo prometido es deuda, aquí teneis una foto de como va el ala, parece que aguanta el deprom para costillas.

De Todos somos ignorantes pero no de las mismas cosas

No utilices el martillo de oro

Hoy me apetece relatar las consideraciones que hay que tener en cuenta a la hora de escribir código.

Todos los que programamos tenemos ciertos vicios creados y es dificil prescindir de ellos, puesto que según el antipatrón de diseño del martillo de oro cuando un martillo funciona todo te parece un clavo :) y es prácticamente imposible eludir esa norma, así que desde mi humilde opinión voy a mencionar algunas ideas que a mi me han valido.

* Piensate bien las cosas antes de actuar, pero no dejes que eso te paralice, una aplicación sana comienza en la base de datos y termina en la interface de usuario sin descuidar ninguno de sus puntos intermedios, un error de diseño en cualquier paso será como una pequeña piedrecita, pero se convertirá en una enorme losa de granito al final del desarrollo, como nadie es perfecto, refactoriza frecuentemente, no dejes que la losa te aplaste.

* Utilizar un lenguaje de marcas al generar la interface siempre es una buena idea, aunque si el tamaño de la aplicación lo merece, es mucho más recomendable utilizar un motor de plantillas, esto facilitará mucho la comunicación entre el equipo de programación y de diseño.

* Tampoco estaría mal tener un método rápido y sencillo para generar todo el código que vaya al servidor, de la misma forma que se genera el x?html si va al servidor no es más que mera presentación, por qué no darle el mismo trato al html?

* $Deity nos coja bien follados confesados en las depuraciones bajo internet exploiter, como su propio nombre indica es una bestia indomable e impredecible, en este caso conviene atarla bien atada con una dtd, para que el quirks mode no haga de las suyas, o pasar de dtd, ponerte el gorro mejicano y que comience el rodeo.

* Estudia tus necesidades e intenta casarte lo mínimo posible con cualquier tecnología, a no ser que necesites rendimiento, entonces cásate con cuantas quieras, siempre que las hagas modulares, si formas amalgamas es probable que cuando haya que cambiar por una chinita en el camino, la losa te aplaste.

* En realidad cuando uno es buen programador encuentra caminos fáciles y concretos y camínos difíciles y genéricos, siempre hay que buscar al fantasma de la sobreingeniería y resolver el problema con el grado de complejidad correcto, un exceso costará más, pero lo más probable es que cuando se implemente la parte que sobró haya que adaptar la interface o que esa parte nunca se use, un defecto llevará a una refactorización, ya sea para adaptar interface o ampliarla, en cualquier caso la parte a + b parece mejor opción, sobre todo si la parte b no se conoce en el momento de la generación del código, por qué implementarlo si no se sabe ni como ni cuando se va a usar?

Me dejo todo un libro en el tintero, pero, cuando uno tiene estudios aprovechados, dos dedos de frente o un buen proyecto, aprende todas estas cosas enseguida, para el resto de los mortales son los misterios del exito del código de otros y no son más que cuatro recomendaciones básicas, así que recuerda, no utilices el martillo de oro

The financial crisis for dummies

El otro día me llegó un enlace de los más interesantes que me han llegado últimamente, el blog de Leopoldo Abadía y navegando llegué a uno de los anexos, la crisis ninja.

En este anexo se explican el cuando, el cómo, el porqué y el quien ha influido en la crisis como el la llama ninja, que significa No Income, No Job, no Assets (Sin ingresos, sin trabajo y sin activos) en referencia a las personas que recibieron préstamos en esas condiciones, los tipo de productos que la banca inventó para aprovecharse de ellos, como la clase política "comenta la jugada" y lo que el piensa de esos comentarios :).

Una lectura muy entretenida que debería ser seguida por todo aquel al que le importe lo más mínimo lo que pasa en este planeta y no tenga ni idea de los oscuros detalles de ese mundillo perverso en el que se convirtió la economía en los últimos años.