MMORPG location-based for Android - IIT

 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
MMORPG location-based for Android
Autor: Antonio Rodríguez López
Director: Alfonso Villar Chicharro
Madrid
Septiembre 2012
Autorizada la entrega del proyecto del alumno/a:
Antonio Rodríguez López
EL DIRECTOR DEL PROYECTO
Alfonso Villar Chicharro
Fdo.: …………………… Fecha: 03/ 09/ 2012
Vº Bº del Coordinador de Proyectos
David Contreras Bárcena
Fdo.: …………………… Fecha: ……/ ……/ ……
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
Agradecimientos
Gracias en primer lugar, a mis padres por todo su apoyo y dedicación. Por la gran labor
que han hecho al brindarme una educación inmejorable y por el tremendo esfuerzo que
han realizado para que pueda estudiar la carrera que he deseado, donde he querido. Sin
vosotros faltaría la piedra angular sobre lo que se asienta todo. Sin vosotros, nada
hubiera sido posible.
A Trini, por estar siempre a mi lado, apoyándome en los momentos de flaqueza y
acompañándome en los momentos de alegría. Sin ella, no hubiera sido capaz de
encontrar las fuerzas para continuar.
A mi director, Alfonso, por brindarme la oportunidad de no acabar la carrera sin haber
programado un videojuego, el broche perfecto para el fin de mis estudios universitarios.
A Fernando por ser mi diseñador gráfico particular y por las conversaciones silenciosas
de una sola mirada.
A mi abuela Maruja, un referente de cariño. A toda mi familia por las muestras de afecto
recibidas.
I
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
II
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
MMORPG location-based for Android
Autor: Rodríguez López, Antonio
Director: Villar Chicharro, Alfonso
Resumen
El objetivo de este proyecto es la programación de un MMORPG basado en localización
para el sistema móvil Android de Google.
Palabras clave: Android, Andengine, MMORPG, videojuego, cliente-servidor.
1
Prólogo
Antes de continuar se subraya que los términos de juego y videojuego van a ser usados
de indistintamente a lo largo del presente documento, pero refiriéndose siempre al
mismo concepto de software de entretenimiento y ocio electrónico.
MMORPG hace referencia a un estilo o tipo de videojuego, acrónimo en inglés de
Massively Multiplayer Online Role Playing Game, una traducción aproximada del
español podría ser videojuego de rol multijugador masivo online. Los videojuegos, al
igual que ocurre con los libros, la música o las películas, también se clasifican en
diferentes estilos, algunos ejemplos son: aventura, survival-horror, simulación de
deportes, simulación de carreras, arcade, plataformas, MMORPG, etc. Decir que un
juego es un MMORPG sólo es decir que pertenece a ese estilo.
2
Introducción
¿Qué implicaciones tiene que un juego sea un MMORPG? Las características básicas de
un MMORPG son dos: primero el jugador va a asumir un alter ego, ya sea una sola
identidad o colectiva, interpretando un papel ficticio en un mundo ficticio que no podría
representarse en la vida real. Asumiendo el jugador todos los requisitos necesarios para
el desarrollo y evolución de este alter ego, medido comúnmente en forma de niveles. Y
segundo, el juego multijugador masivo. El jugador no va a estar sólo en este mundo.
Una gran cantidad de jugadores van a coincidir con él en tiempo real.
III
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
El juego desarrollado se llama Shadow Fire y pone al jugador al mando de una ciudad
ficticia que se mueve en una dimensión paralela e idéntica al mundo real. Esta ciudad
tiene un vínculo único con el jugador siendo capaz de captar y sintetizar para su
evolución todos los elementos que rodean al jugador, convirtiendo estos elementos
“reales” en recursos “digitales” usables. Además esta ciudad tiene la gran peculiaridad
de ser capaz de moverse junto con el jugador, siguiéndolo en todo momento.
3
Diseño del juego
El cuerpo principal del juego consta de una sección para un solo jugador en el que se
deberán gestionar los recursos de una base para evolucionar. Esta base está
representada por una ciudad que consta de siete edificios con diferentes cualidades y
enfoque y dispondrá de plantas únicas. La clave de la evolución de los edificios será
construir en su interior hasta un total de cinco plantas con beneficios distintos, teniendo
en cuenta que la disponibilidad de plantas por edificio será mayor a la cantidad que se
puede construir. El jugador también tendrá acceso a la mejora y evolución de las
unidades o tropas que serán usadas para el enfrentamiento, siendo necesaria una
correcto cuidado de sus habilidades y aprendizaje. Por lo tanto, será vital en para el
correcto desarrollo del potencial del jugador buscar la combinación interna de los
edificios perfecta que maximice su estrategia y se complemente a la perfección con las
habilidades de sus tropas mientras pone la atención necesaria a que todo combine a la
perfección con los beneficios que se le otorgan por climatología y lugar.
La segunda mecánica de juego será la encarga de enfrentar a dos jugadores que
compiten por los recursos de una zona. Los encargados de combatir serán las unidades
que previamente se han entrenado y se les han enseñado los ataques que el jugador
crea convenientes. Durante los enfrentamientos, la mecánica de juego cambiará a
combate por turnos, actuando los jugadores cuando les sea indicado, intercambiando
ataques con el objetivo de mermar por completo los puntos de vida de la unidad de su
oponente.
4
Localización
La localización tendrá implicaciones adicionales dentro del juego. Permite determinar
que la posición geográfica de los jugadores determine también la proximidad en el
juego, permitiendo a los jugadores cercanos interactuar entre ellos (por ejemplo,
IV
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
atacando a un jugador para obtener beneficios en forma de recursos). Además la
localización determina las condiciones climatológicas a las que está sujetas el juego
gracias a la API Weather Underground y haciendo uso de la API de Google Places
determinar si se encuentra en un establecimiento comercial determinado, otorgando
ambas ventajas únicas e indispensables para los recursos y atributos del jugador,
necesarias ser explotadas eficientemente para que las posibilidades competitivas del
jugador se maximicen.
4.1
Uso de la localización
La gran novedad del juego será que estos recursos obtenidos por localización se
repartirán entre los jugadores cercanos, mermando los beneficios. La única forma que
tiene un jugador de volver a adquirir la mejora completa, será retando a los jugadores
cercanos en combate. El ganador de estos enfrentamientos, adquirirá una proporción de
los recursos por zona y climatología de su rival.
5
Implementación
El juego está desarrollado para la plataforma Android de Google e implementada
íntegramente en leguaje Java y ejecutado por la máquina virtual Dalvik, presente en
todos los sistemas Android. Java tiene la ventaja de ser un leguaje de programación
orientado a objetos muy potente y versátil, con una API muy madura que permite
incorporar clases muy complejas fácilmente en el desarrollo que facilitan la labor de
programación permitiendo centrar los esfuerzos de programación en otros aspectos
importantes.
5.1
Motor gráfico
Desarrollar un juego es una tarea altamente compleja y que requiere conjugar multitud
de habilidades y capacidades que son difíciles encontrar una única persona. Diseño
gráfico, programación, diseño de videojuegos, de niveles, de IA y un largo etc. Por ello,
elegir framworks y APIs que faciliten el trabajo es vital. Para este proyecto se ha
incorporado el motor gráfico Andengine en su versión GLES2. La API de este motor
gráfico añadida al proyecto modifica ligeramente el ciclo de vida y la forma de
programar una aplicación Android, pero facilita labores extremadamente complejas
como por ejemplo la carga de recursos gráficos, texturas o la incorporación de físicas.
V
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
5.2
Infraestructura cliente-servidor y multijugador
Para la incorporación del juego multijugador basado se ha desarrollado mediante un
servidor remoto desarrollado en Java con una base de datos MySQL accedido mediante
red IP. El servidor se encarga de dos procesos básicos en el juego online. Determina la
distancia de los jugares en tiempo real, comunicando a los jugadores que se encuentran
geográficamente cercanos y gestiona todo el proceso de interacción entre jugadores
que deseen combatir entre ellos. Se ha creado un algoritmo complejo y eficiente de
cálculo de distancias cercanas entre jugadores que reducen la necesidad de cálculo. El
otro cometido del servidor será gestionar los enfrentamientos entre dos jugadores
cercanos, realizando los cálculos necesarios y comunicándoselo a los terminales.
VI
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
Abstract
The goal of this project is MMORPG location-based for Google´s Andriod programming.
Key words: Android, Andengine, MMORPG, videogame, server-client.
1
Prologue
Before continue is underlined that game and videogame terms are going to use
interchangeably throughout this document, but always with the same concept of
entertainment software and electronic leisure.
MMORPG refer to a videogame style or type, Massively Multiplayer Online Role Playing
Game. Videogames, as same as happen with books, music or films, are clasificated by
styles, some examples are: adventure, survival horror, sports simulations, runs
simulations, arcade, platforms, MMORPG, etc. Said that a game is a MMORG only
means that owns to this style.
2
Introducction
What a game imply to be a MMORPG? The basics characteristics about MMORPG are
two: First, is a role game. The player are going to take an alter ego, just been one identity
or collective, performing a fictitious role in a fictitious world that wouldn’t be performed
in real life. Taking the player all the needs requires for development and evolution of this
alter ego, measure in common with levels. Second, is a massively multiplayer game. The
player is not going to be alone in this world. A big amount of players are going to clash
with him in real time.
The develop game is called Shadow Fire and put to the player a fictitious city on his
hands that moves in a parallel dimension like real world. This city have a unique link with
player and is able to catch and synthesized for it evolution all the elements that
surrounds to player, converting these “real” elements in usable “digital” resources.
Besides this large city has the peculiarity of being able to move along with the player,
following him at all times.
3
Game desing
VII
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
The game´s main body has one part to one only player in which he should to manage
resources in a base to develop. This base is represented by a city which has seven
buildings with different qualities and focuses and will have unique floors. The key of
building`s evolution will be to build inside just five floors with different advantages,
taking availability of floors in account by each building that would be more in quantity
that you could build. The player will have access to the improvement too and unities
development or storm-troops that will use to confrontation, being needed a well care on
their abilities and learning. By the way, will be vital for the well potential development of
the player search the effect internship combination of buildings that maximize their
strategy and complement each other perfectly with your storm-troops meanwhile you
pay the needed attention that all combine perfectly with benefits that granted by
climatology and places.
The second games mechanism will be to make sure to confront two players compete
for the resources of one zone. The changers of fight will be the unities previously are
been trained and are been teached attacks that player thinks properly. During
confrontations the game mechanism will change to fight turns, acting the players when
is indicated. Exchanging attacks with the objective of decrees a completely healthpoints of your opponents unity.
4
Localition
Location will have additional implies inside the game. Let us determined that geographic
position of players determine too proximity in the game, letting closer players interacting
each other (for example, attacking to one player to obtain benefits as resources). In
addition location determine some weathers conditions which are subjected to the game
thanks to API Weather Underground and making use of API Google Place to determinate
if is placed a business establishment determinate, granted both unics advantages and
essential for resources and player´s attribute, needed to be exploit efficiently to
competitive possibilities of player are maximized.
4.1
Localition uses
The game big news will be that this resources obtained by location are shared among
closer players, decreasing benefits. The one way that a player have to come back is to
VIII
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
acquire the complete improvement, will be to challenge other players in combat. Winner
in this confrontation acquiring a piece of resources by zone and climatology of his rival.
The game is developed to Android Google platform and completely interacting on Java
language and execute by Dalvik virtual machine, present at all Android systems. Java
has the advantage to be a programming language orientated to objects very powerful
and versatile, with an API very properly that allow incorporate class very complex easily
on development that easier programming work letting focus on programming efforts in
other important aspects.
5
Implementation
Develop a game is really complex task and require to combine lot of abilities and
capacities that are difficult to find in one person. Graphic´s design, programming,
videogame´s design, levels, IA and a long etc. For that, choose frameworks and API´s
that easier work is vital. For this project has been incorporated graphic motor Andengine
on its version GLES2. The API of this graphic motor added at project to slightly change
the circle of life and the form of programming an Android application, but easier work
extremely complex like for example the charge of graphic resources, texture or physic´s
incorporations.
5.1
Game engine
For the multiplayer incorporation game has been developed through remote server on
Java developed with a MySQL database through access IP red. The server is made sure
of two basics process in online game. Determined the players distance on real time,
communicating to players that are placed geographically of interaction among players
who like battle each other. Is created a complex algorithm and calculate efficient. The
other server tasks will be managed confrontations between two closer players doing the
necessary calculate and communicating to the terminals.
IX
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
X
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
Contenido 1 2 3 4 Prólogo ....................................................................................................................................... 3 1.1 La industria del videojuego ............................................................................................ 4 1.2 El proceso de creación de videojuegos ....................................................................... 4 1.2.1 Cadena de valor ....................................................................................................... 5 1.2.2 Diseño........................................................................................................................ 5 1.2.3 Arte y banda sonora................................................................................................ 6 1.2.4 Programación .......................................................................................................... 6 1.2.5 Testing....................................................................................................................... 6 Introducción .............................................................................................................................. 9 2.1 Motivación ...................................................................................................................... 10 2.2 Objetivos.......................................................................................................................... 11 2.2.1 Desarrollo para Android ....................................................................................... 12 2.2.2 Desarrollo para el servidor................................................................................... 12 Estado del arte ........................................................................................................................ 14 3.1 Nacimiento de los MMORPG....................................................................................... 14 3.2 MMORPG para Android ................................................................................................ 15 3.3 Incorporación de la localización a los MMORPG .................................................... 16 Diseño del juego ..................................................................................................................... 20 4.1 Tipos de jugadores ........................................................................................................ 21 4.2 Shadow Fire .................................................................................................................... 23 4.2.1 Descripción ............................................................................................................. 23 4.2.2 Navegación............................................................................................................. 26 4.2.3 Interfaz de usuario ................................................................................................ 29 4.2.4 Combate Jugador-Jugador ................................................................................ 38 4.2.5 Tipos de recursos.................................................................................................. 41 XI
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
5 4.2.6 Estructura de la ciudad ........................................................................................ 42 4.2.7 Tipos elementales ................................................................................................. 49 4.2.8 Efectos del clima ................................................................................................... 54 4.2.9 Efecto de la localización ...................................................................................... 56 4.2.10 Ejemplo de mejoras por localización................................................................. 59 4.2.11 Juego offline o sin conexión ............................................................................... 61 Tecnologías ............................................................................................................................. 65 5.1 Resumen de la arquitecura.......................................................................................... 65 5.1.1 Arquitectura de la aplicación............................................................................... 65 5.1.2 Arquitectura de tecnologías ................................................................................ 67 5.2 Android ............................................................................................................................ 69 5.2.1 Activity ..................................................................................................................... 69 5.2.2 Ciclo de vida de una aplicación Android ........................................................... 69 5.2.3 Service ..................................................................................................................... 71 5.3 SQLite............................................................................................................................... 71 5.4 Android vs HTML5......................................................................................................... 71 5.5 Elección de un motor gráfico ...................................................................................... 72 5.6 Andengine ....................................................................................................................... 76 5.6.1 Elementos de Andengine ..................................................................................... 77 5.6.2 Android vs. Andengine.......................................................................................... 78 5.7 XML .................................................................................................................................. 80 5.8 Weather Underground .................................................................................................. 80 5.9 Google Places................................................................................................................. 82 5.10 MySQL ............................................................................................................................. 83 6 Diseño software ..................................................................................................................... 87 6.1 Modelo de dominio........................................................................................................ 87 6.2 Casos de uso .................................................................................................................. 88 XII
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
6.3 7 6.3.1 Shadow Fire............................................................................................................ 92 6.3.2 Servidor ................................................................................................................... 95 6.4 Estructura de paquetes ................................................................................................ 96 6.5 Modelo de datos ............................................................................................................ 98 6.5.1 Tabla TUSER .......................................................................................................... 98 6.5.2 Tabla TBUILDING .................................................................................................. 99 6.5.3 Tabla TFLOOR........................................................................................................ 99 Implementación ................................................................................................................... 103 7.1 8 9 Diagrama de clases....................................................................................................... 92 Shadow Fire ..................................................................................................................103 7.1.1 TheShadowOfFireActivity .................................................................................. 103 7.1.2 Localización ......................................................................................................... 124 7.2 CombatActivity ............................................................................................................. 139 7.3 Servidor ......................................................................................................................... 142 7.3.1 Algoritmo de localización .................................................................................. 142 7.3.2 Combate entre jugadores .................................................................................. 144 Trabajos futuros y conclusiones ...................................................................................... 151 8.1 Trabajos futuros .......................................................................................................... 151 8.2 Conclusiones ................................................................................................................ 152 Estudio económico .............................................................................................................. 157 9.1 Personal......................................................................................................................... 157 9.2 Hardware ....................................................................................................................... 158 9.3 Coste del proyecto....................................................................................................... 161 Anexo A .......................................................................................................................................... 163 Plan de gestión del proyecto ...................................................................................................... 163 1 Resumen del proyecto ........................................................................................................ 165 9.4 Estructura de división del trabajo ............................................................................. 165 XIII
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
9.5 10 Descripción de paquetes de trabajo ........................................................................ 166 Equipo de trabajo .............................................................................................................171 10.1 Organigrama del equipo de trabajo.......................................................................... 171 10.2 Descripción de puestos de trabajo .......................................................................... 172 11 Planificación ..................................................................................................................... 176 Bibliografía ..................................................................................................................................... 179 XIV
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
Índice de ilustraciones
Ilustración 1- Cadena de valor....................................................................................................... 5 Ilustración 2 - Cadena de desarrollo ............................................................................................ 5 Ilustración 3 - World of Dragons ................................................................................................. 15 Ilustración 4 - Pocket Legends .................................................................................................... 16 Ilustración 5 - Star Legends ......................................................................................................... 16 Ilustración 6 - Parrallel Kingdom................................................................................................. 17 Ilustración 7 - Paralell Zombies .................................................................................................. 17 Ilustración 8 - Botón atrás ............................................................................................................ 26 Ilustración 9 - Botón Home .......................................................................................................... 26 Ilustración 10 - Botón Aplicaciones............................................................................................ 26 Ilustración 11 - Navegación ......................................................................................................... 27 Ilustración 12 - HUD ...................................................................................................................... 29 Ilustración 13 - Alta de usuario .................................................................................................. 31 Ilustración 14 - Pantalla Splash .................................................................................................. 32 Ilustración 15 - Panorámica de la ciudad.................................................................................. 33 Ilustración 16 - Interior de edificio .............................................................................................. 34 Ilustración 17 - Menú de nueva planta ...................................................................................... 35 Ilustración 18 - Menú de mejora ................................................................................................. 36 Ilustración 19 - Menú de información ........................................................................................ 37 Ilustración 20 - Combate jugador-Jugador .............................................................................. 38 Ilustración 21 - Colmena .............................................................................................................. 42 Ilustración 22 - Baliza .................................................................................................................... 43 Ilustración 23 - Planta de energía ............................................................................................... 44 Ilustración 24 - Centro de mando ............................................................................................... 45 Ilustración 25 - Hospital ............................................................................................................... 46 Ilustración 26 - Base militar ......................................................................................................... 47 Ilustración 27 - Laboratorio ......................................................................................................... 48 Ilustración 28 – Resumen detecnologías del lado cliente cliente ........................................ 67 Ilustración 29 – Resumen de tecnologías del lado servidor ................................................. 68 Ilustración 30 – Ciclo de vida de Andengine............................................................................. 79 Ilustración 31 - Modelo de dominio............................................................................................ 87 XV
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
Ilustración 32 - Casos de uso ...................................................................................................... 88 Ilustración 33 - Diagrama de clases cliente.............................................................................. 92 Ilustración 34 - Diagrama de clases servidor ........................................................................... 95 Ilustración 35 - Diagrama de paquetes ..................................................................................... 96 Ilustración 36 - Modelo entidad-relación .................................................................................. 98 Ilustración 37 - Localización de jugadores ............................................................................. 143 Ilustración 38 – Top de países con mayor número de Smartphones ............................... 152 Ilustración 39 – Consola OUYA y mando de control OUYA ................................................. 153 Ilustración 40 - Servidor de aplicaciones ................................................................................ 158 Ilustración 41 - Switch ................................................................................................................ 159 Ilustración 42 - Router de salida ............................................................................................... 160 Ilustración 43 - estructura de división del trabajo ................................................................. 166 Ilustración 44 - Equipo de trabajo ............................................................................................. 171 Ilustración 45 - Ejemplo diagrama de quemado de Pivotal Tracker .................................. 177 Índice de tablas
Tabla 1 - Estados de la navegación del UI ................................................................................ 28 Tabla 2 -Diseño de los atributos de un emisario ..................................................................... 39 Tabla 3 - Diseño de los atributos de un ataque ....................................................................... 39 Tabla 4 - Diseño de recursos ....................................................................................................... 41 Tabla 5 - Plantas de la colmena .................................................................................................. 42 Tabla 6 - Plantas de la baliza ....................................................................................................... 43 Tabla 7 - Plantas de la planta de energía .................................................................................. 44 Tabla 8 - Plantas del centro de mando ...................................................................................... 45 Tabla 9 - Plantas del hospital ...................................................................................................... 46 Tabla 10 - Plantas de la base militar .......................................................................................... 47 Tabla 11 - Plantas del laboratorio............................................................................................... 48 Tabla 12 - Diseño de los tipos elementales .............................................................................. 52 Tabla 13 - Efectos de combate ................................................................................................... 53 Tabla 14 - Efectos del clima......................................................................................................... 55 Tabla 15 - Efectos de la localización .......................................................................................... 59 Tabla 16 - Prueba de rendimiento .............................................................................................. 75 XVI
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
Tabla 17 - Tabla TUSER................................................................................................................ 99 Tabla 18 - Tabla TBUILDING ....................................................................................................... 99 Tabla 19 - Tabla TFLOOR ........................................................................................................... 100 Tabla 20 - Horas/Personal ......................................................................................................... 157 Tabla 21 - Especificaciones del servidor ................................................................................. 158 Tabla 22 - especificaciones del switch .................................................................................... 159 Tabla 23 - Especificaciones del router..................................................................................... 160 Tabla 24 - Inventario ................................................................................................................... 161 Tabla 25 - Coste del proyecto.................................................................................................... 161 Tabla 26 - Planificación .............................................................................................................. 176 XVII
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
XVII
I
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMATICA
1
Prólogo
1
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
2
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
1 Prólogo
Es indudable que la industria del videojuego no ha dejado de crecer desde los sus
inicios, allá por la lejana década de los años 80, donde comenzó su andadura para
convertirse en la reina del entretenimiento electrónico [UPC12]. La labor que emprendió
en la popularidad de salones recreativos donde juegos como Pac-man, Mario o Donkey
Kong comenzaban sus andaduras de popularidad en antiguas máquinas arcade, siete
generaciones de consolas después, la parición de Internet, las redes sociales junto al
juego social y la fuerte apuesta de los dispositivos móviles como smart-phones y
tablets por los juegos han terminado de acercar los videojuegos a un público masivo
nunca antes imaginado [CLA11].
Un pasado reciente y único, un presente asombroso y lleno de posibilidades y un futuro
que sólo puede ser calificado de espectacular son las claves que han levantado a los
videojuegos al estatus de “arte” más revolucionario jamás creado por la mano del
hombre.
Es importante entender un videojuego como un todo. Es necesario, preciso e
inexcusable tener una visión de conjunto porque, después de todas las fases de
desarrollo, después de de todo el trabajo realizado, sólo quedará la obra. Es necesario
tener claro que en la realización de un juego se conjugan gran multitud de habilidades
complejas de programación, arte, diseño gráfico, entre muchos otros y que pueden en
ocasiones necesitar rozar el virtuosismo para crear una experiencia de éxito que los
jugadores nunca olvidaran.
Es apasionante comprobar que el videojuego no sólo despierta adrenalina. Tenemos
obras, títulos, que han hecho asomar alguna lágrima e emoción. Otros han descolgado
la mandíbula por asombro y otros han conseguido unir a toda la familia en el salón
alrededor del televisor en una experiencia de canciones, baile, minijuegos, acertijos y
diversión.
Este aspecto social de los juegos es clave, ya que el hecho “social” siempre ha estado
presente en este mundo y ha rodeado a los videojuegos desde siempre. Y en los últimos
tiempos, esta dialéctica la han asumido los creadores, gracias a las virtudes de Internet
y el juego online, para compartir ese ocio digital. La red, como base, hace que consolas,
3
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
ordenadores, smart-phones o tablets expandan los videojuegos exponencialmente.
Internet es el patio de recreo, el sitio donde se han apoyado los dispositivos y el lugar
donde la experiencia crece.
Los videojuegos son sin duda, el octavo arte.
1.1 La industria del videojuego
La industria de videojuegos ha experimentado en los últimos años altas tasas de
crecimiento, principalmente debidas al desarrollo de la computación y capacidad de
procesamiento así como a la dedicación cada vez mayor de capital por parte de las
editoriales y empresas de desarrollo. En la década de 2000, los videojuegos han pasado
a generar más dinero que la del cine y la música juntas, como en el caso de España. La
industria de videojuegos generó 57.600 millones de euros durante 2009 en todo el
mundo.
Al igual que ocurriera con el cine y la televisión, el videojuego ha logrado alcanzar en
apenas medio siglo de historia el estatus de medio artístico, y semejante logro no ha
tenido lugar sin una transformación y evolución constante del concepto mismo de
videojuego y de su aceptación. Nacido como un experimento en el ámbito académico,
logró establecerse como un producto de consumo de masas en tan sólo diez años,
ejerciendo un formidable impacto en las nuevas generaciones que veían los videojuegos
con un novedoso medio audiovisual que les permitiría protagonizar en adelante sus
propias historias.
1.2 El proceso de creación de videojuegos
Cuando se habla del desarrollo de videojuegos, aunque se trate a todos los efectos de
un desarrollo software, difiere en aspectos importantes con una aplicación de software
comercial y tradicional al uso. De nuevo, es necesario explicar las salvedades y puntos
distintivos pues, como se ha indicado anteriormente, se necesitan conjugar multitud de
disciplinas dispares para completar el producto.
4
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
1.2.1
Cadena de valor
La cadena de valor del desarrollo de un videojuego, a primera vista, puede parecerse al
proceso de creación y distribución de software comercial tradicional.
Desarrollo
Edición
Producción
Marketing y
distribución
Ilustración 1- Cadena de valor
Primero el equipo de desarrollo crea el juego. La editorial es la encarga de adaptar el
juego al consumidor, realizando labores como la traducción, doblaje, localización, darlo
a conocer al público. En este punto, la máquina comercial que todos conocemos se
pone en marcha para producir en masa las copias del juego (en caso de distribución en
formato físico) y el juego se distribuye, publicita y vende.
Pero es en el desarrollo donde se encuentran las grandes diferencias y el equipo de
desarrollo toma importancia. Al realizar un zoom al eslabón del equipo de desarrollo
destacan perfiles que no se necesitan en los desarrollos tradicionales [Raposo12].
Ilustración 2 - Cadena de desarrollo
1.2.2
Diseño
La labor del diseñador es definir los aspectos que relacionan al usuario con el juego, que
posteriormente necesitan hacerse realidad a manos de los artistas y los
programadores. Es el encargado de definir cómo van a ser todos los aspectos y
5
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
trasfondo, junto con la manera en la que se juega. Define el estilo de juego y el sistema
de juego, la curva de dificultad, los personajes, la historia, escenarios y los niveles, etc.
Aspectos que tienen un impacto directo en la valoración del juego por parte del usuario,
un mal diseño hace que el juego sea aburrido, tedioso o incluso frustrante, un juego mal
diseñado, es un fracaso total desde el principio.
1.2.3
Arte y banda sonora
Aunque la labor de artistas gráficos y músico es distinta y no suele considerarse como
unificada, dada su condición de artistas se va a tratar como única para la clasificación.
La labor de los artistas es crear los gráficos que tiene el juego, los elementos visuales y
sonoros que el usuario percibe. Este perfil es el más creativo al crear tanto los gráficos
como la música y los efectos de sonido que acompañan el juego. Es necesario tener
una formación artística, una técnica experimentada y muy depurada así como un gran
talento para poder desarrollar bien estos elementos.
1.2.4
Programación
Pone a disposición del diseñador y del artista las herramientas necesarias para realizar
su trabajo en relación con el hardware que va a soportar. Su labor es de unificación,
acopla el trabajo de todo el equipo a la vez que lo hacer al hardware, programa todo el
sistema de juego ideado por el diseñador y añade el trabajo realizado por el artista,
dotándolo de la lógica necesaria para que tenga sentido dentro del juego. Es necesario
tener una formación técnica de sistemas y desarrollo de software, así como
conocimiento de IA, física, matemáticas entre otros para desarrollar correctamente un
juego.
1.2.5
Testing
La labor del testador no es el desarrollo del juego y realmente no forma parte del equipo
de desarrollo. Su trabajo consiste en buscar y depurar el juego, fomentando el feedback
con el equipo para la mejora y corrección de los errores. Para medir se el juego es apto
para el público masivo.
6
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
2
Introducción
7
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
8
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
2 Introducción
En el título del proyecto que tiene entre sus manos, MMORPG location-based for
Android (MMORPG basado en localización) destacan tres aspectos muy distintos, pero
que juntos, tienen un gran potencial [WIKIMM12].
Primero ser un MMORPG. La industria del videojuego es un paradigma de crecimiento
que año tras año demuestra que a los usuarios nos gusta jugar. Seguramente usted
mismo, en mayor o menor medida, sin ser consciente o conscientemente, alguna vez
has jugado a un videojuego. Pero no hay que dejarse engañar, el desarrollo de
videojuegos está plagado de duros inconvenientes: la competencia es altísima, el
conocimiento necesario para su desarrollo es muy elevado, se requieren perfiles muy
distintos para llevarlo a cabo (este aspecto se tratará más adelante con un poco más de
detalle) y los usuarios exigen una calidad extrema en el software que acaban de
adquirir. Sin un gran esfuerzo y dedicación, hacer un buen juego es muy difícil, que
tenga éxito comercial es casi imposible.
Segundo, estar basado en localización. Los dispositivos modernos hace tiempo que
dejaron de ser simples teléfonos para convertirse en autenticas navajas suizas
tecnológicas. Encontrar un Smartphone sin GPS es tarea complicada, y la tendencia
actual del mercado marca que todo el mundo tendrá tarde o temprano uno. La
geolocalización capaz de transformar aplicaciones normales en autenticas maravillas,
elevando la experiencia del usuario a nuevas cotas.
Y tercero, estar desarrollado para Android. Android es la plataforma de software que
está revolucionando el mercado global de telefonía móvil. Se trata de la primera
plataforma móvil de código abierto que ha logrado introducirse en los principales
mercados mundiales. Con un gigante como Google junto con la Open Handset Alliance
(agrupación de más de 50 entidades), en unos pocos años se ha convertido en una
fuerza de cambio, ganándose de paso el respeto de muchos.
9
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
2.1 Motivación
Las motivaciones que han impulsado a desarrollar un MMORPG para Android son muy
diversas, sobre todo si tenemos en cuenta las poderosas implicaciones que la
incorporación de la geolocalización añade al sistema.
¿A quién no le gusta jugar o competir?
Todos disfrutamos jugando, desde un simple juego de niños de indios y vaqueros hasta
los juegos tan complejos que podrían ser el objeto de varios libros. Y todos disfrutamos
compitiendo entre nosotros, deportes de equipo, competiciones, torneos… La lista es
muy extensa, la gran virtud del ocio electrónico y multijugador aúna ambos aspectos a
la perfección.
Es cierto que este aspecto puede levantar muchas controversias y es muy delicado. El
mundo de la competición humana en ocasiones ha vivido épocas muy amargas,
independientemente de si se trata de ocio electrónico o otra forma de competición, ya
sea deportiva, comercial, etc. Aunque no esté contemplado como requisito de pleno
derecho en el proyecto, uno de los objetivos es crear un software que, sin sacrificar
nada de jugabilidad ni diversión, encontrar una mecánica que permita una sana y leal
competencia.
El volumen de la industria del videojuego
Como ya se ha comentado anteriormente, el crecimiento y volumen de la industria del
videojuego es inmenso hoy en día y es indiscutiblemente la forma de ocio electrónico
más consumida. Los potenciales jugadores son miles y es posibles encontrar multitud
de jugadores que se amoldan a perfiles muy distintos a los que es interesante lanzar un
producto con unas cualidades determinas y conseguir cierto éxito.
Reto tecnológico
Programar un videojuego no es tarea fácil. Programar una aplicación que haga un
correcto uso del GPS y permita interactuar a los usuarios entre sí tampoco es tarea
sencilla. Trabajar para una nueva plataforma aun en desarrollo y desconocida que
necesita un gran estudio previo y que le va a requerir un aprendizaje desde cero para el
10
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
correcto desarrollo en la aplicación. Todo junto triplica la dificultad del proyecto y
supone un reto muy gratificante a superar.
Falta de madurez en los MMORPG para Smartphones.
Aunque los MMORPG son muy conocidos y jugados para plataformas más clásicas
como el PC o los navegadores, aun queda un largo recorrido para alcanzar productos
innovadores y atractivos para el consumidor de smart-phones y tablets. Con este
proyecto este se quiere proponer algunas nuevas ideas nuevas e ideas al mundo de la
jugabilidad en los MMRPG, especialmente en el uso de la localización, que sean
originales o muy poco vistas y explotadas.
2.2 Objetivos
El objetivo por tanto es la creación de un juego completo para la plataforma móvil
Android, haciendo uso de todas las capacidades de localización que expandan la
experiencia del jugador y soportar todas las capacidades necesarias para incorporar
elementos jugables y creíbles que modifiquen la jugabilidad adecuadamente.
El juego será capaz de gestionar todos los elementos disponibles para el jugador,
permitiendo una compleja posibilidad de crear todos los elementos disponibles y
gestionando el momento en que se puedan crear, permitiendo consultar el estado de su
progreso tanto para un elemento en concreto como en general, actualizar aquellos
elementos que puedan o precise el jugador cambiar y eliminar aquellos que ya no
necesita.
También será necesaria la creación de un servidor centralizado que unifique la tarea de
gestionar las posiciones relativas de los jugadores en tiempo real y determinar si se
encuentran en una posición cercana. Será el servidor el encargado también de la
gestión de los enfrentamientos entre los jugadores, incluyendo la lógica y reglas del
combate y enfrentamientos.
Resumiendo con una estructura más ordenada y desglosados por categorías, los
objetivos que forman parte del proyecto son:
11
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
2.2.1
»
»
»
Motor gráfico Andengine
‐
Diseñar e implementar la UI
‐
Gestionar los recursos gráficos de la UI
Un solo jugador
‐
Gestión y evolución completa de la base.
‐
Gestión completa de los recursos.
‐
Gestión y evolución de las unidades para el enfrentamiento.
Geolocalización
‐
‐
‐
‐
»
Desarrollo para Android
Medir la localización geográfica del jugador.
Medir correctamente la climatología de la posición del jugador.
Adquirir información relevante sobre el lugar donde se encuentre el jugador.
Aplicar las características de la geolocalización al juego
Juego Multijugador
‐ Combate Jugador/Jugador
2.2.2
»
Geolocalización
‐
‐
»
Desarrollo para el servidor
Controlar y medir en tiempo real la posición relativa a jugadores cercanos
Gestionar las interacciones entre jugadores cercanos
Juego Multijugador
‐ Gestión del combate Jugador/Jugador
12
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
3
Estado del arte
13
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
3 Estado del arte
El mundo de los MMORPG es enorme y basto., especialmente si nos olvidamos de la
cuestión de localización, aunque esto no quiere decir que en los últimos años hayan
surgido jugos que explotan la localización de los dispositivos móviles, ya existen
algunos MMORPG basados en localización para Android. Pero es un mercado que aún
no ha podido romper las directrices de sus hermanos mayores para PC/consola, juegos
menores para navegador o redes sociales ya asentados. Los juegos que están
disponibles beben directamente de ellos sin aportar nada nuevo, y es un segmento de
mercado que necesita ideas y directrices nuevas que puedan desviar la tendencia actual
y sean atractivos para el usuario. Especialmente con las características únicas de las
pantallas de los dispositivos móviles, donde la mayoría requieren el uso de controles
táctiles de la pantalla y están en continuo movimiento con su dueño.
Estas características que pretenden aplicarse sin un estudio a las plataformas móviles
son producto de la inercia del mercado y los desarrolladores que insisten en trasladar
las bondades de los juegos ya asentados en el mercado directamente a las plataformas
móviles sin un estudio adecuado para adaptar los juegos a las características que estas
plataformas necesitan realmente. Para entender un poco mejor estos pequeños
problemas, es necesario realizar un ligero repaso histórico de los títulos que han
marcado el camino a seguir para entender cuáles son las fórmulas ya establecidas y
asentadas, desde los primeros y básicos MMORPG, hasta su evolución hasta la
MMORPG basados en localización que se pueden encontrar hoy día y las ideas que
intentan trasladarse a los juegos para móviles directamente.
3.1 Nacimiento de los MMORPG
El primer MMORPG comercial reconocido fue basado en texto fue Islands of Kesmai,
publicado en 1984. Pero la popularidad de estos juegos se logró con el primer MMORPG
gráfico, Neverwinter Nights, que nació en AOL en 1991 y se mantuvo hasta 1997.
The Realm Online fue uno de los primeros MMORPGs con verdadero éxito comercial.
Publicado por Sierra Online en 1996, incluía un motor gráfico de dos dimensiones y un
sistema de niveles de personajes y un sistema de combate por turnos inspirados
14
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
en Dungeons & Dragons. No obstante a Ultima Online publicado en 1997, se le acredita
la popularización del género.
El 23 de noviembre de 2004 salió a la venta World of Warcraft, creado por la compañía
Blizzard. Este juego ha batido récords en su género, ya que ha superado la increíble cifra
de 13 millones de jugadores. Destaca por su facilidad de uso, su interactividad y por los
escenarios gigantescos sin cargas que conforman un universo continuo. Hasta ahora,
World of Warcraft es el juego con más suscriptores de la historia [NEOT09].
3.2 MMORPG para Android
Los primeros MMROPGs para Android beben directamente de la vertiente iniciada con
World of Warcraft, donde jugadores controlan un avatar dentro de un mundo en una
vista de tercera persona explorando el entorno, combatiendo contra varios monstruos y
jugadores, completando misiones e interactuando con personajes no jugadores u otros
jugadores, mientras evolucionan las habilidades y atributos de su avatar, medido en
forma de niveles.
Cabe destacar que estos primeros MMORPG no hacen uso de las capacidades de
localización del usuario ni lo extrapolan a la jugabilidad ni capacidad del juego. La
cercanía de los jugadores dentro del juego únicamente es medida por los movimientos
dentro del propio juego.
Algunos ejemplos de Android de esta vertiente son:
World of Dragons
Desarrollado por CorsairBand.
Ambientado en el mundo de fantasía y basado en la
época medieval, dónde dragones, orcos, elfos,
humanos y más especies conviven en constante
batalla para dominar sobre las demás especies. Con
Ilustración 3 - World of Dragons
un nivel gráficos poco espectaculares, que no hacen
uso de muchos elementos 3D.
15
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Pokect Legends
Desarrollado por Spacetime Studio.
Ambientado en el mundo de fantasía y basado en la época
medieval con gráficos estilo cartoon. En el juego encarnamos a
un personaje con una categoría, oficio o estilo de lucha que lo
diferencia. El objetivo es cumplir misiones en solitario o
formando un grupo de jugadores (popularmente conocido
Ilustración 4 - Pocket
Legends
como raid), mejorando a nuestro personaje a medida que
subimos de nivel ganando experiencia.
Star Legends
Desarrollado por Spacetime Studio.
Siguiendo las bases de Pocket Legends, Star
Legends cambia la temática medieval por la
Ilustración 5 - Star Legends
exploración y aventuras en un mundo creado
siguiendo las bases de la ciencia ficción pura. Dentro
de Star Legends podemos escoger un avatar con una categoría que marcan su estilo de
juego. El objetivo es cumplir misiones en solitario o formando un grupo de jugadores sin
dejar de evolucionar nuestro personaje, consiguiendo capacidades que nos hagan más
competente para el cumplimiento de misiones más complejas o de mayor dificultad.
3.3 Incorporación de la localización a los
MMORPG
Comercialmente ya existen juegos que aúnan en la localización del jugador con los
MMRRPG de corte clásico. Estos juegos son de reciente aparición y aún son una
vertiente muy poco explotada. El principal uso de que hacen estos juegos de la
localización es seguir la posición del jugador y permitir la conquista de las diferentes
zonas en las que se encuentra.
Algunos ejemplos comerciales de juegos ya disponibles son:
16
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Parallel Kingdom
Desarrollado por PerBlue.
Parallel Kingdom fue el primer RPG basado en
localización para iOS u Android. El juego se
desarrolla en un mundo paralelo conocido como
Ilustración 6 - Parrallel Kingdom
Parallel Kingdom donde los usuarios reclaman
sus territorios viajando físicamente en el mundo
real a partir del dispositivo GPS o invitando a nuevos jugadores para que puedan viajar a
nuevos territorios que no pueden alcanzar físicamente.
Parallel Zombies
Desarrollado por PerBlue.
En Parallel Zombies, los jugadores toman las calles en una
lucha por su supervivencia en un mundo post-apocalíptico en
el que los zombies invaden la tierra. Gracias a la tecnología
GPS, los zombies serán capaces (de manera figurada) de
acercarse a las zonas donde habitan los jugadores e incluso
golpear y entrar en sus propias casas. El componente
Ilustración 7 - Paralell
Zombies
MMORPG permite que todos los jugadores cercanos entre sí
colaboren en las labores de exterminio y supervivencia y
ayudarse mutuamente para aumentar las posibilidades de
vivir.
17
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
18
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4
Diseño del juego
19
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4 Diseño del juego
En el desarrollo de videojuegos, el documento de diseño es una herramienta esencial
que requiere una atención especial antes de comenzar con el verdadero desarrollo, pues
en este documento se recogen todos los detalles relativos al diseño del juego [SION10].
Se especifican elementos como la jugabilidad, historia, personajes, posibilidades,
entorno, ambientación etc. Es la versión tradicional de la Especificación de Requisitos
Software pero especializado y orientado al mundo del videojuego.
En un documento de diseño se comienza dando simples pinceladas sobre el juego que
se va a modelar hasta llegar al máximo nivel de detalle, definiendo controles, pantallas
de juego y mecánicas concretas. En él se plasman todas y cada una de las ideas que
aparecerán en el juego.
Cuales son utilidades de un documento de diseño.
Concretar ideas
Las ideas que surgen para el desarrollo de un videojuego son muy prolíficas y en
ocasiones incluso contradictorias o pueden desembocar a la larga un problema que
puede hacer que el proyecto acabe en fracaso, sobre todo si se da en fases muy
avanzadas del desarrollo. Un documento de diseño sirve para plasmar y concretar ese
pequeño caos en un papel donde se aclarare las ideas y asegurándose que son capaces
de funcionar unidas en un juego. Así mismo, podremos discernir de forma muy
preliminar las buenas ideas de las malas.
Estar en el mismo barco
No es extraño diferentes integrantes del mismo equipo de trabajo no tengan claros los
objetivos y características del juego que va a desarrollarse e incluso tengan ideas
totalmente opuestas. Durante la elaboración del GDD se deberán detectar los puntos de
desacuerdo y se podrán zanjar los problemas. De esta manera nos aseguramos de que
todos los compañeros están en el mismo barco y tienen un objetivo común.
20
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Preparar el desarrollo
Como en cualquier proceso de construcción de software, la fase de ingeniería nos
prepara para la implementación. Gracias al GDD nos embarcaremos en etapas
posteriores conociendo el desarrollo y las tecnologías a las que el equipo debe
enfrentarse. En algunos casos estas especificaciones permiten adaptar el desarrollo a
los conocimientos del equipo o incluso a las búsquedas de integrantes que se adapten a
las necesidades.
Comunicación
Tanto en desarrollos comerciales como el que nos ocupa en este momento la
comunicación con el exterior es importante. En el caso de un juego comercial, el equipo
querrá conseguir la financiación de una editora. Con el documento de diseño adecuado
puede conseguirse que personas y compañías ajenas al proyecto comprenda la idea
que pretende desarrollarse, se compruebe que es un proyecto serio y estudiado y
accedan a colaborar.
4.1 Tipos de jugadores
Antes de especificar cómo va a ser el sistema de juego, a definir la experiencia del
jugador al usar el software. Existen dos perfiles de usuario distintos que demandan
juegos totalmente diferentes.
Casual gamer o jugador casual
Se caracteriza por dedicar tiempo o interés en jugar muy limitado. Puede ser cualquier
persona que muestre un interés pasajero por los videojuegos. Los videojuegos que
buscan atraer a jugadores tienden a presentar reglas simples y una jugabilidad fácil que
gente de cualquier edad o con cualquier nivel de habilidad pueda disfrutar.
Generalmente se inclinará por la videoconsola o videojuego más económico, más fácil
de utilizar y jugar, o simplemente que esté de moda. Comúnmente no tiene mucho
conocimiento sobre la construcción, calidad u otros temas más específicos de los
videojuegos. Son los jugadores más abundantes, pero los menos fieles.
21
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Hardcore gamer o jugador extremo
Se interesa principalmente por videojuegos más complejos, difíciles de manejar y
dominar que realmente presenten un verdadero reto, dedicando una gran cantidad de
horas jugando para conocer y explotar todos los aspectos del juego. Dominando e
interesándose por términos y temas más específicos. Son mucho más críticos y menos
abundantes, pero la dedicación que profesan les hace ser consumidores más fieles.
El diseño del juego va a orientarse principalmente a jugadores extremos.
22
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4.2 Shadow Fire
Shadow Fire es un juego multijugador masivo online basada en localización. La primera
versión del juego pretende realizarse para Android como proyecto de fin de carrera de la
Universidad Pontificia Comillas.
Para un futuro no se descarta la posibilidad del desarrollo de una nueva versión del
juego que se asiente en las bases marcadas por Shadow Fire, aumentando sus
capacidades e incorporando nuevos elementos en la jugabilidad o mejoras generales.
Igualmente, dadas las características del desarrollo del juego para Android, también es
posible realizar en un futuro un port a otras plataformas móviles como Iphone/IOS o M
Windows Mobile. Con la integración total de todos los jugadores en una única
experiencia de juego global.
4.2.1
Descripción
Shadow Fire pone al jugador bajo el control de toda una ciudad que no se encuentra
físicamente en el mundo real, si no en un mundo paralelo similar a la tierra conocida.
Desde el momento de la creación de esta ciudad, la ciudad queda vinculada con un
vínculo único al jugador, por lo que se ve afectada de una manera directa por los
movimientos del jugador, de las condiciones climáticas de donde se encuentre y de los
lugares que visite.
La ciudad está compuesta por un total de siete edificios con características y objetivos
distintos. En el interior de estos edificios se pueden construir un total de cinco plantas y
un total de 35 puntos estructurales a gastar. Estas plantas además pueden tener un
nivel entre 1 y 5. Cuanto mayor sea el nivel, un mayor beneficio aportaran al conjunto.
Cualquier subida de que decida hacer en una planta, ya sea elevando el nivel de una ya
construida como creando una nueva, reducirán consumirán el total de puntos
estructurales del edificio.
Por la limitación de los puntos estructurales y el límite de plantas nunca se podrán tener
cinco plantas de nivel 5 en un mismo edificio., la cantidad de plantas disponibles por
edificio es muy superior a las cinco. El objetivo de este sistema es forzar al jugador a
buscar una combinación exitosa que complemente a la perfección sus necesidades
23
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
para el enfrentamiento contra otros jugadores que maximicen sus posibilidades de
obtener la victoria a la vez que se busca optimizar los beneficios por clima y lugar.
La construcción o subida de nivel de las plantas además conllevarán un gasto extra de
recursos. En total existen cinco tipos diferentes de recursos: ciencia, material de
construcción, energía, comida y población. Todos los recursos disponen de un medidor
de cantidad/tiempo que se sumarán al total de los recursos automáticamente y de
máximo que nunca podrá ser superado independientemente de la cantidad/tiempo que
se gane de un recurso, salvo que se destinen plantas específicamente a subir el
máximo.
A los beneficios obtenidos por las plantas hay que sumar beneficios obtenidos por
climatología y lugar. Tanto por el clima como por el lugar donde se encuentre un
jugador se obtienen unos beneficios prefijados. Estos beneficios pueden ser muy
dispares, como una mejora en la cantidad/tiempo que se gana de un recurso o incluso
una mejora porcentual en un tipo elemental o una mejora en el potencial de ataque.
Encontrarse cerca de otro jugador tendrá efector devastadores en los beneficios que se
dan por lugar y clima, pues estos beneficios se repartirán a partes iguales entre los
jugadores. Es decir, que si dos jugadores coinciden en un mismo lugar, ambos recibirán
únicamente el 50% de la mejora; en caso de coincidir 10, cada uno recibirá sólo un 10%.
La única forma de mejorar este porcentaje es retando a un jugador cercano a un
enfrentamiento. El jugador que salga victorioso del enfrentamiento obtendrá una
cantidad del porcentaje de su oponente, aumentando los beneficios del ganador y
reduciendo los del perdedor.
El jugador dispondrá de un emisario para los enfrentamientos. Cuando un jugador reta o
es retado por otro en combate, serán estos emisarios el encargado de luchar por ellos.
Los jugadores, gracias a la experiencia ganada en combate por estos emisarios, podrán
hacerlos subir de nivel ganará un monto de puntos a repartir entre sus características.
Cada emisario dispondrá además de uno o varios tipos elementales a los que es afín y
un conjunto de ataques a realizar en combate. Igual que ocurre con los edificios, el total
de puntos es insuficiente para elevar todas las características a su máximo y el número
de ataques es superior al total que se pueden aprender. De nuevo el objetivo de este
sistema es forzar al jugador a buscar una combinación exitosa que complemente a la
24
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
perfección sus necesidades para el enfrentamiento contra otros jugadores que
maximicen sus posibilidades de obtener la victoria.
Resumiendo, el juego consta de:
Gestión de una base
La gestión de una base será la forma básica de juego para un solo jugador. El jugador
deberá gestionar unos recursos que le permitan mantener y avanzar una base,
epicentro de toda su actividad en el juego.
BTC (Based-turn Combat o combate basado en turnos)
Será el sistema de interacción para el enfrentamiento o combate entre jugadores y entre
el jugador y la máquina o inteligencia artificial. En este sistema, un personaje o grupo
controlado por cada combatiente actúan por turnos no simultáneos en la lucha por
derrotar a su rival.
Geolocalización
El rol que va a desempeñar la localización GPS dentro del juego va a ser diversa. La
ubicación del jugador determina las condiciones del juego, si el jugador se encuentra en
su casa, su personaje también estará en su casa. Establecerá la cercanía de dos
jugadores próximos físicamente, que en el juego estarán en la misma posición relativa,
si dos jugadores se cruzan por la calle, en el juego sus personajes también se estarán
cruzando. Y por último establecerá las condiciones climatológicas del juego iguales al
lugar en donde se encuentra el jugador, si en la vida real llueve, en el juego también.
25
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4.2.2
Navegación
Botones de navegación
A continuación se muestra los usos de los botones de navegación estándar de los
sistemas Android en Shadow Fire. Estos botones táctiles y digitales pueden encontrarse
en la sección inferior de la pantalla del smart-phones y disponibles únicamente a partir
de la versión 4.0 Ice Cream Sandwitch de Android.
Atrás
Ilustración 8 - Botón atrás
Usado en la navegación permite volver a la pantalla o estado anterior. En caso de
encontrarse en la panorámica de la ciudad, se cierra la aplicación.
Home
Ilustración 9 - Botón Home
Pulsar el botón Home devolverá automáticamente a la pantalla de inicio del sistema
Android, colocando la aplicación en estado resume. En caso de volver a la aplicación, se
iniciará en el mismo punto en se pulso el botón Home.
Aplicaciones
Ilustración 10 - Botón Aplicaciones
No tiene uso en Shadow Fire.
26
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Esquema de navegación
A continuación se muestra el esquema de navegación de la interfaz ciudad.
Ilustración 11 - Navegación
27
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Descripción de los estados de la navegación.
Estado Nombre
Acciones
0
Nuevo
Estado accesible únicamente si se inicia la aplicación sin estar
usuario
previamente dado de alta. Se accederá a (1) al completar
correctamente el registro.
1
Splash
Estado de transito automático. Una vez completada la carga de
datos, automáticamente se accederá a (2).
2
Ciudad
Estado donde se muestra la panorámica de la ciudad. En caso
de pulsar un edificio, se accede a (3).
En caso de pulsar atrás, se finaliza la aplicación.
3
Interior
En este estado se muestra el interior del edificio accedido.
edificio
Pulsando una planta construida, se accede a (6).
Pulsando una planta vacía, se accede (5).
Pulsar atrás vuelve a (2).
4
Cambio nivel
En este estado se muestra las opciones de cambio de nivel de
una planta.
Pulsar cualquier posibilidad, tanto de subida o bajada, devuelve
el estado a (3).
Pulsar atrás vuelve a (3).
5
Nueva
En este estado se muestras las posibles plantas a las que se
planta
puede optar para ocupar la planta vacía.
Pulsar cualquier planta devuelve el estado a (3).
Pulsar atrás vuelve a (3).
6
Información
En cualquier estado de la aplicación, pulsar el botón de
información completa accede al estado (6).
Pulsar atrás vuelve a (2).
Tabla 1 - Estados de la navegación del UI
28
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4.2.3
Interfaz de usuario
A continuación se explica detalladamente todos los interfaces y pantallas que el usuario
podrá encontrar a lo largo de su experiencia de juego.
HUD
HUD son las siglas en inglés de Head-Up Display, elemento del interfaz siempre visible y
superpuesto a las demás interfaces. Su objetivo es mostrar información relevante al
usuario y mejorar su experiencia.
Recursos
Viento
Temperatura
Botón Información
Ilustración 12 - HUD
Recursos
Los recursos se encuentran en la sección superior del HUD de la UI. Siempre se dispone
de la información relativa a la cantidad de recursos disponibles por el jugador. En ella se
puede encontrar la información relativa a los cinco recursos disponibles y sus valores
actuales.
29
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Viento
Muestra el indicador de la velocidad del viento. La velocidad del viento
es uno de los indicativos que permiten establecer las mejoras por
clima que consigue el usuario.
Temperatura
Muestra el indicador de la temperatura de la posición del jugador. La
velocidad del viento es uno de los indicativos que permiten establecer
las mejoras por clima que consigue el usuario.
Botón Información
Último elemento que se puede encontrar en la sección lateral derecha
del HUD de la UI. Pulsando este botón puede accederse a la
información completa sobre la posición relativa a clima y lugar, junto a
toda la información disponible sobre jugadores cercanos a esa
posición.
30
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Interfaz de nuevo usuario
Previo a poder jugar, un nuevo usuario debe darse de alta correctamente en el servidor,
es interesante antes de entrar en detalle sobre los interfaces de usuario del juego,
estudiemos la UI de nuevo usuario.
Nombre
Email
Botón enviar al servidor
Ilustración 13 - Alta de usuario
Nombre
Caja de texto reservada al nombre del usuario. El nombre de usuario deberá ser
exclusivo y el servidor no permitirá continuar con el juego repitiendo el proceso de alta
hasta que le jugador no haya introducido un valor válido y único.
Email
El email forma parte de la forma de comunicación básica y directa con el jugador. No
tiene un uso directo en la jugabilidad del juego.
31
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Interfaz Splash
Una pantalla splash es una imagen simple donde se presenta el logo del juego, la
portada del mismo y una barra de progreso. El objetivo de la pantalla splash es enseñar
algo más que una pantalla en negro al jugador mientras en segundo plano se cargan
todos los recursos necesarios. Es importante remarcar que la carga de recursos, sobre
todo los recursos gráficos, es vital para el correcto rendimiento del juego.
Logo y portada
del juego
Barra de progreso
Ilustración 14 - Pantalla Splash
Logo y portada
Simplemente se muestra en grande el logo y la imagen de portada del juego.
Barra de progreso
Barra de progreso que indica a medida que se completa el nivel de carga de todos los
recursos que precisa el juego. Al completarse se indica que todo se ha cargado
correctamente y se puede continuar con el juego.
32
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Interfaz de usuario en modo ciudad
El elemento principal de la interfaz de usuario es la visión general de la ciudad. En ella se
muestran todos los edificios a los que el usuario puede acceder. Tocando cada edificio
podemos acceder a su interior.
Los edificios son el elemento principal de Shadow Fire y en ellos pueden construirse las
plantas que nos permitirán conseguir mayores ventajas y beneficios en el desarrollo del
jugador.
A continuación se muestra una captura con la vista principal de la ciudad:
Scroll
Edificios
Ilustración 15 - Panorámica de la ciudad
Edificios
Sprites de los siete edificios que conforman la ciudad. En caso de tocar uno, se puede
acceder a su interior.
33
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Interfaz interior de un edificio
Al acceder al interior de un edificio se presentan las cinco plantas. Las plantas pueden
presentar un estado de construida o disponibles para su construcción.
Plantas disponible
Planta construida
Ilustración 16 - Interior de edificio
Planta construida
Se muestra la planta construida en esa sección del edifico. Al pulsar en ella se accede al
menú de actualización de nivel de la planta.
Planta en vacía
En caso de pulsar una planta vacía, se accede al menú de construcción de una nueva
planta para ser alojada en esa posición.
34
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Interfaz construcción de una nueva planta
Scroll
Planta a construir
Información sobre
la planta
Ilustración 17 - Menú de nueva planta
Planta a construir
Imagen de la planta que puede ser construida en el lugar. En caso de no poder ser
construida por falta de recursos, los elementos aparcarán en rojo.
Información sobre la planta
Información relativa a la construcción de la planta. Esta información consta de
información sobre los beneficios de construcción de la planta, el tiempo total para
completarse la construcción y el coste total de recursos necesarios.
35
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Interfaz de mejora de plantas
Subida de nivel
Bajada de nivel
Ilustración 18 - Menú de mejora
Subida de nivel
Muestra la información relevante a la subida de nivel de la planta. En total se muestra la
información de mejora aplicada, tiempo de construcción necesario y coste de la mejora.
Bajada de nivel
Muestra la información relevante a la bajada de nivel de la planta. En total se muestra la
información de la disminución aplicada, tiempo de deconstrucción necesario y coste de
la bajada.
36
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Interfaz de información completa
Posición
Clima
Lugar
Mejoras aplicadas
Bajada de nivel
Jugadores
cercanos
Ilustración 19 - Menú de información
Posición
Muestra la posición del jugador, mostrando la ciudad y país en la que se encuentra. Solo
es informativa y no tiene una aplicación directa en el juego.
Clima
Muestra la información de clima en la localización del jugador. En total se muestra el
clima, la temperatura, la velocidad y dirección del viento. Está información si tiene una
aplicación directa en la ganancia de recursos del juego.
Lugar
Muestra la información de lugar en la localización del jugador. En total se muestra
nombre y las características del lugar. Está información si tiene una aplicación directa
en la ganancia de recursos del juego.
37
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Mejoras aplicadas
Las mejoras aplicadas son el compendio completo de las ganancias extras obtenidas
por localización. Porcentaje de ganancias indica el monto que se está ganando del total
posible. Este porcentaje desciende del 100% al encontrarse cercano a otro jugador y
varía al derrotar o ser derrotado en un enfrentamiento.
Jugadores Cercanos
Muestra la información relativa a los jugadores cercanos a la posición del jugador. Se
indica el nombre como el nivel del jugador. Factor de victoria en una métrica que indica
las veces que se es mejor que ese jugador. Un valor por inferior a 1 indica que ese
jugador pierde recursos en nuestro favor, un valor superior indica que ese jugador pierde
recursos a favor el jugador.
4.2.4
Combate Jugador-Jugador
Esta vista no se muestra en el ciclo de vida por su característica especial, únicamente
puede ser accedida si un jugador es cercano al terminal que ejecuta la aplicación. Su
vista es la siguiente.
Vida
Ataques
Emisario
Ilustración 20 - Combate jugador-Jugador
El sistema de combate está basado en turnos, similar a los turnos de los juegos clásicos
como el ajedrez. Cada jugador enviará a su emisario para enfrentarlo con el de su
oponente,
actuará en su turno eligiendo uno de los cuatro ataques disponibles
intentando reducir por completo la barra de vida del emisario oponente. El lado derecho
corresponde al jugador mientras que el lado izquierdo corresponde con el rival.
38
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Emisario
Un emisario es una entidad abstracta que representa al jugador en caso de
enfrentamiento con otro jugador, el cual usará su propio emisario. Los atributos que
perfilan al emisario son:
Nombre
Descripción
Vida
Vida total que puede resistir antes de caer
Fuerza
Fuerza con la que golpea, a mayor fuerza, mayor daño.
Defensa
Capacidad de resistir golpes. A mayor defensa, menos vida se pierde.
Velocidad
Determina el orden de acción. Una mayor velocidad permite atacar antes
que el oponente. Además determina la capacidad de esquivar un ataque.
Tipo
Tipo elemental al que es afín el Emisario, que tendrá una importante
elemental
carga estratégica de cara al juego.
Ataque1
Ataque disponible para realizar contra el oponente. Cada ataque dispone
a su vez de un tipo elemental al que pertenece.
Ataque2
Ataque disponible para realizar contra el oponente. Cada ataque dispone
a su vez de un tipo elemental al que pertenece.
Ataque3
Ataque disponible para realizar contra el oponente. Cada ataque dispone
a su vez de un tipo elemental al que pertenece.
Ataque4
Ataque disponible para realizar contra el oponente. Cada ataque dispone
a su vez de un tipo elemental al que pertenece.
Tabla 2 -Diseño de los atributos de un emisario
Cada ataque dispone a su vez de los siguientes atributos.
Nombre
Descripción
Tipo
Tipo elemental al que es afín el ataque.
Fuerza
Fuerza con la que golpea, a mayor fuerza, mayor daño.
Velocidad Determina como se ve afectada la velocidad del emisario al realizar este
ataque.
Precisión
Capacidad de acertar al oponente con él.
Tabla 3 - Diseño de los atributos de un ataque
39
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Caida de la conexión durante un enfrentamiento
Durante el enfrentameitneo es necesario que mabos jugadores dispongan de una
conexión estable y continua a lo largo de todo el combate. En caso de producirse la
desconexión de uno de los dos jugadores, inditintamente se asumirá que el ganador del
enfrentamiento es el jugador que ha permanecido conectado al servidor, obteniendo la
parte proporcional de los beneficios de la batalla conseguidas hata ese momento.
Por contrapartida, el jugador que ha perdido la conexión se considerará desconectado
del sistema y parsará a considerarse un jugador no conectado, no obteniendo beneficio
alguno de la batalla. Cuando vuelva a estar disponible, se le dará de nuevo de alta en el
sistema de localización del servidor.
40
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4.2.5
Tipos de recursos
Pueden encontrarse un total de cinco tipos de recursos distintos.
La población mide el índice de densidad de habitantes de la
Población
ciudad. Cualquier acción que requiera la acción humana para
llevarse a cabo (como la construcción o la investigación),
requerirá la dedicación de parte de la población inactiva.
La Ciencia mide de forma abstracta el conocimiento y
Ciencia
avances tecnológicos capaces de ser desplegados por tu
ciudad. Cualquier mejora compleja requerirá invertir parte de
la capacidad de ciencia.
La Construcción mide de forma abstracta la disponibilidad de
materiales capaces de ser desplegados por tu ciudad para la
Construcción construcción o mejora de estructuras. Cualquier cambio en
una estructura o edificio necesitará una inversión de este
recurso.
La energía será un recurso necesario para mantener la
actividad industrial y la calidad de vida de la ciudad. Nuevas
Energía
estructuras requerirán un consumo estable y continuo de
energía. Si no puede dedicarse la energía suficiente, parte o la
totalidad de los edificios dejarán de funcionar.
La comida es un recurso necesario para poder mantener la
Comida
actividad humana en la ciudad. A mayor población o
actividades complejas asignadas a los habitantes, mayor
demanda de comida. La falta de este recurso provocará la
disminución progresiva de la población.
Tabla 4 - Diseño de recursos
41
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4.2.6
Estructura de la ciudad
A continuación se detallan todas las estructuras que pueden ser construidas.
Colmena
Ilustración 21 - Colmena
Puntos estructurales: 35
La colmena es un edificio destinado al bienestar de la ciudad. A rasgos generales se
centra en el alojamiento en su interior de plantas que mejoran notablemente los
recursos relativos a la población y a mejorar las condiciones que les afecten
directamente. Es uno de los edificios más importante y básico para tener niveles
aceptables de población elevados y estables.
Al iniciar el juego, la colmena consta por defecto de la planta Residencia a nivel 1
construida.
A continuación se detallan todas las plantas que pueden ser construidas en el interior de
la colmena.
Residencia
Sala del aclimatador
Centro deportivo
Cárcel
Restaurante
Paneles solares
Almacén
Cámara frigorífica
Ferretería
Grandes almacenes
Depósito de agua
Centro de ocio
Contenedores de reciclaje
Tabla 5 - Plantas de la colmena
42
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Baliza
Ilustración 22 - Baliza
Puntos estructurales: 30
La colmena es un edificio destinado a la comunicación de la ciudad. Contiene una
cantidad de plantas especializadas en el comercio exterior y a la mejora de todas las
condiciones que puedan ser obtenidas de fuentes externas, incluso de la localización.
No dispone de plantas construidas al inicio del juego.
A continuación se detallan todas las plantas que pueden ser construidas en el interior de
la baliza.
Centro de comunicaciones
Centro especial
Modulo lunar
Camera de comercio
Cañón solar
Escáner inter-planetario
Escáner inter-dimensional
Aduana
Controlador espacio-temporal
Sala del vórtice
Portal a dimensión vacía
Mercado negro
Cañón abre-portales
Tabla 6 - Plantas de la baliza
43
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Planta de energía
Ilustración 23 - Planta de energía
Puntos estructurales: 45
La planta de energía es un edificio especializado en la generación, eficiencia en la
producción, uso y almacenaje de la energía de la ciudad. Es uno de los edificios pilar del
juego y sin una clara estrategia sobre los recursos que facilita no se puede avanzar
mucho en el desarrollo.
Al iniciar el juego, la planta de energía dispone la planta sala de baterías construida a
nivel 1.
A continuación se detallan todas las plantas que pueden ser construidas en el interior de
la planta de energía.
Sala de baterías
Núcleo radiactivo
Control de residuos
Reactor fisión
Combustibles fósiles
Combustibles fósiles mixta
Fabrica de derivados
Energía renovable
Central solar
Central climatológica
Biocombustible
Tabla 7 - Plantas de la planta de energía
44
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Centro de mando
Ilustración 24 - Centro de mando
Puntos estructurales: 40
El centro de mando es el centro de la ciudad. En edificio central desde el que se coordina
y controla el resto de los edificios. Es uno de los edificios más difíciles de definir y
construir adecuadamente por que las plantas que deben ser alojadas en su interior
dependen exclusivamente de la configuración de los demás edificios para ser rentables
e eficientes.
Dispone de la planta centro de mando a nivel 1 construida desde el inicio.
A continuación se detallan todas las plantas que pueden ser construidas en el interior
del centro de mando.
Arquitecto
Centro de gestión
Inteligencia
Centro de verificación
Control de calidad
Despacho oval
Gabinete de gobierno
Juzgados
Ministerio
Centro de formación
Tabla 8 - Plantas del centro de mando
45
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Hospital
Ilustración 25 - Hospital
Puntos estructurales: 30
El hospital es el edificio centrado en la salud de la ciudad y de los emisarios. Las labores
que se ejercen en su interior van desde el tratamiento directo de las dolencias que
puedan surgir como tratamientos paliativos o preventivos. Una buena estrategia con el
hospital puede desembocar en una ciudad virtualmente duradera y sana, casi imposible
de debilitar.
No dispone de plantas construidas al inicio del juego.
A continuación se detallan todas las plantas que pueden ser construidas en el interior
del hospital.
Medicina nuclear
Depuradora
Control de plagas
Control de enfermedades
Primeros auxilios
Prenatal
Cuidados intensivos
Análisis clínico
Centro psiquiátrico
Farmacia
Tabla 9 - Plantas del hospital
46
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Base militar
Ilustración 26 - Base militar
Puntos estructurales: 35
El rol que juega la base militar dentro de la ciudad es claro y contundente, ampliar la
capacidad destructiva y ofensiva que se pose con la intención de derrotar al rival de una
forma más contundente posible. Aunque algunas mejoras pueden ser muy sutiles en
contraposición de las armas de destrucción masiva más evidentes.
No dispone de plantas construidas al inicio del juego.
A continuación se detallan todas las plantas que pueden ser construidas en el interior de
la base militar.
Armas de fuego
Misiles nucleares
Oficina de seguridad
Oficina de reclutamiento
Almacén de armas
Cuerpo especial
Cuerpo de agentes secretos
Unidad de explosivos
Brigada biológica
Ingeniería militar
Tabla 10 - Plantas de la base militar
47
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Laboratorio
Ilustración 27 - Laboratorio
Puntos estructurales: 35
El laboratorio es el edificio más complejo de configurar de todos los que son accesibles.
Toda planta que pueda ser construida en el laboratorio sirve como apoyo y soporte para
otras previamente edificadas, no siendo útil si no se planifica correctamente su uso.
Además dispone de otro gran inconveniente, es imposible abarcar todas las mejoras
que ofrece siendo necesario elegir que descartar. Pero sin duda, la potenciación que da
el laboratorio no puede ser comparada con ninguna otra edición.
No dispone de plantas construidas al inicio del juego.
A continuación se detallan todas las plantas que pueden ser construidas en el interior de
la base militar.
Laboratorio nuclear
Laboratorio biológico
Laboratorio genético
Farmacología
Laboratorio químico
Laboratorio físico
Acelerador de partículas
Centro de calculo
Granja transgénica
Ingeniería
Tabla 11 - Plantas del laboratorio
48
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4.2.7
Tipos elementales
Los tipos elementales son estados afines de los emisarios con los que pueden
desarrollar poderes, tener cierta afinidad o debilidad y que permite clasificarlos dentro
de un tipo u otro. De la misma forma los ataques que pueden aprender los emisarios se
clasifican según el tipo elemental al que pertenecen.
Tipos disponibles
Biológico
El tipo biológico produce emisarios con unos atributos de ataque
y precisión muy equilibrados y una velocidad muy alta al carecer
de una capa protectora o de elementos adicionales que les
obstaculicen el movimiento. No obstante, su defensa es bastante
justa.
Los ataques biológicos se caracterizan por ser muy poco
potentes en primeros estadios del combate, pero a largo plazo,
son capaces de infectar al oponente, causando un daño masivo y
acumulativo cada vez mayor.
Corrosivo
El tipo corrosivo produce emisario muy lentos y aparatosos, pero
capaces de hacer destrozos en su rival si también es lento y muy
pesado, acabando rápidamente con su defensa.
Los ataques corrosivos se caracterizan por ser capaces de
destruir cualquier tipo de defensa y contra enemigo sin defensa
son capaces de causar estragos. No obstante, carecen de
velocidad y precisión elevadas.
Corte
Los emisarios de tipo corte se especializan en la defensa débil
compensada con una gran velocidad. Son capaces de realizar
múltiples ataques consecutivos sobre un mismo rival sin ser
golpeados.
49
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Los ataques de tipo corte son muy rápidos y precisos. Capaces
de provocar daño masivo con una gran cantidad de ataques
menores, pero les cuesta atravesar una defensa férrea.
Muerte
Los emisarios de tipo muerte están especializados en golpear al
rival duramente y sin piedad, siendo capaces de acabar el
combate de un único golpe fulmínate. Pero al no esperar una
repuesta, no están preparados para defenderse, siendo su coraza
nula.
Los ataques de tipo muerte son muy arriesgados, a todo o nada.
Es poco probable que acierten y requieren mucha precisión, pero
un solo golpe puede ser suficiente para acabar el combate.
Eléctrico
Los emisarios eléctricos son capaces de moverse a grandes
velocidades, las mayores que se pueden encontrar, siendo
además muy equilibrados en ataque y defensa. Pero pueden
tener problemas si el clima no les acompaña.
Los ataques de tipo eléctrico se caracterizan por ser directos y
brutales. Pero es fácil desviarlos se dispone de la defensa
adecuada y un clima propicio.
Fuego
Los emisarios de tipo fuego tienen una gran capacidad de
obtener ventajas de las temperaturas elevadas o incluso del sol.
Junto al tipo hielo, son los que más se ven afectados por un clima
adverso. Pero en general, son muy equilibrados con un ataque
ligeramente superior.
Los ataques de tipo fuego son muy equilibrados en precisión y
velocidad, con un extra de fuerza que puede ser ampliamente
mejorado con un clima extremo de sol y altas temperaturas, son
ataques para el verano y el buen tiempo.
50
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Hielo
Los emisarios de tipo hielo tienen una gran capacidad de obtener
ventajas de las temperaturas muy bajas o incluso de la nieve.
Junto al tipo fuego, son los que más se ven afectados por un
clima adverso. Pero en general, son muy equilibrados con una
defensa ligeramente superior.
Los ataques de tipo hielo son muy equilibrados en precisión y
velocidad, con un extra de fuerza que puede ser ampliamente
mejorado con un clima extremo de nieve y temperaturas por
debajo de los 10º, son ataques para el invierno y el mal tiempo.
Nuclear
Los
emisarios
de
tipo
nuclear
son
muy
inestables
e
impredecibles, la mayoría de las veces se causarán daño a sí
mismos, arrastrando al rival con ellos.
Los ataques nucleares son un peligro tanto para el rival como
para su ejecutor. Dañan a todos por igual de manera brutal y no
suelen fallar nunca. Son muy arriesgados si no se dispone una
defensa adecuada.
Reciclaje
Los emisarios de tipo reciclaje son muy conservadores. Poseen
una cantidad de vida y defensa altísimos y son capaces de
regenerar su vida o aumentar su defensa aun más. Por lo demás,
no destacan en nada y el resto de sus atributos son bajos o muy
bajos. Son jugadores de fondo.
Los ataques de este tipo son los únicos capaces de defender al
usuario que los emplea hasta el punto de regenerar las partes
que ha perdido casi por completo.
Toxico
Los emisarios de tipo tóxico son únicos en su especie. Se
51
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
especializan en causar un daño al rival capaz de matarlo a largo
plazo sin que pueda hacer nada para evitarlo.
Los ataques de tipo tóxico envenena al oponente causándole la
pérdida total de la vida con el tiempo. Un combate contra ataques
de tipo toxico es una contrarreloj donde el tiempo que se dispone
para acabar con el rival se limita cada vez más.
Tabla 12 - Diseño de los tipos elementales
52
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Efectos en combate
A la hora de realizar un ataque, se aplicará un bonificador dependiendo de la relación del
tipo elemental del ataque realizado y el tipo elemental del emisario.
1x Si tanto el ataque como el emisario no comparten el mismo tipo
1.5x Si tanto el ataque como el emisario comparten el mismo tipo
A la hora de soportar un ataque, cada tipo de movimiento aplica además un
multiplicador al bonificar final del ataque de acuerdo a la siguiente tabla.
Tipo del oponente
Tipo de atacante
-
x0.5
-
x0.5
-
X2
-
-
x2
-
X2
-
X2
X0.5
-
-
-
-
X0.5
-
X2
-
-
-
X0.5
X0.5
-
X2
X2
-
X2
-
-
-
-
-
X0.5
-
-
X0.5
-
-
X2
X2
X0.5
X0.5
X0.5
-
-
-
-
X2
X0.5
-
-
X0.5
X2
X0.5
-
-
X0.5
X2
X0.5
-
-
X2
X0.5
-
-
X2
-
-
-
X2
X0.5
-
-
X0.5
X2
X0.5
X0.5
-
-
-
X2
-
-
X0.5
-
X2
-
X0.5
-
-
X2
-
X2
-
-
-
Tabla 13 - Efectos de combate
53
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4.2.8
Efectos del clima
A continuación se detallan todos los posibles estados del clima y todos los efectos que
suponen para el juego.
Mejora
Inconvenientes
Aumenta en
Disminuye en
Energía 5%
Comida 5%
Patches of Fog
Ciencia 15%
Construcción 5%
Biológico 5%
Fuego 5%
Hielo 5%
Tóxico 15%
Energía 10%
Comida 10%
Shallow Fog
Ciencia 10%
Construcción 10%
Biológico 5%
Fuego 10%
Hielo 5%
Tóxico 15%
Energía 15%
Partial Fog
Comida 5%
Construcción 15%
Ciencia 15%
Fuego 10%
Tóxico 15%
Energía 15%
Comida 5%
Patches of Fog
Construcción 20%
Ciencia 15%
Corrosivo 10%
Fuego 10%
Tóxico 15%
Población 15%
Overcast
Energía5%
Hielo 5%
Comida 5%
Corrosivo 5%
Fuego 5%
Biológico 5%
54
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Población 5%
Clear
Energía 20%
Comida 10%
Hielo 5%
Fuego 5%
Biológico 5%
Población 5%
Partly Cloudy
Energía10%
Hielo 10%
Comida 10%
Corrosivo 5%
Fuego 10%
Población 5%
Mostly Cloudy
Energía10%
Comida 10%
Fuego 10%
Energía 10%
Tóxico 5%
Eléctrico 5%
Energía15%
Scattered Clouds
Comida 10%
Hielo 5%
Fuego 5%
Corrosivo 5%
Nuclear 10%
Energía 10%
Small Hail
Hielo 15%
Fuego 5%
Población 5%
Muerte 10%
Construcción 5%
Ciencia 5%
Energía5%
Funnel Cloud
Comida 10%
Fuego 5%
Muerte 5%
Biológico 5%
Hielo 10%
Energía15%
Unknown
Comida 10%
Población 5%
Precipitation
Muerte 5%
Fuego 15%
Biológico 10%
Hielo 10%
Tabla 14 - Efectos del clima
55
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4.2.9
Efecto de la localización
Los lugares se clasifican por un conjunto de tipos atendiendo a sus características y un
mismo lugar puede tener incluso varios tipo distintos. Los beneficios e inconvenientes
de un lugar vienen marcados por estos tipos.
A continuación se detallan todos los posibles estados de lugar y todos los efectos que
suponen para el juego.
Mejora
Inconvenientes
Aumenta en
Disminuye en
Contabilidad
Energía 10%
Banco
Comida 10%
Casino
Ciencia 10%
Contratista
Construcción 15%
Eléctrico 10%
Agencia de seguros
Hielo 5%
Reciclable 5%
Abogado
Fuego 5%
Finanzas
Nuclear 15%
Cajero automático
Tóxico 5%
Aeropuerto
Gasolinera
Tienda de bicicletas
Estación de autobuses
Venta de automóviles
Alquiler de coches
Aparcamiento
Aparcamiento para
caravanas
Estación de metro
Parada de taxi
Energía 10%
Comida 10%
Ciencia 10%
Biológico 5%
Construcción 10%
Corte 10%
Fuego 10%
Eléctrico 20%
Hielo 5%
Tóxico 15%
Estación de tren
Agencia de viajes
56
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Reparación de coches
Lavado de coches
Empresa de mudanzas
Lavandería
Cerrajero
Techador
Zapatería
Ayuntamiento
Embajada
Oficina municipal
Político
Corte de justicia
Oficina postal
Población 5%
Ciencia 10%
Construcción 5%
Ciencia 15%
Eléctrico 10%
Reciclable 5%
Muerte 10%
Energía 15%
Comida 5%
Ciencia 15%
Construcción 20%
Corrosivo 10%
Fuego 10%
Tóxico 15%
Código geográfico
Parque de atracciones
Acuario
Galería de arte
Gimnasio
Biblioteca
Museo
Parque
Centro comercial
Balneario
Población 15%
Energía 15%
Comida 15%
Hielo 5%
Fuego 5%
Corrosivo 5%
Biológico 5%
Estadio
Bolera
Camping
Restaurante
Zoo
57
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Librería
Tienda de ropa
Grandes almacenes
Tienda de electrónica
Establecimiento
Florista
Tienda de muebles
Ferretería
Población 5%
Energía 10%
Ciencia 10%
Construcción 5%
Muerte 10%
Energía 5%
Corte 10%
Corrosivo 10%
Joyería
Tienda de animales
Tienda de vinos y licores
Tienda
Población 15%
Comida
Comida 15%
Ultramarinos o
Biológico 10%
supermercado
Corte 10%
Dispositivos de
Corrosivo 5%
almacenamiento
Toxico 5%
Construcción 5%
Energía 5%
Tienda de barrio
Panadería
Bar
Salón de belleza
Cafetería
Peluquería
Alojamiento
Videoclub
Cine
Club nocturno
Pintor
Población 5%
Energía10%
Hielo 10%
Comida 10%
Corrosivo 5%
Fuego 10%
Fontanero
Policía
Colegio
Universidad
58
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Población 5%
Electricista
Energía10%
Bomberos
Comida 10%
Tóxico 5%
Funeraria
Eléctrico 5%
Fuego 5%
Comida a domicilio
Muerte 5%
Hielo 5%
Comida para llevar
Toxico 5%
Corrosivo 5%
Doctor
Población 10%
Dentista
Comida 15%
Salud
Muerte 10%
Ciencia 10%
Hospital
Corrosivo 5%
Reciclable 5%
Farmacia
Fisioterapeuta
Toxico 5%
Nuclear 10%
Atención veterinaria
Cementerio
Iglesia
Comida 10%
Templo hindú
Biológico 10%
Población 5%
Tienda de artículos para
Nuclear15%
Muerte 10%
el hogar
Reciclable 5%
Ciencia 10%
Mezquita
Toxico 5%
Lugar de culto
Sinagoga
Tabla 15 - Efectos de la localización
4.2.10
Ejemplo de mejoras por localización
Imaginemos el caso de un jugador que tras levantarse tremprano necesita realizar unas
gestiones importantes en el banco antes de comenzar sus obligaciones. Esa mañana ha
amanecido con sol, pero con nubes que amenazan ocasionalmente.
Sintetizando, el juego ha detectado que el jugador se encuentra en ese momento en un
banco y que además el tiempo marca sol parcialmente nublado, por lo tanto, el
cómputo total de las mejoras que le reportaría este hecho, partiendo de los recursos y
de los atributos para los tipos elementales que su ciudad le genera en ese momento.
59
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Total
Inconveniestes
Mejoras
Motivo
Base
Energía 10%
Energía 200
Población 80
Recursos
Comida 10%
Banco
Ciencia 250
Parcial.
nublado
Hielo 100
Fuego 50
Tipos
elementales
Nuclear 220
Banco
Reciclable 25
Corrosivo 100
N/A
Construc. 52
Comida 10%
Hielo 95
Fuego 5%
Eléctrico 10%
Fuego 57
Nuclear 15%
Reciclable 5%
Nuclear 253
Tóxico 5%
Parcial.
nublado
Población 84
Ciencia 275
Población 5%
Energía10%
Energía 240
Comida 120
Hielo 5%
Toxico 50
Electrico 25
N/A
Construc. 15%
Comida 100
Construc. 50
Ciencia 10%
Tóxico 52
Hielo 10%
Fuego 10%
Corrosivo 5%
Electrico 22
Reciclable 24
Corrosivo 95
Para el jugador es altamente beneficicio estar esa mañana nublada en el banco,
especialmente si nos fijamos en la gran cantidad de energía, ciencia y en menor medida
de comida que va ha obtener. Si permanece unas horas en el banco, va a poder disfrutar
de una gran reserva cuando disponga de tiempo para dedicar al juego.
Por otra parte, su estrategia de cara a otros jugadores se basa en ser muy agresivo
gracias a un emisario de tipo nuclear con implacables atques de tipo nuclear tambien,
tipo que recibe una importante mejora esa mañana que elevará la dureza de los
ataques. Combirtiendo al jugador en un gran rival a batir para el resto de oponentes que
se puedan encontrar el el banco y dispotarle las mejoras.
60
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
4.2.11
Juego offline o sin conexión
Adicionalmente de todo lo mencionado, el juego permitirá al jugador acceder al jeugo
sin conexión a la red, pemitiendo que no existan trabas deribadas al no poder manteren
la conectividad activa indefinidamente. Este echo conyeba importantes cambios en la
jubilidad y es importante que los jugadores lo tengan presente en todo memento,
incluso como una opción más a sopesar de cara a la estragia que desen desarrollar
según sus intereses, sopesando los pros y contras que acarrea no disponer de ella.
La consecuencia diracta más clara que determina la no conexión es la imposibilidad de
comunicación con el servidor. Este hecho por sí sólo no supone en problema, salvo que
el jugador no se haya dado de alta en el servidor todavía como jugador. Para poder
iniciar una partida será requisito indipensable una primera conexión para el alta en el
sistema, incluso aunque posteriormente el jugador no vuelva nunca más a jugar con
conexión.
La segunda consecuencia es la perdida de las mejoras que la localización proporciona a
los recursos y a los tipos elementales, dejando como única posibilidad la obtención de
los recursos que únicamente proporcione su ciudad.
Como tercer inconveniente, al no estar comunicado con el servidor, no se considera que
el jugador se encuentre en ese momento activo, no pudiendo relacionarse ni retar a
otros jugadores. De este echo se deriba la única ventaja real de jugar sin conexión,
auque el jugador no puede retar a otros jugadores, el mismo tampoco puede ser retado
por ellos, librándose del enfretamiento. Este detalle tiene unas consecuencias
estratégicas importantes que merecen ser sopesadas a favor de la perdida de recuroso
en muchos casos. Por ejemplo, ¿Qué ocurriría si el jugador no es lo suficientemente
poderoso como para acabar con sus oponentes en combate? Tal vez la mejor solución
es una retirada a tiempo desconectando el disponitivo de la red y ceder todos los
recursos para conseguir que no le ataquen.
61
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
62
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
5
Tecnologías
63
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
64
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
5 Tecnologías
Las aplicaciones Android se desarrollan habitualmente en el lenguaje Java haciendo
uso del Android Software Development Kit (Android SDK) [GOAAPI12]. Todo lo que se
necesita es un conocimiento aceptable de Java y estar en posesión del kit de desarrollo
de software provisto por Google que puede ser descargado gratuitamente.
Aunque la mayoría de las aplicaciones están escritas en Java, no hay una máquina
virtual Java en la plataforma. El bytecode Java no es ejecutado, sino que primero se
compila en un ejecutable Dalvik y corre en la Máquina Virtual Dalvik. Dalvik es una
máquina virtual especializada, diseñada específicamente para Android y optimizada
para dispositivos móviles que funcionan con batería y que tienen memoria y procesador
limitados [Ableson11].
Para el desarrollo de un videojuego se necesitan además Framworks y APIs adicionales
que faciliten algunas tereas e incorporen clases con funcionalidades de complejidad
elevada, permitiendo la abstracción de ciertos aspectos de la programación más a bajo
nivel. En concreto estos Frameworks son el motor gráfico Andengine, que permite la
abstracción de OpenGL entre otros, y las APIs de Google Places y Weather underground
para la obtención de datos de localización [ANDAPI12].
5.1 Resumen de la arquitecura
A continuación se detallan las arquitecturas de la aplicación y la arquitectura de todas
las tecnologías de las que hace uso la aplicacación.
5.1.1
Arquitectura de la aplicación
Como se ha remarcado con anterioridad, la arquitectura que sigue la aplicación es la
estructura clásica cliente/servidor donde el servidor es capaz de en tiempo real
mantener las localizaciones relativas de los jugadores los unos respecto a los otros.
No obstante, el juego también permite el juego offline. Admitiendo jugadores que no
dispongan de conexión y no estén conectados con el servidor.
En resumen la arquitectura de la aplicación pemmite los siguientes casos.
65
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Jugador
D
Jugador
A
Servidor
Jugador
C
Jugador
B
Jugador A
Jugador conectado al servidor que además se encuentra muy cercano al Jugador B. el
servidor ha estiamdo que ambos se encuentran cercanos entre si, se disputan los
recursos de la zona y además pueden combatir entre ellos.
Jugador B
Mismo caso que Jugador A.
Jugador C
Jugador que se encuentra conectado al servidor y está recibiendo beneficios por
localización, pero no se encuentra cercano a ningún otro jugador, por lo que no tiene
que combatir con otros jugadores por los recursos.
Jugador D
Jugador que no se encuentra conectado al servidor y por lo tento sin acceso a la red. No
recibe mejoras por localización ni otros jugadores pueden interaccionar con él.
66
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
5.1.2
Arquitectura de tecnologías
Tecnologías empleadas en la constructución del sistema cliente/servidor.
Cliente
Tecnologías usadas en cliente.
Ilustración 28 – Resumen detecnologías del lado cliente cliente
User Interface o Interfaz de usuario - Andengine
Motor gráfico encargado del dibujado de los gráficos y creación del interfaz de usuario.
Se encarga de gestionar todo aquel elemento que el jugador puede ver e interecional
con él.
Lógica - Java
El nucleo de la lógica de la placiación esta desarrollado con el leguaje de programación
Java, leguaje estándar de programación para Android.
Capa de acceso a datos – SQLite
El sistema gestor de base de datos incluido de forma nativa en la API de Android es
SQLite, un potente y ligero sistema gestor de base de datos que se empleará para las
necesidades de persistencia de datos en el lado cliente.
67
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Conexión – 3G/WiFi
La comunicación con el exterior se realizará a través de una conexión de datos 3G o
WiFi indistintamente
Servidor
Tecnologías usadas en servidor.
Ilustración 29 – Resumen de tecnologías del lado servidor
Lógica – Java
El nucleo de la lógica de la placiación servidor está desarrollado con el leguaje de
programación Java. Del mismo modo que en la aplicación cliente, pemitiendo la
unificación y reutilización de código.
Capa de acceso a datos – MySql
El sistema gestor de base de datos usado en el servidor es MySql, un potente sistema
gestor de base de datos que se empleará para las necesidades de persistencia de datos
en el lado servidor.
Esquema de comunicación – XML
La tecnología empleada para la comunicación entre cliente y servidor esta parseada en
documentos XML que se intercambiarán entre ambas.
68
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
5.2 Android
Antes de entrar en detalle, veamos las bases de Android usadas en el proyecto.
Gracias a la Android SDK, se dispone de una API completa y muy avanzada que facilita
la labor de acceso a todos los recursos que nos ofrece el sistema. En este apartado nos
centraremos en los aspectos concretos de la Android SDK para poder entender más
adelante ciertas peculiaridades del proyecto a desarrollar, en especial lo referente a la
incorporación de Andengine al conjunto.
5.2.1
Activity
Toda aplicación que necesite mostrar algún elemento al usuario necesita tener al
menos una clase que herede de la clase Activity. Al extender una la clase con Activity se
consigue la abstracción del ciclo de vida de la aplicación. Los métodos que Activity
aportan permiten al programador controlar los estados de la aplicación, pero sin poder
controlar directamente el ciclo de vida, como llevar la aplicación a ejecución, mostrarla
al usuario o dejarla en segundo plano, que se delega en el sistema operativo.
5.2.2
Ciclo de vida de una aplicación Android
Todo proceso en Android se incluye en una pila de ejecución. Cuando el usuario
interacciona con el sistema, las actividades se crean y se detienen en un orden concreto
mientras el sistema inicia y detiene procesos [IPCCVA12].
69
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Android proporciona diferentes estados en los que se puede encontrar una Activity, los
más habituales son:
onCreate()
Ciclo de vida completo
onRestart()
Fase de visibilidad
onStart()
Fase de primer plano
onResume()
onPause()
onStop()
onDestroy()
OnCreate()
Se invoca al crear la actividad. Aquí se realiza la configuración. También brinda acceso a
cualquier estado almacenado previamente.
OnRestart()
Se invoca se reinicia la actividad, si sigue en la pila, en lugar de iniciar una nueva.
onStart()
Se invoca cuando la actividad es visible en pantalla para el usuario.
onResume()
Se invoca cuando la actividad comienza a interactuar con el usuario. Siempre es
invocado.
onPause()
Se invoca al detener la aplicación o al reclamar la CPU u otros recursos. En este método
se guarda el estado para que al reiniciar una actividad pueda comenzar con el mismo
estado con el que acabó.
onStop()
70
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Se invoca para detener la actividad y pasar a una fase de invisibilidad.
onDestroy()
Se invoca al eliminar una actividad de la memoria del sistema.
5.2.3
Service
Si se necesita la ejecución de un proceso con un tiempo de vida prolongado y en
segundo plano, debe incluirse en un Service. Al igual que Activity, Service es una clase
proporcionada por el motor en tiempo de ejecución de Android y es necesario extender.
La gran diferencia entre Service y Activity es que a diferencia de la segunda, Service
carece de interfaz de usuario.
Se ha decidido usar dos clases Service para facilitar a la aplicación la obtención de
datos de localización y la comunicación desde/hacia el servidor sin una bajada notable
del rendimiento, dejando toda la potencia del sistema libre para ejecutar el juego.
5.3 SQLite
SQLite es un sistema gestor de base de datos del tipo relacional y ligero que Android
incorpora de forma nativa. Aunque no dispone de todas las funciones de los productos
de base de datos cliente/servidor comerciales, ofrece todo lo necesario para el
almacenamiento local de datos, a la vez que da un rápido acceso a la capa de datos
[SQLIT12].
5.4 Android vs HTML5
Existe una alternativa al desarrollo de una aplicación nativa Android para el juego que no
se ha mencionado con anterioridad, realizar íntegramente la aplicación sobre HTML5 y
ser accedida desde el navegador del dispositivo móvil. La tecnología HTML5 unido a
CCS3 aporta todo lo necesario para el desarrollo completo de la aplicación, además de
existir frameworks muy maduros en la rama de desarrollo de videojuegos.
HTML5 incorpora además una ventaja clara, el soporte sobre el que se ejecuta puede
cambiar sin problemas, no teniendo ningún problema para ampliar el alcance de la
aplicación a dispositivos más allá de Android e incluso, más allá de un dispositivo móvil.
71
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
No obstante, esta ventaja oculta una gran desventaja. No todos los dispositivos usados
por el usuario para acceder a la aplicación disponen de la facilidad de movimiento de un
dispositivo móvil, no teniendo sentido se ejecución en determinados sistemas, como
ordenadores portátiles en menor medida o en ordenadores de sobremesa en mayor
medida.
Pero el verdadero problema que aporta HTML5 es la necesidad de conexión continua e
ininterrumpida de la aplicación. Una gran cantidad de lógica puede ser ejecutada en el
cliente hasta el punto de no necesitar lógica en el servidor mediante el uso de
Javascript, pero la base de datos siempre se encontrará en el servidor, obligando por
tanto a la conexión ininterrumpida antes citada para iniciar la aplicación o para
cualquier cambio en los datos, siendo imposible el juego sin conexión. Como
anteriormente se dejó constancia, el juego debe permitir el juego sin conexión al jugador
sin ningún tipo de traba, siendo esto imposible con la tecnología HTML5.
Por este último motivo, se descarta totalmente el uso de HTML5 para el desarrollo.
5.5 Elección de un motor gráfico
Es interesante, antes de comenzar la implementación del juego, dedicar un tiempo de
estudio previo a comparar todas las posibilidades de elección para un motor gráfico que
facilite la labor de programación. La API de Android cargar una animación es muy fácil,
hacerlo de forma que se pueda controlar el número de repeticiones y el frame en el que
se encuentra la animación ya no lo es, entre otras facilidades importantes.
La oferta de motores open source es bastante amplia y llena de posibilidades A
continuación se listan los motores gráficos con una tasa de actividad, mantenimiento y
uso elevados.
AndEngine
Motor 2D con OpenGL libre bajo licencia LGPL desarrollado por Nicolas Gramlich. Entre
sus múltiples características se encuentran:
»
Optimización para Android y compatibilidad con la versión 1.6 en la versión
GLES1 y 2.2 en la versión GLES2.
72
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
»
Modo SpitScreen.
»
Multijugador en red.
»
Texturas vectoriales (en SVG).
»
Live-Wallpapers.
»
Posibilidad de MuiltTouch.
»
Motor de físicas con Box2D
»
Posibilidad de implementar realidad aumentada.
libGDX
Motor gráfico multiplataforma (Linux, OSX, Windows, Android) para 32 y 64 bits y que
entre sus principales características cuenta con la posibilidad de desarrollar para
sistemas de escritorio y después esa misma aplicación es fácilmente portada a Android
Distribuido con licencia Apache 2.0 entre el resto de sus características cabe destacar:
»
Shaders, vertex y soporte de OpenGL 1.0, 1.1 y 2.0 (solo en Android 2.0).
»
Sistema de partículas.
»
Carga de sonido en mp3, OGG y waw.
»
Carga de mapas TMX de MapEditor.
»
Soporte para ratones, teclados y touch.
»
Soporte del compas, acelerómetro y vibrador.
»
Soporte de eventos remotos, por ejemplo para interactuar con un PC.
»
Físicas con Box2D.
»
Incluye editor de partículas, generador de fuentes y empaquetador de texturas.
jPCT
Motor 3D multiplataforma de escritorio que cuenta además con una versión específica
para Android. Publicado bajo una licencia propia que permite sus redistribución. Entre
sus características:
»
Carga de modelos 3DS, OBJ, MD2, ASC y XML.
»
Animación por frames o por esqueleto.
»
Sistema de iluminación y efectos.
»
Construcción de primitivas.
73
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
»
Detección de colisiones.
»
Completo control de cámaras.
Forget3D
Framework 3D multiplataforma basado en OpenGL ES que permite realizar aplicaciones
para Android, Win32, WinCE. Distribuido bajo licencia GNU GPL v2 entre sus
características cuenta con:
»
Compatible con Android 2.0.
»
Carga de modelos MS3D, G3D (Glest) y MD2.
»
Texturas de 8 y 24 bits.
»
Manejo de escenas.
»
Control de cámaras.
»
Sistema de iluminación.
»
Soporte de fuentes.
Catcake
Motor 3D multiplataforma compatible con Linux, Android y Windows creado con la idea
de tener una pequeña curva de aprendizaje y un buen rendimiento. Está publicado bajo
licencia MIT. Entre las características que destacan de este motor se encuentran:
»
Carga de modelos 3DS.
»
Manejo de transparencias e iluminación.
»
Manejo de fuentes (TTF, TTC, OTF).
»
Monitor de depuración en tiempo real.
»
Creación automática de modelos 3D a partir de imágenes 2D.
»
Detección de colisiones.
e3roid
Motor 2D basado en OpenGL para Android 2.1 o superior bajo la nueva licencia BSD.
Con un ciclo de desarrollo bástate rápido cuenta con las siguientes características:
»
Manejo de capas y sprites.
»
Renderizado de texto.
»
Entrada analógica\digital con soporte para multi touch.
74
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
»
Físicas con Box2D.
»
Carga de mapas TMX.
»
Emulación de teclado.
»
Consola de depuración.
»
Incorpora intérpretes para scripts en Lua y JavaScript.
»
Manejo de sonidos.
De todos los motores mostrados, todos tienen unas características magnificas y
potencia suficiente para el desarrollo de un juego muy potente. Pero de entre todos
destacan en especial dos, Andengine y e3roid. Es importante destacar que el juego que
va a desarrollarse únicamente debe estar soportado por la plataforma Android y sólo
son necesario gráfico 2D sin mayor ostentación de potencia gráfica, no siendo
necesarias lógica de partículas ni iluminación.
Para determinar que motor gráfico se adapta menor a las necesidades del proyecto, se
realizará una prueba de rendimiento basada en frames. Esta prueba consiste en
presentar una cantidad cada vez mayor de pequeñas partículas en movimiento, dejando
al motor gráfico la posibilidad de ajustas el frame rate. Ejecutado sobre un Galaxy Nexus
con Android 4.0.4 (Ice Cream).
Andengine e3roid
FPS (1 Sprite)
58
52
FPS (50 Sprites)
60
46
FPS (100 Sprites)
36
42
FPS (500 Sprites)
25
35
Tabla 16 - Prueba de rendimiento
Comparando el rendimiento y las características de ambas, podemos observar que
AndEngine puede sufrir una caída de rendimiento en función de los objetos del juego
algo que e3roid parece que es capaz de mantener constante, aunque para nuestro
propósito ambos serian validos.
En definitiva cualquier opción sería válida, pero se decanta a favor de AndEngine por la
cantidad de código de ejemplos, actividad en sus foros, tamaño de la comunidad de
desarrollo y su modularidad ya que existen extensiones que permiten una evolución
posterior del juego con un mínimo impacto en el desarrollo.
75
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
»
AndEngine Live-Wallpaper Extension
»
AndEngine .MOD-Player Extension
»
AndEngine Multiplayer Extension
»
AndEngine MultiTouch Extension
»
AndEngine Physics Box2D Extension
»
AndEngine Augmented-Reality Extension
5.6 Andengine
AndEngine es un motor de videojuegos 2D para Android. En el momento de desarrollar
un videojuego hay características como los Sprites o la utilización de físicas que pueden
llegar a ser complejas de desarrollar. El uso de frameworks o librerías para estos puntos
benefician enormemente a conseguir un desarrollo más rápido y permite enfocar los
recursos en otras áreas también importantes.
Una de las características que más resalta de AndEngine es que es de código abierto y
que en sí, se trata de una implementación 2D de OpenGL para Android por lo que se usa
puramente el lenguaje Java.
Andengine se encuentra en su segunda versión GLES2, liberada en Diciembre de 2011 y
que a lo largo de 2012 se ha asentado en una versión estable y potente [GLES12].
Algunas mejoras incluidas en GLES2 que afectan al proyecto son [ANDF10]:
»
Se requiere como mínimo una versión Froyo (Android 2.2) o superior, soportado
por más del 89% de todos los dispositivos.
»
Mejora de rendimiento VertexBufferObject y un buffering más rápido.
»
Incorporación de LowMemoryVertexBufferObject con un uso de memoria un
50% menor que HighPerformanceVertexBufferObject.
»
Entity-Skewing añadido a la rotación, escala y traslación.
»
Nueva claseBitmapFont
»
Fuentes pre-renderizadas.
»
La compresión de texturas soportada por todos los dispositivos.
»
Incorporación de la clase TextureOptions
»
Nuevos DataTypes: Quadtree, LRUCache, UncoloredSprite / DiamondSprite,
TextureRegion rotation, TiledTextureRegion
76
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
»
MultiTouchExtension native para AndEngine.
»
Extension para la AugmentedReality.
»
Nuevas ScreenOrientations: SENSOR_LANDSCAPE, SENSOR_PORTRAIT para
Ginger Bread (Android 2.3) y superior.
»
Rotación de pantalla sin llamadas a los métodos de ciclo de vida.
5.6.1
Elementos de Andengine
Andengine provee de su propia API, poniendo a disposición del desarrollo una serie de
clases que incluyen la lógica necesaria para realizar las acciones comunes en los
videojuegos. Estas clases son:
BaseGameActivity
El BaseGameActivity es la raíz del juego, que contiene el motor y crea la vista donde se
va a dibujar todo. Hay siempre exactamente un solo Engine por cada BaseGameActivity.
BaseGameActivy facilita también la labor de carga y creación de los recursos así como
la especificación de las opciones y características necesarias.
BaseGameActivity hereda de Activity y al igual que ocurre con esta, es necesario
extender una clase con ella para poder mostrar gráficos. Además BaseGameActivity
incluye todos los métodos necesarios para la correcta configuración de los elementos a
usar.
Engine
El Engine es el motor interno del juego, se encarga de ir dibujando en pantalla y
actualizando objetos en la escena, que contiene todo el contenido que tu juego lleva.
Normalmente hay una escena por Engine, pero esta lógica puede extenderse para
implementar múltiples escenas con una única carga de recursos unificada.
IResolutionPolicy
Una implementación de IResolutionPolicy interface es parte del EngineOptions. Abstrae
la resolución del terminal, permitiendo trabajar para una resolución y AndEngine se
encarga de ajustar al resto.
Camera
77
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Un objeto Camera define el rectángulo visible de la escena actual que no tiene porqué
ser la escena completa. Normalmente hay una cámara por escena. Hay subclases
específicas que permiten hacer zoom y mover la cámara suavemente.
Scene
La clase Scene es el contenedor para todos los objetos que se van a dibujar en la
escena. Una escena puede tener Layers, que son capas para ordenar objetos. Hay
subclases
de
la
Scene
como
CameraScene/HUD/MenuScene
que
tienen
comportamientos específicos.
Entity
Una entidad es un objeto que puede ser dibujado, como Imágenes, rectángulos, Texto,
Líneas. Una entidad tiene posición/rotación/zoom/color...
Texture
Una textura es una imagen que se guarda en memoria. En Android, las imágenes deben
ser una potencia de 2.
TextureRegion
Una TextureRegion define un rectángulo en una imagen. Las TextureRegion se usan por
Sprites para usar una imagen grande en la que guardamos muchas imágenes menores.
PhysicsConnector
Motor de físicas integrado en el Engine
5.6.2
Android vs. Andengine
Si bien Andengine administra toda una API que facilita las labores de programación, si
es necesario tener en cuenta que BaseGameActivity incorpora una serie de métodos
propios que modifican ligeramente el ciclo de vida de la actividad, haciendo la clase uso
interno de los métodos clásicos de Activity antes mencionados, por lo que no es
recomendable su uso.
El ciclo de vida de la creación de una clase BaseGameActivity incluye la invocación en
orden de los siguientes métodos.
78
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Ilustración 30 – Ciclo de vida de Andengine
EngineOptions onCreateEngineOptions()
La invocación de este método se realice antes de ninguna otra. Permite la creación de
las configuraciones necesarias para el Engine o motor de la aplicación. En este método
también se crear las opciones necearías para la resolución de la pantalla sobre la que
trabajar y que posteriormente abstraerá de resoluciones distintas y la creación de la
Camera e inicialización.
Como salida se necesita devolver una clase del tipo EngineOptions con todas las
configuraciones antes especificadas.
onCreateResources()
Después de definir y abstraer todas las opciones necesarias, es necesaria la carga de
todos los recursos necesarios para la aplicación, en s mayoría gráficos en forma de
texturas, pero también pude tratarse de música, efectos de sonidos, etc.
onCreateResources crea las condiciones necesarias para la carga de recursos en
memoria de forma estable y abstrae los inconvenientes del cambio de estado de la
aplicación o de la memoria.
Scene onCreateScene()
Por último, se invoca onCreateScene que permite crear la primera Scene que se
mostrará al usuario. Aunque Scene abstrae la creación y dibujado de la primera escena
del juego, esta escena no tiene que ser única, pudiendo agregarse posteriormente
79
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
nuevas Scene al Engina para ser dibujados sin la necesidad de una nueva carga de
recursos.
5.7 XML
XML o Extensible Markup Language es un metalenguaje creado por el World Wide Web
Consortium más comúnmente conocido como W3C. XML no es exactamente un
lenguaje, en realidad es un lenguaje que permite la definición de otros lenguajes y que
se propone como un estándar para el intercambio de información estructurada entre
diferentes plataformas.
Toda comunicación externa o interna del proyecto se realiza a través de mensajes
estructurados XML, como la comunicación entre móvil/servidor como la petición de
datos a las APIs de localización Google Places y weather Underground.
5.8 Weather Underground
Weather Underground es una aplicación propietaria de Weather Underground, Inc para
la consulta online de datos climatológicos. WU dispone de una sencilla interfaz que
permite el envío de solicitudes vía protocolo http con una especificación de latitud y
longitud, devolviendo los datos relativos a la climatología de dicho punto en formato
JSON o XML.
El formato URL que se emplea está pendiente de actualización y la entidad responsable
recomienda el uso del nuevo formato, basado en clave de usuario. Pero el periodo de
vigencia del formato actual es el suficiente para poder incorporar la consulta al proyecto
y realizar una migración posterior al nuevo servicio.
La consulta se realiza configurando la siguiente URL:
http://api.wunderground.com/auto/wui/geo/WXCurrentObX
ML/index.xml?query=[LAT],[LONG]
Donde LAT y LONG representas números Long con la latitud y longitud de la que
queremos obtener la información.
80
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
El formato del XML recibido es el siguiente:
Listado 1
<current_observation>
<credit></credit>
<credit_URL></credit_URL>
<termsofservice ></termsofservice>
<image>
<url></url>
<title> </title>
<link> link>
</image>
<display_location>
<full> </full>
<city> </city>
<state/>
<state_name></state_name>
<country> </country>
<country_iso3166> </country_iso3166>
<zip></zip>
<latitude></latitude>
<longitude></longitude>
<elevation></elevation>
</display_location>
<observation_location>
<full></full>
<city> </city>
<state/>
<country> </country>
<country_iso3166> </country_iso3166>
<latitude></latitude>
<longitude></longitude>
<elevation></elevation>
</observation_location>
<station_id></station_id>
<observation_time></observation_time>
<observation_time_rfc822></observation_time_rfc822>
<observation_epoch></observation_epoch>
<local_time></local_time>
<local_time_rfc822> </local_time_rfc822>
<local_epoch></local_epoch>
<weather> </weather>
<temperature_string></temperature_string>
<temp_f></temp_f>
<temp_c></temp_c>
<relative_humidity></relative_humidity>
<wind_string></wind_string>
81
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
<wind_dir></wind_dir>
<wind_degrees></wind_degrees>
<wind_mph></wind_mph>
<wind_gust_mph/>
<pressure_string></pressure_string>
<pressure_mb></pressure_mb>
<pressure_in></pressure_in>
<dewpoint_string></dewpoint_string>
<dewpoint_f></dewpoint_f>
<dewpoint_c></dewpoint_c>
<heat_index_string> </heat_index_string>
…resto del documento no relevante
</current_observation>
5.9 Google Places
Del mismo modo que Weather Underground, Google Places es una aplicación
propietaria de Google, Inc para la consulta online de datos relativos a comercios
cercanos a una posición geográfica. Permite a las aplicaciones para móviles que
desean proporcionar información de un lugar a sus usuarios y la función de registro de
visitas a lugares de interés y empresas locales.
Al ser una API propietaria cuenta con los límites de consulta. Únicamente con la una
clave de API pueden realizar 1 000 solicitudes por un período de 24 horas. Pero
suficiente para el desarrollo del proyecto.
Google Places dispone de una sencilla interfaz que permite el envío de solicitudes vía
protocolo http con una especificación de latitud y longitud, entre otras opciones de
configuración, devolviendo los datos relativos de dicho punto en formato JSON o XML.
La consulta se realiza configurando la siguiente URL:
https://maps.googleapis.com/maps/api/place/search/xml
?location=[LAT],[LONG]&radius=[RADIUS]&sensor=true&ke
y=[GKEY]
Donde LAT y LONG representas números Long con la latitud y longitud de la que
queremos obtener la información.
82
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
RADUIS indica la distancia (en metros) que se desea utilizar para obtener resultados de
lugar.
GKEY indica la clave de API de la aplicación.
El formato del XML recibido es el siguiente:
Listado 2
<PlaceSearchResponse>
<status></status>
<result>
<name></name>
<vicinity></vicinity>
<type></type>
<type></type>
…
<geometry>
<location>
<lat></lat>
<lng></lng>
</location>
</geometry>
<icon></icon>
<reference></reference>
<id></id>
</result>
<result>
…
</result>
…resto del documento no relevante
</PlaceSearchResponse>
5.10
MySQL
MySQL es un sistema gestor de base de datos del tipo relacional, perteneciente a la
empresa Sun microsystems, se distribuye bajo licencia GPL, aunque también dispone
de software especializado para medianas y grandes empresas con una mejora de
prestaciones y servicios, admitiendo más conexiones simultaneas y un número mayor
de consultas.
Una base de datos relacional archiva datos en tablas separadas en vez de colocar todos
los datos en un gran archivo. Esto permite velocidad y flexibilidad. Las tablas están
conectadas por relaciones definidas que hacen posible combinar datos de diferentes
tablas sobre pedido. También acepta la conexión no solo directa desde su propio
83
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
terminal, sino que tiene implementada una propia API que permite a diferentes
lenguajes de programación acceder a los datos almacenados por este gestor. En Java
es obligatorio descargar un driver que permite la conexión con base de datos por medio
de la propia API de Java llamada JDBC.
La utilización de este tipo de Sistema Gestor de Base de Datos es casi una obligación al
ser uno de los sistemas más extendidos por todo el mundo, además es una herramienta
open source y junto con alguna de las anteriores implica que no hay que pagar ningún
tipo de licencia. Se ha decidido que la base de datos sea relacional puesto que ayuda a
obtener información relacionada de forma muy fácil y sencilla, frente a otro tipo de
bases de datos que son las llamadas NoSQL como puede ser MongoDB, es Sistema
Gestor de Base de Datos que tiene la información almacenada de una forma no
relacional, se basa en el uso de los estándares de JSON, que es un lenguaje nacido a
partir de Javascript cuya funcionalidad es la del intercambio de información entre
diferentes programas escritos en lenguajes diferentes, es por todo el mundo conocido
que los datos en cada uno desde los lenguajes de programación no son tratados de la
misma forma, ni si quiere un entero en Java puede llegar a ser igual en C. JSON llega a
ser mucho más importante en el desarrollo web, donde es muy normal el uso de varios
lenguajes de programación para desarrollar una misma aplicación.
84
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
6
Diseño software
85
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
86
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
6 Diseño software
En este apartado se especificara cual es el diseño de la plataforma desde un punto de
vista de los diagramas UML, para denotar cuales son la funcionalidad principal de
nuestro sistema al margen del código Java y de los framworks y APIs a emplear. Esta
especificación se realiza gracias a los diagramas de caso de uso que están englobados
dentro de los diferentes diagramas de la metodología UML.
6.1 Modelo de dominio
Diagrama de dominio de la aplicación Shadow Fire para soportar la lógica del juego.
Ilustración 31 - Modelo de dominio
Player
Player es la clase principal en el modelo de dominio de la aplicación. Su cometido es
doble, servir como base informativa para el juego, almacenando cierta información
relativa al jugador, y servir como pasarela para el intercambio de información entre
servidor y juego.
Building
Building es una clase que con dos objetivos. Por un lado almacena la información
referente a cada uno de los 7 edificios que forman parte del juego y por otro reúne todos
los métodos y atributos necesarios para el acceso a las clases Floor, abstrayendo el
tratamiento de la información que contiene dicha colección.
Floor
Floor posé la información relevante a cada una de las plantas construidas y su estado,
así como métodos para la actualización y consulta de datos como costes de
87
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
actualización o tiempo de construcción. Su uso más importante es añadir sus mejoras
al conjunto de variables para el cálculo total de las mejoras aplicables.
6.2 Casos de uso
Diagrama de casos de uso de la aplicación Shadow Fire para soportar la lógica
necesaria para las acciones del jugador.
Ilustración 32 - Casos de uso
88
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Nombre: Register as a new player
Actores: Player
Precondiciones: Iniciar la aplicación por primera vez
Iniciar la aplicación sin estar registrado
Trigger: N/A
Escenario primario:
1.
El jugador inicia la aplicación
2. El jugador completa el formulario de nueva alta correctamente
3. El jugador pulsa el botón enviar
Extensiones:
1.a. Datos incorrectos
1. El nombre o el email ya se encuentran en uso
Descripción de datos:
Datos del usuario a actualizar en la base de datos name, email, dinit
Nombre: Add Floor
Actores: Player
Precondiciones: El jugador debe acceder a un edificio.
Trigger: N/A
Escenario primario:
4.
El jugador seleccione una planta vacía
5. El jugador elije una de las plantas disponibles
6. Se muestra el interior del edifico actualizado
Extensiones:
1.a. Selección incorrecta
2. Selección de una planta que no se puede construir por falta de recursos necesarios
Descripción de datos:
Datos del la planta a actualizar en la base de datos building_type, type, level, poss,
isBuild, dinit y dfinish.
Nombre: Update Floor
Actores: Player
Precondiciones: El jugador debe acceder a un edificio.
Trigger: N/A
Escenario primario:
7.
El jugador seleccione una planta construida
8. El jugador elije una de las posibles actualizaciones (bajar un nivel o subir un nivel)
9. Se muestra el interior del edifico actualizado
Extensiones:
1.a. Selección incorrecta
1. Selección de una planta que no se puede construir por falta de recursos necesarios
Descripción de datos:
Datos del la planta a actualizar en la base de datos level, isBuild, dinit y dfinish.
89
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Nombre: Update emisary
Actores: Player
Precondiciones: N/A
Trigger: N/A
Escenario primario:
1.
El jugador seleccione un emisario
2. El jugador reparte experiencia entre los atributos del emisario
3. El jugador acepta los cambios
Extensiones:
Descripción de datos:
Datos del emisario a actualizar en la base de datos name, type, level, attack, defense.
Nombre: Teach attacks
Actores: Player
Precondiciones: El jugador debe acceder a un edificio.
Trigger: N/A
Escenario primario:
1.
El jugador seleccione un emisario
2. El jugador reparte gasta experiencia en enseñar un ataque al emisario
3. En caso de poseer cuatro ataques, el usuario selecciona un ataque a borrar
4. El jugador acepta los cambios
Extensiones:
Descripción de datos:
Datos del la planta a actualizar en la base de datos building_type, type, level, poss,
attack_name
Nombre: Consult information
Actores: Player
Precondiciones: El jugador debe acceder a un edificio.
Trigger: N/A
Escenario primario:
1. El jugador pulsa el botón de información
Extensiones: N/A
Descripción de datos:N/A
90
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Nombre: Fight other player
Actores: Player
Precondiciones: El jugador debe tener un jugador cercano
Trigger: N/A
Escenario primario:
1. El jugador pulsa el botón de información
2. El jugador selecciona un jugador cercano
3. El jugador seleccione un emisario
4. El jugador selecciona un ataque del emisario a ejecutar
5. Al finalizar el combate, el juego actualiza el factor de victoria
Extensiones:
1.a. Fin del combate
2. El combate finaliza con la reducción total a cero de la vida de un emisario.
Descripción de datos: Envío de la información total del combate mediante fichero XML
a través del servidor.
91
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
6.3 Diagrama de clases
Diagrama de clases de la aplicación. El objetivo de este apartado es dotar de una visión
completa del la aplicación para posteriormente, poder hacer un acercamiento más en
detalle de los segmentos de código más interesantes sin que se pierda la visión general
o que los desarrollos sean demasiado excesivos y complejos.
6.3.1
Shadow Fire
Clases especificas de la aplicación Shadow Fire para soportar la lógica necesaria del
juego.
Ilustración 33 - Diagrama de clases cliente
TheShadowOfFireActivity
Clase principal de la aplicación. Hereda de SimpleBaseGameActivity.
Métodos
‐
EngineOptions onCreateOptions()
Primer método del ciclo de vida invocado. En él se inicializan las variables
para el motor gráfico.
‐
void onCreateResources()
92
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Segundo evento del ciclo de vida invocado. Activa un hilo para encargado de
la inicialización y volcado en memoria de la base de datos a la estructura de
datos interna invocando el método updateCity().
‐
void updateCity()
Realiza las operaciones de actualización de las estructuras de datos internas
del programa referentes a los datos de la aplicación.
‐
boolean isOnline()
Determina se el terminal está conectado o no a la red.
‐
scene onCreateScene()
Tercer método del ciclo de vida invocado. Crea la primera escena (Scene)
que va a ser mostrada en pantalla. En concreto la pantalla Splash mostrada
junto al progreso de carga mientras se obtiene el volcado de los recursos
mediante un hilo auxiliar.
‐
void setSplashBarProgress (float pProgress)
Actualiza la barra de progreso al valor indicado.
‐
void loadResources()
Realiza la carga de recursos gráficos hacia memoria.
‐
boolean onSceneTouchEvent()
Método encargado de la actualización de la escena ente los toques del
jugador en la pantalla.
‐
booolean onBackPressed()
Método encargado de la navegación hacia atrás tras ser pulsado el botón
retroceso de la aplicación.
‐
void actLocationinformacion(WeatherInformation wi, PlacesInformation pi)
Recibe la información de localización del jugador tanto por clima como por
lugar y actualiza los datos internos de la aplicación.
FireHUD
Hereda de la clase HUD. HUD personificado encargado de mostrar la información del
juego al jugador mostrándose siempre en pantalla.
Métodos
‐
void acrWeather()
93
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Actualiza los valores de climatología mostrados.
‐
Void actResources()
Actualiza los valores de los recursos mostrados.
CombatActivity
Hereda de SimpleBaseGameActivity. Clase del tipo Activity encargada de mostrar el
combate entre dos jugadores.
Engine
SceneFactory
Clase auxiliar para la abstracción de la creación de escenas. Crea las distintas escenas
según se solicitan para ser pintadas por el motor gráfico.
Métodos
‐
void
createColmenaScene(),
void
createEnergyScene(),
void
createHospitalScene(), void createHallScene(), void createMilitaryScene(),
void createBeaconScene(), void createLabScene().
Métodos específicos para la creación de las distintas escenas del interior de
cada edificio.
‐
Scene getMenuScene()
Devuelve la escena específica a la muestra de datos de localización.
‐
void createAllScenes()
Inicializa todas las escenas que formar parte de la aplicación tomando como
referencia la estructura de datos interna extraída de la base de datos.
MyLocationListener
Listener que implementa el interfaz LocationListener encargado de la actualización de
los datos de localización obtenidos por el dispositivo.
ConnectionChangeReceiver
Clase que hereda de BroadcastReceiver. Encargada de actualizar el estado de la
aplicación ante un cambio de la conexión de la red.
94
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
6.3.2
Servidor
Clases especifica de la aplicación servidor para soportar la lógica necesaria
multijugador centralizada.
Ilustración 34 - Diagrama de clases servidor
LocationCityServer
Clase principal del servidor. Inicia el proceso de escucha en tres puertos distintos para
distintas acciones que el jugador puede realizar online.
CombatListener
Clase encargada de escuchar las peticiones de combate de un jugador. En caso de
recibirla comunicará a ambos jugadores y delegará la lógica de combate a un hilo
CombatLogic.
CombatLogic
Clase encargada de la lógica de combate entre dos jugadores. Espera las acciones de
ambos, calcula los resultados y son comunicados a los jugadores para actualizar la
información en pantalla.
95
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
NewLocationListener
Clase encargada de escucharlas las actualizaciones de localización de un jugador.
Renovando la información en caso de realizarse un cambio.
NewUserListener
Clase encargada de las nuevas altas que se produzcan de jugadores.
6.4 Estructura de paquetes
En el diagrama de la arquitectura se representa un diagrama de paquetes mostrando los
subsistemas en que se descompone el sistema y sus dependencias.
Ilustración 35 - Diagrama de paquetes
com.game
Almacena las clases principales que forman el eje de la aplicación. Contienen todo lo
necesario para confeccionar la interfaz de usuario y la lógica del juego.
96
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
dominio
Almacena las clases que forman parte del dominio de la aplicación. Está estrechamente
relacionada con las clases del paquete dao.
dao
Almacena las clases que forman parte de la capa de acceso a datos de la aplicación
junto a los necesarios para la gestión de la base de datos.
location
Almacena las clases necesarias para la correcta localización del usuario, incluyendo
comunicación, filtrado de datos y distribución de la información.
org.andengine
Librería aportada por el proyecto Andengine elaborada por Nicolas Gramlich. Almacena
las clases las clases referentes al motor gráfico Andengine y todas las clases
adicionales que han sido añadidas.
97
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
6.5 Modelo de datos
El modelo de datos debe soportar todo el modelo de dominio aportando una solución
para el almacenamiento seguro de toda la información que se precisa a los largo de la
aplicación. Al tener acceso a una base de datos relacional, SQLite, se procede al diseño
de las tablas que formarán parte del modelo de datos.
Ilustración 36 - Modelo entidad-relación
6.5.1
Tabla TUSER
La tabla TUSER almacena toda la información referente al jugador.
Descripción detallada de los atributos de TUSER.
Atributo
Tipo
Descripción
Name
VARCHAR(45) Clave. Nombre del jugador.
Email
VARCHAR(45) Email de contacto del jugador.
First
LONG
Fecha de alta del jugador.
Last
LONG
Ultima fecha en la que el jugador abandonó el juego.
Level
INT
Nivel actual del jugador.
Points
INT
Puntos totales del jugador acumulados.
Science
INT
Cantidad del recurso ciencia acumulado al abandonar la
98
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
aplicación en el último acceso.
Construction INT
Cantidad del recurso construcción acumulado al
abandonar la aplicación en el último acceso
Energy
INT
Cantidad del recurso energía acumulado al abandonar la
aplicación en el último acceso
Food
INT
Cantidad del recurso comida acumulado al abandonar la
aplicación en el último acceso
Population
INT
Cantidad del recurso población acumulado al abandonar
la aplicación en el último acceso
Tabla 17 - Tabla TUSER
La relación de cardinalidad de la tabla TUSER con la tabla TBUILDING estables que un
único jugador puede disponer de múltiples edificios y como mínimo uno, pero cada
edificio únicamente perene a un jugador.
6.5.2
Tabla TBUILDING
La tabla TBUILDING almacena toda la información referente al jugador.
Descripción detallada de los atributos de TBUILDING.
Atributo
Tipo
Descripción
Username
VARCHAR(45)
Clave. Nombre del jugador.
Type
VARCHAR(45)
Clave. Tipo del edificio.
Pstruct
INT
Puntos de estructura utilizados
Pstructmax
INT
Puntos de estructura máximos disponibles
Tabla 18 - Tabla TBUILDING
La relación de cardinalidad de la tabla TBUILDING con la tabla TFLOOR estables que un
único edificio puede disponer de múltiples plantas a su disposición y como mínimo una,
pero cada planta únicamente puede ser construida en un único edificio.
6.5.3
Tabla TFLOOR
La tabla TFLOOR almacena toda la información referente a las plantas disponibles para
su construcción.
Descripción detallada de los atributos de TFLOOR.
99
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Atributo
Tipo
Descripción
Username
VARCHAR(45) Clave. Nombre del jugador.
Buildingtype VARCHAR(45) Clave. Tipo del edificio.
Type
VARCHAR(45) Clave. Tipo de la planta.
Level
INT
Nivel actual de la planta.
Poss
INT
Posición que ocupa la planta dentro de la estructura del
edificio.
isbuild
INT
Puede ser NULL. Indica si la planta se encuentra en
construcción.
dinit
LONG
Puede ser NULL. Indica la fecha de inicio de la planta en
construcción.
dfish
LONG
Puede ser NULL. Indica la fecha de fin de la planta en
construcción.
Tabla 19 - Tabla TFLOOR
100
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
6
Implementación
101
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
102
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
7 Implementación
Una vez presentada la aplicación en un contexto general, el estudio se va a centrar en
los algoritmos concretos y complejos que forman parte del código. El desarrollo del
sistema requiere la realización de dos entidades distintas.
»
La aplicación móvil que contiene la implementación del juego y la lógica
necesaria para crear la experiencia del usuario en su terminar.
»
La aplicación servidor, encargada de la medición de localización y comunicación
entre jugadores, además de la lógica de los enfrentamientos.
7.1 Shadow Fire
Sin duda la parte cliente de la aplicación es sin duda la más compleja de abordar. Por un
lado tenemos las clases encargadas de la localización, que continuamente filtran la
información recibida y están pendientes de actualizar y modificar los datos de entrada y
por otro lado todas las clases necesarias para la experiencia de juego, incluida la lógica
propiamente dicha y las complejas clases encargadas del tratamiento gráfico.
Para comenzar el análisis de la implementación es interesante primero abordar la clase
más compleja y que sirve como nexo de unión de toda la aplicación,
TheShadowOfFireActivity.
7.1.1
TheShadowOfFireActivity
La primera acción que tiene que realizar la clase es inicializar todas las clases y
variables necesarias para que Andengine [ANDBLG12] pueda abstraer correctamente su
funcionalidad a la aplicación. Esta inicialización se realiza con la llamada al primer
método de su ciclo de vida, veamos su implementación.
Listado 3
public EngineOptions onCreateEngineOptions() { db = new DBHelper(this); locationUser = new LocationThread(this); 103
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
LocalBroadcastManager.getInstance(this).registerReceiver(mLocationRece
iver, new IntentFilter("send‐socket‐event")); mLocationManager = (LocationManager)getSystemService(Context.LOCATION_SERVICE); if (mLocationManager.isProviderEnabled(LocationManager.GPS_PROVIDER)) { mLocationListener = new MyLocationListener(); mLocationManager.requestLocationUpdates (LocationManager.GPS_PROVIDER, 1, 0, mLocationListener); locationUser.updateLoc(mLocationManager .getLastKnownLocation(LocationManager.GPS_PROVIDER)); } WindowManager windowManager = (WindowManager)getSystemService(WINDOW_SERVICE); WIDTH = windowManager.getDefaultDisplay().getWidth(); HEIGHT = windowManager.getDefaultDisplay().getHeight(); camera = new Camera(0, 0, WIDTH, HEIGHT); return new EngineOptions(true, ScreenOrientation.PORTRAIT_FIXED, new RatioResolutionPolicy(WIDTH, HEIGHT), camera); } La terea realizada por onCreateEngineoptions es sencilla, pero vital. El objetivo es
devolver una clase del tipo engineOptions que permita a Andengine, más
concretamente a la clase engine encargada de la abstracción, especificar las
características que se quieren para el juego, además de iniciar todos los procesos
necesarios.
La primera línea permite crea una instancia a la base de datos SQLite, que se explicará
en detalle en los siguientes apartados. A continuación se inicia el hilo encargado de
obtener
y
filtrar
la
información
de
geolocaclización
y
se
inicia
un
LocalBroadcastManager encargado de filtrar los Intent internos send‐socket‐
event, para los mensajes recibidos desde el servidor. Lo último que se necesita antes
de iniciar el motor gráfico es crear un LocationManager para la escucha de eventos de
nueva localización. Los parámetros indican que las actualizaciones de localización se
realizan en espacios muy cortos de tiempo y sin necesidad de variación de la distancia.
104
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Ya podemos inicializar los valores y políticas de resolución del motor gráfico. Se
inicializan las variables de la clase WindowManager con los valores por defecto del
terminal que ejecuta la aplicación, creando la Camera sujeta a estos valores y centrada
en 0.0. Ya sólo queda devolver una instancia de la clase EngineOptions con dichos
valores y especificando que la orientación de la aplicación siempre sea vertical con
ScreenOrientation.PORTRAIT_FIXED. Con este primer método hemos tocado bastantes clases distintas y muchos procesos
ya están preparados para la recepción de datos, como la localización, el servidor o la
base de datos. Al ser estas clases más complejas, veamos únicamente la
implementación de MyLocationListener.
Listado 4
private class MyLocationListener implements LocationListener { public void onLocationChanged(Location loc) { locationUser.updateLoc(loc); } public void onProviderDisabled(String provider) { } public void onProviderEnabled(String provider) { } public void onStatusChanged(String provider, int status, Bundle extras) { } } MyLocationListener funciona como Listener de los eventos de localización y su
cometido es muy simple. En caso de recibir un nuevo valor del GPS, informa al hilo
encargado de los nuevos valores y actualiza los datos.
El siguiente paso del ciclo de vida es onCreateResources.
105
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Listado 5
public void onCreateResources()
{ try { this.mTextureSplash = new BitmapTexture(this.getTextureManager(), new IInputStreamOpener() { public InputStream open() throws IOException { return getAssets().open("splash/splash.png"); } }); this.mTextureSplash.load(); this.mSlashTextureRegion = TextureRegionFactory.extractFromTexture(this.mTextureSplash); } catch (IOException e) { Debug.e(e); } this.updateCity(); if(isOnline()) { locationUser.start(); } }
En esta clase simplemente se preparan los recursos necesarios para posteriormente
dibujar la primera Scene que se va a mostrar. Siguiendo la navegación de la aplicación,
lo primero es cargar la pantalla de Splash que se mostrará al jugador mientras se
cargan en segundo plano todos los recursos necesarios. La carga de este recurso es
muy simple y sólo es necesario incluir en memoria una única imagen, por lo que la
espera será mínima.
Los pasos para la carga de recursos son comunes en todos los recursos posteriores. La
clase TextureRegion que servirá de contenedor para la clase BitmaTexture que
contiene la imagen. El primer paso es abrir un InputStream sobre la imagen a cargar
desde disco a memoria y realizar la carga invocando el método load. Una vez la textura
está lista, la añadimos a la clase TextureRegion para poder ser usada por el motor
gráfico en forma de Sprite.
106
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Por último, se actualiza la información de la ciudad para persistir toda la estructura de
datos necesaria y por último, si la conexión está habilitada, se permite al hilo de
localización, comenzar la tarea de filtrar la información de tiempo y lugar.
El método isOnline.
Listado 6
public boolean isOnline() { ConnectivityManager cm = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE); NetworkInfo netInfo = cm.getActiveNetworkInfo(); if (netInfo != null && netInfo.isConnected()) { return true; } return false; }
Se pide al sistema Android a través de una clase ConnectivityManager que nos de
toda la información sobre la red en ese instante. Devolviendo true únicamente si se ha
sido capaz de determinar si la conexión del sistema está establecida.
Siguiente y último paso del ciclo de vida, el método onCreateScene.
Listado 7
public Scene onCreateScene() { VertexBuffer = this.getVertexBufferObjectManager(); engine = this.getEngine(); Line[] FrameLines = new Line[4]; Rectangle BackgroundRectangle; float pHeight = HEIGHT*0.05f; float pWidth = WIDTH*0.90f; float pY = HEIGHT‐pHeight*1.05f; float pX = WIDTH*0.05f; splashScene = new Scene(); splashScene.setBackground(new Background(0f, 0f, 0f)); Sprite splash = new Sprite(0, 0, WIDTH, HEIGHT, mSlashTextureRegion, VertexBuffer); 107
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
BackgroundRectangle = new Rectangle(pX, pY, pWidth, pHeight, VertexBuffer); BackgroundRectangle.setColor(0f,0f,0f); FrameLines[0] = new Line(pX, pY, pX+pWidth, pY, VertexBuffer); FrameLines[1] = new Line(pX + pWidth, pY, pX + pWidth, pY + pHeight, VertexBuffer); FrameLines[2] = new Line(pX + pWidth, pY + pHeight, pX, pY + pHeight, VertexBuffer); FrameLines[3] = new Line(pX, pY + pHeight, pX, pY, VertexBuffer); ProgressRectangle = new Rectangle(pX, pY, 0, pHeight, VertexBuffer); ProgressRectangle.setColor(0.5f, 0, 0); splashScene.attachChild(splash); splashScene.attachChild(BackgroundRectangle); splashScene.attachChild(ProgressRectangle); for(int i = 0; i < FrameLines.length; i++) splashScene.attachChild(FrameLines[i]); this.mPixelsPerPercentRatio = pWidth / 100; LoadThread loadThread = new LoadThread(); loadThread.start(); return splashScene; }
Finalmente, se muestra la escena Splash al usuario mientras los datos son cargados en
paralelo. En concreto, esta escena muestra un fondo negro, una imagen con el logo del
juego mostrada en una clase Sprite que toma textura los recursos antes asociados a
una TextureRegion (en concreto mSlashTextureRegion antes cargada en memoria) y
un rectángulo en la parte inferior de la pantalla a modo de barra de progreso.
La clase configurada se devuelve al motor gráfico para que pueda ser pintada en
pantalla.
Ya se ha visto que la persistencia de los datos de la ciudad en memoria se volcaba en
su estructura de datos antes de comenzar con la carga gráfica. A continuación se
muestra su implementación y las estructuras de datos soportan la lógica de los datos.
108
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Estructuras de datos
Teniendo el motor gráfico iniciado y los recursos cargados en memoria, el siguiente
paso es inicializar correctamente las variables necesarias para soportar la lógica de
recursos y de la ciudad. El código es el siguiente.
Listado 8
private void updateCity() { resources = new HashMap(); resources = db.getResources(); resources.put("Science", Float.valueOf(200)); resources.put("Energy", Float.valueOf(100)); resources.put("Construction", Float.valueOf(150)); resources.put("Food", Float.valueOf(200)); resources.put("Population", Float.valueOf(100)); resources.put("mScience", Float.valueOf(1)); resources.put("sScience", Float.valueOf(0)); resources.put("maxScience", Float.valueOf(0)); resources.put("mConstruction", Float.valueOf(1)); resources.put("sConstruction", Float.valueOf(0)); resources.put("maxConstruction", Float.valueOf(0)); resources.put("mEnergy", Float.valueOf(1)); resources.put("sEnergy", Float.valueOf(0)); resources.put("maxEnergy", Float.valueOf(0)); resources.put("mFood", Float.valueOf(1)); resources.put("sFood", Float.valueOf(0)); resources.put("maxFood", Float.valueOf(0)); resources.put("mPopulation", Float.valueOf(1)); resources.put("sPopulation", Float.valueOf(0)); resources.put("maxPopulation", Float.valueOf(0)); resources.put("wind", Float.valueOf(0)); resources.put("temp", Float.valueOf(0)); city = db.getAllBuilding(); Iterator buildingIt = city.iterator(); while(buildingIt.hasNext()) { Building curretBuilding = (Building)buildingIt.next(); ArrayList allBFloor = new ArrayList(); allBFloor = db.getAllFloorbyBuildingType (curretBuilding.getType()); Iterator FloorIt = allBFloor.iterator(); 109
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
while(FloorIt.hasNext()) { Floor currentFloor = (Floor)FloorIt.next(); if(currentFloor.getPoss()>0) { if(currentFloor.getBuild() == CURRENT_IN_CONSTRUCTION && currentFloor.getDfinish().getTimeInMillis() <Calendar.getInstance().getTimeInMillis()) { currentFloor.setBuild(0); currentFloor.setDfinish (Calendar.getInstance()); currentFloor.setDinit (Calendar.getInstance()); db.updateFloor(curretBuilding .getType(), currentFloor); } curretBuilding.addFloor(currentFloor); } curretBuilding.appplyImprovent(resources); } } }
La variable resources contiene las variables necesarias para el control de todos los
recursos. Inicialmente sólo se crea con los valores por defecto, que posteriormente
serán actualizados al ser tratada la estructura por cada edificio. Las variables
sVariable con tienen la suma adicional a aplicar, las variables mVariable contienen el multiplicador a aplicar y maxVariable contiene el valor máximo que esa
variable puede alcanzar.
El siguiente bucle anidado toma los datos obtenidos de la base de datos con la
información de todas las plantas construidas y su estado, encargándose de actualizar
cualquier evento que hubiese surgido desde la anterior actualización, como una
finalización en una construcción.
Esta forma de actuar es muy similar al modelo vista-controlador usado para el
desarrollo de aplicaciones web. Se toma como partida esta estructura que es analizada
por la aplicación para generar las escenas a ser mostradas. Pero la lógica de
110
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
actualización de los datos es independiente de esta, siendo sólo requerida por la clase
SceneFactory la estructura para su correcto dibujado [Zechner11].
Por último con el método curretBuilding.appplyImprovent(resources) para
invocado por cada planta de cada edificio para que apliquen sus modificaciones a las
variables.
Navegación
La navegación entre los distintos estados de la aplicación debe ser hecha a mano pues
Android sólo permite de forma nativa volver a la anterior Activity ejecutada (cerrando la
aplicación en caso de no existir una última).
Pero gracias al método onBackPressed(), invocado al pulsar el usuario el botón
retroceso, se puede modificar dicho comportamiento a medida. La lógica de la
navegación se ha realizado tomando como base los estados como se muestra en el
apartado 4.2.2 del capítulo 4, cuaderno de desarrollo.
Listado 9
public void onBackPressed() { if(actualScene == SCENE_MAIN) { this.finish(); } else if(actualScene == SCENE_INSIDE_COLMENA || actualScene == SCENE_INSIDE_BALIZA || actualScene == SCENE_INSIDE_CENTRO_MANDO || actualScene == SCENE_INSIDE_LABORATORIO || actualScene == SCENE_INSIDE_HOSPITAL || actualScene == SCENE_INSIDE_PLANTA_ENERGIA || actualScene == SCENE_INSIDE_BASE_MILITAR) { engine.setScene(scenefactory.getCityScene()); actualScene = SCENE_MAIN; } else if(actualScene == SCENE_CHOSSE_NEW) { switch(lastScene) { case SCENE_INSIDE_COLMENA: actualScene = SCENE_INSIDE_COLMENA; engine.setScene(scenefactory.getHouseScene()); break; case SCENE_INSIDE_BALIZA: actualScene = SCENE_INSIDE_BALIZA; 111
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
engine.setScene(scenefactory.getBeaconScene()); break; case SCENE_INSIDE_BASE_MILITAR: actualScene = SCENE_INSIDE_BASE_MILITAR; .setScene(scenefactory.getMilitaryScene()); break; case SCENE_INSIDE_CENTRO_MANDO: actualScene = SCENE_INSIDE_CENTRO_MANDO; engine.setScene(scenefactory.getHallScene()); break; case SCENE_INSIDE_HOSPITAL: actualScene = SCENE_INSIDE_HOSPITAL; engine.setScene(scenefactory.getHospitalScene()); break; case SCENE_INSIDE_LABORATORIO: actualScene = SCENE_INSIDE_LABORATORIO; engine.setScene(scenefactory.getLabScene()); break; case SCENE_INSIDE_PLANTA_ENERGIA: actualScene = SCENE_INSIDE_PLANTA_ENERGIA; engine.setScene(scenefactory.getEnergyScene()); break; case SCENE_CHOSSE_NEW: engine.setScene(scenefactory.getCityScene()); actualScene = SCENE_MAIN; lastScene = SCENE_MAIN; break; } lastScene = SCENE_CHOSSE_NEW; camera.setCenter(lastX, lastY); } else if(actualScene == SCENE_MENU) { actualScene = SCENE_MAIN; engine.setScene(scenefactory.getCityScene()); } else { this.finish(); } }
Se distinguen los siguientes estados y la acción a llevar a cabo tras pulsar atrás. Si la
aplicación se encuentra mostrando la escena principal con la panorámica de la ciudad,
se cierra la aplicación. En caso de encontrarse en el interior de uno de los edificios,
112
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
volvemos a la panorámica de la ciudad. En caso de encontrarse en uno de los menús de
construcción o mejora, se vuelve al interior del edificio en el que se estaba.
Fondo parallax y scroll
La pantalla principal con la panorámica de la ciudad así como el menú de construcción
de una nueva planta son demasiado extensos para poder ser mostrados en su totalidad.
Es necesaria la creación de un método que actualice correctamente la pantalla y los
gráficos ante los movimientos del dedo sobre la pantalla.
Para el caso de la panorámica, el scroll será horizontal, pero para la pantalla de
selección el scroll es vertical, teniendo que diferenciar estos estados dentro del método
para calcular correctamente la nueva posición de la cámara.
Listado 10
public boolean onSceneTouchEvent(Scene pScene, TouchEvent pTouchEvent) { if (pTouchEvent.getAction() == MotionEvent.ACTION_DOWN) { mTouchX = pTouchEvent.getMotionEvent().getX(); mTouchY = pTouchEvent.getMotionEvent().getY(); } else if (pTouchEvent.getAction() == MotionEvent.ACTION_MOVE) { float newX = pTouchEvent.getMotionEvent().getX(); float newY = pTouchEvent.getMotionEvent().getY(); mTouchOffsetX = (newX ‐ mTouchX); mTouchOffsetY = (newY ‐ mTouchY); backgroundParallax.updateScrollEvents(); float newScrollX = this.camera.getCenterX() ‐ mTouchOffsetX; float newScrollY = this.camera.getCenterY() ‐ mTouchOffsetY; if(this.actualScene == SCENE_CHOSSE_NEW) this.camera.setCenter(camera.getCenterX() , newScrollY); if(this.actualScene == SCENE_MAIN) this.camera.setCenter(newScrollX , camera.getCenterY()); mTouchX = newX; mTouchY = newY; } return true;} 113
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Cuando el usuario coloque el dedo sobre la pantalla, se registra la posición como inicial.
Al moverse, se utiliza este punto inicial para calcular la cantidad total de movimiento y
actualizar la nueva posición de la cámara con estos datos en el eje que interese.
La pantalla de la panorámica incluye un fondo de que simula profundidad con varias
capas
que
se
actualizan
a
distintas
velocidades.
Esta
clase
ScrollableParallaxBackground no existía en la API original de Andengine, por lo que se
ha incluido al proyecto. Su implementación es la siguiente y se ha añadido al conjunto
de aplicaciones que forman la API de Andengine en el proyecto.
Listado 11
public class ScrollableParallaxBackground extends ParallaxBackground { private float cameraPreviousX; private float cameraOffsetX; private Camera camera; public ScrollableParallaxBackground(final float pRed, final float pGreen, final float pBlue, Camera camera) { super(pRed, pGreen, pBlue); this.camera = camera; cameraPreviousX = camera.getCenterX(); } public void updateScrollEvents() { if (cameraPreviousX != this.camera.getCenterX()) { cameraOffsetX = cameraPreviousX ‐ this.camera.getCenterX(); cameraPreviousX = this.camera.getCenterX(); } } @Override public void onUpdate(float pSecondsElapsed) { super.onUpdate(pSecondsElapsed); this.mParallaxValue ‐= (cameraOffsetX * 2) * pSecondsElapsed; cameraOffsetX = 0; } }
114
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
HUD
El último elemento a de ser dibujado es el HUD de la aplicación. Como se dispone de la
estructura de datos con las variables actualizadas, únicamente es necesario tratar esta
estructura para leer de ella los datos que se van a mostrar y actualizarlos en caso de
realizarse un cambio.
Listado 12
private class FireHUD extends HUD { private Text windText; private Text temperatureText; private Sprite clima; public FireHUD() { super(); float size = HEIGHT*0.07f; Sprite backgroundHUD = new Sprite(0, 0, mHUDTextureRegion, VertexBuffer); Sprite alert = new Sprite(WIDTH*0.83f, HEIGHT*0.37f, size*1.3f, size*1.3f, mIconsAlertTextureRegion, VertexBuffer) { @Override public boolean onAreaTouched(final TouchEvent pTouchEvent, final float pTouchAreaLocalX, final float pTouchAreaLocalY) { actualScene = SCENE_MENU; Scene s = scenefactory.getMenuScene(); engine.setScene(s); return true; }; Float s = Float.valueOf(resources.get("Science").toString()) + Float.valueOf(resources.get("sScience").toString()); Float c = Float.valueOf(resources.get("Construction").toString()) + Float.valueOf(resources.get("sConstruction").toString()); Float e = Float.valueOf(resources.get("Energy").toString()) + Float.valueOf(resources.get("sEnergy").toString()); Float f = Float.valueOf(resources.get("Food").toString()) + Float.valueOf(resources.get("sFood").toString()); Float p = Float.valueOf(resources.get("Population").toString()) + Float.valueOf(resources.get("sPopulation").toString()); Sprite wind = new Sprite(WIDTH*0.89f, HEIGHT*0.19f, size*0.9f, size*0.9f, mIconsWindTextureRegion, VertexBuffer); 115
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Sprite temperature = new Sprite(WIDTH*0.89f, HEIGHT*0.28f, size*0.9f, size*0.9f, mIconsTemperatureTextureRegion, VertexBuffer); windText = new Text(wind.getX()+wind.getWidth()/3, (wind.getY()+wind.getHeight()), mFont, resources.get("wind").toString(), new TextOptions(HorizontalAlign.LEFT), VertexBuffer); temperatureText = new Text(temperature.getX()+temperature.getWidth()/3, (temperature.getY()+temperature.getHeight()), mFont, resources.get("temp").toString(), new TextOptions(HorizontalAlign.LEFT), VertexBuffer); Sprite science = new Sprite(WIDTH*0.05f, HEIGHT*0.01f, size, size, mIconsScienceTextureRegion, VertexBuffer); Sprite construction = new Sprite(WIDTH*0.25f, HEIGHT*0.01f, size, size, mIconsConstructionTextureRegion, VertexBuffer); Sprite energy = new Sprite(WIDTH*0.45f, HEIGHT*0.01f, size, size, mIconsEnergyTextureRegion, VertexBuffer); Sprite food = new Sprite(WIDTH*0.65f, HEIGHT*0.01f,size, size, mIconsFoodTextureRegion, VertexBuffer); Sprite human = new Sprite(WIDTH*0.85f, HEIGHT*0.01f, size, size, mIconsHumanTextureRegion, VertexBuffer); final Text scienceText = new Text(science.getX()+science.getWidth()/3, (science.getY()+science.getHeight()), mFont, s.toString(), new TextOptions(HorizontalAlign.LEFT), VertexBuffer); final Text constructionText = new Text(construction.getX()+construction.getWidth()/3, (construction.getY()+construction.getHeight()), mFont, c.toString(), new TextOptions(HorizontalAlign.LEFT), VertexBuffer); final Text energyText = new Text(energy.getX()+energy.getWidth()/3, (energy.getY()+energy.getHeight()), mFont, e.toString(), new TextOptions(HorizontalAlign.LEFT), VertexBuffer); final Text foodText = new Text(food.getX()+food.getWidth()/3, (food.getY()+food.getHeight()), mFont, f.toString(), new TextOptions(HorizontalAlign.LEFT), VertexBuffer); final Text humanText = new Text(human.getX()+human.getWidth()/3, (human.getY()+human.getHeight()), mFont, p.toString(), new TextOptions(HorizontalAlign.LEFT), VertexBuffer); backgroundHUD.setWidth(WIDTH); backgroundHUD.setHeight(HEIGHT*0.5f); super.attachChild(backgroundHUD); super.attachChild(science); super.attachChild(construction); super.attachChild(energy); super.attachChild(food); super.attachChild(human); super.attachChild(alert); super.registerTouchArea(alert); super.attachChild(wind); 116
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
}
super.attachChild(temperature);
super.attachChild(scienceText); super.attachChild(constructionText); super.attachChild(energyText); super.attachChild(foodText); super.attachChild(humanText); super.attachChild(windText); super.attachChild(temperatureText); super.setTouchAreaBindingOnActionDownEnabled(true); } El HUD dispone de dos grupos de iconos y variables distintos. Los iconos y texto siguen
la misma estructura en su especificación mostrado anteriormente para la escena
splash y el código carece de un interés especial.
Por un lado la parte superior muestra el total de los cinco recursos y sus valores. Y una
barra lateral con los iconos de localización y tiempo, junto con el botón de información.
La carga y configuración del HUD es igual a la configuración de una escena, ya
mostrada anteriormente con la pantalla Splash. Se crean los Sprites recuperando las
imágenes almacenas en las TextureRegion, añadiendo en este caso además unas
clases Text para mostrar los valores numéricos, vinculando todos los recursos a la
escena con el método attachChild.
SceneFactory y escenas restantes
La clase SceneFactory realiza bajo invocación de sus métodos diferentes escenas
usadas por el motor gráfico. En este apartado se van a mostrar los códigos de la
configuración de las escenas que faltan por mostrar.
Las escenas restantes son: Visión general de la ciudad, interior de los edificios, menú de
mejoras y menú de nueva planta.
Fragmento de código necesario para la visión general de la ciudad.
Listado 13
backgroundParallax = new ScrollableParallaxBackground(0, 0, 0, camera); final float centerX = (WIDTH ‐ mCityHallTextureRegion.getWidth()) / 2; final float centerY = HEIGHT/2; 117
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
cityhospital = new Sprite(centerX+400, centerY‐mCityHospitalTextureRegion.getWidth(), mCityHospitalTextureRegion, VertexBuffer){ @Override public boolean onAreaTouched(final TouchEvent pTouchEvent, final float pTouchAreaLocalX, final float pTouchAreaLocalY) { float newX = pTouchEvent.getMotionEvent().getX(); mTouchOffsetX = (newX ‐ mTouchX); scroll += Math.abs(mTouchOffsetX); if(pTouchEvent.getAction() == MotionEvent.ACTION_MOVE) { backgroundParallax.updateScrollEvents(); float newScrollX = camera.getCenterX() ‐ mTouchOffsetX; camera.setCenter(newScrollX, camera.getCenterY()); mTouchX = newX; } else if(pTouchEvent.getAction() == MotionEvent.ACTION_UP) { if(scroll<MAX_SCROLL) { TheShadowOfFireActivity.this.getEngine() .setScene(scenefactory.getHospitalScene()); actualScene = SCENE_INSIDE_HOSPITAL; camera.setCenter(WIDTH/2, HEIGHT/2); } scroll=0; } else if (pTouchEvent.getAction() == MotionEvent.ACTION_DOWN) { mTouchX = pTouchEvent.getMotionEvent().getX(); } return true; } }; //Se omiten resto de Sprites
El código muestra la creación del Sprite de un único edificio. Cada Sprite necesita ser
capaz de diferenciar los distintos toques que el usuario puede realizar sobre él. Por un
lado, si el usuario únicamente da un toque al edificio sin arrastrar el dedo, se entiende
que desea acceder a él. Si el movimiento realizado por el dedo es superior a un umbral,
se asume que el dedo se arrastra por la pantalla, moviendo la escena haciendo scroll
horizontal.
Fragmento de código necesario para la visión interna de un edificio.
118
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Listado 14
public void createColmenaScene()
{ houseScene = new Scene(); houseScene.setBackground(new Background(0f, 0f, 0f)); Building house = city.get(city.indexOf(new Building("Colmena"))); Iterator it = house.getAllFloor().iterator(); housefloor1 = (Sprite)((Floor) it.next()).getSprite(); housefloor2 = (Sprite)((Floor) it.next()).getSprite(); housefloor3 = (Sprite)((Floor) it.next()).getSprite(); housefloor4 = (Sprite)((Floor) it.next()).getSprite(); housefloor5 = (Sprite)((Floor) it.next()).getSprite(); houseScene.attachChild(housefloor1); houseScene.registerTouchArea(housefloor1); houseScene.attachChild(housefloor2); houseScene.registerTouchArea(housefloor2); houseScene.attachChild(housefloor3); houseScene.registerTouchArea(housefloor3); houseScene.attachChild(housefloor4); houseScene.registerTouchArea(housefloor4); houseScene.attachChild(housefloor5); houseScene.registerTouchArea(housefloor5); }
Al recorrer la estructura de datos se puede precisar que planta corresponde a cada
sección del edificio, obteniendo directamente la información sin necesidad de ninguna
operación más.
Fragmento de código necesario para el menú de mejoras.
Listado 15
currentFloor.setSprite(new Sprite(WIDTH*0.03f, HEIGHT*(0.80f‐offset), WIDTH*0.75f, HEIGHT*0.14f, mFloorResidenciaTextureRegion, VertexBuffer) { @Override public boolean onAreaTouched(final TouchEvent pTouchEvent, final float pTouchAreaLocalX, final float pTouchAreaLocalY) { FloorResidencia residencia = (FloorResidencia)currentFloor; lastScene = actualScene; actualScene = SCENE_LEVEL_CHANGED; lastX = camera.getCenterX(); lastY = camera.getCenterY(); Scene selectScene = new Scene(); 119
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
selectScene.setBackground(new Background(0f, 0f, 0f)); Text textup = new Text(WIDTH*0.03f,HEIGHT*0.25f, mWFont, "SUBIDA A NIVEL + residencia.getDescription(), new TextOptions(HorizontalAlign.LEFT), VertexBuffer); Text textdown = new Text(WIDTH*0.03f,HEIGHT*0.50f, mWFont, "BAJADA NIVEL A NIVEL " +residencia.getDescription() , new TextOptions(HorizontalAlign.LEFT), VertexBuffer); selectScene.attachChild(textup); selectScene.attachChild(textdown); engine.setScene(selectScene); return true; } });
La creación de esta escena se encuentra implícita dentro de la creación del propio Sprite
de la planta y se activa al tocar el usuario la planta. Se trata de una configuración como
las que se han realizado con anterioridad y el código no contiene ningún elemento
nuevo no mostrado ya.
Fragmento de código necesario para el de nueva construcción.
Listado 16
currentFloor.setSprite(new Sprite(WIDTH*0.03f, HEIGHT*(0.80f‐offset), WIDTH*0.75f, HEIGHT*0.14f, mFloorEmpyTextureRegion, VertexBuffer) { @Override public boolean onAreaTouched(final TouchEvent pTouchEvent, final float pTouchAreaLocalX, final float pTouchAreaLocalY) { if(pTouchEvent.getAction() == MotionEvent.ACTION_UP) { lastScene = actualScene; actualScene = SCENE_CHOSSE_NEW; lastX = camera.getCenterX(); lastY = camera.getCenterY(); ArrayList list = new ArrayList(); switch(lastScene) { case SCENE_INSIDE_COLMENA: list = db.getAllFloorbyBuildingType("Colmena"); break; 120
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
case SCENE_INSIDE_BALIZA:
list = db.getAllFloorbyBuildingType("Baliza"); break; case SCENE_INSIDE_BASE_MILITAR: list = db.getAllFloorbyBuildingType("Base militar"); break; case SCENE_INSIDE_CENTRO_MANDO: list = db.getAllFloorbyBuildingType("Centro de break; case SCENE_INSIDE_HOSPITAL: list = db.getAllFloorbyBuildingType("Hospital"); break; case SCENE_INSIDE_LABORATORIO: list = db.getAllFloorbyBuildingType("Laboratorio"); break; case SCENE_INSIDE_PLANTA_ENERGIA: list = db.getAllFloorbyBuildingType("Planta de break; } Scene selectScene = new Scene(); selectScene.setBackground(new Background(0f, 0f, 0f)); int numFloors = 0; Iterator it = list.iterator(); while(it.hasNext()) { final Floor floor = (Floor)it.next(); if(floor.getLevel()<=0) { floor.setSprite(new Sprite(WIDTH*0.03f, HEIGHT*(0.2f + numFloors*HEIGHT*0.14f), WIDTH*0.75f, HEIGHT*0.14f, mFloorResidenciaTextureRegion, VertexBuffer) { @Override public boolean onAreaTouched(final TouchEvent pTouchEvent, final float pTouchAreaLocalX, final float pTouchAreaLocalY) { float newY = pTouchEvent.getMotionEvent().getY(); mTouchOffsetY = (newY ‐ mTouchY); scroll += Math.abs(mTouchOffsetY); if(pTouchEvent.getAction() == MotionEvent.ACTION_MOVE) { float newScrollY = camera.getCenterY() ‐ mTouchOffsetY; camera.setCenter(camera.getCenterX() ,newScrollY); mTouchY = newY; 121
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
} else if(pTouchEvent.getAction() == MotionEvent.ACTION_UP) { if(scroll<MAX_SCROLLY) { Floor floor = (Floor)floor; floor.setPoss( currentFloor.getPoss()); floor.setLevel(1); floor.setDinit(Calendar. getInstance().getTimeInMillis()); floor.setDfinish(floor. calculateDFinish(floor.getLevel())); floor.setBuild(1); db.deleteFloor(curretBuilding .getType(), currentFloor); { db.updateFloor(curretBuilding .getType(), safloor); updateCity(); createAllScenes(); switch(lastScene) case SCENE_INSIDE_COLMENA: houseScene.clearChildScene(); engine.setScene(getHouseScene()); break; case SCENE_INSIDE_BALIZA: beaconScene.clearChildScene(); engine.setScene(getBeaconScene()); break; case SCENE_INSIDE_BASE_MILITAR: militaryScene.clearChildScene(); engine.setScene(getMilitaryScene()); break; case SCENE_INSIDE_CENTRO_MANDO: hallScene.clearChildScene(); 122
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
});} engine.setScene(getHallScene());
break; case SCENE_INSIDE_HOSPITAL: hospitalScene.clearChildScene(); engine.setScene(getHospitalScene()); break; case SCENE_INSIDE_LABORATORIO: labScene.clearChildScene(); engine.setScene(getLabScene()); break; case SCENE_INSIDE_PLANTA_ENERGIA: energyScene.clearChildScene(); engine.setScene(getEnergyScene()); break; } camera.setCenter(lastX, lastY); } scroll = 0; } else if (pTouchEvent.getAction() == MotionEvent.ACTION_DOWN) { mTouchY = pTouchEvent. getMotionEvent().getY(); } return true; } De nuevo el paso de creación de esta escena se encuentra implícito dentro del propio
Sprite que debe ejecutar el método de invocación al ser tocado.
El primer paso consiste en obtener todas las plantas que aun no han sido construidas y
mostrarlas al usuario recorriendo el Array que nos es devuelto de la clase dbHelper.
Como ya sucedía en la escena que representaba la panorámica de la ciudad, el usuario
puede pulsar o arrastrar con el dedo sobre los Sprites, por lo que es necesario
diferenciar entre estos dos aspectos calculando el movimiento del dedo, esta vez sobre
el eje Y.
En caso de arrastrar, la escena únicamente se desplaza el espacio necesario. En caso
de pulsar, la información pertinente a la nueva planta se actualiza en la base de datos,
restando actualizar la escena pertinente al edificio en curso para mostrar los cambios.
123
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
7.1.2
Localización
Ya tenemos la aplicación mostrado los gráficos y las estructuras de datos preparadas
para soportar todas las variables básicas. Pero si el usuario se encuentra conectado a la
red, la aplicación podrá tomar los datos de su localización y obtener las variaciones que
le son aplicables.
El proceso es sencillo, un hilo paralelo a la aplicación realiza una petición http a los dos
sitios Google Places [GPAP12] y Weather Underground [WUAP12], recibiendo toda la
información en formato XML. Una clase Handler trata los XML y los persiste en dos
clases enviadas a la actividad principal.
La implementación del hilo es el siguiente.
Listado 17
public class LocationThread extends Thread
{ //URL services y APIs private static final String QBASE = "http://api.wunderground.com/auto/wui/geo/WXCurrentObXML/index.xml?query="; private static final String GPLACES = "https://maps.googleapis.com/maps/api/place/search/xml?location="; private TheShadowOfFireActivity tsof; //Google Places Params private static final String GKEY = "xxx"; //Private Key, can’t show it private static final int RADIUS = 10; WeatherInformation wi; PlacesInformation pi; private Location currentLocation; public LocationThread(TheShadowOfFireActivity act) { currentLocation = null; tsof = act; } public void updateLoc(Location loc) { currentLocation = loc; } public void run() { while(true) 124
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
{ if(currentLocation!=null) { wi = new WeatherInformation(); pi = new PlacesInformation(); try { GeoHandler parser = new GeoHandler(); URL urlWeather = new URL(QBASE + currentLocation.getLatitude() + "," + currentLocation.getLongitude()); URL urlPlaces = new URL(GPLACES + currentLocation.getLatitude() + "," + currentLocation.getLongitude() + "&radius=" + RADIUS + "&sensor=true&key=" + GKEY); wi = parser.parseWeather(urlWeather); ArrayList<PlacesInformation> array = parser.parsePlaces(urlPlaces); pi = (PlacesInformation) array.get(0); this.tsof.actLocationInformation(wi,pi); } catch (MalformedURLException e) { e.printStackTrace(); } catch (Exception e) { e.printStackTrace(); } } try { this.sleep(1000*15); } catch (InterruptedException e) { e.printStackTrace(); } } } public WeatherInformation getWi() { return wi; } public PlacesInformation getPi() { return pi; } }
El primer paso es preparar las URL con los datos necesarios. En el caso de Weather
Undergraund sólo se precisan los datos de localización en forma de latitud y longitud.
125
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Google Places es un poco más refinado. Además de los datos de latitud y longitud, se
necesita especificar el radio de acción al que aplicar la búsqueda, en este caso fijada en
10 metros y especificar si la petición se realiza a través de un dispositivo móvil, en este
caso sí.
Con estas URL el parser puede abrir un Stream con los XMLs entrantes y devolver el par
de clases WeatherInformation y PlacesInformation con los datos necesario a
enviar a la aplicación. Por último el hilo espera 15 segundos para realizar una nueva
petición.
Handler
La clase GeoHandleres la encargada del parseo de los XMLs obtenidos de las URLs.
Para su desarrollo se ha usado una versión simplificada de SAX para Android. Veamos
su implementación.
Listado 18
public class GeoHandler { private PlacesInformation pi; public WeatherInformation parseWeather(URL urlWeather) { final WeatherInformation wi = new WeatherInformation(); RootElement root = new RootElement("current_observation"); Element dl = root.getChild("display_location"); dl.getChild("state_name").setEndTextElementListener( new EndTextElementListener(){ public void end(String country) { wi.setCountry(country); } }); dl.getChild("city").setEndTextElementListener( new EndTextElementListener(){ public void end(String city) { wi.setCity(city); } }); root.getChild("temp_c").setEndTextElementListener( new EndTextElementListener(){ public void end(String temp_c) { wi.setTemp_c(temp_c); } }); 126
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
root.getChild("weather").setEndTextElementListener( new EndTextElementListener(){ public void end(String weather) { wi.setWeather(weather); } }); root.getChild("wind_dir").setEndTextElementListener( new EndTextElementListener(){ public void end(String wind_dir) { wi.setWind_dir(wind_dir); } }); root.getChild("wind_mph").setEndTextElementListener( new EndTextElementListener(){ public void end(String wind_mph) { wi.setWind_vel(String.valueOf(Double.parseDouble(wind_mph)*1.609344)); } }); try { Xml.parse(urlWeather.openConnection().getInputStream(), Xml.Encoding.UTF_8, root.getContentHandler()); } catch (Exception ex) { throw new RuntimeException(ex); } return wi; } public ArrayList<PlacesInformation> parsePlaces(URL urlPlaces) { final ArrayList<PlacesInformation> ap = new ArrayList<PlacesInformation>(); RootElement root = new RootElement("PlaceSearchResponse"); Element result = root.getChild("result"); result.setStartElementListener(new StartElementListener (){ public void start(Attributes attributes) { pi = new PlacesInformation(); } }); result.setEndElementListener(new EndElementListener(){ public void end() { ap.add(pi); } 127
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
}); result.getChild("name").setEndTextElementListener( new EndTextElementListener(){ public void end(String name) { pi.setName(name); } }); result.getChild("type").setEndTextElementListener( new EndTextElementListener(){ public void end(String type) { pi.addType(type); } }); result.getChild("icon").setEndTextElementListener( new EndTextElementListener(){ public void end(String icon) { pi.setIcon(icon); } }); try { Xml.parse(urlPlaces.openConnection().getInputStream(), Xml.Encoding.UTF_8, root.getContentHandler()); } catch (Exception ex) { throw new RuntimeException(ex); } return ap; } }
Para evitar problemas, Android propone una variante del modelo SAX que permite
asociar directamente las acciones a etiquetas concretas dentro de la estructura del
documento XML, lo que alivia en gran medida los inconvenientes. Este modelo SAX
alternativo simplifica la elaboración del handler necesario y puede ayudar a evitar
posibles errores y disminuir la complejidad del mismo para casos en los que el
documento XML no sea tan sencillo.
La clase Handler establece dos InputStreams con los datos en formato XML recibidos a
partir de las URL configuradas en la clase LocationThread. Una vez abierta la
comunicación, dos datos se analizan y parsean a las clases que soportan los datos.
128
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Las clases PlacesInformation y WeatherInformation se muestran a continuación.
PlacesInformation
Listado 19
public class PlacesInformation implements Parcelable
{ private String name; private ArrayList types; private String icon; public PlacesInformation(Parcel in) { readFromParcel(in); } public PlacesInformation() { types = new ArrayList(); } @Override public String toString() { return "PlacesInformation [name=" + name + ", types=" + types.toString() + ", icon=" + icon + "]"; } public String getName() { return name; } public void setName(String name) { this.name = name; } public ArrayList getTypes() { return types; } public void setTypes(ArrayList types) { this.types = types; } public String getIcon() { return icon; } public void setIcon(String icon) { this.icon = icon; } public int describeContents() { return 0; } public void writeToParcel(Parcel dest, int flags) { dest.writeString(name); dest.writeList(types); dest.writeString(icon); } 129
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
private void readFromParcel(Parcel in) { name = in.readString(); in.readList(types, null); icon= in.readString(); } public static final Parcelable.Creator CREATOR = new Parcelable.Creator() { public PlacesInformation createFromParcel(Parcel in) { return new PlacesInformation(in); } public PlacesInformation[] newArray(int size) { return new PlacesInformation[size]; } }; public void addType(String type) { this.types.add(type); } }
De todos los datos obtenidos de Google Places interesa únicamente la primera tienda
devuelta más cercana al jugador. Del XML se extraen los datos de nombre, tipo e icono.
El interfaz Parcelable que implementa la clase permite que esta pueda ser transmitida
entre distintas Activitys dentro del sistema Android, haciendo uso el sistema de los
métodos readFromParcel y writeToParcel. Es importante en la implementación de
estos métodos respetar el orden en el que los atributos han sido transformados.
Comparado con el documento XML recibido.
Listado 20
<PlaceSearchResponse>
<status></status>
<result>
<name></name>
<vicinity></vicinity>
<type></type>
<type></type>
…
<geometry>
<location>
<lat></lat>
<lng></lng>
</location>
</geometry>
<icon></icon>
<reference></reference>
<id></id>
130
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
</result>
<result>
…
</result>
…resto del documento no relevante
</PlaceSearchResponse>
Las variables serían parseadas de los siguientes elementos:
<name></name> -> name Nombre del establecimiento desde la que juega el jugador. Empleado en estadísticas sin
aplicación real al juego.
<type></type> -> types Indica el o los tipos de establecimiento en el que se encuentra el jugador. Usado para la
toma de recursos por localización.
<icon></icon> -> icon Icono del establecimiento. Usado como element decorative e informative en la interfaz
de usuario.
WeatherInformation
Listado 21
public class WeatherInformation implements Parcelable
{ private String country; private String city; private String weather; private String temp_c; private String wind_dir; private String wind_vel; public WeatherInformation(Parcel in) { readFromParcel(in); } public WeatherInformation() { } public String getCountry() { return country; } public void setCountry(String country) { this.country = country; } public String getCity() { 131
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
return city; } public void setCity(String city) { this.city = city; } public String getWeather() { return weather; } public void setWeather(String weather) { this.weather = weather; } public String getTemp_c() { return temp_c; } public void setTemp_c(String temp_c) { this.temp_c = temp_c; } public String getWind_dir() { return wind_dir; } public void setWind_dir(String wind_dir) { this.wind_dir = wind_dir; } public String getWind_vel() { return wind_vel; } public void setWind_vel(String wind_mph) { this.wind_vel = wind_mph; } public int describeContents() { return 0; } @Override public String toString() { return "WeatherInformation [country=" + country + ", city=" + city + ", weather=" + weather + ", temp_c=" + temp_c + ", wind_dir=" + wind_dir + ", wind_mph=" + wind_vel + "]"; } public void writeToParcel(Parcel dest, int i) { dest.writeString(country); dest.writeString(city); dest.writeString(weather); dest.writeString(temp_c); dest.writeString(wind_dir); dest.writeString(wind_vel); } private void readFromParcel(Parcel in) { country = in.readString(); 132
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
city = in.readString();
weather = in.readString(); temp_c = in.readString(); wind_dir = in.readString(); wind_vel = in.readString(); } public static final Parcelable.Creator CREATOR = new Parcelable.Creator() { public WeatherInformation createFromParcel(Parcel in) { return new WeatherInformation(in); } public WeatherInformation[] newArray(int size) { return new WeatherInformation[size]; } }; } De todos los datos obtenidos de Weather Underground se procesan una mayor cantidad
que el caso anterior. Del XML se extraen los datos de país, ciudad, tiempo, temperatura
en Celsius, velocidad del viento y dirección del viento. El interfaz Parcelable lo
implementa la clase del mismo modo que el caso anterior.
Comparado con el documento XML recibido.
Listado 22
<current_observation>
<credit></credit>
<credit_URL></credit_URL>
<termsofservice ></termsofservice>
<image>
<url></url>
<title> </title>
<link> link>
</image>
<display_location>
<full> </full>
<city> </city>
<state/>
<state_name></state_name>
<country> </country>
<country_iso3166> </country_iso3166>
<zip></zip>
<latitude></latitude>
<longitude></longitude>
<elevation></elevation>
</display_location>
133
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
<observation_location>
<full></full>
<city> </city>
<state/>
<country> </country>
<country_iso3166> </country_iso3166>
<latitude></latitude>
<longitude></longitude>
<elevation></elevation>
</observation_location>
<station_id></station_id>
<observation_time></observation_time>
<observation_time_rfc822></observation_time_rfc822>
<observation_epoch></observation_epoch>
<local_time></local_time>
<local_time_rfc822> </local_time_rfc822>
<local_epoch></local_epoch>
<weather> </weather>
<temperature_string></temperature_string>
<temp_f></temp_f>
<temp_c></temp_c>
<relative_humidity></relative_humidity>
<wind_string></wind_string>
<wind_dir></wind_dir>
<wind_degrees></wind_degrees>
<wind_mph></wind_mph>
<wind_gust_mph/>
<pressure_string></pressure_string>
<pressure_mb></pressure_mb>
<pressure_in></pressure_in>
<dewpoint_string></dewpoint_string>
<dewpoint_f></dewpoint_f>
<dewpoint_c></dewpoint_c>
<heat_index_string> </heat_index_string>
…resto del documento no relevante
</current_observation>
Las variables serían parseadas de los siguientes elementos:
<state_name> </state_name> -> country Al tratarse de una aplicación estadounidense, Weather underground no diferencia entre
estado u país, marcado indicando el país bajo esta etiqueta. Nombre del país desde el
que juega el jugador. Empleado en estadísticas sin aplicación real al juego.
<city> </city> -> city 134
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Nombre de la ciudad desde la que juega el jugador. Empleado en estadísticas sin
aplicación real al juego.
<weather> </weather> -> weather Indica las condiciones climatológicas del lugar donde se encuentra el jugador. Usado
para la toma de recursos por localización.
<temp_c></temp_c> -> temp_c Indica la temperatura del lugar donde se encuentra el jugador. Usado para la toma de
recursos por localización.
<wind_dir></wind_dir>n -> wind_dir Indica la la dirección del viento del lugar donde se encuentra el jugador. Usado para la
toma de recursos por localización.
<wind_mph></wind_mph> -> wind_vel Indica la velocidad del viento del lugar donde se encuentra el jugador. La variable
recibida se recibe en millas por hora que posteriormente es convertida en kilometros por
hora. Usado para la toma de recursos por localización.
Jugadores cercanos
Estos datos necesitan ser tratados si desde el servidor se ha comunicado a la aplicación
que existe uno o más jugadores que compiten con el jugador por los beneficios. Por
cada jugador se establece una relación uno a uno asociada con un valor llamado factor
de victoria o FV. Dicho tiene por defecto el valor 1 y a medida que los jugadores
compiten entre ellos aumenta o decremento.
‐
En caso de ser mayor a 1, el jugador pierde recursos a favor del enemigo.
‐
En caso de ser menor a 1, el enemigo pierde recursos a favor del jugador.
La cantidad que cada recurso debe ser modificado se calcula de forma unificada para
todos los jugadores que los comparten y separadamente para cada recurso
multiplicándolo por un valor conocido como porcentaje de ganancia, calculado
siguiendo la siguiente formula.
135
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
1
1
∑
Siendo PG el porcentaje de ganancia y FV el factor de victoria. A un mayor FV, se obtiene
un menor PG y por lo tanto se obtienen menos recursos.
Este porcentaje únicamente se aplica a los recursos obtenidos en ese momento gracias
a la localización, no a los recursos ya obtenidos y almacenados por el jugador.
SQLite
Únicamente queda la especificación de la clase DBHelper para el acceso a la base de
datos SQLite.
Listado 23
public class DBHelper { private SQLiteDatabase db; private final DBOpenHelper dbOpenHelper; private static final String DATABASE_NAME = "the_shadow_of_fire_database"; private static String tuser = "tuser"; private static String tbuilding = "tbuilding"; private static String tfloor = "tfloor"; private static String[] USER_COLS = new String[] {"name", "email", "first", "last","level", "points", "Science","Construction","Energy","Food","Population"}; private static String[] BUILDING_COLS = new String[] {"type", "pstruct", "pstructmax"}; private static String[] FLOOR_COLS = new String[] {"type", "building_type", "level", "poss", "isbuild", "dinit","dfinish"}; private static String[] TECHTREE_COLS = new String[] {"type", "level", "type_necessary", "level_necessary"}; private static final int DATABASE_VERSION = 39; private static String CREATE_TUSER = "CREATE TABLE tuser (name VARCHAR(45) NOT NULL UNIQUE, email VARCHAR(45) NOT NULL, first LONG NOT NULL, last LONG NOT NULL, level INT NOT NULL, points INT NOT NULL, Science FLOAT NOT NULL, Construction FLOAT NOT NULL, Energy FLOAT NOT NULL, Food FLOAT NOT NULL, Population FLOAT NOT NULL, PRIMARY KEY (name));"; private static String CREATE_TBUILDINDG = "CREATE TABLE tbuilding (type VARCHAR(45) NOT NULL UNIQUE, pstruct INT NOT NULL, pstructmax INT NOT NULL, PRIMARY KEY (type));"; private static String CREATE_TFLOOR = "CREATE TABLE tfloor (type 136
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
VARCHAR(45) NOT NULL, building_type VARCHAR(45) NOT NULL, level INT NOT NULL , poss INT NOT NULL, isbuild INT NOT NULL, dinit LONG NOT NULL, dfinish LONG NOT NULL, PRIMARY KEY (type, building_type, poss), FOREIGN KEY (building_type ) REFERENCES tbuilding (type));"; private static String CREATE_TECHTREE = "CREATE TABLE techtree (type VARCHAR(45) NOT NULL, level int NOT NULL, type_necessary VARCHAR(45) NOT NULL, level_necessary INT NOT NULL, PRIMARY KEY (type, type_necessary), FOREIGN KEY (type ) REFERENCES tfloor (type), FOREIGN KEY (type_necessary ) REFERENCES tfloor (type) ON DELETE NO ACTION ON UPDATE NO ACTION);"; public DBHelper(Context context) { dbOpenHelper = new DBOpenHelper(context, DATABASE_NAME, DATABASE_VERSION); establish(); } // =========================================================== // Inner class // =========================================================== public class DBOpenHelper extends SQLiteOpenHelper { public DBOpenHelper(Context context, String name, int version) { super(context, name, null , version); } @Override public void onUpgrade(SQLiteDatabase database, int oldVersion, int newVersion) { Log.w(DBHelper.class.getName(),"Upgrading database from version " + oldVersion + " to " + newVersion + ", which will destroy all old data"); database.execSQL("DROP TABLE IF EXISTS tuser"); database.execSQL("DROP TABLE IF EXISTS tbuilding"); database.execSQL("DROP TABLE IF EXISTS tfloor"); database.execSQL("DROP TABLE IF EXISTS techtree"); onCreate(database); } @Override public void onCreate(SQLiteDatabase database) { database.execSQL(CREATE_TUSER); database.execSQL(CREATE_TBUILDINDG); database.execSQL(CREATE_TFLOOR); database.execSQL(CREATE_TECHTREE); // ==================================== // DBBuildings // ==================================== database.execSQL("INSERT INTO tbuilding (type, 137
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
pstruct, pstructmax) VALUES ('Colmena',0, 35)");
database.execSQL("INSERT INTO tbuilding (type, pstruct, pstructmax) VALUES ('Baliza',0, 35)"); // Se omiten el resto de operaciones } @Override public void onOpen(SQLiteDatabase db) { super.onOpen(db); } } private void establish() { if(db==null) { db = dbOpenHelper.getWritableDatabase(); } } public void cleanup() { if(db!=null) { db.close(); db = null; } } // =========================================================== // Building dbActions // =========================================================== public void insertBuilding(Building building) { ContentValues values = new ContentValues(); values.put("type", building.getType()); values.put("pstruct", building.getStructuralPoints()); values.put("pstructmax", building.getMaxStructuralPoints()); db.insert(tbuilding, null, values); } // Se omiten el resto de operaciones
Tenemos varias constantes que definen los valores estáticos relacionados con la base
de datos como le nombre, la versión y los nombres de las tablas, además de especificar
las columnas de todas las tablas y las diferentes querys estáticas que podrán realizarse.
La clase interna BBOpenHelper amplia SQLiteOpenHelper, una clase proporcionada por
Android para ayudar a la creación, actualización y apertura de la base de datos
[DBOAPI12]. En esta clase se incluyen los métodos de retro llamada SQLiteOpenHelper,
138
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
en especial, onCreate y onUpgrade. Tras crear una instancia interna de BBOpenHelper
en el constructor si se detecta que la versión de la base de datos es superior a la que se
tiene, se invocan estos dos métodos que actualizan la información. Por último se
establece la conexión.
Ya sólo queda realizar las peticiones necesarias a través de los métodos necesarios,
como insertBuilding. Se omite la implementación del resto por redundancia.
7.2 CombatActivity
La creación de la Activity carece de un interés especial, pues al igual que la Activity
anterior hereda de SimpleGameBase, Activity y sigue las mismas pautas y código para
ejecutarse, con una excepción, la orientación de la pantalla a apaisado, estableciendo la
opción en la clase EngineOptions.
EngineOptions(true, ScreenOrientation.LANDSCAPE_FIXED, new RatioResolutionPolicy(WIDTH, HEIGHT), camera); La clase dispone a su vez de dos Stream de entrada y de salida para recibir y enviar
información al servidor. Una vez establecida la Activity y la conexión, sólo queda
determinar el código para la clase Emisary.
Listado 24
public class Emisary { private String name; private int tipElem; private int level; private int exp; private HashMap attrib; private ArrayList attack; public Emisary(String name, int tipElem, int level, int exp, HashMap attrib, ArrayList attack) { this.name = name; this.tipElem = tipElem; this.level = level; this.exp = exp; this.attrib = attrib; this.attack = attack; } public String getName() { 139
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
} return name; } public void setName(String name) { this.name = name; } public int getLevel() { return level; } public void setLevel(int level) { this.level = level; } public int getExp() { return exp; } public void setExp(int exp) { this.exp = exp; } public HashMap getAttrib() { return attrib; } public void setAttrib(HashMap attrib) { this.attrib = attrib; } public ArrayList getAttack() { return attack; } public Object getAttack(int index) { return attack.get(index); } public void setAttack(ArrayList attack) { this.attack = attack; } public int getTipElem() { return tipElem; } public void setTipElem(int tipElem) { this.tipElem = tipElem; } Los detalles sobre cada elemento han sido especificados en el apartado de diseño. En la
estructura HashMap attrib es donde se almacena la información especificada en
forma de atributos fuerza, defensa y velocidad. Cada emisario dispone de un array de
cuatro posiciones con cuatro ataques distintos, su implementación es.
Listado 25
public class Attack { private String name; 140
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
}
private int tipElem; private HashMap effects; public Attack(String name, int tipElem, HashMap effects) { this.name = name; this.tipElem = tipElem; this.effects = effects; } public String getName() { return name; } public void setName(String name) { this.name = name; } public int getTipElem() { return tipElem; } public void setTipElem(int tipElem) { this.tipElem = tipElem; } public HashMap getEffects() { return effects; } public void setEffects(HashMap effects) { this.effects = effects; } Al igual que la clase emisario, la estructura HashMap effects dispone de los atributos
que confeccionan el ataque, estos son fuerza, precisión y velocidad.
El servidor dispone de esta información para calcular los resultados de los turnos del
combate.
141
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
7.3 Servidor
El servidor posee dos algoritmos críticos para la experiencia de juego. Por un lado
realiza el control periódico de la posición de todos los jugadores, actualizando y
comunicación de la información en tiempo real, por lo que el algoritmo debe ser muy
eficiente y optimizado. Y por otro lado comunica dos jugadores que se estén
enfrentando y ejecuta la lógica del combate.
7.3.1
Algoritmo de localización
El algoritmo de localización basa al cálculo de las distancias calculando la separación
como el módulo o longitud del vector que separa los puntos en los que se encuentran
los jugadores.
Para el caculo de esta distancia se emplea la fórmula clásica.
,
Siendo JxLat la latitud del jugador X, JyLat la latitud del jugador Y, LxLon la longitud del
jugador X y JyLon la longitud del jugador Y.
El empleo de está fórmula concreta calcula la distancia a través de la tierra, no teniendo
en cuenta el hecho de que la tierra es redonda por la complejidad extra que añadiría a
los cálculos [GLDI07]. El uso de esta fórmula tiene otra ventaja y es disminuir
drásticamente el tiempo de cálculo a favor de la rapidez del algoritmo, que va a tener
que ser recalculado cada pocos segundos.
. Pero esto no supone ningún problema. A escalas tan pequeñas, sólo de unos pocos
metros, el error que se comete es ínfimo en comparación. Y jugadores muy alejados
como para que la curvatura sea suficiente nunca van a ser considerados como
cercanos.
Una vez se dispone de la información de localización con la latitud y la longitud de los
jugadores, se calculan las distancias teniendo en cuenta la simetría de la matriz,
realizando solamente las operaciones de la diagonal superior, ahorrando todavía más
tiempo al proceso de cálculo.
142
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Una vez se depone de la información calculada, es determinan las distancias que son
inferiores al umbral de los 25 metros, considerando que esos jugadores se encuentra
cercanos entre sí, como se muestra a continuación en una simulación de ejemplo.
Ilustración 37 - Localización de jugadores
Después de calcular las distancias, se han determinado los jugadores cercanos
(marcados en rojo), el servidos procede entonces a mandar la lista de jugadores a cada
terminal.
143
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
7.3.2
Combate entre jugadores
La lógica de combate es responsabilidad del servidor, encargado de centralizar el
combate y aplicar la lógica del enfrentamiento. A continuación se muestra el código
referente al combate.
Listado 26
public class CombatThread extends Thread
{ private int turn; private Socket userS1; private Socket userS2; private User user1; private User user2; private Emisary emisary1; private Emisary emisary2; private ObjectInputStream oisS1; private ObjectInputStream oisS2; private ObjectOutputStream oosS1; private ObjectOutputStream oosS2; public CombatThread(Socket userS1, Socket userS2, User user1, User user2, Emisary emisary1, Emisary emisary2, ObjectInputStream oisS1, ObjectInputStream oisS2, ObjectOutputStream oosS1, ObjectOutputStream oosS2) { this.userS1 = userS1; this.userS2 = userS2; this.user1 = user1; this.user2 = user2; this.emisary1 = emisary1; this.emisary2 = emisary2; this.oisS1 = oisS1; this.oisS2 = oisS2; this.oosS1 = oosS1; this.oosS2 = oosS2; } public void run() { Random rnd = new Random(); while(Integer.parseInt(emisary1.getAttrib().get("vida").toString()) > 0 || Integer.parseInt(emisary1.getAttrib().get("vida").toString()) > 0) { try { int a1 = oisS1.readInt(); 144
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
int a2 = oisS2.readInt();
Attack attack1 = (Attack) emisary1.getAttack(a1); Attack attack2 = (Attack) emisary2.getAttack(a2); //Determinar el turno float prob = Float.parseFloat(emisary1.getAttrib().get("velocidad").toString()) * Float.parseFloat(attack1.getEffects().get("velocidad").toString()) /( Float.parseFloat(emisary1.getAttrib().get("velocidad").toString()) * Float.parseFloat(attack1.getEffects().get("velocidad").toString()) + Float.parseFloat(emisary2.getAttrib().get("velocidad").toString()) * Float.parseFloat(attack2.getEffects().get("velocidad").toString())); if(rnd.nextFloat()%100 < prob) turn = 1; else turn = 2; //Calculo del daño float str1 = Integer.parseInt(emisary1.getAttrib().get("fuerza").toString()) + Integer.parseInt(emisary1.getAttrib().get("loc_elem").toString()) + Integer.parseInt(attack1.getEffects().get("fuerza").toString()); if(emisary1.getTipElem() == attack1.getTipElem()) str1 *= 1.5; float str2 = Integer.parseInt(emisary2.getAttrib().get("fuerza").toString()) + Integer.parseInt(emisary2.getAttrib().get("loc_elem").toString()) + Integer.parseInt(attack2.getEffects().get("fuerza").toString()); if(emisary2.getTipElem() == attack2.getTipElem()) str2 *= 1.5; //Calculo de la defensa float def1 = (float) (Integer.parseInt(emisary1.getAttrib().get("defensa").toString()) + Integer.parseInt(emisary1.getAttrib().get("loc_elem").toString()) * 0.4); float def2 = (float) (Integer.parseInt(emisary2.getAttrib().get("defensa").toString()) + Integer.parseInt(emisary2.getAttrib().get("loc_elem").toString()) 145
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
* 0.4);
float dam1 = str1 ‐ def2; if(dam1<0) dam1 = 0; float dam2 = str2 ‐ def1; if(dam2<0) dam2 = 0; if(turn == 1) { emisary2.getAttrib().put("vida", Integer.parseInt(emisary2.getAttrib().get("vida").toString()) ‐ dam1); if(Integer.parseInt(emisary2.getAttrib().get("vida").toString()) > 0) { //Jugador 2 NO derrotado emisary1.getAttrib().put("vida", Integer.parseInt(emisary1.getAttrib().get("vida").toString()) ‐ dam2); } } else { emisary1.getAttrib().put("vida", Integer.parseInt(emisary1.getAttrib().get("vida").toString()) ‐ dam2); if(Integer.parseInt(emisary1.getAttrib().get("vida").toString()) > 0) { //Jugador 2 NO derrotado emisary2.getAttrib().put("vida", Integer.parseInt(emisary2.getAttrib().get("vida").toString()) ‐ dam1); } } //Comprobar victoria if(Integer.parseInt(emisary1.getAttrib().get("vida").toString()) < 0) { //Victoria jugador 2 oosS2.writeObject(CombatResults.WINNER); oosS1.writeObject(CombatResults.LOSER); } else if(Integer.parseInt(emisary2.getAttrib().get("vida").toString()) < 0) { //Victoria jugador 1 oosS1.writeObject(CombatResults.WINNER); oosS2.writeObject(CombatResults.LOSER); } 146
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
} } } } catch (IOException e) { e.printStackTrace(); } El bucle principal del combate valora si alguno de los emisarios dispone de una vida
inferior a cero a causa de los ataques, en caso contrario, el combate continúa.
El primer paso es recibir los ataques que han elegido los jugadores desde la aplicación
móvil. Esta sólo enviará un índice entre 1 y 4 que indica el número de ataque realizado
de los 4 disponibles en cada emisario.
El primer cálculo es realizar el orden del turno en que los emisarios actuaran. Disponer
del turno implica tacar antes que el oponente, brindándose la oportunidad de acabar con
el oponente sin darle opciones de responder.
El cálculo se realiza en relación a las velocidades de ambos, según la fórmula:
1
1
2
Si prov. es menor que un número aleatorio entre 0 y 100, el turno lo obtendrá el
jugador1, el turno lo obtendrá el jugador2 en caso contrario.
Una vez determinados los turnos, es necesario calcular la cantidad de daño bruto que
producen ambos emisarios con sus ataques, siendo el daño el que se va a restar
directamente a la vida de su oponente. Para el cálculo del daño se toma como base la
fuerza del emisario, sumando el beneficio por clima y la fuerza del ataque elegido. Para
el cálculo de la defensa se suma el atributo de defensa del emisario más el bonificador
por localización, multiplicando la cantidad por 0.4.
El daño total que va a realizarse se calcula restando la fuerza del ataque con la defensa
de su oponente. En caso de que la defensa sea mayor que el ataque, el daño se anula.
El último paso es restar los daños causados en los emisarios con los datos calculados,
controlando si la vida de alguno de los emisarios desciende por debajo de cero. En ese
147
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
caso se determina como vencedor el jugador cuyo emisario aún disponga de un valor
de vida superior a cero, comunicando el resultado a los jugadores y acabando el
combate.
Si ninguno de los dos ha sido aún derrotado, ambos son informados de la vida que les
resta y el combate continúa hasta que alguno de los dos sea derrotado al fin.
148
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
8
Trabajos futuros y
conclusiones
149
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
150
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
8 Trabajos futuros y conclusiones
8.1 Trabajos futuros
La posibilidad de hacer crecer un juego, especialmente un MMROPG, puede ser
prácticamente infinito. La cuestión de diseño permite tanto pequeñas modificaciones
como grandes cambios estructurales que amplíen la experiencia y complejidad.
Desde el punto de vista de jugabilidad, siempre es sencilla la incorporación de nuevos
edificios y plantas ampliando las posibles estrategias, además de añadir nuevos
emisarios y ataques disponibles. Un gran cambio sería modificar el combate para poder
manejar dos emisarios por jugador en lugar de uno, ampliando aún más si cabe la
importancia de una buena estrategia de cara a un enfrentamiento. Además de introducir
nuevos atributos tanto en los emisarios como en los ataques que aumenten la
complejidad del mismo.
Desde el punto de vista social, la aplicación dispone de un gran potencial. Es posible
permitir a los jugadores a los jugadores la libre asociación a través de alianzas y
comercio, abriendo una vía para las interrelaciones más complejas y profundas más allá
de las planteadas inicialmente por el juego.
Otro gran cambio social es añadir la posibilidad de comunicación online sin importar la
distancia. Es interesante primero discutir las implicaciones reales a la localización que
esta aportación significaría, pero manejada con cierto cuidado puede generar un gran
incentivo.
Desde el punto de vista gráfico, la aplicación no ha contado con verdaderos expertos en
la materia. Por lo que incluir un gran dibujante daría un salto cualitativo visual
importante.
151
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
8.2 Conclusiones
No cabe duda que el desarrollo de un videojuego es altamente gratificante para un
programador por dos claros motivos. Primero, es un autentico reto tecnológico que
necesita de gran dedicación para llevarse a cabo muy por encima de muchos
desarrollos, especialmente si la aplicación cuenta con una cantidad de gráficos
complejos muy elevada. Segundo, es emocionante saber desde el primer momento en
que se piensa en cómo abordar la aplicación, que el objetivo principal es divertir. Todo
esfuerzo, dedicación e idea que se quiera plasmar no sirve si no aporta una mejora en la
diversión del jugador.
El crecimiento de los smartphones en general y de los sistema Android en particular
están experimentando un crecimiento masivo en los últimos años, ostentando el
merecido reconocimiento de ser, junto a IOS de la empresa Apple, la tecnología que más
rápidamente ha sido adaptada en la sociedad [PTIC12], especialmente con la entrada de
los mercados asiáticos al mercado global.
Ilustración 38 – Top de países con mayor número de Smartphones
Otro aspecto importante del sistema Android es que su aplicación no está limitada
únicamente a sistemas de telefonía. Recientemente se ha presentado a la sociedad la
primera consola de sobremesa con núcleo Android, conocida como OUYA, que ha
recibido un apoyo inesperado por parte del público, hasta el punto de obtener mediante
152
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
su campaña de financiación kickstarter 8.500.000$ de los 950.000$ originalmente
solicitados.
Ilustración 39 – Consola OUYA y mando de control OUYA
Esta consola abre un mundo de posibilidades inmenso a los desarrolladores al poder
ofrecer desarrollos paralelos entre dispositivos táctiles y una consola que hace uso de
un mando de control tradicional, muy demandado por la mayoría de consumidores de
videojuegos por su comodidad en contrapartida con la versión táctil. Además pone a
disposición tanto de consumidores como de desarrolladores de un sistema con un
hardware a la vanguardia de la tecnología actual.
Andengine se presenta como un framework complejo cuya API sólo se ha rozado en el
desarrollo. Sin duda el estudio y aplicación de sus capacidades y extensiones van a ser
muy tenidas en cuenta en futuros desarrollos para juegos en Android.
Tecnológicamente, trabajar con Android realmente permite hacerse a la idea del
potencial que tiene como plataforma. Un número cada vez mayor de personas disponen
hoy día de un smartphones que llevan a diario con ellos, abriendo un abanico de
posibilidades abrumadoras. Sin olvidar todas las periféricos adicionales al puro proceso
de computación del móvil cómo GPS, acelerómetro, WiFi, 3G, cámara, etc. Sin lugar a
dudas, la informática y la programación tienen un brillante futuro en esta rama de
investigación y desarrollo.
153
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
154
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
9
Estudio
económico
155
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
156
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
9 Estudio económico
9.1 Personal
Una vez se han definido el conjunto de perfiles necesarios detallados en el plan de
gestión de proyecto (ver Anexo A, apartado 2), se va a estimar los costes de personal del
proyecto. Cada perfil tendrá una tarifa asociada necesario para calcular el gasto total a
computar.
Nº de horas(h) Tarifa hombre/hora (€/h)
Total(€)
Coordinador
5
70
350 €
Director
18
60
1.080 €
Jefe proyecto
45
50
2.250 €
Analista
55
45
2.475 €
Diseñador
35
40
1.400 €
Diseñador gráfico
30
20
600€
Programador
155
30
4.650 €
Total Personal
343
12.805 €
Tabla 20 - Horas/Personal
Para poder desarrollar este proyecto hace falta que exista un coordinador de proyectos
que cobre una tarifa de 70 € la hora, luego hay falta un director de proyecto que
certifiquen y validen el trabajo realizado, cada uno cobre una tarifa de 60€,
posteriormente hace falta la presencia de un Jefe de proyecto que debe planificar las
reuniones con los directores y supervise el trabajo de los demás integrantes del grupo
de trabajo, su tarifa es de 50 €, el siguiente será una Analista que está a cargo de
análisis del problema y de la supervisiones del trabajo de los programadores, su tarifa
es de 45 €, el siguiente será un diseñador encargado de realizar todos los aspectos
técnicos y de jugabilidad que forman parte del juego, su tarifa es de 40 € y por último el
equipo de trabajo estará formado por un diseñador gráfico que realice todos los gráficos
del juego con una tarifa de 20 y programador que codifique toda la plataforma en el
lenguaje seleccionado, su tarifa es de 30 €. Estas tarifas multiplicadas por las horas que
realiza cada uno, da un total de 12.805 € en gasto de personal.
157
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
9.2 Hardware
Para poder implementar la plataforma es necesario adquirir un conjunto de máquinas u
ordenadores. Al tratarse de una aplicación cliente servidor, será necesaria la aportación
de de un servidor con una disponibilidad de 24x7.
Servidor
Se detallan las especificaciones del modelo elegido como servidor para la aplicación.
HP ProLiant ML110 G6 X3430/1GB/250GB
Ilustración 40 - Servidor de aplicaciones
Procesador
Intel Xeon 3430, 2.40GHz, 8MB Cache
Memoria
1GB Memory DDR3 PC3-10600E
Sistema Operativo
Linux Ubuntu Server Edition.
Disco Duro
1 x SATA 3.5 NHP 7.200rpm 250GB
Tarjeta de Red
NC107i PCI-Express Gigabit Ethernet Integrated
Tabla 21 - Especificaciones del servidor
Se ha escogido este modelo por proporcionar una solución asequible y funcional,
facilitando una solución inicial ideal sin limitar la capacidad de crecimiento futuro con
las ranuras de expansión que el propio servidor pone a disposición del equipo,
especialmente en requerimientos de memoria principal que necesitan soportar el
algoritmo de localización. Es necesaria la aportación de un segundo servidor, ambos
conectados a la misma red para la redundancia del servidor con objetivo de mitigar
fallos en caso de caída de uno de los servidores y garantizar un servicio 24x7.
158
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Switch
Se detallan las especificaciones del modelo elegido para interconectar los múltiples
servidores que soportan el servicio.
Netgear Mini Switch Ethernet Gigabit 8 puertos 10/100/1000 Mb GS108
Ilustración 41 - Switch
Cantidad de puertos
8 x Ethernet 10Base-T
Ethernet 100Base-TX
Ethernet 1000Base-T
Velocidad de transferencia
1.06 Gbps
Protocolo de interconexión
Ethernet, Fast Ethernet, Gigabit Ethernet
Tabla 22 - especificaciones del switch
La velocidad soportada por el switch permite la duplicación a gran velocidad de los
datos de un servidor a otro en tiempo real sin comprometer las necesidades de ancho
de banda para las conexiones que provengan del exterior. Además el dispositivo aporta
suficientes puertos para garantizar una futura incorporación de nuevos servidores de
aplicación o la inclusión de servidores dedicados a la base de datos.
159
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Router
Se detallan las especificaciones del modelo elegido para la conexión de la red interna
con el exterior.
Linksys WRT54GL Wireless Router Neutro 54Mbps Linux
Ilustración 42 - Router de salida
Velocidad
54 Mbps
Seguridad
PSK, WEP - 128-bit, WEP - 64-bit, WPA,
WPA2
Protocolo de trasmisión
IEEE 802,3, IEEE 802.CÚ, IEEE 802.11B,
IEEE 802.11G
Tabla 23 - Especificaciones del router
El último dispositivo necesario para la configuración de la red de servidores. Este router
permite la interconexión de la red interna con el exterior, comunicando los servidores
con los clientes. Además tiene el segundo propósito de permitir a un pequeño equipo de
desarrollo o de mantenimiento compartir la red para el trabajo y acceso a Internet,
garantizando el ancho de banda necesario.
160
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Inventario
Unidad
Precio (€)
HP ProLiant ML110 G6 X3430/1GB/250GB
315,00 €
HP ProLiant ML110 G6 X3430/1GB/250GB
315,00 €
Linksys WRT54GL Wireless Router Neutro 54Mbps Linux
44,95 €
Netgear Mini Switch Ethernet Gigabit 8 puertos 10/100/1000 Mb GS108
50,81 €
Total
725,76 €
Tabla 24 - Inventario
9.3 Coste del proyecto
En la siguiente tabla se muestra una tabla resumen con todos los costes asociados al
desarrollo de este proyecto, se ha realizado un análisis de los costes de recursos
humanos, diferenciando que tipos de perfiles son necesarios, también se ha realizado
un análisis de las maquinas en las que se implementará la aplicación.
Tipo
Coste (€)
Personal
12.805,00 €
Hardware
725,76 €
Total
13.530,00 €
Tabla 25 - Coste del proyecto
Por lo tanto el coste final del proyecto asciende 13.530,00 €.
161
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
162
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Anexo A
Plan de gestión
del proyecto
163
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
164
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Anexo A.
Plan de gestión del
proyecto
Realizar un plan de gestión de proyecto permitirá de manera fiable estimar cubre todos
los aspectos relacionados con la gestión del proyecto.
1 Resumen del proyecto
El objetivo de este proyecto es la programación de un MMORPG basado en localización
para el sistema móvil Android de Google.
9.4 Estructura de división del trabajo
A continuación se muestra la estructura de división del trabajo completa que forma
parte de la aplicación.
165
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Ilustración 43 - estructura de división del trabajo
9.5 Descripción de paquetes de trabajo
Descripción de cada uno de los paquetes de trabajo aparecidos en la estructura de
división del trabajo.
Nombre del paquete
Cliente/servidor
Índice de la actividad
A1.1.1
Responsable/s
Antonio Rodríguez López
Horas asignadas
50
Entradas
Cuaderno de desarrollo
Procesos
Elaborar Clases Cliente Android
Elaborar Clases Servidor
Clases comunicación Cliente/Servidor
Clases tratamiento XML
Incluir AndEngine proyecto Cliente
Salidas
Proyecto AndEngine incluido
166
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Clases Cliente
Clases servidor
Herramientas
Servidor lenguaje Java
Cliente Lenguaje Java Android
Android API
AndEngine API
Nombre del paquete
Geolocalización
Índice de la actividad
A1.1.2
Responsable/s
Antonio Rodríguez López
Horas asignadas
55
Entradas
Cuaderno de desarrollo
Android API
Procesos
Geolocalizar maquina cliente
Realizar clases para la geolocalización
Integrar la geolocalización con AndEngine
Comunicación con Google Places y Weather Underground
Salidas
Clases para la geolocalización
Herramientas
Cliente Lenguaje Java Android
Android API
AndEngine API
Nombre del paquete
Lógica de la base
Índice de la actividad
A1.1.3
Responsable/s
Antonio Rodríguez López
Horas asignadas
65
Entradas
Cuaderno de desarrollo
Documento de diseño
Android API
Procesos
Elaborar las clases de localización
Elaborar las clases de tratamiento de la información e
167
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
localización
Salidas
Clases necesarias para la localización incluida en el paquete
localition
Herramientas
Android API
GPS Android
Nombre del paquete
Lógica combate jugador-jugador
Índice de la actividad
A1.1.4
Responsable/s
Antonio Rodríguez López
Horas asignadas
35
Entradas
Cuaderno de desarrollo
Documento de diseño
Android API
Procesos
Elaborar las clases con la lógica de combate jugadorjugador
Salidas
Clases necesarias para el combate jugador-jugador
Herramientas
Android API
Andengine API
Nombre del paquete
Fondos
Índice de la actividad
A1.2.1
Responsable/s
Antonio Rodríguez López
Horas asignadas
20
Entradas
Documento de diseño
Procesos
Elaborar las imágenes de los fondos de la aplicación.
Salidas
Imágenes de los fondos de la aplicación
Herramientas
Inkscape
GIMP 2
168
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Nombre del paquete
Personajes
Índice de la actividad
A1.2.2
Responsable/s
Antonio Rodríguez López
Horas asignadas
10
Entradas
Documento de diseño
Procesos
Elaborar las imágenes de los personajes de la aplicación.
Salidas
Imágenes de los personajes de la aplicación
Herramientas
Inkscape
GIMP 2
Nombre del paquete
Sistema de juego
Índice de la actividad
A1.3.1
Responsable/s
Antonio Rodríguez López
Horas asignadas
15
Entradas
Lista de requisitos
Procesos
Elaborar la sección del documento de diseño referente al
sistema de juego
Salidas
Sección de sistema de juego del documento de diseño
Herramientas
N/A
Nombre del paquete
Diseño de la base
Índice de la actividad
A1.3.2
Responsable/s
Antonio Rodríguez López
Horas asignadas
10
Entradas
Lista de requisitos
Procesos
Elaborar la sección del documento de diseño referente al
diseño de la base
Salidas
Sección del diseño de la base del documento de diseño
Herramientas
N/A
169
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Nombre del paquete
Diseño de personajes
Índice de la actividad
A1.3.3
Responsable/s
Antonio Rodríguez López
Horas asignadas
5
Entradas
Lista de requisitos
Procesos
Elaborar la sección del documento de diseño referente al
diseño de personajes
Salidas
Sección del diseño de personajes del documento de diseño
Herramientas
N/A
Nombre del paquete
Sistema de combate
Índice de la actividad
A1.3.4
Responsable/s
Antonio Rodríguez López
Horas asignadas
5
Entradas
Lista de requisitos
Procesos
Elaborar la sección del documento de diseño referente al
sistema de combate
Salidas
Sección del sistema de combate del documento de diseño
Herramientas
N/A
Nombre del paquete
Documentación
Índice de la actividad
A3
Responsable/s
Antonio Rodríguez López
Horas asignadas
35
Entradas
Clases codificadas
Ejecutable del juego desarrollado
Anexo B
Lista de requisitos
Procesos
Elaborar la documentación del proyecto
Salidas
Documentación del proyecto
Herramientas
N/A
170
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
10 Equipo de trabajo
Detalle de la estructura organizativa del personal asignado para el proyecto.
10.1
Organigrama del equipo de trabajo
En este árbol se detallan los puestos que serán necesarios para completar el proyecto,
descendiendo en su nivel jerárquico. Un nivel inferior indica que el puesto superior será
responsable del inferior, y una línea horizontal indica que el puesto sirve como ayuda o
“staff” del superior, sin tener que ser responsable jerárquico del mismo.
Alfonso Villar Chicharro
Director de Proyecto
David Contreras Bárcenas
Coordinador de proyecto
Antonio Rodríguez López
Jefe de proyecto
Antonio Rodríguez López
Diseño
Antonio Rodríguez López
Diseño Gráfico
Antonio Rodríguez López
Analista
Antonio Rodríguez López
Programador
Ilustración 44 - Equipo de trabajo
171
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
10.2
Descripción de puestos de trabajo
En este apartado se describirá de manera detallada cada uno de los perfiles mostrados
en el organigrama. La descripción está dividida en el código usado para las
responsabilidades a nivel general que ostenta, las horas asignadas, una descripción
detallada y las habilidades requeridas para desempeñar el puesto.
Nombre del puesto
Director de proyecto
Responsabilidades
Correcta asignación de recursos y supervisión general
Descripción
Es el último responsable del proyecto. Será el encargado de aprobar el plan de proyecto
y controlar el seguimiento de los hitos.
Sus tareas principales serán:
Coordinación de las unidades organizativas y supervisión del trabajo realizado
Apoyo al Jefe de Proyecto.
Comprobación del cumplimiento de plazos.
Su labor principal consistirá en el aseguramiento de que los recursos del proyecto son
asignados de forma razonable y eficaz, garantizando el cumplimiento correcto de los
objetivos marcados como hitos para el desarrollo del proyecto. Debe tener
conocimientos probados de gestión y amplia experiencia en el sector del proyecto.
172
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Nombre del puesto
Responsabilidades
Jefe de proyecto
Elaboración del plan del proyecto y coordinar efectivamente la
totalidad del proyecto
Descripción
Es el responsable principal de la correcta ejecución del proyecto. Tendrá a su cargo al
personal necesario para poder construir el proyecto pedido, y la mayoría de los
entregables finales serán responsabilidad suya. Su primera labor será elaborar el plan
general de proyecto y entregárselo al cliente, y una vez aceptado, vigilará que todo
marche correctamente elaborando informes de situación periódicos.
Aparte de las labores mencionadas, será responsabilidad suya:
Controlar el nivel de cumplimiento de los objetivos del proyecto
Cumplimiento de la metodología establecida en el plan de proyecto
Se encargará asimismo de coordinar al analista y al asesor legal de manera directa, ya
que los programadores están bajo la responsabilidad de los analistas. Su labor consiste
en ajustar todo lo posible el desarrollo del proyecto al planificado en el PGP, y justificar
las posibles desviaciones que aparezcan.
Es necesario que tenga elevada experiencia en la gestión de proyectos y de equipos, ya
que deberá ser capaz de resolver conflictos interpersonales y reconocer riesgos que
puedan afectar al éxito del proyecto.
Asimismo, debe ser capaz de tener una política de comunicación abierta, para que cada
participante pueda expresar su opinión; pero a la vez imponer la autoridad que ostenta
dentro del proyecto citado. La reducida duración del proyecto hace que sea necesario
un estricto control del cumplimiento de objetivos, y una medición exhaustiva de las
desviaciones.
173
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Nombre del puesto
Analista
Responsabilidades
Diseño del sistema, módulos y sub-módulos de la aplicación
Descripción
Los analistas serán los encargados de pasar a diagramas, pseudocódigo, etc.
adecuados a los requerimientos del proyecto. Diseñarán una solución que cumpla con
los requisitos y la plasmarán en un lenguaje más cercano al puro código. Asimismo,
evaluarán las distintas opciones para implementar la solución diseñada.
Sus tareas principales, de manera forma, serán:
Diseño del sistema, dividido en dos subtareas:
Modelo Conceptual del sistema
Modelo funcional del sistema
Coordinación del trabajo realizado por cada uno de los programadores asignados
Nombre del puesto
Programador
Responsabilidades
Construcción de la solución diseñada por los analistas
Descripción
Será el encargado de construir el código necesario para que la aplicación se ponga en
marcha. Una vez diseñado el sistema por parte de los analistas, ellos serán los que
pasarán las especificaciones al código fuente final, y se asegurarán de que el sistema
cumple los requisitos para los que fue diseñado.
Formalmente, su labor consiste en:
Creación del código fuente final
Probar el código
Crear un manual de usuario
En la aplicación a desarrollar, los perfiles se especializan: cada programador será
174
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
responsable del desarrollo de una de las secciones de la aplicación, tanto servidor como
aplicación móvil. Deberán conocer a fondo el lenguaje en el que se determine el
desarrollo de la plataforma. Asimismo es conveniente (aunque no necesario) haber
realizado algún proyecto previo que implicara el desarrollo de un área como la que va a
estar encargado cada uno de ellos.
Nombre del puesto
Diseñador gráfico
Responsabilidades
Construcción de los gráficos y arte del juego
Descripción
La labor de los artistas es crear los gráficos que tiene el juego, los elementos visuales y
sonoros que el usuario percibe. El diseño artístico deberá atenerse a los requisitos de
arte definidos, siendo labor de los programadores la integración final de los diseños en
la aplicación.
Este perfil es el más creativo al crear tanto los gráficos como la música y los efectos de
sonido que acompañan el juego. Es necesario tener una formación artística y un gran
talento para poder desarrollar bien estos elementos siendo necesarios conocimientos
avanzados de diseño asistido por ordenador y de dibujo vectorial.
Nombre del puesto
Diseñador
Responsabilidades
Construcción de los gráficos y arte del juego
Descripción
La labor del diseñador es definir los aspectos que relacionan al usuario con el juego, que
posteriormente necesitan hacerse realidad a manos de los artistas y los
programadores.
Es el encargado de definir cómo van a ser todos los aspectos y trasfondo, junto con la
manera en la que se juega. Define el estilo de juego y el sistema de juego, la curva de
dificultad, los personajes, la historia, escenarios y los niveles, etc. Aspectos que tienen
un impacto directo en la valoración del juego por parte del usuario.
175
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
11 Planificación
Reparto de horas asignadas para la realización de cada paquete de actividades.
Diseñador
Diseñador Gráfico
Programador
Total
Analista
horas/actividad
Jefe proyecto
[A1.1.1]
0
20
0
0
35
55
[A1.1.2]
0
15
0
0
40
55
[A1.1.3]
0
10
0
0
55
65
[A1.1.4]
0
10
0
0
25
35
[A1.2.1]
0
0
0
20
0
20
[A1.2.2]
0
0
0
10
0
10
[A1.3.1]
0
0
15
0
0
15
[A1.3.2]
0
0
10
0
0
10
[A1.3.3]
0
0
5
0
0
5
[A1.3.4]
0
0
5
0
0
5
[A3]
45
0
0
0
0
35
Horas/persona
45
55
35
30
155
320
Tabla 26 - Planificación
Se ha tomado la decisión de que se utilizase la metodología ágil Scrum para el control
de la planificación del proyecto. La propia metodología Scrumm otorga el diagrama de
burndown o quemado que indica de una forma global el progreso total de proyecto
como una suma del porcentaje finalizado de cada una de las pequeñas tareas que se
han proyectado he indicado el los paquetes de trabajo. Midiendo el proceso de
desarrollo en Sprints de una semana de duración Al comenzar cada Sprint, se determina
el índice de avance de cada paquete y se realiza un estudio determinado para qué
aspectos concretos pueden mejorarse o ya cuentan con una complejidad e índice de
desarrollo adecuada.
176
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Ilustración 45 - Ejemplo diagrama de quemado de Pivotal Tracker
La herramienta usada para este fin es Pivotal Tracker. Esta aplicación web otorga una
potente herramienta que permite una gestión ágil fácil y rápida, siendo su mayor virtud
poder ser accedida desde cualquier lugar con conexión a Internet y que aporta todas las
herramientas necesarias para la gestión de los paquetes de trabajo, incluyendo
diagramas de quemado y posibilidad de trabajo en equipo.
177
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
178
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Bibliografía
[UPC12]
Facultat d'Informàtica de Barcelona, Historia de los videojuegos.
http://www.fib.upc.edu/retro-informatica/historia/videojocs.html
Ultimo acceso 26/08/2012
[CLA12]
Clarín-Revista de divulgación
http://www.clarin.com/internet/juegos-smartphones-mueven-dineroconsola_0_593340865.html-Último acceso 26/08/2012 - Ultimo acceso
26/08/2012
[Rapsoso12]
Raposo , Martín, Graduate School of Business-Centro de Investigación en
Entretenimiento y Medios-Universidad de Palermo
[TEVV11]
Tu experto en juegos, blog especializado
http://www.tuexpertojuegos.com/2010/03/24/los-videojuegos-venden-enespana-mas-que-el-cine-y-la-musica-juntos/-Ultimos acceso 26/08/2012
[WIKIMM12]
Wikipedia-
Videojuego
de
rol
multijugador
masivo
en
línea-
http://es.wikipedia.org/wiki/Videojuego_de_rol_multijugador_masivo_en_l%C3%
ADnea-Ultimo acceso 15/07/2012
[NEOT09]
N+ Neoteo ABC-Revista especializada.
http://www.neoteo.com/la-historia-de-juegos-de-rol-online-mmorpg-Último
acceso 20/08/2012
[SIONO10]
Sion
Dream.
Saltares,
David.
“Games
desing
and
programming”
http://siondream.com/blog/games/game-design-document/-Ultimo
acceso
26/08/2012
[Ableson11]
Ableson, Fran W., Sen, Rubi, King, Chris (2011) “Android Guia para
desarrolladores” Anaya
[GOAAPI12]
Android API, Google.Application fundamentals
http://developer.android.com/guide/components/fundamentals.html-Ultimo
179
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
Acceso 26/08/20112 Ultimo acceso 26/08/2012
[ANDAPI12]
Andengine GLES2 API, Nicholas Gramlich
https://github.com/nicolasgramlich/AndEngine
Ultimo acceso 26/08/20112
[IPCCVA12]
Institut Puig Castelar, “Android: Ciclo de vida de las actividades y otros detalles”
http://elpuig.xeill.net/Members/vcarceler/misc/android/ciclo-de-vida-de-lasactividades-y-otros-detalles-de-la-plataforma-Ultimo acceso 26/08/2012 Ultimo acceso 26/08/2012
[SQLIT12]
About SQLite, SQLite
http://www.sqlite.org/about.html - Ultimo acceso 26/08/2012
[ANDFO10]
Andengine Forum, Andengine comunity
http://www.andengine.org/forums/announces/andengine-gles2-pre-releaseon-december-23rd-t6097.html - Ulitmo acceso 26/08/2012
[GLES12]
Matim Development 2012.
https://sites.google.com/site/matimdevelopment/gles1-versus-gles2--comparison
[Zechner11]
Zechner, Mario (2011). “Desarrollo de juegos Android”, Anaya
[GPAP12]
Google Places API.
https://developers.google.com/maps/documentation/places/?hl=es – Ultimo
acceso 26/08/2012
[ANDBLG12]
Andengine Blog, Nicholas Gramlich
http://www.andengine.org/blog/ - Ultimo acceso 26/08/2012
[WUAP12]
Weather underground API.
http://www.wunderground.com/weather/api/d/docs
Último acceso 26/08/2012
[DBOAPI12].
DBOpenHelper, Android API
180
UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
http://developer.android.com/reference/android/database/sqlite/SQLiteOpenH
elper.html
Ultimo acceso 26/08/2012
[GLDI07]
Franchu's Lair, GIS: Cálculo de distancias sobre la Tierra
http://blog.franchu.net/2007/11/16/gis-calculo-de-distancias-sobre-la-tierra/
- Ultimo acceso 26/08/2012
[PTIC12]
Portal TIC Revista especializada en las TIC
http://www.europapress.es/portaltic/sector/noticia-ios-android-experimentancrecimiento-mas-rapido-historia-tecnologia-20120829111322.html - Ultimo
acceso 30/08/2012
181