Estaba leyendo el blog de DevZing sobre desarrollo de videojuegos y me hizo reflexionar.
Uno de los mayores peligros que tenemos los testers es “la contaminación”, es un aspecto que repercute directamente en el equilibrado del producto.Hay que diferenciar, pruebas para detectar bugs (ya hablaremos seriamente en otro momento) de equilibrar un juego.
Normalmente se crea una base donde el juego está teóricamente a punto, posteriormente, cuando ya se han revisado los bugs, se equilibra sobre emuladores y finalmente se testea por personas ajenas al proyecto. Estos últimos, si que juegan, el resto han estado haciendo prueba tras prueba.
Otro tema es el mercado hacia el que esté dirigido, móviles, consolas, Pc…El diseño y pruebas es diferente en cada caso. No es lo mismo validar una consola que un terminal móvil.
Para ello una de las opciones es tener un equipo de testers y un conjunto de beta-testers, pero esto en la mayoría de las empresas no suele ocurrir, más trabajadores = demasiado gasto…
Es como todo, hay muy buenas ideas y también buenas metodologías pero en mi opinión no todas son aplicables al 100%, me explico, hay que ser realistas a la hora de ver la duración del proyecto, lo que suele ocurrir habitualmente, ya que estamos en un mercado que no permite desarrollos de más de 45 días si realmente quieres estar dentro.
Para evitarlo se puede tener preparada una plantilla con las baterías generales de pruebas (los programadores también tienen que decir por aquí), con la finalidad de probar aspectos que puedan ser comunes en los juegos, véase menús, opciones, módulos de audio etc...
Y una batería de pruebas concreta, agrupada por géneros por ejemplo, pruebas diferentes para un Arcade que para un juego de estrategia.
Ésto evita en un alto porcentaje probar aspectos del juego que no tienen relevancia, además, probamos aquellas partes que más le interesa vigilar al programador.
Otro de los aspectos que hay que tener en cuenta es el tipo de juego, si es casual o hardcore, el contenido y la complejidad que tenga, según esto también haríamos las pruebas de IA: no se puede probar en tan sólo un par de partidas que cada componente tenga el comportamiento que se espera. Habrá diferencia entre si es un Pac o un Cuarto sello la diversidad de los comportamientos y estados hace que se realice un análisis más exhaustivo.

Etiquetas: QA

Un dato importante acerca de Battlewizad es que puede ejecutarse bajo cualquier S.O. que soporte Java 1.4 o superior; esta caracterísitica le hace adecuado para cualquier usuario, use Windows, Linux o incluso Mac.
En este post cubriremos la ejecución de Battlewizard sobre una plataforma MacosX Tiger.
Cualquiera que utilice habitualmente MacosX sabrá que existen ciertos detalles importantes bastante diferentes de otros sistemas operativos; porejemplo, las barras de menú se encuentran siempre en la parte superior de la pantalla, justo al lado de la manzana. Con unos sencillos ajustes podemos dar a nuestra aplicación Java un look and feel nativo de modo que los usuarios de MacosX puedan instalar y ejecutar esta aplicación sin ser consciente de que están ejecutando una aplicación multi-plataforma.

Es importante darse cuenta de que Battlewizard contará con un lanzador para los sistemas MacosX que hará uso de todos estos temas.

1.- Usando JVM sin ajustes

Si lanzamos Battlewizard con una maquina JVM sin ajustes, tendrá el siguiente aspecto:



2.- Colocando la barra de menús en su sitio

Haremosuso de algunas propiedades de sistema de JVM para conseguir esto; simplemente añade el siguiente argumento a la linea de ejecución de jvm para el lanzamiento de battlewizard:

-Dapple.laf.useScreenMenuBar=true

Y el resultado es el siguiente:


Se puede ver como labarra de menús ahora está en la zona superior.

3.- Cambiando el nombre de la clase....

Como se puede ver en la última imagen, la barra de menús descansa donde debe, pero el nombre de la aplicación es el nombre completo de la aplicación, junto con sus paquetes.
Eso carece de estilo, así que lo cambiamos para poder ver el nombre en ese punto.
En este caso, usamos una opción de jvm especial para MacosX en vez de una propiedad del sistema:

-Xdock:name="Battlewizard"

Y aquí llega el resultado:


4.- Añadiendo un a entrada "About" en el menú del sistema

No es realmente importante, pero todas las aplicaciones MacosX tienen uno de esos así que... por qué no nosotros?
Usando la propiedad del sistema:

-Dcom.apple.mrj.application.apple.menu.about.name=Battlewizard

nos permitirá ver la siguiente opción de menú:


JVM por defecto habilita el Double Buffering para todos sus gráficos. El resultado es una animación más suave y eliminación de parpadeos.
MacosX usa un engine gráfico, llamado Quartz 2D, aprte del framework gráfico principal; es un engine de dibujo en 2D avanzado independiente de resolución y dispositivo. Sus potentes características incluyen capas de transparencia, dibujo basado en paths, offscreen rendering, gestión avanzada del color así como creación, visualización y parseo de documentos PDF.


Este engine siempre realiza Double Buffering así que, si no lo desactivamos en Java, tendremos un doble buffering de un dobre buffering. Funcionar, funciona, pero no veremos mucha mejora y en cambio si que notaremos un descenso del rendimiento.

Para poder deshabilitar el doble buffering de Java, usamos la siguiente propiedad del sistema:

-Dawt.nativeDoubleBuffering=true


6.- Otras opciones

Dos opciones más pueden usarse para cambiar nuestra aplicación y hacerla más a tono con MacosX.

-Dcom.apple.mrj.application.growbox.intrudes=false

La opción de arriba hace que las aplicaciones respeten la "zona de crecimiento" de una ventana de MacosX; en caso contrario, los componentes podrían invadir esa "zona de crecimiento".


-Dcom.apple.macos.smallTabs=true

La última de las opciones es para ajustar el tamaño de las pestañas. Es difícil hacer diseños GUI para aplicaciones multi-plataforma si quieres establecer con precisión el tamaño y posición de los componentes. Un obstáculo es que el tamaño de las fuentes es diferente en las distintas plataformas. Apple te permite elegir entre Pestañas grandes o pequeñas, siendo por defecto las primeras.

Conclusión

Aunque Java es un lenguaje de desarrollo multi-plataforma, debemos ser conscientes de que cada una de estas plataformas tiene pequeños detalles que pueden ser activados. Es muy útil conocer cómo cambiar estas caractéristicas con el menor esfuerzo posible.

Etiquetas: Unkasoft Platform

Hola, soy Jorge del departamento de QA en Unkasoft y me gustaría contaros un poco sobre las tareas habituales que desarrollo a lo largo de un día de trabajo.

Espero que ya conozcáis algún juego de Unkasoft; ‘El Cuarto Sello’ o ‘IsoRoller’ sino, no es mala idea que juguéis al próximo, transmite misterio con sus gráficos de gran calidad, genera más adicción en cada nivel, quieres llegar al final…!! Esperamos que os guste.

Ahora estamos en plena fase de producción, en este momento estoy probando ése próximo juego, para que en los próximos días quede equilibrado y a continuación mi misión será validarlo en diferentes terminales para que se pueda garantizar que es compatible con casi 300 modelos de móvil.

Por otro lado también realizamos tareas de pruebas y calidad sobre la plataforma Battlewizard, ejecutando las pruebas funcionales, en parte de manera manual y en parte de forma automatizada con herramientas Open-Source como Marathon, que complementamos programando scripts en Python. Actualmente estamos en proceso de automatizar todas las pruebas funcionales posibles, hasta el momento hemos cubierto el 80% de ellas en nuestro Smoke-Test, el restante lo estamos investigando con otras herramientas.

Todo ello lo iremos comentando en próximos post.

Etiquetas: QA

Desde que empezamos nuestra serie sobre SCRUM, nos han llegados algunos correos vuestros preguntando sobre eXtreme Programming. ¿Seguís usando XP? ¿Se pueden usar XP junto con SCRUM? ¿En qué lugar quedan las prácticas de XP dentro de SCRUM?

Lo primero que hay que tener claro es qué es cada cosa:

• eXtreme programming: es una metodología de desarrollo formada por un conjunto de prácticas de programación (y algunas de planificación). Está orientado a escribir un código lo más adaptable al cambio y libre de errores posible.
• SCRUM: es una metodología de planificación y seguimiento de proyectos (de software, de ingeniería civil o de jardinería :) con prácticas orientadas a la gestión de equipos, tareas,
  funcionalidades, etc. No explica cómo tienes que escribir tu código (¡en jardinería no se escribe código!) sino cómo organizar los equipos y en general el tiempo para llegar a un buen puerto.

O sea: cada cosa para lo suyo.
Gracias a SCRUM conseguimos hacer un seguimiento continuo del proyecto, adelantando las sorpresas desagradables, para que nos de tiempo a reaccionar ante ellas. Conseguimos crear un buen ambiente de trabajo, dando a cada uno sus responsabilidades, e intentando no crear tensiones entre el equipo (aunque algunas son inevitables).

Sin embargo, si sólo usásemos SCRUM para gestionar el proyecto,no tendríamos sin ningún control en toda la parte de programación. ¿Cómo debemos escribir el código? ¿Qué tareas debemos hacer antes de codificar? ¿Y después? Aquí es donde entra en juego XP. Con eXtreme Programming tenemos una metodología ágil para programar, que encaja perfectamente con la filosofía que propone SCRUM. Quizá por esto último, el tandem SCRUM + XP se ha empezado a aplicar en varios proyectos de Microsoft e incluso en alguna empresa de videojuegos.

Así que todo lo que hemos contado de SCRUM lo intentamos combinar con las siguientes prácticas de XP:

• El juego de la planificación: es más o menos lo que ocurre durante la planificación del sprint: el product owner propone funcionalidades a desarrollar, y el equipo de desarrollo las estima en horas de trabajo.
• Entregas pequeñas y frecuentes: por esta razón hacemos sprints de 1-2 semanas en vez de los de 30 días de propone SCRUM.
  
• Historias de usuario: más o menos las distintas funcionalidades que apuntamos en el product backlog son historias de usuario.
• Diseño simple: intentamos programar siempre el mínimo código posible que implementa una funcionalidad, sin adornos ni futuribles.
• Pruebas unitarias: seguimos escribiendo nuestras pruebas antes que el propio código, al menos cuando es posible.
• Refactorizaciones: nuestro código está en continua evolución, sobre todo para intentar simplificarlo y clarificarlo.
• Integración continua: hacemos versiones frecuentes y automáticas, lanzando todas las pruebas.
• Semana de 40 horas: no tiene sentido intentar crear un buen clima de trabajo si se exprime a los trabajadores.
• Cliente in situ: nuestro product owner está siempre disponible para cualquier duda.
• Estándares de programación: intentamos seguir la guía de estilo de Sun.

Pero hay algunas que hemos tenido que dejar a un lado:

• Programación en parejas: sólo trabajamos en parejas para solucionar problemas o para dar apoyo puntual. SCRUM no limita este aspecto, ya que durante el daily scrum, dos programadores pueden asignarse a una misma tarea si quieren hacerla juntos, pero la verdad es que nosotros no lo estamos haciendo, excepto cuando alguien está atascado con algún problema.
  
• Propiedad colectiva del código: no es que ahora tengamos módulos privados que sólo su creador puede tocar, sino que intentamos asignar distintos responsables a cada parte del código. Así, cualquiera puede cambiar cualquier código, pero el responsable de ese código debe dar su visto bueno o al menos saber de va el cambio.

En definitiva: SCRUM por si solo se puede quedar cojo, ya que no da pautas específicas sobre cómo abordar la programación, así que combinándolo con eXtreme Programming conseguimos una metodología ágil mucho más completa.

Etiquetas: agile, SCRUM

Hoy debe ser el día de las noticias de SonyEricsson, porque me están llegando todas, aunque algunas ya tengan unos días.

Por un lado me cuenta Félix que SonyEricsson saca su versión de JUnit para J2ME. Una buena noticia, ya que teníamos un gran vacío en este campo.
Nosotros llevamos tiempo usando J2MEUnit, aunque no nos acaba de convencer. El framework en sí ocupa cerca de 20 KB, así que con archivos con datos para las pruebas, la lógica a probar y la lógica de las propias pruebas, andamos bastante justos para móviles pequeños (con un JAR máximo de 64 KB).
Además, hace un par de meses me enteré de otro nuevo xUnit para J2ME: el JMUnit. El nombre me gusta (: pero todavía no he tenido un rato para ponerme a probarlo y decidir cual de los dos es mejor.
Y con la llegada del nuevo framework de SonyEricsson, tengo otro más que probar. Acostumbrados a la calidad del software de la gente de SonyEricsson, estoy seguro que no va a defraudar. Bueno, a ver si en el próximo sprint consigo colar alguna tarea para probarlos.

Por otro lado, me entero también que SonyEricsson se une al proyecto Eclipse para aportar plug-ins orientado a desarrollo para J2ME. Si la anterior era una buena noticia, esta es casi mejor. Tener los toolkits y herramientas de SonyEricsson integrados en Eclipse es un sueño para nosotros, que trabajamos con Eclipse por un lado y con las herramientas de Sony de forma separada. Dentro de poco, abriremos el entorno de Eclipse y sólo con eso podremos hacer todo nuestro trabajo diario.
Esperemos que todo esto llegue a buen puerto y vayamos viendo como mejoran poco a poco las plataformas de desarrollo para móviles.

Etiquetas: j2me, TDD

La publicidad en teléfonos móviles continua en el candelero, más y más gente se siente atraída por ello. Creo que es un síndrome post-vacacional, se empiezan a coleccionar fascículos, clases de idiomas, y también publicidad en nuevos medios. No obstante, las ideas para este medio siguen estancadas.

A pesar de que las posibilidades de creatividad son infinitas, continua el uso de inserción de códigos promociónales en los paquetes de productos, en los que los clientes debe enviar un SMS indicando su código y se les informa de si han obtenido un premio.

Ejemplo de ello, es el lanzado recientemente en una bolsa de aperitivos -he censurado nombres para evitar problemas-:
"Tras adquirir el producto XXXXX , deberás enviar un SMS al XXXXX (coste del mensaje 0,90 euros + IVA) con la palabra TUPREMIO seguido del código de 12 dígitos y entrarás a formar parte del sorteo....”

Las teorías parecen venirse abajo, cuando se ven ejemplos de compra por un euro unos snack y paga otro euro para participar en el sorteo. Si la panacea de que el cliente subvencione la campaña se nos queda corta, llega el momento crucial de introducir un código de 12 dígitos -gracias a Dios tendrán paciencia-.
La idea debe ser ligeramente distinta, cuando no se desea competir con la O.N.C.E. celebrando sorteos. Un premio puede ser una parte de la promoción, pero no la promoción en sí.

Recientemente ha sido editado el libro Mobile Marketing de Alex Michael y Ben Salter, el cual he leído en busca de ampliar ideas de publicidad en los terminales móviles. Mi sentimiento tras ello es el mismo que mis amigos sintieron con Piratas del Caribe 2...
Los autores del libro realizan un estudio de todo tipo de aspectos del mundo de las telecomunicaciones, pero arrastra una falta de esencia e ideas enfocadas a la publicidad.

Dentro de las explicaciones prolijas del libro, se extraen algunas notas interesantes:

• Potencia de este nuevo medio; las posibilidades de segmentar la publicidad, por edad, localización, etc. son increíbles.
• Tasas de respuesta a la publicidad enviada por SMS (proporcionada por el libro):

94% de los mensajes son visualizados
62% de los anuncios son recordados
22% de envíos a conocidos (marketing viral)
18% de respuesta

• Costes: Al contrario que la publicidad en TV, radio, revistas... actividades para móvil tienen un relativo, bajo coste.
• Posibilidades de medir la respuesta, siempre se puede mejorar las campañas al disponer de tan amplia información.
• Wireless Advertising Asociation (WAA), interesante organismo que están lanzando iniciativas como: -Es tan importante como el IAB en Internet-

Creación de estándares para los anuncios
Proteger la privacidad e intereses de los usuarios
Mediciones de las campañas

• Código de buenas prácticas definidas -que son independiente del medio para la publicidad- : Legal, Decente, honesto, confiable, basado en el permiso del usuario, responsable y respetuoso
• Comando STOP. Comando único para dejar de recibir publicidad, si el usuario no ha dado su permiso y le enviamos publicidad debe ser sencillo anularla.

La teoría para el modelo de negocio que ofrecer a los anunciantes o agencias de publicidad, también sigue sin cambios:

• Cuota de arranque.
• Cuota mensual de mantenimiento.
• Pago de una cantidad por el contenido móvil que se baja el usuario (juegos, salvapantallas…).

Recientemente la alegría me la dieron nuestros amigos de HandyGames, creando un modelo gratuito de juegos móviles para el usuario. Esperemos que vengan más ideas igual de creativas.

Etiquetas: advergaming