Internal Beeper


Mobile Game Development (II)
febrero 8, 2006, 1:01 am
Filed under: Divagaciones

Venga, empezamos la parte interesante: Programación. Este post va a ser un poco duro para los no programadores, quedais avisados.

Programar para móviles, en Java, es bastante fácil. Si sabes Java (es decir J2SE), sabes J2ME. Es decir MIDP.

Básicamente es lo mismo. La API (comandos disponibles para el programador) es más limitada, lo que obliga a hacerse uno mismo muchas cosas que en Java convencional ya te vienen hechas, y por otra parte se dispone de algunos comandos, sobretodo en MIDP2, que bien utilizados (y suponiendo que el móvil para el que programas sea completamente compatible con esas funciones) pueden mejorar la capacidad gráfica enormemente.

Para aprender más sobre MIDP, no hay nada mejor que pasarse por developer.com, MicroDevNet, tutoriales varios o la siempre infalible página de Sun. También por emule se puede encontrar bastante información sobre J2ME.

Pero hay algo que no se acostumbra a enseñar en los tutoriales. Para programar en J2ME, sobretodo cuando tratamos con móviles reales, debemos abandonar la programación orientada a objetos de JAVA. Al menos, en su faceta más pura.

A todos los que hemos aprendido Java nos han enseñado que lo mejor es tener un sistema de clases organizado. Muy organizado. Múltiples clases, herencias, hacer decenas de clases para agrupar cualquier tipo de dato relacionado…

Para programar con móvil uno debe desprenderse de esto. Hacer objetos, es decir, instancias de clases, le cuesta una barbaridad a un móvil. Destruirlos aún más. Aún suponiendo que el móvil libere completamente la memoria, y sin fragmentarla, que es más la excepción que la regla.

Imaginemos el Zelda pasado a móvil. Sistema de habitaciones donde hay un número limitado de enemigos. Cualquier manual de Java nos explicaría que lo que tenemos que hacer es una clase genérica de “enemigo”. Y tener clases heredadas para los enemigos con características distintas. Y, evidentemente, cada vez que se entra en una habitación, generar un objeto por cada enemigo (o tenerlos todos previamente generados), e irlos destruyendo los objetos “enemigos” cuando los vas matando.

Pero si queremos que realmente el juego se pueda ejecutar en un móvil, se tiene que programar más a lo bruto. Por ejemplo, la mejor solución sería:

-Tener una tabla de características de cada tipo de enemigo, en una array bidimensional. Será una array relativaente pequeña, de 10×10 bytes.

-Tener una array de booleanos de los enemigos con su estado (vivo o muerto) o, mejor aún, de bytes (en MIDP, un booleano ocupa lo mismo que un byte) con la vida restante de ese enemigo (si queremos guardar información adicional, como la habitación donde están o incluso la posición en concreto, el tamaño empezará a ser preocupante, por lo que es mejor cargar sólo los de esa fase).

-Tener una array de índices de que tipo de enemigo es cada uno.

Así, ya no tenemos distintos objetos que crearemos y destruiremos constantemente, consumiendo la memoria del móvil. Tendremos unas pocas arrays de información que solo tendremos que cargar al inicio del juego y destruir cuando salimos de él.

Bienvenidos al maravilloso mundo de la programación para móviles…

Anuncios

5 comentarios so far
Deja un comentario

Talibaneando un poco: Se escribe móVil 😛

Y sí: programar para móviles te obliga a hacer muchas warreridas que van contra la filosofía de Java. Incluso usar preprocesadores de código es bastante normal cuando se desarrolla para diferentes perfiles y terminales..

Comentario por Julio Gorgé

O sea, que básicamente le llaman Java pero quieren decir C a pelo, ¿no? Pues así es como se ha programado durante un webo de tiempo (sin las “chorradas” de POO y otras cosas que sobrecargan la máquina), y tan ricamente que han funcionado las cosas. Y algunas incluso funcionan ahora mismo!

Comentario por Naranek

Interesante el artículo aunque me hubiera gustado algo más de profundidad en lo que se refiere al cálculo global, es decir, cuanto puedo hacer que me quepa en un móvil medio, cuantos gráficos puedo meter, animaciones, código… esto es, números.

Lo que realmente me asombra es que en dispositivos tan limitados se esté usando un lenguaje tan sobrecargado con la excusa de la compatibilidad cuando todos sabemos que la compatibilidad entre móviles está muy lejos de la realidad.

Espero que sigas con la línea de programación de juegos de móviles y que te mojes un poco más, no estabas trabajando en gameloft?

Comentario por javi

Una cosa más, no sé si será por memoria para la aplicación, pero mucho contenido se puede generar o almacenar de forma eficiente, no tienes más que ver algunos ejemplos de intros 4kb o 64kb (http://www.pouet.net/prod.php?which=13017,http://www.pouet.net/prod.php?which=18252 por citar algún ejemplo).

Yo mismo he creado algunos juegos en 4kb y 8kb:
-http://blep.blogspot.com/2005/12/resultados-compo-stratos-48h.html (RTS 😛 en 8kb con música y efectos de sonido)
-http://blep.blogspot.com/2005/05/cuby-2.html (FPS en 8kb)
-http://blep.blogspot.com/2005/05/48h.html (juego de habilidad en 4kb)

no son gran cosa, pero algo se puede hacer en poco espacio 🙂

Comentario por javi

yo por algún experimento propio y más que nada por un amigo que trabaja haciendo juegos para móviles, creo que te has quedado corto y todo xD

· Para optimizar memoria y algo de velocidad al no sobrecargar el stack de llamadas, nada de 200 métodos y todo ordenadito: todo en una misma clase, y si te cabe en 4-5 funciones mejor que mejor.

· Gifs optimizados al maximo, con el numero exacto de colores (si consigues cambiar alguno por otro menor y pasas por ej. de 64 a 48 colores eres la bomba).

· Si no caben los gráficos, nada de sprites completos para las animaciones: Los troceas y por código la animación: 2 piernas en distinta posición + un cuerpo ocupan menos que 2 sprites enteros moviendo las piernas.

· Emplear los bytes como 8 flags (jugando con ANDs y ORs), o los integer para mas, etc. El booleano como si no existiera.

A mi personalmente es precisamente lo que mas me gusta del j2me, que esta tan tan limitado, que cualquier cosa que consigues hacer da una satisfacción fabulosa 🙂

Eso si, como bien mencionas, es una vergüenza que se llame “Java 2 Micro Edition” cuando de java no tiene mas que la sintaxis básica, y la compatibilidad no es muy allá y diferencia de rendimiento a veces es notable.

Comentario por Kartones




Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s



A %d blogueros les gusta esto: