En nuestro trabajo diario intentamos desarrollar siguiendo las prácticas de eXtreme Programming, y entre ellas en especial el desarrollo guiado por pruebas o TDD. Y digo "intentamos" porque a veces no es fácil aplicar TDD para corregir bugs o trabajar con código que ya está escrito. Sin embargo, TDD funciona extraordinariamente bien para desarrollar nuevas clases, sobretodo si trabajas con Eclipse.

Vamos a poner un ejemplo tonto: tenemos que desarrollar la clase "Device", que entre otras cosas, tiene un identificador, una descripción, un constructor de copia y un método que nos dice si el dispositivo soporta un formato específico de audio (basándonos en una base de datos en UAProf o WURLF).
Podemos abordar este problema de tres formas distintas:

• La forma tradicional de hacerlo sería directamente: se codifica la clase, se usa desde donde sea, y los errores que se vayan detectando se corrigen como se puedan.

• Otra forma es codificando la clase y después programando un test unitario sobre esa clase. Hay un montón de frameworks que nos ayudan a programar test unitarios, aunque en nuestro caso usamos JUnit y J2MEUnit.

• Y por último, como decía Félix, podemos empezar la casa por el tejado y aplicar la metodología TDD: codificando primero las pruebas y después la lógica. Aviso que hay situaciones donde esto no tiene mucho sentido, y otras donde hacerlo así nos puede aclarar mucho la mente. Por ejemplo, si tienes muy claro el interfaz público que va a tener tu clase (porque ya has desarrollado antes algo parecido, o porque vienes de un diseño muy detallado), quizá no necesites codificar antes las pruebas. Sin embargo, si no tienes muy claro cómo va a ser la clase que tienes que hacer, empieza por las pruebas y verás como el resultado es mejor de lo que esperabas.

Bien, el caso que nos ocupa es que Eclipse nos ofrece una serie de herramientas que nos ayudarán a usar el TDD de forma poco traumática.


Empezamos codificando el esqueleto típico de la clase de pruebas con JUnit, y vemos como Eclipse nos marca una serie de errores de compilación. Como vemos en la imagen de la derecha, nos dice que la clase "Device" no se ha encontrado (logicamente, porque todavía no existe :). Haciendo clic sobre la marca de error del margen izquierdo, nos aparece una lista con posibles soluciones al error, y entre ellas: crear la clase. Así que dejamos que Eclipse cree el esqueleto de la clase "Device", y seguimos con nuestras pruebas.


Después de codificar dos métodos de pruebas estamos en las mismas: tenemos varios errores de compilación, ya que estamos llamando a métodos que todavía no existen.
Por ejemplo, en el test que prueba el constructor de copia, estamos llamando a un constructor que todavía no existe (además de un par de los getter), así que hacemos clic sobre la marca de error, y seleccionamos la opción "Create constructor Device(Device)". Con el resto de errores de compilación podemos hacer lo mismo, aunque habrá casos en que tendremos que completar o cambiar el tipo a ciertos parámetros que Eclipse no es capaz de deducir.

De este modo, casi podemos hacer que Eclipse nos vaya generando el esqueleto de nuestra clase de lógica basándose en las llamadas que hacemos desde la clase de pruebas.

Esto nos puede ahorrar bastante tiempo que dedicamos sólo a tareas de códificación zombie (la que se hace sin pensar, sólo para que los compiladores nos dejen vivir en paz).

Una vez que tenemos la prueba completa y el esqueleto de la lógica, podemos seguir codificando la lógica de la clase, hasta que todos los test pasen correctamente (aunque creo que Eclipse no puede ayudarnos demasiado en esto).

Etiquetas: agile, j2me, programación, TDD

Ahora que estamos internacionalizando (localizando) nuestros primeros videojuegos, empezamos a comprender en que acertamos y en que nos equivocamos cuando diseñamos nuestras herramientas. Nuestra experiencia nos decía que debíamos ir adaptando nuestras herramientas para que soportasen el ya conocido “Locale” formado por dos ISO, el ISO-639 para el lenguaje y el ISO-3166 para el país (ej. es_ES para español de España). Cuando planeamos nuestro desarrollo lo hicimos pensando que primero debíamos internacionalizar las cadenas de texto y más tarde los recursos de imágenes, porque pueden aparecer imágenes con textos que hay que traducir. En el papel todo es muy bonito y al final a parte de estas dos premisas nos hemos encontrado con varios problemas añadidos que estamos solucionando estos días: necesitamos un sistema para importar y exportar las tablas de traducciones de los recursos de cadenas de texto y los tamaños de los recursos traducidos pueden llegar a ser muy diferentes. Las soluciones que estamos añadiendo son crear un sistema de importación y exportación para poder editar las traducciones de las cadenas de texto en hojas de cálculo, más práctico que nuestro editor de cadenas que no es conocido por los traductores, y a más largo plazo implementaremos un gestor de layout para crear pantallas con texto e imágenes que pueda adaptarse correctamente a los cambios de tamaño, dentro de las limitaciones de las pantallas de teléfonos móviles. Actualmente soportamos la internacionalización de cadenas de texto y de recursos de imagen pero aunque suficiente para nuestros primeros videojuegos, se nos antoja mejorable en usabilidad y comodidad. Nuestra próxima release de Battlewizard incluirá al menos el sistema de importación y exportación de cadenas de texto y sus traducciones, y creemos en no mucho más tiempo, tendremos un editor de pantallas con layouts.

Etiquetas: Unkasoft Platform

Estamos pasando por momentos de nerviosismo ante el lanzamiento de nuestro primer juego para “jugones”, El Cuarto Sello, en varios países. Empezaremos en España en unos días, ya están los paquetes en los servidores de descargas y la publicidad preparada, luego le seguirán varios países de Latinoamérica y finalmente lanzaremos en otros países europeos. Ya tenemos El Cuarto Sello traducido a cuatro idiomas y seguramente prepararemos otras traducciones que nos están pidiendo los distribuidores. También son momentos de duro trabajo adaptando algunos juegos para advergaming y diseñando y desarrollando los títulos que lanzaremos a partir de Octubre y Noviembre.
Nuestras expectativas de ir entrando poco a poco este año en los mercados de juegos para móviles empiezan a vislumbrarse.
Por otro lado acabamos de lanzar una nueva versión de Early Adopter de Battlewizard que será instalada en varias empresas en los próximos 15 días. Las primeras pruebas de migración con nuestro primer Early Adopter, GPM han ido bastante bien. Hemos conseguido migrar un proyecto completo, tanto en contenidos como en código en unos 20 minutos aproximadamente, y lo probamos en varios móviles. Ahora nos queda ir mejorando la parte de portabilidad, que ya alcanza más de 200 móviles aproximadamente, pero que tiene que alcanzar la cifra de 350 o 400 durante este año.
Lanzar un juego, ya sea casual o un juego de jugones, implica un trabajo muy duro a todos lo niveles y cuando estás en la recta final estás como mínimo nervioso, expectante y siempre atareado.

Etiquetas: Juegos móviles, unkasoft

Dentro de las prisas por desarrollar un videojuego o por cerrar una entrega, algunos desarrolladores se encuentran que no han podido solucionar algunos bugs y deciden encubrir dichos bugs controlando las excepciones inesperadas o errores no controlados. Esta práctica que debería ser a ojos de cualquier desarrollador con experiencia una grave práctica, está extendida entre algunas comunidades de desarrolladores.

Es verdad que existe la posibilidad de evitar algunos errores no controlados de una tecnología no desarrollada por nosotros, por ejemplo swing de Java o una implementación de la KVM (J2ME) de algún fabricante de teléfonos, puede ser capturar dichas excepciones y evitar el problema. A veces no hay más remedio si no tenemos control sobre la plataforma que estamos usando. Pero cuando lo que estamos manejando es nuestra lógica y nuestro código, el capturar excepciones genéricas en todos los métodos de forma incontrolada puede llegar a ser una broma de mal gusto e inclusive una pesadilla:

/**
 * Controls "key pressed" events
 * @param key Key that has been pressed
 */
public void processKeyPressed(int key) {
    try {
        // Toda la lógica aquí
        // …
    } catch (Exception ex) {
        // No hacer nada
    }
}

Una pesadilla porque el tiempo de proceso de dichos bloques de excepciones es muy alto e implica que la detección de teclas, el proceso de la IA, los cambios de estado, el control de movimiento, la carga de recursos, el pintado de algunos elementos, la creación y construcción de personajes, el control de eventos y acciones, y en general todo aquello que se ejecuta en cada ciclo del juego, harán que vaya mucho más lento.

Poca potencia en los móviles, puede ser, pero normalmente deberemos vigilar las malas prácticas que a veces cometemos y que los equipos de desarrollo no deberían cometer.

Si en vuestros equipos de desarrollo detectáis esta práctica, normalmente usada por desarrolladores de poca experiencia o que no se preocupan por el resultado de su trabajo, deberéis atajarla de inmediato o podréis encontraros con problema de potencia a ultima hora. Mi recomendación es que hagáis revisiones de código con frecuencia haciendo que desarrolladores que no conozcan un código lo analicen y detecten estos tipos de mala práctica. Algunos desarrolladores se tomarán estas revisiones como algo personal, pero simplemente habrá que hacerles ver que es un tema meramente profesional y que hay prácticas que hacen que se complique mucho el desarrollo de un producto.

Etiquetas: j2me, programación

Estamos en pleno lanzamiento de nuestro primer gran videojuego y al mismo tiempo estamos lanzando al mercado un juego casual al que seguirán pronto varios más.

Nuestra mayor sorpresa respecto al mercado desde que empezamos con Unkasoft es lo rápido que puede cambiar y la necesidad de adaptación continua que necesitamos.

Hace apenas dos años, cualquier videojuego que llevásemos a los distribuidores y operadores, habría tenido bastante éxito por la necesidad de contenidos del mercado. Actualmente, muchos hemos entrado de golpe y porrazo a cubrir dicha demanda y hemos saturado un poco el mercado de juegos “mediocres”. Se ha impuesto la fuerza de la marca conocida y del juego casual, y los operadores y distribuidores son verdaderos esclavos de la marca y poco valoran la calidad de los contenidos que distribuyen y venden. El mercado está lleno de agentes mixtos como los desarrolladores-distribuidores que no hacen más que ver competencia en todos los lados y que se matan por meter sus catálogos en los operadores a cualquier precio. Ya se empieza a hablar de la necesidad de ver juegos de calidad, pero lo que estamos viendo son lanzamientos de juegos con marca y la calidad sigue siendo algo lejano.

Nosotros hemos hecho una apuesta difícil, hemos creado calidad y nos hemos lanzado directamente sin marca a convencer a los jugadores de las posibilidades de sus móviles y allí donde creemos que venceremos puede que esté nuestra mayor debilidad: ¿Quiere el jugador de videojuegos para móvil un gran videojuego de calidad? Nosotros apostamos porque el juego de calidad en el móvil puede ser jugado por los grandes jugones en ciertos tiempos muertos o complementando a las grandes plataformas de videojuegos, y que a la vez puede abrir nuevas puertas a los jugadores casuales. Pero como siempre hay que pelear en varios frentes, también disponemos de juegos casuales de un uso corto, y más fáciles de manejar para aquellos no iniciados en el mundo de los videojuegos, pero sin dejar de mirar por la calidad y diversión.

Creo que el mercado necesita calidad en todos sus juegos y no caer en los errores de otras plataformas como “sólo importa ingresar dinero a toda costa sin importar la calidad, diversión o el jugador”.

Etiquetas: Juegos móviles