Taller de Sistemas de Información 3 Trabajo Obligatorio Primer Semestre Año 2007 1. Introducción El mundo de los video-juegos ha experimentado una revolución con la llegada de los llamados Massive Multiplayer Online Games [1] (MMOG). Las características de este género de video-juegos es permitir grandes cantidades de jugadores que cooperan/interactúan/compiten en un mundo virtual o real para cumplir los objetivos del juego. El nacimiento y desarrollo de este género se remonta a fines de los 80, principios de los 90. Mientras que cobró mayor protagonismo últimamente con la aparición de juegos como Ultima, World of Warcraft, Second Life, OGame, entre otros. A partir de su aparición se han desarrollado varios subgéneros, generalmente adaptaciones de otros géneros al ambiente de interacción masiva, como son: Massive Multiplayer Online First Person Shooter (MMOFPS), Massive Multiplayer Online Role- Playing Game, etc. O también nuevos y novedosos subgéneros como Massive Multiplayer Online Social Games, en donde se busca socializar más que cumplir una serie de objetivos. Ejemplos de estos juegos son Second Life o Home. Otro género de juegos que también empiezan a aparecer son los juegos basados en la ubicación física del usuario, también llamados Location-Based Games (LBG) [2], utilizando tecnologías de GPS. En este género el campo de batalla típicamente es una ciudad y los jugadores deben recorrerla cumpliendo determinados objetivos. Generalmente por las deficiencias en el servicio de comunicación inalámbrico que existe actualmente, estos juegos deben incorporar la opción de jugar desconectados como una realidad. Tanto los MMOG como los juegos basados en ubicación física, generalmente requieren de un sistema de información que mantiene el estado del juego y permite a los diferentes jugadores interactuar. Estos sistemas tienen fuertes requerimientos de escalabilidad dada la gran cantidad de jugadores que van a estar jugando simultáneamente.
Los clientes de dicho sistemas pueden variar dramáticamente en complejidad. Por ejemplo, en un MMOFPS se requiere un motor capaz de renderizar el mundo para que el usuario lo vea y escuche, mientras que para un juego basado en la ubicación física simplemente requiere presentarle al usuario una vista simple del estado del juego y transmitir coordenadas. En este contexto, el objetivo del proyecto a realizar es construir un prototipo de un MMOG con características de LBG. El juego se asemeja a una búsqueda del tesoro a nivel planetario. El juego plantea una serie de desafíos. Para cada desafío dos o más grupos de jugadores, distribuidos en el planeta, compiten por ver quien es el que llega antes a completarlo. Un desafío está compuesto de varios objetivos. Cada objetivo está asociado a una coordenada geográfica y plantea una problemática que debe ser resuelta en dicho punto del planeta. La idea es que los jugadores mediante dispositivos móviles vayan a dichos puntos y resuelvan la problemática. 2. Dominio de Problema Un desafío estructuralmente se lo puede ver como un grafo dirigido sin ciclos. Cada nodo del grafo representa una actividad. Las actividades representan: el inicio del desafío (no tiene aristas entrantes), un objetivo o el fin del desafío (no tiene aristas salientes). Cada desafío ofrece múltiples caminos para llegar del inicio al fin. Un objetivo tiene asociada una coordenada geográfica (latitud, longitud), una zona que incluye la coordenada (por ejemplo, Montevideo o París) y plantea una determinada problemática. Ejemplos de dicha problemática pueden ser: - Llegar a un determinado punto del planeta, validado a través del GPS disponible en los dispositivos móviles de los jugadores. - Descubrir un objeto ubicado en un determinado punto (ej. una plaza, un monumento, etc) - Responder una pregunta de algo que está en un determinado punto (ej. qué fecha dice la placa del monumento?) Cada grupo de jugadores es responsable de determinar por que camino, o caminos, va a intentar llegar a cumplir el desafío. Existen dos roles de usuarios: los ejecutores y los coordinadores. Los ejecutores están encargados de cumplir con los objetivos, o sea, son los usuarios con los dispositivos móviles que van a las coordenadas establecidas por cada objetivo y resuelven la problemática. Los coordinadores (existiendo uno por grupo) son los que se encargan de definir la estrategia a utilizar por el grupo y asignar los objetivos a los ejecutores. Cada grupo de jugadores debe de estar conformado al menos, de un ejecutor y un coordinador. Durante el transcurso del desafío, los coordinadores solo disponen de una visión parcial del grafo que conforma el desafío. Los objetivos visibles en dicha vista parcial son los únicos que el coordinador puede asignar, siendo que desconoce el resto. La visibilidad que tiene un coordinador está determinada por dos factores (ver figura): el grado de avance de su grupo (por camino) y los niveles. Los niveles plantean una forma de dividir los objetivos que conforman un desafío.
Para ir avanzando en el desafío los objetivos deben ser completados en forma secuencial, o sea, para poder completar el objetivo O 2 antes se debe de haber completado el objetivo O 1, de la misma forma, para poder completar el objetivo O 3 se debe haber completado el O 2. Inicialmente el coordinador tiene visibilidad sobre los dos primeros niveles de desafío. A medida que el juego avanza y su grupo logra completar todos los objetivos del nivel 1 por un determinado camino, su grupo obtiene automáticamente visibilidad sobre el nivel 3 para todos los posibles sub-caminos que deriven del camino completado. Por ejemplo, en la figura, el hecho de completar el objetivo O 3 hace visible el nivel 3 para ese camino. Dado que ningún otro camino ha completado el nivel 1, no cuentan con visibilidad sobre el nivel 3. En el caso de completarse O 4, los dos sub-caminos que derivan de él, en el nivel 3, pasarían a ser visibles. En el caso general, para poder tener visibilidad sobre el nivel x de un determinado camino, todos los objetivos del camino en el nivel x 2 deben haber sido completados. Los jugadores de un mismo grupo pueden chatear entre sí para poder realizar una coordinación más flexible. Existen dos modalidades de Chat: entre dos jugadores exclusivamente y entre todos los miembros de un grupo (salón de Chat). En el primer caso se debe asegurar que todos los mensajes que envía cada participante le lleguen al otro. Para poder iniciar un Chat ambos jugadores deben haber realizado el login al sistema. En el segundo, el jugador tiene la opción de participar o no del Chat. En el caso que esté participando le deben llegar todos los mensajes del Chat. 3. Arquitectura de Deployment Preliminar El juego consta de tres componentes fundamentales, a saber: servidor central, front-end ejecutor y aplicativo de coordinadores. El diagrama que se muestra a continuación representa una visión parcial de la arquitectura de deployment. En la realidad existen varios dispositivos móviles y varios coordinadores (uno por cada grupo). El servidor central lleva el estado del juego. El front-end del ejecutor le permite a estos jugadores realizar sus tareas: tomar objetivos, enviar las respuestas de la problemática de dichos objetivos, Chat, etc. El aplicativo del coordinador actúa como un
servidor, en lo que respecta a la coordinación de su grupo, y le permite al coordinador realizar sus tareas de coordinación. El juego plantea dos requerimientos no funcionales. Primero, los medios de comunicación entre los dispositivos móviles y los otros componentes no son confiables. Por lo tanto el ejecutor debe poder seguir trabajando en escenarios en donde haya una mala conexión o una desconexión total con el resto. Segundo, dado el número potencial de jugadores que pueden estar online simultáneamente, se prevé que el servidor no pueda atender todos los pedidos de sus clientes cuando estos los realizan. 4. Requerimientos Funcionales Mínimos A continuación se presentan los requerimientos funcionales mínimos por cada componente. Los requerimientos se presentan desde dos puntos de vista: desde el punto de vista del usuario final, que usa el componente, y desde el punto de vista de requerimientos que otros componentes establecen sobre el componente especificado. Cabe notar que los requerimientos entre componentes NO están completamente especificados. 4.1. Servidor Central El servidor central debe brindar el siguiente servicio a los administradores del juego: - Iniciar un desafío, siempre y cuando existan dos o más grupos de jugadores anotados al desafío. La implementación de todos los servicios administrativos como definición de desafíos, jugadores y grupos, es opcional (ver Requerimientos opcionales). Esto significa que estos datos pueden ser cargados directamente de la base de datos.
El servidor central debe brindar los siguientes servicios a los otros componentes: - Login/Logout de jugadores - Obtener un desafío. Permite obtener el grafo que describe el desafío, cumpliendo con las reglas de visibilidad aplicadas sobre el grupo que solicita. - Obtener la información de un objetivo. - Establecer si una solución a un objetivo es correcta. Para ello se debe cumplir que: (1) el grupo debe de haber cumplido algún objetivo inmediatamente anterior; (2) la solución al objetivo es efectivamente correcta. En base a esto, el servidor debe contestar. En caso que el objetivo haya sido cumplido y esto dé visibilidad sobre otro nivel, el servidor deberá mandar la información del nuevo nivel visible al coordinador. 4.2. Front-End Ejecutor El aplicativo del ejecutor debe ofrecer las siguientes funcionalidades a los ejecutores: - Login. Para esto se debe especificar el nombre del jugador, su password y zona de acción. El nombre del jugador y su password deben ser validadas contra el servidor central. - Logout. - Obtener siguiente objetivo asignado a su zona. El ejecutor recibe el siguiente objetivo a realizar (de haber alguno) según la zona que especificó en el login. - Desplegar un objetivo. Permite ver la información asociada a un objetivo. - Rechazar un objetivo, informa al coordinador que dicho objetivo fue rechazado por el ejecutor, dado que no tiene posibilidad de cumplirlo. - Envío de la solución de un objetivo. La solución del objetivo es enviada al coordinador. - Inicio y terminación de Chat con otro jugador - Comenzar y terminar de participar del Chat del grupo - Envío de mensaje a Chat El aplicativo del ejecutor debe brindar los siguientes servicios a los otros componentes: - Recibir un objetivo asignado al jugador. El jugador debe de ser notificado inmediatamente. El front-end debe ser capaz de manejar estas funcionalidades aún con limitaciones en cuanto a la conectividad con los servidores involucrados. 4.3. Aplicativo Coordinador El aplicativo del coordinador debe ofrecer las siguientes funcionalidades a los coordinadores: - Login. Para esto se debe especificar el nombre de jugador y su password. El nombre del jugador y su password deben ser validadas contra el servidor central. - Logout. - Desplegar el desafío. Debe ser posible ver claramente la estructura del desafío, incluyendo: objetivos, relaciones de orden y los niveles. Se debe poder ver que
objetivos fueron completados y que objetivos no lo fueron. En el caso de los objetivos que no fueron completados, es posible saber el tipo de asignación que se hizo (de haber alguna) y que jugadores están llevando a cabo objetivos. - Permitir asignar un objetivo. Existen dos formas de asignación: por jugador o por zona. En el primer caso se asigna un objetivo a un jugador particular. Es posible especificar un timeout para dicha asignación, de forma que si el jugador no recibe efectivamente la asignación antes de ese tiempo, ésta se vuelva inválida y el objetivo debería volver al estado desasignado. Esto permite evitar situaciones en las que objetivos importantes queden trancados porque un jugador no tiene conexión. En el caso que el ejecutor reciba la asignación en tiempo y forma, y luego decida rechazarla, el objetivo debería pasar a estado desasignado. En el segundo caso, el objetivo se asigna a todo participante que esté en una zona, de forma que cualquier ejecutor en dicha zona pueda realizarlo. Un objetivo asignado por zona solo puede ser tomado por un ejecutor a la vez (por grupo). Los objetivos asignados por zona deben ser consumidos por orden de prioridad. Dicho orden de prioridad está dado por la relevancia que tiene dicho objetivo respecto a los otros objetivos asignados a la zona. Cada grupo de laboratorio debe definir una métrica para esto. En el caso que el ejecutor rechace un objetivo asignado a su zona, este objetivo debe quedar nuevamente asignado a la zona, esperando por otro ejecutor que lo tome. Al volver a quedar asignado, se debe seguir respetando la relación de orden con los otros objetivos de la misma zona. - Inicio y terminación de Chat con otro jugador - Comenzar y terminar de participar del Chat del grupo - Envío de mensaje a Chat El aplicativo del coordinador debe ofrecer los siguientes servicios a los otros componentes: - Obtener el siguiente objetivo asignado a una zona. - Registrar que un objetivo es rechazado por un ejecutor y tomar las acciones correspondientes. - Recibir una solución para un determinado objetivo. Las soluciones deben ser ordenadas antes de ser enviadas al servidor central, de forma de asegurar que antes de enviar una solución a un objetivo, el objetivo inmediatamente anterior haya sido cumplido. - Recibir la información de un nuevo nivel que se ha vuelto visible. El aplicativo debe ser capaz de brindar estos servicios para todos los jugadores que se encuentren relacionados por medio de un mismo grupo. 4.4. Otros Se debe poder guardar un historial de la conversación que ocurre en el Chat del grupo.
5. Tecnologías a utilizar La tecnologías que se utilicen para la implementación del proyecto son de libre elección, aunque deben ser coordinadas con su docente de monitoreo. A continuación se presenta una matriz con las diferentes tecnologías que se pueden utilizar. No necesariamente todas las tecnologías a utilizar por un grupo deben pertenecer a una misma plataforma. Se valorará la heterogeneidad entre las plataformas existentes en la solución de un grupo. Presentación (gruesa) Presentación (fina) (*) Lógica Mensajería Base de Datos Windows Presentation Fundation Java Swing ASP.NET JSP JSF J2EE (utilizando JBoss AS).NET 3.0 Java Message Service MSMQ SQL Server o PostgreSQL (*) En un principio no existe ningún requerimiento que establezca la necesidad de utilizar clientes finos. Todos los clientes pueden ser potencialmente gruesos. En un principio, el componente ejecutor no tiene porque ser implementado dentro de una plataforma móvil, aunque opcionalmente puede serlo (ver sección Requerimientos opcionales). Si bien puede no utilizarse una plataforma móvil, se deben considerar las restricciones que ésta implica. Debe ser posible simular escenarios de desconexión y también debe ser posible simular la presencia de un GPS. 6. Requerimientos opcionales Se presentan a continuación la lista de requerimientos opcionales respecto a la entrega inicial. 6.1. Objetivos Mutuo excluyentes Considerar que los objetivos de los desafíos son de dos tipos diferentes: - mutuo excluyentes, lo cual significa que el grupo de jugadores que cumpla con dicho objetivo primero es el único que puede seguir adelante por dicho camino. - normales, que plantean un problema cuya resolución es no excluyente, o sea cualquier grupo puede resolverlo en cualquier momento. 6.2. Requerimientos Administrativos Agregar al servidor central las funcionalidades administrativas, a saber:
- Definición de un objetivo - Listado de objetivos disponibles - Definición de un desafío - Administración de jugadores y grupos. Implica poder dar de alta jugadores, grupos de jugadores y asociar jugadores a grupos (asignándoles un rol) - Inscribir grupos a desafíos por iniciar Cada uno de estos requerimientos deberá ser implementado a nivel lógico y además se deberá proveer una interfaz gráfica para su implementación. 6.3. Ejecutor en dispositivo móvil Implementar la aplicación del ejecutor como una aplicación móvil, utilizando tecnologías Java ME [4] o Windows Mobile [5]. En el caso de utilizar Java ME es posible utilizar algún producto, a elección, para dispositivos móviles que implemente Java Message Service, por ejemplo Joram [7] o jtom [8]. En el caso de Windows Mobile se puede utilizar MSMQ para dispositivos móviles [6]. 6.4. Uso de Workflow Utilizar un motor de workflow (por ejemplo Windows-Workflow Fundation [9], Bonita [10] o jbpm [11]) para implementar los desafíos a nivel del servidor central. 6.5. Métricas del Servidor Considerar la siguiente restricción: el servidor central solamente puede atender 5 pedidos de un cliente (ya sea ejecutor o coordinador) por minuto. Modificar los clientes de forma que tomen esta restricción en consideración de forma de no sobrepasar la cota de mensajes. 7. Mecanismo de trabajo y entrega Cada grupo deberá entregar el sistema completo, que consta de los tres componentes mencionados anteriormente. Estos deberán correr en las computadoras de la sala 501. 7.1. Software disponible Se deberá coordinar con el tutor la instalación del software necesario en el equipamiento de la sala 501. Dicha instalación debe ser prevista con una anticipación de al menos 1 semana.
7.2. A Entregar Cada grupo deberá entregar: Software - Código fuente de todos las aplicaciones. - Scripts de ejecución automática para cada una de las aplicaciones, incluyendo argumentos de línea de comandos o archivos de configuración, si los tuvieran. - Archivo (llamarlo readme.txt ) con una explicación rápida de los parámetros u opciones que considere necesario aclarar. El archivo no debe contener más de una carilla. - Opcional: Instalador para cada una de las aplicaciones. Documentación: - Cronograma de desarrollo del laboratorio - Documento de entre 10 y 15 páginas con la presentación de la solución. El formato del documento debe seguir las líneas de un artículo de divulgación científica. - Documentación del sistema. - Manual de usuario, para las diferentes aplicaciones. - Juego de datos de prueba. 7.3. Formas y plazos de entrega - Las clases de monitoreo comienzan la semana del 23 de abril. Las mismas serán en horarios a convenir con los docentes. En la clase el docente indicará el salón de la clase siguiente, pudiendo ser el salón de clase o la sala de máquinas cuando considere necesario. - El 14 de Mayo se deberá entregar una descripción de la solución a ser desarrollada por el grupo. Este documento deberá ser entregado mediante correo electrónico al docente responsable del grupo y deberá tener un tamaño inferior a las 10 páginas. El documento debe contener las siguientes secciones: o Introducción a la solución: Describir en media carilla los puntos más relevantes de la solución a desempeñar. o Tecnologías: Descripción de las tecnologías a utilizar en la solución. Se deberá justificar, en las secciones subsiguientes de este mismo documento, la selección de las mismas. o Vista de diseño: Descripción del diseño general de la solución a nivel de módulos y componentes que la conforman. o Vista de deployment: Cómo los módulos serán distribuidos en los dispositivos físicos que conformen la solución. o Vista de mensajería [3]: Dada la naturaleza del problema, se deberá describir como se utilizará la mensajería en la solución entre los diferentes componentes del sistema. - El docente puede solicitar entregas adicionales para las restantes clases de consulta.
Adicionales - Todas las entregas se realizarán en el horario de monitoreo. - El docente a cargo del monitoreo, podrá requerir que se entregue documentación impresa. Entrega final - La entrega final deberá incluir, además, un CD con el producto final y la documentación dentro de un sobre con los datos de grupo, (nombre y cédula de todos los integrantes). Esta entrega se le realizará en la última clase de monitoreo al docente responsable del mismo, la cuál se llevará a cabo en la semana del 16 de Julio de 2007. - Posterior a la entrega (fecha a confirmar) se deberá realizar una presentación del trabajo realizado y una demo del producto final. 8. Referencias [1] Massive Multiplayer Online Games. http://en.wikipedia.org/wiki/mmog [2] Location-Based Games. http://en.wikipedia.org/wiki/location-based_game [3] Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. ISBN: 0321200683 http://www.enterpriseintegrationpatterns.com/ [4] Java Micro Edition Plataform. http://java.sun.com/javame/index.jsp [5] Windows Mobile. http://www.microsoft.com/windowsmobile/default.mspx [6] MSMQ Application Development for Windows Mobile-based Devices. http://msdn2.microsoft.com/en-us/library/ms879924.aspx [7] JORAM: Java (TM) Open Reliable Asynchronous Messaging http://joram.objectweb.org/ [8] jtom- Java to Mobile http://www.jtom.de/what_s_jtom.14.0.html?&l=2 [9] Windows Workflow Foundation http://msdn2.microsoft.com/en-us/netframework/aa663328.aspx [10] Bonita Workflow project http://wiki.bonita.objectweb.org/xwiki/bin/view/main/webhome [11] jbpm http://www.jboss.com/products/jbpm