Battlex: Juego de estrategia por turnos basado en

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
GRADO EN INGENIERÍA INFORMÁTICA
TECNOLOGÍA ESPECÍFICA DE
TECNOLOGÍAS Y SISTEMAS DE INFORMACIÓN
TRABAJO FIN DE GRADO
Battlex: Juego de estrategia por turnos basado en
comunicació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 DE
TECNOLOGÍAS Y SISTEMAS DE INFORMACIÓN
TRABAJO FIN DE GRADO
Battlex: Juego de estrategia por turnos basado en
comunicació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 GNU
Free Documentation License, Version 1.3 or any later version published by the Free Software
Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy
of 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 la
Licencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada por
la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida en
el apéndice titulado «GNU Free Documentation License».
Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios son
reclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, y
cuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos en
mayúsculas o como nombres propios.
i
TRIBUNAL:
Presidente:
Vocal:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE
Fdo.:
VOCAL
SECRETARIO
Fdo.:
Fdo.:
iii
Resumen
Hoy en día todo el mundo posee un smartphone y gracias a ellos los videojuegos sociales
se están extendiendo cada vez más y más. Las redes sociales o aplicaciones de comunicación
ocupan la mayor parte del tiempo de uso de estos dispositivos, aunque las aplicaciones de
ocio las siguen muy de cerca. Podemos comunicarnos 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 de nuestros conocidos.
Aprovechando esas tecnologías, el presente trabajo pretende crear un videojuego asíncrono para plataforma iOS, heredando la temática de los juegos de estrategia basados en
conquista de territorios. De este modo Battlex podrá ser jugado por todos los usuarios de
iOS para disfrutar de partidas en modo multijugador asíncrono, con otras personas. Entonces
entrará en la categoría de juegos móviles sociales.
V
Abstract
Nowadays everyone has a smartphone, and thanks to them the social games are spreading
more and more. Social networking and communication applications take up most of the
time to use these devices, although the entertainment applications closely follow. We can
communicate directly with social applications through challenges in video games or other
social 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 game
for iOS platform, inheriting themed strategy games based on territorial conquest. In this way
Battlex 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 mi
hermana 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 siempre
conmigo.
A mis amigos y todas las personas que me quieren, porque también han puesto luz en el
camino.
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 ayudarme a hacer un sueño realidad con su apoyo en este trabajo, por su paciencia y el trato
cercano 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 óptimos
para el TFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.2. Analizar, definir y adaptar las reglas del juego a desarrollar asegurando 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
15
3.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
33
4.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
63
5.1. Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
5.2. Aspectos Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.2.1. Adaptación de las reglas originales para crear una aplicación
así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
75
A.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
81
B.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
89
C.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
E
este capítulo se detallará el contexto en el que se ubica el proyecto, el problema que
hay que abordar y cual es la solución propuesta que más adelante se desarrollará.
N
1.1 Contexto del TFG
Este 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 la
ludología.
1.1.1
Contexto de la Computación Móvil
Estamos 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. Las
redes sociales o aplicaciones de comunicación ocupan la mayor parte del tiempo de uso
de estos dispositivos, aunque las aplicaciones de ocio las siguen muy de cerca. Podemos
comunicarnos 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 de
nuestros conocidos.
1.1.2
Contexto de la Computación en la Nube
La 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 o
almacenar esos datos, que gracias a ésta se mantienen centralizados al alcance de todos los
usuarios o consumidores (Figura 1.1). Aunque tiene sus desventajas, compensa y mucho
utilizar este tipo de servicios. Algunas de las ventajas que ofrecen son un bajo coste de
mantenimiento, información en tiempo real y la seguridad, ya que no tienes que preocuparte
por 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-Computador
Busca 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 cabo
se 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 deben 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 motivación determinada, tiene necesariamente unas consecuencias que varían según la calidad y
amplitud 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 en
procesos 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 la
especie, en la conversión del Homo Ludens en Homo Sapiens” [Bandera(2006)].
1.2 Problema y solución propuesta
Ahora 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 problema
Existen varios ejemplos famosos de aplicaciones asíncronas, Apalabrados [Etermax(2014a)],
Draw Something [Omgpop(2014)], etc. Todas ellas utilizan servicios de notificaciones y
computació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 conquista. 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 las
fases clásicas de juegos de mesa como Risk, necesita de una respuesta directa del rival a la
hora de efectuar los ataques.
Risk es uno de los más famosos juegos de mesa basado en conquista de territorios. Compuesto por un tablero de territorios colindantes, se trata de ser el jugador que más territorios
conquiste y en definitiva, de conquistarlo todo.
Las siguientes fases mezclan lo que sería una partida del juego complementado con funcionalidades 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 propuesta
Con 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 en
la aplicación. Este se comunicará con el servicio en la nube para comprobar los credenciales
del 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 que
el turno es del rival.
También podrá crear partidas, las cuales aparecerán en la lista del turno del usuario que la
ha creado. Los rivales se añadirán a la partida creada de forma aleatoria, escogiendo a estos
a 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 aparecerá la pantalla de juego, donde se cargarán los datos cacheados de la partida en cuestión. En
este juego existirán tres fases que compondrán el turno, con lo cual la partida seleccionada
se cargará en la fase en la que el usuario la dejó, si anteriormente ya hubiera jugado alguna
de las fases. Por defecto una partida empieza en la fase de reclutamiento, pero es posible
jugar las fases (excepto la última) sin llegar a pasar el turno. El estado de las partidas se
almacenará en el servidor.
En la pantalla de juego se podrán visualizar los datos de la partida, y en concreto de la fase
actual. La pantalla de juego mostrará un tablero, en el que cada territorio estará identificado
con un hexágono, y el mapa por defecto será un mapa de 60 (12 x 5) hexágonos, característicos en muchos juegos de estrategia por computador. Cada territorio estará compuesto por
una tropa del color del usuario en la partida y un número identificativo para saber el número
de tropas que controlan ese territorio.
Lo anteriormente citado respecto a la pantalla de juego, es de carácter general para todas
las 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 distribuirlas entre los territorios que controla. Se visualizará entonces el número de tropas
ganadas para ese turno.
Ataque: En la segunda fase el jugador podrá atacar desde sus territorios hacia territorios enemigos adyacentes usando un número de tropas menor o igual a tres, siempre
dejando una tropa en la retaguardia. En esta fase se podrá visualizar el número de tropas con las que el usuario desea atacar a otro territorio (el ataque lo componen dos
territorios, 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 visualizará 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 (incluidas
las 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). En
esta 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 siguientes
requisitos:
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 memoria
A 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 problema 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 el
desarrollo 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 relacionados
con 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 diferentes
mé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 han
integrado 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én
un manual de ejemplo de uso del backOffice.
6
Capítulo 2
Objetivos
E
este capítulo se detallan los objetivos generales y específicos del proyecto, así como
las herramientas utilizadas a lo largo del desarrollo del mismo.
N
2.1 Objetivo general
El 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 se
ejecutará bajo la plataforma iOS, integrará librearías gráficas y computación en la nube sobre
la plataforma móvil.
2.2 Objetivos específicos
A 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 manera
de 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és
del usuario.
2. Implementar el juego mediante los lenguajes y tecnologías más apropiados para
alcanzar el objetivo general.
3. Asegurar el correcto funcionamiento y la consecución del objetivo general mediante
pruebas del software generado.
2.3 Objetivos operativos
2.3.1
Analizar y seleccionar los lenguajes y frameworks gráficos óptimos
para el TFG
Se 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 diferentes
tareas, 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 incrementales
para 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 asegurando la jugabilidad del proyecto
Simplificar y/o adaptar las reglas de un juego de estrategia clásico, para que haga uso de
la interacción de un dispositivo móvil con pantalla táctil. Esto implica también adaptar las
reglas para que la jugabilidad se lleve a cabo de manera asíncrona, es decir, que los diferentes
integrantes 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 la
secció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 registro hasta el visor de partidas y el tablero. Las primeras no tendrán mucha complejidad
ya que deberán mostrar una interfaz sencilla para que lo usuarios introduzcan 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 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 aplicaciones
similares, para conocer cómo resuelven diferentes problemas de interacción y saber cómo se
podría enfocar el diseño de la interfaz de usuario, que es uno de los elementos más importantes en proyectos de este tipo. También se hará uso y se tendrá en cuenta las recomendaciones
que 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 para
guardar, obtener o modificar la base de datos allí almacenada. Ésta dispondrá de todos los
elementos 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 cliente
que está suscrito a sus notificaciones [Mateos(2013)]. Se implementará este servicio para que
los 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 el
turno de alguna de las partidas en juego.
8
2.4 Herramientas utilizadas
A continuación se van a detallar las herramientas, tanto software como hardware, utilizadas para completar el proyecto.
2.4.1
Lenguajes de programación y sistema operativo
Para llevar a cabo la aplicación se podría haber hecho uso de herramientas de alto nivel para desarrollar un proyecto multiplataforma, sin embargo, gracias a disponer de las
herramientas necesarias, se pretendía adquirir conocimientos acerca de la tecnología de Apple y desarrollar de manera nativa, con lo que el lenguaje escogido no podía ser otro que
Objective-C [Anónimo(2014)], aunque recientemente ha publicado otro lenguaje con el que
implementar aplicaciones nativas llamado Swift.
Para justificar la elección de este sistema operativo móvil, nos centraremos en diferentes
estudios, mostrando los beneficios que genera una aplicación en iOS y otra en la competencia directa, Android. Ya que a pesar de la expansión de Android en cuanto al número de
dispositivos en el mercado, no se obtienen los mismos beneficios para una misma aplicación
que 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 con
el número de descargas frente al beneficio generado por ambas plataformas. Las gráficas del
estudio 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 en
la App Store (Tienda de aplicaciones de Apple), vemos como las categorías de Juegos (en
las que se enmarca el presente proyecto) y Entretenimiento son las que mayor número de
descargas poseen.
9
Figura 2.2: Descargas por categoría
[AppAnnie(2013)]
Para compilar el código fuente objective-c necesitaremos un compilador, el compilador de
XCode (IDE nativo en OS X) es Apple LLVM. El compilador fue introducido en la version
de 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 Hardware
La 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í como
diferentes versiones del sistema operativo móvil iOS.
El dispositivo con el que más pruebas se han realizado y por tanto para el que estará optimizada la aplicación, es un iPhone 4 (Figura 2.3) (lanzado en 2010) cuyas
caracterí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 (Figura
2.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 Software
Ya se ha comentado el lenguaje de programación que se utilizará para desarrollar la aplicació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 una
serie 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 Framework UIKit.
Media: Esta capa es la encargada de controlar los gráficos, audio, video y el sistema
AirPlay.
Core Services: Servicios como iCloud, Compras dentro de las apps, SQlite, CoreData
y Core Location son controlados gracias a esta capa.
Core OS: La capa de mas bajo nivel, encargada de gestionar el Bluetooth, los accesorios 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 de
Apple. Es un IDE muy completo, que tiene integrado en sí, el Framework Cocoa y Cocoa
Touch del que ya hemos hablado. Dispone de las herramientas necesarias para comenzar el
desarrollo (Compilador, Depurador, Herramientas de gestión, Simulador, Documentación,
etc), aunque para probar la aplicación en dispositivos físicos es necesario enrolarse en el
centro 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 fases
del juego, se realizó un estudio previo de las posibilidades de las librerías más comúnmente
usadas en el desarrollo de videojuegos de bajo presupuesto para iOS. En su mayoría son
librerías gráficas para realizar juegos en 2D aunque tienen ciertas herramientas para el desarrollo 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 cuenta
en el estudio previo:
Game Engine
Lenguaje
Multiplataforma
Coste Publicación
Cocos2D
C++,
Python,
Objective-C
o
JavaScript
LUA
Mono, UnityScript,
C# o Boo
Si
Gratis
Si
Si
16 hasta 200 $
3000 $
Corona SDK
Unity
Cuadro 2.1: Comparativa sobre frameworks gráficos para iOS
Como se ha comentado anteriormente, la idea del proyecto también era aprender el lenguaje de programación para implementar aplicaciones nativas para plataforma iOS, con lo
cual el lenguaje elegido entre los que se han comparado ha sido Cocos2D. Entre otras opciones se ha decantado por usar este framework ya que se integra con XCode, el coste para
publicar una aplicación basada en él es gratuito y la gran comunidad de desarrolladores que
lo usan.
Esta aplicación no necesita mucha potencia, además solo se utilizarán gráficos en 2D, con
lo 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 BAA S que nos permitirá utilizar múltiples servicios de manera gratuita (aunque con límites), basados en la nube. Sus principales características son las
siguientes [Rubio(2013b)]:
Modelo de datos en la nube: creación de tablas no-SQL en la nube y capacidades
para 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 la
realización de validaciones de seguridad, o procesos automáticos por cambios en los
datos.
Esta plataforma provee a los desarrolladores de un SDK, disponible para múltiples plataformas, 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 el
director 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 elaborar la memoria.
Vista Previa: Herramienta nativa para visualizar y editar documentos y gráficos en OS
X.
BitBucket: Servicio de alojamiento web basado en Git, en el cuál se almacenará el
proyecto para control de versiones.
14
Capítulo 3
Estado del arte
E
N 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 Estrategia
Los 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 para
conseguir 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ás
complejos, por ejemplo en el trabajo se mezclan los conceptos de tablero y dados, con la
tá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
Poker
Existen varias modalidades, aunque la más famosa actualmente es la llamada Texas HoldEm. Consta de una baraja de 52 cartas, dividida en 4 palos. La primera fase es llamada
Preflop, en la que cada jugador recibe 2 cartas para comenzar las apuestas. Luego le siguen
las fases de Flop, el repartidor levanta 3 cartas encima de la mesa, Turn, se levanta una carta
más, y River, donde se levanta la última carta. Cada una de ellas con sus correspondientes
apuestas. Para determinar el ganador existe un orden de 10 tipos de combinaciones (Figura
3.1) , gana el jugador que consiga la mejor mano de 5 cartas, entre las que posee y las de la
mesa.
3.1.2
Poker de dados
Bá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 la
mejor jugada. La manera de determinar el ganador es similar al de las combinaciones de la
figura 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
Risk
Juego 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 y
diferentes versiones del juego original, pero se va a explicar el funcionamiento básico de
una partida. Pueden jugar de 2 a 6 jugadores, el tablero está compuesto por 42 territorios
agrupados en 6 continentes, se juega con 3 dados de ataque, 2 de defensa y 56 cartas. La
finalidad es conquistar todos los territorios. Cada turno está compuesto por tres fases que se
describen a continuación:
Refuerzos: Consiste en obtener nuevas tropas según el número de territorios que se
controlen y ubicarlos en ellos en cualquier orden
Ataque: El ataque se ejecuta de manera que el atacante puede atacar con un máximo de
3 tropas a un territorio enemigo adyacente, siempre dejando como mínimo una tropa
en 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 el
ataque, ganando el atacante en caso de superar el valor del dado defensor. En caso de
empate gana siempre el defensor.
Fortificación: En la última fase se podrá mover tropas de un territorio controlado a otro
adyacente, 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íncronas
Ahora 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, con
o sin modificaciones, de juegos de mesa, dados, etc, como se han descrito en ejemplos del
punto anterior.
3.2.1
Apalabrados
Basado 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 aprovechar
las palabras ya formadas en el tablero. Se obtienen puntos según el número de letras de la
palabra formada y su situación en el tablero. La finalidad del juego consistía en terminar con
la mayor puntuación. Apalabrados hereda muchas de éstas y otras reglas de juego, agregando
el componente social y las partidas con gente a distancia, sin la necesidad de jugar al mismo
tiempo.
Una vez identificado en la aplicación a través de tu correo electrónico o tu cuenta de
Facebook, podrás ver una lista de partidas en juego, crear una nueva (eligiendo oponente, el
idioma 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 de
usuario, 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 idioma
concreto.
Logros: Se podrá visualizar la mayor puntuación conseguida en un juego completo, la
de la mejor jugada y la palabra mas larga formada.
Desempeño: Se visualizan, el número de partidas ganadas, perdidas, y el porcentaje de
partidas 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 de
los enfrentamientos que se hayan tenido con él. Además se puede solicitar amistad en
Facebook 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 del
Scrabble, repartiéndose fichas entre ambos oponentes, formando palabras sobre el tablero
respetando las reglas y cuya finalidad es conseguir el mayor número de puntos. Para conseguir esto también se juega con la puntuación de cada ficha (no todas valen lo mismo) y
con las casillas “especiales” del tablero (figura 3.4): Las casillas están denominadas por dos
letras, DL o doble letra, TL o triple letra, DP o doble palabra y TP o triple palabra. Al formar
una palabra colocando las fichas sobre estas casillas se le proporciona al jugador puntos extra
según el significado de cada casilla.
En la parte inferior de la pantalla se muestran una serie de opciones que hacer con las
fichas o la jugada, como pasar turno, cambiar fichas, mezclar las fichas actuales, rendirse
y cuando se ha formado una palabra válida pasar se convierte en jugar para confirmar la
jugada.
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): Lista
de 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 tu
turno en primer lugar y debajo las que el turno es del rival. Por cada partida se muestran los
datos del rival, la última palabra formada y hace cuanto tiempo fue formada, el idioma de la
partida, hace cuanto fue creada y las fichas restantes.
En la captura de la Partida terminada se muestra un mensaje para el usuario que ha
ganado o perdido y dá la posibilidad de compartir en las redes sociales el resultado de la
partida.
En la captura referente al chat del juego se muestra un chat que ofrece la posibilidad de
conversar con el usuario rival en cada partida.
Figura 3.5: Apalabrados, redes sociales (imagen obtenida de http://applicantes.com)
19
3.2.2
Mezcladitos
El 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 famosos, 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 a
continuación.
En la pantalla principal (figura 3.6) nada más abrir la aplicación se pide introducir los
datos para la identificación. Si se posee cuenta de usuario de apalabrados se podrá usar en
esta app ya que ésta lo permite al estar creada por la misma compañía (Etermax), por lo tanto
se 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, de
dos minutos de duración cada uno. Por supuesto para hacerlo se dispone de un tablero de
4x4 con un total de 16 letras para juntar palabras (figura 3.7), ya sea en horizontal, vertical u
horizontal. Además algunas letras tienen bonificación de multiplicación, que sigue la misma
forma que la aplicación anterior (DL, TL, DP y TP). Ganará el jugador que mas puntos
consiga 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 la
balanza en su favor. Al registrarte se obtienen 50 monedas del juego con las que se pueden comprar comodines. Las monedas se pueden comprar (compras in-app desde 0,89, 1,79
euros...) 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 anterior
app, 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 la
publicidad en el caso de las aplicaciones gratuitas y del coste de las aplicaciones que eliminan
la 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 aparece
un banner publicitario y también publicidad a pantalla completa cada vez que hacemos una
jugada.
3.2.3
Preguntados
Del 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 juegos
de preguntas y respuestas de varios campos, en concreto el juego de este tipo más famoso es
Trivial Pursuit.
Como otros ejemplos, esta adaptación tiene sus matices, sobre todo uno de ellos es el de
hacer que los propios jugadores propongan preguntas para el juego, que a través de unas
votaciones se valorarán. Esto hace el juego mucho más dinámico, divertido, social y adictivo.
La mecánica del juego es muy similar al ya comentado anteriormente Trivial, pero en este
caso no se utiliza un tablero con un dado para avanzar de casilla en casilla intentando conseguir los ”quesitos”. En su lugar los quesitos se sustituyen por personajes y el tablero por
una 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 contesta correctamente las preguntas, pero también podrá retar a los rivales si le sale la casilla
de 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, ya
que por defecto son tres y también se pueden comprar más ”vidas”, aunque se pueden obtener
con el transcurso de la partida. En Preguntados ganará el jugador que primero obtenga todos
los personajes.
El juego como los ejemplos anteriores, permite identificarse con cuentas de Facebook o
usuario y contraseña. Además también tiene todos los aspectos sociales, compartir resultados
via Twitter y Facebook, chat de juego, etc. Por supuesto es un juego asíncrono, las partidas
pueden estar ahí durante días, solo cuando el usuario podrá contestar sin límite mas halla de
los 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 el
que más se aleja de la mera adaptación del juego en el que está basado. La finalidad es la
misma, pero la dinámica de juego es diferente para adaptarla a los dispositivos móviles.
3.2.4
Triviados o Atríviate
Al igual que el ejemplo anterior (subsección 3.2.3), Triviados es una adaptación del famoso juego Trivial Pursuit. Pero en este caso de una manera mas fiel, pues antes se comentaba
que la manera de elegir las preguntas era a través de una ruleta, sin embargo en Triviados se
hace 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 disponible 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 se
van actualizando periódicamente para que los jugadores nunca lleguen a conocer todas las
preguntas 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 las
distintas casillas del tablero y contestando las preguntas de la categoría de la casilla en la
que caigamos hasta conseguir las 7 estrellas (una correspondiente a cada categoría) que se
encuentran repartidas por el tablero. Así el ganador de Triviados será el primer jugador que
logre obtener las 7 estrellas antes que sus oponentes ([Triviados(2014)]).
3.2.5
Enumerados
Enumerados 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 este
caso no se trata de formar palabras, sino de formar operaciones matemáticas básicas usando
fichas 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 utilizadas 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 tablero
previamente (Figura 3.14) y también se pueden continuar las fórmulas como se muestra en
la 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 todos 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 ha
comentado.
Como ocurre en diversos juegos y en algunos de los ejemplos citados anteriormente, existen multiplicadores en el tablero de juego, al colocar una ficha que forme la fórmula en la
casilla 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 utilizar
en una jugada todas las fichas que se tienen en la mano del jugador. Otro mas es el de suamr
30 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, como
la de los bonus de juego. Existen varias maneras de conseguir bonus, esperar que se recargue
la barra de bonus, la cual aumenta en cada turno, aunque aumentará mas rápido si se usa en
una 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 comprado
se podrá usar una vez por partida, aunque siempre se podrá usar un bonus aleatorio cuando
se 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 pantalla
principal 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
Temporis
Temporis 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íneas
temporales correctas de eventos de varias categorías.
La aplicación permite identificarse a través de las redes sociales, FaceBook y Twitter o con
correo 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 y
acciones que se pueden hacer en la lista de partidas (Crear una nueva partida o actualizar la
lista), 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 las
partidas jugadas, además de un desglose de las categorías en las que mejor hemos puntuado.
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ías
para los eventos de la línea temporal o crear una partida en la categoría es aleatoria. Las
categorí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 jugadores
y con categoría aleatoria. La finalidad del juego es conseguir ordenar correctamente la mayor
parte de los eventos que van apareciendo. Aunque la partida consta de 4 jugadores, Temporis
permite 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 el
turno, podrá mover eventos en la línea temporal mientras no cometa ningún error, en cuyo
caso se pasará el turno al siguiente, el cual podrá contestar cuando quiera a la partida. En temporis gana el jugador que consigue colocar el mayor numero de eventos de la línea temporal
correctamente. también permite compartir estadísticas a través de las redes sociales.
3.3 Conclusiones
En 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 mejoras
futuras.
3.3.1
Integradas
Organización de partidas: La primera similitud con estas aplicaciones que se puede
observar en Battlex es la manera en que un usuario ver sus partidas y elige una de ellas
para entrar a jugar. En los ejemplos descritos anteriormente se puede observar como se
muestran en forma de tabla, diferenciando las partidas en las que se tiene el turno y las
que el turno lo posee el rival. También la información que se muestra de cada partida
ha servido de inspiración para mostrar los datos más relevantes de cada partida. Se ha
considerado 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 se
pueden crear nuevas partidas, aunque éstas se pueden personalizar en los ejemplos, en
Battlex 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 del
rival, en el caso de Triviados (sección 3.2.4) se puede diferenciar por colores donde
está 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 del
jugador, el usuario identificará cual es el color de sus tropas.
Controles: Los controles sobre los tableros en los ejemplos aparecen en la parte inferior
de la pantalla, ya que en todos los casos el dispositivo está en posición vertical y es
más cómodo usar el dispositivo con los dedos pulgares de cada mano. En el caso de
Battlex el dispositivo siempre estará en posición horizontal, con lo cual los controles
sobre el tablero estarán alíneados a los bordes laterales de la pantalla y serán accesibles
por 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 hora
de mostrar los tableros. Éstas lo muestran completo para que se pueda observar en
toda la pantalla, aunque algunas permiten hacer zoom. En Battlex el tablero se muestra
completo en toda la pantalla, aunque no permite zoom.
Notificaciones: Todos los ejemplos anteriores hacen uso de notificaciones para manterner informados a los usuarios del progreso de las partidas en juego. En Battlex se
hace uso también de esta funcionalidad para que los usuarios sepan cuando les toca el
turno en alguna de las partidas que tienen en juego.
3.3.2
No integradas
A 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 porque
alguna de ellas hubiera sido complicada de implementar.
Sistema de logros: No se ha citado mucho en los ejemplos anteriores, pero están integrados con sistemas de logros de las diferentes plataformas para las que están disponibles. Sería intersante integrar en Battlex un sistema de logros que ofrecieran recompensas 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 a
través de sus cuentas en redes sociales, lo que aporta un valor añadido para ellas ya
que puede darse a conocer la aplicación a través de éstas redes, publicando anuncios
si el usuario lo permite en los tablones de éstas. Integrar estos modos de identificación
darí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 la
bú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 usuarios, 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 que
los 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 toda
la información de los chats.
Compras dentro de la aplicación: Algunas de las aplicaciones citadas anteriormente
ofrecen compras dentro de ellas. Se pueden comprar ayudas para tener ventajas a la
hora de jugar las partidas. La posibilidad de integrar también el sistema de cartas del
juego Risk original, podría ser una de esas ayudas que ofrecer al usuario. Canjeando
estas cartas, los jugadores podrían obtener más tropas a la hora de reclutarlas en la
primera fase de cada turno.
Multiplataforma: Aunque el presente proyecto se basa en una aplicación para plataforma iOS, casi todas las aplicaciones citadas están disponibles en las distinas tiendas de
aplicaciones móviles y también en las redes sociales, es otra de las ventajas que podría
ofrecer Battlex para alcanzar más cuota de usuarios.
3.3.3
Conclusiones
Todas 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 la
aplicación durante el mayor tiempo posible e incentivar el que unos usuarios rivalicen con
otros para fomentar el juego.
31
Capítulo 4
Método de Trabajo
D
de haber realizado un estudio de tecnologías hardware, software y haber sondeado 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.
ESPUÉS
4.1 Metodología de Desarrollo
Para 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 (Programació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 las
metodologías tradicionales en que el foco está en la adaptabilidad y menos en la previsibilidad.
4.1.1
Programación Extrema
La 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 y
un buen ambiente de trabajo. A continuación se detallarán los valores de los que se compone
XP:
Simplicidad: Para alcanzar la simplicidad se implementará la tarea asignada o estimada, 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 documentación, se debe realizar el código de manera que sea fácilmente interpretable por el
resto del equipo.
Comunicación: Como se comentaba, el código debe ser lo más inteligible posible
para que la comunicación y el conocimiento sobre el proyecto fluyan a través de todos
los integrantes del equipo. La mejor manera de documentar el código es eligiendo bien
el nombre de variables, métodos, clases y carpetas o grupos, porque los comentarios
pueden quedar obsoletos si los miembros del equipo se centran en mejorar el código y
se 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 descubre
en fases tempranas, donde no se cumplen los requisitos gracias a la observación del
cliente. 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 mismo
previamente hizo. Sin importar el esfuerzo que conllevó hacerlo o que llevará cambiarlo, 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 y
adoptar las medidas oportunas de cara a la refactorización para conseguir una mejor
calidad del producto.
Figura 4.1: Valores de XP (imagen obtenida de http://pmoinformatica.com)
4.1.2
Historias de Usuario
Se 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ás
especí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 se
deben detallar con enunciado y descripción, otras solo con la descripción y que deben tener
una estimación de esfuerzo en días.
1
El 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 se
detallan fecha, tipo de actividad (nueva, corrección, mejora), prueba funcional, número de
historia, prioridad técnica y del cliente, referencia a otra historia previa, riesgo, estimación
técnica, descripción, notas y una lista de seguimiento con la fecha, estado cosas por terminar
y comentarios [Letelier(2005)].
Siguiendo los valores de XP, se llevará a cabo el presente proyecto. El proyecto lo conforman dos personas, director y alumno, el director asumirá el papel de cliente y el alumno
será el equipo de desarrollo. Se detallarán las historias de usuario conjuntamente por los dos
miembros, se llevará acabo el desarrollo y se presentará al final de cada iteración una versión
funcional cliente, el cual podrá proponer cambios, nuevos requisitos, mejoras, etc.
Una vez satisfecho el cliente con el producto final, se realizará la documentación, detallando todas las iteraciones y sus características y se realizará el manual de usuario de la
aplicación.
4.2 Desarrollo del proyecto
A 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 recomendaciones a tener en cuenta a través de la retroalimentación del cliente, hay que definir
unos estilos, unas reglas del juego (adaptadas de juegos de guerra basados en conquista de
territorios y otras aplicaciones asíncronas) y la arquitectura del sistema. A continuación se
definirán las decisiones que se han ido tomando durante el desarrollo en cuanto a estilo o
diseño, reglas del juego y arquitectura del sistema, y como quedará todo una vez terminado
el desarrollo.
4.2.1
Diseño de la Interfaz de Usuario
Aunque 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 seguir
unos diseños más actuales y mejorar la experiencia de usuario.
Al comienzo del presente proyecto los dispositivos móviles como Android, iOS, etc, tenían unas interfaces nativas más basadas en el skeumorph (Skeumorfismo), que viene del
griego skeuos (herramienta) y morphe (forma) y se refiere a una propiedad de un objeto evolucionado (o derivado) que mantiene detalles del diseño del objeto original con el objetivo
de hacerlo más familiar para su usuario.
No se ha abandonado radicalmente este estilo pero ahora se siguen una serie de recomendaciones de guía de estilo para interfaces de usuario como las que Apple publicó el verano
de 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 en
los 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 el
contenido, pero no compite con él.
Claridad: El texto es legible en todos los tamaños, los iconos precisos y los adornos
son 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 experiencia de usuario.
Un ejemplo del cambio que supone la interfaz de usuario en iOS 7 con respecto de las
anteriores 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 de
iOS:
Estilo de la barra
Apariencia
Tinte
Botón atrás
iOS 7
iOS 6
Translúcida clara (por defecto) o translúcida oscura
Linea de un píxel en el borde inferior
tintColor para personalizar los botones,
barTintColor para personalizar el fondo
El botón atrás es un botón hecho con el
título de la pantalla previa
Opaco con degradado azul (por defecto)
u opaco negro
Sombra en el borde inferior
tintColor para personalizar la barra
El botón atrás es un botón con borde que
contiene 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 se
explicarán mas adelante.
36
Escenas de Juego
Registro: Tiene un diseño sobrio y sencillo, sin distracciones, solamente los campos
necesarios para la información requerida (nombre de usuario, contraseña e e-mail) junto 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 usuario y contraseña para poder identificarse y los botones para confirmar la identificación
y otro para ir a la escena de registro.
Menú de partidas: La siguiente pantalla ya es algo más compleja que las anteriores
como 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 parte
derecha el botón de crear nueva partida, como se puede observar ambos controles están
realizados 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 debajo
separadas en dos tablas, aparecen las listas de partidas que tiene el usuario en juego, a
la izquierda las partidas en las que tiene el turno, a la derecha en las que el turno es de
alguno de los rivales.
Refuerzos: En esta escena se muestran los controles asociados a los refuerzos, estos
son: Tropa de ejemplo y el número de las tropas de refuerzos restantes por colocar en el
tablero, las cuales podrán ser colocadas en los territorios que se tengan bajo control. El
botón para acceder a la siguiente fase se activa al colocar todas las tropas de refuerzo
y en caso de ser pulsado se guarda el progreso de refuerzos y de fase. También se
muestra 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 tienen
un 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 un
borde 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: La
primera es porque es un número redondo (60 territorios) para dividir los territorios
entre tres jugadores. La segunda es porque con el ancho de pantalla de menor ancho
en modo apaisado, 480 puntos, siguiendo la recomendación de que los elementos con
interacción no sean menores de 44x44 puntos (mismos pixels en no-retina y 88x88 en
retina) 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 tropas
junto con el número de tropas en cada territorio, los cuales están representados en
forma de hexágono. El motivo de la elección de este polígono para representar los
territorios es porque está basado en los juegos de estrategia por turnos clásicos, es un
recurso muy utilizado en juegos de guerra y además puede permitir en el futuro generar
mapas aleatorios o personalizados por el usuario de una manera sencilla. Lo que sería
mucho 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 describirá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 seleccionar
un territorio bajo control, este se resalta añadiendo un tono de oscuridad a la tropa
y se muestra el número de tropas al lado de la figura, encima de las tropas que hay
en ese territorio. 4.5. A continuación con el ataque seleccionado se pulsa sobre
un territorio enemigo adyacente al anterior.
• Confirmar ataque: Se debe pulsar el botón situado en la parte central justo encima 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 se
muestran los resultados y se quedan resaltados los territorios involucrados para
que el usuario sepa donde se ha realizado la acción.
Fortificar: Simplemente se selecciona el territorio desde el que se quieren mover tropas, el cual se resaltará y se mostrará el número de tropas a desplazar, y a continuación
se 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ón
Estará 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 de
Apple. El lenguaje para todos los módulos de la aplicación será el ya comentado
Objective-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 de
las 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 usando
mapas (CCTMXTiledMap), y las tropas de los jugadores (CCSprites).
Escenas de Juego: Como se ha comentado, el framework ofrece un director de escenas
que 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 de
transiciónes que ofrece el framework, como se puede ver en el listado 4.2 o se vuelve
a la escena anterior como en el listado 4.3.
CCTransitionFlipY ⇤ tran = [ CC Transi tionFl ipY
t r a n s i t i o n W i t h D u r a t i o n :0.5
scene :[ 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 nivel
visual muestran un formulario muy similar y básicamente se comunican con la capa
de servicios usando el modelo de datos para realizar las acciones pertinentes, registrar
nuevos usuarios e identificar usuarios respectivamente.
Como ejemplo en la figura 4.8, se puede observar el flujo de las llamadas entre las
diferentes capas para realizar un login con éxito y hacer una transición a la escena de
Partidas. El usuario se identifica en la ”Escena Login” llamando al servicio con sus
credenciales, el servicio responde con éxito (success) entonces ésta escena llama al
método scene de .Escena Partidas"la cual devuelve una instancia de si misma y entonces
la escena de login llama al CCDirector para realizar que realice la transición entre las
escenas.
Figura 4.8: Flujo de datos: Login con éxito
Escena Partidas: Esta escena muestra la tabla que contiene las partidas en juego del
usuario previamente identificado cuya configuración se muestra en el listado 4.4.
41
(void) o n E n t e r T r a n s i t i o n D i d F i n i s h
{
self . winSize = [[ CCDirector sharedDirector ] winSize ];
CCLabelTTF ⇤ tableTitle = [[ CCLabelTTF alloc ] initWithString : @ " Mi turno
" dimensions : CGSizeMake ( self . winSize . width ⇤ 0.85 / 2 , 20)
hAlignment : k C C T e x t A l i g n m e n t C e n ter vAlignment :
k C C V e r t i c a l T e x t A l i g n m e n t C e n t e r 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 :
UIT able Vi e w S t y l e P l a i n ];
[ self . tableView setS eparat orInse t : 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 y
otra en la que se muestran las que le toca jugar a alguno de los rivales. Cada una de
ellas está en una clase diferente y se añaden a la escena como se puede ver en el listado
4.5.
Para que las tablas muestren las partidas es necesario llamar al servicio para obtener
las partidas del usuario. El flujo de llamadas se puede ver en la figura 4.9. Cuando
se carga la escena de partidas, ésta llama al servicio para obtener los datos de las
partidas del jugador identificado. A continuación el servicio devuelve un diccionario
con las partidas, entonces la escena llama al modelo de datos para que traduzca esos
diccionarios 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 realizar
cuando el usuario escoge una partida en la que le toca jugar en el listado 4.6.
}
(void) tableView :( UITableView ⇤) tableView d i d S e l e c t R o w A t I n d e x P a t h :(
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
t r a n s i t i o n W i t h D u r a t i o n :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, se
muestra en la figura 4.10 el flujo de datos que hace la presente escena a la hora de
generar 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 diccionario
para 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 muy
similares ya que todas comparten la capa del tablero y como ya se ha comentado la
diferencia entre ellas son los controles. Lo primero es crear el tablero y añadirlo a la
escena, 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 t i le d M ap W i th T M XF i l e : 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 como
se 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 p o i n t L o c a t i o n F r o m T i l e : CGPointMake
(j , i ) ];
position . x = 4;
[ tropa . sprite setPosition : position ];
[ self addChild : tropa . sprite z :2];
tropa . nTropas = (( Casilla ⇤) [ self . partida . mapa
casillaWithCoor : j andCoorY : i ]) . nTropas ;
tropa . o b j ec t IdP r o pi e t ar i o = (( Casilla ⇤) [ self . partida . mapa
casillaWithCoor : j andCoorY : i ]) . ob j e ct I d Pr o p ie t a ri o ;
tropa . nTropasLabel = [[ CCLabelTTF alloc ] initWithString
:[ NSString stringWithFormat : @ " %@ " , @ ( tropa . nTropas ) ]
dimensions : CGSizeMake (16 , 12) hAlignment :
k C C T e x t A l i g n m e n t C e n t e r vAlignment :
k C C V e r t i c a l T e x t A l i g n m e n t C e n t e r 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 . sprite
boundingBox ]. size . height / 2) + 6) ];
[ self addChild : tropa . nTropasLabel z :2];
tropa . tropasUsarLabel = [[ CCLabelTTF alloc ] initWithString
: @ " " dimensions : CGSizeMake (16 , 12) hAlignment :
k C C T e x t A l i g n m e n t C e n t e r vAlignment :
k C C V e r t i c a l T e x t A l i g n m e n t C e n t e r 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 configuraciones 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 de
elementos (CCMenuItem) los cuales son: Botón para volver a la escena de las
partidas, una tropa como leyenda para que el jugador sepa cual es su color, una
etiqueta con el número de tropas de refuerzo que se pueden colocar en el mapa y
un botón para pasar a la escena de ataque.
En esta escena se detecta cuando el usuario toca un territorio del tablero y si es
controlado 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, hay
elementos similares como el botón para volver a la escena de partidas y el botón
para 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 abreviatura ”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 jugador
cuando se pulse el botón ”Ataque” situado debajo de la abreviatura anteriormente
citada.
Todas las escenas de juego actualizan adecuadamente los datos en el servidor
cuando los jugadores terminan cada fase, pero en el caso del ataque, se guarda
cada ver que uno de éstos se realiza, ya que no hay vuelta atrás cuando se ha
realizado uno. En la figura 4.11 se puede observar el flujo de datos para llevar a
cabo 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 del
jugador en una etiqueta centrada en la parte superior.
Aquí se resalta el territorio desde el que se quieren mover tropas, aparece una
etiqueta 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 resaltado
y la etiqueta.
Modelo de datos: Se utiliza esta capa para hacer más fácil la tarea del manejo de
datos, ya que la capa de servicios devuelve diccionarios, éstos son traducidos a objetos
de éste modelo de datos. Son utilizados por las escenas para configurarse y tratar la
información que contienen. Un ejemplo de modelos de datos utilizados puede verse a
continuación en el listado 4.9.
46
@interface Partida : NSObject
@property
@property
@property
@property
@property
@property
@property
( nonatomic ,
( nonatomic ,
( nonatomic )
( nonatomic ,
( nonatomic )
( nonatomic )
( nonatomic )
strong ) NSString ⇤ objectId ;
strong ) Mapa ⇤ mapa ;
NSInteger fase ;
strong ) JugadorColorList ⇤ jugadorColorList ;
NSInteger TurnoIndex ;
NSInteger LeaderIndex ;
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) reemp lazarC asilla :( 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 por
Parse. Para ello se sirve de dos clases principales PFUser y PFObject que básicamente
son diccionarios que asocian elementos con claves. Tienen una funcionalidad muy
extensa y aunque se utilizan más elementos, por su extensión no serán nombrados en
este apartado.
Como ejemplo, se han mostrado figuras en algunas de las escenas anteriores para que
se pudiera observar el flujo de datos que se realizan cuando se hace uso de la capa de
servicios 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 de
creación de nuevos usuarios.
PFUser ⇤ newUser = [ PFUser user ];
[ newUser setUsername : self . userName . text ];
[ newUser setPassword : self . password . text ];
[ newUser setEmail : self . email . text ];
[ newUser s i g n U p I n B a c k g r o u n d W i t h B l o c k :^( 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 datos
almacenada 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 ejemplo
cuando 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 la
aplicación (listado 4.11).
PFQuery ⇤ query = [ PFQuery queryWi thC la ss Na me : @ " Partida " ];
[ query whereKey : @ " Jugadores " equalTo :[ PFUser currentUser ]];
[ query f i n d O b j e c t s I n B a c k g r o u n d W i t h B l o c k :^( 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, la
manera de guardar esos cambios en la base de datos se puede ver en el listado 4.12.
PFObject ⇤ casillaObject = [ PFObject o b j ec t W it h C l as s N am e : @ " 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 s a v e I n B a c k g r o u n d W i t h B l o c k :^( 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 de
la aplicación, éste se puede ver en el CD adjunto donde se encuentra todo el código fuente y
los recursos utilizados para la implementación de Battlex.
4.3 Evolución del proyecto
En 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 Anteproyecto
Reunidos de una parte el director del presente proyecto y el alumno, se definieron los requisitos 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 sin
haber encontrado un proyecto igual, se pasó a redactar el Anteproyecto presentado.
4.3.2
2a Etapa: Estudio previo
fue necesario adquirir conocimientos sobre la plataforma iOS, el lenguaje de programació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 esta
etapa, ya que no sólo no se tenían conocimientos sobre la plataforma, sino que tampoco se
había tomado contacto previo con ninguna librería de gráficos.
Para adquirir los conocimientos necesarios, han sido de gran ayuda varios libros y sobre
todo los blogs sobre la plataforma. A continuación se van a citar algunas de las fuentes
usadas, que más importancia han tenido durante el estudio y el desarrollo.
Para realizar los primeros ejemplos e investigar sobre el framework gráfico escogido 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 videojuegos
con 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 base 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 desarrollo ha sido Stack Overflow ([Inc(2014)]), indiferentemente de la tecnología en esta
comunidad se ha buscado respuesta a las numerosas dificultades encontradas.
4.3.3
3a Etapa: Implementación
Después de la segunda etapa, habiendo adquirido conocimientos básicos sobre como llevar a cabo el proyecto y siguiendo la metodología anteriormente explicada, eXtreme Programming, se llevaron a cabo una serie de iteraciones. Éstas se definieron de manera que
se marcaban hitos, para de un modo incremental, completar un prototipo funcional de la
aplicación.
1a Iteración: Diseño del tablero de juego: En esta etapa se configuraron las herramientas necesarias para crear un ejemplo de proyecto de cocos2d. Este venía con una
escena de ejemplo, sobre la que se comenzaron a crear los primeros diseños del tablero y a tomar contacto con el framework gráfico. También se implementaron los gestos
para calcular los territorios que se pulsaban por el usuario y se pusieron sprites como
ejemplo 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ía
obtener la información de los territorios pulsados. El proyecto podía ser compilado y
probado en dispositivos reales o el simulador de iOS. Éste mostraba una pantalla de
inicio de ejemplo donde estaba dibujado el logo de cocos2d y a continuación cuando
cargaba 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 habí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 iteració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 las
escenas 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 ataques entre territorios y migrar tropas de unos a otros. Pero no permitía jugar una partida
real ya que no se tenía gestión de los usuarios. Fue la iteración más larga y en la que
se aprendio más sobre el framework y sus diferentes clases, como CCDirector para la
transición entre escenas y CCMenu y CCMenuItem para la creación de los menús de
controles de cada escena.
3a Iteración: Controles: En esta etapa se definió la experiencia de usuario de cada
escena.
Para la escena de fortificar se definió la interacción de como colocar los refuerzos sobre
el 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ía
el botón para pasar a la siguiente fase. También se podían deshacer los cambios para
comenzar de nuevo a colocar los refuerzos.
50
En la escena de ataque, éste estaba definido de manera que se seleccionaba el territorio
origen y con un contro de + y -, se aumentaban las tropas con las que efectuar el ataque
y, a continuación, se seleccionaba el objetivo. Por último se pulsaba el botón de ataque
para realizarlo. Pero la selección del número de atacantes fue mejorada, pues lo que
se decidio fue que se mostraba el número de tropas elegidas al lado de la tropa en el
territorio y, cada vez que se pulsase, éste número aumentaría hasta alcanzar el valor
deseado.
Por último la escena de fortificar es muy similar a la elección del atacante en la anterior. Se pulsa el territorio tantas veces como para alcanzar el valor de tropas a mover
deseado 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 intentó alcanzar la mejor experiencia posible para la comodidad del usuario. El resultado
fue 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 el
SDK de Parse para iOS, que permitía la comunicación con un servidor en la nube, para
implementar la lógica de registro e identificación, además de toda la persistencia de
los 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 comunicarse con éste desde la aplicación. Después de integrar el SDK y configurar las claves
en la clase principal de la aplicación, se comenzaron a hacer pruebas de registro e
identificación.
En esta iteración también se crearon los formularios de las escenas de registro y login
y 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 se
tuvo 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 usuarios
y 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 y
poder 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 Clases
del portal de Parse.
Se observan las clases principales para llevar a cabo la gestión de las partidas y los
jugadores.
En esta etapa se implementaron una serie de tareas asociadas a la persistencia en la
nube:
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 la
información en el tablero, en la escena correspondiente a la fase actual de la
partida.
• 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 jugador
durante 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 identificar usuarios y hacer uso de todas las funcionalidades citadas, es decir, ya se
podía jugar con la aplicación a falta de la gestión de notificaciones y revision de
diseño.
6a Iteración: Notificaciones: Se llevó a cabo en esta la gestión de notificaciones, para
avisar a los jugadores de los cambios en sus partidas, haciendo uso de la plataforma de
parse.
Se puede observar en la figura 4.14, como se muestra la llegada de una notificación de
Battlex.
Para realizar esta iteración se hizo uso nuevamente del SDK de Parse y de una clase
especial proporcionada por la plataforma llamada ”Installation” (Instalación). En ella
se guardaban los identificadores únicos de dispositivo (UDID) en el momento de la
identificación, para asociar un usuario con su dispositivo.
Entonces para mandar una notificación, una vez un jugador había completado todas las
fases de su turno, se configura ésta y se le dice a la plataforma que mande el mensaje
al 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 interfaz
agradable y actualizada a los diseños de aplicaciones actuales, se llevo a cabo una
revisió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 una
plantilla 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ón
anterior, pero con la interfaz mejorada.
4.3.4
4a Etapa: Documentación
En 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 Realizadas
En 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 funcionalidad.
4.4.1
Pruebas de Compatibilidad
En 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 se
tenía como dispositivo de pruebas el iPhone 4, lo que derivó mas tarde en problemas de
compatibilidad al compilar la aplicación para iPad.
Cuando se realizó la primera compilación del proyecto para el iPad, ya se había implementado toda la lógica de las escenas del juego, sólo quedaba por implementar la integración con
el servicio, entonces aparecieron problemas de compatibilidad:
Interfaz: Los recursos (como imágenes, fondos, etc) no estaban hechos para soportar
la 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 proyecto
está configurado para que la aplicación pueda ser usada en dispositivos iOS con ésta
versión como mínimo.
Apple recomienda siempre que saca una nueva versión de iOS, que los desarrolladores
actualicen sus aplicaciones a esa última, sin embargo se puede ofrecer la aplicación
para diferentes versiones, con esto se pueden aprovechar las mejoras del sistema operativo en cada versión, sin que los usuarios con versiones anteriores tengan que dejar
de actualizar la aplicación.
La solución a estos problemas de compatibilidad se solucionó configurando el proyecto
para que la compilación no fuera universal (Figura 4.15), sino que fuera optimizada para
iPhone 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 se
vea dos veces más grande y sea completamente funcional al igual que en iphone 4 (Figura
4.16).
Figura 4.16: Captura de Battlex en ejecución en iPad
54
4.4.2
Pruebas de Jugabilidad
Para 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 mediante
dicha encuesta y las conclusiones al respecto.
Los siguientes gráficos muestran los resultados obtenidos después de encuestar a 15 personas.
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 la
efectividad, que se debe a la estadística de la puntuación obtenida de los dados ya que que
perjudicaría al atacante, y el requisito social se debe a que no se pueden elegir los rivales a
la 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ía
darse 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 existe
comunicación entre los jugadores durante la partida, y la motivación puede deberse a que no
se 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 la
obtenida 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 tablero
original y el uso de la aplicación
Aprendizaje: Se interpreta de manera que los jugadores que conocen el juego si saben
usar 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 debido
a 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 tropas
en 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á de
jugar la partida seleccionada, no hay personalización de las mismas.
Motivación: No existe sistema de recompensas en el juego, por lo que este requisito
tiene una puntuación muy baja.
Conclusiones
La puntuación global sobre la aplicación al realizar el test sobre 15 personas ha sido de
3,46 sobre 5.
Se es consciente de las limitaciones en cuanto a todos los aspectos que engloban la realización de un juego, por eso hay algunos puntos que mejorar en el futuro, estos puntos de
mejoras futuras se expondrán más adelante en la sección 5.5.
4.4.3
Pruebas de Funcionalidad
Para realizar las pruebas de funcionalidad del software, durante el desarrollo se implementaron registros que mostraban en la consola de XCode los resultados a la hora de procesar
los datos.
Para realizar los registros se utiliza la clase de objective-C llamada NSLog, en el listado
4.13 se puede ver un ejemplo del código necesario para lanzarlo. A continuación se describirán algunas de las partes que componen la aplicación, con el fin de mostrar como se realizan
los registros a la hora de probar las funcionalidades del software y recibir retroalimentación
de 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 partidas
de usuarios y se muestra un diagrama de flujo de datos (Figura 4.9) de las llamadas que
se producen al cargar las partidas. A continuación se describirá la manera de registrar los
eventos que suceden durante este flujo de datos.
Carga de la escena: Existen dos maneras de acceder a esta escena, la primera es haciendo
login desde la escena de login y la segunda es entrando en la aplicación con el usuario
cacheado localmente en el dispositivo.
Desde login: En el siguiente listado (listado 4.14) se muestran los registros que se
capturan 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 ]
Correcto
2014 08 21 21:16:46.688 Battlex [608:60 b ]
GameListScene
2014 08 21 21:16:46.691 Battlex [608:60 b ]
Instancia de la escena creada
2014 08 21 21:16:47.262 Battlex [608:60 b ]
y tablas cargados
( Escena Login ) Login
( Escena Login ) Cargando
( Escena Partidas )
( Escena Partidas ) Menus
Listado 4.14: Login correcto, transición a Escena Partidas
Usuario cacheado: En el listado (listado 4.15) se muestrar los registros que se capturan desde que arranca la aplicación y se identifica el usuario cacheado, hasta que se
carga la escena de partidas.
2014 08 21 21:47:42.630 Battlex [624:60 b ]
cache
2014 08 21 21:47:42.664 Battlex [624:60 b ]
GameListScene
2014 08 21 21:47:42.669 Battlex [624:60 b ]
Instancia de la escena creada
2014 08 21 21:47:42.711 Battlex [624:60 b ]
started with frame interval : 60.00
2014 08 21 21:47:42.743 Battlex [624:60 b ]
960 x640
2014 08 21 21:47:43.068 Battlex [624:60 b ]
y tablas cargados
( AppDelegate ) Usuario en
( AppDelegate ) Cargando
( Escena Partidas )
cocos2d : animation
cocos2d : surface size :
( Escena Partidas ) Menus
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 al
servicio, 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 { N S E r r o r F a i l i n g U R L S t r i n g K e y = https :/
/ api . parse . com /2/ update , N S E r r o r F a i l i n g U R L K e y = https :/ / api . parse .
com /2/ update , NS Lo cal i z e d D e s c r i p t i o n = The Internet connection
appears to be offline . , N SUnder lying Error =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 observar
como se van obteniendo los datos del servicio, desde las partidas de un jugador, después
los jugadores que forman la partida, y por último las casillas que conforman el mapa, hasta
conseguir 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 consola
informando de ello.
Obtener jugadores de cada partida: Una vez que se han recuperado las partidas, por
cada una de ellas se manda una nueva petición para obtener los jugadores, cuando llega
la respuesta un registro informa del resultado.
Obtener casillas del mapa: Nuevamente, cada tabla por separado creará otra petición
por cada elemento de la tabla para pedir las casillas que corresponden al mapa de la
partida, este ya ha sido recuperado en la petición de la partida. Se mostrará un registro
cada vez que se obtengan las casillas de una partida.
Mostrar contenido de las partidas en las tablas: Cuando se ha terminado de recibir
toda 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 vez
se haya realizado la recarga un registro informa de ello, significará que en la pantalla
se 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 partidas
del 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 Creada
2014 08 21 23:54:36.468 Battlex [704:60 b ] ( GameListScene ) Partidas de
Test recibidas
2014 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 recibidas
2014 08 21 23:54:37.169 Battlex [704:60 b ] ( MiTurnoTable ) Casillas de
partida : yN7TlsyWqx recibidas
2014 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 la
aplicación desde que se hace login hasta que se muestran la información de las partidas en
las tablas.
60
Interacción con el mapa
En este punto se definirá un ejemplo de como se tiene constancia de que se está capturando correctamente el territorio que el usuario está pulsando. Con esto quedarán definidos
los diferentes comportamientos de la aplicación, no se ilustrarán los demás porque resultaría repetitivo, aunque sus registros están implementados en el código. Comportamientos
como navegar entre escenas, recuperación de datos desde el servidor y configuración de los
elementos de la vista, así como los registros de la interacción del usuario quedarán definidos.
Cálculo de territorio pulsado: La pantalla de ataque será sobre la que se mostrará el
ejemplo 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 cuarta
columna 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 empiezan a producirse los cálculos, cuyo registro se muestra en el listado 4.18.
2014 08 22 00:27:53.669
132.50 200.00
2014 08 22 00:27:53.674
(265.0 , 400.0)
2014 08 22 00:27:53.680
territorio pulsado
2014 08 22 00:27:53.683
obtenido : (3 , 0)
2014 08 22 00:27:53.687
: (3.0 , 0.0)
2014 08 22 00:27:53.700
atacantes
Battlex [725:60 b ] ( AtaqueScene ) Punto pulsado :
Battlex [725:60 b ] ( AtaqueScene ) Pixel pulsado :
Battlex [725:60 b ] ( AtaqueScene ) Calculando
Battlex [725:60 b ] ( AtaqueScene ) Territorio
Battlex [725:60 b ] ( AtaqueScene ) Tropa Sombreada
Battlex [725:60 b ] ( AtaqueScene ) Aumentando
Listado 4.18: Registros de territorio pulsado
61
Como se puede observar en el registro del listado anterior, primero se muestra la coordenada 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 a
calcular el territorio pulsado, es (3, 0) porque el primer número de fila y columna empieza
por 0. Una vez se ha calculado la coordenada del mapa del territorio, se realizan las llamadas
correspondientes para configurar visualmente el territorio.
Conclusiones
Aunque no se han realizado test unitarios, el sistema de pruebas realizado ofrece mucha
visibilidad sobre el estado de la aplicación en caso de que se produzca cualquier tipo de error
o excepción.
Como se ha tenido constancia, sobre todo en las llamadas al servicio, de cuando se producían errores que se tenía mucha información del estado de la aplicación como se ha podido
ver en los registros cuando se pierde la conexión, se ha considerado suficiente para gestionar
las pruebas de esta manera.
Aun así, para dar mas visibilidad sobre los errores, se podrían integrar herramientas de
gestión de errores, de terceros, que envían informes de errores y otros registros que se pudieran considerar relevantes, que les ocurren a los usuarios cuando la aplicación esta en
producción. Una de las posibilidades podría ser la reciente herramienta obtenida por Apple
llamada TestFlight (https://www.testflightapp.com).
62
Capítulo 5
Resultado y Conclusiones
E
N este capítulo, después de que el esfuerzo realizado durante el desarrollo haya dado sus
frutos, 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 de
las tecnologías utilizadas y propuestas de trabajo futuro.
5.1 Resultado
El resultado final obtenido como Trabajo fin de grado ha sido Battlex, nombre que aparece de fusionar la palabra en ingles Battle, que en la categoría militar significa: ”Encuentro
hostil entre fuerzas militares opuestas”, con otra palabra inglesa, Hexagon, que en castellano
quiere decir ”hexágono” o ”polígono de 6 lados”. La pronunciación de la primera sílaba de
la palabra Hexagon es similar a la de la letra ”x” en inglés. Ese es el origen del nombre, que
hace referencia a batallas en territorios con forma de hexágono, forma geométrica escogida
para el diseño del tablero.
Para realizar el desarrollo, se ha seguido la metodología ágil, eXtreme Programming. El
diseño y la experiencia de usuario se han realizado con el criterio UCD, siguiendo patrones y
guí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 del
mapa no cambia para un dispositivo iOS de 4 pulgadas, como podrían ser el iPhone 5, 5C
o 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 para
ambas 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 dispositivos iPhone de 5a generación son superiores en hardware.
En las siguientes figuras se muestra el resultado visual de la aplicación, las diferentes
pantallas que la forman.
En la figura 5.1 se puede ver como el usuario a través de un formulario podrá introducir
sus 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 las
tropas de refuerzo sobre sus territorios, deshacer los cambios, volver a la pantalla de partidas
o pasar a la siguiente fase.
En la figura 5.4 se puede observar la pantalla de ataque, en ella el usuario podrá realizar
sus ataques, seleccionando un territorio aliado y uno enemigo para realizar el ataque, cuyos
resultados se mostrarán en esta misma pantalla. A parte de esta función se podrá volver a la
pantalla 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 territorios, en ella el usuario podrá realizar la fortificación de los territorios aliados que desee y
las 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 mercado
actual de aplicaciones móviles. Pero no se encontró ninguna que estuviera basada en juegos
de conquista de territorios. Entonces se empezó a definir lo que sería la descripción del
problema.
Con lo cual, sin alternativas en el mercado de aplicaciones, al menos directas, pues existen
infinidad de juegos de guerra, estrategia y conquista de territorios, Battlex podría ser una
referencia en el campo de los juegos asíncronos, ya que se diferencia mucho del resto de
aplicaciones asíncronas actuales en la temática de juego, aunque todos comparte el mismo
origen, los juegos de mesa o tablero.
5.2.1
Adaptación de las reglas originales para crear una aplicación
asíncrona
Una de las fases clásicas de juegos de mesa como Risk, necesita de una respuesta directa
del rival a la hora de efectuar los ataques.
A la hora de definir los ataques, en el juego original, el defensor puede decidir hacer uso
de uno o dos dados de defensa. En el caso de Battlex se suprime esta decisión por parte del
defensor, 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áximo
posible, 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 integrantes de una partida era, el reparto de territorios. Ya que en el juego original, éstos se
sitúan en el tablero en orden de uno en uno pasando el turno de jugador en jugador en cada
colocación.
El reparto de territorios se adaptó de la siguiente manera: Se hace un reparto aleatorio de
los territorios siempre manteniendo el mismo número de los mismos controlados por cada
jugador.
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 manera
que 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 se
van a repasar para explicar como se ha llevado a cabo su cumplimiento.
66
5.3.1
Objetivos Específicos
Las siguientes fases mezclan lo que sería una partida del juego complementado con
funcionalidades 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 las
diferentes 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és
del 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íncronas que hay en el mercado. Ayudandose de adaptaciones de Risk en juegos para
ordenador y consolas se definieron las reglas que debía tener la aplicación para cumplir el requisito general de ser asíncrona. Y complementado las reglas clásicas que
tanto éxito han tenido desde la creación de este género como juego de tablero con las
interfaces táctiles y el servicio de notificaciones, se obtiene el interés del usuario sobre
la aplicación.
2. Implementar el juego mediantes los lenguajes y tecnologías más apropiados para
alcanzar el objetivo general.
Ya que el trabajo está orientado al sistema operativo iOS, se pudieron elegir las herramientas para desarrollar de manera nativa para esta tecnología. Además, ya que tanto
cocos2d for iPhone como Parse tienen SDK escrito en Objective-C, lenguaje nativo de
iOS, todo el desarrollo de la aplicación ha sido llevado a cabo en éste lenguaje. Con
lo cual, dado que los lenguajes y tecnologías utilizados fueron los más apropiados, se
cumplió este objetivo.
3. Asegurar el correcto funcionamiento y la consecución del objetivo general mediante
pruebas 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 Operativos
1. Se 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 diferentes tareas, 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 vez elegido el que se integrará en el proyecto, se
procederá a realizar tareas incrementales para aprovechar el tiempo de aprendizaje
en el desarrollo de la aplicación final.
Para cumplir este objetivo, como se puede observar en el capítulo 4, se crearon las
interfaces de usuario para las escenas dle juego utilizando cocos2d. También se hizo uso de la metodología incremental eXtreme Programming para la realización de
iteraciones, 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 haga
uso de la interacción de un dispositivo móvil con pantalla táctil. Esto implica también
adaptar las reglas para que la jugabilidad se lleve a cabo de manera asíncrona, es
decir, que los diferentes integrantes 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 la sección 1.2.2 del capítulo 1.
El cumplimiento de este objetivo operativo ha sido explicado anteriormente en la sección 5.3.1.
3. Diseñar e implementar las diferentes escenas del juego. Desde el inicio de sesión
y el registro hasta el visor de partidas y el tablero. Las primeras no tendrán mucha
complejidad ya que deberán mostrar una interfaz sencilla para que lo usuarios introduzcan 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 jugadores
los controlan.
Se crearon todas las escenas, desde las más sencillas a las mas complejas, usando cocos2d para iPhone. Y para representar los territorios se escogió un tablero, en el que
los territorios son de forma hexagonal, de manera que cumpliendo las recomendaciones de Apple sobre interfaces de usuario, se mostraran en la pantalla de manera que
los usuarios pudieran interactuar con ellos.
4. Se realizará una búsqueda de información a través del estado del arte, con aplicaciones similares, para conocer como resuelven diferentes problemas de interacción y
saber como se podría enfocar el diseño de la interfaz de usuario, que es uno de los elementos mas importantes en proyectos de este tipo. También se hará uso y se tendrá en
cuenta 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 y
poder representar debidamente la interfaz de usuario y que éste entendiera lo que se
quería transmitir.
5. La aplicación dispondrá de un servicio web o backend, con el que realizar llamadas
para 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én
dispondrá de un SDK para realizar peticiones al servicio REST.
Este objetivo se cumplió de la siguiente manera: Integrando el SDK de Parse para iOS
en el proyecto y configurando la aplicación, base de datos y notificaciones push en el
portal web, como se puede ver en el anexo A.
6. Una notificación push es, básicamente, un mensaje enviado por un servidor a un
cliente que está suscrito a sus notificaciones [Mateos(2013)]. Se implementará este
servicio para que los 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 el turno de alguna de las partidas en juego.
Para cumplir este objetivo se configuró debidamente la aplicación para poder suscribir
los dispositivos de los usuarios para que pudieran recibir notificaciones. En el portal
de parse se configuró la aplicación y la base de datos para poder enviar notificaciones
a los dispositivos usando su SDK.
5.4 Limitaciones encontradas
Todas 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 de
empezar.
Al comienzo se realizaron una serie de tutoriales y ejemplo simples de aplicaciones, primero usando iOS y más tarde integrando en éste cocos2d. La curva de aprendizaje del lenguaje
utilizado Objective-C es más alta que la de otros lenguajes como java, pero además nunca se
había tenido contacto con estas tecnologías. Sobre el lenguaje java si se tenían conocimientos
previos, pero la adaptación al lenguaje utilizado en el trabajo ha sido más complicada, mas
aú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 lenguaje 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 servicios
web, como el utilizado en la aplicación. Sólo se habían realizado tutoriales sobre la integració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 libros
sobre las tecnologías como su comunidad de usuarios y los portales utilizados, lo que conlleva otro esfuerzo más a la hora de encontrar solución a los problemas que se han tenido.
5.5 Trabajo Futuro
A 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 crear
un sistema de creación de partidas que no fuera aleatorio y que el creador pudiera elegir el
nú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 de
personalización de la nueva partida e implementado la lógica se podría llevar a cabo esta
mejora.
Otra mejora que se podría realizar es integrar un sistema de logros como Game Center
para iOS, así los jugadores de todo el mundo podrían ver un ranking de puntuación y retarse
desde el portal. Utilizando el framework de Game Center se podría integrar la aplicación para
ofrecer 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 que
supongan un reto para los usuarios.
Otra de las mejoras sería crear una capa mas en la arquitectura para que la dependencia
de un servicio externo fuera mínima y fácilmente se pudiera cambiar de sistema de gestión
de la persistencia. En Objective-C la manera de implementar esta capa podría ser a través de
una serie de interfaces que pudieran abstraer a las llamadas al servicio del SDK externo, es
decir, las llamadas aceptarían objetos nativos que se tradujeran al modelo de datos sin que
estos 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 ataques, etc, mejorarían la experiencia de usuario. También sería posible realizar unas texturas
más detalladas para mejorarla.
Como en los ejemplos de aplicaciones que se han visto en el estado del arte, se podría
realizar un chat de partidas, en las que lo usuarios que la forman pudieran hablar entre ellos
para, por ejemplo, formar pactos contra otros. Esto mejoraría la estrategia y por tanto la
jugabilidad. 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, se
llevaría a cabo esta mejora.
Para realizar de manera nativa toda la aplicación para iOS, se podría utilizar el framework
grá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 da
soporte el fabricante del sistema operativo y el hardware.
5.6 Conclusiones
Ha sido gratificante enfrentarse a una serie de tecnologías totalmente desconocidas, empleando todos los conocimientos previamente adquiridos durante la carrera, y poder llevar a
cabo este trabajo.
Esto ha abierto un mundo de oportunidades futuras muy motivador. Ya que a nivel de
usuario el alumno era apasionado por esta tecnología, y ahora lo es también del desarrollo
de ésta.
Lo mejor que ha ocurrido con la realización del trabajo, ha sido el aprendizaje de la plataforma móvil como es iOS, ya que complementa los estudios que el alumno ha realizado
durante la carrera. También el hecho de conseguir crear una aplicación videojueguil, consiguiendo los objetivos marcados, para una de las plataformas más extendidas, ha sido muy
satisfactorio.
Por último añadir que la realización del trabajo me ha servido para encontrar trabajo, de
lo cual estoy muy agradecido, pero no sólo eso sino que también estoy trabajando en la
plataforma móvil en al que está basada el presente trabajo.
71
ANEXOS
73
Anexo A
Parse
D
que la persistencia y comunicación usando la nube, es uno de los pilares mas
importantes 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.
ADO
A.1 Registro y Configuración
Inmediatamente después de hacer el registro como usuario de Parse, se registra la aplicación en Parse para conseguir las App Keys (Figura B.4), que darán acceso a la plataforma
desde 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 credenciales obtenidas de la siguiente manera:
# import < Parse / Parse .h >
[ Parse setApplicationId : @ " v 4 p W h I w Q p G n D c W w w E X k L h p u x 7 G k f 9 9 l W j 9 V U 6 I c Y "
clientKey : @ " E U B z o Q q Q o 0 n n 4 u 3 3 d O W 7 r x s 3 f P b d t W M 0 O S j W J w G y
" ];
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 correspondiente a la plataforma, en este caso iOS.
A.2 Panel de control
Desde 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 los
usuarios 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 el
que más nos interesa en este momento es ”Data Browser” (Explorador de datos).
A.2.1 Clases
Ya 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 personalizada (Figura A.3. En el caso de Battlex todas las clases serán personalizadas, excepto la
de usuario e instalación, ya que la plataforma dispone de sistemas de seguridad y control de
usuarios 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 la
tabla ”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”. Esto
se debe a que cuando un usuario cierra sesión en la aplicación, también lo realiza en la
plataforma de Parse, es decir, en ese momento solo había un usuario identificado.
A.2.2 Relaciones
El 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 partida
en el campo ”Jugadores” y el mapa de cada partida.
Como ya se ha comentado, cada partida esta formada por tres jugadores, con lo cual, el
campo ”Jugadores” de la clase ”Partida”, estará formado por una lista de punteros a usuarios
de la clase ”User”.
Cuando se realiza una petición para conseguir los datos de una partida, el campo ”Jugadores” 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 datos
de los jugadores que la forman, se debe hacer una petición más a la clase ”User” usando
la clase PFQuery. En el listado A.3, se puede observar como se configura la petición para
obtener la información completa de los jugadores contenidos en una partida.
77
NSMutableArray ⇤ jugadores = [[ partida objectForKey : @ " Jugadores " ]
valueForKey : @ " objectId " ];
PFQuery ⇤ query = [ PFQuery q ue ryW it hC la ss Na me : @ " _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én
contiene el campo ”Mapa”. Pero este sólo contiene el identificador del mapa de la partida, ya
que es una relación directa. En la figura A.5 se observa como se crea una columna del tipo
relació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 Inconvenientes
Ahora se van a nombrar las ventajas y los inconvenientes que tiene el uso de Parse como
BAA S 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 para
no 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 cerrara 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 los
siguientes 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
E
el juego Battlex, el objetivo es conquistar todos los territorios enemigos para conseguir el control de todo el tablero.
N
Para realizar esto primero se debe realizar el registro del usuario, a continuación la identificación del usuario registrado y con ello ya se entra dentro de la aplicación.
B.1 Registro
Para 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 se
hayan introducido los datos, se debe pulsar el botón ”Registrarse”.
Figura B.1: Battlex paso a paso: Registro
81
B.2 Identificación
Como en el apartado anterior, se deben rellenar los campos con los datos requeridos. Pulsando sobre ellos aparecerá el teclado con el cual se introducen los datos. Una vez introducidos, se debe pulsar el botón ”Identificarse”.
Figura B.2: Battlex paso a paso: Identificación
82
B.3 Menú Partidas
En el menú partidas existen diferentes controles que se explicarán a continuación.
B.3.1
Opciones
Pulsando el botón de opciones, situado en la parte superior izquierda de la pantalla, aparecerá 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 Partida
En la parte superior derecha de la pantalla, está situado el botón crear partida con el simbolo ”+”. Pulsando sobre él se creará una nueva partida, que se añadirá a la lista de partidas
en las que le toca jugar al usuario identificado.
B.3.3 Partidas
En 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”. Una
vez elegida una partida, se mostrará el mapa y los controles correspondientes a la fase en la
que esté.
Figura B.4: Battlex paso a paso: Partidas
84
B.4 Situar Refuerzos
En 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 al
lado del número de refuerzos.
Para ordenar a una tropa que se sitúe sobre un territorio, el usuario debe pulsar ese territorio
y una tropa se colocará en él. Un refuerzo por cada toque, mientras queden refuerzos por
situar. Si el usuario se equivoca, la opción deshacer devolverá el último refuerzo situado
sobre el tablero a la reserva de refuerzos que situar.
Una vez que los refuerzos están situados, aparecerá el botón ”Siguiente” que llevará al
usuario a la siguiente fase: El ataque.
En el ejemplo de la figura B.5 se puede observar como se ha ordenado la colocación de
los 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 Ataque
Pasos para configurar el ataque deseado:
1. Pulsar sobre el territorio de ataque tantas veces como tropas se quieran usar en el
mismo. Se podrán utilizar un máximo de 3 tropas, siempre dejando una tropa defendiendo el territorio, es decir, si el territorio tiene 3 tropas, se podrán utilizar un máximo
de 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 territorio
seleccionado 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 la
parte 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 aplicació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 primero
con 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 sus
tropas y el jugador ”Minguel553” ha perdido 6-4 otra.
87
B.6 Fortificar
Al 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 quiera
mover. Una vez alcanzado el valor de tropas deseado, con un máximo de n-1 tropas seleccionadas, 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 7
para realizar su movimiento.
Una vez el usuario lo desee, puede pulsar sobre el botón siguiente, se guardarán los cambios 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
A
comienzo del trabajo se definieron una serie de requisitos de arquitectura, librerías
y 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.
L
No obstante, se hicieron diversas pruebas e incluso se introdujo en la propia aplicación de
Battlex. A continuación se van a mostrar los ejemplos que se realizaron para estudiar estas
tecnologías.
C.1 Base de Datos: SQLite
XCode 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 los
datos de la aplicación en una base de datos local del dispositivo con el fin de realizar las
primeras pruebas.
En la figura C.1 se puede observar que aspecto tenía la base de datos llamada ”BDBattlex.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 los
datos 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 se
utilizaban 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 SQLite
no se muestra en la memoria por su extensión y porque no es relevante, sin embargo se
incluirá en el CD adjunto a la presente por si se quiere consultar esta información.
C.2 Prueba de registro
Antes 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 datos
SQLite. A continuación se describirá brevemente los componentes que formaban parte de
este proyecto de prueba.
90
C.2.1 Interfaz de Usuario
Para 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 diferentes
pantallas 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 datos
Como 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 de
rellenar el formulario, se ejecuta el método que se puede ver en el listado C.1 que abre la
base de datos y genera la consulta correspondiente para generar el usuario.
( IBAction ) btnregistrar :( id ) sender {
AppDelegate ⇤ appDelegate = ( AppDelegate ⇤) [[ UIApplication
sharedApplication ] delegate ];
// Ahora instanciamos la variable database de tipo sqlite3
sqlite3 ⇤ database ;
// Creamos el sqlite3_stmt que contendra despues la sentencia a
ejecutar compilada .
sqlite3_stmt ⇤ sentencia ;
// Abrimos la base de datos de la ruta indicada en el delegate
if( sqlite3_open ([ appDelegate . DataBasePath UTF8String ] , & database )
== SQLITE_OK ) {
// Si no ha habido errores al abrir , creamos la sentencia de
insercion .
NSString ⇤ sqlStatement = [ NSString stringWithFormat : @ " Insert
into Usuarios VALUES (\" % @ \" , \" % @ \" , \" % @ \") " , self .
91
txtcorreo . text , self . txtusuario . text , self . txtcontrasena .
text ];
// Lanzamos la consulta y recorremos los resultados si todo ha
ido OK
if( sq li te 3_ pr ep ar e_ v2 ( database , [ sqlStatement UTF8String ] , 1,
& sentencia , NULL ) == SQLITE_OK ) {
// En otros casos recorremos los resultados . En este caso
no habra .
while( sqlite3_step ( sentencia ) == SQLITE_ROW ) {
}
} else {
NSLog ( @ " Error en la creacion del insert " ) ;
}
// Libero la consulta
sqlite3_finalize ( sentencia ) ;
}else{
NSLog ( @ " No se ha podido abrir la BD " ) ;
}
// Cierro la base de datos
sqlite3_close ( database ) ;
}
// Si todo ha ido bien podemos abandonar la ventana e ir a la
superior .
[ self . na v i g a t i o n C o n t r o l l e r p o p V i e w Co n t r o l l e r A n i m a t e d : YES ];
Listado C.1: Generación de usuarios en Sqlite
Todo esto sirvió de toma de contacto para realizar posteriormente la integración de SQLite
en Battlex, aunque como se ha comentado, finalmente se decidió no utilizar este framework
para 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 dar
su 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!
!
!
Jugabilidad!
Intrínseca!
!
!
Jugabilidad!
Mecánica!
!
!
!
Jugabilidad!
Interactiva!
!
!
Jugabilidad!
Artística!
Atributo!
Satisfacción!
Aprendizaje!
Efectividad!
Inmersión!
Motivación!
Emoción!
Social!
Satisfacción!
Aprendizaje!
Efectividad!
Inmersión!
Motivación!
Emoción!
Social!
Satisfacción!
Aprendizaje!
Efectividad!
Inmersión!
Motivación!
Emoción!
Social!
Satisfacción!
Aprendizaje!
Efectividad!
Inmersión!
Motivación!
Emoción!
Social!
Satisfacción!
!
!
!
Aprendizaje!
Jugabilidad!
Efectividad!
Intrapersonal! Inmersión!
Motivación!
Emoción!
Social!
!
Satisfacción!
!
Aprendizaje!
Jugabilidad!
Efectividad!
Interpersonal! Inmersión!
Motivación!
Emoción!
Social!
Requisitos!a!cumplir!
Valoración!del!Sistema!de!Juego!
Reglas!fácil!de!entender!
Intentos!para!conquistar!territorios!
Conquistar!el!mapa!
Reconquistar!territorios!perdidos!
Ganar!la!partida!conquistando!el!mapa!
Uso!de!compañeros!para!jugar!!
No!apreciación!de!retrasos!ni!sincronizaciones!
Estrategia!
Detecciones!táctiles!de!los!elementos!
Reconocimiento!táctil!
Tiempos!de!carga!mínimos!
Cambios!de!escena!
Sincronización!de!partidas!por!WiVFi!o!3G!
Interacción!táctil!
Comprensión!de!los!elementos!visuales!
Correcto!reconocimiento!táctil!de!los!elementos!
pulsados!
Diferentes!controles!del!mapa!en!cada!fase!
Resultados!visuales!de!los!ataques!
Efectos!de!cambio!de!escena!
Comunicación!con!otros!jugadores!
Diseño!de!la!aplicación!
Se!diferencia!cada!territorio!por!su!color!
Es!fácil!reconocer!las!tropas!de!cada!jugador!
Colores!típicos!de!juegos!de!conquista!
Retroalimentación!al!pulsar!territorios!
Visualización!de!los!cambios!
Se!muestra!la!información!de!las!partidas!
Se!prefiere!usar!la!aplicación!a!usar!el!juego!de!
mesa!
Se!comprende!el!juego!sin!ayuda!exterior!
Se!avanza!rápido!en!las!partidas!
El!jugador!cree!que!es!el!general!de!las!tropas!
El!jugador!está!pendiente!de!los!cambios!en!sus!
partidas!
El!jugador!se!alegra!al!conquistar!territorios!
Incentivar!las!ganas!de!revancha!
Gestión!de!recursos!para!las!partidas!
Adaptarse!a!los!cambios!de!los!rivales!
Número!de!turnos!para!terminar!la!partida!
Comunicación!y!control!de!las!partidas!
Recompensas!por!las!partidas!ganadas!
Incentivar!la!rápida!respuesta!de!los!jugadores!
Fomentar!el!cambio!de!estrategia!entre!jugadores!
Puntuación!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
Referencias
[Anónimo(2014)] Anónimo. Objective-c. www.wikipedia.org, último acceso en Junio de
2014, 2014.
[AppAnnie(2013)] AppAnnie. Index market q2 2013. blog.appannie.com, último acceso en
Mayo 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 acceso
en 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 Mayo
de 2014, 2014.
[Languedoc(2012)] Kevin Languedoc. How to become an iphone app creator. HubPages.com, último acceso en Junio de 2014, 2012.
[Letelier(2005)] Patricio Letelier. Metodologías ágiles para el desarrollo de software: Extreme 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 acceso en Junio de 2014, 2013.
[Mateos(2013)] Manu Mateos. Tecnología push así funciona. www.genbeta.com, último
acceso en Julio de 2014, 2013.
[Omgpop(2014)] Omgpop. Draw something. http://omgpop.com/drawsomething, último
acceso en Junio de 2014, 2014.
[Rubio(2013a)] Miguel Díaz Rubio. migueldiazrubio.com. www.migueldiazrubio.com, último acceso en Julio de 2014, 2013a.
[Rubio(2013b)] Miguel Díaz Rubio. Desarrollo ios: Parse. www.migueldiazrubio.com, último acceso en Agosto de 2014, 2013b.
[Triviados(2014)] Triviados. ¿qué es triviados? http://triviados.org/triviados/, último acceso
en Junio de 2014, 2014.
[Wells(2009)] Don Wells. Extreme programming. www.extremeprograming.org, último acceso en Junio de 2014, 2009.
[y Andreas Löw(2011)] Steffen Itterheim y Andreas Löw. Learn cocos2d Game Development 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 LATEX
empleando la clase esi-tfg que se puede encontrar en:
https://bitbucket.org/arco group/esi-tfg
[Respeta esta atribución al autor]
99