battlex: juego de estrategia por turnos basado en comunicación
TRANSCRIPT
UNIVERSIDAD DE CASTILLA-LA MANCHAESCUELA SUPERIOR DE INFORMÁTICA
GRADO EN INGENIERÍA INFORMÁTICA
TECNOLOGÍA ESPECÍFICA DETECNOLOGÍAS Y SISTEMAS DE INFORMACIÓN
TRABAJO FIN DE GRADO
Battlex: Juego de estrategia por turnos basado encomunicación asíncrona para plataforma iOS
Miguel Ángel Aragonés Castañeda
Septiembre, 2014
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
Tecnologías y Sistemas de Información
TECNOLOGÍA ESPECÍFICA DETECNOLOGÍAS Y SISTEMAS DE INFORMACIÓN
TRABAJO FIN DE GRADO
Battlex: Juego de estrategia por turnos basado encomunicación asíncrona para plataforma iOS
Autor: Miguel Ángel Aragonés Castañeda
Director: Dr. Ramón Hervás Lucas
Septiembre, 2014
Miguel Ángel Aragonés Castañeda
Ciudad Real – Spain
E-mail: [email protected]
c� 2014 Miguel Ángel Aragonés Castañeda
Permission is granted to copy, distribute and/or modify this document under the terms of the GNUFree Documentation License, Version 1.3 or any later version published by the Free SoftwareFoundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copyof the license is included in the section entitled "GNU Free Documentation License".Se permite la copia, distribución y/o modificación de este documento bajo los términos de laLicencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada porla Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida enel apéndice titulado «GNU Free Documentation License».Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios sonreclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, ycuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos enmayúsculas o como nombres propios.
i
TRIBUNAL:
Presidente:
Vocal:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE VOCAL SECRETARIO
Fdo.: Fdo.: Fdo.:
iii
Resumen
Hoy en día todo el mundo posee un smartphone y gracias a ellos los videojuegos socialesse están extendiendo cada vez más y más. Las redes sociales o aplicaciones de comunicaciónocupan la mayor parte del tiempo de uso de estos dispositivos, aunque las aplicaciones deocio las siguen muy de cerca. Podemos comunicarnos directamente con aplicaciones socia-les, a través de retos en videojuegos de ámbito social u otras que miden nuestra actividad yrealizan estadísticas con respecto a la de nuestros conocidos.
Aprovechando esas tecnologías, el presente trabajo pretende crear un videojuego asín-crono para plataforma iOS, heredando la temática de los juegos de estrategia basados enconquista de territorios. De este modo Battlex podrá ser jugado por todos los usuarios deiOS para disfrutar de partidas en modo multijugador asíncrono, con otras personas. Entoncesentrará en la categoría de juegos móviles sociales.
V
Abstract
Nowadays everyone has a smartphone, and thanks to them the social games are spreadingmore and more. Social networking and communication applications take up most of thetime to use these devices, although the entertainment applications closely follow. We cancommunicate directly with social applications through challenges in video games or othersocial area measuring and conduct our activity with respect to statistics people we know.
Taking advantage of these technologies, this paper intends to create an asynchronous gamefor iOS platform, inheriting themed strategy games based on territorial conquest. In this wayBattlex can be played by all users to enjoy iOS asynchronous multiplayer games with others.Then enter into the category of social mobile games.
VII
Agradecimientos
A mi madre, que por circunstancias de la vida, nos ha tenido que educar ella sola, a mihermana y a mí y a pesar de ello nos ha dado una gran educación.
A mi hermana, porque gran parte de lo que soy es gracias a ella.
A mi padre, que nos dejó demasiado pronto, a quien llevo siempre conmigo.
A mi novia, que tanto me ha ayudado en el día a día y que tanta paciencia tiene siempreconmigo.
A mis amigos y todas las personas que me quieren, porque también han puesto luz en elcamino.
A mis compañeros de trabajo, por los buenos consejos me dan todos los días.
Y Por último, pero no por ello menos importante, a mi director Ramón Hervás, por ayu-darme a hacer un sueño realidad con su apoyo en este trabajo, por su paciencia y el tratocercano que siempre ha tenido conmigo.
Miguel Ángel
IX
"La paciencia es un árbol de raíz amarga pero de frutos muy dulces"
xi
Índice general
Resumen V
Abstract VII
Agradecimientos IX
Índice general XIII
Índice de cuadros XVII
Índice de figuras XIX
Índice de listados XXIII
Listado de acrónimos XXV
1. Introducción 1
1.1. Contexto del TFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1. Contexto de la Computación Móvil . . . . . . . . . . . . . . . . . 1
1.1.2. Contexto de la Computación en la Nube . . . . . . . . . . . . . . . 1
1.1.3. Contexto de la Interacción Persona-Computador . . . . . . . . . . 2
1.1.4. Contexto de la Ludología . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Problema y solución propuesta . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Descripción del problema . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2. Solución propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . 5
2. Objetivos 7
2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Objetivos operativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
XIII
2.3.1. Analizar y seleccionar los lenguajes y frameworks gráficos óptimospara el TFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. Analizar, definir y adaptar las reglas del juego a desarrollar asegu-rando la jugabilidad del proyecto . . . . . . . . . . . . . . . . . . . 8
2.3.3. Diseñar e implementar escenas del juego . . . . . . . . . . . . . . 8
2.3.4. Diseñar e implementar la interfaz de usuario . . . . . . . . . . . . 8
2.3.5. Implementar el sistemas de persistencia de datos del juego . . . . . 8
2.3.6. Diseñar e implementar el sistema de notificaciones del juego . . . . 8
2.4. Herramientas utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. Lenguajes de programación y sistema operativo . . . . . . . . . . . 9
2.4.2. Medios Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.3. Medios Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Estado del arte 153.1. Juegos de Estrategia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1. Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2. Poker de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3. Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Aplicaciones Asíncronas . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Apalabrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2. Mezcladitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.3. Preguntados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.4. Triviados o Atríviate . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.5. Enumerados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.6. Temporis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1. Integradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2. No integradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4. Método de Trabajo 334.1. Metodología de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1. Programación Extrema . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.2. Historias de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2. Desarrollo del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1. Diseño de la Interfaz de Usuario . . . . . . . . . . . . . . . . . . . 35
4.2.2. Arquitectura de la aplicación . . . . . . . . . . . . . . . . . . . . . 39
xiv
4.3. Evolución del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1. 1a Etapa: Definición general y Anteproyecto . . . . . . . . . . . . . 48
4.3.2. 2a Etapa: Estudio previo . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.3. 3a Etapa: Implementación . . . . . . . . . . . . . . . . . . . . . . 49
4.3.4. 4a Etapa: Documentación . . . . . . . . . . . . . . . . . . . . . . . 53
4.4. Pruebas Realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.1. Pruebas de Compatibilidad . . . . . . . . . . . . . . . . . . . . . . 53
4.4.2. Pruebas de Jugabilidad . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.3. Pruebas de Funcionalidad . . . . . . . . . . . . . . . . . . . . . . 58
5. Resultado y Conclusiones 635.1. Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2. Aspectos Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.1. Adaptación de las reglas originales para crear una aplicaciónasíncrona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3. Objetivos Alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.1. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.2. Objetivos Operativos . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4. Limitaciones encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A. Parse 75A.1. Registro y Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.2. Panel de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.2.1. Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.2.2. Relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.2.3. Ventajas e Inconvenientes . . . . . . . . . . . . . . . . . . . . . . 78
B. Manual de Usuario 81B.1. Registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.2. Identificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.3. Menú Partidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
B.3.1. Opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
B.3.2. Nueva Partida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.3.3. Partidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.4. Situar Refuerzos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
xv
B.5. Configurar Ataque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
B.6. Fortificar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
C. Proyectos de Prueba 89C.1. Base de Datos: SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
C.2. Prueba de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
C.2.1. Interfaz de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 91
C.2.2. Registro en base de datos . . . . . . . . . . . . . . . . . . . . . . . 91
D. Formulario del Test de Jugabilidad 93
Referencias 97
xvi
Índice de cuadros
2.1. Game Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Estilo NavigationBar iOS6 frente iOS7 . . . . . . . . . . . . . . . . . . . . 36
XVII
Índice de figuras
1.1. Ilustración de computación en la nube utilizando dispositivos móviles . . . 2
2.1. Descargas frente a Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Descargas por categoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Apple iPhone 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. iPad Air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5. Capas de las que se compone Cocoa Touch . . . . . . . . . . . . . . . . . 12
2.6. XCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Combinaciones de Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Tablero de Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. Apalabrados, nuevo juego y perfil de usuario . . . . . . . . . . . . . . . . . 18
3.4. Apalabrados, tablero de juego . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5. Apalabrados, redes sociales . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6. Mezcladitos, pantallas de inicio . . . . . . . . . . . . . . . . . . . . . . . . 20
3.7. Mezcladitos, pantallas de juego . . . . . . . . . . . . . . . . . . . . . . . . 21
3.8. Mezcladitos, comodines . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.9. Mezcladitos, creación de partida . . . . . . . . . . . . . . . . . . . . . . . 22
3.10. Preguntados, pantallas de juego . . . . . . . . . . . . . . . . . . . . . . . . 23
3.11. Tablero de Triviados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.12. Categorías de Triviados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.13. Inicio de juego en Enumerados . . . . . . . . . . . . . . . . . . . . . . . . 25
3.14. Ejemplo de jugada en Enumerados . . . . . . . . . . . . . . . . . . . . . . 25
3.15. Continuar formula en Enumerados . . . . . . . . . . . . . . . . . . . . . . 25
3.16. Casilla de aceleración en Enumerados . . . . . . . . . . . . . . . . . . . . 26
3.17. Tienda de bonus de Enumerados . . . . . . . . . . . . . . . . . . . . . . . 26
3.18. Partidas de usuario en Temporis . . . . . . . . . . . . . . . . . . . . . . . 27
3.19. Perfil de usuario en Temporis . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.20. Categorías de Temporis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
XIX
3.21. Ejemplo de partida de Temporis . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Valores de XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2. UI de Barra de navegación en iOS 6 e iOS 7 . . . . . . . . . . . . . . . . . 36
4.3. Captura del menú de partidas de Battlex . . . . . . . . . . . . . . . . . . . 37
4.4. Captura de la escena de refuerzos de Battlex . . . . . . . . . . . . . . . . . 38
4.5. Captura de la escena de ataque de Battlex . . . . . . . . . . . . . . . . . . 39
4.6. Captura de la escena fortificar de Battlex . . . . . . . . . . . . . . . . . . . 39
4.7. Arquitectura de Battlex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8. Flujo de datos: Login con éxito . . . . . . . . . . . . . . . . . . . . . . . . 41
4.9. Flujo de datos: Cargar Partidas . . . . . . . . . . . . . . . . . . . . . . . . 43
4.10. Flujo de datos: Crear Partida . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.11. Flujo de datos: Actualizar casillas después del ataque . . . . . . . . . . . . 46
4.12. Protipo Tablero Battlex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.13. Explorador de clases de Parse . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.14. Notificación de partida de Battlex . . . . . . . . . . . . . . . . . . . . . . 53
4.15. Dispositivos de la configuración del proyecto . . . . . . . . . . . . . . . . 54
4.16. Captura de Battlex en ejecución en iPad . . . . . . . . . . . . . . . . . . . 54
4.17. Resultados de la faceta de Jugabilidad Intrínseca . . . . . . . . . . . . . . . 55
4.18. Resultados de la faceta de Jugabilidad Mecánica . . . . . . . . . . . . . . . 55
4.19. Resultados de la faceta de Jugabilidad Interactiva . . . . . . . . . . . . . . 56
4.20. Resultados de la faceta de Jugabilidad Artística . . . . . . . . . . . . . . . 56
4.21. Resultados de la faceta de Jugabilidad Intrapersonal . . . . . . . . . . . . . 57
4.22. Resultados de la faceta de Jugabilidad Interpersonal . . . . . . . . . . . . . 57
4.23. Ejemplo del territorio pulsado . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1. Pantallas Registro y Login . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2. Pantalla partidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3. Pantalla refuerzos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4. Pantalla ataque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5. Pantalla fortificar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.1. Claves de aplicación de Parse . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.2. Resumen de Battlex en Parse . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.3. Creación de tablas o clases en Parse . . . . . . . . . . . . . . . . . . . . . 76
A.4. Campos de la tabla User en Parse . . . . . . . . . . . . . . . . . . . . . . . 77
A.5. Creación de columna con relación en Parse . . . . . . . . . . . . . . . . . 78
xx
B.1. Battlex paso a paso: Registro . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.2. Battlex paso a paso: Identificación . . . . . . . . . . . . . . . . . . . . . . 82
B.3. Battlex paso a paso: Opciones . . . . . . . . . . . . . . . . . . . . . . . . 83
B.4. Battlex paso a paso: Partidas . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.5. Battlex paso a paso: Situar refuerzos . . . . . . . . . . . . . . . . . . . . . 85
B.6. Battlex paso a paso: Configurar Ataque . . . . . . . . . . . . . . . . . . . 86
B.7. Battlex paso a paso: Configurar Ataque . . . . . . . . . . . . . . . . . . . 86
B.8. Battlex paso a paso: Configurar Ataque . . . . . . . . . . . . . . . . . . . 87
B.9. Battlex paso a paso: Fortificar . . . . . . . . . . . . . . . . . . . . . . . . 88
C.1. Tablas de Battlex en SQLite . . . . . . . . . . . . . . . . . . . . . . . . . 89
C.2. Campos de la tabla Partida en SQLite . . . . . . . . . . . . . . . . . . . . 90
C.3. Datos de la tabla Mapa en SQLite . . . . . . . . . . . . . . . . . . . . . . 90
C.4. Capa de servicios con SQLite integrado . . . . . . . . . . . . . . . . . . . 90
C.5. Interfaz de usuario de prueba . . . . . . . . . . . . . . . . . . . . . . . . . 91
xxi
Índice de listados
4.1. Creación de una escena con Cocos2d . . . . . . . . . . . . . . . . . . . . . 40
4.2. Reemplazo de escena con efecto FlipY . . . . . . . . . . . . . . . . . . . . 41
4.3. Liberación de la escena actual . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4. Configuración de la tabla de partidas . . . . . . . . . . . . . . . . . . . . . 42
4.5. Creación y agregación de tablas de partidas en la escena . . . . . . . . . . . 42
4.6. Selección de partida cuando se es poseedor del turno . . . . . . . . . . . . 43
4.7. Creación y configuración del tablero de juego . . . . . . . . . . . . . . . . 44
4.8. Colocación de tropas sobre el tablero . . . . . . . . . . . . . . . . . . . . . 45
4.9. Ejemplo de Modelos de datos Partida y Mapa . . . . . . . . . . . . . . . . 47
4.10. Creación de un usuario utilizando Parse SDK . . . . . . . . . . . . . . . . 47
4.11. Petición de partidas del usuario utilizando Parse SDK . . . . . . . . . . . . 48
4.12. Actualización de una casilla utilizando Parse SDK . . . . . . . . . . . . . . 48
4.13. Ejemplo de registro con la clase NSLog . . . . . . . . . . . . . . . . . . . 58
4.14. Login correcto, transición a Escena Partidas . . . . . . . . . . . . . . . . . 59
4.15. Usuario cacheado, transición a Escena Partidas . . . . . . . . . . . . . . . 59
4.16. Registro de error sin conexión . . . . . . . . . . . . . . . . . . . . . . . . 59
4.17. Registros de carga de partidas . . . . . . . . . . . . . . . . . . . . . . . . 60
4.18. Registros de territorio pulsado . . . . . . . . . . . . . . . . . . . . . . . . 61
A.1. Configuración en el cliente de las credenciales de Parse . . . . . . . . . . . 75
A.2. Jugadores de una partida en Parse . . . . . . . . . . . . . . . . . . . . . . 77
A.3. Query de obtención de jugadores contenidos en una partida en Parse . . . . 78
C.1. Generación de usuarios en Sqlite . . . . . . . . . . . . . . . . . . . . . . . 91
XXIII
Listado de acrónimos
REST Representational State Transfer
SDK Software Development Kit
SSOO Sistemas Operativos
IDE Integrated Development Environment
BaaS Backend as a Service
API Application Programming Interface
UCD User Center Design
DAO Data Access Object
XXV
Capítulo 1
Introducción
EN este capítulo se detallará el contexto en el que se ubica el proyecto, el problema quehay que abordar y cual es la solución propuesta que más adelante se desarrollará.
1.1 Contexto del TFGEste proyecto está relacionado con varias áreas de investigación y desarrollo, como son
la computación móvil, la computación en la nube, la interacción persona-computador y laludología.
1.1.1 Contexto de la Computación MóvilEstamos ante la era móvil, lleva con nosotros algunas décadas (Ordenadores portátiles,
PDAs, etc), sin embargo desde el nacimiento de los dispositivos inteligentes (smartphones,tablets, dispositivos Wearables, etc) todo el mundo está constantemente comunicado. Lasredes sociales o aplicaciones de comunicación ocupan la mayor parte del tiempo de usode estos dispositivos, aunque las aplicaciones de ocio las siguen muy de cerca. Podemoscomunicarnos directamente con aplicaciones sociales, a través de retos en videojuegos deámbito social u otras que miden nuestra actividad y realizan estadísticas con respecto a la denuestros conocidos.
1.1.2 Contexto de la Computación en la NubeLa computación en la nube, utiliza la palabra nube como metáfora de internet. El objetivo
de la computación en la nube es evitar el procesamiento local que conllevaría procesar oalmacenar esos datos, que gracias a ésta se mantienen centralizados al alcance de todos losusuarios o consumidores (Figura 1.1). Aunque tiene sus desventajas, compensa y muchoutilizar este tipo de servicios. Algunas de las ventajas que ofrecen son un bajo coste demantenimiento, información en tiempo real y la seguridad, ya que no tienes que preocupartepor la integridad de los datos, todo esto te lo proporciona el servicio.
1
Figura 1.1: Ilustración de computación en la nube utilizando dispositivos móviles
1.1.3 Contexto de la Interacción Persona-ComputadorBusca la unión entre la persona y el computador para que el primero interactúe con el
segundo y viceversa, de la manera mas correcta y fácil posible. Para que ello se lleve a cabose utilizan entre otras las siguientes metodologías y especializaciones:
Diseño centrado en el usuario (en ingles UCD, user-center design)
Usabilidad
Utilidad
Accesibilidad
1.1.4 Contexto de la Ludología‘La Ludología, como disciplina ocupada en el estudio del juego por el juego, del aparente
sinsentido de esta acción antropológica. La espontaneidad y la “gratuidad” del juego no de-ben engañarnos... El está limitado en el tiempo y, en definitiva, sus resultados son borrados.Sin embargo, como requiere la totalidad del ser, de forma voluntaria en función de una moti-vación determinada, tiene necesariamente unas consecuencias que varían según la calidad yamplitud del compromiso, según los rasgos dominantes del juego considerado. La obtención
2
del placer lúdico, como resultado esencial de esta acción, tiene su sentido más profundo enprocesos objetivos y dialécticos del desarrollo, que trascienden las aplicaciones concretas,pues determinan el paso hacia una condición superior en la existencia del individuo y de laespecie, en la conversión del Homo Ludens en Homo Sapiens” [Bandera(2006)].
1.2 Problema y solución propuestaAhora se sabe el enfoque del proyecto, pasaremos entonces a describir el problema que
abordamos y la propuesta de resolución.
1.2.1 Descripción del problemaExisten varios ejemplos famosos de aplicaciones asíncronas, Apalabrados [Etermax(2014a)],
Draw Something [Omgpop(2014)], etc. Todas ellas utilizan servicios de notificaciones ycomputación en la nube para centralizar los datos de sus usuarios.
Aunque entre las más famosas no hay ninguna aplicación basada en los juegos de conquis-ta. No se puede hacer una traducción directa de las reglas, como en los ejemplos anteriores,para que se usen en dispositivos móviles.
En los ejemplos citados anteriormente, cuando un jugador posee el turno de la partida,no requiere ninguna atención de los rivales para efectuar la jugada. Sin embargo, una de lasfases clásicas de juegos de mesa como Risk, necesita de una respuesta directa del rival a lahora de efectuar los ataques.
Risk es uno de los más famosos juegos de mesa basado en conquista de territorios. Com-puesto por un tablero de territorios colindantes, se trata de ser el jugador que más territoriosconquiste y en definitiva, de conquistarlo todo.
Las siguientes fases mezclan lo que sería una partida del juego complementado con fun-cionalidades para adaptarlo a la plataforma móvil:
1. Registrar usuario
2. Idenfificar usuario
3. Crear partida
4. Unirse a las partidas creadas por otros usuarios
5. Distribuir nuevas tropas sobre sus territorios en el tablero
6. Realizar ataques para conquistar nuevos territorios
7. Redistribuir tropas de territorios dominados
1.2.2 Solución propuestaCon todo lo anterior en mente, se propone crear un juego de estrategia por turnos basado
en comunicación asíncrona para plataforma iOS.
3
En primer lugar dispondrá de un servicio de autenticación y registro nada más entrar enla aplicación. Este se comunicará con el servicio en la nube para comprobar los credencialesdel usuario o para crear usuarios nuevos.
Una vez que el usuario se identifica en la aplicación podrá ver el estado de sus partidas,aparecerán en primer lugar las partidas en las que tiene el turno, y en segundo lugar las queel turno es del rival.
También podrá crear partidas, las cuales aparecerán en la lista del turno del usuario que laha creado. Los rivales se añadirán a la partida creada de forma aleatoria, escogiendo a estosa partir de la base de datos remota almacenada en el servidor.
El usuario podrá seleccionar una de las partidas de la sección de su turno y entonces apare-cerá la pantalla de juego, donde se cargarán los datos cacheados de la partida en cuestión. Eneste juego existirán tres fases que compondrán el turno, con lo cual la partida seleccionadase cargará en la fase en la que el usuario la dejó, si anteriormente ya hubiera jugado algunade las fases. Por defecto una partida empieza en la fase de reclutamiento, pero es posiblejugar las fases (excepto la última) sin llegar a pasar el turno. El estado de las partidas sealmacenará en el servidor.
En la pantalla de juego se podrán visualizar los datos de la partida, y en concreto de la faseactual. La pantalla de juego mostrará un tablero, en el que cada territorio estará identificadocon un hexágono, y el mapa por defecto será un mapa de 60 (12 x 5) hexágonos, caracterís-ticos en muchos juegos de estrategia por computador. Cada territorio estará compuesto poruna tropa del color del usuario en la partida y un número identificativo para saber el númerode tropas que controlan ese territorio.
Lo anteriormente citado respecto a la pantalla de juego, es de carácter general para todaslas fases. Ahora se explicará la información que se visualizará en cada fase del juego.
Refuerzos: La primera fase del turno es en la que el jugador ganará tropas para distri-buirlas entre los territorios que controla. Se visualizará entonces el número de tropasganadas para ese turno.
Ataque: En la segunda fase el jugador podrá atacar desde sus territorios hacia territo-rios enemigos adyacentes usando un número de tropas menor o igual a tres, siempredejando una tropa en la retaguardia. En esta fase se podrá visualizar el número de tro-pas con las que el usuario desea atacar a otro territorio (el ataque lo componen dosterritorios, uno atacante y otro defensor), además de seleccionar un territorio enemigo;y será entonces cuando el usuario podrá realizar el ataque. Al realizar éste, se visuali-zará el resultado del ataque, la puntuación se corresponderá con un valor entre 1 y 6(valor de un dado convencional), por cada tropa que forme parte del ataque (incluidaslas tropas del rival).
Fortificar: La última fase, donde el jugador tendrá la oportunidad de mover tropas entre
4
los territorios que controle (siempre, dejando una tropa mínima en cada territorio). Enesta fase se mostrará la información del usuario y el color de tropas que controla.
Por último, la aplicación contará con un servicio en la nube, que cubrirá los siguientesrequisitos:
Almacenamiento en base de datos.
Servicio web REST [Marques(2013)], para realizar peticiones al servidor.
Servidor de notificaciones PUSH.
Informes de analítica.
1.2.3 Estructura de la memoriaA continuación se detalla la organización de la presente memoria.
Capítulo 1. Introducción.En este capítulo se definen los campos de estudio del proyecto, se introduce el proble-ma y se propone una visión general de la solución propuesta.
Capítulo 2. Objetivos del proyecto y herramientas utilizadas.Se detallan los objetivos generales y específicos que se deben llevar a cabo durante eldesarrollo del proyecto, y se definen las herramientas utilizadas, hardware y software.
Capítulo 3. Fundamentos y Estado del arte.A partir de una búsqueda bibliográfica, se detallan algunos antecedentes relacionadoscon el presente proyecto.
Capítulo 4. Modelo Conceptual.Se detalla el estudio teórico más relevante y se justifica la elección de los diferentesmétodos y técnicas empleadas.
Capítulo 5. Método de trabajo.Se define la metodología de desarrollo y arquitectura, además de definir cómo se hanintegrado las diferentes herramientas utilizadas en el desarrollo.
Capítulo 6. Resultados y conclusiones.Se muestra el resultado de la aplicación y se expone el cumplimento de los objetivos,así como las conclusiones. Se exponen posibles alternativas y mejoras futuras.
5
Anexos.En este apartado se incluyen, el manual de usuario para usar la aplicación y tamibiénun manual de ejemplo de uso del backOffice.
6
Capítulo 2
Objetivos
EN este capítulo se detallan los objetivos generales y específicos del proyecto, así comolas herramientas utilizadas a lo largo del desarrollo del mismo.
2.1 Objetivo generalEl objetivo de este proyecto es el de realizar un juego de estrategia basado en conquista
de territorios que permita interactuar de forma asíncrona a varios jugadores. El juego seejecutará bajo la plataforma iOS, integrará librearías gráficas y computación en la nube sobrela plataforma móvil.
2.2 Objetivos específicosA continuación se va a proceder a explicar los objetivos específicos con los que llevar a
cabo el proyecto. Se detallarán punto por punto todos y cada uno de los objetivos y la manerade alcanzarlos.
1. Diseñar la mecánica del juego a implementar mediante el análisis de herramientas,tecnologías y estado del arte con el fin de asegurar la jugabilidad y potenciar el interésdel usuario.
2. Implementar el juego mediante los lenguajes y tecnologías más apropiados paraalcanzar el objetivo general.
3. Asegurar el correcto funcionamiento y la consecución del objetivo general mediantepruebas del software generado.
2.3 Objetivos operativos2.3.1 Analizar y seleccionar los lenguajes y frameworks gráficos óptimos
para el TFGSe realizarán una serie de tutoriales y pruebas para avanzar en el aprendizaje del lenguaje
de programación, para la plataforma escogida, llamado Objective-C. Se harán diferentestareas, desde interfaces básicas hasta realizar peticiones a servicios web. También se realizaráuna estudio previo de los diferentes frameworks que se pudieran utilizar en el proyecto y una
7
vez elegido el que se integrará en el proyecto, se procederá a realizar tareas incrementalespara aprovechar el tiempo de aprendizaje en el desarrollo de la aplicación final.
2.3.2 Analizar, definir y adaptar las reglas del juego a desarrollar aseguran-do la jugabilidad del proyecto
Simplificar y/o adaptar las reglas de un juego de estrategia clásico, para que haga uso dela interacción de un dispositivo móvil con pantalla táctil. Esto implica también adaptar lasreglas para que la jugabilidad se lleve a cabo de manera asíncrona, es decir, que los diferentesintegrantes de una partida no tenga porqué coincidir en estar conectados al mismo tiempo.Para adaptar el juego se deberá partir de las fases que componen un turno, descritas en lasección 1.2.2 del capítulo anterior.
2.3.3 Diseñar e implementar escenas del juego
Diseñar e implementar las diferentes escenas del juego. Desde el inicio de sesión y el re-gistro hasta el visor de partidas y el tablero. Las primeras no tendrán mucha complejidadya que deberán mostrar una interfaz sencilla para que lo usuarios introduzcan sus creden-ciales, sin embargo, el visor y el tablero tendrán mas complejidad. Este último tendrá querepresentar territorios y que los usuarios vean que jugadores los controlan.
2.3.4 Diseñar e implementar la interfaz de usuario
Se realizará una búsqueda de información a través del estado del arte, con aplicacionessimilares, para conocer cómo resuelven diferentes problemas de interacción y saber cómo sepodría enfocar el diseño de la interfaz de usuario, que es uno de los elementos más importan-tes en proyectos de este tipo. También se hará uso y se tendrá en cuenta las recomendacionesque ofrece Apple en su documentación [Apple(2014a)].
2.3.5 Implementar el sistemas de persistencia de datos del juego
La aplicación dispondrá de un servicio web o backend, con el que realizar llamadas paraguardar, obtener o modificar la base de datos allí almacenada. Ésta dispondrá de todos loselementos necesarios para persistir las partidas y los usuarios. También dispondrá de un SDK
para realizar peticiones al servicio REST.
2.3.6 Diseñar e implementar el sistema de notificaciones del juego
Una notificación push es, básicamente, un mensaje enviado por un servidor a un clienteque está suscrito a sus notificaciones [Mateos(2013)]. Se implementará este servicio para quelos usuarios no tengan que estar pendientes del estado de las partidas en las que participan,sino que sea el propio dispositivo que te avise a través de esta tecnología de cuando tienes elturno de alguna de las partidas en juego.
8
2.4 Herramientas utilizadasA continuación se van a detallar las herramientas, tanto software como hardware, utiliza-
das para completar el proyecto.
2.4.1 Lenguajes de programación y sistema operativoPara llevar a cabo la aplicación se podría haber hecho uso de herramientas de alto ni-
vel para desarrollar un proyecto multiplataforma, sin embargo, gracias a disponer de lasherramientas necesarias, se pretendía adquirir conocimientos acerca de la tecnología de Ap-ple y desarrollar de manera nativa, con lo que el lenguaje escogido no podía ser otro queObjective-C [Anónimo(2014)], aunque recientemente ha publicado otro lenguaje con el queimplementar aplicaciones nativas llamado Swift.
Para justificar la elección de este sistema operativo móvil, nos centraremos en diferentesestudios, mostrando los beneficios que genera una aplicación en iOS y otra en la compe-tencia directa, Android. Ya que a pesar de la expansión de Android en cuanto al número dedispositivos en el mercado, no se obtienen los mismos beneficios para una misma aplicaciónque corre bajo los SSOO de Apple y Google.
En un artículo realizado en App Annie el 31 de Julio del pasado año, nos encontramos conel número de descargas frente al beneficio generado por ambas plataformas. Las gráficas delestudio están basadas en el segundo cuatrimestre de 2013.
Figura 2.1: Descargas frente a Beneficios[AppAnnie(2013)]
Además, echando un vistazo a las categorías que obtienen mayor número de descargas enla App Store (Tienda de aplicaciones de Apple), vemos como las categorías de Juegos (enlas que se enmarca el presente proyecto) y Entretenimiento son las que mayor número dedescargas poseen.
9
Figura 2.2: Descargas por categoría[AppAnnie(2013)]
Para compilar el código fuente objective-c necesitaremos un compilador, el compilador deXCode (IDE nativo en OS X) es Apple LLVM. El compilador fue introducido en la versionde XCode 3.2 para la versión del sistema operativo de escritorio OS X 10.6 (Snow Leopard),basado en el proyecto Open Source LLVM.org [Apple(2012)].
2.4.2 Medios HardwareLa implementación se lleva a cabo en un ordenador portátil MacBook Pro Retina de
mediados de 2012, sus características son:
Pantalla retina de 15,4 pulgadas.
Procesador Intel Core i7 3a generación a 2,3GHz y 6MB de cache L3 compartida.
8GB de memoria RAM DDR3L.
Disco sólido de 256GB.
Tarjeta gráfica NVIDIA GeForce GT 650M con 1GB de GDDR5.
Sistema operativo OS X 10.9 Mavericks.
Para probar la aplicación durante el desarrollo se utilizan varios dispositivos, así comodiferentes versiones del sistema operativo móvil iOS.
El dispositivo con el que más pruebas se han realizado y por tanto para el que es-tará optimizada la aplicación, es un iPhone 4 (Figura 2.3) (lanzado en 2010) cuyascaracterísticas son:
10
• Pantalla retina de 3,5” y una resolución de 640x960 pixels.
• Procesador ARM-Cortex A-8 a 1GHz.
• 512MB de memoria RAM.
• 16GB de memoria interna.
• Sistema operativo al comienzo iOS 5.0, y actualmente 7.1.1.
Figura 2.3: Apple iPhone 4 (imagen obtenida de http://www.iosxtreme.com/2012/07/
16/repaso-sobre-todas-las-generaciones-de-iphone/)
Otro dispositivo más actual en el que se han realizado pruebas es un iPad Air (Figura2.4) (lanzado en 2013) cuyas características son:
• Pantalla retina de 9,7” y una resolución de 640x960 pixels.
• Procesador A7 y M7.
• 1GB de memoria RAM.
• 32GB de memoria interna.
• Sistema operativo al comienzo iOS 7.1.1.
Figura 2.4: iPad Air, imagen obtenida de https://www.apple.com/es/ipad-air/
2.4.3 Medios SoftwareYa se ha comentado el lenguaje de programación que se utilizará para desarrollar la aplica-
ción será objective-C. El API de iOS llamada Cocoa Touch, se utiliza para crear aplicaciones
11
nativas en esta plataforma. Está formada por 4 capas, y cada una provee al sistema de unaserie de características. Se pueden ver las diferentes capas en la Figura 2.5.
Figura 2.5: Capas de las que se compone Cocoa Touch, imagen obtenida de http://iosdev.
es/frameworks/
A continuación se definirá brevemente las características de cada capa [Languedoc(2012)]:
Cocoa Touch: Storyboards, Documentos, Gestos, Multitarea, Notificaciones y el Fra-mework UIKit.
Media: Esta capa es la encargada de controlar los gráficos, audio, video y el sistemaAirPlay.
Core Services: Servicios como iCloud, Compras dentro de las apps, SQlite, CoreDatay Core Location son controlados gracias a esta capa.
Core OS: La capa de mas bajo nivel, encargada de gestionar el Bluetooth, los acceso-rios externos y un framework acelerador.
La herramienta o entorno de desarrollo para llevar a cabo la aplicación es XCode (2.6),una aplicación gratuita que funciona bajo el sistema operativo OS X en los ordenadores deApple. Es un IDE muy completo, que tiene integrado en sí, el Framework Cocoa y CocoaTouch del que ya hemos hablado. Dispone de las herramientas necesarias para comenzar eldesarrollo (Compilador, Depurador, Herramientas de gestión, Simulador, Documentación,etc), aunque para probar la aplicación en dispositivos físicos es necesario enrolarse en elcentro de desarrolladores de Apple (iOS dev Center) [Apple(2014c)].
12
Figura 2.6: XCode, configuración general del proyecto
Con el fin de utilizar una librería gráfica que ayudase al desarrollo de las diferentes fasesdel juego, se realizó un estudio previo de las posibilidades de las librerías más comúnmenteusadas en el desarrollo de videojuegos de bajo presupuesto para iOS. En su mayoría sonlibrerías gráficas para realizar juegos en 2D aunque tienen ciertas herramientas para el desa-rrollo 3D, aunque no se utilizarán gráficos en 3D para el presente proyecto.
A continuación se muestra una tabla comparativa de las librerías que se tuvieron en cuentaen el estudio previo:
Game Engine Lenguaje Multiplataforma Coste Publicación
Cocos2D C++, Python,Objective-C oJavaScript
Si Gratis
Corona SDK LUA Si 16 hasta 200 $Unity Mono, UnityScript,
C# o BooSi 3000 $
Cuadro 2.1: Comparativa sobre frameworks gráficos para iOS
Como se ha comentado anteriormente, la idea del proyecto también era aprender el len-guaje de programación para implementar aplicaciones nativas para plataforma iOS, con locual el lenguaje elegido entre los que se han comparado ha sido Cocos2D. Entre otras op-ciones se ha decantado por usar este framework ya que se integra con XCode, el coste parapublicar una aplicación basada en él es gratuito y la gran comunidad de desarrolladores quelo usan.
Esta aplicación no necesita mucha potencia, además solo se utilizarán gráficos en 2D, conlo cual será suficiente con este framework basado en OpenGL 1.1, que viene con algunas
13
librerías para controlar mapas basados en cuadros (Tile maps).
También se utilizará Parse, un BAAS que nos permitirá utilizar múltiples servicios de ma-nera gratuita (aunque con límites), basados en la nube. Sus principales características son lassiguientes [Rubio(2013b)]:
Modelo de datos en la nube: creación de tablas no-SQL en la nube y capacidadespara inserción, modificación y consulta vía API.
Notificaciones Push: posibilidad de envío de notificaciones push a nuestros usuarios,previa aceptación por parte del usuario.
Cloud Code: capacidades para la ejecución de código en el servidor, muy útil para larealización de validaciones de seguridad, o procesos automáticos por cambios en losdatos.
Esta plataforma provee a los desarrolladores de un SDK, disponible para múltiples plata-formas, entre ellas iOS.
De esta manera, todas las herramientas que usamos están desarrolladas en Objective-C,con lo cual todo el desarrollo se lleva a cabo en el mismo lenguaje.
Otros medios software secundarios
DropBox: Para almacenar documentos y archivos, con el fin de compartirlos entre eldirector y el alumno.
Adobe Ilustrator CC: Para crear y modificar los gráficos de la aplicación.
MacTex, el paquete de latex para OS X, además de la herramienta TexPad para ela-borar la memoria.
Vista Previa: Herramienta nativa para visualizar y editar documentos y gráficos en OSX.
BitBucket: Servicio de alojamiento web basado en Git, en el cuál se almacenará elproyecto para control de versiones.
14
Capítulo 3
Estado del arte
EN este capítulo se detallan algunos ejemplos que han servido de inspiración al proyecto,pues como ya se ha comentado el trabajo consta de una aplicación móvil asíncrona
basada en juegos de estrategia para plataforma iOS.
3.1 Juegos de EstrategiaLos juegos de estrategia se basan en la inteligencia, habilidades, planificación y ejecución.
Estos factores, junto con el rol que desempeñe el jugador, pueden ser determinantes paraconseguir la victoria.
Según el medio utilizado se pueden clasificar en juegos de cartas, dados, tablero, etc.Aunque también pueden mezclar varios de estos conceptos a la vez para crear juegos máscomplejos, por ejemplo en el trabajo se mezclan los conceptos de tablero y dados, con latáctica del combate para limitar el despliegue de tropas con el azar.
A continuación se exponen algunos ejemplos de estos tipos de juegos:
3.1.1 PokerExisten varias modalidades, aunque la más famosa actualmente es la llamada Texas Hol-
dEm. Consta de una baraja de 52 cartas, dividida en 4 palos. La primera fase es llamadaPreflop, en la que cada jugador recibe 2 cartas para comenzar las apuestas. Luego le siguenlas fases de Flop, el repartidor levanta 3 cartas encima de la mesa, Turn, se levanta una cartamás, y River, donde se levanta la última carta. Cada una de ellas con sus correspondientesapuestas. Para determinar el ganador existe un orden de 10 tipos de combinaciones (Figura3.1) , gana el jugador que consiga la mejor mano de 5 cartas, entre las que posee y las de lamesa.
3.1.2 Poker de dadosBásicamente igual que el juego de poker con cartas descrito anteriormente, pero en este
caso se juega con 5 dados. Cada jugador tiene tres oportunidades en cada turno para sacar lamejor jugada. La manera de determinar el ganador es similar al de las combinaciones de lafigura 3.1. La mayor diferencia es a la hora de utilizar el “AS”, que se puede utilizar como
15
comodín (ser sustituido por cualquier carta) o con normalidad, y a la hora de las fases aquíno existen, son sustituidas por las tiradas que tiene cada jugador.
Figura 3.1: Combinaciones de Poker (imagen obtenida de http://www.jugar-poker.
info)
3.1.3 RiskJuego de mesa creado por Albert Lamorisse en el año 1950. Se comercializa desde 1958
y está basado en turnos simulando la estrategia militar. Existen varias maneras de jugar ydiferentes versiones del juego original, pero se va a explicar el funcionamiento básico deuna partida. Pueden jugar de 2 a 6 jugadores, el tablero está compuesto por 42 territoriosagrupados en 6 continentes, se juega con 3 dados de ataque, 2 de defensa y 56 cartas. Lafinalidad es conquistar todos los territorios. Cada turno está compuesto por tres fases que sedescriben a continuación:
Refuerzos: Consiste en obtener nuevas tropas según el número de territorios que secontrolen y ubicarlos en ellos en cualquier orden
Ataque: El ataque se ejecuta de manera que el atacante puede atacar con un máximo de3 tropas a un territorio enemigo adyacente, siempre dejando como mínimo una tropaen la retaguardia. Cada tropa atacante y defensora estará identificada con un dado,estos se ordenan en orden descendente y se enfrentarán dado a dado para concluir elataque, ganando el atacante en caso de superar el valor del dado defensor. En caso deempate gana siempre el defensor.
Fortificación: En la última fase se podrá mover tropas de un territorio controlado a otroadyacente, siempre dejando una tropa como mínimo en cada territorio.
16
Figura 3.2: Tablero de Risk (imagen obtenida de http://img.americanas.com.br)
3.2 Aplicaciones AsíncronasAhora se van a poner ejemplos de aplicaciones actuales, que utilizan tecnologías similares
a las que se utilizan en el trabajo. Estas aplicaciones en su mayoría son adaptaciones, cono sin modificaciones, de juegos de mesa, dados, etc, como se han descrito en ejemplos delpunto anterior.
3.2.1 ApalabradosBasado en otro juego de mesa llamado Scrabble, modificado y adaptado para dispositivos
móviles. Este consistía en ganar puntos formando palabras sobre un tablero de 15x15 casillas.Las palabras podían formarse en vertical u horizontal y se podían cruzar para aprovecharlas palabras ya formadas en el tablero. Se obtienen puntos según el número de letras de lapalabra formada y su situación en el tablero. La finalidad del juego consistía en terminar conla mayor puntuación. Apalabrados hereda muchas de éstas y otras reglas de juego, agregandoel componente social y las partidas con gente a distancia, sin la necesidad de jugar al mismotiempo.
Una vez identificado en la aplicación a través de tu correo electrónico o tu cuenta deFacebook, podrás ver una lista de partidas en juego, crear una nueva (eligiendo oponente, elidioma preferido para formar las palabras) o acceder a tu perfil entre otras pantallas.
En la pantalla de perfil (Figura 3.3), se puede ver la siguiente información:
Datos de usuario: Sea el perfil propio o de un rival se podrá ver el avatar y nombre deusuario, la cuenta de twitter del usuario (si lo permite el usuario), el instante en que
17
se hizo la última jugada y banderas con el número de partidas jugadas en un idiomaconcreto.
Logros: Se podrá visualizar la mayor puntuación conseguida en un juego completo, lade la mejor jugada y la palabra mas larga formada.
Desempeño: Se visualizan, el número de partidas ganadas, perdidas, y el porcentaje departidas que se han abandonado. Las partidas abandonadas computan como perdidas.
Versus: Si el perfil es de un rival, veremos esta tabla que muestra el computo global delos enfrentamientos que se hayan tenido con él. Además se puede solicitar amistad enFacebook a través del botón ‘Agregar Amigo”.
Figura 3.3: Apalabrados, nuevo juego y perfil de usuario (imagen obtenida de http://
applicantes.com)
Como se ha comentado anteriormente, apalabrados está muy en la línea de las reglas delScrabble, repartiéndose fichas entre ambos oponentes, formando palabras sobre el tablerorespetando las reglas y cuya finalidad es conseguir el mayor número de puntos. Para con-seguir esto también se juega con la puntuación de cada ficha (no todas valen lo mismo) ycon las casillas “especiales” del tablero (figura 3.4): Las casillas están denominadas por dosletras, DL o doble letra, TL o triple letra, DP o doble palabra y TP o triple palabra. Al formaruna palabra colocando las fichas sobre estas casillas se le proporciona al jugador puntos extrasegún el significado de cada casilla.
En la parte inferior de la pantalla se muestran una serie de opciones que hacer con lasfichas o la jugada, como pasar turno, cambiar fichas, mezclar las fichas actuales, rendirsey cuando se ha formado una palabra válida pasar se convierte en jugar para confirmar lajugada.
18
Figura 3.4: Apalabrados, tablero de juego (imagen obtenida de http://applicantes.com)
En la figura 3.5 se pueden ver unas capturas de las pantallas (de izquierda a derecha): Listade partidas en juego, partida terminada y chat de juego.
En Lista de partidas se muestran las listas de apalabrados en juego en las que te toca tuturno en primer lugar y debajo las que el turno es del rival. Por cada partida se muestran losdatos del rival, la última palabra formada y hace cuanto tiempo fue formada, el idioma de lapartida, hace cuanto fue creada y las fichas restantes.
En la captura de la Partida terminada se muestra un mensaje para el usuario que haganado o perdido y dá la posibilidad de compartir en las redes sociales el resultado de lapartida.
En la captura referente al chat del juego se muestra un chat que ofrece la posibilidad deconversar con el usuario rival en cada partida.
Figura 3.5: Apalabrados, redes sociales (imagen obtenida de http://applicantes.com)
19
3.2.2 MezcladitosEl caso de Mezcladitos no se trata de una adaptación de ningún juego de mesa famoso
como ocurre con el caso anterior (sección 3.2.1). Aunque se parece a muchos juegos famo-sos, bebe directamente del anterior y también de los clásicos ”crucigramas”, con lo cual,es otra aplicación de formar palabras con una serie de particularidades que se describirán acontinuación.
En la pantalla principal (figura 3.6) nada más abrir la aplicación se pide introducir losdatos para la identificación. Si se posee cuenta de usuario de apalabrados se podrá usar enesta app ya que ésta lo permite al estar creada por la misma compañía (Etermax), por lo tantose podrá introducir usuario y contraseña o identificarse con la cuenta de Facebook.
Figura 3.6: Mezcladitos, pantallas de inicio (imagen obtenida de http://applicantes.
com)
La mecánica de juego consiste en formar el mayor número de palabras en tres turnos, dedos minutos de duración cada uno. Por supuesto para hacerlo se dispone de un tablero de4x4 con un total de 16 letras para juntar palabras (figura 3.7), ya sea en horizontal, vertical uhorizontal. Además algunas letras tienen bonificación de multiplicación, que sigue la mismaforma que la aplicación anterior (DL, TL, DP y TP). Ganará el jugador que mas puntosconsiga en el transcurso de la partida
20
Figura 3.7: Mezcladitos, pantallas de juego (imagen obtenida de http://applicantes.
com)
El juego tiene un sistema de comodines que hacen que un usuario pueda desequilibrar labalanza en su favor. Al registrarte se obtienen 50 monedas del juego con las que se pue-den comprar comodines. Las monedas se pueden comprar (compras in-app desde 0,89, 1,79euros...) a través de la propia aplicación (figura 3.8) o ganando partidas.
Existen varios tipos de comodines que ofrecen diferentes bonificaciones:
Pingüino: Congelar el tiempo.
Tortuga: Ralentizar el tiempo.
Mono: Se chiva de tres palabras que se pueden formar.
Loro: Sugiere términos.
Figura 3.8: Mezcladitos, comodines (imagen obtenida de http://applicantes.com)
21
En mezcladitos se pueden crear partidas en 11 idiomas diferentes y como en la anteriorapp, se pueden crear partidas buscando a amigos en Facebook o por el email de usuario.Tiene el mismo aspecto social y una interfaz de usuario similar a la de su antecesor.
Figura 3.9: Mezcladitos, creación de partida (imagen obtenida de http://applicantes.
com)
Por supuesto las partidas pueden estar en espera de que el usuario quiera realizar su jugada,pero en caso de demorar más de 7 días la partida desaparece.
Los beneficios que gana la empresa gracias a estas aplicaciones se fundamentan en lapublicidad en el caso de las aplicaciones gratuitas y del coste de las aplicaciones que eliminanla publicidad, a parte de las compras in-app. En este caso y el de Apalabrados (sección 3.2.1)la publicidad puede llegar a parecer exagerada, porque en muchas de las pantallas apareceun banner publicitario y también publicidad a pantalla completa cada vez que hacemos unajugada.
3.2.3 PreguntadosDel mismo desarrollador que los dos ejemplos de aplicaciones anteriores es Preguntados.
Una vez más una aplicación basada en otro juego de mesa famoso como lo son los juegosde preguntas y respuestas de varios campos, en concreto el juego de este tipo más famoso esTrivial Pursuit.
Como otros ejemplos, esta adaptación tiene sus matices, sobre todo uno de ellos es el dehacer que los propios jugadores propongan preguntas para el juego, que a través de unasvotaciones se valorarán. Esto hace el juego mucho más dinámico, divertido, social y adicti-vo.
La mecánica del juego es muy similar al ya comentado anteriormente Trivial, pero en estecaso no se utiliza un tablero con un dado para avanzar de casilla en casilla intentando con-seguir los ”quesitos”. En su lugar los quesitos se sustituyen por personajes y el tablero poruna ruleta (figura 3.12. Se trata de girar la misma e ir contestando preguntas de los diferentes
22
campos que se van mostrando. Durante la partida el jugador obtendrá los personajes si con-testa correctamente las preguntas, pero también podrá retar a los rivales si le sale la casillade la corona para intentar arrebatarle al usuario un personaje que haya conseguido.
Figura 3.10: Preguntados, pantallas de juego (imagen obtenida de http://applicantes.
com)
También ofrece compras in-app para obtener más oportunidades de tirada en cada turno, yaque por defecto son tres y también se pueden comprar más ”vidas”, aunque se pueden obtenercon el transcurso de la partida. En Preguntados ganará el jugador que primero obtenga todoslos personajes.
El juego como los ejemplos anteriores, permite identificarse con cuentas de Facebook ousuario y contraseña. Además también tiene todos los aspectos sociales, compartir resultadosvia Twitter y Facebook, chat de juego, etc. Por supuesto es un juego asíncrono, las partidaspueden estar ahí durante días, solo cuando el usuario podrá contestar sin límite mas halla delos 7 días inactivo en una partida, en cuyo casi ésta será eliminada.
De todos los ejemplos de aplicaciones creados por Etermax([Etermax(2014b)]) este es elque más se aleja de la mera adaptación del juego en el que está basado. La finalidad es lamisma, pero la dinámica de juego es diferente para adaptarla a los dispositivos móviles.
3.2.4 Triviados o AtríviateAl igual que el ejemplo anterior (subsección 3.2.3), Triviados es una adaptación del famo-
so juego Trivial Pursuit. Pero en este caso de una manera mas fiel, pues antes se comentabaque la manera de elegir las preguntas era a través de una ruleta, sin embargo en Triviados sehace con un tablero (Figura 3.11) muy parecido al del juego de mesa.
Tal y como se describe en su sitio ([Triviados(2014)]): Triviados en un juego online dispo-nible para todo tipo de smartphones, tablets, equipos de escritorio y portátiles. Se trata de un
23
Figura 3.11: Tablero de Triviados (imagen obtenida de www.triviados.es)
juego tipo Trivial Pursuit compuesto por más de 5.000 preguntas y respuestas que además sevan actualizando periódicamente para que los jugadores nunca lleguen a conocer todas laspreguntas y el juega siga teniendo, en todo momento, la emoción del primer día.
Figura 3.12: Categorías de triviados (imagen obtenida de www.triviados.es)
Como en cualquier otro juego de tipo Trivial, el objetivo del juego es ir recorriendo lasdistintas casillas del tablero y contestando las preguntas de la categoría de la casilla en laque caigamos hasta conseguir las 7 estrellas (una correspondiente a cada categoría) que seencuentran repartidas por el tablero. Así el ganador de Triviados será el primer jugador quelogre obtener las 7 estrellas antes que sus oponentes ([Triviados(2014)]).
3.2.5 EnumeradosEnumerados es una aplicación muy parecida en su interfaz y experiencia de usuario al ya
comentado Apalabrados (Subsección 3.2.1) y a Mezcladitos (Subsección 3.2.2). Pero en estecaso no se trata de formar palabras, sino de formar operaciones matemáticas básicas usandofichas de valores numéricos y fichas de símbolos operacionales.
24
A continuación se explicará en que consiste el juego:
La primera jugada debe pasar por la casilla de salida, es decir, algunas de las fichas utili-zadas debe ser posicionada en dicha celda del tablero (3.13).
Figura 3.13: Inicio de juego en Enumerados (imagen obtenida de www.enumerados.es)
Para realizar una jugada es obligatorio utilizar números o signos que ya estén en el tableropreviamente (Figura 3.14) y también se pueden continuar las fórmulas como se muestra enla figura 3.15.
Figura 3.14: Ejemplo de jugada en Enumerados (imagen obtenida de www.enumerados.es)
Figura 3.15: Continuar fórmula en Enumerados (imagen obtenida de www.enumerados.es)
Cuando el jugador termina su jugada, la puntuación que consigue es equivalente a to-dos los números sumados que forman la fórmula, es decir, simplemente hay que formular
25
operaciones válidas pero el resultado de la fórmula no es la puntuación sino lo que se hacomentado.
Como ocurre en diversos juegos y en algunos de los ejemplos citados anteriormente, exis-ten multiplicadores en el tablero de juego, al colocar una ficha que forme la fórmula en lacasilla multiplicadora, ésta se multiplica por el valor de la casilla.
También existen otros bonus, como el bonus para sumar 15 puntos que consiste en utilizaren una jugada todas las fichas que se tienen en la mano del jugador. Otro mas es el de suamr30 puntos al conseguir rellenar una fila o columna del tablero con una fórmula.
Además de lo anteriormente citado, esta aplicación cuenta con mas características, comola de los bonus de juego. Existen varias maneras de conseguir bonus, esperar que se recarguela barra de bonus, la cual aumenta en cada turno, aunque aumentará mas rápido si se usa enuna jugada la casilla de acelerar (Figura 3.16).
Figura 3.16: Casilla de aceleración en Enumerados (imagen obtenida de www.enumerados.
es)
La otra manera de utilizar un bonus es pagando por ellos (Figura 3.17), una vez compradose podrá usar una vez por partida, aunque siempre se podrá usar un bonus aleatorio cuandose recargue la barra.
Figura 3.17: Tienda de bonus de Enumerados (imagen obtenida de www.enumerados.es)
26
Durante el juego el jugador podrá abandonar la partida o darla por perdida. En la pantallaprincipal de la aplicación después de identificarse, se muestran todas las partidas del usuario,además de poder gestionar la cuenta de usuario y los ajustes de la aplicación.
3.2.6 TemporisTemporis es un juego multijugador por turnos para poner a prueba los conocimientos de
los jugadores. Se ha de retar a amigos o desconocidos e intentar ser el primero en crear líneastemporales correctas de eventos de varias categorías.
La aplicación permite identificarse a través de las redes sociales, FaceBook y Twitter o concorreo electrónico como ocurre con la mayoría de las aplicaciones citadas anteriormente.
En la pantalla principal después de la identificación, vemos nuestro avatar de usuario yacciones que se pueden hacer en la lista de partidas (Crear una nueva partida o actualizar lalista), debajo se muestra la lista de partidas en juego y las terminadas.
Figura 3.18: Partidas de usuario en Temporis (imagen obtenida de play.google.com)
El perfil de usuario de Temporis (Figura 3.19) muestra unas estadísticas globales sobre laspartidas jugadas, además de un desglose de las categorías en las que mejor hemos puntua-do.
27
Figura 3.19: Perfil de usuario en Temporis (imagen obtenida de play.google.com)
Al crear una nueva partida en temporis, se puede elegir una de las diferentes categoríaspara los eventos de la línea temporal o crear una partida en la categoría es aleatoria. Lascategorías se pueden visualizar en la figura 3.20.
Figura 3.20: Categorías de Temporis (imagen obtenida de play.google.com)
En la figura 3.21, se puede ver como es la pantalla de juego de una partida de 4 jugadoresy con categoría aleatoria. La finalidad del juego es conseguir ordenar correctamente la mayorparte de los eventos que van apareciendo. Aunque la partida consta de 4 jugadores, Temporispermite crear partidas desde 2 hasta 4.
28
Figura 3.21: Ejemplo de partida de Temporis (imagen obtenida de play.google.com)
La aplicación funciona de la misma manera que las anteriores, el jugador que posee elturno, podrá mover eventos en la línea temporal mientras no cometa ningún error, en cuyocaso se pasará el turno al siguiente, el cual podrá contestar cuando quiera a la partida. En tem-poris gana el jugador que consigue colocar el mayor numero de eventos de la línea temporalcorrectamente. también permite compartir estadísticas a través de las redes sociales.
3.3 ConclusionesEn esta sección se detallan más concretamente las funcionalidades que se han tenido en
cuenta de las aplicaciones anteriormente descritas, para adoptarlas en Battlex o como mejorasfuturas.
3.3.1 IntegradasOrganización de partidas: La primera similitud con estas aplicaciones que se puedeobservar en Battlex es la manera en que un usuario ver sus partidas y elige una de ellaspara entrar a jugar. En los ejemplos descritos anteriormente se puede observar como semuestran en forma de tabla, diferenciando las partidas en las que se tiene el turno y lasque el turno lo posee el rival. También la información que se muestra de cada partidaha servido de inspiración para mostrar los datos más relevantes de cada partida. Se haconsiderado que es la mejor manera de mostrar la información a los usuarios.
En las pantallas donde se visualizan las partidas en los ejemplos anteriores, también sepueden crear nuevas partidas, aunque éstas se pueden personalizar en los ejemplos, enBattlex se crearán de manera automática, pero la funcionalidad será similar.
Fichas: Otra de las similitudes es a la hora de diferenciar las "fichas"propias de las delrival, en el caso de Triviados (sección 3.2.4) se puede diferenciar por colores dondeestá situado cada jugador. En Battlex se pueden diferenciar las tropas por colores y
29
siguiendo la leyenda de la parte superior donde se muestra el color de la tropa deljugador, el usuario identificará cual es el color de sus tropas.
Controles: Los controles sobre los tableros en los ejemplos aparecen en la parte inferiorde la pantalla, ya que en todos los casos el dispositivo está en posición vertical y esmás cómodo usar el dispositivo con los dedos pulgares de cada mano. En el caso deBattlex el dispositivo siempre estará en posición horizontal, con lo cual los controlessobre el tablero estarán alíneados a los bordes laterales de la pantalla y serán accesiblespor los mismos dedos.
Tablero: También se ha tenido en cuenta el uso que hacen aplicaciones como Trivados(sección 3.2.4), Apalabrados (sección 3.2.1) o Enumerados (sección 3.2.5) a la horade mostrar los tableros. Éstas lo muestran completo para que se pueda observar entoda la pantalla, aunque algunas permiten hacer zoom. En Battlex el tablero se muestracompleto en toda la pantalla, aunque no permite zoom.
Notificaciones: Todos los ejemplos anteriores hacen uso de notificaciones para man-terner informados a los usuarios del progreso de las partidas en juego. En Battlex sehace uso también de esta funcionalidad para que los usuarios sepan cuando les toca elturno en alguna de las partidas que tienen en juego.
3.3.2 No integradasA continuación se citarán brevemente las funcionalidades que se han considerado buenas,
pero que no se han integrado en el proyecto, o bien porque no estaban planificadas o porquealguna de ellas hubiera sido complicada de implementar.
Sistema de logros: No se ha citado mucho en los ejemplos anteriores, pero están inte-grados con sistemas de logros de las diferentes plataformas para las que están dispo-nibles. Sería intersante integrar en Battlex un sistema de logros que ofrecieran recom-pensas a los jugadores, para así motivar más el uso de la aplicación.
Redes Sociales: Todos los ejemplos anteriores permiten identificar a los usuarios através de sus cuentas en redes sociales, lo que aporta un valor añadido para ellas yaque puede darse a conocer la aplicación a través de éstas redes, publicando anunciossi el usuario lo permite en los tablones de éstas. Integrar estos modos de identificacióndaría muchas más posibilidades de expansión a la aplicación.
Perfil y estadísticas: Una vista más detallada de los perfiles de usuario y permitir labúsqueda de perfiles de otros usuarios mejoraría el sistema de creación de partidas.También los ejemplos anteriores muestran estadísticas sobre las partidas de los usua-rios, y estas podrían mostrarse en esa vista más detallada de los perfiles de usuario.
Sala de chats: La mayoría de las aplicaciones anteriores permiten la posibilidad de quelos usuarios que forman las partidas puedan hablar mediante salas de chats. En Battlex
30
se podría integrar esta funcionalidad, siempre que el servidor pudiera almacenar todala información de los chats.
Compras dentro de la aplicación: Algunas de las aplicaciones citadas anteriormenteofrecen compras dentro de ellas. Se pueden comprar ayudas para tener ventajas a lahora de jugar las partidas. La posibilidad de integrar también el sistema de cartas deljuego Risk original, podría ser una de esas ayudas que ofrecer al usuario. Canjeandoestas cartas, los jugadores podrían obtener más tropas a la hora de reclutarlas en laprimera fase de cada turno.
Multiplataforma: Aunque el presente proyecto se basa en una aplicación para platafor-ma iOS, casi todas las aplicaciones citadas están disponibles en las distinas tiendas deaplicaciones móviles y también en las redes sociales, es otra de las ventajas que podríaofrecer Battlex para alcanzar más cuota de usuarios.
3.3.3 ConclusionesTodas las funcionalidades citadas son interesantes de cara a la jugabilidad y usabilidad
de la aplicación para los usuarios. La finalidad de ellas es mantener al usuario utilizando laaplicación durante el mayor tiempo posible e incentivar el que unos usuarios rivalicen conotros para fomentar el juego.
31
Capítulo 4
Método de Trabajo
DESPUÉS de haber realizado un estudio de tecnologías hardware, software y haber son-deado el mercado de aplicaciones para la búsqueda de inspiración, se va a proceder a
explicar la metodología de desarrollo escogida para el desarrollo del proyecto.
4.1 Metodología de DesarrolloPara realizar el desarrollo de la aplicación con un equipo tan reducido de personas, se
decide usar una metodología ágil de desarrollo llamada eXtreme Programming (Programa-ción Extrema) [Wells(2009)] , formulada por Kent Beck en el primer libro sobre la materia”Extreme Programming Explained: Embrace Change” [Beck(1999)], se diferencia de lasmetodologías tradicionales en que el foco está en la adaptabilidad y menos en la previsibili-dad.
4.1.1 Programación ExtremaLa programación extrema (en adelante XP), se basa en una serie de valores (figura 4.1), los
cuales se deben seguir para que la consecuencia de ello la simplicidad de un buen producto yun buen ambiente de trabajo. A continuación se detallarán los valores de los que se componeXP:
Simplicidad: Para alcanzar la simplicidad se implementará la tarea asignada o estima-da, sólo poniendo el foco en lo que se necesita, sin pensar en las necesidades futuras.Éstas se implementarán más tarde. También se aplicará la simplicidad en la documen-tación, se debe realizar el código de manera que sea fácilmente interpretable por elresto del equipo.
Comunicación: Como se comentaba, el código debe ser lo más inteligible posiblepara que la comunicación y el conocimiento sobre el proyecto fluyan a través de todoslos integrantes del equipo. La mejor manera de documentar el código es eligiendo bienel nombre de variables, métodos, clases y carpetas o grupos, porque los comentariospueden quedar obsoletos si los miembros del equipo se centran en mejorar el código yse olvidan de cambiar los comentarios.
33
Retroalimentación: Este es uno de los valores clave. Se realizan iteraciones cortas,en cada una de las cuales se entregará software funcionando, con lo que se descubreen fases tempranas, donde no se cumplen los requisitos gracias a la observación delcliente. Esto ayuda a que los desarrolladores se centren en las partes más importantes.
Valentía: Se sirve de ésta para desechar, cambiar o adaptar el código que uno mismopreviamente hizo. Sin importar el esfuerzo que conllevó hacerlo o que llevará cambiar-lo, siempre y cuando esto sea para mejorar la calidad del producto.
Respeto: Apoyar a los compañeros, enseñar y aprender de ellos, respetar su trabajo yadoptar las medidas oportunas de cara a la refactorización para conseguir una mejorcalidad del producto.
Figura 4.1: Valores de XP (imagen obtenida de http://pmoinformatica.com)
4.1.2 Historias de UsuarioSe trata de unas tarjetas en papel que se utilizan para definir los requisitos de cada tarea,
sean estos funcionales o no funcionales. Tienen una serie de características:
Trato dinámico y muy flexible.
En cualquier momento se pueden desechar, cambiar o reemplazarse por otras másespecíficas o generaleso añadir nuevas.
Deben ser lo suficientemente específicas como para ser desarrolladas en unas semanas(iteraciones1).
Para el contenido de las historias de usuario existen varias plantillas, unas definen que sedeben detallar con enunciado y descripción, otras solo con la descripción y que deben teneruna estimación de esfuerzo en días.
1El equipo de desarrollo especificará de cuantas semanas se compone una iteración
34
Otra definición es la de Kent Beck en su primer libro citado anteriormente, en la cual sedetallan fecha, tipo de actividad (nueva, corrección, mejora), prueba funcional, número dehistoria, prioridad técnica y del cliente, referencia a otra historia previa, riesgo, estimacióntécnica, descripción, notas y una lista de seguimiento con la fecha, estado cosas por terminary comentarios [Letelier(2005)].
Siguiendo los valores de XP, se llevará a cabo el presente proyecto. El proyecto lo con-forman dos personas, director y alumno, el director asumirá el papel de cliente y el alumnoserá el equipo de desarrollo. Se detallarán las historias de usuario conjuntamente por los dosmiembros, se llevará acabo el desarrollo y se presentará al final de cada iteración una versiónfuncional cliente, el cual podrá proponer cambios, nuevos requisitos, mejoras, etc.
Una vez satisfecho el cliente con el producto final, se realizará la documentación, deta-llando todas las iteraciones y sus características y se realizará el manual de usuario de laaplicación.
4.2 Desarrollo del proyectoA la hora de realizar una aplicación, hay que definir la idea y a través de ella realizar un
diseño de la misma. Aunque puede cambiar durante el desarrollo por las mejoras o reco-mendaciones a tener en cuenta a través de la retroalimentación del cliente, hay que definirunos estilos, unas reglas del juego (adaptadas de juegos de guerra basados en conquista deterritorios y otras aplicaciones asíncronas) y la arquitectura del sistema. A continuación sedefinirán las decisiones que se han ido tomando durante el desarrollo en cuanto a estilo odiseño, reglas del juego y arquitectura del sistema, y como quedará todo una vez terminadoel desarrollo.
4.2.1 Diseño de la Interfaz de UsuarioAunque se comenzó con una interfaz menos cuidada, desde el punto de vista del diseño y
se dio más importancia a la lógica de programación, ésta ha ido evolucionando hasta seguirunos diseños más actuales y mejorar la experiencia de usuario.
Al comienzo del presente proyecto los dispositivos móviles como Android, iOS, etc, te-nían unas interfaces nativas más basadas en el skeumorph (Skeumorfismo), que viene delgriego skeuos (herramienta) y morphe (forma) y se refiere a una propiedad de un objeto evo-lucionado (o derivado) que mantiene detalles del diseño del objeto original con el objetivode hacerlo más familiar para su usuario.
No se ha abandonado radicalmente este estilo pero ahora se siguen una serie de recomen-daciones de guía de estilo para interfaces de usuario como las que Apple publicó el veranode 2012 junto con la primera beta de iOS 7 ([Apple(2014b)]).
La razón de seguir esta guía de estilo y no otra como podría ser de Android o de otros
35
diseñadores es porque la aplicación es para plataforma iOS y se hace un diseño centrado enlos usuarios de esta plataforma para que encuentren en ella una interfaz ”familiar”.
La guía de estilo de iOS 7 comienza definiendo los temas que incorpora:
Deferencia: La interfaz de usuario ayuda a los usuarios a entender e interactuar con elcontenido, pero no compite con él.
Claridad: El texto es legible en todos los tamaños, los iconos precisos y los adornosson sutiles y apropiados, y se centra en que la funcionalidad motiva el diseño.
Profundidad: Capas visuales y movimiento realista dan vitalidad y mejoran la expe-riencia de usuario.
Un ejemplo del cambio que supone la interfaz de usuario en iOS 7 con respecto de lasanteriores versiones se puede visualizar en la figura 4.2.
Figura 4.2: UI de Barra de navegación en iOS 6 e iOS 7 (imagen obtenida de https://
developer.apple.com)
En la siguiente tabla se muestran las diferencias visuales entre las diferentes versiones deiOS:
iOS 7 iOS 6
Estilo de la barra Translúcida clara (por defecto) o trans-lúcida oscura
Opaco con degradado azul (por defecto)u opaco negro
Apariencia Linea de un píxel en el borde inferior Sombra en el borde inferiorTinte tintColor para personalizar los botones,
barTintColor para personalizar el fondotintColor para personalizar la barra
Botón atrás El botón atrás es un botón hecho con eltítulo de la pantalla previa
El botón atrás es un botón con borde quecontiene el título de la pantalla previa
Cuadro 4.1: Comparativa sobre UI de NavigationBar
Siguiendo estas y otras características más específicas como tamaños de botones, fuentes,colores, etc, se definirán las escenas de las que estará compuesta la aplicación, las cuales seexplicarán mas adelante.
36
Escenas de Juego
Registro: Tiene un diseño sobrio y sencillo, sin distracciones, solamente los camposnecesarios para la información requerida (nombre de usuario, contraseña e e-mail) jun-to con los botones para confirmar el registro y otro para poder volver a la identificación,además del título de la aplicación en la parte superior.
Identificación: Muy similar al anterior, esta vez solo con los campos nombre de usua-rio y contraseña para poder identificarse y los botones para confirmar la identificacióny otro para ir a la escena de registro.
Menú de partidas: La siguiente pantalla ya es algo más compleja que las anteriorescomo se puede ver en la figura 4.3, tiene una serie de botones en la parte superior,a la izquierda el botón de opciones en el cual se puede cerrar la sesión y en la partederecha el botón de crear nueva partida, como se puede observar ambos controles estánrealizados siguiendo las guías de estilo recomendadas citadas anteriormente.
Figura 4.3: Captura del menú de partidas de Battlex
En la parte centrar aparece el nombre del usuario con el que se inició la sesión y debajoseparadas en dos tablas, aparecen las listas de partidas que tiene el usuario en juego, ala izquierda las partidas en las que tiene el turno, a la derecha en las que el turno es dealguno de los rivales.
Refuerzos: En esta escena se muestran los controles asociados a los refuerzos, estosson: Tropa de ejemplo y el número de las tropas de refuerzos restantes por colocar en eltablero, las cuales podrán ser colocadas en los territorios que se tengan bajo control. Elbotón para acceder a la siguiente fase se activa al colocar todas las tropas de refuerzoy en caso de ser pulsado se guarda el progreso de refuerzos y de fase. También semuestra el botón volver, para poder volver en cualquier momento al menú de partidas.
Como se puede ver en la figura 4.4 , se hace uso de la guía de estilo, los botónes tienenun borde del mismo color del texto para diferenciar claramente los elementos con los
37
que el usuario puede interactuar y también del fondo, además están diseñados con unborde fino para resaltarlos más frente al texto informativo de la partida.
Figura 4.4: Captura de la escena de refuerzos de Battlex
El tablero tiene una dimensión de 12x5, se utiliza esta medida por varias razones: Laprimera es porque es un número redondo (60 territorios) para dividir los territoriosentre tres jugadores. La segunda es porque con el ancho de pantalla de menor anchoen modo apaisado, 480 puntos, siguiendo la recomendación de que los elementos coninteracción no sean menores de 44x44 puntos (mismos pixels en no-retina y 88x88 enretina) es la medida mas óptima alcanzada realizando los cálculos oportunos.
Con respecto al tablero, se utiliza la silueta de un soldado para representar las tropasjunto con el número de tropas en cada territorio, los cuales están representados enforma de hexágono. El motivo de la elección de este polígono para representar losterritorios es porque está basado en los juegos de estrategia por turnos clásicos, es unrecurso muy utilizado en juegos de guerra y además puede permitir en el futuro generarmapas aleatorios o personalizados por el usuario de una manera sencilla. Lo que seríamucho más difícil si se tratara de polígonos irregulares y no homogéneos.
Ataque: Ya se han definido las decisiones con respecto al tablero, así que se describi-rán solamente los controles diferentes que hay entre la presente escena y la anterior.
En la fase de ataque se podrá realizar las siguiente interacciones:
• Selección de territorios: La acción para realizar el ataque empieza por seleccionarun territorio bajo control, este se resalta añadiendo un tono de oscuridad a la tropay se muestra el número de tropas al lado de la figura, encima de las tropas que hayen ese territorio. 4.5. A continuación con el ataque seleccionado se pulsa sobreun territorio enemigo adyacente al anterior.
• Confirmar ataque: Se debe pulsar el botón situado en la parte central justo enci-ma del tablero, cuyo título es ”Ataque” para que aleatoriamente se muestren los
38
Figura 4.5: Captura de la escena de ataque de Battlex
resultados del ataque.
• Retroalimentación posterior al ataque: Inmediatamente a realizar el ataque semuestran los resultados y se quedan resaltados los territorios involucrados paraque el usuario sepa donde se ha realizado la acción.
Fortificar: Simplemente se selecciona el territorio desde el que se quieren mover tro-pas, el cual se resaltará y se mostrará el número de tropas a desplazar, y a continuaciónse pulsa el territorio al que se desean mover las tropas para fortificar esa zona. 4.6.
Figura 4.6: Captura de la escena fortificar de Battlex
4.2.2 Arquitectura de la aplicaciónEstará basada en módulos bien marcados por los SDK y/o API utilizadas para llevar a cabo
el proyecto, a continuación se describirán los módulos de la arquitectura de la aplicación(Figura 4.7):
39
Figura 4.7: Arquitectura de Battlex
iOS: La base de la aplicación es el sistema operativo para dispositivos móviles deApple. El lenguaje para todos los módulos de la aplicación será el ya comentadoObjective-C y la versión mínima que soporta la aplicación será iOS 4.3.
Cocos2d: El framework gráfico que se utiliza en la aplicación, para navegar a través delas diferentes escenas (CCScene) del juego gracias al director de escenas (CCDirector)y dibujar las diferentes capas (CCLayer) donde se dibujarán el terreno del juego usandomapas (CCTMXTiledMap), y las tropas de los jugadores (CCSprites).
Escenas de Juego: Como se ha comentado, el framework ofrece un director de escenasque es el encargado de hacer la transición entre las mismas.
Primero se crean la escenas (Listado 4.1).
+ ( CCScene ⇤) scene{
CCScene ⇤scene = [ CCScene node ];GameListScene ⇤ gameListScene = [ GameListScene node ];[scene addChild : gameListScene ];return scene;
}
Listado 4.1: Creación de una escena con Cocos2d
40
Y a continuación se cambia de escena hacia una nueva utilizando cualquier tipo detransiciónes que ofrece el framework, como se puede ver en el listado 4.2 o se vuelvea la escena anterior como en el listado 4.3.
CCTransitionFlipY ⇤ tran = [ CCTransitionFlipYtransitionWithDuration :0.5scene :[ SingUpScene scene ]];
[[ CCDirector sharedDirector ] replaceScene :tran ];
Listado 4.2: Reemplazo de escena con efecto FlipY
[[ CCDirector sharedDirector ] popScene ];
Listado 4.3: Liberación de la escena actual
Escenas Registro y Login: Aunque no comparten la misma funcionalidad a nivelvisual muestran un formulario muy similar y básicamente se comunican con la capade servicios usando el modelo de datos para realizar las acciones pertinentes, registrarnuevos usuarios e identificar usuarios respectivamente.
Como ejemplo en la figura 4.8, se puede observar el flujo de las llamadas entre lasdiferentes capas para realizar un login con éxito y hacer una transición a la escena dePartidas. El usuario se identifica en la ”Escena Login” llamando al servicio con suscredenciales, el servicio responde con éxito (success) entonces ésta escena llama almétodo scene de .Escena Partidas"la cual devuelve una instancia de si misma y entoncesla escena de login llama al CCDirector para realizar que realice la transición entre lasescenas.
Figura 4.8: Flujo de datos: Login con éxito
Escena Partidas: Esta escena muestra la tabla que contiene las partidas en juego delusuario previamente identificado cuya configuración se muestra en el listado 4.4.
41
� (void) onEnterTransitionDidFinish{self. winSize = [[ CCDirector sharedDirector ] winSize ];CCLabelTTF ⇤ tableTitle = [[ CCLabelTTF alloc] initWithString :@"Mi turno
" dimensions : CGSizeMake (self. winSize .width ⇤ 0.85 / 2, 20)hAlignment : kCCTextAlignmentCenter vAlignment :kCCVerticalTextAlignmentCenter fontName :@" Helvetica Light"fontSize :15];
[ tableTitle setPosition : CGPointMake (self. winSize .width ⇤ 0.05 + (tableTitle . dimensions . width / 2), (self. winSize . height ⇤ 0.8) + (tableTitle . dimensions . height / 2))];
[self addChild : tableTitle z:0 tag :504];CGRect frame = CGRectMake (self. winSize .width ⇤ 0.05 , self. winSize .
height ⇤ 0.2 , self. winSize . width ⇤ 0.85 / 2, self. winSize . height ⇤0.8);
self. tableView = [[ UITableView alloc] initWithFrame :frame style:UITableViewStylePlain ];
[self. tableView setSeparatorInset : UIEdgeInsetsMake (0, 0, 0, 0)];self. tableView . rowHeight = 58;self. tableView . dataSource = self;self. tableView . delegate = self;[[[ CCDirector sharedDirector ] view] addSubview :self. tableView ];}
Listado 4.4: Configuración de la tabla de partidas
self. miTurnoTable = [ MiTurnoTable node ];self. noMiTurnoTable = [ NoMiTurnoTable node ];[self addChild :self. miTurnoTable ];[self addChild :self. noMiTurnoTable ];
Listado 4.5: Creación y agregación de tablas de partidas en la escena
Se muestran dos tablas, una con las partidas que toca jugar al usuario identificado yotra en la que se muestran las que le toca jugar a alguno de los rivales. Cada una deellas está en una clase diferente y se añaden a la escena como se puede ver en el listado4.5.
Para que las tablas muestren las partidas es necesario llamar al servicio para obtenerlas partidas del usuario. El flujo de llamadas se puede ver en la figura 4.9. Cuandose carga la escena de partidas, ésta llama al servicio para obtener los datos de laspartidas del jugador identificado. A continuación el servicio devuelve un diccionariocon las partidas, entonces la escena llama al modelo de datos para que traduzca esosdiccionarios en objetos del mismo.
42
Figura 4.9: Flujo de datos: Cargar Partidas
Para terminar de analizar las tablas de partidas, se muestran las acciones a realizarcuando el usuario escoge una partida en la que le toca jugar en el listado 4.6.
�(void) tableView :( UITableView ⇤) tableView didSelectRowAtIndexPath :(NSIndexPath ⇤) indexPath {CCScene ⇤scene = nil;switch ([ self. partidaList partidaAtIndex : indexPath .row ]. fase) {
case 0:scene = [ ReclutasScene scene :[ self. partidaList
partidaAtIndex : indexPath .row ]];break;
case 1:scene = [ AtaqueScene scene :[ self. partidaList
partidaAtIndex : indexPath .row ]];break;
case 2:scene = [ RecolocarScene scene :[ self. partidaList
partidaAtIndex : indexPath .row ]];}[[ CCDirector sharedDirector ] pushScene :[ CCTransitionFade
transitionWithDuration :0 scene:scene withColor : ccWHITE ]];}
Listado 4.6: Selección de partida cuando se es poseedor del turno
Por último para mostrar un ejemplo del uso de la función guardar en el servicio, semuestra en la figura 4.10 el flujo de datos que hace la presente escena a la hora degenerar una nueva partida y guardarla en el servidor. En este caso la escena de partidas,genera una nueva partida, a continuación con el modelo de datos obtiene un diccionariopara llamar así al servicio y guardar ese diccionario de partida.
43
Figura 4.10: Flujo de datos: Crear Partida
Escena Juego: En este apartado se van a describir las escenas del juego. Son muysimilares ya que todas comparten la capa del tablero y como ya se ha comentado ladiferencia entre ellas son los controles. Lo primero es crear el tablero y añadirlo a laescena, se inicializa la escena configurando el tablero a través del modelo ”Partida”como se puede observar en el listado 4.7.
�(id) initWithMapa :( Partida ⇤) fromPartida {if (self = [ super initWithColor :ccc4 (218 ,219 ,220 ,255) ]) {
self. isTouchEnabled = YES;self. partida = fromPartida ;[self guardarJugador ];self. winSize = [[ CCDirector sharedDirector ] winSize ];NSString ⇤mapName = @" TileMap101x88_2 .tmx";self. tileMap = [ CCTMXTiledMap tiledMapWithTMXFile : mapName ];[self addChild :self. tileMap z:1 tag :1];[self centrarTileMap ];
}return self;
}
Listado 4.7: Creación y configuración del tablero de juego
Después de configurar el mapa se dibujan sobre éste las tropas de caja jugador comose puede ver el el listado 4.8.
� (void) cargarReclutas{
self. playerList = [ PlayerList new ];for ( NSInteger i = 0; i < self. tileMap . mapSize . height ; i++) {
for ( NSInteger j = 0; j < self. tileMap . mapSize .width; j++) {Tropa ⇤tropa = [Tropa new ];[tropa setSprite :[[[ CCSprite alloc] initWithFile :[ self
colorTile :j conY:i]] autorelease ]];
44
[tropa setPosition : CGPointMake (j, i)];CGPoint position = [self pointLocationFromTile : CGPointMake
(j, i)];position .x �= 4;
[tropa. sprite setPosition : position ];[self addChild :tropa. sprite z:2];
tropa. nTropas = (( Casilla ⇤)[self. partida .mapacasillaWithCoor :j andCoorY :i]). nTropas ;
tropa. objectIdPropietario = (( Casilla ⇤)[self. partida .mapacasillaWithCoor :j andCoorY :i]). objectIdPropietario ;
tropa. nTropasLabel = [[ CCLabelTTF alloc] initWithString:[ NSString stringWithFormat :@" %@", @(tropa. nTropas )]
dimensions : CGSizeMake (16, 12) hAlignment :kCCTextAlignmentCenter vAlignment :kCCVerticalTextAlignmentCenter fontName :@" Helvetica "
fontSize :11];[tropa. nTropasLabel setColor :ccc3 (0, 0, 0)];[tropa. nTropasLabel setPosition : CGPointMake (tropa. sprite .
position .x + ([ tropa. sprite boundingBox ]. size.width /2) + 4, tropa. sprite . position .y � ([ tropa. spriteboundingBox ]. size. height / 2) + 6)];
[self addChild :tropa. nTropasLabel z:2];tropa. tropasUsarLabel = [[ CCLabelTTF alloc] initWithString
:@"" dimensions : CGSizeMake (16, 12) hAlignment :kCCTextAlignmentCenter vAlignment :kCCVerticalTextAlignmentCenter fontName :@" Helvetica "fontSize :11];
[tropa. tropasUsarLabel setPosition : CGPointMake (tropa.nTropasLabel . position .x, tropa. sprite . position .y + ([tropa. sprite boundingBox ]. size. height / 2) � 6)];
[tropa. tropasUsarLabel setColor :ccc3 (255 , 255, 255) ];[self addChild :tropa. tropasUsarLabel z:2];[self. playerList addPlayer :tropa ];
}}
}
Listado 4.8: Colocación de tropas sobre el tablero
Una vez se ha visto como se configura el mapa se va a definir brevemente las configu-raciones de los controles, en las diferentes escenas del juego que se están definiendo.
• Refuerzos: En esta escena se configura un menú (CCMenu) con una serie deelementos (CCMenuItem) los cuales son: Botón para volver a la escena de laspartidas, una tropa como leyenda para que el jugador sepa cual es su color, unaetiqueta con el número de tropas de refuerzo que se pueden colocar en el mapa yun botón para pasar a la escena de ataque.
En esta escena se detecta cuando el usuario toca un territorio del tablero y si escontrolado por él, se añade una tropa de refuerzo en el territorio.
• Ataque: En esta escena también se configura un menú como en la anterior, hayelementos similares como el botón para volver a la escena de partidas y el botónpara avanzar de escena de juego. Los controles que se añaden en esta fase son un
45
marcador con diferentes elementos.
El marcador tiene una etiqueta con el nombre del jugador actual, otra con la abre-viatura ”vs” y a continuación el nombre del rival contra el que efectúa el ataque.Debajo de cada jugador se mostrará el resultado de los ”dados” de cada jugadorcuando se pulse el botón ”Ataque” situado debajo de la abreviatura anteriormentecitada.
Todas las escenas de juego actualizan adecuadamente los datos en el servidorcuando los jugadores terminan cada fase, pero en el caso del ataque, se guardacada ver que uno de éstos se realiza, ya que no hay vuelta atrás cuando se harealizado uno. En la figura 4.11 se puede observar el flujo de datos para llevar acabo la función de actualizar las casillas afectadas en el ataque.
Figura 4.11: Flujo de datos: Actualizar casillas después del ataque
• Fortificar: En esta escena la única diferencia es que se muestra el nombre deljugador en una etiqueta centrada en la parte superior.
Aquí se resalta el territorio desde el que se quieren mover tropas, aparece unaetiqueta al lado del sprite que informa del número de tropas que se quieren mover,y una vez seleccionado otro territorio, éstas se mueven y desaparece el resaltadoy la etiqueta.
Modelo de datos: Se utiliza esta capa para hacer más fácil la tarea del manejo dedatos, ya que la capa de servicios devuelve diccionarios, éstos son traducidos a objetosde éste modelo de datos. Son utilizados por las escenas para configurarse y tratar lainformación que contienen. Un ejemplo de modelos de datos utilizados puede verse acontinuación en el listado 4.9.
46
@interface Partida : NSObject
@property (nonatomic , strong ) NSString ⇤ objectId ;@property (nonatomic , strong ) Mapa ⇤mapa;@property ( nonatomic ) NSInteger fase;@property (nonatomic , strong ) JugadorColorList ⇤ jugadorColorList ;@property ( nonatomic ) NSInteger TurnoIndex ;@property ( nonatomic ) NSInteger LeaderIndex ;@property ( nonatomic ) NSInteger LeaderCount ;
@end
@interface Mapa : NSObject
@property (nonatomic , strong ) NSString ⇤ objectId ;@property (nonatomic , strong ) NSString ⇤nombre ;@property (nonatomic , strong ) NSMutableArray ⇤ casillas ;
� ( Casilla ⇤) casillaWithCoor :( NSInteger )x andCoorY :( NSInteger )y;� (void) reemplazarCasilla :( Casilla ⇤) nuevaCasilla ;
@end
Listado 4.9: Ejemplo de Modelos de datos Partida y Mapa
Parse SDK: Se utiliza para comunicarse con el servicio en la nube proporcionado porParse. Para ello se sirve de dos clases principales PFUser y PFObject que básicamenteson diccionarios que asocian elementos con claves. Tienen una funcionalidad muyextensa y aunque se utilizan más elementos, por su extensión no serán nombrados eneste apartado.
Como ejemplo, se han mostrado figuras en algunas de las escenas anteriores para quese pudiera observar el flujo de datos que se realizan cuando se hace uso de la capa deservicios que a continuación se va a detallar. Se han mostrado ejemplos de restaurar(figura 4.9), guardar (figura 4.10) y actualizar (figura 4.11) objetos en el servicio.
Guardar: En el caso de guardar objetos en la nube, se utilizan las clases del SDK
nombradas anteriormente, como se puede observar en el listado 4.10 el ejemplo decreación de nuevos usuarios.
PFUser ⇤newUser = [ PFUser user ];[ newUser setUsername :self. userName .text ];[ newUser setPassword :self. password .text ];[ newUser setEmail :self.email.text ];[ newUser signUpInBackgroundWithBlock :^( BOOL succeeded , NSError ⇤error)
{}];
Listado 4.10: Creación de un usuario utilizando Parse SDK
Restaurar Hay muchas maneras diferentes de buscar o pedir objetos a la base de datosalmacenada en la nube, en algunos casos se utiliza la clase PFQuery para formular
47
peticiones y así obtener la respuesta mas eficiente en cada caso. Como por ejemplocuando se quieren listar las partidas de un usuario, se busca en la tabla partidas donde,en el campo de ”Jugadores” exista la coincidencia con el usuario identificado en laaplicación (listado 4.11).
PFQuery ⇤query = [ PFQuery queryWithClassName :@" Partida "];[query whereKey :@" Jugadores " equalTo :[ PFUser currentUser ]];[query findObjectsInBackgroundWithBlock :^( NSArray ⇤objects , NSError ⇤
error) {}];
Listado 4.11: Petición de partidas del usuario utilizando Parse SDK
Actualizar: Habiendo obtenido el objeto y cambiado los parámetros a actualizar, lamanera de guardar esos cambios en la base de datos se puede ver en el listado 4.12.
PFObject ⇤ casillaObject = [ PFObject objectWithClassName :@" Casilla "];[ casillaObject setObjectId : casilla . objectId ];[ casillaObject setObject :@( casilla .coorX) forKey :@"CoorX"];[ casillaObject setObject :@( casilla .coorY) forKey :@"CoorY"];[ casillaObject setObject :@( casilla . nTropas ) forKey :@" NTropas "];[ casillaObject setObject :[ PFUser currentUser ] forKey :@" Propietario "];[ casillaObject saveInBackgroundWithBlock :^( BOOL succeeded , NSError ⇤
error) {}];
Listado 4.12: Actualización de una casilla utilizando Parse SDK
Los listados explicados anteriormente, son solo pequeños ejemplos del extenso código dela aplicación, éste se puede ver en el CD adjunto donde se encuentra todo el código fuente ylos recursos utilizados para la implementación de Battlex.
4.3 Evolución del proyectoEn la presente sección se va a describir la evolución no sólo de la implementación, sino
también de todo el estudio previo que se ha llevado a cabo para la preparación de ésta.
4.3.1 1a Etapa: Definición general y AnteproyectoReunidos de una parte el director del presente proyecto y el alumno, se definieron los re-
quisitos generales para llevar a cabo el proyecto. A través del estado del arte y los requisitos,se decidieron también las tecnologías a utilizar. Con los aspectos generales definidos y sinhaber encontrado un proyecto igual, se pasó a redactar el Anteproyecto presentado.
4.3.2 2a Etapa: Estudio previofue necesario adquirir conocimientos sobre la plataforma iOS, el lenguaje de programa-
ción de la misma y el framework gráfico utilizado en la implementación, ya que estos no
48
se han adquirido previamente durante la carreara. Fue necesario mucho tiempo durante estaetapa, ya que no sólo no se tenían conocimientos sobre la plataforma, sino que tampoco sehabía tomado contacto previo con ninguna librería de gráficos.
Para adquirir los conocimientos necesarios, han sido de gran ayuda varios libros y sobretodo los blogs sobre la plataforma. A continuación se van a citar algunas de las fuentesusadas, que más importancia han tenido durante el estudio y el desarrollo.
Para realizar los primeros ejemplos e investigar sobre el framework gráfico escogi-do para el desarrollo se utilizaron principalmente dos libros escritos sobre el mismo,Aprende Cocos 2d 2 ([y Andreas Löw(2012)]) y Aprende desarrollo de videojuegoscon cocos 2d en iOS 5 ([y Andreas Löw(2011)]).
El blog de Miguel Díaz Rubio también ha sido de gran ayuda, gracias a sus tutoriales([Rubio(2013a)]).
Durante la primera toma de contacto con iOS, los mejores tutoriales para adquirir la ba-se de programación fueron los del blog de desarrollo Manzana mágica ([Mágica(2012)]).
La mayor comunidad utilizada para la ayuda cuando se ha visto atascado el desarro-llo ha sido Stack Overflow ([Inc(2014)]), indiferentemente de la tecnología en estacomunidad se ha buscado respuesta a las numerosas dificultades encontradas.
4.3.3 3a Etapa: ImplementaciónDespués de la segunda etapa, habiendo adquirido conocimientos básicos sobre como lle-
var a cabo el proyecto y siguiendo la metodología anteriormente explicada, eXtreme Pro-gramming, se llevaron a cabo una serie de iteraciones. Éstas se definieron de manera quese marcaban hitos, para de un modo incremental, completar un prototipo funcional de laaplicación.
1a Iteración: Diseño del tablero de juego: En esta etapa se configuraron las herra-mientas necesarias para crear un ejemplo de proyecto de cocos2d. Este venía con unaescena de ejemplo, sobre la que se comenzaron a crear los primeros diseños del table-ro y a tomar contacto con el framework gráfico. También se implementaron los gestospara calcular los territorios que se pulsaban por el usuario y se pusieron sprites comoejemplo de las tropas que se situarían en el futuro (Figura 4.12).
Como resultado se obtuvo un tablero con territorios hexagonales sobre el que se podíaobtener la información de los territorios pulsados. El proyecto podía ser compilado yprobado en dispositivos reales o el simulador de iOS. Éste mostraba una pantalla deinicio de ejemplo donde estaba dibujado el logo de cocos2d y a continuación cuandocargaba la escena, se podía ver e interactuar con el mapa.
2a Iteración: Escenas de juego: Esta iteración fue la más complicada, pues ya ha-bía que implementar lógica e jugadores, transiciones y sincronización (local en primer
49
Figura 4.12: Protipo Tablero Battlex
lugar). Entonces se crearon las siguientes tareas para cumplir el objetivo de esta itera-ción:
• Implementación del resto modelos para el manejo de datos.
• Creación de las diferentes escenas y sus transiciones.
• Implementación de escena de refuerzos.
• Implementación de escena de ataque.
• Implementación de escena de fortificar.
• Diseño de iconos y botones.
• Diseño de fondos.
El resultado des esta iteración fue un prototipo en el que se podía interactuar con lasescenas con su respectiva lógica, pero sin persistencia en la nube ni inicio de sesión.Permitía colocar nuevas tropas sobre el tablero en la escena de refuerzos, realizar ata-ques entre territorios y migrar tropas de unos a otros. Pero no permitía jugar una partidareal ya que no se tenía gestión de los usuarios. Fue la iteración más larga y en la quese aprendio más sobre el framework y sus diferentes clases, como CCDirector para latransición entre escenas y CCMenu y CCMenuItem para la creación de los menús decontroles de cada escena.
3a Iteración: Controles: En esta etapa se definió la experiencia de usuario de cadaescena.
Para la escena de fortificar se definió la interacción de como colocar los refuerzos sobreel tablero, de manera que cada vez que el usuario pulsara un territorio controlado porél, se sumaba una tropa, mientras quedaran tropas de refuerzo, en cuyo caso se activaríael botón para pasar a la siguiente fase. También se podían deshacer los cambios paracomenzar de nuevo a colocar los refuerzos.
50
En la escena de ataque, éste estaba definido de manera que se seleccionaba el territorioorigen y con un contro de + y -, se aumentaban las tropas con las que efectuar el ataquey, a continuación, se seleccionaba el objetivo. Por último se pulsaba el botón de ataquepara realizarlo. Pero la selección del número de atacantes fue mejorada, pues lo quese decidio fue que se mostraba el número de tropas elegidas al lado de la tropa en elterritorio y, cada vez que se pulsase, éste número aumentaría hasta alcanzar el valordeseado.
Por último la escena de fortificar es muy similar a la elección del atacante en la ante-rior. Se pulsa el territorio tantas veces como para alcanzar el valor de tropas a moverdeseado y se pulsa después en el destino para mover las tropas.
Esta iteración no fue complicada en cuanto a implementación se refiere, sino que se in-tentó alcanzar la mejor experiencia posible para la comodidad del usuario. El resultadofue la experiencia explicada anteriormente, aún sin gestión de usuarios.
4a Iteración: Registro e identificación: En esta iteración se comenzó a integrar elSDK de Parse para iOS, que permitía la comunicación con un servidor en la nube, paraimplementar la lógica de registro e identificación, además de toda la persistencia delos datos del juego en la base de datos remota.
Se creó la cuenta en Parse para registrar la aplicación en el sistema y poder comuni-carse con éste desde la aplicación. Después de integrar el SDK y configurar las clavesen la clase principal de la aplicación, se comenzaron a hacer pruebas de registro eidentificación.
En esta iteración también se crearon los formularios de las escenas de registro y loginy se hicieron pruebas con datos obtenidos desde éstos para realizar las pruebas.
Gracias a la documentación en la web de Parse https://parse.com/docs/, no setuvo demasiada complicación mas allá de la familiarización con el uso de sus clases.El resultado fueron las escenas con los formularios que recibían datos de los usuariosy registraban o identificaban a éstos.
5a Iteración: Persistencia en la nube: Esta iteración fue una de las más complicadas.En ella se hizo uso del portal de la web de Parse para crear la base de datos remota ypoder guardar, recuperar y actualizar los datos de las partidas, jugadores, etc.
En la figura 4.13 se pueden ver el panel de clases creadas en el Explorador de Clasesdel portal de Parse.
Se observan las clases principales para llevar a cabo la gestión de las partidas y losjugadores.
En esta etapa se implementaron una serie de tareas asociadas a la persistencia en lanube:
51
Figura 4.13: Explorador de clases de Parse
• Recuperación de partidas del usuario identificado.
• Recuperación de una partida seleccionada de entre las anteriores y mostrada lainformación en el tablero, en la escena correspondiente a la fase actual de lapartida.
• Creación y guardado de partidas del usuario identificado.
• Actualización de las casillas modificadas en la escena de refuerzos.
• Actualización de las casillas afectadas en los ataques efectuados por un jugadordurante la fase de ataque.
• Actualización de las casillas modificadas durante la fase de fortificar territorios.
El resultado fue un prototipo de aplicación en la que se podían registrar e iden-tificar usuarios y hacer uso de todas las funcionalidades citadas, es decir, ya sepodía jugar con la aplicación a falta de la gestión de notificaciones y revision dediseño.
6a Iteración: Notificaciones: Se llevó a cabo en esta la gestión de notificaciones, paraavisar a los jugadores de los cambios en sus partidas, haciendo uso de la plataforma deparse.
Se puede observar en la figura 4.14, como se muestra la llegada de una notificación deBattlex.
Para realizar esta iteración se hizo uso nuevamente del SDK de Parse y de una claseespecial proporcionada por la plataforma llamada ”Installation” (Instalación). En ellase guardaban los identificadores únicos de dispositivo (UDID) en el momento de laidentificación, para asociar un usuario con su dispositivo.
Entonces para mandar una notificación, una vez un jugador había completado todas lasfases de su turno, se configura ésta y se le dice a la plataforma que mande el mensajeal dispositivo asociado con el usuario al que pasa el turno.
7a Iteración: Revisión de Diseño: Con el fin de que la aplicación tuviera una interfazagradable y actualizada a los diseños de aplicaciones actuales, se llevo a cabo unarevisión de diseño de iconos, creando éstos con programas como Adobe Illustrator, el
52
Figura 4.14: Notificación de partida de Battlex
cual también se usó para diseñar los fondos, botones, tablero, hexágonos y con unaplantilla de soldados, personalizarlos para hacer uso de estos dentro de la aplicación.
Se obtuvo por tanto la aplicación que ya funcionaba correctamente en la iteraciónanterior, pero con la interfaz mejorada.
4.3.4 4a Etapa: DocumentaciónEn esta última etapa se comenzó a redactar la memoria, detallando toda la evolución,
herramientas, estado del arte, etc, en el que se ha basado para realizar el trabajo.
4.4 Pruebas RealizadasEn esta sección se definirán los diferentes tipos de pruebas realizadas sobre la aplicación.
Pruebas de compatibilidad entre dispositivos, pruebas de jugabilidad y pruebas de funciona-lidad.
4.4.1 Pruebas de CompatibilidadEn la subsección 2.4.2 se identificaron los dispositivos que se iban a utilizar para probar
la aplicación durante el desarrollo. El problema es que al comienzo del desarrollo sólo setenía como dispositivo de pruebas el iPhone 4, lo que derivó mas tarde en problemas decompatibilidad al compilar la aplicación para iPad.
Cuando se realizó la primera compilación del proyecto para el iPad, ya se había implemen-tado toda la lógica de las escenas del juego, sólo quedaba por implementar la integración conel servicio, entonces aparecieron problemas de compatibilidad:
Interfaz: Los recursos (como imágenes, fondos, etc) no estaban hechos para soportarla resolución del iPad. Las dimensiones de los elementos de pantalla (cajas de texto,botones, etiquetas, etc) no estaban implementadas relativas al tamaño de cada pantalla.
Lógica: El tamaño del mapa es siempre el mismo, y la lógica para detectar la celda
53
pulsada por el usuario está hecha para un mapa con las dimensiones de un iPhone.
Versiones: La aplicación se ha probado en versiones de iOS desde la 5.0 y el proyectoestá configurado para que la aplicación pueda ser usada en dispositivos iOS con éstaversión como mínimo.Apple recomienda siempre que saca una nueva versión de iOS, que los desarrolladoresactualicen sus aplicaciones a esa última, sin embargo se puede ofrecer la aplicaciónpara diferentes versiones, con esto se pueden aprovechar las mejoras del sistema ope-rativo en cada versión, sin que los usuarios con versiones anteriores tengan que dejarde actualizar la aplicación.
La solución a estos problemas de compatibilidad se solucionó configurando el proyectopara que la compilación no fuera universal (Figura 4.15), sino que fuera optimizada paraiPhone y en este caso el iPhone 4.
Figura 4.15: Dispositivos de la configuración del proyecto
Esta solución no significa que la aplicación no funcione en iPad, pero si que funcionaráen el modo iPhone en este dispositivo. Este modo permite escalar la aplicación para que sevea dos veces más grande y sea completamente funcional al igual que en iphone 4 (Figura4.16).
Figura 4.16: Captura de Battlex en ejecución en iPad
54
4.4.2 Pruebas de JugabilidadPara realizar las pruebas de jugabilidad se hizo una encuesta (Anexo D) que realizaron
algunos compañeros. A continuación se van a mostrar los resultados obtenidos mediantedicha encuesta y las conclusiones al respecto.
Los siguientes gráficos muestran los resultados obtenidos después de encuestar a 15 per-sonas.
Jugabilidad Intrínseca
Figura 4.17: Resultados de la faceta de Jugabilidad Intrínseca
En la gráfico de la figura 4.17 se pueden ver los puntos flojos de esta faceta, como en laefectividad, que se debe a la estadística de la puntuación obtenida de los dados ya que queperjudicaría al atacante, y el requisito social se debe a que no se pueden elegir los rivales ala hora de crear las partidas, estos se general aleatoriamente.
Jugabilidad Mecánica
Figura 4.18: Resultados de la faceta de Jugabilidad Mecánica
En general la figura 4.18 muestra buenos resultados, sin embargo la menor puntuación la
55
obtiene el requisito de satisfacción, esto se debe a que se utiliza un servidor externo y podríadarse el caso de qu tarde en responder a las peticiones.
Jugabilidad Interactiva
Figura 4.19: Resultados de la faceta de Jugabilidad Interactiva
En la figura 4.19 se obtienen resultados muy bajos en el requisito social ya que no existecomunicación entre los jugadores durante la partida, y la motivación puede deberse a que nose interpretan fácilmente los resultados de los ataques.
Jugabilidad Artística
Figura 4.20: Resultados de la faceta de Jugabilidad Artística
En general en la figura 4.20 se obtienen buenos resultados, la puntuación más baja es laobtenida en la faceta de satisfacción, en lo referido al diseño de la interfaz de usuario.
56
Jugabilidad Intrapersonal
Figura 4.21: Resultados de la faceta de Jugabilidad Intrapersonal
En la figura 4.21 se obtiene puntuación regular en 4 de 7 requisitos:
Satisfacción: Se ve como los usuarios están a medio camino entre el juego de tablerooriginal y el uso de la aplicación
Aprendizaje: Se interpreta de manera que los jugadores que conocen el juego si sabenusar la aplicación y los que no necesitan ayuda para conocer las reglas.
Efectividad: Como se ha comentado antes, si las partidas no avanzan rápido es debidoa que la mayoría de las puntuaciones de los ataques favorecen a los defensores.
Inmersión: El usuario no tiene demasiada sensación de que está organizando sus tropasen una guerra.
Jugabilidad Interpersonal
Figura 4.22: Resultados de la faceta de Jugabilidad Interpersonal
57
Los puntos más flojos de esta faceta son:
Inmersión: La comunicación y control sobre las partidas no está presente mas allá dejugar la partida seleccionada, no hay personalización de las mismas.
Motivación: No existe sistema de recompensas en el juego, por lo que este requisitotiene una puntuación muy baja.
Conclusiones
La puntuación global sobre la aplicación al realizar el test sobre 15 personas ha sido de3,46 sobre 5.
Se es consciente de las limitaciones en cuanto a todos los aspectos que engloban la rea-lización de un juego, por eso hay algunos puntos que mejorar en el futuro, estos puntos demejoras futuras se expondrán más adelante en la sección 5.5.
4.4.3 Pruebas de FuncionalidadPara realizar las pruebas de funcionalidad del software, durante el desarrollo se implemen-
taron registros que mostraban en la consola de XCode los resultados a la hora de procesarlos datos.
Para realizar los registros se utiliza la clase de objective-C llamada NSLog, en el listado4.13 se puede ver un ejemplo del código necesario para lanzarlo. A continuación se describi-rán algunas de las partes que componen la aplicación, con el fin de mostrar como se realizanlos registros a la hora de probar las funcionalidades del software y recibir retroalimentaciónde los eventos que se realizan durante la ejecución de la misma.
NSLog(@"Error: %@ %@", error , [error userInfo ]);
Listado 4.13: Ejemplo de registro con la clase NSLog
Obtener partidas de usuario
En la subsección 4.2.2 se definió la manera de crear la escena donde se cargan las partidasde usuarios y se muestra un diagrama de flujo de datos (Figura 4.9) de las llamadas quese producen al cargar las partidas. A continuación se describirá la manera de registrar loseventos que suceden durante este flujo de datos.
Carga de la escena: Existen dos maneras de acceder a esta escena, la primera es haciendologin desde la escena de login y la segunda es entrando en la aplicación con el usuariocacheado localmente en el dispositivo.
Desde login: En el siguiente listado (listado 4.14) se muestran los registros que secapturan desde que el usuario se identifica hasta que se carga la escena de partidas.
58
2014�08�21 21:16:46.687 Battlex [608:60 b] ( Escena Login) LoginCorrecto
2014�08�21 21:16:46.688 Battlex [608:60 b] ( Escena Login) CargandoGameListScene
2014�08�21 21:16:46.691 Battlex [608:60 b] ( Escena Partidas )Instancia de la escena creada
2014�08�21 21:16:47.262 Battlex [608:60 b] ( Escena Partidas ) Menusy tablas cargados
Listado 4.14: Login correcto, transición a Escena Partidas
Usuario cacheado: En el listado (listado 4.15) se muestrar los registros que se cap-turan desde que arranca la aplicación y se identifica el usuario cacheado, hasta que secarga la escena de partidas.
2014�08�21 21:47:42.630 Battlex [624:60 b] ( AppDelegate ) Usuario encache
2014�08�21 21:47:42.664 Battlex [624:60 b] ( AppDelegate ) CargandoGameListScene
2014�08�21 21:47:42.669 Battlex [624:60 b] ( Escena Partidas )Instancia de la escena creada
2014�08�21 21:47:42.711 Battlex [624:60 b] cocos2d : animationstarted with frame interval : 60.00
2014�08�21 21:47:42.743 Battlex [624:60 b] cocos2d : surface size:960 x640
2014�08�21 21:47:43.068 Battlex [624:60 b] ( Escena Partidas ) Menusy tablas cargados
Listado 4.15: Usuario cacheado, transición a Escena Partidas
Por supuesto, cuando el dispositivo se queda sin conexión a internet y se intanta acceder alservicio, también se muestra un registro con el mensaje de error concreto (listado 4.16).
2014�08�21 21:55:08.342 Battlex [624:182 b] Error: Error Domain =NSURLErrorDomain Code=�1009 "The Internet connection appears to be
offline ." UserInfo =0 x17da9930 { NSErrorFailingURLStringKey =https ://api.parse.com /2/ update , NSErrorFailingURLKey =https :/ /api.parse .
com /2/ update , NSLocalizedDescription =The Internet connectionappears to be offline ., NSUnderlyingError =0 x17d6e9c0 "The Internet
connection appears to be offline ."} (Code: 100, Version : 1.2.19)
Listado 4.16: Registro de error sin conexión
Obtener partidas del servicio
A continaución se definirán brevemente los registros con los cuales se puede observarcomo se van obteniendo los datos del servicio, desde las partidas de un jugador, despuéslos jugadores que forman la partida, y por último las casillas que conforman el mapa, hastaconseguir mostrar los datos de las partidas en las tablas.
Obtener partidas del jugador: Cuando la petición al servicio ha tendido éxito antes
59
de comenzar el procesamiento de la respuesta se muestra un registro en la consolainformando de ello.
Obtener jugadores de cada partida: Una vez que se han recuperado las partidas, porcada una de ellas se manda una nueva petición para obtener los jugadores, cuando llegala respuesta un registro informa del resultado.
Obtener casillas del mapa: Nuevamente, cada tabla por separado creará otra peticiónpor cada elemento de la tabla para pedir las casillas que corresponden al mapa de lapartida, este ya ha sido recuperado en la petición de la partida. Se mostrará un registrocada vez que se obtengan las casillas de una partida.
Mostrar contenido de las partidas en las tablas: Cuando se ha terminado de recibirtoda la información anterior, se lanza un método de la clase UITableView llamado”reloadData” que realizará la recarga de los datos para mostrarlos en pantalla, una vezse haya realizado la recarga un registro informa de ello, significará que en la pantallase podrá visualizar la información de las partidas.
Como ejemplo en la lista 4.17, se muestran los registros de obtener los datos de las partidasdel usuario ”Test”, para que no fuera muy extenso, se creó este usuario con una sola partida,así se entiende mejor la secuencia de los registros.
2014�08�21 23:54:32.498 Battlex [704:60 b] Partida Creada2014�08�21 23:54:36.468 Battlex [704:60 b] ( GameListScene ) Partidas de
Test recibidas2014�08�21 23:54:36.471 Battlex [704:60 b] Partida : <Partida : yN7TlsyWqx
:( null)> {Fase = 1;Jugadores = (
"<PFUser : a8OWYkf2HY :( null)> {\n}","<PFUser :1 AUwXcSOe7 :( null)> {\n}","<PFUser :8 lshWGgpNE :( null)> {\n}"
);LeaderCount = 0;LeaderIndex = "�1";Mapa = "<Mapa: gp7JHfecHK >";TurnoIndex = 0;
}2014�08�21 23:54:36.720 Battlex [704:60 b] ( GameListScene ) Jugadores de
partida : yN7TlsyWqx recibidas2014�08�21 23:54:37.169 Battlex [704:60 b] ( MiTurnoTable ) Casillas de
partida : yN7TlsyWqx recibidas2014�08�21 23:54:37.183 Battlex [704:60 b] ( MiTurnoTable ) Tabla
recargada
Listado 4.17: Registros de carga de partidas
En este punto ha quedado definido el registro que se hace de los comportamientos de laaplicación desde que se hace login hasta que se muestran la información de las partidas enlas tablas.
60
Interacción con el mapa
En este punto se definirá un ejemplo de como se tiene constancia de que se está captu-rando correctamente el territorio que el usuario está pulsando. Con esto quedarán definidoslos diferentes comportamientos de la aplicación, no se ilustrarán los demás porque resul-taría repetitivo, aunque sus registros están implementados en el código. Comportamientoscomo navegar entre escenas, recuperación de datos desde el servidor y configuración de loselementos de la vista, así como los registros de la interacción del usuario quedarán defini-dos.
Cálculo de territorio pulsado: La pantalla de ataque será sobre la que se mostrará elejemplo de captura y cálculo del territorio pulsado por el usuario.
En la figura 4.23 se puede observar como el territorio situado en la primera fila y cuartacolumna está sombreado y muestra el número de tropas atacantes en blanco.
Figura 4.23: Ejemplo del territorio pulsado
Justo desde el comienzo de la pulsación del usuario sobre la pantalla del dispositivo em-piezan a producirse los cálculos, cuyo registro se muestra en el listado 4.18.
2014�08�22 00:27:53.669 Battlex [725:60 b] ( AtaqueScene ) Punto pulsado :132.50 200.00
2014�08�22 00:27:53.674 Battlex [725:60 b] ( AtaqueScene ) Pixel pulsado :(265.0 , 400.0)
2014�08�22 00:27:53.680 Battlex [725:60 b] ( AtaqueScene ) Calculandoterritorio pulsado
2014�08�22 00:27:53.683 Battlex [725:60 b] ( AtaqueScene ) Territorioobtenido : (3, 0)
2014�08�22 00:27:53.687 Battlex [725:60 b] ( AtaqueScene ) Tropa Sombreada: (3.0 , 0.0)
2014�08�22 00:27:53.700 Battlex [725:60 b] ( AtaqueScene ) Aumentandoatacantes
Listado 4.18: Registros de territorio pulsado
61
Como se puede observar en el registro del listado anterior, primero se muestra la coorde-nada del punto seleccionado, se llama punto porque por defecto iOS te devuelve esta medida,en una pantalla retina como la que se utiliza en la prueba equivale a dos píxeles por punto,como se muestra en el segundo registro. Después de mostrar esta información se procede acalcular el territorio pulsado, es (3, 0) porque el primer número de fila y columna empiezapor 0. Una vez se ha calculado la coordenada del mapa del territorio, se realizan las llamadascorrespondientes para configurar visualmente el territorio.
Conclusiones
Aunque no se han realizado test unitarios, el sistema de pruebas realizado ofrece muchavisibilidad sobre el estado de la aplicación en caso de que se produzca cualquier tipo de erroro excepción.
Como se ha tenido constancia, sobre todo en las llamadas al servicio, de cuando se produ-cían errores que se tenía mucha información del estado de la aplicación como se ha podidover en los registros cuando se pierde la conexión, se ha considerado suficiente para gestionarlas pruebas de esta manera.
Aun así, para dar mas visibilidad sobre los errores, se podrían integrar herramientas degestión de errores, de terceros, que envían informes de errores y otros registros que se pu-dieran considerar relevantes, que les ocurren a los usuarios cuando la aplicación esta enproducción. Una de las posibilidades podría ser la reciente herramienta obtenida por Applellamada TestFlight (https://www.testflightapp.com).
62
Capítulo 5
Resultado y Conclusiones
EN este capítulo, después de que el esfuerzo realizado durante el desarrollo haya dado susfrutos, se resumirá de un modo general el trabajo llevado a cabo. También se procederá
a comparar los objetivos propuestos con los conseguidos y se expondrán las limitaciones delas tecnologías utilizadas y propuestas de trabajo futuro.
5.1 ResultadoEl resultado final obtenido como Trabajo fin de grado ha sido Battlex, nombre que apare-
ce de fusionar la palabra en ingles Battle, que en la categoría militar significa: ”Encuentrohostil entre fuerzas militares opuestas”, con otra palabra inglesa, Hexagon, que en castellanoquiere decir ”hexágono” o ”polígono de 6 lados”. La pronunciación de la primera sílaba dela palabra Hexagon es similar a la de la letra ”x” en inglés. Ese es el origen del nombre, quehace referencia a batallas en territorios con forma de hexágono, forma geométrica escogidapara el diseño del tablero.
Para realizar el desarrollo, se ha seguido la metodología ágil, eXtreme Programming. Eldiseño y la experiencia de usuario se han realizado con el criterio UCD, siguiendo patrones yguías de estilo de diseños planos, más simples y profundos.
El desarrollo se ha realizado de manera nativa para el sistema operativo de Apple, iOS,optimizando el desarrollo para el dispositivo iPhone 4. De esta manera la dimensión delmapa no cambia para un dispositivo iOS de 4 pulgadas, como podrían ser el iPhone 5, 5Co 5S, ya que con el dispositivo en posición horizontal, solo cambia la anchura, y se tomóla decisión de que los hexágonos fueran regulares, con lo cual se debían dejar iguales paraambas resoluciones para no perder espacio para los controles.
Aún así la experiencia de usuario es muy similar, si no tenemos en cuenta que los disposi-tivos iPhone de 5a generación son superiores en hardware.
En las siguientes figuras se muestra el resultado visual de la aplicación, las diferentespantallas que la forman.
En la figura 5.1 se puede ver como el usuario a través de un formulario podrá introducirsus datos para registrarse o identificarse.
63
Figura 5.1: Pantallas Registro y Login
Figura 5.2: Pantalla partidas
En la figura 5.2 se muestra la pantalla en la que el usuario, una vez identificado, podráinteractuar con sus partidas, crear nuevas o cerrar la sesión.
En la figura 5.3 se muestra la pantalla de refuerzos, en la que el usuario podrá colocar lastropas de refuerzo sobre sus territorios, deshacer los cambios, volver a la pantalla de partidaso pasar a la siguiente fase.
En la figura 5.4 se puede observar la pantalla de ataque, en ella el usuario podrá realizarsus ataques, seleccionando un territorio aliado y uno enemigo para realizar el ataque, cuyosresultados se mostrarán en esta misma pantalla. A parte de esta función se podrá volver a lapantalla de partidas o pasar a la siguiente fase igual que en la pantalla anterior.
Finalmente se muestra la figura 5.5 en la que se observa la pantalla de fortificar los terri-torios, en ella el usuario podrá realizar la fortificación de los territorios aliados que desee ylas funciones comunes de las pantallas del juego citadas anteriormente.
64
Figura 5.3: Pantalla refuerzos
Figura 5.4: Pantalla ataque
Figura 5.5: Pantalla fortificar
65
5.2 Aspectos Generales
Al principio del documento se citaban varias aplicaciones asíncronas famosas del mercadoactual de aplicaciones móviles. Pero no se encontró ninguna que estuviera basada en juegosde conquista de territorios. Entonces se empezó a definir lo que sería la descripción delproblema.
Con lo cual, sin alternativas en el mercado de aplicaciones, al menos directas, pues existeninfinidad de juegos de guerra, estrategia y conquista de territorios, Battlex podría ser unareferencia en el campo de los juegos asíncronos, ya que se diferencia mucho del resto deaplicaciones asíncronas actuales en la temática de juego, aunque todos comparte el mismoorigen, los juegos de mesa o tablero.
5.2.1 Adaptación de las reglas originales para crear una aplicaciónasíncrona
Una de las fases clásicas de juegos de mesa como Risk, necesita de una respuesta directadel rival a la hora de efectuar los ataques.
A la hora de definir los ataques, en el juego original, el defensor puede decidir hacer usode uno o dos dados de defensa. En el caso de Battlex se suprime esta decisión por parte deldefensor, ya que en el momento del ataque solo el atacante está interactuando con la partida.Con lo cual cuando se efectúa un ataque el número de dados de la defensa será el máximoposible, siendo 2 en caso de haber 2 o más tropas defendiendo un territorio atacado.
Otro de los aspectos que requerían una interacción menos amigable por parte de los in-tegrantes de una partida era, el reparto de territorios. Ya que en el juego original, éstos sesitúan en el tablero en orden de uno en uno pasando el turno de jugador en jugador en cadacolocación.
El reparto de territorios se adaptó de la siguiente manera: Se hace un reparto aleatorio delos territorios siempre manteniendo el mismo número de los mismos controlados por cadajugador.
En este aspecto, la estrategia de los jugadores al comienzo del juego podría verse mermada,sin embargo, se ha definido una estrategia de adyacencia a la hora de atacar, de tal maneraque todos la amenaza de conquistar los territorios este balanceado.
5.3 Objetivos Alcanzados
En el capítulo 2 se marcaron una serie de objetivos específicos y operativos, que ahora sevan a repasar para explicar como se ha llevado a cabo su cumplimiento.
66
5.3.1 Objetivos EspecíficosLas siguientes fases mezclan lo que sería una partida del juego complementado confuncionalidades para adaptarlo a la plataforma móvil:
• 1. Registrar usuario
• 2. Identificar usuario
• 3. Crear partida
• 4. Unirse a las partidas creadas por otros usuarios
• 5. Distribuir nuevas tropas sobre sus territorios en el tablero
• 6. Realizar ataques para conquistar nuevos territorios
• 7. Redistribuir tropas de territorios dominados
En el capitulo 1 se proponía esa lista de fases que podrían ser ahora las de Battlex.Ya que se han alcanzado todos los puntos citados, gracias a la implementación de lasdiferentes escenas y la gestión de usuarios.
1. Diseñar la mecánica del juego e implementar mediante análisis de herramientas,tecnologías y estado del arte con el fin de asegurar la jugabilidad y potenciar el interésdel usuario.
Para cumplir este objetivo se ha realizado una aplicación con la temática de conquista,pero siguiendo el estilo de la gestión de partidas de las diferentes aplicaciones asín-cronas que hay en el mercado. Ayudandose de adaptaciones de Risk en juegos paraordenador y consolas se definieron las reglas que debía tener la aplicación para cum-plir el requisito general de ser asíncrona. Y complementado las reglas clásicas quetanto éxito han tenido desde la creación de este género como juego de tablero con lasinterfaces táctiles y el servicio de notificaciones, se obtiene el interés del usuario sobrela aplicación.
2. Implementar el juego mediantes los lenguajes y tecnologías más apropiados paraalcanzar el objetivo general.
Ya que el trabajo está orientado al sistema operativo iOS, se pudieron elegir las herra-mientas para desarrollar de manera nativa para esta tecnología. Además, ya que tantococos2d for iPhone como Parse tienen SDK escrito en Objective-C, lenguaje nativo deiOS, todo el desarrollo de la aplicación ha sido llevado a cabo en éste lenguaje. Conlo cual, dado que los lenguajes y tecnologías utilizados fueron los más apropiados, secumplió este objetivo.
3. Asegurar el correcto funcionamiento y la consecución del objetivo general mediantepruebas del software generado.
Para cumplir este objetivo, se han llevado a cabo durante todo el proceso de desarrollo,pruebas de interacción, estrés y funcionamiento por parte del equipo de desarrollo para
67
asegurar que cada iteración cumplía con un correcto funcionamiento.
5.3.2 Objetivos Operativos1. Se realizarán una serie de tutoriales y pruebas para avanzar en el aprendizajedel lenguaje de programación para la plataforma escogida llamado Objective-C. Seharán diferentes tareas, desde interfaces básicas hasta realizar peticiones a serviciosweb. También se realizará una estudio previo de los diferentes frameworks que sepudieran utilizar en el proyecto y una vez elegido el que se integrará en el proyecto, seprocederá a realizar tareas incrementales para aprovechar el tiempo de aprendizajeen el desarrollo de la aplicación final.
Para cumplir este objetivo, como se puede observar en el capítulo 4, se crearon lasinterfaces de usuario para las escenas dle juego utilizando cocos2d. También se hi-zo uso de la metodología incremental eXtreme Programming para la realización deiteraciones, que de manera incremental, ayudaron a desarrollar la aplicación.
2. Simplificar y/o adaptar las reglas de un juego de estrategia clásico, para que hagauso de la interacción de un dispositivo móvil con pantalla táctil. Esto implica tambiénadaptar las reglas para que la jugabilidad se lleve a cabo de manera asíncrona, esdecir, que los diferentes integrantes de una partida no tenga porqué coincidir en estarconectados al mismo tiempo. Para adaptar el juego se deberá partir de las fases quecomponen un turno, descritas en la sección 1.2.2 del capítulo 1.
El cumplimiento de este objetivo operativo ha sido explicado anteriormente en la sec-ción 5.3.1.
3. Diseñar e implementar las diferentes escenas del juego. Desde el inicio de sesióny el registro hasta el visor de partidas y el tablero. Las primeras no tendrán muchacomplejidad ya que deberán mostrar una interfaz sencilla para que lo usuarios intro-duzcan sus credenciales, sin embargo, el visor y el tablero tendrán mas complejidad.Este último tendrá que representar territorios y que los usuarios vean que jugadoreslos controlan.
Se crearon todas las escenas, desde las más sencillas a las mas complejas, usando co-cos2d para iPhone. Y para representar los territorios se escogió un tablero, en el quelos territorios son de forma hexagonal, de manera que cumpliendo las recomendacio-nes de Apple sobre interfaces de usuario, se mostraran en la pantalla de manera quelos usuarios pudieran interactuar con ellos.
4. Se realizará una búsqueda de información a través del estado del arte, con aplica-ciones similares, para conocer como resuelven diferentes problemas de interacción ysaber como se podría enfocar el diseño de la interfaz de usuario, que es uno de los ele-mentos mas importantes en proyectos de este tipo. También se hará uso y se tendrá encuenta las recomendaciones que ofrece Apple en su documentación [Apple(2014a)].
68
Se hizo un estudio sobre las aplicaciones asíncronas más famosas, para coger ideas ypoder representar debidamente la interfaz de usuario y que éste entendiera lo que sequería transmitir.
5. La aplicación dispondrá de un servicio web o backend, con el que realizar llamadaspara guardar, obtener o modificar la base de datos allí almacenada. Esta dispondráde todos los elementos necesarios para persistir las partidas y los usuarios. Tambiéndispondrá de un SDK para realizar peticiones al servicio REST.
Este objetivo se cumplió de la siguiente manera: Integrando el SDK de Parse para iOSen el proyecto y configurando la aplicación, base de datos y notificaciones push en elportal web, como se puede ver en el anexo A.
6. Una notificación push es, básicamente, un mensaje enviado por un servidor a uncliente que está suscrito a sus notificaciones [Mateos(2013)]. Se implementará esteservicio para que los usuarios no tengan que estar pendientes del estado de las parti-das en las que participan, sino que sea el propio dispositivo que te avise a través deesta tecnología de cuando tienes el turno de alguna de las partidas en juego.
Para cumplir este objetivo se configuró debidamente la aplicación para poder suscribirlos dispositivos de los usuarios para que pudieran recibir notificaciones. En el portalde parse se configuró la aplicación y la base de datos para poder enviar notificacionesa los dispositivos usando su SDK.
5.4 Limitaciones encontradasTodas las limitaciones que se han tenido durante el trabajo han sido relacionadas con las
tecnologías utilizadas, al tener un completo desconocimiento de estas en el momento deempezar.
Al comienzo se realizaron una serie de tutoriales y ejemplo simples de aplicaciones, prime-ro usando iOS y más tarde integrando en éste cocos2d. La curva de aprendizaje del lenguajeutilizado Objective-C es más alta que la de otros lenguajes como java, pero además nunca sehabía tenido contacto con estas tecnologías. Sobre el lenguaje java si se tenían conocimientosprevios, pero la adaptación al lenguaje utilizado en el trabajo ha sido más complicada, masaún cuando se trataba de hacer iteraciones más complejas en el desarrollo.
También adaptarse a la arquitectura de cocos2d ha sido complicado, no sólo por que el len-guaje es el mismo, Objective-C, sino porque nunca se había tratado con frameworks gráficos,ni se tenían conocimientos sobre lógica de videojuegos.
Por último añadir que tampoco se tenían conocimientos sobre integración con serviciosweb, como el utilizado en la aplicación. Sólo se habían realizado tutoriales sobre la integra-ción de bases de datos SQlite, descritos en el Anexo C.
69
En cuanto a documentación, la mayoría de lo consultado estaba en inglés, tanto los librossobre las tecnologías como su comunidad de usuarios y los portales utilizados, lo que conlle-va otro esfuerzo más a la hora de encontrar solución a los problemas que se han tenido.
5.5 Trabajo FuturoA continuación se proponen una serie de mejoras que se podrían realizar para ampliar el
trabajo realizado.
Para que los usuarios de la aplicación pudieran personalizar sus partidas, se podría crearun sistema de creación de partidas que no fuera aleatorio y que el creador pudiera elegir elnúmero de jugadores, el tamaño del mapa y su forma, el color o las imágenes de las tropas,etc. Creando una nueva pantalla en la que se mostrara un formulario con las opciones depersonalización de la nueva partida e implementado la lógica se podría llevar a cabo estamejora.
Otra mejora que se podría realizar es integrar un sistema de logros como Game Centerpara iOS, así los jugadores de todo el mundo podrían ver un ranking de puntuación y retarsedesde el portal. Utilizando el framework de Game Center se podría integrar la aplicación paraofrecer este sistema, este framework es nativo de iOS, la lógica no sería muy complicada,excepto la parte de generar los logros, ya que habría que proponer estos de manera quesupongan un reto para los usuarios.
Otra de las mejoras sería crear una capa mas en la arquitectura para que la dependenciade un servicio externo fuera mínima y fácilmente se pudiera cambiar de sistema de gestiónde la persistencia. En Objective-C la manera de implementar esta capa podría ser a través deuna serie de interfaces que pudieran abstraer a las llamadas al servicio del SDK externo, esdecir, las llamadas aceptarían objetos nativos que se tradujeran al modelo de datos sin queestos se conocieran.
Otra mejora sería añadir animaciones en el mapa para que fuera más atractiva la interfaz.Por ejemplo animaciones de movimiento de tropas, explosiones cuando se realizan los ata-ques, etc, mejorarían la experiencia de usuario. También sería posible realizar unas texturasmás detalladas para mejorarla.
Como en los ejemplos de aplicaciones que se han visto en el estado del arte, se podríarealizar un chat de partidas, en las que lo usuarios que la forman pudieran hablar entre ellospara, por ejemplo, formar pactos contra otros. Esto mejoraría la estrategia y por tanto lajugabilidad. Si el servicio utilizado en la aplicación pudiera almacenar los datos de los chats,creando una nueva pantalla en la aplicación y las correspondiente lógica de peticiones, sellevaría a cabo esta mejora.
Para realizar de manera nativa toda la aplicación para iOS, se podría utilizar el frameworkgráfico integrado a partir de iOS 7 así sería mucho más mantenible el desarrollo. Llamado
70
SpriteKit, podría ser una mejor elección que el presente framework utilizado, ya que le dasoporte el fabricante del sistema operativo y el hardware.
5.6 ConclusionesHa sido gratificante enfrentarse a una serie de tecnologías totalmente desconocidas, em-
pleando todos los conocimientos previamente adquiridos durante la carrera, y poder llevar acabo este trabajo.
Esto ha abierto un mundo de oportunidades futuras muy motivador. Ya que a nivel deusuario el alumno era apasionado por esta tecnología, y ahora lo es también del desarrollode ésta.
Lo mejor que ha ocurrido con la realización del trabajo, ha sido el aprendizaje de la pla-taforma móvil como es iOS, ya que complementa los estudios que el alumno ha realizadodurante la carrera. También el hecho de conseguir crear una aplicación videojueguil, consi-guiendo los objetivos marcados, para una de las plataformas más extendidas, ha sido muysatisfactorio.
Por último añadir que la realización del trabajo me ha servido para encontrar trabajo, delo cual estoy muy agradecido, pero no sólo eso sino que también estoy trabajando en laplataforma móvil en al que está basada el presente trabajo.
71
ANEXOS
73
Anexo A
Parse
DADO que la persistencia y comunicación usando la nube, es uno de los pilares masimportantes de la aplicación. Se va a describir el proceso de creación de las tablas
aprovechando el potencial del panel de control que proporciona Parse desde su web www.
parse.com.
A.1 Registro y ConfiguraciónInmediatamente después de hacer el registro como usuario de Parse, se registra la aplica-
ción en Parse para conseguir las App Keys (Figura B.4), que darán acceso a la plataformadesde la aplicación, una vez ésta sea configurada.
Figura A.1: Claves de aplicación de Parse
Para configurar el SDK en la aplicación y poder comenzar a utilizarlo se añaden las cre-denciales obtenidas de la siguiente manera:
#import <Parse/Parse.h>
[Parse setApplicationId :@" v4pWhIwQpGnDcWwwEXkLhpux7Gkf99lWj9VU6IcY "clientKey :@" EUBzoQqQo0nn4u33dOW7rxs3fPbdtWM0OSjWJwGy
"];
Listado A.1: Configuración en el cliente de las credenciales de Parse
75
Una vez realizados estos primeros pasos, ya se puede comenzar a usar el SDK correspon-diente a la plataforma, en este caso iOS.
A.2 Panel de controlDesde el panel de control se puede elegir la aplicación que queremos configurar, pues se
pueden registrar varias aplicaciones con la misma cuenta. Se mostrará un resumen de losusuarios y las peticiones, es decir, el tráfico que tiene la aplicación (Figura A.2).
Figura A.2: Resumen de Battlex en Parse
Como se puede observar en la figura A.2, muestra una serie de apartados, de los cuales elque más nos interesa en este momento es ”Data Browser” (Explorador de datos).
A.2.1 ClasesYa se han citado anteriormente las clases o tablas que componen la base de datos, pero
ahora se va a describir el contenido de éstas.
Para empezar, se pueden crear clases de varios tipos nativos que ofrece Parse o persona-lizada (Figura A.3. En el caso de Battlex todas las clases serán personalizadas, excepto lade usuario e instalación, ya que la plataforma dispone de sistemas de seguridad y control deusuarios y dispositivos.
Figura A.3: Creación de tablas o clases en Parse
76
A modo de ejemplo, en la figura A.4 se pueden ver los campos que forman parte de latabla ”User”.
Figura A.4: Campos de la tabla User en Parse
Como se puede apreciar, sólo uno de los usuarios tiene registrado el ”deviceId”. Estose debe a que cuando un usuario cierra sesión en la aplicación, también lo realiza en laplataforma de Parse, es decir, en ese momento solo había un usuario identificado.
A.2.2 RelacionesEl mejor ejemplo que se encuentra en la base de datos para mostrar las relaciones, es la
clase ”Partida”. Ya que esta contiene, entre otros campos, los usuarios que forman la partidaen el campo ”Jugadores” y el mapa de cada partida.
Como ya se ha comentado, cada partida esta formada por tres jugadores, con lo cual, elcampo ”Jugadores” de la clase ”Partida”, estará formado por una lista de punteros a usuariosde la clase ”User”.
Cuando se realiza una petición para conseguir los datos de una partida, el campo ”Jugado-res” será deuvelto en forma de Array o Lista como se puede observar en el Listado A.2.
[{" __type ":" Pointer "," className ":"_User"," objectId ":" i7fMFLMrSw "},{"__type ":" Pointer "," className ":"_User"," objectId ":"1 AUwXcSOe7 "},{"__type ":" Pointer "," className ":"_User"," objectId ":"8 lshWGgpNE "}]
Listado A.2: Jugadores de una partida en Parse
Una vez obtenido en este caso el contenido de una partida, si se quieren obtener los datosde los jugadores que la forman, se debe hacer una petición más a la clase ”User” usandola clase PFQuery. En el listado A.3, se puede observar como se configura la petición paraobtener la información completa de los jugadores contenidos en una partida.
77
NSMutableArray ⇤ jugadores = [[ partida objectForKey :@" Jugadores "]valueForKey :@" objectId "];PFQuery ⇤query = [ PFQuery queryWithClassName :@"_User"];[query whereKey :@" objectId " containedIn : jugadores ];
Listado A.3: Query de obtención de jugadores contenidos en una partida en Parse
Al igual que la clase ”Partida” contiene una lista de los jugadores que la forman, tambiéncontiene el campo ”Mapa”. Pero este sólo contiene el identificador del mapa de la partida, yaque es una relación directa. En la figura A.5 se observa como se crea una columna del tiporelación con alguna de las clases de la base de datos.
Figura A.5: Creación de columna con relación en Parse
A.2.3 Ventajas e InconvenientesAhora se van a nombrar las ventajas y los inconvenientes que tiene el uso de Parse como
BAAS en la aplicación.
Ventajas:
Interfaz amigable
Rápida configuración
Mucha documentación y comunidad activa
Gratuito hasta cierto volumen de datos, el cual es los suficientemente alto como parano tener que llegar a pagar por el servicio hasta obtener un volumen muy alto de tráfico.
Inconvenientes:
La aplicación tendrá mucha dependencia del servicio, impidiendo escalar si éste cerra-ra o se quisiera cambiar a otros servicios.
Aunque las suscripciones no hacen falta hasta tener mucho volumen de datos, la tarifa”Pro” es muy cara, 199$/mes.
78
Como conclusión, decir que la versión gratuita para el uso de la plataforma ofrece lossiguientes limites de tráfico al mes, los cuales son bastante elevados.
1.000.000 de peticiones API
1.000.000 de notificaciones push
1 Gb de espacio en disco
Un máximo de 20 peticiones por segundo
79
Anexo B
Manual de Usuario
EN el juego Battlex, el objetivo es conquistar todos los territorios enemigos para conse-guir el control de todo el tablero.
Para realizar esto primero se debe realizar el registro del usuario, a continuación la identi-ficación del usuario registrado y con ello ya se entra dentro de la aplicación.
B.1 RegistroPara realizar el registro el usuario debe pulsar cada una de las cajas de texto de la pantalla,
aparecerá un teclado con el cual introducirá los datos solicitados en las mismas. Una vez sehayan introducido los datos, se debe pulsar el botón ”Registrarse”.
Figura B.1: Battlex paso a paso: Registro
81
B.2 IdentificaciónComo en el apartado anterior, se deben rellenar los campos con los datos requeridos. Pul-
sando sobre ellos aparecerá el teclado con el cual se introducen los datos. Una vez introdu-cidos, se debe pulsar el botón ”Identificarse”.
Figura B.2: Battlex paso a paso: Identificación
82
B.3 Menú PartidasEn el menú partidas existen diferentes controles que se explicarán a continuación.
B.3.1 OpcionesPulsando el botón de opciones, situado en la parte superior izquierda de la pantalla, apa-
recerá un menú emergente en el que el usuario podrá cerrar sesión.
Figura B.3: Battlex paso a paso: Opciones
83
B.3.2 Nueva PartidaEn la parte superior derecha de la pantalla, está situado el botón crear partida con el sim-
bolo ”+”. Pulsando sobre él se creará una nueva partida, que se añadirá a la lista de partidasen las que le toca jugar al usuario identificado.
B.3.3 PartidasEn la parte central del mapa aparecen dos tablas. A la izquierda las partidas que le toca
jugar al usuario identificado y a la derecha las del turno rival. Para elegir una partida a jugar,el usuario debe pulsar sobre una de las partidas situadas en la tabla llamada ”Tu Turno”. Unavez elegida una partida, se mostrará el mapa y los controles correspondientes a la fase en laque esté.
Figura B.4: Battlex paso a paso: Partidas
84
B.4 Situar RefuerzosEn la pantalla refuerzos, aparece en la parte superior a modo de leyenda, una tropa del
color del jugador al lado del nombre de éste. También se tiene el botón ”Deshacer” justo allado del número de refuerzos.
Para ordenar a una tropa que se sitúe sobre un territorio, el usuario debe pulsar ese territorioy una tropa se colocará en él. Un refuerzo por cada toque, mientras queden refuerzos porsituar. Si el usuario se equivoca, la opción deshacer devolverá el último refuerzo situadosobre el tablero a la reserva de refuerzos que situar.
Una vez que los refuerzos están situados, aparecerá el botón ”Siguiente” que llevará alusuario a la siguiente fase: El ataque.
En el ejemplo de la figura B.5 se puede observar como se ha ordenado la colocación delos 6 refuerzos en el territorio situado en la primera fila y séptima columna.
Figura B.5: Battlex paso a paso: Situar refuerzos
85
B.5 Configurar AtaquePasos para configurar el ataque deseado:
1. Pulsar sobre el territorio de ataque tantas veces como tropas se quieran usar en elmismo. Se podrán utilizar un máximo de 3 tropas, siempre dejando una tropa defen-diendo el territorio, es decir, si el territorio tiene 3 tropas, se podrán utilizar un máximode 2, sin embargo, si tiene 5, solo se podrán utilizar 3.
Figura B.6: Battlex paso a paso: Configurar Ataque, atacante
2. Pulsar sobre un territorio adyacente al territorio de ataque seleccionado. El territorioseleccionado defenderá con un máximo de 2 tropas. Si sólo tiene 1, defenderá con ella.En caso de perderla, el atacante ganará el territorio.
Figura B.7: Battlex paso a paso: Configurar Ataque, defensor
86
3. Para realizar el ataque, el usuario debe pulsar sobre el botón ”Ataque”, situado en laparte central de los controles superiores.
Figura B.8: Battlex paso a paso: Configurar Ataque, confirmación
4. La puntuación obtenida en los dados (los dados son aleatorios, los genera la aplica-ción) se sitúa debajo de su correspondiente jugador.
La puntuación se interpretan de la siguiente manera:
• Las puntuaciones de cada jugador se ordenan de mayor a menor por separado.
• Se cotejan las puntuaciones una a una después de haberse ordenado. El primerocon el primero, el segundo con el segundo, y así sucesivamente.
• En caso de empate gana el jugador que defiende su territorio.
• En el caso de la figura B.8, el jugador ”Estefanie” ha perdido 6-6 una de sustropas y el jugador ”Minguel553” ha perdido 6-4 otra.
87
B.6 FortificarAl igual que en las fases anteriormente explicadas, en la presente, el usuario deberá pulsar
un territorio de origen para mover sus tropas hacia otro, tantas veces como tropas quieramover. Una vez alcanzado el valor de tropas deseado, con un máximo de n-1 tropas seleccio-nadas, el usuario debe pulsar sobre el territorio de destino de éstas.
Por ejemplo: Si en un territorio se tienen 8 tropas, se podrán seleccionar un máximo de 7para realizar su movimiento.
Una vez el usuario lo desee, puede pulsar sobre el botón siguiente, se guardarán los cam-bios y se volverá a la pantalla de selección de partida.
Figura B.9: Battlex paso a paso: Fortificar
88
Anexo C
Proyectos de Prueba
AL comienzo del trabajo se definieron una serie de requisitos de arquitectura, libreríasy caché. Finalmente se introdujo Parse (Anexo A) y se decidió no utilizar SQLite ni
una base de datos remota alojada en un servidor con MySql.
No obstante, se hicieron diversas pruebas e incluso se introdujo en la propia aplicación deBattlex. A continuación se van a mostrar los ejemplos que se realizaron para estudiar estastecnologías.
C.1 Base de Datos: SQLiteXCode tiene por defecto un framework llamado ”libsqlite3.0.dylib” el cual sirve para leer
o escribir en ficheros con extensión ”sqlite”. Se hizo uso de esta librería para guardar losdatos de la aplicación en una base de datos local del dispositivo con el fin de realizar lasprimeras pruebas.
En la figura C.1 se puede observar que aspecto tenía la base de datos llamada ”BD-Battlex.sqlite”.
Figura C.1: Tablas de Battlex en SQLite
89
A continuación en las figuras C.2 y C.3 se muestran los campos de la tabla ”Partida” y losdatos de un mapa guardados en la tabla ”Mapa” respectivamente.
Figura C.2: Campos de la tabla Partida en SQLite
Figura C.3: Datos de la tabla Mapa en SQLite
Por último se muestra en la figura C.4, como quedaba la capa de servicios cuando seutilizaban las clases DAO en la aplicación.
Figura C.4: Capa de servicios con SQLite integrado
El código correspondiente en la aplicación a la lectura/escritura de la base de datos SQLiteno se muestra en la memoria por su extensión y porque no es relevante, sin embargo seincluirá en el CD adjunto a la presente por si se quiere consultar esta información.
C.2 Prueba de registroAntes de integrar el framework de sqlite en Battlex, se realizó un proyecto de prueba en
XCode en el que se realizaba un registro de usuarios, creando éstos en una base de datosSQLite. A continuación se describirá brevemente los componentes que formaban parte deeste proyecto de prueba.
90
C.2.1 Interfaz de UsuarioPara aprender a usar en Interface Builder de XCode, se realizó una interfaz sencilla que
constaba de varias pantallas con las que se podía interactuar para acceder a las diferentespantallas y rellenar un formulario para finalmente, crear los usuarios de prueba.
En la figura C.5 se puede ver ésta interfaz creada en XCode.
Figura C.5: Interfaz de usuario de prueba
C.2.2 Registro en base de datosComo se ha comentado, la prueba que se hizo fue registrando usuarios, aunque en la
interfaz se muestre la interfaz de la identificación. Al pulsar el botón de registro, después derellenar el formulario, se ejecuta el método que se puede ver en el listado C.1 que abre labase de datos y genera la consulta correspondiente para generar el usuario.
� ( IBAction ) btnregistrar :(id) sender {
AppDelegate ⇤ appDelegate = ( AppDelegate ⇤) [[ UIApplicationsharedApplication ] delegate ];
// Ahora instanciamos la variable database de tipo sqlite3sqlite3 ⇤ database ;
// Creamos el sqlite3_stmt que contendra despues la sentencia aejecutar compilada .
sqlite3_stmt ⇤ sentencia ;
// Abrimos la base de datos de la ruta indicada en el delegateif( sqlite3_open ([ appDelegate . DataBasePath UTF8String ], & database )
== SQLITE_OK ) {
// Si no ha habido errores al abrir , creamos la sentencia deinsercion .
NSString ⇤ sqlStatement = [ NSString stringWithFormat :@" Insertinto Usuarios VALUES (\" %@\", \" %@\", \" %@\")", self.
91
txtcorreo .text , self. txtusuario .text , self. txtcontrasena .text ];
// Lanzamos la consulta y recorremos los resultados si todo haido OK
if( sqlite3_prepare_v2 (database , [ sqlStatement UTF8String ], �1,&sentencia , NULL) == SQLITE_OK ) {
// En otros casos recorremos los resultados . En este casono habra .
while( sqlite3_step ( sentencia ) == SQLITE_ROW ) {}
} else {NSLog(@"Error en la creacion del insert ");
}
// Libero la consultasqlite3_finalize ( sentencia );
}else{NSLog(@"No se ha podido abrir la BD");
}// Cierro la base de datossqlite3_close ( database );
// Si todo ha ido bien podemos abandonar la ventana e ir a lasuperior .
[self. navigationController popViewControllerAnimated :YES ];}
Listado C.1: Generación de usuarios en Sqlite
Todo esto sirvió de toma de contacto para realizar posteriormente la integración de SQLiteen Battlex, aunque como se ha comentado, finalmente se decidió no utilizar este frameworkpara implementar la persistencia de la aplicación.
El resto de este proyecto de prueba se incluirá en el CD adjunto con el presente proyecto,donde podrá ser visualizado.
92
Anexo D
Formulario del Test de Jugabilidad
En este anexo se adjunta el formulario realizado para que una serie de usuarios puedan darsu punto de vista sobre la realización de la aplicación.
93
Test%de%Jugabilidad%de%Battlex%!
Objetivos:%!
• Identificar!el!nivel!de!satisfacción!de!los!atributos!de!la!jugabilidad.!• Medir!la!usabilidad!y!motivación!por!el!juego.!• Identificar!problemas!con!respecto!de!los!dos!objetivos!anteriores.!
Población%!A!partir!de!los!7!años!de!edad.!!
Política%de%privacidad%!El!test!es!completamente!anónimo!y!los!cuestionarios!no!incluirán!información!sobre!la!identidad!de!los!participantes.!!
Metodología%!En!el!presente!test!se!van!a!evaluar!una!serie!de!facetas!de!jugabilidad.!Son!las!siguientes:!!
• Jugabilidad!Intrínseca:!Evalúa!el!diseño!del!juego!y!sus!reglas.!• Jugabilidad!Mecánica:!Evalúa!el!comportamiento!de!la!aplicación!desde!el!
punto!de!vista!del!software.!• Jugabilidad!Interactiva:!Evalúa!la!interacción!con!el!usuario!y!el!diseño!de!
toda!la!interfaz.!• Jugabilidad!Artística:!Evalúa!la!relación!de!la!estética!con!la!naturaleza!
propia!del!juego.!• Jugabilidad!Intrapersonal:!Evalúa!la!percepción!que!tiene!el!usuario!del!
juego!y!que!sensaciones!le!produce.!• Jugabilidad!Interpersonal:!Evalúa!la!competitividad!del!juego.!
!
Instrucciones%!Una!vez!comprendidas!las!facetas!de!la!jugabilidad!a!evaluar,!se!deberán!puntuar!los!atributos!de!cada!faceta!de!la!siguiente!manera:!En!una!escala!del!1!al!5,!siendo!1!Nada!Satisfactorio!y!5!Totalmente!Satisfactorio.!!!!!!!
!!
Faceta! Atributo! Requisitos!a!cumplir! Puntuación!!!Jugabilidad!Intrínseca!
Satisfacción! Valoración!del!Sistema!de!Juego! !Aprendizaje! Reglas!fácil!de!entender! !Efectividad! Intentos!para!conquistar!territorios! !Inmersión! Conquistar!el!mapa! !Motivación! Reconquistar!territorios!perdidos! !Emoción! Ganar!la!partida!conquistando!el!mapa! !Social! Uso!de!compañeros!para!jugar!! !
!!Jugabilidad!Mecánica!
Satisfacción! No!apreciación!de!retrasos!ni!sincronizaciones! !Aprendizaje! Estrategia! !Efectividad! Detecciones!táctiles!de!los!elementos! !Inmersión! Reconocimiento!táctil! !Motivación! Tiempos!de!carga!mínimos! !Emoción! Cambios!de!escena! !Social! Sincronización!de!partidas!por!WiVFi!o!3G! !
!!!Jugabilidad!Interactiva!
Satisfacción! Interacción!táctil! !Aprendizaje! Comprensión!de!los!elementos!visuales! !Efectividad! Correcto!reconocimiento!táctil!de!los!elementos!
pulsados!!
Inmersión! Diferentes!controles!del!mapa!en!cada!fase! !Motivación! Resultados!visuales!de!los!ataques! !Emoción! Efectos!de!cambio!de!escena! !Social! Comunicación!con!otros!jugadores! !
!!Jugabilidad!Artística!
Satisfacción! Diseño!de!la!aplicación! !Aprendizaje! Se!diferencia!cada!territorio!por!su!color! !Efectividad! Es!fácil!reconocer!las!tropas!de!cada!jugador! !Inmersión! Colores!típicos!de!juegos!de!conquista! !Motivación! Retroalimentación!al!pulsar!territorios! !Emoción! Visualización!de!los!cambios! !Social! Se!muestra!la!información!de!las!partidas! !
!!!Jugabilidad!Intrapersonal!
Satisfacción! Se!prefiere!usar!la!aplicación!a!usar!el!juego!de!mesa!
!
Aprendizaje! Se!comprende!el!juego!sin!ayuda!exterior! !Efectividad! Se!avanza!rápido!en!las!partidas! !Inmersión! El!jugador!cree!que!es!el!general!de!las!tropas! !Motivación! El!jugador!está!pendiente!de!los!cambios!en!sus!
partidas!!
Emoción! El!jugador!se!alegra!al!conquistar!territorios! !Social! Incentivar!las!ganas!de!revancha! !
!!Jugabilidad!Interpersonal!
Satisfacción! Gestión!de!recursos!para!las!partidas! !Aprendizaje! Adaptarse!a!los!cambios!de!los!rivales! !Efectividad! Número!de!turnos!para!terminar!la!partida! !Inmersión! Comunicación!y!control!de!las!partidas! !Motivación! Recompensas!por!las!partidas!ganadas! !Emoción! Incentivar!la!rápida!respuesta!de!los!jugadores! !Social! Fomentar!el!cambio!de!estrategia!entre!jugadores! !
Referencias
[Anónimo(2014)] Anónimo. Objective-c. www.wikipedia.org, último acceso en Junio de2014, 2014.
[AppAnnie(2013)] AppAnnie. Index market q2 2013. blog.appannie.com, último acceso enMayo de 2014, 2013.
[Apple(2012)] Apple. Llvm compiler overview. https://developer.apple.com/library/mac,último acceso en Julio de 2014, 2012.
[Apple(2014a)] Apple. ios developer libary. https://developer.apple.com/library/ios/navigation/,último acceso en Julio de 2014, 2014a.
[Apple(2014b)] Apple. ios human interface guideline. developer.apple.com último accesoen Julio de 2014, 2014b.
[Apple(2014c)] Apple. ios dev center. developer.apple.com, último acceso en Julio de 2014,2014c.
[Bandera(2006)] Pedro Fulleda Bandera. Ludología: La indagación del juego por el juego.www.redcreacion.org, último acceso en Abril de 2014, 2006.
[Beck(1999)] Kent Beck. Extreme Programming Explained: Embrace Change. US ed,1999.
[Etermax(2014a)] Etermax. Apalabrados, 2014a. URL www.apalabrados.com.
[Etermax(2014b)] Etermax. Etermax. www.etermax.com, último acceso en Junio de 2014,2014b.
[Inc(2014)] Stack Exchange Inc. Stack overflow. stackoverflow.com, último acceso en Mayode 2014, 2014.
[Languedoc(2012)] Kevin Languedoc. How to become an iphone app creator. HubPa-ges.com, último acceso en Junio de 2014, 2012.
[Letelier(2005)] Patricio Letelier. Metodologías ágiles para el desarrollo de software: Ex-treme programming. 2005.
97
[Mágica(2012)] Manzana Mágica. Desarrollo. http://www.manzanamagica.com/desarrollo/,último acceso en Febrero de 2014, 2012.
[Marques(2013)] Asier Marques. Conceptos sobre apis rest. asiermarques.com, último ac-ceso en Junio de 2014, 2013.
[Mateos(2013)] Manu Mateos. Tecnología push así funciona. www.genbeta.com, últimoacceso en Julio de 2014, 2013.
[Omgpop(2014)] Omgpop. Draw something. http://omgpop.com/drawsomething, últimoacceso en Junio de 2014, 2014.
[Rubio(2013a)] Miguel Díaz Rubio. migueldiazrubio.com. www.migueldiazrubio.com, úl-timo acceso en Julio de 2014, 2013a.
[Rubio(2013b)] Miguel Díaz Rubio. Desarrollo ios: Parse. www.migueldiazrubio.com, últi-mo acceso en Agosto de 2014, 2013b.
[Triviados(2014)] Triviados. ¿qué es triviados? http://triviados.org/triviados/, último accesoen Junio de 2014, 2014.
[Wells(2009)] Don Wells. Extreme programming. www.extremeprograming.org, último ac-ceso en Junio de 2014, 2009.
[y Andreas Löw(2011)] Steffen Itterheim y Andreas Löw. Learn cocos2d Game Develop-ment with iOS 5. Apress, 2011.
[y Andreas Löw(2012)] Steffen Itterheim y Andreas Löw. Learn cocos2d 2. Apress, 2012.
98
Este documento fue editado y tipografiado con LATEXempleando la clase esi-tfg que se puede encontrar en:
https://bitbucket.org/arco group/esi-tfg
[Respeta esta atribución al autor]
99
