domingo, 23 de enero de 2011

Sonidos

Uno de los aspectos más importantes, a mi entender, de un videojuego, es el sonido. Y me refiero lógicamente tanto a la música como a los efectos que acompañan la acción.

En casi todos los análisis que se hacen de videojuegos en revistas especializadas (véase vandal) se incluye una puntuación para este apartado. Sin embargo, me da la impresión de que realmente los jugadores no llegamos a ser conscientes del gran peso que tiene el sonido para formar nuestra visión subjetiva de si un videojuego nos gusta o no. Al final acabamos hablando de los maravillosos gráficos, las espectaculares escenas de acción, el novedoso sistemas de control, o lo adictivo de la mecánica. Pero no de que Super Mario nunca hubiese sido súper si no sonase como un silbato al saltar.

Si nunca lo habéis probado, coged un juego de guerra estilo Call of Duty, y jugad durante un rato sin sonido. Notaréis un significativo empeoramiento de la experiencia de juego (a no ser que juguéis siempre sin sonido, claro).

El último ejemplo de juego que para mí ha explotado a la perfección su apartado sonoro es Bejewlet Blitz, uno de esos jueguitos que se han hecho mundialmente famosos a través de Facebook (y al que reconozco estar enganchado). En sí el juego es bastante simplote. Uno de tantos adictivos descendientes lejanos del tetris. Pero en este caso, además, los efectos sonoros consiguen aumentar la tensión y el interés, e incluso motivar al jugador a querer cada vez más.

Dicho todo esto, hace poco llegó para mí el momento de encargarme del apartado sonoro del juego que estoy haciendo para aprender a manejarme con Android. La verdad es que se unían en este punto dos factores; por un lado, como acabo de mostrar, la importancia que le doy a este apartado; por otro, mi absoluta incapacidad y desconocimiento en este ámbito: ni sé crear sonidos, ni tengo las herramientas para hacerlo.

Menos mal que Internet es una fuente inagotable de información y recursos. Tras unos días buscando herramientas y paseándome por Webs de sonidos que requerían registro, he dado con SoundsResource.com. Un repositorio de efectos de sonido bastante amplio, con archivos bien clasificados, gratuitos, y buscables, que me ha resuelto la papeleta. En esta Web he encontrado los efectos que necesitaba para dar un toque más profesional a mi desarrollo. 

Supongo que existirán muchas otras Webs del estilo, pero esta es la que me ha salvado en este caso, así que la recomiendo para aquellos que, como yo, necesiten efectos de sonido, pero no se vean con fuerzas para crearlos.

sábado, 15 de enero de 2011

Encuestas

Los departamentos de informática, aunque a veces no nos demos cuenta, nacen con una evidente y destacada vocación de servicio al usuario. Nosotros no somos el fin, sino el medio. Una herramienta que la empresa, sea cual sea su área de negocio (administración, salud, energía, investigación, docencia...), pone a disposición de sus empleados para facilitar la consecución de sus objetivos.

Muchas veces los departamentos de informática nos perdemos en nuestras pequeñas guerras tecnológicas, y nos olvidamos de que nuestra finalidad principal es facilitar el trabajo de los usuarios. Esto puede llevarnos a perder el rumbo y a provocar en ellos una perjudicial sensación de insatisfacción con nuestros servicios.

Me refiero a que es habitual encontrar a todo un equipo centrado en implantar un maravilloso entorno de desarrollo, con un servidor de integración continua, herramientas de control de código, fastuosos servidores de aplicaciones y demás parafernalia, mientras un usuario lleva varios días esperando que se le cree una cuenta de correo electrónico, que es lo único que necesita para trabajar.

Como proveedores de servicios informáticos es nuestro deber adecuarnos a las necesidades de los usuarios y hacer todo lo posible por satisfacerlas, ya que ese es el verdadero indicador que nos dirá cómo estamos haciendo nuestro trabajo.

Y no existe mejor forma de saber hasta qué punto está satisfecho el usuario que preguntarle a él mismo. Ahí es donde las encuestas pueden ser útiles para nosotros.

Recoger información de un grupo de personas es una tarea muy difícil. Si uno se pone manos a la obra se encontrará con gente para la que nunca es un buen momento, gente que prefiere no opinar, gente que responde cualquier cosa para cumplir, gente que piensa que dar su opinión es una tontería... el caso es que al final obtener la información lleva lo suyo, así que es muy importante hacer las cosas bien para conseguir resultados útiles.

Así que hay una serie de claves que se deben tener en cuenta para tener éxito con los sondeos a usuarios.

Lo primero, y más importante: ¿Qué quiero saber? Esta es la clave y, posiblemente, el punto en el que debamos detenernos más tiempo. Aunque suene redundante, tenemos que saber qué queremos saber. Y tenemos que saberlo de forma concreta, claro. No vale con decir que quiero saber qué es lo que el usuario piensa de mi trabajo; hay que ser más concretos, ¿qué aspectos de mi trabajo quiero que se valoren? Pongamos un ejemplo.

- Quiero saber si mis usuarios están satisfechos con el tiempo de respuesta a sus peticiones.
- Quiero saber si mis usuarios están satisfechos con la calidad de las respuestas.
- Quiero saber si mis usuarios están satisfechos con el trato ofrecido por mi equipo.
- Quiero saber si mis usuarios están satisfechos con las herramienta puesta a su disposición para notificar incidencias.
- Etcétera, etcétera.

Tan importante como identificar qué quiero saber es reconocer qué no me interesa, para ajustar lo máximo el tiro. Si estoy valorando la posibilidad de cambiar mi gestor de incidencias por una herramienta más barata, pero que elimina alguna funcionalidad, como por ejemplo la notificación por correo, en lugar de la última línea lo adecuado sería preguntar: ¿sigue usted las notificaciones por correo electrónico de sus incidencias? ¿echaría de menos esta funcionalidad? Quizá nos sorprendamos al ver que la mayoría de los usuarios tienen marcados como spam lo correos del gestor de incidencias.

Lo siguiente es tener claro que al usuario hay que ponérselo fácil. Olvidémonos por supuesto de pasarnos a hablar cara a cara con cada uno de ellos, o de pasarles un cuestionario en papel. Al día siguiente todos estarían perdidos entre montañas de formularios. Hoy las encuestas online son la mejor opción. Colguémosla, demos acceso sin contraseña, y dejémosla ahí durante un periodo de tiempo suficientemente grande. Y, por supuesto, promocionémosla; empujemos a la gente a perder 5 minutos de su tiempo. Seamos pesados si es necesario, ya que este tipo de peticiones suele caer en saco roto la primera vez. Y si todo esto falla, sorteemos un iPad entre los participantes. Nada mejor para que te hagan caso.

Y por último, e importántisimo también, esa gran palabra, el feedback. Demos feedback. Ya que los usuarios han perdido un rato en satisfacernos, dejémosles conocer los resultados, comentemos las conclusiones, y hagamos públicas las actuaciones aprobadas. Todo dentro de plazos razonables. Es muy probable que el ver que sus opiniones han significado cambios percibibles les impulse a participar en próximas ocasiones.

Y ahora, digan, ¿les ha parecido interesante el post? ;)

jueves, 13 de enero de 2011

Configurar barras de progreso en Android

En estas primeras horas de mi andadura con Android me he encontrado un gran problema a la hora de trabajar con las barras de progreso.

Como ya comenté, la idea que tengo entre manos es desarrollar un juego para foguearme con la tecnología, y necesito mostrar en pantalla varias barras de progreso. Lógicamente interesa que no sean todas iguales, para que se pueda identificar cada una de ellas con lo que expresa. El caso más típico es el de mostrar la vida con una barra roja, por ejemplo.

El primer paso es definir el tipo de barra de progreso. Por defecto Android trabaja con barras circulares (o barras paradójicas). Para utilizar barras de verdad, tenemos que indicar explícitamente el valor del atributo style del elemento ProgressBar del fichero de layout que estemos utilizando (main.xml, o el que corresponda).


Sí, el valor es así de raro, y agradezco enormemente a Daniel Yankowsky el aporte.

Lo siguiente que nos plantearemos normalmente, ahora que tenemos la barra, es cómo cambiarle el color. El amarillo sobre gris está muy bien, pero hay todo un mundo más allá. En este caso vamos a necesitar crear un nuevo fichero, que ubicaremos en la carpeta res/drawable, y llamaremos progress.xml (por poner). El fichero tendremos que crearlo directamente desde el sistema operativo, y en él podemos definir con mayor detalle el estilo de la barra de progreso, mediante el siguiente código:



En este caso tenemos dos items, que se corresponden con el fondo y el progreso de la barra. Se podría añadir otro elemento secondaryProgress si lo necesitásemos. Para cada elemento se configura el radio de las esquinas, para que queden redondeadas, y se añade un gradiente, para que el color no sea uniforme, sino una degradación de los tres indicados. El ángulo indica cómo se aplica el gradiente (0 para hacerlo en horizontal, y 270 para vertical). Respecto al color, se identifica mediante ocho dígitos hexadecimales, donde los dos primeros indican la transparencia.

Existen otras opciones como poner relleno, y están bastante bien descritas aquí.

El último detalle que puede ayudar a personalizar la barra es el tamaño. En mi caso me interesaba presentar barras más finas para determinada información. Para conseguir este resultado nos vamos de nuevo al fichero de layout, y añadimos los atributos maxHeight y minHeight.



De esta forma conseguimos barras con distintas presentaciones. Como muestra, una captura (botones no me quedan ahora mismo).


Hope this helps!

Android TIP: refrescar recursos

En las últimas semanas he empezado a meterme en el mundo de Android con la idea de hacer algunas pequeñas aplicaciones, y poder publicarlas en el market.

Como punto de partida me he marcado el objetivo de crear un juego, y aprender así a manejarme con el entorno y herramientas de desarrollo. En futuros posts iré dando más detalles sobre el proyecto (si puede llegar a tener esa categoría). De momento, simplemente una pequeña ayuda para reducir tiempos de espera al trabajar.

Uno de los principales problemas que le veo al desarrollo para Android con Eclipse, mediante el plugin ADT, es que el emulador es bastante lento, sobre todo a la hora de arrancar, y en ocasiones puede hacerte perder la paciencia.

Si estás desarrollando una aplicación, y especialmente si es un juego, es normal que manejes ficheros de recursos, y concretamente imágenes. Y también es normal que las modifiques a menudo para ir metiendo mejoras en el apartado gráfico. Ante una situación de cambio en cualquier fuente del proyecto durante el desarrollo, siempre surge la duda de qué hay que hacer para que ésta se refleje en nuestra ejecución. ¿Compilo? ¿Redespliego? ¿Simplemente guardo? ¿Reinicio el ordenador?

Depende de con qué estés desarrollando. En el caso de Android, hasta donde sé, si haces un cambio en el código, simplemente tienes que volver a ejecutar la aplicación, pero no el emulador. Sin embargo, esto no es suficiente cuando el cambio se hace en un fichero de recursos. No vale ejecutar la aplicación, ni tampoco reiniciar el emulador, si no has refrescado antes la carpeta de recursos. Esto lo hacemos desde el explorador de paquetes, con el menú contextual.

Tras el refresco sí que podemos ejecutar de nuevo sobre el emulador que tengamos arrancado, y veremos que los cambios han sido aplicados.