Touching music: juego educativo musical multiplataforma

Asier Tarancón García

Touching music: juego educativo musical

María Vico Pascual Martínez-Losa

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2012-2013

Título

Autor/es

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013

publicaciones.unirioja.esE-mail: [email protected]

Touching music: juego educativo musical multiplataforma, trabajo fin de gradode Asier Tarancón García, dirigido por María Vico Pascual Martínez-Losa (publicado por la

Universidad de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.

Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright.

i

Contenido

1 RESUMEN / ABSTRACT .......................................................................................................... 1

1.1 Resumen ........................................................................................................................ 1

1.2 Abstract ......................................................................................................................... 1

2 OBJETIVO ............................................................................................................................... 2

3 MOTIVO DE LA ELECCIÓN ...................................................................................................... 3

4 METODOLOGÍA ...................................................................................................................... 4

4.1 Descripción .................................................................................................................... 4

4.2 Team Foundation Service .............................................................................................. 5

5 MODO DE JUEGO .................................................................................................................. 8

6 ARQUITECTURA GENERAL ................................................................................................... 10

7 PLANIFICACIÓN INICIAL ....................................................................................................... 12

8 SPRINT 0 .............................................................................................................................. 13

8.1 Descripción .................................................................................................................. 13

8.2 WaveEngine ................................................................................................................. 14

9 SPRINT 1 .............................................................................................................................. 16

9.1 Descripción .................................................................................................................. 16

9.2 Sprint Backlog .............................................................................................................. 17

9.2.1 Interfaz gráfica .................................................................................................... 17

9.2.2 Pantalla menú principal ....................................................................................... 25

9.2.3 Servicio en Windows Azure ................................................................................. 26

9.2.4 Implementación acceso al servicio...................................................................... 33

9.3 Revisión del sprint / Burndown ................................................................................... 34

10 SPRINT 2 .......................................................................................................................... 36

10.1 Descripción .................................................................................................................. 36

10.2 Sprint Backlog .............................................................................................................. 37

10.2.1 Servicio en Windows Azure. Tareas pendientes ................................................. 37

10.2.2 Sonidos, Música ................................................................................................... 38

10.2.3 Pantalla de configuración .................................................................................... 38

10.2.4 Pantalla de selección de área .............................................................................. 39

10.2.5 Pantalla usuario ................................................................................................... 40


11 SPRINT 3. MEMORY SOUND ............................................................................................ 43

11.1 Descripción .................................................................................................................. 43

ii

11.2 Sprint Backlog .............................................................................................................. 43

11.2.1 Pantalla selección nivel / subnivel....................................................................... 44

11.2.2 Memory sound .................................................................................................... 46

11.2.3 Idioma de la aplicación ........................................................................................ 52


12 SPRINT 4 .......................................................................................................................... 56

12.1 Descripción .................................................................................................................. 56

12.2 Sprint backlog .............................................................................................................. 56

12.2.1 Pantalla Usuarios ................................................................................................. 57

12.2.2 Pantalla final de nivel .......................................................................................... 60

12.2.3 Scoreoid ............................................................................................................... 61


13 SPRINT 5 .......................................................................................................................... 66

13.1 Descripción .................................................................................................................. 66

13.2 Sprint Backlog .............................................................................................................. 66

13.2.1 Juego memoria musical ....................................................................................... 67

13.2.2 Pantalla logros del usuario .................................................................................. 69

13.2.3 Publicidad ............................................................................................................ 71


14 CONCLUSIONES ............................................................................................................... 73

15 FUTURO ........................................................................................................................... 74

16 REFERENCIAS ................................................................................................................... 76

iii

ÍNDICE DE ILUSTRACIONES

Ilustración 1. Team Foundation Service ........................................................................................ 5

Ilustración 2. Conectar con TFS desde Visual Studio..................................................................... 5

Ilustración 3. Vista de tareas desde Visual Studio ........................................................................ 6

Ilustración 4. Dashboard del portal de TFS ................................................................................... 7

Ilustración 5. Diagrama de navegabilidad de las pantallas del juego ........................................... 9

Ilustración 6. Arquitectura general ............................................................................................. 10

Ilustración 7. Arquitectura integración con Windows Azure ...................................................... 10

Ilustración 8. Diagrama de secuencia para obtener los datos de un usuario ............................. 11

Ilustración 9. Funcionamiento WaveEngine ............................................................................... 15

Ilustración 10. Panel SCRUM Backlog inicial sprint 1 .................................................................. 16

Ilustración 11. Backlog inicial sprint 1 ......................................................................................... 17

Ilustración 12. Inkscape, ejemplo de la creación de la interfaz gráfica ...................................... 18

Ilustración 13. Assets exporter de WaveEngine .......................................................................... 19

Ilustración 14. Inkscape, ejemplo de gráficos para animaciones ................................................ 23

Ilustración 15. Texture Packer GUI .............................................................................................. 24

Ilustración 16. Captura final pantalla menú principal ................................................................. 26

Ilustración 17. Captura 1 portal Windows Azure ........................................................................ 27

Ilustración 18. Captura 2 portal Windows Azure ........................................................................ 28

Ilustración 19. Modelo Entidad - Relación .................................................................................. 30

Ilustración 20. Diagrama relacional ............................................................................................. 31

Ilustración 21. Burndown sprint 1 ............................................................................................... 35

Ilustración 22. Panel SCRUM fin sprint 1 ..................................................................................... 35

Ilustración 23. Panel SCRUM, Backlog inicial sprint 2 ................................................................. 36

Ilustración 24. Backlog inicial sprint 2 ......................................................................................... 37

Ilustración 25. Captura pantalla configuración ........................................................................... 39

Ilustración 26. Captura pantalla Selección Área ......................................................................... 40


Ilustración 28. Panel SCRUM fin sprint 2 ..................................................................................... 41

Ilustración 29. Panel SCRUM Backlog inicial sprint 3 .................................................................. 43

Ilustración 30. Backlog sprint 3 ................................................................................................... 44

Ilustración 31. Captura pantalla selección nivel .......................................................................... 44

Ilustración 32. Captura selección de nivel e movimiento ........................................................... 45

Ilustración 33. Nivel Desbloqueado ............................................................................................ 45

Ilustración 34. Nivel bloqueado .................................................................................................. 45

Ilustración 35. Captura SlidePanel .............................................................................................. 46

Ilustración 36. Diseño de las cartas. MemorySound ................................................................... 46

Ilustración 37. Carta con varias notas ......................................................................................... 47

Ilustración 38. Diagrama de flujo. MemorySound ...................................................................... 48

Ilustración 39. Captura inicial del juego MemorySound ............................................................. 49

Ilustración 40. Captura MemorySound en juego ........................................................................ 49

Ilustración 41. Diagrama de un WrapPanel ................................................................................ 52

Ilustración 42. Diagrama de clases para la internacionalización ................................................ 53


Ilustración 44. Panel SCRUM final sprint 3 .................................................................................. 55

Ilustración 45. Panel SCRUM backlog sprint 4 ............................................................................ 56


iv

Ilustración 47. Respuesta en el foro de WaveEngine .................................................................. 57

Ilustración 48. Captura 1 pantalla usuarios ................................................................................. 58

Ilustración 49. Captura 2 pantalla usuarios ................................................................................. 58

Ilustración 50. Captura login, pantalla usuarios .......................................................................... 59

Ilustración 51. Crear usuario, pantalla usuarios .......................................................................... 60

Ilustración 52. Pantalla nivel completo inacabada ..................................................................... 61

Ilustración 53. Dashboard portal ScoreOID ................................................................................. 62

Ilustración 54. Consola servicio ScoreOID ................................................................................... 63

Ilustración 55. Panel final sprint 4 ............................................................................................... 64


Ilustración 57. Panel SCRUM backlog sprint 5 ............................................................................ 66


Ilustración 59. Diagrama de clases lógica del juego .................................................................... 68

Ilustración 60. captura final nivel completado ............................................................................ 69

Ilustración 61. Captura logros del usuario .................................................................................. 70

Ilustración 62. Ads Settings Manager de WaveEngine ................................................................ 71

Ilustración 63. Panel SCRUM, fin sprint 5 .................................................................................... 72


Ilustración 65. Captura previa juego "repite el ritmo" ................................................................ 74

Ilustración 66. Captura previa juego "completa la canción" ....................................................... 75

1

1 RESUMEN / ABSTRACT

1.1 RESUMEN Desde hace unos cuantos años podemos ver cómo los niños aprenden a manejar los dispositivos

táctiles, teléfonos o tabletas, a edades más tempranas. Tenemos que aprovechar todo ese

potencial para ofrecerles herramientas que además de servirles para jugar les permita aprender.

En este proyecto se ha desarrollado un juego infantil de educación musical, con el que los niños

podrán aprender música a la par que se divierten jugando.

El juego llamado Touching Music, se compone de varios minijuegos con los que se fomenta el

aprendizaje de cuatro partes vitales en el estudio de la música, oir, cantar, tocar y leer.

Se ha creado una arquitectura base para un juego infantil, reutilizable para futuros juegos,

además de un minijuego llamado Memory Sound queda fuera del alcance del proyecto el resto

de minijuegos.

Touching Music funciona en varias plataformas, Windows 8 y Windows Phone actualmente y

Android e iOS en un futuro cercano. Con Touching Music se puede almacenar la información del

usuario en un servicio en la nube para poder iniciar sesión en varios dispositivos y guardar así el

estado de la partida. Además el juego es multiidioma (inglés, alemán y castellano de momento).

1.2 ABSTRACT Since several years ago we can see how children learn to handle with touchscreen devices like

mobile telephones or tablets in a very early age. We have to take advantage of this potential

skill and provide them the tool not only to play but also to learn.

In this project it has been developed a children´s game of music´s training, which whom children

can learn music and enjoy playing at the same time.

The game is called Touching Music, and it is composed of several small games to encourage the

four basic musical skills learning: to hear, to sing, to touch and to read.

A base architecture for a children game has been created in this project to be used and

developed for further games, as well as another small game called Memory Sound.

Touching music runs in several platforms, Windows 8 and Windows Phone currently and Android

and iOS in a near future. As Touching Music information can be stored in a cloud computing, it

is also possible to start session through several devices and save the last game status.

In addition, the game is multilingual, (English, German and Spanish at the moment).

2

2 OBJETIVO

El objetivo principal de este trabajo de fin de grado es desarrollar un juego educativo musical

infantil.

El proyecto se apoya en la base de un método de aprendizaje musical que se centra en 4 áreas

que todo estudiante de música debe educar y perfeccionar. Estas áreas son: Oir, Cantar, Tocar

y Leer.

La plataforma consta de varios minijuegos que fomentan el aprendizaje de estas áreas.

El juego está creado con un motor de juegos llamado WaveEngine que nos permitirá tratar con

las imágenes o sonidos de forma más efectiva y nos abstraerá de muchos temas inherentes al

juego.

La plataforma se desarrollará íntegramente en C# de la plataforma .NET. Como backend para el

juego se usará un Servicio Móvil de Windows Azure en el que guardaremos los usuarios, con sus

niveles, puntuaciones, logros y todo lo que pueda hacer falta para restaurar el juego en otro

dispositivo.

Características adicionales:

- Plataforma multiusuario

- Multilenguaje: Castellano, inglés y alemán (ampliable en futuras versiones)

- Táctil. Aprovechando las capacidades de los nuevos dispositivos móviles y tablets.

- Constará de una versión de prueba gratuita con publicidad y una versión de pago con la

posibilidad de desbloquear más juegos y sin publicidad.

3

3 MOTIVO DE LA ELECCIÓN

Tengo la gran suerte de trabajar en lo que es mi pasión, la informática y en concreto el desarrollo

de aplicaciones. Empecé desde pequeño a programar y siempre tuve la ilusión de poder llegar a

desarrollar un juego.

Pasaron los años y empecé a estudiar, primero un grado de desarrollo de aplicaciones y un par

de años más tarde, ingeniería técnica de informática de gestión. Después de 10 años

programando aplicaciones, en su mayoría, de gestión, era el momento de enfrentarme al gran

reto de crear un juego.

No tenía ningún conocimiento anterior en lo que a la creación de juegos se refiere, pero en parte

esto también fue una de los motivos por los que opté por esta opción. Hay que salir de la zona

de confort y enfrentarse a nuevos retos constantemente, y eso es lo que he intentado hacer con

este proyecto.

El motivo principal por el que se eligió hacer un juego educativo y musical es que mi pareja,

profesora de música y musicoterapeuta tenía grandes ideas sobre cómo enseñar música a los

niños. Sólo tuvimos que dar forma a esas ideas y desgranarlas en pequeños juegos con los que

los niños pudieran aprender a la vez que divertirse.

Por otro lado se pensó que de cara a la comercialización, en las tiendas de juegos de las

principales plataformas móviles, un juego en la categoría educación e infantil podría tener un

hueco en el mercado.

4

4 METODOLOGÍA

4.1 DESCRIPCIÓN Para el desarrollo del proyecto se ha seguido una metodología ágil. Lo que significa que se ha

creado un software de manera incremental, haciendo más hincapié en la evolución de los

requerimientos según avanzaba el proyecto que en la necesidad de generar una documentación

exhaustiva desde el principio.

De esta forma, en vez de seguir una metodología clásica en la que inicialmente se preparaban

todos los requisitos, se hacía la planificación global para más tarde pasar al desarrollo, se

planificó el proyecto en función a varios sprints o incrementos.

Cada sprint engloba una serie de características nuevas que aumentan la funcionalidad de la

plataforma. Por tanto, cada sprint genera un nuevo incremento del software que amplía una

funcionalidad.

Este tipo de metodologías encajaba perfectamente en el tipo de proyecto que se quería

implementar, ya que desde un primer momento había muchas incógnitas que se irían

resolviendo según avanzaba el proyecto. Era mejor tomar las decisiones oportunas antes de

cada inicio de sprint, no al inicio del proyecto. De esta forma se ha podido ajustar cada sprint a

las necesidades que obligaba el proyecto.

Para la planificación y seguimiento de los sprints se ha utilizado una herramienta llamada Team

Foundation Service. Esta herramienta incorpora una plantilla de SCRUM, una metodología ágil

muy utilizada en la actualidad. Esta metodología utiliza como base una serie de artefactos en los

que nos hemos apoyado en este proyecto para su gestión.

- Un backlog de cada sprint

- Un tablero SCRUM

- Gráfico Burndown

No se puede decir que se haya seguido SCRUM, ya que esta metodología tiene una serie de

características que una persona individualmente no puede cubrir. Diferentes roles y reuniones

principalmente.

El backlog del sprint. Es una serie de requisitos, llamados historias de usuario, que se van a cubrir

durante el tiempo que dura el sprint. Cada historia de usuario, se dividirá en diferentes tareas.

El tablero SCRUM, es una vista muy gráfica de la situación actual del sprint. En ella veremos por

cada historia seleccionada si está sin comenzar, en curso o finalizada.

Gráfico Burndown. Este gráfico, nos representa la cantidad de esfuerzo pendiente para terminar

el sprint. En SCRUM no es tan importante el tiempo que se ha dedicado si no el tiempo que

queda para acabar.

5

4.2 TEAM FOUNDATION SERVICE

Ilustración 1. Team Foundation Service

Team Foundation Service (TFS en adelante) es un servicio de gestión del ciclo de vida de

proyectos con el que se puede realizar no sólo el control de versiones de las aplicaciones (sean

para la plataforma que sean…y en cualquier lenguaje de programación), sino también un

seguimiento de tareas hechas y por hacer, reparto de tareas entre miembros del equipo de

desarrollo, petición de feedback sobre los cambios realizados, etc.

Es un servicio ofrecido gratuitamente por Microsoft, con alguna limitación en número de

usuarios sobre todo, y se integra de manera perfecta con sus herramientas de desarrollo.

Se ha utilizado este servicio durante todo el proyecto para:

- El control del código fuente

- Planificar y gestionar las historias de usuario / tareas

- Supervisión del avance del proyecto

El control del código fuente es esencial en todo proyecto de software. Permite tener versiones

del código, colaborar entre varios programadores, recuperar versiones anteriores de los

archivos, sirve como copia de seguridad… En este proyecto se ha usado la herramienta de

desarrollo Visual Studio 2012 que tiene una integración muy buena con Team Foundation

Service.

Ilustración 2. Conectar con TFS desde Visual Studio

6

En la imagen anterior se puede apreciar cómo desde Visual Studio podemos conectarnos al TFS,

y en la siguiente imagen vemos que se puede gestionar el conjunto de tareas del proyecto desde

el propio Visual Studio:

Ilustración 3. Vista de tareas desde Visual Studio

Pero TFS además, tiene un portal web, desde el que se puede gestionar todo el ciclo de vida del

proyecto. En la imagen siguiente se puede ver el dashboard de la página principal:

7

Ilustración 4. Dashboard del portal de TFS

En él se puede ver la situación actual del sprint, el burndown, las horas pendientes, miembros

del equipo… Toda la información necesaria para valorar de forma rápida la evolución actual del

proyecto. Desde aquí se puede acceder a toda la funcionalidad del servicio.

Como parte de la supervisión, se dio acceso a la tutora del proyecto para que pudiera entrar al

portal y tener una visión global de los avances en todo momento.

A lo largo de todo el proyecto se irán viendo más funciones y capturas del TFS por lo que no se

profundizará más en este punto.

8

5 MODO DE JUEGO

Touching Music es un juego educativo musical. A través de cuatro áreas se pretende que el niño

interiorice y aprenda los fundamentos básicos de la música.

Touching Music se compondrá de varios minijuegos, cada uno pensado para fomentar una de

las áreas (oir, cantar, tocar o leer).

En este proyecto se ha creado la arquitectura básica del juego. Arquitectura que se podrá usar

en un futuro para otro tipo de juegos que no sea musical, ya que la base está diseñada de manera

genérica.

Esta base del juego comprende la creación de usuarios, la configuración básica, la selección del

juego, selección de nivel y la pantalla de final de nivel.

Además de esta base, se ha implementado uno de los minijuegos, Memory Sound.

Cada minijuego se divide en distintos niveles que el jugador tendrá que ir superando para poder

continuar avanzando en el juego.

Según se avanza en los niveles y pantallas, la dificultad aumenta, incorporando nuevas

características de la música cada vez más complejas. Por ejemplo, en el juego de memoria

auditiva, empezará con sonidos individuales y simples de la escala musical y poco a poco irá

incorporando otros elementos como sostenidos, bemoles, cambios de tonalidad… y

aumentando el número de notas a identificar.

Según se van terminando pantallas se irá sumando puntuación. Cada juego tendrá su propio

sistema de puntuación dado que en función de las características del juego primarán más el

número de intentos, el tiempo u otro tipo de variables.

Cada vez que se termine un nivel de cada juego A través del servicio de backend se actualizará

el perfil del usuario con las puntuaciones conseguidas y se incorporarán a una tabla de

puntuaciones global.

A la par, en función de cada juego podrá conseguir logros, identificados con badges o medallas.

Este elemento se incorpora porque a los niños les gusta mucho coleccionar este tipo de méritos,

y su interés por conseguirlos/coleccionarlos hace que puedan dedicar más tiempo e interés al

aprendizaje.

El juego terminará cuando hayan completado todos los niveles de todos los juegos.

A continuación se muestra una previsión de la navegabilidad de las pantallas del juego:

9

Ilustración 5. Diagrama de navegabilidad de las pantallas del juego

Escena Cargando

Escena principal

Escena de selección de

área de juego

Escena de usuarios

Escena de configuración

Escena de logros

Area Oir

Selector de juego

Memory Sound.

Selector de nivel

Memory Sound. Juego

Nivel completo

Juego pausado

Retorno al juego

10

6 ARQUITECTURA GENERAL

Como consecuencia directa de varios de los requisitos no funcionales indicados en los objetivos

del proyecto, podemos comenzar con una arquitectura general básica, que nos permite una

primera aproximación para entender la estructura del proyecto.

Ilustración 6. Arquitectura general

Como vemos en la imagen superior, el juego tendrá varias entradas/salidas. Por un lado, está la

configuración local del juego, almacenada en un fichero .Xml. Por otro lado, se cargarán los

gráficos y los niveles de cada juego, también almacenados de forma local en el dispositivo en el

que esté instalado el juego. Finalmente, podemos ver la conexión del juego con el servicio

backend en el que se almacenará toda la información de los usuarios.

Uno de los requisitos de la aplicación es poder guardar el estado de la partida de los usuarios,

así como sus logros y demás datos. Para ello, se decidió usar Windows Azure, en concreto

Windows Azure Mobile Service, que nos permite de forma muy sencilla crear el backend

necesario.

Ilustración 7. Arquitectura integración con Windows Azure

Como vemos en la parte izquierda del diagrama, la aplicación puede funcionar en multitud de

sistemas operativos, tanto móviles como de escritorio. Desde esos clientes, la aplicación se

.XML

TOUCHING MUSIC

CONFIGURACIÓNSERVICIO BACKEND

EN LA NUBE

.XML

NIVELES JUEGOS

Windows Azure Services

AUTENTICACIÓN USUARIOS

NOTIFICACIONESPUSH

DATA

SCRIPTS

Mobile Services

SQLSERVER

Touching Music

11

comunica con el servicio web alojado en Windows Azure a través de una API REST. Aunque

Windows Azure Mobile Service tiene una implementación específica para las plataformas

móviles más importantes (Windows 8 / Windows Phone 8, iOS y Android), en nuestro caso se ha

tenido que usar la API REST debido a la plataforma usada para el juego, WaveEngine. Este

apartado se explicará en profundidad más adelante.

Para conectarse al servicio, la aplicación tiene una clave proporcionada por Windows Azure, la

cual autoriza a la aplicación a consultar/modificar los datos.

Como servicios añadidos, en Windows Azure Mobile Service, nos proveen de una autenticación

de usuarios, notificaciones PUSH, scripting y acceso a datos. Este acceso a datos se realiza de

forma interna y transparente en el servicio, y facilita enormemente el trabajo al desarrollador.

La base de datos que utiliza es SQL Server.

Como ejemplo, a continuación vemos un diagrama de secuencia en el que se explica los pasos

necesarios para obtener los datos de un usuario concreto.

Ilustración 8. Diagrama de secuencia para obtener los datos de un usuario

Una vez conseguida una visión global veremos a continuación la planificación inicial de la que

parte el proyecto.

UserSceneTouching

Music

Entra escena usuarios

ITouchingMusicService

TouchingMusicServiceAzure

GetUser(id)

WindowsAzure

Selecciona usuariollama funcion GetUser

API REST / Get<User>(id)

User

User

Usuario seleccionado actualizadoSale escena usuarios

12

7 PLANIFICACIÓN INICIAL

Se ha creado una planificación inicial como base para el desarrollo del proyecto. Pero se asume

que durante el desarrollo del mismo puede verse modificada.

En la planificación inicial se han establecido 5 sprints, cada uno de 3 semanas, desde mediados

de febrero hasta junio. Estas fechas no podrán verse modificadas, ya que la entrega del proyecto

tiene fechas definidas, pero sí que podrá variar el contenido asignado a los sprints.

Como se está gestionando el proyecto desde una metodología ágil, no hay problema en adaptar

el contenido de cada sprint a lo que se vea necesario en cada momento. Aceptando los cambios

como algo inherente al proyecto.

Se estiman unas 2h al día de dedicación desde mediados de febrero hasta la primera semana de

junio. Se tiene en cuenta días que no se podrá trabajar y fines de semana que se podrán dedicar

más horas de las estipuladas inicialmente.

Por tanto estimamos una velocidad media de sprint de 45 horas.

En la tabla siguiente vemos el backlog general del proyecto. En cada sprint se dividirá cada

historia de usuario en sus tareas correspondientes y se priorizarán en función de las

necesidades.

Título Esfuerzo Iteracción

Elección del motor de juegos 6 TouchingMusic\Release 1\Sprint 0

Gráficos/música del juego 12 TouchingMusic\Release 1\Sprint 0

Menú principal 10 TouchingMusic\Release 1\Sprint 1

Servicio en Windows Azure 25 TouchingMusic\Release 1\Sprint 1

Interfaz gráfica 20 TouchingMusic\Release 1\Sprint 1

Sonidos, Música 10 TouchingMusic\Release 1\Sprint 2

Pantalla de configuración 12 TouchingMusic\Release 1\Sprint 2

Pantalla usuario 20 TouchingMusic\Release 1\Sprint 2

Pantalla logros del usuario 10 TouchingMusic\Release 1\Sprint 2

Juego memoria musical 40 TouchingMusic\Release 1\Sprint 3

Juego "repite el ritmo" 45 TouchingMusic\Release 1\Sprint 4

Juego "puzzle musical" 40 TouchingMusic\Release 1\Sprint 5

Juego "Trivial musical" 40 TouchingMusic\Release 1\Sprint 5

13

8 SPRINT 0

8.1 DESCRIPCIÓN En el primer sprint, del 4 de febrero al 17 de febrero, se invirtió la totalidad de tiempo en la

elección de la plataforma de desarrollo. Uno de los requisitos no funcionales que se estableció

desde el inicio, fue la posibilidad de crear un juego multiplataforma. Este requisito nos obligaba

a buscar un motor de juegos que permitiera programar en un único lenguaje y convertirlo

posteriormente a otras plataformas. Después de sondear varias alternativas, la elegida fue

WaveEngine de Weekend Game Studio (empresa creada por Plain Concepts).

A continuación se exponen los motores de juegos estudiados, marcando en verde las

plataformas mejor valoradas según las necesidades del proyecto:

WaveEngine Unity Cocos 2D XNA

Plataformas Destino

Windows, Windows Store, Mac, iOS, Android y Windows Phone

Windows, Mac, iOS, Android y Windows Phone

Windows, Linux, Mac, iOS, Android

Windows, Xbox 360 y Zune

Lenguaje programación

C# Javascript, Boo, C#

Python, c++ C#

Versión actual 1.0.8.0 (beta) 4.1.2 0.5.5 4.0

Precio Gratuito 199$ (Indie) 1499$ (Pro)

Gratuito Gratuito

Física Si Si Si No

Analítica multiplataforma

Si No No No

Sistema integrado de publicidad

Si No No No

Exportación automática distintas plataformas

Si No No No

Como se puede apreciar en la comparativa, la plataforma mejor valorada, según las necesidades

del proyecto, es WaveEngine. Las características que más pesaron en la decisión fueron:

- que se pudiera, de forma sencilla, portar el juego a varias plataformas como iOS,

Android, Windows Phone, y Windows 8.

- que fuera gratuito,

- y a ser posible en C#.

Además de todo lo anterior, la plataforma WaveEngine está siendo desarrollada por una

empresa española afincada en San Francisco, Plain Concepts. Empresa referencia en España por

la calidad de sus trabajos, por lo que aseguraba la gran calidad del trabajo que estaban haciendo

con la plataforma.

El único punto negativo que tiene la plataforma a día de hoy es que está en fase beta. Esto puede

suponer un hándicap importante, ya que el proyecto puede verse mermado en algún punto en

14

el que el motor de juegos todavía no esté desarrollado al 100%. Según avance el proyecto el

equipo de WaveEngine irá liberando más funcionalidades y habrá que adaptarse a los cambios

impuestos en la plataforma.

Desde esta web se puede ver el roadmap del motor de juegos:

http://www.waveengine.net/Engine/Roadmap

A continuación se explica el motor WaveEngine con un poco más de detalle.

8.2 WAVEENGINE Vamos a profundizar en este punto sobre el motor de juegos elegido ya que va a determinar las

reglas a seguir durante todo el proyecto.

WaveEngine es un motor de juegos creado por la empresa española Plain Concepts. A la par que

crearon un juego propio, fueron moldeando un motor a su alrededor, que finalmente decidieron

publicar de forma gratuita. Los inicios del motor fueron por febrero de 2013 y a día de hoy sigue

en fase beta. Desde entonces se han ido liberando versiones que han ido completando

funcionalidad.

La base de WaveEngine es construir un juego en C# y poder exportarlo a diferentes plataformas.

Soportan iOS, Android, MAC, Windows Store, Windows (escritorio), Windows Phone… como se

puede ver, todas las más importantes.

WaveEngine provee de unas plantillas para Visual Studio que generan un pequeño esqueleto de

la aplicación para poder empezar. Además incorpora tres herramientas básicas que se usarán a

lo largo del proyecto:

- Conversor de proyectos.

- Exportador de los llamados assets. Gráficos, música, sonidos, animaciones…

- Gestor de publicidad.

En la siguiente imagen se puede ver la arquitectura de la aplicación en lo que a componentes

del motor se refieren.

http://www.waveengine.net/Engine/Roadmap

15

Ilustración 9. Funcionamiento WaveEngine

Por tanto la idea a seguir en el proyecto, será programar en C# el juego. Crear los diferentes

elementos tanto gráficos, como sonoros con herramientas externas e importarlos al proyecto.

Finalmente se exportará cada proyecto a las plataformas elegidas para posteriormente

compilarlas como aplicaciones nativas en cada plataforma. Este punto es importante, las

aplicaciones son nativas en los sistemas, WaveEngine en la conversión de los proyectos adecúa

las dlls necesarias a la plataforma y genera un código compatible con la plataforma destino.

Más adelante, cuando se hable de la implementación de los componentes, se darán detalles

concretos de acuerdo a la plataforma.

Conversión de gráficos, sonidos, animaciones

a formato .wpk (WaveEngine)

Conversión proyectos

Creación juegoEn C#

API Servicio

16

9 SPRINT 1

9.1 DESCRIPCIÓN Este sprint abarcó las fechas del 18/02/13 hasta el 10/03/13.

En este primer sprint, se da forma a la interfaz gráfica del juego, tan importante en este tipo de

desarrollos. Se tenía claro que el juego está dirigido a niños pequeños por tanto se tenía que

adecuar el contenido de la interfaz a estas edades.

Cada elemento gráfico ha sido creado en este proyecto de forma vectorial e importado

finalmente al juego. Lo mismo se puede decir del resto de elementos que lo componen.

Además, una vez construidos los primeros elementos, como los botones del menú principal, y

los personajes, se crea la primera escena del juego: el menú principal.

Por último, se crea el servicio web en Windows Azure, y se implementa las primeras operaciones

del servicio.

Vemos a continuación la vista del panel de Scrum sacada de TFS. Podemos ver la situación inicial

del sprint, con las tres historias de usuario seleccionadas para este sprint a la izquierda y

divididas cada una en sus tareas. Al ser la situación inicial están todas en la columna “TO DO”.

Ilustración 10. Panel SCRUM Backlog inicial sprint 1

17

A continuación vemos las mismas historias de usuario en la vista del sprint backlog, sacada

también de nuestro servicio TFS.

Ilustración 11. Backlog inicial sprint 1

9.2 SPRINT BACKLOG

9.2.1 Interfaz gráfica

9.2.1.1 Descripción

Una de las primeras historias de usuario en las que se pensó a la hora de desarrollar la

plataforma, fue la interfaz gráfica. Como todo juego, la interfaz tiene que tener una línea gráfica

muy cuidada y seleccionada para la edad a la que va dirigido. En este sentido, Touching Music

está dirigida a niños de edades muy tempranas, por tanto los colores elegidos tenían que ser

muy vivos y los personajes simples y coloridos.

Un juego se compone de muchas piezas que hay que ensamblar de forma correcta para que

quede tan bonito, como usable y divertido. Como el juego hace referencia a la educación musical

se creyó conveniente usar un tipo de letra en el que aparecieran símbolos musicales y repetir

estos símbolos a lo largo de toda la interfaz gráfica. Por ejemplo, usamos las figuras musicales,

negras, corcheas y semicorcheas para formar los rayos del sol en la pantalla inicial del juego.

18

Para la creación de todos los componentes gráficos del juego se ha usado una aplicación llamada

Inkscape, herramienta de edición de gráficos vectoriales.

Se han creado todos los elementos gráficos manualmente y son de diseño propio creados en

exclusiva para este proyecto.

Ilustración 12. Inkscape, ejemplo de la creación de la interfaz gráfica

En la imagen anterior vemos la creación de la pantalla del menú principal en Inkscape. Cada

elemento ha sido creado de manera independiente y unido posteriormente para el prototipo.

De cara al juego, se ha exportado individualmente cada elemento (botones, el marcador, el sol,

el fondo…) a formato .png.

Una vez exportados los elementos a formato .png, hay que convertirlos a un formato propio de

WaveEngine, llamado wpk (Wave PacKage) para poder usarlos con el motor.

Este proceso se hace a través de una herramienta que provee WaveEngine, llamada Assets

Exporter. Con esta herramienta podemos crear un árbol de carpetas para organizar todos los

gráficos del juego. No sólo hay que convertir los elementos gráficos, también los elementos

sonoros, las animaciones (las veremos en profundidad más adelante), e incluso las fuentes que

se utilizarán en el juego.

Además, esta herramienta nos permite crear varias configuraciones diferentes para cada

plataforma, ya que es posible que queramos usar los mismos gráficos para cada plataforma,

pero a diferentes escalas. No es lo mismo preparar el juego para un Windows Phone con una

resolución definida por el fabricante que para un iPad por ejemplo o para un Windows 8. Esto

se puede apreciar en la siguiente imagen en la parte de la derecha, justo debajo del dibujo de

19

Dodo. En este caso tenemos una configuración por defecto, y otras dos configuraciones más.

Una para Windows Phone y otra para Windows 8.

Ilustración 13. Assets exporter de WaveEngine

Una vez importados todos los gráficos en la herramienta, y configuradas las escalas de salida y

el resto de características, sólo queda exportarlas de forma automática a la extensión .wpk. Con

todo esto ya están los assets preparados para usarlos en el proyecto.

A continuación se exponen los principales elementos gráficos creados para el juego:

20

9.2.1.2 Personajes

Mimi (Oir)

Sisi (Cantar)

Dodo (Tocar)

Guido (Leer)

21

9.2.1.3 Fondos

Fondo menú principal

Fondo menú selección juegos

9.2.1.4 Botones y otros elementos gráficos

En este sprint se han definido los elementos necesarios para el menú principal.

Botón Inicio

Botón Usuario

Botón Logros

Botón Configuración

Panel puntuación

22

Tablero de nombre de usuario

9.2.1.5 Animaciones

Es muy importante también en un juego animar los elementos necesarios para que de una

mayor sensación de realismo. Los niños se ven atraídos por los objetos en movimiento por lo

que es importante usar estas animaciones para atraer su atención.

En este punto hay que distinguir dos tipos de animaciones, ya que darán un trabajo muy

diferente en su creación.

- Animaciones de botones, u otros elementos en los que sólo se cambian componentes

de los gráficos como la escala o la posición horizontal o vertical.

- Animaciones en las que hay un movimiento del gráfico. Por ejemplo los rayos del sol de

la pantalla principal, o animaciones con los personajes.

Para realizar el primer tipo de animaciones, no hace falta usar ninguna herramienta externa, ya

que podemos realizar la animación desde el código en C#. En el caso de los botones, se ha creado

un nuevo tipo de botón que se anima cuando es pulsado y además reproduce un sonido. Esta

animación es un pequeño cambio de escala, que hace que durante un instante crezca el botón

desde el centro y vuelva a su tamaño pasado un segundo.

Para el segundo tipo de animaciones es necesario recurrir a otra herramienta de terceros para

crear un sprite. Un sprite es un gráfico tipo mapa de bits que incorpora una serie de elementos

gráficos en la misma imagen. Computacionalmente es mucho más eficiente cargar una imagen

grande y moverse por la imagen para buscar el trozo de imagen deseado que cargar muchas

imágenes pequeñas. Se guarda la posición de cada imagen y así posteriormente se puede

localizar de forma sencilla.

Para crear estos sprites, se ha utilizado la herramienta Texture Packer GUI, en su versión gratuita.

Antes de nada, tenemos que dibujar cada frame de la animación a mano. Para esto de nuevo

utilizaremos la herramienta Inkscape y dibujaremos cada frame apoyándonos sobre el anterior

para darle un pequeño movimiento.

23

Ilustración 14. Inkscape, ejemplo de gráficos para animaciones

Una vez conseguidos todos los frames de la animación, los exportaremos individualmente como

imagen .png para utilizarlas en el programa Texture Packer GUI.

Lo que hace entonces Texture Packer GUI es importar las imágenes que hemos generado

manualmente y colocarlas en una misma imagen, además genera un fichero .XML con la posición

de cada frame, para poder localizarla rápidamente desde el código.

Con el fichero .png generado con todos los frames, lo convertimos a formato .wpk con la

herramienta Assets Exporter de la plataforma WaveEngine y junto al .XML generado ya está

listo para utilizarlos en el código fuente.

24

Ilustración 15. Texture Packer GUI

A continuación vemos el código fuente necesario para crear el sprite animado:

public Entity CreateMimiAnime() { var mimi = new Entity("Mimi") .AddComponent(new Transform2D() { X = 150, Y = 100, }) .AddComponent(new Sprite("Content/Scenes/SelectorArea/animationMimi.wpk")) .AddComponent(Animation2D.Create<TexturePackerGenericXml>("Content/Scenes/SelectorArea/animationMimi.xml") .Add("Dancing", new SpriteSheetAnimationSequence() { First = 1, Length = 10, FramesPerSecond = 10 })) .AddComponent(new AnimatedSpriteRenderer(DefaultLayers.Alpha)) .AddComponent(new RectangleCollider()) .AddComponent(new TouchGestures()); mimi.FindComponent<TouchGestures>().TouchTap += GameSelectorScene_TouchTap; EntityManager.Add(mimi); var anim2D = mimi.FindComponent<Animation2D>(); anim2D.CurrentAnimation = "Dancing"; anim2D.Play(true); return mimi; }

Cargamos la imagen, el fichero .XML con la información del sprite, luego establecemos la

secuencia de frames y la asociamos a un nombre de animación, en este caso Dancing para poder

referenciarla desde el resto del código fuente.

También se ha implementado la animación para los rayos de sol

25

9.2.2 Pantalla menú principal


Pantalla principal del juego en el que tendremos acceso a las funciones principales. Desde esta

pantalla podremos acceder a:

- Pantalla configuración. Acceso a la pantalla de configuración en la que se podrá

establecer los ajustes de volumen de sonido y música.

- Pantalla usuarios. Es el acceso a la pantalla de selección de usuario. Si todavía no hay

un usuario creado se podrá dar de alta un usuario en el sistema.

- Pantalla logros. Acceso a la pantalla de logros del usuario actual.

- Pantalla juegos. Acceso a la pantalla de selección de juegos, a través de las distintas

áreas definidas.

Además en la pantalla del menú principal tendremos

- Puntuación actual. Puntuación del usuario actual

- Nivel. Nivel del usuario actual

9.2.2.2 Desarrollo

El desarrollo de esta pantalla por ahora simplemente es situar cada elemento gráfico generado

en el paso anterior en su lugar correspondiente en la pantalla. Teniendo en cuenta que los

elementos de abajo son botones, el sol es un botón rodeado del sprite animado de los rayos y

los paneles superiores son imágenes con el texto dinámico.

Ejemplo de código del botón usuarios:

… this.UserBtn = new TouchingMusicButton("User") { Text = string.Empty, IsBorder = false, BackgroundImage = TouchingMusic.Helpers.ResourcePath.UsersButton, BackgroundColor = Color.White, Width = 169f, Height = 169f, Margin = new Thickness(10f), VerticalAlignment = VerticalAlignment.Bottom, HorizontalAlignment = HorizontalAlignment.Center }; this.UserBtn.Click += delegate(object e, EventArgs a) { if (this.CurrentState != GameState.Playing) { WaveServices.TaskScheduler.CreateTask(TimeSpan.FromSeconds(1.0), delegate { this.UserScene.Initialize(WaveServices.GraphicsDevice); }).ContinueWith(delegate { ScreenLayers screenLayers = WaveServices.ScreenLayers; screenLayers.AddScene(this.UserScene); screenLayers.Apply(); }); } }; this.fadeOut.Completed += delegate(object e, EventArgs a){ this.UpdateState(GameState.Playing); }; base.EntityManager.Add(this.UserBtn);

26

En el código anterior, incluido en la inicialización de la escena, vemos cómo hacemos una

instancia de un botón personalizado, lo situamos en la pantalla y le asignamos la imagen

correspondiente. Además en el evento click del botón, inicializamos la escena de usuarios y la

cargamos.

Posteriormente cuando esté desarrollado el módulo de usuarios habrá que cargar el usuario

actual del servicio y actualizar su puntuación y nivel en cada juego.

9.2.2.3 Resultado

Resultado final de la pantalla

Ilustración 16. Captura final pantalla menú principal

9.2.3 Servicio en Windows Azure


Para almacenar los usuarios de la aplicación, se ha creado un servicio móvil de la plataforma

Windows Azure. Hay varios motivos para la elección de esta plataforma:

- La plataforma Windows Azure es de Microsoft y es muy sencilla la integración con

aplicaciones .NET

- Es posible consumir el servicio desde cualquier plataforma, incluidas iOS y Android.

Plataformas posibles futuras del juego.

- Windows Azure es escalable y la disponibilidad que ofrece es máxima. Perfecto para una

aplicación como la que se ha desarrollado en este proyecto.

En este servicio se han implementado varios métodos desde los que se podrán realizar las

siguientes funcionalidades:

- Dar de alta usuarios, así como modificar sus datos y baja del sistema.

- Obtener la situación actual de un usuario, nivel, logros desbloqueados…

A continuación se explica el modelo de datos diseñado para soportar la información anterior y

la implementación en clases necesaria. Para probar el servicio se ha creado una pequeña

27

aplicación de prueba para garantizar que funciona correctamente. En posteriores sprints se

ampliará la funcionalidad del servicio incluyendo las puntuaciones de los jugadores.

Una vez creada la cuenta en Windows Azure, se ha creado un servicio móvil desde el propio

portal. La vista del panel de control de Azure es la siguiente:

Ilustración 17. Captura 1 portal Windows Azure

Como se ve en la imagen anterior, se ha creado un servicio móvil, y una base de datos SQL Server.

El servicio web es accesible desde un gran abanico de plataformas móviles, incluidas las

principales: Windows Phone, Windows 8, iOS y Android.

Las funcionalidades que nos ofrece Windows Azure son muchas. En la siguiente imagen vemos

la primera de las vistas que nos ofrece al entrar al servicio móvil.

28

Ilustración 18. Captura 2 portal Windows Azure

Vemos un resumen de la cantidad de datos descargados y el consumo de CPU y memoria por

parte del servidor. Una de los puntos negativos que pueden tener el servicio, es que Windows

Azure es un servicio de pago y que cobran por datos como transferencia, cantidad de

procesadores o memoria. En un futuro es posible que se busque una alternativa gratuita al

servicio.

Otra de las ventajas que ofrece Windows Azure es la escalabilidad. Si vemos que nuestro servicio

está en un consumo muy alto y que las características contratadas del servidor no son

suficientes, podríamos aumentar su capacidad de forma inmediata.

29

No se va a profundizar más en este tema. Para obtener más información acerca del portal de

Windows Azure puede ir a las referencias, al final del documento.

9.2.3.2 Capa de datos

Para guardar los usuarios de la aplicación necesitamos una estructura de datos muy sencilla.

Simplemente necesitamos guardar los datos referentes a los usuarios como nombre, email… , el

nivel que llevan y los logros conseguidos. Vemos primero un diagrama entidad-relación para

soportar esta estructura.

30

Ilustración 19. Modelo Entidad - Relación

A continuación se muestra el diagrama relacional:

User

Play

FirstName

LastName

Email

UserName

Password

Game

ActualLevel Have

Badge

id nameid name

Date

(0, N)

(0, N)

(0, N)

(0, N)

31

Ilustración 20. Diagrama relacional

9.2.3.3 Capa de servicio

Aunque la decisión inicial de elegir Windows Azure como plataforma para el backend es clara,

hay que tener en cuenta que en un futuro es posible que se decida cambiarla. Esta decisión

debiera de ser transparente para el resto de la plataforma. Para eso vamos a implementar un

patrón de diseño llamado Inversion of Control, y en concreto usaremos la inyección de

dependencias. Este patrón cambia el flujo de ejecución del código haciendo que sea una entidad

externa o estructura externa la encargada de iniciar su ejecución. De esta forma aislamos la

lógica del backend en lo que se denomina servicio. Crear servicios es una buena práctica que

conviene explicar brevemente.

Un servicio es una clase, o un conjunto de ellas, que nos provee de una funcionalidad que no es

el objetivo principal de la aplicación, pero la necesita para actuar. Además este servicio puede

ser reutilizado en otras aplicaciones.

En nuestro caso, la llamada al backend es algo que necesitamos, pero su lógica no es el objetivo

principal del juego. Además como hemos visto, puede cambiar su plataforma destino y la

aplicación no tiene por qué enterarse.

UserGame

UserGame

Badge

UserBadge

IdPK

FirstName

LastName

IdPK

Name

IdUserPK

ActualLevel

IdGamePK

IdPK

Name

IdUserPK

Date

IdBadgePK

Email

UserName

Password

1

N

N

1

N

1

1

1 N

32

Para cumplir todo lo anterior, se ha creado una interfaz llama ITouchingMusicService con todos

los métodos necesarios para interactuar con el servicio. Además se ha creado una

implementación para Azure de la interfaz.

De este modo, las llamadas al servicio se hacen a través de la interfaz, y desde una clase factoría

crearemos el objeto que cumple la interfaz. Si en algún momento decidimos usar otro servicio

simplemente cambiaremos este objeto por otro que cumpla la misma interfaz y el resto de la

aplicación seguirá funcionando igualmente.

Las operaciones que se incluyen en el servicio, y por tanto en la interfaz, son las necesarias para

interactuar con los usuarios del sistema. Cada operación lleva parejo un evento en el que se

recogerá el resultado de la llamada. Todas las operaciones del sistema tienen que ser asíncronas

para no hacer esperar al usuario y parar la interfaz. De esta forma, por ejemplo, la operación

CreateUserAsync inicia una llamada al servicio y una vez obtenido el resultado de la operación

llamará al evento CreateUserCompleted donde avisaremos al usuario del resultado.

Las operaciones a implementar son las necesarias para crear usuarios, actualizar los datos del

usuario actual y obtener todos los datos de un usuario dados su nombre de usuario y contraseña.

interface ITouchingMusicService { event EventHandler<ServerEventArgs<bool>> CreateUserCompleted; void CreateUserAsync(User user); event EventHandler<ServerEventArgs<User>> GetUserCompleted; void GetUserAsync(string login, string password); event ServerDataEventHandler SetUserCompleted; void SetUserAsync(User user); }

Una vez construida una interfaz que nos satisface todas las operaciones necesarias con el

servidor, en el código del juego utilizaremos esta interfaz para realizar todas las llamadas al

servicio. De esta forma conseguimos aislar el juego del servicio utilizado.

Esta solución llevada al juego basado en WaveEngine, implica registrar el servicio al inicio del

juego.

public class Game : WaveEngine.Framework.Game { public override void Initialize(IAdapter adapter) { ... WaveServices.RegisterService<ITouchingMusicService>( new ScoreoidService()); ... }

}

En futuros sprints se intentará una implementación similar a la realizada con Azure, con otro

servicio llamado ScoreOID, que ya tiene implementada internamente toda la lógica necesaria

33

para almacenar los datos del juego, jugadores, puntuaciones, … y así probamos la arquitectura

de diseño del servicio con dos servicios diferentes.

9.2.4 Implementación acceso al servicio

En este apartado se explica la implementación del servicio con Windows Azure.

Para acceder al servicio web, Azure proporciona una URL única y un servicio de autenticación.

https://touchingmusic.azure-mobile.net/

El carácter multiplataforma del juego limita a la hora de usar ciertos componentes en la

programación. En este caso, para el uso de Windows Azure Mobile Services limita al hecho de no

poder usar las SDK´s nativas que vienen implementadas ya por Microsoft y atacaremos al

servicio a través de su API REST.

A continuación vemos una porción del código de la implementación de la interfaz del servicio

comentada en los puntos anteriores:

public class TouchingMusicService : ITouchingMusicService { MobileServices Service { get; set; } public TouchingMusicService() { Service = new MobileServices("TouchingMusic", "[Master Key Touching Music]", ""); } public List<User> GetUsers() { return Service.GetAll<User>("User").ToList(); } public void AddUser(User user) { Service.Insert<User>("User", user); } }

La clase MobileServices es un helper creado para facilitar el acceso al Servicio Web en Azure. A

modo de ejemplo vemos a continuación el código para añadir un usuario nuevo al sistema:

public void Insert<T>(string tableName, T item) where T : class { Uri address = new Uri(string.Format("https://{0}.azure-mobile.net/tables/{1}", ServiceName, tableName)); HttpWebRequest request = (HttpWebRequest)WebRequest.Create(address); request.AllowWriteStreamBuffering = false; request.Method = "POST"; request.Headers = new WebHeaderCollection {

https://touchingmusic.azure-mobile.net/

34

{"X-ZUMO-APPLICATION", ApplicationId} }; string serialization = item.Serialize(); byte[] byteData = Encoding.UTF8.GetBytes(serialization); request.ContentLength = byteData.Length; request.ContentType = "application/json"; request.Accept = "application/json"; request.UserAgent = "TouchingMusic"; using (Stream postStream = request.GetRequestStream()) { postStream.Write(byteData, 0, byteData.Length); } HttpWebResponse response = (HttpWebResponse)request.GetResponse(); response.Close(); }

El acceso al API lo hacemos con REST y pasamos los datos en formato JSON. Por tanto creamos

una llamada Web con el método POST y los datos que necesita el servicio. El nombre del servicio

y la clave de aplicación.

En este sprint se ha completado la creación del servicio web y la implementación del mismo en

C# a través del API REST, pero no se ha incluido en la lógica del juego. En un sprint posterior se

completará esta parte integrándola completamente en la interfaz gráfica.

9.3 REVISIÓN DEL SPRINT / BURNDOWN En el sprint 1 se terminaron la mayoría de las tareas propuestas a tiempo. Se quedó alguna tarea

pendiente sobre el servicio web para el sprint 2. Pero dado que era el primer sprint y que había

muchas cosas por definir el resultado ha sido bastante satisfactorio.

El tiempo dedicado al proyecto ha sido el planificado y junto a una estimación más o menos

exacta ha permitido que el burndown luzca bastante óptimo.

35

Ilustración 21. Burndown sprint 1

Vemos a continuación el panel SCRUM con las historias de usuario y tareas que se han

completado durante el sprint y las que se han quedado pendientes para el próximo.

Ilustración 22. Panel SCRUM fin sprint 1

La historia de usuario: “Servicio en Windows Azure” no se completó y se deja para el siguiente

sprint.

36

10 SPRINT 2

10.1 DESCRIPCIÓN El segundo sprint, empezó el 12 de marzo y acabó el 31 de marzo.

En este sprint se incluyó la historia de usuario que no se terminó en el anterior sprint y se

completó con varias historias de usuario más, cubriendo las 45 horas estimadas de velocidad de

sprint.

Una vez diseñada la pantalla del menú inicial, se continuó con las pantallas de configuración,

usuarios y todo el sistema sonoro del juego.

En la planificación inicial, se había incluido en este sprint la pantalla de logros del usuario. Pero

al arrastrar una historia del anterior sprint, se decidió quitarla y dejarla para un futuro sprint.

Se ven a continuación la lista de historias de usuario y tareas elegidas para el sprint 2

Ilustración 23. Panel SCRUM, Backlog inicial sprint 2

37

Ilustración 24. Backlog inicial sprint 2

10.2 SPRINT BACKLOG

10.2.1 Servicio en Windows Azure. Tareas pendientes

Esta tarea se quedó pendiente en el sprint 1, y se retoma en este. Durante este periodo se

completa la tarea de recuperar el estado del usuario.

Se crea una función genérica para conseguir los datos del servicio a través del API REST y

posteriormente utilizamos esta función para conseguir todos los datos necesarios del servicio.

Con estas funciones cumplimos así todos los métodos de la interfaz creada para acceder al

servicio backend.

public RestResult<T> Get<T>(string tableName, string filter = "", int skip = 0, int top = 50) where T : class { if (!string.IsNullOrWhiteSpace(filter)) filter = string.Concat("&$filter=", filter); Uri address = new Uri(string.Format("https://{0}.azure-mobile.net/tables/{1}?$inlinecount=allpages&$skip={2}&$top={3}{4}", ServiceName, tableName, skip, top, filter)); HttpWebRequest request = (HttpWebRequest)WebRequest.Create(address); request.Method = "GET"; request.Headers = new WebHeaderCollection {

38

{"X-ZUMO-APPLICATION", ApplicationId}, {"X-ZUMO-MASTER", MasterKey}, }; RestResult<T> result; using (HttpWebResponse response = (HttpWebResponse)request.GetResponse()) { Stream stream = response.GetResponseStream(); result = stream.Deserialize<RestResult<T>>(); } return result; }

10.2.2 Sonidos, Música

Una de las partes importantes de un juego, es la música que acompaña en todo momento al

jugador, y los sonidos que se reproducen cuando se ejecuta alguna acción, como por ejemplo

pulsar un botón.

Para los sonidos, se buscó un banco de sonidos ya creados, con licencia copyleft para poder

usarlos sin problemas. Después de una exhaustiva búsqueda encontramos unos sonidos acordes

con el tipo de juego.

Además se crearon los archivos de sonido que representan a las notas de música en varias

escalas, para comprender todo el espectro musical necesario para el juego. Con un programa

llamado Finale, para la creación de partituras, se fueron creando individualmente cada nota. Se

han creado las notas correspondientes entre el Do en escala 3ª hasta el Do en escala 5ª

Con la música se procedió de manera diferente. En vez de buscar una música hecha, se

externalizó la creación de una canción que encajara como fondo en el juego.

De esta forma, la tarea establecida en el backlog para la música, comprende las reuniones con

la compositora y la elección de la música.

El único requisito que se le pidió a la compositora para la creación de la música fue que la

sintonía fuera compatible con la edad en la que estaba pensado el juego y que fuera una sintonía

divertida y alegre.

10.2.3 Pantalla de configuración

La función de esta pantalla es la configuración del juego, que incluye:

- Volumen de la música

- Volumen de los sonidos

- Selección de idioma. A elegir entre español, inglés y alemán

Para establecer los volúmenes se han elegido los controles de tipo slider para poder mover el

volumen entre 0 y 100.

A continuación vemos una vista de la pantalla:

39

Ilustración 25. Captura pantalla configuración

Como vemos en la imagen para elegir el idioma del juego seleccionaremos la bandera del país.

En un primer momento se implementará en español, inglés y alemán.

La lógica de los recursos de los idiomas disponibles en el juego, se implementarán en otro sprint

al no tener tiempo en este.

10.2.4 Pantalla de selección de área

Una vez pulsado el botón del sol para empezar a jugar hay que seleccionar a qué área de las

cuatro disponibles se quiere jugar.

Para eso se crea una pantalla en la que aparecen los cuatro personajes del juego para poder

seleccionar el área deseada.

Además, como se comentó en el sprint 1, se introduce aquí la animación para Mimi, el pájaro

verde que representa el área OIR. De esta forma se llama al usuario a pulsar en este personaje

ya que el resto, por el momento, no están habilitados.

A los personajes ya creados en otro sprint, se añade la creación de una enredadera sombreada

de la que salen 4 ramas donde se sitúan los personajes.

Esta pantalla no aporta nada nuevo en cuanto a lo que implementación se refiere por lo que no

se detalla nada de código. Toda la dificultad técnica está en el apartado gráfico.

40

Ilustración 26. Captura pantalla Selección Área

10.2.5 Pantalla usuario

Esta historia de usuario se introdujo en este sprint, para completar las 45 horas asignadas como

velocidad del sprint. Sólo se pudo meter una de sus tareas ya que el resto no cabía en este sprint.

Aun así no se pudo más que empezar. Se queda pendiente para futuros sprints.

En la pantalla de usuarios, tendremos todo lo referente a los usuarios del juego. Desde esta

pantalla se podrá:

- Darse de alta en el juego.

- Loguearse. Es posible que el usuario exista ya en el juego al darse de alta en otro

dispositivo.

- Seleccionar un usuario existente.

- Eliminar un usuario del dispositivo.

Se tuvo que abandonar por el momento esta pantalla al encontrar un bug en el motor

WaveEngine. En el foro de la plataforma, se le ha dado feedback del problema y en el momento

que se solucione el problema se retomará el desarrollo.

En este sprint, por tanto, no se ha podido completar la tarea, pero sí que se ha planteado la

funcionalidad de manera más detallada para una mejor planificación en un futuro.

10.3 REVISIÓN DEL SPRINT / BURNDOWN Este sprint ha sufrido un retraso importante sobre lo planificado. Problemas de falta de tiempo

sobre todo a mitad del sprint, como se puede ver en el gráfico del burndown hacen que no se

pueda completar todas las tareas planificadas.

Se han quedado 16 horas pendientes para terminar en la siguiente iteración, referentes al

idioma y a la pantalla de usuario.

41

Aunque durante este sprint ha bajado la velocidad del sprint se entiende que ha sido algo

excepcional y que en el siguiente sprint se puede mantener la velocidad establecida en un primer

momento, de 45 horas.

A continuación se ven las gráficas del burndown, y el estado final de las tareas en el panel del

TFS.


Ilustración 28. Panel SCRUM fin sprint 2

43

11 SPRINT 3. MEMORY SOUND

11.1 DESCRIPCIÓN El tercer sprint se desarrolló desde el 1 de abril hasta el 21 de abril.

En el sprint 3 se centró el desarrollo en el minijuego llamado Memory Sound, el primero de una

serie de juegos posteriores. Este juego está ubicado en la sección OIR, sección en la que se

pretende mejorar el oído musical de los niños, preparándoles para distinguir entre las notas

musicales y su ubicación en el pentagrama.

Para ello el juego tiene una dinámica tipo memory en el que se dispone de una serie de cartas

tornadas hacia abajo y el usuario debe ir dándoles la vuelta por parejas hasta encontrar todas

las parejas iguales. Cada carta representará a una o varias notas musicales. Cada vez que se dé

la vuelta a una carta sonará la nota o notas que representa.

También se aborda durante este sprint la historia del idioma del juego que se dejó sin completar

en el sprint anterior. La historia referente a la creación de usuarios y comunicación con el servicio

Azure sigue todavía pendiente en este sprint. Problemas con la beta del motor WaveEngine

hacen que se tenga que posponer esta tarea hasta más adelante.

11.2 SPRINT BACKLOG

Ilustración 29. Panel SCRUM Backlog inicial sprint 3

44

Ilustración 30. Backlog sprint 3

11.2.1 Pantalla selección nivel / subnivel

Como paso previo al juego, hay que elegir el nivel/subnivel en el que se quiere jugar. Esta

pantalla cobra más importancia según avanza el sprint de la que se le da en un primer momento.

La primera decisión que había que tomar para el desarrollo de la pantalla era cómo mostrar los

distintos niveles. Se pensó en una solución en la que se viera un nivel y sus subniveles en una

misma pantalla y se pudiera deslizar de un nivel a otro llevando el dedo de izquierda a derecha.

Según se ve en las siguientes imágenes:

Ilustración 31. Captura pantalla selección nivel

45

Ilustración 32. Captura selección de nivel e movimiento

Otro tema importante era cómo mostrar los niveles bloqueados y los desbloqueados, para ello

se eligieron estas dos imágenes.

Ilustración 33. Nivel Desbloqueado

Ilustración 34. Nivel bloqueado

La imagen de la izquierda además tendrá el comportamiento de un botón, e incluirá en su

interior, el número del subnivel al que se va a acceder. El número se escribirá desde el código

fuente para poder hacerlo dinámico.

Para saber qué nivel está bloqueado o desbloqueado miraremos el usuario actual del sistema.

Cada vez que el usuario pasa un nivel del juego se aumenta el valor del nivel desbloqueado del

usuario. Primero sumará por subnivel y si es el último del nivel, se aumentará de nivel.

Una vez que el jugador haya completado todos los niveles y subniveles habrá completado el

minijuego. Una vez pasado cada subnivel el jugador podrá volver a jugar cuantas veces quiera.

La dificultad de esta pantalla radicaba en la creación del panel deslizante. Se quería dotar al

panel de una animación efecto muelle para poder pasar de una pantalla a otra de manera fluida

y vistosa. Para reproducir este efecto se creó un nuevo componente con un comportamiento

específico para el propósito que se pretendía conseguir.

Lo primero cargamos los 5 niveles con sus respectivos subniveles en un panel 5 veces el tamaño

de la pantalla (en la imagen sólo se han dibujado 3 para mejorar su visionado). Cada vez que el

46

usuario desliza el dedo movemos ese panel de izquierda a derecha. Cuando suelta el dedo

colocamos el panel centrándolo en la pantalla con un efecto muelle.

Ilustración 35. Captura SlidePanel

11.2.2 Memory sound

El juego Memory Sound, consiste en unir parejas de cartas iguales en diseño y en sonido. El

objetivo principal de este juego es que los usuarios se familiaricen con los distintos sonidos de

las escalas además de ubicarlos en su correspondiente lugar en el pentagrama.

11.2.2.1 Diseño

El diseño de las cartas tenía que ser por un lado un pentagrama con la nota que estaba sonando

y por el otro lado un reverso de carta normal.

Finalmente se decidió este diseño de las cartas:

Ilustración 36. Diseño de las cartas. MemorySound

La complejidad radica en que las cartas se tienen que dibujar de forma dinámica según la nota

que le corresponda a esa carta. Más adelante se ve en profundidad este apartado simplemente

adelantar que una carta se forma por varias partes:

- La clave (en la imagen la clave de Sol)

- La tonalidad (en la imagen, tonalidad Do Mayor, no tiene alteraciones (sostenidos,

bemoles…).

- Un conjunto de notas. Podemos poner una nota individual como en el caso de la imagen

que hay un Mi en escala 4ª, pero se pueden mostrar hasta 3, formando un intervalo.

47

Ilustración 37. Carta con varias notas

En un primer momento se planteó el juego como 2D ya que un juego en 3D tiene mayores

dificultades técnicas que no iba a dar tiempo a abordar en este proyecto. En cualquier caso,

como se analizará en un punto posterior, al no conseguir el efecto deseado en 2D se tuvo que

plantear la opción de desarrollarlo en 3D. Aunque finalmente se desechara esta opción.

11.2.2.2 Flujo del juego

Los juegos de Touching Music, se dividen en varios niveles, y cada nivel a su vez en varios

subniveles. Se empezará el juego en el nivel 1, subnivel 1 y se irá avanzando en los subniveles

hasta completar todos los del nivel actual, una vez completos estos se avanzará al nivel posterior

y así sucesivamente.

Para entender mejor la lógica de estas pantallas, se presenta a continuación el diagrama de flujo

correspondiente.

48

Ilustración 38. Diagrama de flujo. MemorySound

El modo de funcionamiento del juego es el siguiente: Una vez dispuestas las cartas en la pantalla,

el usuario puede empezar a girar cartas. Cuando gire una carta la nota correspondiente sonará.

A la segunda carta que gire, si coincide con la anterior habrá acertado la pareja y se mantendrán

Inicializar escena, selector de nivel

Carga del contenido del nivel (fichero

.xml)

Distribución de las cartas en pantalla

Iniciamos tablero nº intentos

Comienza el juego

El usuario voltea una pareja de cartas

¿Coinciden las cartas?

Se descubren las dos cartas y se hacen

desaparecer

¿Quedan cartas en juego?

No

Se mantienen las dos cartas

momentáneamente y se voltean de

nuevo

Si

Sumamos puntuación

No

Mostramos escena final, tiempo, puntuación y botones para

siguiente nivel o salir al menú

49

las dos cartas descubiertas. Si no coinciden, entonces se volverán a voltear automáticamente las

dos quedándose boca abajo. El juego termina cuando descubra todas las parejas del juego.

Captura del momento inicial del juego, antes de descubrir ninguna carta:

Ilustración 39. Captura inicial del juego MemorySound

Después de 4 intentos, se ha descubierto una pareja de cartas:

Ilustración 40. Captura MemorySound en juego

11.2.2.3 Desarrollo

WaveEngine es un motor de juegos con una arquitectura basada en componentes. Esto quiere

decir, que cada elemento del juego se representa como un conjunto de componentes y cada

uno de ellos, dota a la entidad que se está construyendo de unas características propias.

50

Este tipo de desarrollo basado en componentes es algo novedoso que se está empezando a

implementar en los nuevos motores de juegos. Este sistema permite crear con el mismo motor

diferentes tipos de juegos. Los componentes se dividen en varios tipos:

- Componentes (Almacena información, como la posición del objeto).

- Comportamientos (Componentes que pueden actualizarse)

- Dibujables (Pintan elementos en pantalla)

Una de las características del motor, es que se puede representar cada objeto del juego como

una entidad, que se forma a partir de diferentes tipos de objetos, componentes,

comportamientos, … Para representar una carta, se sigue este mismo camino. Se representa una

carta como una entidad a la que le vas añadiendo diferentes componentes para formar

finalmente el objeto necesario. En este caso:

entity = new Entity("Card" + instances) .AddComponent(new Transform2D()) .AddComponent(new RectangleCollider()) .AddComponent(new TouchGestures()) .AddComponent(new PanelControl(205, 147) { Margin = new Thickness(10) }) .AddComponent(new PanelControlRenderer()) .AddComponent(new AnimationUI()) .AddComponent(new CardBehavior //SIDE UP .AddChild(new Entity("CardUp") .AddComponent(new Transform2D()) .AddComponent(new RectangleCollider()) .AddComponent(new GridControl(205, 147)) .AddComponent(new GridRenderer()) .AddComponent(new AnimationUI())); //SIDE DOWN .AddChild(new Entity("CardDown") .AddComponent(new Transform2D()) .AddComponent(new RectangleCollider()) .AddComponent(new GridControl(205, 147)) .AddComponent(new GridRenderer()) .AddComponent(new AnimationUI()));

El código anterior representa una entidad en 2D con un comportamiento creado especialmente

para las cartas (CardBehavior). En este comportamiento se controlan los estados de las cartas

del juego, si está boca arriba, o boca abajo, si está resuelta o pendiente… y se muestran las

animaciones correspondientes entre los cambios de estado.

El contenido del nivel se carga de un Xml creado con anterioridad. Se han creado tantos ficheros

Xml como niveles tiene el juego. Cada nivel va aumentando en complejidad.

El Xml del primer nivel y subnivel deserializado se vería así

List<ScreenLevel> screenLevel1 = new List<ScreenLevel>() { new ScreenLevel(){ LevelNumber = 1, Cards = new List<Card>() {

Card (cardBehavior)

SideDown

• Image

SideUp

• Image

• Notes

51

new Card(){ Clef = Clef.Sol, Tonality = TonalityName.DoM, Notes = new List<NoteScale>(){new NoteScale(){ Note = Note.Do, Scale = 4}}}, new Card(){ Clef = Clef.Sol, Tonality = TonalityName.DoM, Notes = new List<NoteScale>(){new NoteScale(){ Note = Note.Re, Scale = 4}}}, new Card(){ Clef = Clef.Sol, Tonality = TonalityName.DoM, Notes = new List<NoteScale>(){new NoteScale(){ Note = Note.Mi, Scale = 4}}}, new Card(){ Clef = Clef.Sol, Tonality = TonalityName.DoM, Notes = new List<NoteScale>(){new NoteScale(){ Note = Note.Fa, Scale = 4}}}, new Card(){ Clef = Clef.Sol, Tonality = TonalityName.DoM, Notes = new List<NoteScale>(){new NoteScale(){ Note = Note.Sol, Scale = 4}}}, new Card(){ Clef = Clef.Sol, Tonality = TonalityName.DoM, Notes = new List<NoteScale>(){new NoteScale(){ Note = Note.La, Scale = 4}}} }} };

Una vez elegido el nivel y subnivel al que se quiere jugar, se carga del fichero XML

correspondiente el contenido del nivel. En el fichero se establece el número de cartas que se

tienen que dibujar y qué notas corresponden a cada carta.

Una nota se caracteriza por las siguientes propiedades:

- El nombre de la nota (Do, Re, Mi…)

- La escala en la que se encuentra (3ª, 4ª, 5ª…)

En una misma carta se pueden representar varias notas (de una a tres notas). Una carta viene

dada por las siguientes propiedades:

- Clave (de Sol, de Fa, de Do)

- Tonalidad (Do menor, Do Mayor, Sol Mayor…)

- Notas. Cada nota representada como se ha comentado en el punto anterior.

Para poder gestionar todas estas características relacionadas con la música, se han creado una

serie de clases y enumeraciones. Por ejemplo, para las notas de la escala musical se ha creado

una enumeración (Do, Re, Mi, Fa, Sol, La, Si). Otro ejemplo, para identificar una nota en el

pentagrama, se ha creado una clase con la nota (la enumeración anterior) y la escala en la que

está (un entero).

Con esta lógica, creamos una clase que representa la escena entera del juego. Como ya tenemos

el contenido de las cartas que tenemos que cargar, creamos las entidades de las cartas

pasándoles como parámetro la clase Card deserializada del Xml que les corresponden.

Insertamos las cartas en un panel de tipo WrapPanel. Este tipo de panel distribuye su contenido

de forma ordenada en función del espacio que ocupa. De la siguiente forma:

52

Ilustración 41. Diagrama de un WrapPanel

Lo cual es perfecto para representar nuestro panel con las cartas. Además del panel central se

crean los botones de ir atrás y el panel con el número de intentos.

El único problema que tiene esta solución en 2D es que no se puede dar el efecto de volteo muy

realista. Porque para eso es necesario un giro en el eje Z, algo característico de un objeto en 3D.

Para el efecto de transición en el volteo de cara, se ha hecho una transición de opacidad entre

los dos lados.

Una vez conseguida esta solución en 2D se plantea la posibilidad de realizarla en 3D

aprovechando toda la lógica que ya está desarrollada para el tipo en 2D decide realizar la

solución en 3D. Con el propósito de hacer lo mejor posible el juego y que tenga la mejor

apariencia posible. Pero después de varios intentos infructuosos se decide descontinuar esta vía

y seguir el desarrollo en 2D para no comprometer el resultado final del proyecto.

11.2.3 Idioma de la aplicación

Esta historia de usuario se quedó pendiente del sprint anterior. Si bien ya estaba claro cómo se

iba a representar en la interfaz gráfica faltaba incluir la lógica del idioma en el código.

Para ello se pensó en una solución basada en el patrón de diseño Façade. El patrón Façade

implementa un punto de entrada único a una estructura compleja. De esta forma a través de la

clase ResourceLanguage podemos acceder al lenguaje actual y buscar el texto correspondiente.

HIJO 1 HIJO 2 HIJO 3

HIJO 4 HIJO 5

WrapPanel

53

Ilustración 42. Diagrama de clases para la internacionalización

De esta forma, se definen una serie de constantes (enumeración ResourceNamesKey) que

representan cada texto que se expone en el juego y se guardan en clases separadas los textos

asociados a cada constante, de cada idioma.

Como ejemplo vemos una parte de la clase SpanishResourceNames

public class SpanishResourceNames : IResourceName { private Dictionary<ResourceNamesKey, string> names = new Dictionary<ResourceNamesKey, string>(); public SpanishResourceNames() { names.Add(ResourceNamesKey.MENU_TAPTOCONTINUE, "Toca o haz click para continuar"); names.Add(ResourceNamesKey.SCENE_CONFIG_TITLE, "Configuracion"); //... } public string GetString(ResourceNamesKey key) { return this.names[key]; } }

Para acceder a un recurso concreto entonces:

Text = ResourceLanguage.GetString(ResourceNamesKey.LOADING);

El idioma es una de las propiedades que se almacena en un fichero .Xml de configuración. Así

una vez seleccionado el idioma se guarda para posteriores ejecuciones.

54

Si en algún momento se quiere añadir otro idioma, simplemente crearíamos una clase con el

idioma nuevo que implemente la interfaz, y llenamos el diccionario de recursos con los textos

en el idioma. No habría que tocar el resto del juego.

11.3 REVISIÓN DEL SPRINT / BURNDOWN Este sprint ha terminado de acuerdo a lo planificado. Con todas las tareas que se pusieron como

objetivo terminadas.

La primera historia que se abordó en este sprint fue la pantalla de configuración. Estaba

pendiente la parte del idioma y se concluyó en el tiempo estimado.

La pantalla de selección de niveles también se pudo completar. Esta pantalla se aprovechará a

partir de ahora en el resto de juegos.

En la planificación inicial que se hizo para el sprint 3 el objetivo principal era tener el juego

Memory Sound terminado. Como se han tenido que abordar tareas que se llevaban retrasadas

de sprints anteriores hubo una replanificación al inicio del sprint quitando tareas del juego, para

futuras iteraciones.

Una vez concluido este sprint se han tomado alguna decisión que cambiarán los siguientes

sprints. Se hizo una previsión muy optimista del desarrollo del juego en la planificación inicial.

No se tuvo en cuenta algún impedimento importante que ha hecho retrasarse más de la cuenta,

como por ejemplo el hecho de que el motor de juegos utilizado, WaveEngine, está en fase beta.

No hay apenas documentación y cada pequeño problema se hace muy grande y la solución se

alarga en el tiempo más de lo previsto.

Con todo ello se ha decidido centrar más el desarrollo en lo que ya está definido. Dejar todas las

pantallas acabadas, ajustadas a la multiplataforma y no pretender abarcar todo lo previsto en

un primer momento.

Así que para los próximos sprints, se cerrarán todas las tareas que hay abiertas y se probará lo

realizado hasta el momento en las plataformas Windows 8 y Windows Phone. Se considera que

los puntos fuertes del proyecto son el carácter multiplataforma del juego y la solución del

servicio backend.

Vemos a continuación el estado de las tareas al final del sprint y el gráfico burndown.

55


Ilustración 44. Panel SCRUM final sprint 3

56

12 SPRINT 4

12.1 DESCRIPCIÓN Este sprint se desarrolló desde el 22 de abril hasta el 12 de mayo

Como se ha explicado en el punto anterior, una vez concluido el sprint 3 se tuvo que rediseñar

el Sprint 4 con todas las historias de usuario acumuladas hasta este momento que no se habían

podido completar.

En el tiempo que quedaba libre por cubrir en el sprint, se decide que en vez de empezar un juego

para dejarlo sin terminar, se va a probar un servicio llamado ScoreOID. Si las pruebas son buenas,

se incluirá también como backend dando alternativa gratuita a Azure.

12.2 SPRINT BACKLOG

Ilustración 45. Panel SCRUM backlog sprint 4

57


Entran por tanto de nuevo en este sprint, la creación de usuarios y su sincronización con la nube.

Completar las pantallas del juego Memory Sound y la pantalla común a todos los juegos de nivel

completado.

12.2.1 Pantalla Usuarios

Aunque en el sprint 2 se empezó el desarrollo de esta pantalla, se tuvo que abandonar por el

momento al encontrar un bug en el motor WaveEngine. En el foro de la plataforma, les dimos

feedback del problema y tras un mes y varias versiones después, solucionaron el bug.

Ilustración 47. Respuesta en el foro de WaveEngine

Una vez solucionado el problema que impedía añadir elementos hijos de forma dinámica a una

entidad se continúa con la pantalla de usuarios en este sprint.

La pantalla de usuarios debe permitir:

- Seleccionar un usuario existente para empezar a jugar con él.

- Poder loguearse frente al servicio para obtener un usuario que si bien existe en el

servicio, no está disponible en el dispositivo. Puede pasar esto si un usuario se da de alta

en un dispositivo pero luego quiere jugar en otro.

- Crear un usuario nuevo en el servicio y guardarlo en local en el dispositivo.

- Desvincular el usuario del dispositivo.

58

Para el diseño de la pantalla se decide una solución que aprovecha uno de los componentes

creados para otra pantalla, el panel deslizante.

De esta forma se decide mostrar cada usuario existente en el dispositivo de forma local en una

pantalla, como se ve en la siguiente captura:

Ilustración 48. Captura 1 pantalla usuarios

Al final de los usuarios existentes, se mostrará una pantalla en la que el usuario pueda hacer

login en el juego para traerse un usuario existente en el servicio o pueda crear el usuario nuevo.

Como se ve en la siguiente captura:

Ilustración 49. Captura 2 pantalla usuarios

En el caso de no existir ningún usuario, se mostrará únicamente esta pantalla.

59

Si el usuario pulsa en el botón de login le aparecerá la siguiente pantalla:

Ilustración 50. Captura login, pantalla usuarios

En esta pantalla el usuario podrá escribir su nombre de usuario y contraseña y al darle al botón

de aceptar se inicia el proceso de autenticación contra el servicio backend.

Si el usuario existe y la contraseña es correcta, se descargan todos los datos del usuario, incluida

la información de los niveles actuales de los juegos. Mientras se descarga la información se crea

una nueva pantalla para el usuario recién descargado, para que el usuario pueda seleccionar ese

jugador como el jugador actual y empezar a jugar.

Si el usuario quiere crear un nuevo jugador, pulsará entonces en el botón y le aparecerá la

siguiente pantalla:

60

Ilustración 51. Crear usuario, pantalla usuarios

Con este formulario el usuario rellenará los datos necesarios para crear al nuevo jugador y

pulsará en el botón de Aceptar. Empieza entonces el proceso de creación de nuevo jugador

frente al servicio. El servicio puede devolver aquí varios resultados.

- Que exista ya un jugador con ese nombre de usuario. Por tanto no se puede crear el

nuevo jugador y deberá elegir otro nombre de usuario.

- Si el nombre de usuario está disponible y todos los campos rellenos correctamente el

servició devolverá un OK y por tanto el usuario se ha creado correctamente. En ese caso

se almacenará un nuevo usuario en local al dispositivo y se creará una pantalla como en

el caso del login, para que el usuario pueda seleccionarlo y empezar a jugar.

Estas operaciones se ejecutan a partir de las funciones creadas en el servicio web construido en

el sprint 2.

Con todo esto, la pantalla de usuarios queda terminada.

12.2.2 Pantalla final de nivel

Cuando terminamos un subnivel o nivel de cualquiera de los juegos, tiene que aparecer una

pantalla que nos dé información sobre la puntuación, número de intentos y varias opciones que

nos permitan avanzar al próximo nivel/subnivel, repetir el nivel o volver al menú anterior.

Para este propósito se ha diseñado una pantalla como la siguiente, en la que aparecen estos

elementos:

Botón para volver al menú principal

61

Botón para repetir el nivel actual

Botón para avanzar de nivel

Además de estos elementos aparecerán la puntuación conseguida, la acumulada o los logros

conseguidos, pero esto se terminará en el próximo sprint.

Actualmente la apariencia de la pantalla se vería así:

Ilustración 52. Pantalla nivel completo inacabada

En el próximo sprint se completará la puntuación de la pantalla y se mostrarán los logros y el

tiempo conseguido.

12.2.3 Scoreoid

Seleccionamos Windows Azure desde un primer momento como servicio backend del juego.

Windows Azure tiene una pega, es de pago. Para programadores Indie, o para juegos gratuitos

o que no se sabe si van a resultar, tener una cuota mensual puede ser un hándicap que a la larga

puede hacer que se pare el servicio.

Se buscaron alternativas a Windows Azure con dos fines. Probar la independencia del servicio

backend programada atacando a dos servicios diferentes y si resultaba cambiar el servicio para

mantenerlo finalmente con una alternativa gratuita.

Una muy buena alternativa era ScoreOID, un servicio pensado exclusivamente para hacer de

backend de videojuegos. Además es gratuito y funciona sobre Windows. La única pega que tiene

62

el servicio a día de hoy es que está en fase Beta y todavía no está implementada toda la

funcionalidad. En cualquier caso para las necesidades actuales del juego Touching Music es

suficiente.

La integración con este servicio es, como en el caso de Azure, a través de su API REST, así que

perfecto para nuestro propósito, teniendo en cuenta, como se comentó en el sprint 1, que no

podemos usar ningún API nativo dado el carácter multiplataforma del juego.

Otra de las ventajas que tiene ScoreOID frente a un servicio Azure normal, como el que se creó

en los primeros sprints, es que ofrece un panel de control en el que se puede ver toda la

información del juego. Jugadores, máximas puntuaciones, puntuaciones medias,

notificaciones…

En la imagen siguiente se ve la página principal del portal:

Ilustración 53. Dashboard portal ScoreOID

Se ha creado un nuevo juego en el portal, llamado Touching Music. Con un identificador único

del juego y junto con la clave del API que se nos proveyó al darnos de alta en el portal podremos

autenticarnos desde las llamadas al API REST.

El portal ofrece una muy buena funcionalidad para probar el resultado de las consultas. Dispone

de una consola como se ve en la imagen siguiente en la que se pueden consultar todas las

funciones disponibles del servicio. Los resultados que devuelven las funciones del servicio se

recogen en un XML.

63

Ilustración 54. Consola servicio ScoreOID

Como el servicio se montó sobre una interfaz que exponía los métodos del servicio, únicamente

se tuvo que implementar dicha interfaz para el servicio ScoreOID. Las funciones que se

implementaron eran muy sencillas y se parecían muchísimo entre los dos servicios así que fue

bastante sencillo su implementación

public class ScoreoidService : TouchingMusicService { private const string api_key = "…ad497433c…"; private const string game_id = "78cb…"; private const string uri = "https://www.scoreoid.com/api/"; public override void CreateUserAsync(Helpers.User user) { string post_data = "api_key=" + api_key + "&game_id=" + game_id + "&response=XML&username=" + user.UserName + "&response=XML&password=" + user.Password + "&response=XML&email=" + user.Email + "&response=XML&name=" + user.Name + "&response=XML&lastname=" + user.LastName; string uri = "https://www.scoreoid.com/api/createPlayer"; ScoreRequests<string> postOfflineScore = new ScoreRequests<string>(); postOfflineScore.RequestSuccessful += postScore_RequestSuccessful; postOfflineScore.ProcessRequest<player>(uri, post_data); }

... }

public abstract class TouchingMusicService : Service, ITouchingMusicService

64

{ public event EventHandler<ServerEventArgs<bool>> CreateUserCompleted; public virtual void CreateUserAsync(User user) { } public virtual void OnCreateUserCompleted(object sender, ServerEventArgs<bool> e) { if (CreateUserCompleted != null) { CreateUserCompleted(this, e); } } ...

}

12.3 REVISIÓN DEL SPRINT / BURNDOWN Con la replanificación que se hizo del sprint, se consiguió acabar casi todas las historias de

usuario que teníamos pendiente. Sólo se quedó una historia de usuario sin terminar para el

siguiente sprint, la pantalla final de nivel.

El sprint se comenzó con la tarea de la pantalla de usuarios. Además de terminar esta pantalla

se aprovechó para probar otro servicio backend, que funcionaría en sustitución del servicio

Windows Azure. Con este servicio llamado ScoreOID, además de ser gratuito, se demuestra la

independencia del código del juego con el servicio.

Una vez terminada estas historias, se continuó con la historia del juego Memory Sound, se

terminó de definir las pruebas de todos los niveles, serializándolas en un fichero XML. Y se quedó

pendiente parte de la historia de usuario sobre la pantalla de final de nivel. Esta pantalla aunque

en este punto es funcional, no muestra los datos que se consideran necesarios para darla por

terminada. Se queda pendiente para el siguiente sprint.

Ilustración 55. Panel final sprint 4

65


66

13 SPRINT 5

13.1 DESCRIPCIÓN Este sprint comprendió las fechas entre el 13 de mayo y el 2 de junio.

En esta última fase se va a abordar la tarea pendiente del anterior sprint que formaba parte del

juego Memory Sound. Para completarlo se va a incluir la última tarea, sobre la puntuación del

juego.

Se va a realizar también el desarrollo sobre los logros del usuario. El diseño de los logros, su

gestión dentro del juego y su actualización en el perfil del usuario.

Por último se va a intentar incluir un cuadro en el juego para la publicidad.

13.2 SPRINT BACKLOG

Ilustración 57. Panel SCRUM backlog sprint 5

67


13.2.1 Juego memoria musical

Continuando con lo que se quedó pendiente en el sprint 4 abordamos el desarrollo final de la

pantalla del juego.

Se quedó pendiente incluir las puntuaciones y alguna cosa más. Así que para poder completar

esta pantalla se aborda primero la tarea de puntuación.

En un juego de tipo memory, el factor que permite valorar lo bien o mal que se ha hecho, es el

número de intentos que le ha llevado al jugador descubrir todas las cartas de la pantalla. En

otro tipo de juegos el tiempo en resolver la pantalla puede ser determinante pero no en este

caso. Así que la puntuación del juego se tiene que basar en el número de intentos.

Cada vez que incrementa el número de intentos menos puntuación hay que darle al usuario,

así que se parte una cifra fijada en el juego de 5000 puntos y por cada intento se bajan 100

puntos.

Estas cifras no son totalmente aleatorias. Se estima, después de muchas pruebas, que a un

adulto le cuesta unos 15 intentos resolver un juego de memoria. Esto nos da bastante margen

hasta 50 intentos para que un niño pueda sumar puntos por cada pantalla.

Una característica importante que tenía que tener esta pantalla, era que sirviese para el resto

de juegos. Para eso se tenía que aislar el desarrollo de la pantalla de la escena del juego de

memoria. Además los botones de acción de la pantalla tendrían que responder en función del

juego que la invocaba.

Para esto se creó la siguiente arquitectura de clases con bajo acoplamiento entre ellas:

68

Ilustración 59. Diagrama de clases lógica del juego

En el diagrama se ven las siguientes clases:

- ILogicGame: Interfaz con varios métodos y propiedades con lo necesario para poder

abstraer la lógica del juego.

- MemorySoundLogicGame: es la lógica del juego Memory Sound, implementa la

interfaz anterior y es la intermediaria entre la pantalla del juego y la interfaz. Aquí se

calcula la puntuación del juego y se dibuja lo necesario en la escena de nivel completo.

- MemorySoundScene: la pantalla del juego.

- SceneLevelCompleted: Es la escena que aparece cuando se termina el nivel actual.

Esta escena sólo necesita una clase que implemente la interfaz para funcionar.

Con esta arquitectura conseguimos una baja cohesión entre las clases que nos permite

reutilizar la escena de nivel completado en todos los juegos.

En la captura siguiente se ve el resultado final de la pantalla.

69

Ilustración 60. captura final nivel completado

13.2.2 Pantalla logros del usuario

Uno de los objetivos marcados inicialmente era que según avanzaba el juego, el jugador

pudiera obtener unas medallas (logros, badges…) en función de unos objetivos específicos.

Dado que en el juego hay cuatro áreas se pensó en crear varios logros por área y una sección

general para la puntuación total.

Con esto en mente se diseñaron los siguientes badges:

Para la categoría general:

Los badges en la categoría general se consiguen en función de los puntos obtenidos. A los

5000, 10000, 25000 y 50000 puntos.

Para el área oir se otorgarán los siguientes badges en función de:

Se consigue si se encadena una buena jugada en alguno de los juegos del área Oir. En el caso del juego Memory Sound, se conseguirá si se descubren 4 parejas seguidas.

70

Se consigue si se hace una partida perfecta en uno de los juegos del área Oir

Se consigue cuando se llega a la mitad de niveles en todos los juegos que forman el área oir.

Se consigue cuando se terminan todos los niveles de todos los juegos del área.

El dato sobre los logros conseguidos se guarda en el perfil del usuario, por tanto una vez que

se guarda la partida se lleva con el perfil el dato de los logros obtenidos. Estas funciones están

creadas desde sprints anteriores así que sólo se ha tenido que crear el diseño de la pantalla.

Para la distribución de la pantalla se ha creado una rejilla invisible y se ha situado cada área en

una fila y los badges situados en las columnas. Vemos a continuación una captura de la

pantalla:

Ilustración 61. Captura logros del usuario

71

El resto de logros se diseñarán cuando se implemente el resto de áreas. Seguirán la estética de

los logros ya creados.

13.2.3 Publicidad

Como última tarea del proyecto se quiso estudiar la posibilidad de incluir una caja de

publicidad en el juego. En la página web del motor WaveEngine se hablaba de la posibilidad de

hacerlo e incluso hay una aplicación llamada Ads Settings Manager:

Ilustración 62. Ads Settings Manager de WaveEngine

Sin embargo después de estudiar la librería y preguntar en el foro, se tuvo que dejar de

momento esta tarea para más adelante. Se nos informó que en la beta todavía no tienen

implementado esta funcionalidad.

13.3 REVISIÓN DEL SPRINT / BURNDOWN En este sprint se terminó de dar forma a la parte del juego que estaba prevista para el proyecto.

En esta fase se incluía la historia de usuario correspondiente a la pantalla final del nivel. Esta

historia venía arrastrada del anterior sprint. No quedaba mucho por hacer así que se completó

en el tiempo estimado, con los resultados esperados.

Además se hicieron el diseño de los logros y la gestión de los mismos con el perfil del usuario.

Esta historia se completó de acuerdo con la estimación, no aportaba ninguna novedad en el

desarrollo y se pudo completar en el tiempo previsto.

Se tuvo que posponer la creación de la caja de publicidad por no estar todavía desarrollado en

el motor, pero se implementará en cuanto esté desarrollada, porque es un punto clave en la

monetización de la aplicación en las tiendas de las plataformas móviles.

A continuación se muestra el panel Scrum con los resultados del último sprint y el burndown

final.

72

Ilustración 63. Panel SCRUM, fin sprint 5


73

14 CONCLUSIONES

Este proyecto ha resultado muy satisfactorio en todos los aspectos. Se han conseguido todos los

objetivos propuestos desde un inicio y se ha dejado una buena base para continuar extendiendo

el juego y completando su funcionalidad.

El primer objetivo era enfrentarse a la creación de un juego de inicio a fin. Así se ha hecho, desde

los gráficos o la música hasta el desarrollo completo del juego.

He aprendido a manejar gráficos vectoriales, a crear animaciones con sprites, a programar en

un motor de juegos,… en definitiva, a gestionar todos los elementos que un juego tiene a su

alrededor, que son muchos.

Otro de los objetivos conseguidos era estudiar la plataforma Windows Azure. Al desarrollarse el

backend del juego en dicha plataforma se ha profundizado y aprendido mucho al respecto.

Como efecto colateral positivo, he aprendido mucho de lenguaje musical, con toda la lógica que

se ha tenido que implementar, lo cual también es placentero.

Después de varios meses de intenso trabajo estoy muy satisfecho con el resultado obtenido.

74

15 FUTURO

El resultado de este proyecto forma parte de un proyecto más ambicioso.

Durante estos meses se ha desarrollado una muy buena base del juego, se han creado los

cimientos de lo que en un futuro será un juego completo, comercial, y sobre todo educativo.

En este proyecto sólo se ha podido abordar un pequeño juego para una de las cuatro secciones

que lo forman. Este juego, Memory Sound, forma parte del área Oir. En un futuro cercano se

quiere añadir varios minijuegos más correspondientes al resto de secciones Cantar, Tocar y

Leer…

Ya se tiene en mente varios de estos juegos, como ejemplo se presentan dos brevemente.

Uno de los juegos se llamará “Repite el ritmo” y pertenecerá al área Tocar. Este juego tratará de

que el jugador repita el ritmo que sonará en cada nivel, se verá el ritmo en una línea del

pentagrama y se marcará el ritmo con un metrónomo digital. Se puede apreciar en la siguiente

imagen, como prototipo para el juego:

Ilustración 65. Captura previa juego "repite el ritmo"

Otro de los juegos que está en el tintero pertenece a la sección Cantar y se llamará Puzzle

musical. El juego tratará de que el jugador componga un puzzle con trocitos de una canción,

colocando cada pieza en su sitio para que suene la canción de forma correcta. En la siguiente

imagen se puede apreciar un adelanto de lo que será el juego:

75

Ilustración 66. Captura previa juego "completa la canción"

Uno de los objetivos a futuro, es sacar el juego en varios mercados de aplicaciones móviles. Se

empezará con el Marketplace de Windows 8 y Windows Phone al tener ya la aplicación

funcionando en estas plataformas. Pero en función de los resultados y el interés del público se

irán aumentando las plataformas disponibles a iOS y Android.

En cualquier caso para poder salir al mercado se terminarán por lo menos un juego de cada

sección para posteriormente ir aumentando los niveles.

No se descarta tampoco la adecuación del juego para mayores edades a las pensadas

inicialmente. Simplemente cambiando el diseño gráfico del juego y el contenido sonoro. Además

de adecuar también los niveles de dificultad.

76

16 REFERENCIAS

Finale: es un editor de partituras, es decir un programa completo para escribir, ejecutar,

imprimir y publicar partituras de música. Fue creado por la empresa MakeMusic. Está diseñado

para toda clase de músicos, desde estudiantes y profesores hasta compositores profesionales.

http://www.finalemusic.com/

Juegos Indie: son videojuegos creados por individuos o pequeños grupos, sin apoyo financiero

de distribuidores. Los videojuegos independientes a menudo se centran en la innovación y se

basan en la distribución digital. Los juegos indie han visto un aumento en los últimos años,

principalmente debido a los nuevos métodos de distribución en línea y herramientas de

desarrollo.

http://es.wikipedia.org/wiki/Indie_game

Inkscape: es un editor de gráficos en formato vectoriales SVG, gratuito, libre y multiplataforma.

Las características de SVG soportadas incluyen formas básicas, trayectorias, texto, canal alfa,

transformaciones, gradientes, edición de nodos, exportación de SVG a PNG, agrupación de

elementos, etc.

http://inkscape.org/

Metodología ágil: El desarrollo ágil de software son métodos de ingeniería del software basados

en el desarrollo iterativo e incremental, donde los requerimientos y soluciones evolucionan

mediante la colaboración de grupos auto organizados y multidisciplinarios. Existen muchos

métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en lapsos cortos.

El software desarrollado en una unidad de tiempo es llamado una iteración, la cual debe durar

de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de

requerimientos, diseño, codificación, revisión y documentación. Una iteración no debe agregar

demasiada funcionalidad para justificar el lanzamiento del producto al mercado, sino que la

meta es tener una «demo» (sin errores) al final de cada iteración. Al final de cada iteración el

equipo vuelve a evaluar las prioridades del proyecto.

http://es.wikipedia.org/wiki/Metodolog%C3%ADa_%C3%A1gil

ScoreOID: Es un servicio creado por y para desarrolladores de videojuegos y se utiliza como

backend para los juegos. Puede gestionar varios juegos, usuarios, puntuaciones, notificaciones

todo a través de un API REST o desde implementaciones nativas en varias plataformas.

http://www.scoreoid.com

Scrum: Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas

prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de

un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de

la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el

beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado

para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los

requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la

flexibilidad y la productividad son fundamentales.

http://www.finalemusic.com/

http://es.wikipedia.org/wiki/Indie_game

http://inkscape.org/

http://es.wikipedia.org/wiki/Metodolog%C3%ADa_%C3%A1gil

http://www.scoreoid.com/

77

http://www.proyectosagiles.org/que-es-scrum

Team Foundation Service: Servicio ALM de Microsoft, desde el que se puede gestionar el ciclo

de vida completo de una aplicación. Es un servicio web accesible desde cualquier lugar, y

gratuito para equipos pequeños. Con él se puede gestionar un proyecto desde la planificación

de tareas y sprints, gestión del código fuente, integración continua, pruebas del software, etc.

http://tfs.visualstudio.com

Texture Packer GUI: Herramienta para crear sprite sheets a partir de imágenes sueltas. Es de

pago pero tiene una versión pequeña gratuita.

http://www.codeandweb.com/texturepacker

Visual Studio: es un entorno de desarrollo integrado (IDE, por sus siglas en inglés) para sistemas

operativos Windows. Soporta varios lenguajes de programación tales como Visual C++, Visual

C#, Visual J#, y Visual Basic .NET, al igual que entornos de desarrollo web como ASP.NET. aunque

actualmente se han desarrollado las extensiones necesarias para muchos otros.

Visual Studio permite a los desarrolladores crear aplicaciones, sitios y aplicaciones web, así como

servicios web en cualquier entorno que soporte la plataforma .NET (a partir de la versión .NET

2002). Así se pueden crear aplicaciones que se intercomuniquen entre estaciones de trabajo,

páginas web y dispositivos móviles.

http://www.microsoft.com/visualstudio

WaveEngine: WaveEngine es la solución definitiva para el desarrollo de juegos multiplataforma

en C#. Proporciona todas las herramientas necesarias para crear juegos en 3D o 2D en muy

diversas plataformas de hardware:

- Unifica el acceso a los sensores de los dispositivos y capacidades,

- Integra un motor de física de 2D y 3D,

- Provee de un editor de juego poderoso,

- Se integra con Visual Studio,

- y está diseñado como un Fluent API.

http://www.waveengine.net/

Windows Azure: es una plataforma en la nube abierta y flexible que permite compilar,

implementar y administrar aplicaciones rápidamente, en una red global de centros de datos

administrados por Microsoft. Puede compilar aplicaciones en cualquier lenguaje, herramienta o

marco. Y puede integrar sus aplicaciones de nube públicas con el entorno de TI existente.

http://www.windowsazure.com

http://www.proyectosagiles.org/que-es-scrum

http://tfs.visualstudio.com/

http://www.codeandweb.com/texturepacker

http://www.microsoft.com/visualstudio

http://www.waveengine.net/

http://www.windowsazure.com/

Touching music: juego educativo musical multiplataforma

Documents

Transcript of Touching music: juego educativo musical multiplataforma