Game Over

Acabé el proyecto, con ello también el Máster y mi estancia en Oviedo, así que básicamente esta es la última entrada en el blog. Gracias a los miembros de HCI por leer esto y por las buenas ideas aportadas.

Pantallas PDA

Estas son algunas capturas de pantalla del juego en la PDA. La interfaz gráfica es MUY sencilla.

Login

Inmediatamente después del login te muestra la pantalla para elegir una partida que tengas iniciada. Se muestra el nombre del juego y la fecha de inicio de cada partida. Puedes entrar a una de esas partidas o elegir iniciar una partida nueva.

Para iniciar una partida nueva eliges el juego y, de la lista de tus contactos, eliges con quien quieres jugar.

Una vez dentro de una partida, el mapa se muestra como se ve a continuación. Los textos no forman parte de la pantalla. Los he añadido yo a esta imagen con el fin de explicar la pantalla, pero no sé si sería buena idea que el juego los mostrara. Las posiciones de los puntos las obtengo a partir de las coordenadas geográficas con que se crea el juego, convertidas a coordenadas cartesianas y después a escala de acuerdo a la pantalla del dispositivo. La foto que se ve es la imagen con que se registra el jugador en el portal web. Esa imagen el jugador la puede cambiar cuando quiera desde el mismo portal. La posición de la imagen se muestra de acuerdo a las coordenadas GPS. También se muestra la posición de otros jugadores en la partida que estén conectados en ese momento. He fijado un timeout de 5 minutos, si el usuario no actualiza su posición en 5 minutos asumo que no está conectado.

Finalmente, esta pantalla en donde puedes ver el nivel en que estás, los puntos y recursos que tienes.

En los próximos días estaré trabajando en el resto de la documentación, manuales de usuario y esas cosas. Si alguien quiere probar el juego, lo que sería de mucha utilidad, le paso el fichero y una explicación más amplia de como funciona. Es necesario tener Windows Mobile 5 o superior porque estoy utilizando el GPS Intermediate Driver. Yo por ahora lo he probado en una iPAQ hw6945.

Conexión WiFi

Parece que ha quedado resuelto uno de los pendientes que me quedaba en la aplicación para el dispositivo móvil. Finalmente lo resolví mediante eventos cada vez que cambia el status de la conexión. La librería que revisa si el dispositivo tiene conexión a Internet tiene un background thread que lanza un evento cada vez que cambia el estado de la conexión. La interfaz de usuario recibe el evento y si el dispositivo está conectado reanuda las invocaciones a los servicios web.

Gestión de usuarios y contactos

Siguiendo alguna sugerencia de Tejo he implementado la gestión de contactos utilizando FOAF (Friend of a Friend). Ha sido un ejercicio interesante dado que luego de dar Web Semántica en el máster lo dejé registrado como un mito en mi cerebro. Así que ha valido la pena ponerlo un poco en práctica. Entonces las cosas han quedado implementadas de la siguiente forma. Como todo en el proyecto esto funciona mediante servicios web porque siempre necesito acceder desde dos clientes distintos, un portal web y la aplicación del dispositivo móvil. Entonces tengo publicados dos nuevos servicios, uno para gestión de usuarios y otro para gestión de contactos. Lo típico, registro de usuario, modificar datos, cancelar la cuenta y validar el login. En cuanto a la gestión de contactos, puedes agregar contactos (friends) y luego es con estos contactos con quienes puedes jugar partidas. En base de datos sólamente tengo la información relativa a la autenticación de usuario y en ficheros xml tengo la descripción del usuario en FOAF. En el resultado final me parecen interesantes dos cosas, la primera es que podrías registrarte cargando directamente tu fichero FOAF (evitando registrarte una y otra vez en distintas aplicaciones) y la segunda es que una vez teniendo la red de amigos de un usuario, podrían iniciarse partidas con sus conocidos, con los conocidos de sus conocidos y así a distintos niveles.

GPS

En las últimas semanas estuve (además de estar de vacaciones, desde luego) trabajando con el tema del GPS. Para empezar tengo ya implementado el "algoritmo radial" para saber si un punto está dentro de un polígono. Hasta ahora parece que funciona correctamente. He conseguido trabajar con el GPS Intermediate Driver utilizando el código de ejemplo que viene con el SDK de Windows Mobile y parece que funciona. Tuve algún problema porque aparentemente hay un error en alguno de los códigos (concretamente el método ParseDegreesMinutesSeconds de la clase GPSPosition) y entonces el GPS me ponía sobre el mar. Encontré las correcciones y ahora parece darme una coordenada con algún error de unos metros, lo que supongo será normal (ya no me pone sobre el mar én Gijón, ahora me pone sobre la piscina de la universidad). Quiero hacer más pruebas, pero el tiempo en Oviedo ahora dice que no es el mejor momento para andar por ahí probando el GPS. Así que por el momento pasaré a otras cosas y cuando el sol decida visitar Oviedo nuevamente retomaré las pruebas con el GPS y decidiré cuál será la mejor forma de manejar el error del GPS.

Juegos

Hola. Escribiré un poco sobre como serán los ficheros XML para definir los juegos. Los juegos están formados básicamente por estos elementos.

1. Sistema de puntuación.
2. Lugares. Que corresponderán a las coordenadas geográficas.
3. Personajes. El número de personajes define el número máximo de jugadores.
4. Recursos. Son objetos en el juego sobre los que se realizan acciones.
5. Niveles. En cada nivel se pueden definir recursos y puntos que el personaje debe tener para superar ese nivel.
6. Acciones. Una acción siempre es con un recurso y en un lugar. Las acciones posibles son las siguientes: hacer que un recurso esté disponible, comprar un recurso, alquilar un recurso, intercambiar recurso con otro jugador, perder un recurso, recoger un recurso.

Las acciones son lo más importante. En cada acción se pueden definir recursos y puntos que el personaje debe tener para poder realizar esa acción. Se pueden definir acciones opcionales u obligatorias. Y cada acción puede dar o quitar puntos al personaje. Las acciones también pueden tener un requisito mínimo en tiempo, es decir, algo que no puede suceder hasta después de un tiempo de iniciado el juego.

Dado esto, en el UC hablamos de las reglas del juego para el GeoMonopoly. Es posible comprar, alquilar propiedades, venderlas a otro jugador. Una idea (gracias a Jaime) para simular la cárcel fue que en determinado lugar el usuario recogiera un objeto que le impidiera hacer otras cosas, y para deshacerse del objeto tuviera que ir a un determinado lugar. De esta forma obligaríamos al jugador a moverse por los lugares del juego. Hablamos también acerca de la necesidad de darle al jugador alguna motivación para pasar por las propiedades que son de otro y para no apagar la PDA mientras recorre la ciudad. Por ejemplo, mientras el jugador no está jugando, no paga alquiler pero tampoco cobra el alquiler de sus propiedades.

Se aceptan toda clase de sugerencias.

Señales de vida

Entre terminar las asignaturas del máster, vacaciones y finalmente retomar el trabajo llevo un tiempo sin escribir aquí. Pero ahora explicaré en qué va este tema.

Estoy implementando un primer prototipo del motor de juegos principalmente con dos objetivos: comprobar que es posible definir los juegos en lenguaje XML y probar las reglas de los juegos. Tengo ya una versión del GeoMonopoly (se compran propiedades, se paga alquiler, ... ). En el caso del GeoMonopoly lo único que no veo muy claro como hacer es lo de subastar las propiedades, le daré más vueltas al tema. En los próximos días escribiré otro post con los detalles de como serían los ficheros XML para definir los juegos.

Análisis

Al menos por ahora, he completado la etapa de análisis de mi proyecto. Evidentemente irán surgiendo modificaciones más adelante, pero mencionaré brevemente los requisitos funcionales más importantes.

• Independencia del motor de juegos y los juegos. Los juegos se definirán con XML.
• Portal web para crear (modificar y eliminar) nuevos juegos y en ese mismo portal mediante algún mapa como GoogleMaps se hará la geolocalización los juegos.
• Gestión de contactos. Dado el riesgo que puede representar que una persona desconocida conozca tu posición geográfica en todo momento el usuario sólo podrá jugar con usuarios "conocidos".
• Los juegos son geolocalizados, los movimientos del jugador en el juego corresponden con los movimientos del usuario en el mundo real.
• Los juegos son multijugador.
• Los juegos podrán estar divididos en niveles, utilizar algún sistema de puntuación y el jugador podrá recolectar objetos durante el juego.
• El usuario tendrá que registrarse, tanto para jugar como para crear nuevos juegos.
• Persistencia. El jugador podrá salir temporalmente de una partida y volver a ella más adelante.

Otro juego: búsqueda del tesoro

Describiré otro posible juego con este motor, la búsqueda del tesoro. El objetivo final del juego es encontrar un tesoro que se encuentra escondido por algún lugar de la ciudad. Para llegar al tesoro necesitas tener ciertos objetos, por ejemplo, un mapa y una pala que te servirá para cavar y sacar el cofre. A su vez esos dos objetos pueden estar escondidos, por ejemplo el mapa puede estar escondido en un lugar cerrado con una llave. Antes de llegar por el mapa tienes que haber encontrado la llave. Así se puede enredar tanto como quiera.

Estos juegos se escribirán en XML, ya tengo más o menos pensado como, pero una de las próximas tareas es definirlo mucho más a detalle.

Monopoly Geolocalizado

La primer idea de un juego para este motor de juegos es una especie de Geo Monopoly. En este momento haré un resumen de como creo que debe funcionar este juego. Por supuesto se aceptan sugerencias para que algo funcione diferente e ideas de algún otro juego.

Basándonos en el tradicional juego de mesa Monopoly haremos una adaptación a un juego geolocalizado en donde las propiedades del juego correspondan a ubicaciones reales. El objetivo del juego es el mismo, ser el jugador más rico haciendo un monopolio de las propiedades en el juego. La diferencia es que para comprar la propiedad tienes que estar realmente en ella y cada vez que camines por una propiedad que pertenece a otro jugador, tendrás que pagar alquiler. Habrá que establecer un período para volver a pagar alquiler, de modo que si esto se hace por una ciudad y entras, por ejemplo, a un bar puedas permanecer ahí durante ese período sin estar pagando todo el tiempo.

Algunas cosas más que tienen que ser diferentes:

• No habrá dados. Las propiedades se pondrán en venta durante un período de tiempo determinado aleatoriamente. El primer jugador en llegar tiene derecho a comprarla, si decide no comprarla, la propiedad se subasta.
• El papel del banco lo hará el propio motor de juegos.
• El jugador recibirá una cantidad de dinero al iniciar el juego (1500€).
• Habrá un sitio marcado como el inicio del espacio del juego. Un jugador recibirá una cantidad de dinero (200€) al pasar por ahí. Deben pasar un determinado tiempo (digamos, dos horas) antes de volver a recibir el dinero al pasar por ahí. Además, ese dinero no se puede recibir más de un determinado número de veces por día (digamos dos).
• En el juego existirán espacios marcados como "Sorpresa". Esos espacios sustituyen a los espacios de "Casualidad" o "Arca comunal" en el juego de mesa. Cuando un jugador camine por esos espacios, el sistema decidirá aleatoriamente en función de probabilidades si el jugador recibe una carta (60%), si el jugador va a la cárcel (10%), si el jugador paga impuestos (10%) o si el jugador no recibe nada (20%). De la misma forma que la casilla de salida, tiempo mínimo para volver a recibirlo y un máximo de veces por día.
• La cárcel. En este juego el jugador podrá ir a la cárcel cuando al llegar al espacio sorpresa así se le indique. Si el jugador tiene una carta para salir de la cárcel puede utilizarla en ese momento. Al estar en la cárcel el jugador no puede comprar las propiedades por las que pasa, pero puede cobrar alquileres, comprar propiedades en subasta, comprar casas y hoteles y vender propiedades.

Para salir de la cárcel se me ocurren dos opciones: 1) simular el tiro de dados cada determinado tiempo o que el jugador tenga que ir al lugar físicamente marcado como cárcel y ahí simular el tiro de dados. Lo demás igual, utilizar una carta o pagar una multa.

El resto me parece que funciona todo igual: compra y venta de casas y hoteles, hipotecas y quiebra.

Estado del arte

En una primera etapa de mi proyecto he realizado una investigación sobre temas como:

• Motores de juegos para dispositivos móviles.
• Juegos para dispositivos móviles geolocalizados.
• Juegos geolocalizados.

En abril realicé esta presentación para el Second Conference on Usability Engineering organizado por el HCI.

Proyecto Fin de Máster

Este blog está dedicado a mi proyecto de fin del Máster en Ingeniería Web de la Universidad de Oviedo. El objetivo de este proyecto es desarrollar un motor de juegos geolocalizados para dispositivos móviles con cobertura de redes inalámbricas.