Prototipo eSlayer presentación

Albert Lozano Ciller
Adrià Solé Orrit
Andrés Ricardo Herrera Gil
Carlos Pardo Durán
Fran Carpio Bueno
Daniel Guzmán Guzmán

Índice

1. Descripción del proyecto
2. Análisis de la aplicación
3. Diseño del sistema
4. Tecnologías utilizadas
5. Dimensionado
6. Planificación
7. Conclusiones

2

Índice

1.1. ¿Qué es eSlayer?

5. Dimensionado
6. Planificación
7. Conclusiones

3

1.1 ¿Qué es eSlayer?

• Juego multijugador en línea en tiempo real para móviles con sistema operativo
Android.
• Objetivo principal: sobrevivir eliminando al resto de jugadores.
• Información, tutorial, visualización de estadísticas y ranking a través de la página
web.
4

Índice
2.1. Descripción de la aplicación móvil
2.2. Descripción de la aplicación web

5. Dimensionado
6. Planificación
7. Conclusiones
5

2.1.Descripción de la aplicación móvil

• Cada jugador tiene un avatar.
• Cada jugador tiene asignado un objetivo que no conoce (el avatar de otro usuario) al que
debe eliminar.
• El jugador obtiene pistas sobre el avatar de su objetivo (para reconocerlo) cubriendo
necesidades (comiendo, yendo a clase,…) .
• Para matar a otro jugador, el usuario debe situarse geográficamente cerca de ese
jugador. Para controlar este aspecto, utilizaremos la tecnología Bluetooth.
• Publicación de eventos en Twitter/Facebook.
• Objetivo Principal:
Sobrevivir eliminando al resto de jugadores.

6

2.1 Descripción de la aplicación móvil

1
• Autenticación 4.1 Necesidades

4.2 Ver pistas

1 2 3
Autenticación Seleccionar partida Menú 4.3 Ver Jugadores
Jugador

4.4 Mapa

7

1
• Autenticación:
- Mediante Facebook o Twitter.
- Autenticación: se redirige al usuario a la página de Facebook/Twitter para aceptar los
términos de privacidad, o para loguearse si no lo está.

8


2
• Seleccionar partida 4.1 Necesidades

4.2 Ver pistas

1 2 3
Jugador

4.4 Mapa

9


2
• Seleccionar Partida:
- Unirse a partida ya creada o Crear Partida.
- La partida empieza cuando se ha unido un
determinado número de jugadores.
- Posibilidad de visualizar información sobre la partida.
- Una vez la partida ha empezado, NO se pueden unir
más jugadores.
- La partida acaba cuando sólo queda un superviviente
o cuando pasa un tiempo determinado.

10


3
• Menú Jugador 4.1 Necesidades

4.2 Ver pistas

1 2 3
Jugador

4.4 Mapa

11

•3 Menú Jugador:
- Información de nuestro jugador (foto, avatar eSlayer).
- Balas: Cada vez que se dispara a un jugador que no sea
tu objetivo, se pierde una bala. Si te quedas sin balas, no
puedes disparar durante un tiempo determinado.
- Ver pistas: Listar las pistas obtenidas sobre el objetivo al
que debemos asesinar.
- Tiempo restante: Tiempo que queda para dar la partida
por finalizada.
- Acceso a otras pantallas:
- Ver pistas
- Necesidades
- Ver jugadores
- Ver Mapa

12


4.1 Necesidades
• 4.1 Necesidades

4.2 Ver pistas

1 2 3
Jugador

4.4 Mapa

13


4.1 Necesidades:
•

- Cada X minutos, se deben saciar unas necesidades (ir
al baño, comer, …).
- Recompensa por saciar una necesidad: obtener una
pista.
- Para saciar una necesidad debes capturar un
DETERMINADO código QR con el móvil. Ejemplo:
- Si tienes que comer, debes capturar el código
QR localizado en el restaurante de la escuela.

14


4.2 Ver Pistas
• 4.1 Necesidades

4.2 Ver pistas

1 2 3
Jugador

4.4 Mapa

15


4.2 Ver Pistas:
•
- Se obtienen al cubrir necesidades.
- Las pistas dan información acerca del AVATAR de tu
objetivo o de las zonas donde ha estado tu objetivo.
- Los avatares son asignados automáticamente por el
servidor para evitar que hayan dos avatares
completamente iguales.

16


4.3 Ver Jugadores
• 4.1 Necesidades

4.2 Ver pistas

1 2 3
Jugador

4.4 Mapa

17


4.3 Ver Jugadores:
•
- Permite ver información acerca de los jugadores
que siguen vivos en la partida:
- Foto y avatar eSlayer.
- Dónde ha capturado su último código QR.
- Listar ubicaciones donde ha estado a lo largo de la
partida.

- Escanear zona: escanea mediante Bluetooth qué
jugadores se encuentran próximos a él. Acción
esencial para acabar con tu objetivo.

18


4.4 Mapa
• 4.1 Necesidades

4.2 Ver pistas

1 2 3
Jugador

4.4 Mapa

19


4.4 Mapa:
•
- Permite saber cuáles han sido los últimos códigos QR
visitados por el resto de jugadores y la localización
geográfica de éstos en la escuela.
- Útil para saber dónde debes escanear la zona para
acabar con tu objetivo.

20


21

• Información importante:
- Cada jugador tiene asignada un objetivo y a la vez es el objetivo de otro jugador.
- Herencia de objetivos: al acabar con tu víctima, tu nuevo objetivo pasará a ser el
antiguo objetivo de tu víctima.

Mari Mari

Juan Ana Juan Ana

Jose Jose

- Herencia de pistas: Al heredar el objetivo de tu víctima, también heredarás las pistas
que ésta tenía sobre su objetivo.

22

2.2. Descripción de la aplicación web

• Ofrece información sobre la aplicación eSlayer (descripción, cómo se juega, vídeo-
tutorial, …).
• Link QR para descargar la aplicación
desde el móvil.
• Ranking semanal de jugadores.
• Buscador de jugadores: ver perfil.
• Información sobre los desarrolladores
del proyecto.

23


24

3. Diseño del Sistema
• Servidor Web:

- Utiliza servicios web para la comunicación con la aplicación móvil.
Servidor BD
Recibe petición-> solicita servicio a capa lógica -> devuelve respuesta de
capa lógica al usuario.
Servidor Web

- Aloja el portal web de la aplicación (para la conexión mediante PCs). Lógica de la aplicación
Recibe petición-> solicita servicio a capa lógica -> devuelve respuesta de
capa lógica al usuario.
Servicios
Portal Web
Web
- Capa lógica: se encarga de la mecánica de las operaciones y el acceso

HTTP (REST)

HTTP + JSON

HTTP
a la base de datos.

HTTP
Recibe solicitudes de servicios web y portal web -> procesa solicitudes
accediendo a BD -> devuelve respuesta a servicios web y portal web.

26

• Ejemplo: Juan quiere matar a Jose

Mato a Jose ¿Jose es la
victima de Juan?

¿Juan puede
matar Si
a jose?
¿Quién era la
victima de Jose?

Maria BD
Jose está muerto

María es el
objetivo de Juan
Has matado a Jose,
tienes un Servicios Si
Lógica de la
Juan nuevo objetivo Web aplicación

27

• Seguridad en Servicios Web:
• Utilización del Estándar OAuth:
• Usuario utiliza access token para autenticarse.
• El access token lo genera la aplicación al recibir el request token.
• Sólo el usuario que ha enviado el request token puede utilizar el access token (el
access token está ligado al request token).

Usuario Servidor
Get Request token
Grant Request token

Get Access token
Grant Access token

Mata a Dani + access token

Dani ha muerto
. . .

28

Índice
4.1. Aplicación móvil
4.2. Portal web
4.3. Servicio web
4.4. Base de datos
4.5. Herramientas de desarrollo
5. Dimensionado
6. Planificación
7. Conclusiones
29

4.1 Aplicación móvil
• Desarrollada para el SO Android de Google: plataforma abierta con mayor número de
usuarios.
• Autenticación y autorización a través de Twitter/Facebook.

4.2 Portal web
• Java: lenguaje de programación de alto nivel orientado a objetos.
• HTML: lenguaje de marcado para la elaboración de las páginas web.
• CSS: lenguaje usado para definir la presentación de un documento estructurado escrito en
HTML o XML.
• Ajax:
- Conjunto de técnicas para el desarrollo de aplicaciones web asíncronas.
- Se ejecuta en el cliente y mantiene una comunicación con el servidor asíncrona en
segundo plano.

30

4.3 Servicio web
• REST:
- Técnica de arquitectura software para sistemas distribuidos como WWW.
- Permite hacer llamadas a un webservice mediante peticiones HTTP sin la necesidad de
implementar un cliente específico.
- Más ligero que SOAP.
• JSON:
- Estándar basado en texto diseñado para el intercambio de datos de fácil lectura.
- Deriva de Javascript y se trata de un formato más ligero que XML.
• Java Servlet:
- Tecnología Java utilizada que amplia las capacidades del servidor.
- Corren dentro de un contenedor de servlets (pe. Tomcat).
- Puede comunicarse sobre cualquier protocolo cliente-servidor.
- Fácil integración con otras partes del proyecto ya hechas en Java.
31

4.4 Base de datos
• RDBMS:
- Sistema de gestión de una base de datos relacional.
- SQL es el lenguaje diseñado para la gestión de datos dentro de RDBMS.
- Usaremos MySQL como servidor SQL (Open-Source).

4.5 Herramientas de desarrollo
• Apache Wicket:
- Framework para el diseño de aplicaciones web: HTML (diseño) y JAVA
(comportamiento). Uso transparente de AJAX. Fácil desarrollo.
• Apache Maven:
- Herramienta de software para la gestión y construcción de proyectos Java.
- Se basa en el concepto de Project Object Model (POM) para describir el proyecto de
software a construir, sus dependencias a otros módulos y componentes externos .
- Incluye automáticamente las dependencias necesarias para arrancar un proyecto.
32

4.5 Herramientas de desarrollo
• Android SDK: API para el desarrollo de aplicaciones para Android.
• SVN: Sistema de control de versiones.
- Ofrece la posibilidad de que varias personas puedan modificar y administrar el mismo
conjunto de datos desde sus respectivas ubicaciones.
- Privacidad en los proyectos (a diferencia de GitHub).
• Jersey: API en Java para la implementación de servicios web RESTful.
• JPA: Entorno de desarrollo que gestiona datos relacionales en aplicaciones Java. Evita tener
que diseñar bases de datos y clases Java por separado. Pensado para RDBMS.
• Hibernate:
- Implementa la API de JPA.
- La relación se realiza mediante archivos XML o anotaciones.

33

Índice
5. Dimensionado
5.1. Estudio de demanda
5.2. Estrategia de dimensionado y estudio de uso

6. Planificación
7. Conclusiones
34

5. Dimensionado
5.1.Estudio de demanda

• Titulaciones en la EETAC:
• Grados: Sistemas de Telecomunicación, Telemática, Aeronavegación, Aeropuertos.
• 25 alumnos/grado · 4 grados/cuatrimestre · 2 cuatrimestres/año · 4 años = 800
alumnos
• Másteres oficiales: MASTEAM, MAST, GEONA
• 20 alumnos/Máster · 3 Másteres/cuatrimestre · 2 cuatrimestres/año · 4 años =
480 alumnos
• Personal docente de la EETAC: alrededor de 150 profesores.
• Posibles usuarios de la aplicación: 1430 usuarios.

35

5. Dimensionado
• Apache JMeter: herramienta para realizar test de rendimiento del servidor.
• Se modela un usuario base y se realizan peticiones concurrentes.
• Se obtiene la carga máxima y se comprueba el consumo de recursos por usuario en
el servidor .
• A partir de estos datos podremos dimensionar el servidor para que soporte un
mínimo de usuarios (pe. 1000 usuarios).
• Software de monitorización del servidor (pe. Zabbix):
• Controlaremos el estado del servidor en todo momento.
• Reúne y almacena información acerca del consumo de recursos o peticiones
recibidas.
• Estadísticas del juego: a partir de los datos almacenados en la BBDD SQL.
• Relacionaremos esta información con la que ofrece el software de gestión sacando
conclusiones sobre el uso de la aplicación (Pe: uso de RAM vs partidas en curso).
36

5. Dimensionado

• Estudio de la aplicación móvil: se analizarán requisitos y consumo.
• Diferentes tipos de móviles Android.
• Diferentes tipos de conexión: GPRS, 3G o WiFi.
• Diferentes perfiles de uso del dispositivo: número de aplicaciones en ejecución.
• Los estudios se realizarán de forma regular para disponer de una muestra más grande:
• Se sacarán mejores conclusiones para optimizar la aplicación.

37

Índice

5. Dimensionado
6. Planificación
6.1. Metodología Scrum

7. Conclusiones
38

6. Planificación

• El proyecto se desarrolla de forma incremental (sprints) realizando, de forma regular,
entregas parciales (incrementos) del producto final.
• Dentro del marco de trabajo definido por Scrum existen diferentes roles:
• Propietario del producto: Toni Oller y Eduard Garcia (representa al cliente).
• Scrum manager: Ricardo (gestiona y facilita la ejecución del proceso).
• Equipos de desarrollo:
• Portal web: Ricardo y Adrià (Wicket).
• Web Services: Albert (Rest).
• Cliente móvil: Fran y Daniel (Android).
• Base de datos: Carlos (Hibernate).
• Interesados: profesores DXAT (asesoran y observan).
39

6. Planificación

• El product backlog (esta presentación) es el punto de partida. Explica, a alto nivel, el
trabajo a realizar.
• A fecha de hoy el primer sprint ya ha terminado. Las tareas completadas (definidas en el
sprint backlog y mostradas en la demo) son:
• Implementación parcial del portal Web: no hay acceso a BBDD.
• Web Service: devolver lista de usuarios.
• Cliente móvil:
• Implementación del diseño previo de la interfaz gráfica.
• Autenticación a través de Twitter.
• Solicitar lista de usuarios y mostrarla por pantalla.

40

6. Planificación

• Tiempo disponible para completar el desarrollo: 2 meses.
• Sprint pendientes: 4 sprints de dos semanas de duración.

41

6. Planificación
• Día 1: sprint planning meeting
• Seleccionar qué trabajo se ha de hacer y preparar el sprint backlog.
• A partir del día 1: reunión diaria de 15 minutos para inspeccionar cómo va el trabajo
de los equipos (daily scrum).
• Último día del sprint: revisar el trabajo completado y realizar una demo (sprint
review meeting).

42

6. Planificación
• Objetivos del próximo sprint:
• Esqueleto de modelos/clases (base): diseño e implementación.
• BBDD:
• Familiarizarse con JPA e Hibernate.
• Implementación de operaciones básicas de lectura y escritura.
• Web Services:
• Identificar qué servicios web (base) se van a necesitar.
• Añadirlos al servidor (la lógica se implementará en próximos sprints).
• Android:
• Códigos QR: investigar cómo se crean, cómo se leen y planificar su uso en
la aplicación.
• Notificaciones: identificar los requisitos y realizar un diseño del sistema.
43

6. Planificación

44

7. Conclusiones
• Subversion nos ayuda a trabajar de forma coordinada.
• Maven facilita el uso de diferentes librerías añadiéndolas automáticamente en el proyecto.
• Existen muchas APIs que nos permiten trabajar con diferentes tecnologías sin tener que
implementar métodos propios.
- Por ejemplo Jersey ya ofrece soporte para OAUTH.
• Los servicios web RESTful son útiles para la interacción con clientes escritos en lenguajes
distintos.
- Inconveniente: seguridad.
• Scrum nos ofrece un método de organización que se adapta muy bien a las características
de este proyecto.
- Nos permite desarrollar de manera incremental a la vez que nos familiarizamos con
las distintas tecnologías.
- Al no dominar las tecnologías que usaremos es difícil estimar la duración de cada
tarea con precisión.

45

Turno de preguntas

46

Prototipo eSlayer presentación

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Prototipo eSlayer presentación