Ya va siendo hora de que hablemos de nuestra plataforma de desarrollo de juegos para móviles: Battlewizard.


Uno de los principales problemas a la hora de desarrollar un producto para teléfonos móviles, es que la gama y capacidades de los dispositivos es muy amplia. Aunque desarrollemos para móviles con soporte para Java (concretamente J2ME, CLDC 1.1 y CDC 1.1), hay que tener en cuenta que no es lo mismo desarrollar para un Nokia 3100 que para un Sony Ericsson S700, por ejemplo. No tienen la misma pantalla, no tiene la misma potencia de cálculo, ni soportan los mismos APIs (el S700 soporta 3D a través de JSR-184).

Este "problema de la fragmentación", nos afecta en muchos aspectos: hay que controlar el contenido que sale pantalla, ya que los tamaños de las pantallas, el número de colores y la resolución es variable, hay que controlar el tamaño de los juegos, ya que cada móvil soporta un tamaño máximo distinto, hay que controlar la ocupación del heap, hay que controlar el tamaño de datos persistentes (Record Store) almacenados... y un sinfín de aspectos más.

La solución tradicional a este problema suele ser desarrollar el mismo juego varias veces, aunque intentando reutilizar la mayor cantidad de código posible. Es decir: un equipo grande desarrolla un juego, pero repite su código para los distintos dispositivos que quiere soportar, intentando extraer todo el código común, y cambiando algunas partes para ajustarse a las peculiaridades de cada dispositivo. Esto genera es un montón de código repetido, propenso a errores y muy rígido ante el cambio.
Pensad que en las últimas fases de desarrollo de un juego es cuando surgen las mejores mejores ideas para hacer el juego realmente divertido, y en ese punto ya está casi todo el código escrito, así que hay que intentar que el código sea lo menos rígido posible.
Este enfoque de desarrollo requiere un equipo grande de personas, normalmente un programador para cada plataforma a soportar, y es el modelo que siguen algunas de las empresas más grandes de desarrollo de juegos para móviles, como por ejemplo GameLoft.

Otra opción que se está imponiendo, es la de desarrollar el juego completo en una única plataforma, y subcontratar a una empresa (habitualmente de bajo coste y en países en vías de desarrollo como China), la migración al resto de plataformas, que se encarga del trabajo sucio. A parte de consideraciones éticas (¿alguien se ha parado a pensar las condiciones en las que trabajan esos programdores?), este modelo requiere más dinero y una coordinación extra con la empresa que hará la migración. Y ni que decir tiene que una vez hecha la migración, el juego es intocable, y no podremos añadir o eliminar características en ciertos dispositivos.

La tercera opción se llama Battlewizard: con nuestra herramienta es posible se desarrollar el juego una vez, tener un único código fuente y que funcione en todos los móviles que se quieran soportar. Incluso un único programador podría generar 150 ó 200 versiones distintas sin mucho esfuerzo.
¿Magia? No, simplemente se tiene en cuenta el problema de la fragmentación desde el principio del desarrollo y se corta de raíz con las herramientas adecuadas.
¿Que quieres sacar tu juego para pantallas pequeñas (128x128) y grandes (240x320)? Pues defines ambos perfiles, añades el contenido gráfico teniendo en cuenta ambos tamaños, y generas la versión para todos los teléfonos que encajen en esos tamaños de pantalla.
¿Que necesitas sacar tu juego para móviles MIDP 2.0 y Nokia? Pues defines ambos perfiles, y al generar la versión se utilizará un motor específico para cada tipo de móvil.

Battlewizard está formado por varios componentes:

• Un entorno de desarrollo (IDE) sobre el que se aporta el contenido del juego: gráficos, fuentes, sprites, niveles, comportamientos de IA, perfiles de dispositivos a soportar, etc.
• Un API de programación para manejar el contenido generado con el IDE y ciertas tareas habituales en los juegos (detección de colisiones, renderizadores isométicos, etc.)
• Una implementación por cada uno de los teléfonos que soporta la plataforma: así tendremos la implementación de MIDP 2.0, MIDP 3.0, nokiaui, etc. Dependiendo de la versión que estemos generando, se utilizará una u otra implementación.
• Un middleware para juegos on-line: que permite descargar partes del juego una vez instalado en el teléfono.
• Un motor de scripting interno: para poder enviar código a través de GPRS/GSM a los juegos, y poder modificar el comportamiento de los agentes, o añadir nuevo contenido dinámico al juego (nueva lógica del juego, nuevos tipos de enemigos, etc.)

Battlewizard soporta cualquier juego para J2ME (ya sea CLDC o CDC), aunque estamos trabajando en las versiones para Symbian y Brew.

Pero como siempre, la magia no existe, y nosotros no somos menos: el principal inconveniente de este modelo es que los juegos deben tener en cuenta el mínimo común de todos los dispositivos que vamos a soportar. Por ejemplo, si nuestro juego debe funcionar en un abanico de teléfonos con un heap desde 500 KB hasta 4 MB, hay que programar teniendo en cuenta los picos de memoria en el dispositivo menos potente, aunque en los dispositivos más potentes no estemos aprovechando toda la memoria que nos ofrece. Es decir: la plataforma más pequeña limitará a las plataformas más potentes.

Bueno, como introducción yo creo que ya está bien. En los próximos posts hablaremos más sobre Battlewizard y todo lo que nos permite hacer.

Etiquetas: j2me, Unkasoft Platform