Tesis-Videojuego Multigenero GARCIA REILLO EDUARDO

Grado en Ingeniera Multimedia
Trabajo Fin de Grado

Autor:
Eduardo Garca Rello
Tutor/es:
Carlos Jos Villagr Arnedo
Francisco Jos Gallego Durn
Enero 2014
Videojuego Multignero
Eduardo Garca Rello
ndice de contenidos
1. Introduccin .............................................................................................................................. 8
1.1 Panorama actual del sector del videojuego ........................................................................ 8
1.2 Videojuegos Multignero en la actualidad ......................................................................... 9
1.3 Motivacin ........................................................................................................................ 12
1.4 Objetivos del proyecto ...................................................................................................... 13
2. Diseo y Especificacin ........................................................................................................... 15
2.1 Argumento ........................................................................................................................ 15
2.2 Objetivo del juego ............................................................................................................. 16
2.3 Mecnica del juego ........................................................................................................... 17
2.4 Metodologa empleada ..................................................................................................... 19
2.5 Gneros incluidos .............................................................................................................. 20
2.5.1 Accin / Plataformas .................................................................................................. 20
2.5.2 Shoot Em Up .............................................................................................................. 22
2.5.3 RPG ............................................................................................................................. 23
2.5.4 Carreras ...................................................................................................................... 24
2.5.5 Vertical ....................................................................................................................... 25
2.6 Herramientas utilizadas .................................................................................................... 26
2.7 Evolucin en el planteamiento.......................................................................................... 27
2.7.1 Motor de Fsicas propio VS Box2D ............................................................................. 27
2.7.2 Un Sprite para dominarlos a todos ............................................................................ 28
2.8 Diseo Especfico VS Diseo Genrico .............................................................................. 29
2.9 Diseo Visual ..................................................................................................................... 32
2.10 Diseo Sonoro ................................................................................................................. 38
3. Desarrollo e Implementacin .................................................................................................. 39
3.1 Patrones de Diseo empleados ........................................................................................ 39
3.1.1 Patrn Fachada........................................................................................................... 40
3.1.2 Patrn Singleton ......................................................................................................... 40
3.2 Gestor de Efectos ............................................................................................................. 41
3.2.1 Efectos Independientes .............................................................................................. 42
3.2.2 Efectos Dependientes ................................................................................................ 44
3.3 Gestor de Partculas .......................................................................................................... 47
3.3.1 Emisores de tipo Explosin ........................................................................................ 49
Eduardo Garca Rello
3.3.2 Emisores de tipo Fuente............................................................................................. 50

3.4 Gestor de Recursos ........................................................................................................... 51
3.5 Motor de Fsicas ................................................................................................................ 52
3.5.1 Fuerzas ....................................................................................................................... 53
3.5.2 Gestor de Colisiones ................................................................................................... 54
3.5.2.1 Colisiones Ente con Ente ..................................................................................... 55
3.5.2.2 Colisiones Ente con Tile ....................................................................................... 56
3.5.2.3 Colisiones Ente con Obstculo ............................................................................ 61
3.6 Parseadores y sistema de archivos ................................................................................... 63
3.6.1 Parseador de Indicadores de Lneas ........................................................................... 63
3.6.2 Parseador de SpriteSheets ......................................................................................... 64
3.6.3 Parseador de Animaciones ......................................................................................... 65
3.6.4 Parseador de Sprites .................................................................................................. 66
3.6.5 Parseador de Listas de Enemigos ............................................................................... 68
3.6.6 Parseador de Entes..................................................................................................... 69
3.6.7 Parseador de Tiles Animados ..................................................................................... 70
3.6.8 Parseador de Tiles Especiales ..................................................................................... 71
3.6.9 Parseador de Mapas................................................................................................... 72
3.6.10 Parseador de Textos ................................................................................................. 74
3.7 Entes .................................................................................................................................. 75
3.7.1 Seres Atacables .......................................................................................................... 75
3.7.1.1 Personaje Principal .............................................................................................. 76
3.7.1.1.1 Sistema de Niveles ....................................................................................... 76
3.7.1.1.2 Movimientos Base ........................................................................................ 78
3.7.1.1.3 Habilidades ................................................................................................... 79
3.7.1.2 Enemigos ............................................................................................................. 85
3.7.1.2.1 Inteligencia Artificial..................................................................................... 86
3.7.1.3 Obstculos ........................................................................................................... 92
3.7.2 Proyectiles .................................................................................................................. 93
3.7.3 Objetos ....................................................................................................................... 93
3.7.4 NPCs ........................................................................................................................... 94
3.8 Tiles ................................................................................................................................... 94
3.8.1 Pantallas basadas en Tiles .......................................................................................... 95
3.8.2 Tilesets........................................................................................................................ 96
Eduardo Garca Rello
3.8.3 Tipos de Tiles .............................................................................................................. 96

3.9 Sprites................................................................................................................................ 97
3.9.1 Animaciones en Sprites .............................................................................................. 98
3.10 Gestor de Textos ............................................................................................................. 99
3.10.1 Dilogos .................................................................................................................. 100
3.10.2 Indicadores ............................................................................................................. 101
3.10.3 Creacin de textos.................................................................................................. 101
3.10.3.1 Textos generados desde Fichero ..................................................................... 102
3.10.3.2 Textos generados desde Nmero ................................................................... 103
3.10.3.3 Textos generados desde Cadena de caracteres .............................................. 103
3.11 Gestor de Mens ........................................................................................................... 103
3.12 Gestor de Audio ............................................................................................................ 105
3.13 Controles ....................................................................................................................... 106
3.14 Eventos .......................................................................................................................... 107
4. Conclusiones.......................................................................................................................... 108
5. Lneas futuras ........................................................................................................................ 109
6. Agradecimientos ................................................................................................................... 110
7. Bibliografa ............................................................................................................................ 111
Eduardo Garca Rello
ndice de figuras
Figura 1.1 Metal Slug usando Accin / Plataformas ................................................................ 10
Figura 1.2 Metal Slug usando Shoot Em Up ............................................................................ 10
Figura 1.3 Metal Slug usando Shoot Em Up con scroll vertical ............................................... 11
Figura 1.4 Chrono Trigger usando RPG por turnos .................................................................. 11
Figura 1.5 Chrono Trigger usando el gnero de Carreras ........................................................ 12
Figura 2.1 Diagrama de etapas en FDD .................................................................................... 19
Figura 2.2 Arte conceptual del personaje ................................................................................ 32
Figura 2.3 Personaje ampliado (izquierda) y tal cual se ve en el juego (derecha) ................... 33
Figura 2.4 Hoja de sprites del personaje .................................................................................. 34
Figura 2.5 Hoja de sprites de los enemigos .............................................................................. 35
Figura 2.6 Hoja de sprites de los efectos del juego .................................................................. 36
Figura 2.7 Hoja de sprites para los elementos de los mens ................................................... 37
Figura 2.8 Tiles utilizados para las distintas pantallas .............................................................. 38
Figura 2.9 Fondo para escenarios con temtica naturaleza ................................................. 38
Figura 3.1 Efecto ChoqueDisparo al disparar sobre una piedra ............................................... 43
Figura 3.2 Efecto MuerteSerAtacable al eliminar un enemigo ................................................ 43
Figura 3.3 Efecto InicioDisparo justo en la boca del arma ....................................................... 44
Figura 3.4 Efecto GolpeSerAtacable generado en el lugar de impacto con el enemigo .......... 44
Figura 3.5 Efecto DamageSerAtacable mostrado sobre el enemigo al recibir un golpe .......... 45
Figura 3.6 Barra de vida mostrndose sobre el enemigo al poco de recibir dao................... 46
Figura 3.7 Efecto al recoger el consumible de Salud................................................................ 47
Figura 3.8 Diagrama funcional de ComprobarColisionesEntes ................................................ 55
Figura 3.9 Orden de prioridades a la hora de comprobar colisiones ....................................... 59
Figura 3.10 Ente atravesando tiles de terreno ......................................................................... 60
Figura 3.11 Ente ubicado correctamente encima del Tile objetivo ......................................... 61
Figura 3.12 Obstculo con la variable esPlataforma a true .................................................. 62
Figura 3.13 Obstculo con la variable esPlataforma a false ................................................. 62
Figura 3.14 Ejemplo de asociacin entre un indicador de lnea y su fichero ........................... 64
Figura 3.15 Informacin en archivo de texto y textura en Spritesheet de tiles animados ...... 71
Figura 3.16 Men de pausa con estadsticas ........................................................................... 77
Figura 3.17 Ataque lateral 1 ..................................................................................................... 80
Figura 3.18 Ataque lateral 2 ..................................................................................................... 81
Figura 3.19 Utilizando el ataque cargado ................................................................................. 81
Eduardo Garca Rello
Figura 3.20 Disparo con la pistola ......................................................................................... 82

Figura 3.21 Lanzando Disparo Cargado .................................................................................... 82
Figura 3.22 Usando transmutador de energa ......................................................................... 83
Figura 3.23 Escudo de energa rodeando al personaje ............................................................ 84
Figura 3.24 Ametralladora mientras se desplaza hacia arriba ................................................. 84
Figura 3.25 Proyectil pequeo que precede a la Bomba de Energa ....................................... 85
Figura 3.26 Bomba de Energa una vez explotando ................................................................. 85
Figura 3.27 Personaje enfrente de un NPC que emite dilogo ................................................ 86
Figura 3.28 Dilogo emitido por el NPC en concreto ............................................................... 87
Eduardo Garca Rello
ndice de abreviaturas
RPG: Role Playing Game, o juego de rol.
NPC: Non Player Character, o personaje no controlado por un jugador.
IA: Inteligencia Artificial.
HUD: Heads-Up Display, o pantalla de visualizacin frontal.
SFML: Simple and Fast Multimedia Library, o librera multimedia rpida y simple.
Eduardo Garca Rello
1. Introduccin
1.1 Panorama actual del sector del videojuego
Si echamos la vista atrs los videojuegos han pasado de ser casi ignorados o catalogados de
perjudiciales, a ser uno de los elementos con mayor presencia en el da a da de casi cualquier
persona. El mundo de los videojuegos ha ido establecindose en la vida cotidiana de las
personas de forma progresiva, de no saber nada, a conocerse hasta personajes principales
incluso sin tener aficin por los videojuegos o haberlos jugado en la vida, ya solo por lo
presente que estn en la sociedad. Partiendo de conceptos genricos e impersonales como
comecocos o marcianitos que todo el mundo conoce y asocia a videojuegos, a personajes
como Mario o Pikachu que ya son conocidos mundialmente, incluso sin necesidad de que la
gente sepa de donde proceden originalmente.
Podemos decir, por tanto, que los videojuegos forman un pilar base en el entretenimiento de
las personas en la actualidad, superando incluso al cine en ingresos. Muchos juegos
demuestran el potencial que pueden alcanzar de varias formas: de forma visual, con grandes
efectos especiales, cinemticas y grficos realistas; de forma sonora, contando con bandas
sonoras reconocidas por todo el mundo y unos efectos sonoros que potencian la inmersin del
jugador; en cuanto al guin, con historias que dejan huella en los jugadores durante aos; o en
cuanto a jugabilidad, ofreciendo una experiencia de juego entretenida e incluso en algunos
casos siendo considerada deporte por su complejidad (sobre todo en juegos de estrategia).
Y si ha llegado a tantsimas personas la aficin por jugar videojuegos es principalmente por su

catlogo, pudiendo variar desde juegos de estrategia en tiempo real, juegos de rol, de accin
en primera y tercera persona, de carreras y deportes, juegos casuales como puzles y
rompecabezas Hay una inmensa variedad de gneros y una ingente cantidad de juegos para
cada gnero, por lo que el catlogo es gigantesco a la hora de decidir cul jugar.
Adems de toda esta oferta, importa mucho a la hora de establecerse en la vida de las
personas el hecho de cmo se consigue. Hasta hace escasos aos slo se poda conseguir
desplazndose hasta el videoclub o la tienda de videojuegos ms cercana y adquiriendo el
ttulo fsicamente. Sin embargo con la popularidad que ha ganado internet, empezaron a
aumentar de forma exponencial las compras de videojuegos de forma online, lo que haca ms
sencillo poder adquirir ttulos desde la casa de cada uno. Actualmente internet ha cambiado
por completo la forma de adquirir juegos, de modo que ya no solo se pueden comprar copias
Eduardo Garca Rello
fsicas de videojuegos de forma online, sino que gran parte de las empresas que desarrollan
ttulos ofrecen copias digitales que pueden comprarse en plataformas de juegos online, tales
como Steam, GoG o Origin, permitiendo adquirir un ttulo y jugarlo de forma casi instantnea.
Esta facilidad a la hora de adquirir y jugar videojuegos ha permitido que stos estn mucho
ms cerca de los usuarios que nunca, lo cual sumado al creciente uso de las redes sociales,
permite que todo el mundo pueda disfrutar de los videojuegos en cualquier momento y en
cualquier lugar.
1.2 Videojuegos Multignero en la actualidad

Con el paso de los aos los videojuegos han ido evolucionando hasta tener un sinfn de
gneros que permiten abarcar cualquiera que sea el gusto del usuario. Se han asentado de tal
forma que existen unas ramas que catalogan los juegos si pertenecen a ellas o no, como por
ejemplo los juegos de rol, los de plataformas o los comnmente denominados marcianitos,
entre muchsimos otros. Esto permite que, segn los gustos de cada uno, cada usuario se
decante por un juego u otro segn pertenezca a la rama o ramas de juegos por las que sienta
predileccin. Esto en general es algo beneficioso ya que permite una gran variedad de juegos
as como de empresas especializadas en ellos, pudiendo crear y mejorar juegos y sagas que
continen con un gnero hasta pulirlo en uno u otro sentido.
Aun as esto es un arma de doble filo, ya que el mismo hecho de hacer que el usuario elija una
rama u otra dificulta que existan juegos que comprendan varias ramas en uno mismo. Esto
puede estar motivado en parte por el riesgo que supone que un juego contenga distintos
gneros, ya que no todo el mundo puede que llegue a ser fan de todos los gneros que incluya,
haciendo que el usuario que por ejemplo no le guste el RPG, se aburra cuando le toque la fase
de RPG en un juego que incluya muchos gneros. No obstante este riesgo tambin implica
beneficios, ya que al igual que con cualquier gnero, su maduracin y continua mejora
permiten que los juegos multignero anen todos los aspectos de una forma ms armnica y
no demasiado tosca.
Debido a este riesgo no existen muchos juegos que incluyan dos o ms gneros en uno
mismo utilizndolo como parte del ncleo del juego, ya que como mucho en la mayora de
juegos se encuentra algn nivel de entre muchos o bien como simple minijuego algn gnero
distinto al principal. Por esto el catlogo de este tipo de juego de juegos es muy reducido y
Eduardo Garca Rello
por ende no ha sido perfeccionado lo suficiente como para hacerse hueco ante las principales
ramas atmicas en gneros.
Sin embargo existen videojuegos muy populares en los cuales se incluy algn nivel con otro
gnero distinto al principal y que todos los que hemos jugado a esos juegos agradecimos por
que aportaba un toque diferente y bastante entretenido a ste. Un ejemplo de estos juegos es
el archiconocido Metal Slug, que fusion de una magnfica manera el gnero base del juego
(Accin/Plataformas) con el gnero Shoot Em Up. A pesar de que en el juego el personaje
caminaba o conduca vehculos de tierra que utilizaban el gnero Accin/Plataformas, cuando
el jugador se meta en un vehculo areo el manejo era similar al de los Shoot Em Up dentro
del mismo escenario.
Fig. 1.1: Metal Slug usando Accin / Plataformas
Fig. 1.2: Metal Slug usando Shoot Em Up
10
Eduardo Garca Rello
Adems, en determinadas situaciones el jugador tena que recorrer una pantalla con scroll en
vertical mientras disparaba hacia arriba, cambiando de nuevo al gnero Shoot Em Up.
Fig. 1.3: Metal Slug usando Shoot Em Up con scroll vertical
Otro ejemplo es el aclamado juego Chrono Trigger, un RPG de batalla por turnos que fusion
en una determinada parte del juego el gnero de Carreras. La mecnica era sencilla: solamente
con las teclas de direccin y el botn de turbo se tena que ganar en una carrera a tu rival. La
carrera era relativamente corta pero la mayora de jugadores agradecieron ese cambio en la
jugabilidad.
Fig. 1.4: Chrono Trigger usando RPG por turnos
11
Eduardo Garca Rello
Fig. 1.5: Chrono Trigger usando el gnero de carreras
1.3 Motivacin
Esta ramificacin de gneros asla a los jugadores de un gnero de otros que puede que no
hayan probado por no haber sentido apenas curiosidad o porque puede que ni conozcan que
existen, pudiendo desechar la posibilidad de que estos jugadores puedan incluir entre sus
ramas favoritas estas otras desconocidas para ellos.
Es por esto que se ha decidido como Proyecto de Final de Grado elaborar un videojuego
multignero que incluya algunos de los gneros ms populares que existen, y que han sentado
las bases de una gran parte de videojuegos hoy en da. De este modo, el juego que se ha
elaborado incluir los elementos y mecnica claves de los siguientes gneros: RPG por turnos,
Accin/Plataformas (de dos tipos: combate cuerpo a cuerpo y combate a distancia), Shoot Em
Up y Carreras.
Con esto se pretende que en un mismo videojuego se puedan probar diversos gneros que han
de superarse para continuar y que permitan que aquellos jugadores que jams hayan conocido
o jugado a estos gneros puedan probarlos y puedan desenvolverse en ellos con facilidad,
gracias entre otras cosas al uso de sencillos tutoriales que les permitan iniciarse en stos
gneros. Tras este primer contacto que tendrn los usuarios al inicio de cada nuevo gnero
sern ellos los que continuarn mejorando conforme avanzan en el juego y conforme van
encontrando habilidades que les permita jugar con una mayor variedad de opciones.
12
Eduardo Garca Rello
Todos los gneros se incluirn en un nico videojuego con una nica historia, de modo que la
eleccin de un gnero u otro vendr condicionada por el tipo de pantalla en el cual se ubique
el jugador, justificando as su uso dentro de la situacin que se de en cada pantalla y sin
necesidad de ponerlo por poner.
Unir varios gneros en un solo juego puede resultar sencillo si no comparten elementos entre
gneros (como en el caso ya mostrado antes de Metal Slug, ya que cuando cambia de gnero
no existe ningn elemento compartido entre ellos pues cada uno es independiente del otro),
ya que al estar aislados no influyen entre s y pueden desarrollarse como mltiples juegos
distintos conectados en uno solo. El problema principal de los videojuegos multignero es
precisamente ste, compartir elementos clave para la jugabilidad entre gneros que no tienen
nada que ver, ya que al no poseer la misma mecnica es difcil encontrar algn aspecto que
pueda permanecer intacto o simplemente permanecer en todos los gneros. En el juego que
se ha realizado como Proyecto de Final de Grado se ha conseguido fusionar todos los gneros
en un solo juego compartiendo todos los elementos claves que se hacen uso conforme se
avanza, de modo que no se note un cambio brusco de mecnica al cambiar de gnero, sino
que permanezca intacto para no confundir al usuario.
Un ejemplo de ello es el sistema de niveles y atributos del jugador, ya que para cada gnero los
atributos (a pesar de ser los mismos siempre) podrn afectar de forma distinta al personaje,
pero siempre manteniendo una lgica comn, de modo que aunque por ejemplo el atributo de
velocidad afecte de forma distinta al personaje o sus habilidades, siempre tendr que ver con
la velocidad.
1.4 Objetivos del proyecto

Desde el inicio hasta el final de la elaboracin del Proyecto Final de Grado se ha tenido en
cuenta que ste debe finalizar cumpliendo los siguientes objetivos:
Crear una librera propia

Se desea crear una librera propia que permita la creacin de videojuegos de una manera ms
sencilla, lista para posterior implementacin de nuevas funciones para cada juego que se
quiera realizar. Esta librera ser creada ntegramente por cdigo propio sin hacer uso de
ninguna herramienta o cdigo externo con excepcin de SFML. Iincluir aspectos tales como
13
Eduardo Garca Rello
un Gestor de Efectos, un Sistema de Partculas, varios Parseadores para cada necesidad

(mapas, entidades, etc.), un Motor de Fsicas, un Sistema de Cmaras, un Gestor de Eventos o
mltiples Inteligencias Artificiales basadas en Objetivos, entre otros aspectos. Con la creacin
de esta librera se pretende crear as un motor de videojuegos que permita desarrollar nuevos
de una forma ms genrica y externa, reduciendo la necesidad de implementar cdigo
mediante el uso de parseadores y archivos externos que contengan gran parte de la
informacin de diversos elementos del juego como pueden ser los tipos de enemigos y
parmetros de cada uno, eventos especiales, tipos de obstculos, trampas, etc.
Implementar mltiples gneros

Se implementarn varios gneros en el videojuego, contando con las caractersticas clave
propias de cada uno de forma que el jugador pueda experimentar ste tipo de gneros sin
perderse ninguna de las caractersticas que los hace nicos. Esto proporciona al usuario una
sensacin de estar jugando a juegos completamente distintos cada vez que cambie de gnero
ya que estar reflejada la esencia de cada uno de ellos de una manera fiel a los clsicos, pero
de una forma sencilla y nada confusa que impida que el usuario se desoriente al cambiar entre
gneros. Esto proporciona un mayor grado de jugabilidad y reduce la monotona al estar
cambiando de gnero varias veces a lo largo de la aventura.
Fusionar los gneros de forma justificada

El videojuego que se crear tendr unificados todos los gneros de forma que, aunque
aparezcan separados teniendo en cuenta sus pantallas correspondientes, tengan justificados
los motivos de su inclusin dentro de una historia comn. De este modo independientemente
del nmero de pantallas o del nmero de apariciones de cada gnero, su cambio vendr
condicionado por un suceso en la trama del juego, por lo que no existir ningn momento en
el que se cambie de gnero porque s. Un ejemplo de esto podra ser si el jugador llega a una
pantalla en la cual hay un precipicio y sucede un evento que obligue al personaje a precipitarse
por l, cambiando entonces de gnero al Shoot Em Up con scroll vertical.
Crear mltiples gneros independientes entre s e incluirlos toscamente en un solo juego es

relativamente sencillo pero ofrece una mala imagen del producto, suscitando en el jugador la
idea de que el videojuego apenas ha sido elaborado o por lo menos cuidado con un mnimo de
atencin. Es por eso que esta parte se considera como uno de los objetivos finales, ya que es
esencial que el jugador est entretenido y no se incomode por culpa del desarrollador.
14
Eduardo Garca Rello
2. Diseo y Especificacin
2.1 Argumento
Hlioir era una tranquila aldea ubicada en la zona ms serena del valle. Su gente era muy
trabajadora, responsable y amable con sus vecinos. Alfareros, panaderos, constructores,
herreros, guardias todos tenan trabajos que permitan a la aldea crecer y mantener un
ambiente afable. Se podra decir que era el lugar perfecto para residir si quieres una vida
tranquila y sin sobresaltos justo lo contrario de lo que Vidheim buscaba.
l quera accin, aventuras, riesgos, vivir cada segundo como si fuese el ltimo y estar
horneando pan hasta el da de su muerte no le sonaba como el ejemplo perfecto de aventura.
Harto de soar despierto cada da, Vidheim decidi dejarlo todo y aceptar el puesto de cazador
que ofreca el lder de la aldea y que nadie quera aceptar por los riesgos que incumba, ya que
no solo constaba de cazar animales, tambin haba que despejar los caminos de bandidos que
pudiesen merodear.
Es por eso que se construy una cabaa en lo ms profundo de uno de los bosques dentro del
valle y decidi pasar sus das all, acechando a criaturas del bosque o bandidos que se
refugiasen en l.
Bien entrada la maana de un da cualquiera, mientras Vidheim an dorma, ocurri lo que

pareca ser un terremoto que sacudi todo el valle con una increble fuerza. Sobresaltado, sali
corriendo fuera de su cabaa para ver qu haba pasado. Tras llegar a una de las salidas del
bosque, contempl algo que le congel la sangre: la aldea haba
quedado totalmente
destruida, aplastada por lo que parece ser un gigantesco monolito, como si hubiese cado del
mismsimo cielo con el objetivo de destruir la aldea.
Cerca de donde l estaba se podan or las carcajadas de un desconocido que contemplaba la

grotesca escena. Cuando Vidheim lo vi, descubri que ese desconocido tena todo el cuerpo
cubierto de lo que pareca ser una amalgama de rganos, tentculos y ojos, todo unido por lo
una especie de tejido orgnico rojo. Sospechando que esa abominacin podra tener algo que
ver, le pregunt quin era y qu haba pasado con la aldea. El ser respondi: Yo soy Nysrogh, y
esto solo es solo el inicio de lo que est por llegar.
15
Eduardo Garca Rello
Vidheim, consumido por la ira, se abalanz ante aquel individuo y le peg un puetazo con
todas sus fuerzas. Tras el golpe un trozo de la criatura cay al suelo, y acto seguido, como
tomando consciencia de s mismo, aquel trozo de carne atac a Vidheim impulsndose contra
su mano y extendindose por ella. Sintiendo un gran dolor, el cazador peg un puetazo al
suelo para intentar destruir a este organismo, consiguiendo as frenar la propagacin por su
brazo.
Nysrogh ,conmocionado por la fuerza del golpe, decidi dejar el lugar abriendo un extrao
portal a algn lugar desconocido. Mientras entraba al portal, se oy una voz gritndole que
esperase, que no le dejase atrs. Sorprendido, Vidheim descubri que quien estaba hablndole
a Nysrogh era su propia mano, concretamente el parsito que se haba incrustado en l, que no
poda moverse por haber intentado poseerle en vano, quedando fusionado con l.
Antes de que se cerrase el portal, el parsito orden a Vidheim que entrase en l rpidamente,
pues no quera seguir un segundo ms atrapado en su cuerpo. Aunque odiase admitirlo, saba
que la nica forma de deshacerse de se parsito era eliminando a Nysrogh, ya que as matara
dos pjaros de un tiro: eliminara de raz el problema del parsito y vengara a la gente de la
aldea adems que aquello significaba peligros y aventuras, por lo que no poda perdrselo,
por lo que entr sin dudarlo en el portal, adentrndose en lo desconocido
Vidheim emprender un largo viaje persiguiendo a Nysrogh, viajando por portales que
conducirn a distintas realidades paralelas, en las cuales aquella abominacin tiene pensado
implantar monolitos para consumir toda la materia de la Tierra en cada una de esas realidades
y as satisfacer a su amo, Sug-Phomet, una abominacin colosal encarcelada desde hace
milenios para evitar que consuma todo cuanto se conoce.
2.2 Objetivo del juego

El objetivo del juego es sencillo: el jugador deber ir completando progresivamente cada
pantalla para superar cada uno de los mundos que se presentan, derrotando a cada jefe del
mundo hasta llegar al jefe final del juego, de modo que una vez derrotado se complete. Para
ello el jugador har uso de las diversas formas de atacar y defenderse que se presentan en la
mayora de gneros, as como poder conseguir y utilizar diversas habilidades que podrn
mejorar sus atributos, realizar nuevos ataques y plantear nuevas estrategias de combate. Junto
16
Eduardo Garca Rello
con las habilidades el jugador tambin dispondr de objetos que le servirn de apoyo durante
su aventura.
Todo el juego est diseado para que se prueben todos los gneros incluidos y se saque el
mximo partido de ellos, aprovechando todas las caractersticas que los definen y diferencian
de los dems, de modo que siempre sea un nuevo reto comenzar una pantalla con un gnero
distinto.
2.3 Mecnica del juego

El juego se caracteriza por tener distintos gneros bastante dispares entre s, ya que cada uno
ofrece una forma completamente distinta de jugar, cambiando algunos aspectos de forma
significativa (que hacen nico a cada gnero) y conservando otros similares entre ellos. El
objetivo comn en todo gnero es llegar al final de cada pantalla, superando los obstculos
que se presenten, ya sea en forma de enemigos comunes, jefes finales, puzles o trampas sin
que se agote la vida del personaje.
De este modo cada gnero presenta una mecnica distinta a la cual el jugador deber
adaptarse para que el protagonista sobreviva. Para facilitarle el cambio entre gneros se
incluyen una serie de indicaciones que informan al jugador sobre los controles y acciones,
indicadores que se mostrarn nada ms empezar por primera vez el gnero en cuestin. Estas
indicaciones sern simples de modo que no se confunda al usuario con un exceso de
informacin, ya que ir aprendiendo a manejar cada gnero conforme avance, puesto que no
tiene todas las habilidades desde el principio.
El juego est dividido en realidades paralelas que vienen a ser los mundos que lo componen,
las cuales a su vez estn divididas en un determinado nmero de pantallas. Cada realidad
tendr una temtica distinta, como son el valle del protagonista, un entorno futurista postapocalptico, o la realidad original del antagonista principal. Todas estas realidades estn
separadas entre s por un portal dimensional que se abre tras derrotar al jefe final de cada
realidad, proporcionando as acceso a la siguiente realidad respecto de la que est el jugador.
Las pantallas por su parte varan de gnero segn cual sea, es decir, que si por ejemplo en una
pantalla el protagonista tiene que descender por un acantilado, el gnero de la pantalla ser
Shoot Em Up vertical; y si otra pantalla transcurre en un bosque el cual se ha de atravesar, el
17
Eduardo Garca Rello
gnero de sta ser Accin/Plataformas. De este modo se consigue adaptar los gneros
propuestos de una forma justificada de cara al jugador, sin forzar la situacin.
El jugador har uso de habilidades tanto ofensivas como defensivas que le permitirn esquivar
ataques, intercambiar energa por salud o atacar de varias formas distintas a los enemigos,
entre otras. Estas habilidades las ir encontrando por el camino y se irn sumando a las que ya
tenga el personaje.
Junto con las habilidades, el jugador ir consiguiendo objetos tras eliminar a enemigos u
obstculos, los cuales le ayudarn en su aventura. Estos objetos pueden tener efecto
inmediato (recuperacin de vida o energa, por ejemplo) o bien podrn almacenarse en el
inventario para utilizarse luego.
El personaje ir adquiriendo experiencia conforme elimine enemigos, permitiendo as que

aumente de nivel cuando consiga la suficiente. Cada enemigo proporcionar una cantidad
distinta de experiencia, de modo que eliminar a aquellos ms duros supondr una recompensa
mayor en experiencia que eliminar a los ms dbiles. Cada vez que el jugador suba de nivel se
le otorgar un determinado nmero de puntos que utilizar para incrementar uno de los
atributos del personaje (como fuerza, velocidad, vida) segn desee, mejorando as las
caractersticas del jugador segn el atributo aumentado. Conforme vaya subiendo de nivel la
cantidad de experiencia que necesitar para subir al siguiente se incrementar de modo que le
cueste ms subir conforme ms niveles tenga el usuario.
Durante la aventura se irn sucediendo una serie de eventos de dilogo que permitirn
avanzar en la historia y mejorar la inmersin del jugador en el juego. Estas conversaciones
ocurrirn entre el personaje principal y diversos NPC que se vaya encontrado por el camino as
como conversaciones entre l y el parsito de su brazo.
Junto con el objetivo principal del juego de superar cada pantalla existirn algunos objetivos
secundarios, como por ejemplo la localizacin de objetos ocultos que solo pueden ser
descubiertos si el jugador est muy atento a ciertos lugares o situaciones. Estos objetos
pueden proporcionar ventajas directas como aumentos de alguna estadstica del jugador o
bien pueden ser objetos acumulables para alcanzar un objetivo final, como por ejemplo
conseguir una habilidad oculta si se ha encontrado un determinado nmero de stos.
18
Eduardo Garca Rello
2.4 Metodologa empleada

Para la elaboracin de un proyecto de stas caractersticas se ha optado por seguir una
metodologa gil como es en este caso la denominada como FDD o Feature Driven
Development (Desarrollo Basado en Funcionalidades). sta metodologa se basa en la
realizacin de un diseo preliminar y global de cmo ser el proyecto una vez terminado, tras
lo cual se desarrollar una lista con todas y cada una de las funcionalidades que incluir,
ordenadas por prioridad de realizacin. Cuando se hayan planificado todas las funcionalidades
se comenzar por su desarrollo realizndose una a una de forma iterativa, de modo que se
vaya completando el proyecto progresivamente.
Fig. 2.1: Diagrama de etapas en FDD
Esta metodologa es muy til para este tipo de proyectos, ya que requieren de muchas
funcionalidades, siendo necesario planificarlas y priorizarlas para que no exista confusin
durante su desarrollo, ms an si es un proyecto desarrollado por una nica persona. Adems,
el diseo y construccin de las funcionalidades de forma individual hace que el proyecto sea
ms organizado y mantenga un flujo de creacin continuo.
Algo que ha ayudado y mucho a la hora de aplicar esta metodologa en el proyecto es el portal
Cloud. Este portal web ofrece una serie de herramientas que permiten establecer un
seguimiento y planificacin de una forma mucho ms organizada, controlando en cada
momento qu se ha de hacer y cundo se ha de hacer.
Entre sus herramientas se encuentra la creacin de peticiones, que sern la base para
establecer el seguimiento del proyecto. Estas peticiones son aquellas tareas a realizar dentro
del proyecto, pudiendo especificar tanto una descripcin como a quin se le ha asignado, junto
con el da de finalizacin o las horas estimadas para su realizacin. Estas peticiones pueden ir
19
Eduardo Garca Rello
actualizndose indicando las horas realizadas, el porcentaje completado y una descripcin del
contenido realizado en ella, controlando as el trabajo de todos los componentes del proyecto.
Una vez se hayan definido todas las peticiones que se deseen, Cloud nos ofrece un diagrama
de Gantt con todas stas peticiones ordenadas por fecha y categora, indicando su porcentaje
de realizacin as como pudiendo observar cundo se inici y cuando debera terminar. Esto
proporciona una visin mucho ms intuitiva y rpida para controlar el seguimiento del
proyecto, sobre todo en aquellos en los que participen ms personas.
Entre las mltiples herramientas que ofrece Cloud, cabe destacar otra que se ha utilizado para
este proyecto muchsimas veces: el repositorio. Cloud ofrece un repositorio en el cual subir las
versiones que se vayan completando del proyecto, de forma que pueda actualizarse de forma
sencilla, ofreciendo por tanto una copia del proyecto en el portal de modo que todos los
componentes puedan utilizarla y puedan ir completndola de forma sencilla a pesar de que
estn trabajando en ella al unsono todos los componentes. A pesar de que ste proyecto se
ha desarrollado de forma individual, ha sido muy til el sistema de versiones para poder
restaurar en caso de prdida o bien controlar qu se ha realizado en cada momento.
2.5 Gneros incluidos

De entre todos los gneros que se han sopesado para ser incluidos en el proyecto, finalmente
se han elegido los siguientes:
2.5.1 Accin / Plataformas

Los videojuegos de plataformas siempre han sido de los ms populares en cuanto a
entretenimiento y diversin se refiere. Suelen ser muy intuitivos, y pueden integrar fcilmente
aspectos de otros gneros o subgneros para hacerlos an ms entretenidos, como por
ejemplo los puzles o caractersticas que aumenten la accin en el juego. Uno de los ms
icnicos fue el archiconocido Super Mario Bros., que combinaba plataformas con un poco de
accin mediante el uso de ataques simples como la Flor de Fuego o la Estrella.
Son muy verstiles de modo que incluso a da de hoy, tras tres dcadas desde que fueron
creados, siguen crendose videojuegos de plataformas innovadores y muy originales. De
20
Eduardo Garca Rello
hecho, suele ser el gnero preferido por todos aquellos que comienzan a crear sus propios
videojuegos, ya que el resultado es bastante satisfactorio aun con pocos contenidos en escena.
Como ya he comentado, se suelen integrar otros gneros o subgneros en el de plataformas

para mejorar el resultado final, por lo que se ha optado por integrar diversos elementos del
gnero de Accin en ste, de modo que no solo se podr viajar por las pantallas saltando
plataformas y superando terreno, sino que tambin se podrn realizar una serie de
movimientos que aumenten el nmero de opciones que tiene el jugador a la hora de jugar.
Esta combinacin de gneros (accin + plataformas) se ha establecido como situacin base

para el juego, por lo que se ha decidido que aparezca en un mayor porcentaje de pantallas que
el resto de gneros debido a su versatilidad y facilidad para desarrollar mejor la historia que el
resto de gneros incluidos.
Dentro de este gnero el jugador podr moverse horizontalmente y saltar, siendo en todo
momento afectado por la fuerza de la gravedad. En el apartado de acciones ofensivas y
defensivas el gnero de Accin se ha decidido dividirlo en 2 ramas:
Accin Cuerpo a Cuerpo

En ste tipo de subgnero se han incluido ataques que afectan en un rango prximo al jugador,
de modo que l mismo tendr que acercarse a elementos como enemigos u obstculos para
atacarlos. Poseen una fuerza mayor que los ataques a distancia pero implican lgicamente un
mayor riesgo al estar el jugador ms prximo del peligro.
El jugador dispondr de una serie de ataques base iniciales que podrn realizarse mediante la
pulsacin del botn de ataque y una tecla de direccin, de modo que exista un ataque hacia
los lados, uno hacia arriba y otro hacia abajo.
Junto con estos ataques, el jugador ir descubriendo una serie de habilidades que mejorarn
sus ataques base o que incluso aadirn nuevos ataques, como por ejemplo el ataque cargado
lateral.
Adems, el jugador podr realizar algunas tcnicas de defensa como el esquive lateral, que
ignora todo el dao que reciba mientras est realizando ste movimiento.
21
Eduardo Garca Rello
Accin A Distancia
En este otro tipo de subgnero el jugador dispondr de un arma que le permitir realizar
disparos a distancia. El dao producido por estos disparos base es inferior al dao producido
por ataques cuerpo a cuerpo base pero tienen como ventaja que pueden lanzarse en gran
nmero y no implica necesariamente estar cerca del enemigo para que reciba el ataque.
El jugador podr disparar lateralmente sin necesidad de pulsar la tecla de direccin

izquierda/derecha, ya que es el ataque base. Al igual que con el subgnero de Accin Cuerpo a
Cuerpo, el jugador ir descubriendo habilidades por el camino, como el disparo cargado, el
cual toma ms tiempo para dispararse pero posee mayor fuerza ofensiva. Junto con las
habilidades ste subgnero tambin conserva los movimientos defensivos del subgnero
Accin Cuerpo a Cuerpo, como el de esquive lateral.
2.5.2 Shoot Em Up
Un gnero bastante popular y utilizado en infinidad de ocasiones. Suele ser usado tambin
como gnero base para iniciarse en el desarrollo de videojuegos ya que se puede crear un
juego Shoot Em Up muy simple en cuestin de poco tiempo, aunque eso mismo es un arma de
doble filo ya que debido al gran nmero de juegos con ese gnero es muy difcil innovar. Sin
embargo debido a la libertad que ste gnero ofrece para cambiar elementos clave en el juego
sin necesidad de sacrificar entretenimiento, se han conseguido muchas variantes distintas
dentro del mismo gnero que casi parece que pertenezcan a gneros propios.
Cambiando el tipo de scroll de escenario (scroll lateral, vertical, sin scroll o scroll controlado
por el usuario, por ejemplo); cambiando el sistema de combate (hordas de enemigos en
formaciones, enemigos posicionados fijos, combate VS entre un enemigo y el jugador, etc.);
cambiando el sistema de habilidades o power-ups (combinacin de nuevos ataques, direccin
de disparo controlada por el usuario, etc.) hay muchsimas formas de hacer un videojuego
con el gnero Shoot Em up, y todas ofrecen un mecanismo y una jugabilidad nicas.
En ste tipo de pantallas el jugador podr moverse en cualquier direccin mientras dispara
proyectiles a las hordas de enemigos que aparecen. Estos enemigos podrn aparecer en
formaciones de varios miembros o de forma individual, segn el tipo de enemigo que sea. El
jugador deber esquivarlos al mismo tiempo que les dispara para eliminarlos y reducir el riesgo
de perder puntos de vida.
22
Eduardo Garca Rello
El escenario se desplazar de forma horizontal a una velocidad constante, de modo que

independientemente del movimiento del jugador ste acabar llegando en algn momento al
final de la pantalla. Conforme avance por sta irn apareciendo obstculos que tambin se
movern por la pantalla as como terreno propio de sta, siendo en ambos casos perjudicial
que colisionen con el jugador.
A lo largo de la pantalla el jugador ir consiguiendo habilidades y poderes que le ayudarn a

eliminar los obstculos y las hordas de enemigos. No existe municin por lo que no tendr que
preocuparse por cunto tiene que disparar. Esto da pie a que se incluyan elementos que
dificulten algo ms la situacin , pues el tener municin infinita en estos juegos propicia que
sea demasiado fcil si no hay algn contra como enemigos difciles de matar o un moderado
nmero de disparos enemigos por la pantalla.
Este tipo de Shoot Em Up se ha incluido en el proyecto en pantallas como las que sirven de
trnsito entre un mundo u otro, viajando entre dimensiones.
2.5.3 RPG
Uno de los gneros ms utilizados cuando se quiere contar una historia o cuando se quiere
hacer hincapi en la estrategia a la hora de combatir. Al igual que la gran mayora de gneros,
posee una gran cantidad de elementos que pueden variar para ofrecer experiencias
completamente distintas entre juegos del mismo gnero, pudiendo variar tanto la exploracin
por el mundo, como la interaccin con personajes, as como los combates (algo que en algunos
casos define completamente el juego), permitiendo variar el juego de formas muy distintas.
En el caso de ste proyecto se ha decidido incluir ste gnero debido a su importancia y

popularidad, adems de que contrasta bastante con los ya elegidos y supone un reto integrarlo
con stos. Sin embargo se ha conseguido integrar perfectamente, utilizando elementos
comunes en todos los gneros del proyecto como el sistema de niveles o las habilidades entre
otros.
El jugador podr mover al personaje en todas las direcciones por un escenario visto desde
arriba, por aquellos lugares en los que sea viable andar. Conforme camina por el escenario le
23
Eduardo Garca Rello
aparecer de repente un indicador de combate y dar comienzo una batalla entre el personaje
y los enemigos que se hayan generado en ese combate.
Los combates se basan en turnos, de modo que (teniendo en cuenta la velocidad de los
enemigos y la del personaje) cuando uno ataca, el otro ataca despus. Una vez dentro del
combate, el jugador podr elegir la accin entre Atacar, Habilidades, Objetos y Huir. Se
mostrar el nombre del enemigo y su imagen, as como el HUD del personaje en el cual se
informa sobre aspectos como la vida o su energa.
Las habilidades de combate consumirn puntos de energa, de modo que solo podr utilizar
aquellas que no superen la cantidad de energa que disponga el jugador en ese momento. Con
el comando Atacar atacar con un ataque base teniendo en cuenta el atributo de fuerza del
jugador cuando se realice la accin.
Cuando el jugador elimina a todos los enemigos del combate, ste acaba y se recompensa al
jugador con experiencia y si el enemigo los ha soltado, objetos.
2.5.4 Carreras
Este gnero tiene muchas variantes tambin, sobre todo dependiendo de si se quiere
conseguir realismo (con juegos como Gran Turismo o Forza); si se quiere conseguir situaciones
cmicas y no muy realistas (como con Mario Kart o Crash Bandicoot Nitro Kart); o bien si lo
que se desea es utilizar al mximo los reflejos del jugador con pantallas frenticas (como con la
mtica carrera de Battletoads o con el clsico Unirally).
En ste proyecto se ha decantado por incluir el ltimo grupo de los mencionados

anteriormente, de modo que se sucedan carreras que irn a gran velocidad y probarn los
reflejos del usuario. Sin embargo como este proyecto pretender ser una toma de contacto
ante gente que no haya probado o no est muy versado en este tipo de gneros, no se
exceder la dificultad para no resultar frustrante al usuario.
La carrera se desarrollar en horizontal, con una vista parecida a la que ya se mostraba en el

gnero Shoot Em Up, pero con un scroll bastante ms rpido y diversos elementos que
diferencian stas pantallas de las que son Shoot Em Up.
24
Eduardo Garca Rello
El jugador podr desplazarse en todas las direcciones, pero debido a la velocidad del vehculo
le ser ms difcil avanzar hacia el lado en que conduce pero ms fcil frenar e ir hacia el lado
opuesto.
Durante el transcurso de las pantallas con ste gnero, el jugador ir encontrando avisos que
le informarn de obstculos ubicados en la carretera a escasa distancia de l, para que consiga
evitarlos antes de que sea demasiado tarde, debido a la velocidad de la carrera. Junto con
estos obstculos tambin se ir encontrando con algunos enemigos que intentarn acabar con
su personaje disparndole o simplemente chocndose contra l.
Para paliar sta situacin el personaje podr disparar desde su vehculo en la direccin en la
que est conduciendo de modo que pueda eliminar a aquellos enemigos que estn enfrente
de l.
2.5.5 Vertical
A pesar de no suponer un gnero propio, ste tipo de pantallas mezclan elementos tanto del
gnero Shoot Em Up como del de Carreras, de modo que se ha decidido catalogar ste tipo de
pantallas bajo este pseudnimo.
Pensado para pantallas especiales en las que el personaje, por ejemplo, descienda desde una
altura a otra ubicada a gran profundidad. En este tipo de pantallas el usuario podr moverse
en cualquier direccin pero la gravedad y la velocidad de cada afectarn a su movimiento
vertical, de modo que a la hora de moverse hacia arriba al jugador le costar ms esfuerzo, lo
contrario que para moverse hacia abajo que ir a una velocidad mayor.
Durante el descenso el usuario podr atacar a los enemigos y obstculos que vayan
apareciendo desde arriba o desde abajo.
La pantalla ir desplazndose a gran velocidad verticalmente, de modo que el usuario ha de

estar atento a cambios en el escenario para evitar chocarse contra las paredes de ste, as
como a enemigos y obstculos que vayan apareciendo. Su dificultad es elevada ya que la
velocidad de cada as como los lmites del escenario hacen peligroso el descenso.
25
Eduardo Garca Rello
2.6 Herramientas utilizadas

Para la elaboracin de este proyecto se ha decidido utilizar el menor nmero de herramientas
externas posibles, ya que como objetivo principal se ha propuesto la realizacin de una librera
propia y todo lo referente a un videojuego multignero de forma personal y empezando de 0,
de modo que no se incluyan, entre otros, motores de fsicas o sistemas de partculas externos,
ya que en todo momento se ha tenido en mente la motivacin de aprender a desarrollar de
forma independiente este motor de videojuegos y crear as un videojuego multignero.
Aun as para poder desarrollar todos estos componentes de forma personal s ha sido
necesaria la integracin de SFML, librera en la cual se ha basado el proyecto, ya que ofrece
una serie de herramientas que ayudan bastante a la hora de realizar videojuegos. Entre estas
herramientas encontramos la posibilidad de dibujar por pantalla, herramientas para medir el
tiempo, para crear rectngulos de colisin (bounding box), herramientas para el apartado de
audio, vistas y cmaras, entre muchas otras. Sin embargo stas herramientas son solo clases
con ciertos mtodos que permiten realizar una serie de funciones, de modo que es el propio
desarrollador el que decide cmo y dnde utilizarlas.
Junto con sta librera se ha utilizado el entorno de desarrollo integrado Visual Studio 2010, ya
que ha ofrecido mejores resultados que con otros entornos de desarrollo como Netbeans o
CodeBlocks. Tras unos sencillos pasos se puede adaptar SFML perfectamente a Visual Studio,
de manera que se pueda empezar a trabajar casi inmediatamente.
Para poder crear las pantallas se ha utilizado el programa Tiled, que permite disear pantallas
basadas en tiles de una manera sencilla, pintando directamente los tiles seleccionados sobre
una matriz de posiciones. Pueden aadirse capas, lo que permite establecer todo el escenario
directamente en el programa, tanto el fondo como la capa de colisin como todas las capas de
detalles que se quieran aadir. Se pueden, adems, asignar caractersticas a tiles concretos, a
capas o directamente a la pantalla creada, de modo que se puedan especializar stos
elementos an ms. Tiled exporta en varios formatos, siendo XML el elegido para ste
proyecto, de modo que realizando un parseador se puedan leer los datos y adaptarlos a ste.
Para la elaboracin del arte del juego se ha utilizado Paint Tool SAI, pues proporciona grandes
resultados a la hora de realizar dibujo artstico ayudado por una tableta digitalizadora.
26
Eduardo Garca Rello
Contiene mltiples opciones para personalizar pinceles, de modo que se pueda bocetar, pintar
o aadir efectos con stos de forma sencilla.
Por ltimo, para la elaboracin de algunos efectos de sonido se ha utilizado la herramienta

Bfxr Standalone, que permite crear efectos de sonido estilo 8-bit de una manera sencilla pero
que a la vez posee un gran nmero de herramientas para modificar los sonidos.
2.7 Evolucin en el planteamiento

Durante la planificacin del proyecto as como en la fase de desarrollo de pruebas en ste, se
han ido sopesando ideas de las cuales algunas han conseguido tener el visto bueno y se han
implementado y otras han tenido que ser rechazadas o modificadas con respecto al
planteamiento original para que pudiesen adaptarse al proyecto correctamente. Estas ideas
van desde detalles dentro de elementos ya planificados (como las caractersticas de las
distintas habilidades) as como stos propios elementos (qu habilidades podran entrar y
cuales no), como tambin aspectos mucho ms decisivos a la hora de encaminar el desarrollo
del proyecto, como puede ser la eleccin de qu gneros entran en el proyecto o de si usar
libreras y motores externos para facilitar el desarrollo del proyecto.
2.7.1 Motor de Fsicas propio VS Box2D

En un principio el proyecto se ide para ser desarrollado de manera personal, es decir, usando
el mnimo de herramientas externas posibles con el objetivo de crear una librera propia y a su
vez alcanzar un mayor nivel de aprendizaje que si se utilizasen stas herramientas.
Despus de varias experiencias en proyectos pasados y tras la elaboracin de prototipos de

motores de fsicas en ste que no cumplieron las expectativas se opt en un primer momento
en incluir el motor de fsicas Box2D en el proyecto, de forma que ese bache estuviese
paliado por ste motor.
Tras una serie de pruebas se comprob que Box2D se integraba bien con lo que ya se haba
creado para el proyecto, de modo que se empezaron a realizar prototipos para comprobar la
comprobacin y resolucin de colisiones entre cuerpos de distintos tipos (Box2D incluye tres
tipos de cuerpos: dinmicos, cinemticos y estticos, cada uno con propiedades distintas al
resto). Los prototipos iban bien, pero se comprob que eran demasiado perfectos pues
27
Eduardo Garca Rello
simulaban aspectos innecesarios que daban demasiado realismo ante un juego con stos
gneros. Colisiones que devolvan el golpe recibido, rozamiento excesivo con el suelo y con
los laterales de los objetos, rotaciones innecesarias de cuerpos al chocar con otros todo era
demasiado realista.
Esto supuso un alto en la continuacin de pruebas, en el cual se deba sopesar qu hacer a

continuacin: seguir con Box2D y restringirle funcionalidades as como contrarrestar los
efectos realistas que producan sus colisiones, o bien continuar investigando la realizacin de
un motor de fsicas propio y quizs abordarlo desde otro punto de vista empezando de cero.
Tras meditarlo se pens que, a pesar de ofrecer algunas herramientas muy tiles para el
proyecto, si inclua un motor como Box2D teniendo que mutilarlo en mltiples aspectos
acabara siendo ms costoso que si empezaba uno yo mismo, adems de que al no haberlo
desarrollado yo no sabra exactamente cmo solucionar los posibles problemas que me
encontrase en el futuro (ya que no existe mucha informacin sobre Box2D utilizndose fuera
del motor de juegos Cocos2D).
Se opt entonces por crear el motor de fsicas desde cero, motivado por aprender a
desarrollarlo, conseguir que la librera sea personal al 100% y tambin por la necesidad de
solucionar la espina que se qued clavada tras el fracaso del anterior motor de fsicas propio.
Tras una larga investigacin y muchsimas pruebas se consigui crear uno nuevo, cuya base
consista en la elaboracin de una matriz de sensores que rodean a las distintas entidades del
juego (como se explica en la seccin Motor de Fsicas).
El motor se comprob que funcionaba correctamente en todas las situaciones probadas as

que se fij su implementacin al proyecto.
2.7.2 Un Sprite para dominarlos a todos

Durante las primeras fases de implementacin de funcionalidades los distintos objetos de tipo
Sprite se creaban de forma dinmica, conforme el juego los fuese necesitando. Esto pareca no
desentraar ningn problema al principio, pero conforme se continuaba el desarrollo se
comenzaron a ver extraas ralentizaciones durante la ejecucin del juego, ocurriendo stas
cuando se creaban elementos tales como enemigos o proyectiles nuevos, as como efectos
28
Eduardo Garca Rello
especiales. Tras investigar se lleg a la conclusin de que estos elementos tenan un factor
comn que poda ocasionar stas ralentizaciones: la creacin de nuevos sprites.
Originalmente los sprites se creaban sobre la marcha e incluso para algunos era necesario
parsear en el momento el spritesheet que contena al sprite para asignarle los valores, algo
bastante costoso, por lo que si ya estaban sucediendo cosas en ese momento provocaba
ralentizaciones. Se decidi entonces cambiar la forma en la que se usaban los sprites, de modo
que en vez de crearse y en ocasiones parsearse dinmicamente se creasen en un nico
momento y se almacenasen en el gestor de recursos, de forma que si un elemento del juego
necesitase un sprite en concreto simplemente tuviese que apuntar a aquel ya creado en el
gestor. De este modo se podran crear sin miedo 50 enemigos en pantalla, ya que todos
tendran un puntero apuntando a un nico Sprite creado, ubicado en el gestor de recursos.
Esto supuso tambin un gran cambio en el sistema de carga de mapas, ya que en el prototipo
los tiles originalmente tenan un Sprite cada uno, generando as miles de sprites por mapa, de
modo que tras el cambio solo se necesit 1 nico Sprite para absolutamente todo el mapa,
independientemente de cuntas capas, filas o columnas tuviese.
Para que este sistema funcione compartiendo un nico Sprite todos los del mismo tipo,
solamente hay que implementar los datos que se utilizaran para cambiar el Sprite dentro del
dueo de ste, en vez de directamente en el Sprite como estaba puesto originalmente. De
este modo cada dueo solo tendr que aplicar stos datos en el Sprite cuando se vaya a
dibujar, de forma que el Sprite cambiar en cada momento para cada elemento pero dentro
de una misma iteracin del bucle del juego, permitiendo as representar a todos los elementos
con Sprite utilizando uno por cada tipo.
2.8 Diseo Especfico VS Diseo Genrico

A la hora de desarrollar un proyecto de estas dimensiones es necesario planificar muy
detalladamente qu se ha de realizar y cmo, para evitar confusiones y sobre todo porque si
surgen problemas puedan ser arreglados de la forma ms rpida y sencilla.
Si queremos desarrollar, como es el caso, un videojuego, hay que tener claro que existir una
gran cantidad de datos que podrn variar conforme se vaya testeando y desarrollando, de
modo que es importante tener un sistema que facilite la comprobacin y modificacin de stos
29
Eduardo Garca Rello
datos de una forma intuitiva y rpida, ya que es muy difcil tener originalmente todos los datos
perfectamente equilibrados sin que tengan que ser modificados en un futuro, ya que en un
videojuego es muy importante la fase de testeo (sobre todo en temas de enemigos, objetos y
terreno por ejemplo).
De este modo podemos diferenciar dos ramas por las cual poder decantarnos a la hora de
disear y desarrollar el proyecto:
Diseo Especfico
Se trata de una forma de disear que mantiene en todo momento el objetivo de disear
exclusivamente para el proyecto que se est desarrollando, en este caso un videojuego, sin
vistas a que pueda servir para otro proyecto posterior. Esta forma de disear y desarrollar no
est enfocada a que sus componentes puedan ser modificados en mltiples ocasiones, si no
que ms bien est pensado para grabar a fuego los datos y que se queden como se han
diseado originalmente.
Este suele ser el tipo de diseo que se suele seguir nada ms empezar a desarrollar
videojuegos, pues no es estrictamente necesario el uso de parseadores y de archivos externos
para funcionar, ya que todo est fijado en el propio cdigo.
Sin embargo no es lo ms recomendable, ya que cierra completamente las puertas a la

posibilidad de que sus caractersticas puedan ser modificadas en cualquier momento, ya que al
estar todo tan cerrado y unido si se quisiese volver a modificar stas caractersticas podra
afectar a gran parte del proyecto.
En todo caso, si se desease usar, debera ser en ocasiones en que el proyecto no sea muy
grande o bien se tengan todos los aspectos de ste bien establecidos de forma inicial, de modo
que no necesiten cambios sustanciales en el futuro (debido al riesgo que esto implica para la
estabilidad del proyecto). Sin embargo no suele darse el caso de que un videojuego est
perfecto y equilibrado antes incluso de desarrollar su cdigo, por lo que se entiende que no
es recomendable el uso de ste tipo de diseo.
Diseo Genrico
30
Eduardo Garca Rello
Es un tipo de diseo mucho ms abierto e intuitivo que el diseo especfico, ya que permite
modificar en cualquier momento aspectos que pueden llegar a ser cruciales para que el
proyecto sea satisfactorio, sin necesidad de meterse a cambiar cdigo dentro de ste.
Est orientado para aquellos proyectos que tengan unas dimensiones lo suficientemente
grandes como para necesitar modificaciones de vez en cuando, de forma que stas sean
sencillas, rpidas e intuitivas de realizar. Adems tambin es recomendable ste tipo de diseo
para aquellos proyectos con vistas a que parte de stos pueda ser reutilizado en otros
proyectos en el futuro, modificando el mnimo cdigo necesario y realizndolo todo de forma
externa a ste.
Y esa es la base de ste tipo de diseo: el uso de datos ubicados de forma externa al cdigo.
Estos datos por lo general suelen venir de ficheros incluidos en el proyecto, de modo que en
cdigo solo hara falta desarrollar parseadores que permitan leer estos archivos y que sean los
responsables de asignar el contenido de stos a nuestro cdigo sin que tengamos que
meternos de por medio. Esto implica que para modificar el contenido de, por ejemplo, un
enemigo (como puede ser sus variables de salud o fuerza), solo tengamos que irnos al archivo
en el cual est la informacin del enemigo y modificarlas directamente en l sin necesidad de
tocar cdigo, de modo que cuando carguemos el juego de nuevo el enemigo tenga esta nueva
informacin de manera automtica.
Esto ofrece una mayor flexibilidad al proyecto as como un control de errores mucho ms
sencillo, ya que si por ejemplo queremos mermar el poder de un objeto solo tendremos que
irnos a su archivo correspondiente, lo que facilita mucho las cosas, permitiendo adems su
reutilizacin en otros proyectos ajenos a ste.
Por todo esto se ha decidido que ste tipo de diseo sea el utilizado para ste proyecto, de
forma que mediante el uso de parseadores y de archivos de texto se puedan controlar desde
los tipos de enemigos (definiendo qu inteligencia artificial tienen, as como su vida, fuerza e
incluso sprites) hasta los tiles del mapa que tengan comportamiento especial, pasando por las
especificaciones de trampas o de efectos especiales, entre otras muchas cosas.
31
Eduardo Garca Rello
2.9 Diseo Visual

Para el apartado visual del proyecto se ha optado por disear y dibujar uno mismo casi todos
los elementos que se han incluido en el juego. De este modo se pretende que el proyecto sea
lo ms personal posible, reduciendo el uso de elementos externos siempre que sea posible.
El apartado visual se compone de varias imgenes, en las cuales se han dibujado elementos
tales como el personaje, enemigos, elementos del hud, tiles de las pantallas, fondos de
escenarios, efectos especiales o proyectiles, entre otros muchos.
Se ha optado pues por disear a mano todos estos elementos a excepcin de los tiles del
escenario, ya que en algunos casos se han utilizado tiles proporcionados en tilesets ajenos,
siempre y cuando el autor de permiso para poder utilizarlos. De este modo agradecer a Johann
Charlot por proporcionar el tileset que se ha empleado en gran parte del juego.
En cuanto a la elaboracin de ste apartado, se ha optado por dibujar todos los sprites del
juego (a excepcin del ttulo y del mensaje de has muerto) siguiendo el estilo pixelart, de
modo que visualmente sea mucho ms atractivo, a la vez que evoque el estilo de los
videojuegos de inicio-mitad de la dcada de los 90. De este modo se ha dibujado y pintado
todos y cada uno de stos sprites siguiendo tcnicas que potencien el estilo de pixelart.
Personaje
El personaje fue lo primero que se dise, mediante dibujos conceptuales para saber cmo
sera en el futuro, una vez se hubiese adaptado al tamao y necesidades del juego. Como se
puede apreciar en al siguiente imagen el diseo se ha mantenido a grandes rasgos (evitando
dibujar detalles para no sobrecargar el sprite al ser de muy poco tamao y adems en pixelart).
32
Eduardo Garca Rello

Fig 2.2 Arte conceptual del personaje.
Fig. 2.3 Personaje ampliado (izquierda) y tal cual se ve en el juego (derecha)

En la hoja de sprites del personaje se han dibujado 106 sprites distintos, que forman parte de
las 26 animaciones que compone el personaje.
33
Eduardo Garca Rello
Fig. 2.4 Hoja de sprites del personaje.

Enemigos
En cuanto a la hoja de sprites de los enemigos, encontramos en total 110 sprites distintos, que
dan forma y animan a 30 enemigos distintos en un nmero de animaciones que vara segn el
enemigo en cuestin.
34
Eduardo Garca Rello
Fig 2.5 Hoja de sprites de los enemigos.
35
Eduardo Garca Rello
Efectos
Se han desarrollado 187 efectos (sin contar con las letras del abecedario), distribuidos entre
disparos, habilidades, objetos, efectos especiales, partculas, etc.
Fig. 2.6 Hoja de sprites de los efectos del juego.

Elementos relativos a los mens
Se han creado 15 elementos usados en mens, ya sea paneles donde mostrar botones e
informacin as como los propios botones.
36
Eduardo Garca Rello
Fig. 2.7 Hoja de Sprites para los elementos de los mens.

Tiles y fondos
Se han elegido tiles de 3 artistas distintos, que cumplen con todas las necesidades el proyecto.
Algunos tiles (mostrados en la esquina inferior izquierda) s han sido desarrollados de manera
personal, ya que hay una serie de elementos demasiado especficos (como sensores, trampas y
efectos de lluvia por ejemplo) que los dems no han podido abarcar. A su vez se ha decidido
dibujar unos fondos que se ubicarn detrs de todos los elementos del escenario durante la
partida.
37
Eduardo Garca Rello
Fig. 2.8 Tiles utilizados para las distintas pantallas.
Fig. 2.9 Fondo para escenarios con temtica naturaleza.
2.10 Diseo Sonoro

Ya que para el proyecto se ha elaborado un sistema de audio que permite reproducir sonidos y
msicas, es necesario cubrir estas necesidades con los elementos correspondientes.
38
Eduardo Garca Rello
Banda sonora
En cuanto a la banda sonora del juego se ha optado por utilizar material de artistas que
ofrezcan sus trabajos de forma gratuita y que no suponga ningn problema su utilizacin en
proyectos ajenos. Se ha decidido pues utilizar msica perteneciente a la banda sonora del
famoso (y reciente) videojuego Shovel Knight, ya que est desarrollada ntegramente en
estilo chiptune u 8-bit, acorde a la esttica de su juego ya que rememora juegos clsicos
de la consola NES (Nintendo Entertainment System). Ya que este proyecto tambin pretende
hacer un guio a los clsicos, as como por su esttica visual retro, la banda sonora elegida
encaja perfectamente en l.
Esta banda sonora est disponible de forma gratuita en internet, y lo nico que se pide es que
el proyecto no se use de forma comercial, as como atribuir su creacin al autor original, en
este caso Jake Kaufman.
Efectos de sonido
Los efectos de sonido han sido desarrollados de forma personal gracias a la herramienta Bfxr,
la cual es una utilidad online (con opcin para descarga de forma gratuita) para la elaboracin
de efectos de sonido que podemos encontrar tpicamente en videojuegos antiguos de 8 bits.
Los sonidos se pueden generar de forma aleatoria, as como pueden generarse como fruto de
modificaciones de un sonido previamente generado con esta herramienta, mediante la opcin
mutate (creando as variantes parecidas a un sonido en concreto, algo muy til para dar
mayor realismo y variedad al repertorio de sonidos).
Una vez generado el sonido, se puede modificar muchos parmetros de ste para adaptarlo
como mejor nos parezca, pudiendo exportarse despus para poder descargrnoslo.
Se han elaborado 27 sonidos que cubren todas las necesidades del proyecto, desde actuar
como indicador sonoro ante golpes recibidos, as como emitidos, disparos, recoleccin de
objetos, etc.
3. Desarrollo e Implementacin
3.1 Patrones de Diseo empleados
Los patrones de diseo comprenden soluciones a problemas comunes que pueden surgir
durante el desarrollo de software. No necesariamente pueden utilizarse cuando se d un
problema, tambin pueden ser utilizados para agilizar, estructurar y optimizar el propio
proyecto cuando se necesite. Adems implican que, si el proyecto se comparte, otros
desarrolladores puedan manejarlo mejor si saben el comportamiento de los patrones
utilizados en ste, agilizando las cosas.
39
Eduardo Garca Rello
Durante el desarrollo de este proyecto se ha sopesado la utilizacin de diversos patrones de

diseo, los cuales podran ayudar a la hora de estructurar y mejorar el diseo global del
proyecto, dndose el visto bueno a los siguientes:
3.1.1 Patrn Fachada

El patrn de diseo Fachada permite estructurar el cdigo de una manera ms sencilla e
intuitiva con respecto al desarrollador, permitiendo separar y minimizar las dependencias
entre cdigo, algo muy til cuando se trabaja con herramientas externas como libreras.
Para el proyecto actual se ha decidido su implementacin de cara a minimizar stas

dependencias entre el cdigo que yo he creado y los elementos que proporciona SFML, de
modo que la utilizacin de elementos de ste sea mnima de forma directa, utilizando primero
por tanto aquel cdigo que yo he creado. Algunos ejemplos de esto son las clases Sprite,
Ventana, Textura o Rectngulo, entre otras. Con esto se ha conseguido que, llamando por
ejemplo a la clase Sprite, se pueda trabajar con sus mtodos y variables (los cuales s estn
relacionados con SFML, haciendo de fachada) sin necesidad de llamar explcitamente a
aquellos de SFML. Adems se ha mejorado el uso de algunas de estas clases, como de nuevo es
el caso de Sprite, que sustituye a la clase con el mismo nombre de SFML, habindose integrado
en la clase propia mtodos que SFML no tiene y que la mejoran, como es el control de
animaciones entre frames de stos sprites.
Como consecuencia de realizar clases, mtodos y variables propias que sirvan de fachada a las
que pudiese tener SFML, se ha conseguido que el cdigo sea mucho ms intuitivo con respecto
al desarrollador, ya que es uno mismo el que define esos elementos y por tanto pueda
desarrollar con una mayor facilidad a la hora de recordar qu elementos contiene cada clase y
para qu sirven.
3.1.2 Patrn Singleton

El patrn Singleton permite que un objeto sea creado una nica vez en todo el transcurso de la
ejecucin, de modo que solo se crear cuando no exista ninguno, por lo que si se solicita su
creacin habindose creado ya anteriormente, en vez de crearse de nuevo se devolver el que
ya existe.
40
Eduardo Garca Rello
Esto es muy til para controlar diversos elementos que pueden afectar de forma general a
todo el cdigo, como pueden ser relojes o gestores de cualquier tipo (de partculas, efectos, de
recursos, etc.), los cuales solo es necesario crearlos una vez.
Esto ha sido muy til en el proyecto actual ya que el hecho de que existan stos elementos, los
cuales pueden ser utilizados en diversos puntos del proyecto, ha permitido reducir bastante
cdigo y hacer ms simple la elaboracin de nuevos elementos tales como enemigos o sprites.
Al tratarse de forma global, los gestores y toda aquella clase que tuviese ste patrn ha
podido ser utilizada desde cualquier otra clase sin necesidad de crear una nueva instancia de
sta, simplemente se ha creado un puntero que llama al mtodo Instanciar de la clase con
Singleton, recibiendo su instancia ya creada.
3.2 Gestor de Efectos

Los efectos especiales son algo casi esencial en la gran mayora de videojuegos hoy en da, de
hecho es difcil ver alguno que no los incluya. Ofrecen una mejora visual muy interesante e
incluso van ms all sirviendo de indicaciones en algunos casos, como por ejemplo en el
videojuego Mario Kart, en el cual se puede derrapar generando unos efectos especiales de
varios colores que indica el grado de turbo que se puede llegar a conseguir, adems de
reforzar visualmente la situacin. Su versatilidad y flexibilidad a la hora de crearse, as como el
grandsimo nmero de tipos distintos que se pueden crear suponen un punto fuerte dentro de
cada videojuego, ofreciendo al jugador una sensacin de profesionalidad y atencin a los
detalles muy cuidada con respecto al juego y a su desarrollador.
Durante la realizacin del proyecto se plante el uso de efectos especiales que pudiesen
reforzar diversas situaciones, tanto de manera simplemente esttica como proporcionando
ayuda tcnica al jugador. Por ello se decidi implementar un sistema de efectos especiales que
fuesen manejados por un gestor de efectos, el cual se encargara de crearlos, actualizarlos y
eliminarlos conforme la situacin as lo requiriese.
La clase GestorEfectos est compuesta de varios mtodos esenciales para su funcionamiento:

- Varios mtodos para crear efectos segn el tipo que sean.
- Un mtodo par inicializar todos aquellos elementos que pudiesen necesitar futuros
efectos.
41
Eduardo Garca Rello
- Un mtodo para actualizar los efectos que estn vivos en cada momento.
- Un mtodo para dibujar stos efectos.
Crear un efecto nuevo es muy sencillo, pues lo nico que necesitamos hacer es llamar al
mtodo correspondiente de creacin de efecto (segn del tipo que sea), y pasarle, entre otras
cosas, el nombre del efecto. sta es una de las principales ventajas de que el proyecto est
realizado siguiendo un diseo genrico, pues simplemente pasndole el nombre del efecto que
queramos el propio gestor se encargar de detectar qu efecto es (pues al inicio del juego se
parsearon todos los datos de los efectos disponibles desde ficheros de texto) y aplicar los
datos necesarios para cada uno segn su nombre. Una vez creada la instancia de la clase
Efecto, se aadir al vector de efectos que el gestor posee, pudindose as recorrer tanto para
actualizarlos como para dibujarlos posteriormente. Una vez el efecto ha terminado se elimina
y se quita del vector de efectos.
Todos los efectos que nos encontraremos (identificados por el nombre que poseen cada uno)
estn englobados en varias ramas, de modo que dentro de una misma rama los efectos sern
creados de una forma o de otra segn a la que pertenezcan. Sin embargo su comportamiento
vendr dado nicamente por el nombre que posean, de modo que cada efecto ser distinto a
los dems aun pudiendo pertenecer todos a la misma rama. Estas categoras de efectos son:
3.2.1 Efectos Independientes

Son aquellos efectos que, como su propio nombre indica, son independientes a cualquier otro
elemento del juego. Se utilizar esta categora para aquellos efectos puntuales cuya posicin
no importe en absoluto. Su forma de comportarse variar con cada uno, pero por lo general
suelen tener un ciclo de vida corto, funcionando la mayora simplemente como factor esttico.
Dentro de esta categora se han decidido implementar los siguientes:
ChoqueDisparo
Consta de un sprite con una animacin simple, generado cuando un proyectil entra en colisin
con cualquier obstculo, ya sea del propio escenario o de las entidades que haya en l.
42
Eduardo Garca Rello
Fig 3.1 Efecto ChoqueDisparo al disparar sobre una piedra
MuerteSerAtacable
Cuando un SerAtacable es eliminado tras realizrsele un ataque, se genera una onda de
energa roja que indica este hecho de una forma mucho ms rpida y visualmente ms
llamativa que si simplemente desapareciese del escenario.
Fig 3.2 Efecto MuerteSerAtacable al eliminar un enemigo

InicioDisparo
Cuando el jugador dispara con el arma de fuego del protagonista se emite un destello desde la
boca de sta, indicando que se acaba de efectuar el disparo y reforzando esa accin.
43
Eduardo Garca Rello
Fig 3.3 Efecto InicioDisparo justo en la boca del arma

GolpeSerAtacable
Cuando el jugador golpea un SerAtacable se genera una onda parecida a la de
MuerteSerAtacable pero mucho ms pequea y de color azul, indicando que se ha efectuado
con xito el golpe.
Fig 3.4 Efecto GolpeSerAtacable generado en el lugar de impacto con el enemigo
Teletransporte
Algunos enemigos tienen la posibilidad de invocar a otros, de modo que cuando esto suceda se
crear el efecto en cuestin, mostrando un portal en la posicin en la que se generen los
enemigos, reforzando la situacin, dando la sensacin as de que se estn teletransportando a
la escena, en vez de aparecer directamente desde la nada.
3.2.2 Efectos Dependientes
Son aquellos efectos que, como su nombre indica, dependen de algn elemento externo a
ellos, como por ejemplo un enemigo. Estos efectos estn atados a stos elementos, ya sea
solo para el momento de su creacin o durante toda su vida. Por lo general suelen depender
44
Eduardo Garca Rello
de la posicin del elemento, aunque existen algunos que dependen de ms factores aparte de
ste. Dentro de ste grupo encontramos los siguientes efectos:
DamageSerAtacable
Consta de un sprite que genera el gestor de textos, apareciendo sobre aquellos enemigos que
reciban dao. Este sprite indicar con nmeros la cantidad de dao infligido, haciendo un
efecto de impulso hacia arriba y luego cayendo hasta desaparecer. Es dependiente del
enemigo solamente en el momento de crearse, ya que necesita su posicin y la cantidad de
dao recibido, pero no est ligado a l por ms tiempo por lo que aunque el enemigo se
mueva el movimiento del sprite es independiente al enemigo una vez creado.
Como no depende del ente que lo contiene ms all del momento en que fue creado, aunque
se elimine a ese ente el indicador de dao seguir existiendo hasta que desaparezca por su
cuenta una vez est cayendo.
Fig. 3.5 Efecto DamageSerAtacable mostrado sobre el enemigo al recibir un golpe
BarraVida
Indicador en forma de barra que muestra la vida del elemento que lo contiene (elementos que
pertenecen a la clase SerAtacable, por lo que tienen vida) al poco de recibir un ataque (inicia
invisible y luego se va aumentando su opacidad). Esta barra consta de dos sprites, uno fijo que
hace de borde del ms pequeo que crece o decrece indicando cmo de llena est sta barra
de vida. Es totalmente dependiente del elemento al que pertenece, de modo que si ste se
mueve la barra se mover con l la misma cantidad de pxeles.
45
Eduardo Garca Rello
sta barra aparecer desde el centro del ente hasta ubicarse encima de l con un movimiento
suavizado y con un degradado de alfa que vara desde invisible (cuando se inicia) hasta ser
completamente visible (cuando est ubicado ya encima del personaje). Este mismo
movimiento lo repite hacia abajo cuando ha pasado un periodo de tiempo sin que ataquen al
enemigo. Si lo atacan con la barra activa el contador de vida se reiniciar, quedndose en su
posicin ms tiempo.
Cuando el ente que lo contiene muere la barra de vida desaparece
Fig. 3.6 Barra de vida mostrndose sobre el enemigo al poco de recibir dao
EscudoEnergia
Al utilizar la habilidad EscudoEnergia, una esfera de energa aparece rodeando en todo
momento al jugador. Tras un intervalo de tiempo la esfera empezar a parpadear
rpidamente, indicando que se acerca su fin. Tras acabar se la habilidad tambin lo hace el
efecto.
Indicadores de obstculos
Cuando el jugador est manejando al personaje en el gnero de Carrera se crearn una serie
de efectos que indicarn si un obstculo se le aproxima, posicionndose una seal con una
exclamacin en el lateral derecho de la pantalla, a la altura en la cual est el obstculo
prximo. El efecto desaparece cuando el obstculo empieza a verse por la pantalla.
RecogerConsumible
46
Eduardo Garca Rello
Cuando el jugador recoge del suelo un objeto consumible se crear un efecto en el cual unas
lneas de energa suben en vertical en la ubicacin del personaje, indicando que se ha
incrementado algo (si es un objeto de tipo Salud las lneas sern verdes, si es de tipo Energa
sern azules).
Fig. 3.7 Efecto al recoger el consumible de Salud
3.3 Gestor de Partculas

Las partculas podran considerarse un tipo de efecto ms, pero poseen caractersticas propias
por las cuales merece la pena separarlas y construir un gestor dedicado a ellas. Mientras que
en este proyecto los efectos son individuales, de modo que solo se crean de uno en uno, las
partculas suelen aparecer en grupos, pudiendo alcanzar un gran nmero de componentes
dentro de ellos. Adems, mientras que los efectos suelen tener alguna utilidad (como servir de
indicacin para el usuario) aparte de ofrecer un buen efecto visual, las partculas simplemente
sirven como refuerzo visual de diversas situaciones, sin tener que representar algn tipo de
indicacin til para la aventura.
Del mismo modo que los efectos individuales, un sistema de partculas es algo muy a tener en
cuenta a la hora de desarrollar un videojuego, ya que ofrecen un gran atractivo visual,
despertando en muchos casos el inters y asombro de los jugadores por lo bien que se
complementan a las situaciones que se pueden dar en los diversos videojuegos que las
incluyan.
Al igual que pasaba con el gestor de efectos, crear nuevas partculas es sencillo, pero en este
caso tendremos un intermediario ms: el emisor de partculas. La clase EmisorParticulas
ser la encargada de manejar las partculas, algo que se diferencia del gestor de efectos ya que
47
Eduardo Garca Rello
en ste era el propio gestor el que los manejaba. En este caso si el gestor de partculas tuviese
que manejar una a una todas las que existiesen podra llegar a ser algo engorroso, de modo
que la clase GestorParticulas se encargar nicamente de crear, actualizar, dibujar y eliminar
las instancias de EmisorParticulas, siendo stas ltimas las que se encargan de crear, inicializar,
actualizar y eliminar una a una las partculas que contengan.
Tambin se ha seguido la filosofa del diseo genrico a la hora de crear este gestor, de
modo que a los emisores de partculas se les asignarn unos nombres a la hora de ser creados,
y, teniendo en cuenta los tipos de partculas parseados cuando se inicializ el juego, sabr que
hacer en cada momento, solamente comprobando su nombre.
El sistema de partculas, por tanto, trabaja de la siguiente forma:

1. El gestor, nada ms empezar el juego, prepara los elementos comunes a todos los emisores
que se puedan dar (como son, por ejemplo, los sprites del juego).
2. Durante el juego, el gestor recibe una peticin para crear un nuevo emisor de partculas,
indicndole todos los parmetros necesarios para este emisor, as como lo ms importante: el
nombre del emisor, mediante el cual sabr que hacer en cada momento durante su ciclo de
vida. Al crearse tambin se agregar al vector de EmisorParticulas que tiene la clase
GestorParticulas
3. El emisor trabajar entonces con las variables recibidas y teniendo en cuenta el tipo de
emisor que sea, se encargar de crear una a una las partculas teniendo en cuenta las
necesidades de cada tipo.
4. El gestor se encargar de actualizar cada uno de los emisores creados, los cuales a su vez se
encargarn de actualizar todas aquellas partculas asociadas a cada uno.
5. Cuando llegue el momento en que las partculas deban eliminarse (lo cual tambin
depender del tipo de emisor), ser el emisor el que lo haga, y una vez estn todas eliminadas
establecer su variable haMuerto a true ya que no tiene sentido que siga existiendo al
carecer de partculas, de modo que le tocar al gestor eliminar ese emisor de partculas.
6. Tras cada actualizacin el gestor recorrer todos los emisores llamando a sus funciones de
dibujado para que muestren por pantalla todas las partculas que contienen.
Como se ha mencionado, existen varios tipos de emisores de partculas, cada uno con sus
caractersticas que lo hacen distinto en comportamiento a los dems. Estos tipos de emisores
son:
48
Eduardo Garca Rello
3.3.1 Emisores de tipo Explosin

Los emisores de tipo explosin son aquellos en los que se generan todas las partculas a la vez
y en una nica ronda, de ah que se le denomine explosin. Este emisor por tanto solo genera
partculas en el momento de ser creado, de modo que una vez que todas stas mueren el
emisor muere con ellas.
Al generarse, cada una de las partculas generadas recibe un impulso con una fuerza aleatoria
tanto en horizontal como en vertical, de modo que de sensacin de realismo y no quede
demasiado artificial.
Suelen ser utilizados en colisiones (contra enemigos simulando sangre, contra objetos
simulando sus piezas, en explosiones, etc.).
Algunos ejemplos de los utilizados en el proyecto son los siguientes:
RomperObstaculo
Cuando el jugador destruye un obstculo en el escenario se genera una serie de partculas a la
vez desde la posicin en la que estaba el obstculo, dejando constancia visual de que lo ha
roto. Estas partculas varan teniendo en cuenta el tipo de obstculo, de modo que, por
ejemplo, si se elimina una piedra se emitirn trozos de dicha piedra, para dar mayor realismo.
GolpeSerAtacable
Cuando se efecta un golpe a un SerAtacable se emiten una serie de destellos que indican que
el objetivo ha sido golpeado.
ChoqueDisparo
Cuando un disparo choca contra un objeto se emiten una serie de destellos en el lugar donde
se ha eliminado el disparo. Estos destellos variarn en color teniendo en cuenta el tipo de
disparo efectuado (ya que no es lo mismo un disparo del jugador que el de un enemigo).
RecogerObjeto
Cuando el jugador recoge un objeto consumible o una habilidad se emite unos destellos que
refuerzan la accin. Estos destellos variarn en color dependiendo de si es un objeto
consumible o una habilidad lo que se ha conseguido.
49
Eduardo Garca Rello
3.3.2 Emisores de tipo Fuente

Este otro tipo de emisor es completamente distinto al de tipo Explosin, ya que las partculas
de ste emisor se generan una a una conforme se necesite (normalmente determinada por
una condicin, como por ejemplo una variable aleatoria teniendo en cuenta un rango de
tiempo entre la generacin de una partcula y otra). Adems por las caractersticas de ste tipo
de emisores, la nica forma de determinar cuando muere el propio emisor es de forma
preestablecida, es decir, que un evento ser el que determine cuando ha de parar la
generacin de partculas, de modo que cuando la ltima se elimine, muera tambin el emisor.
Debido a sta generacin continua de partculas este tipo de emisores reciben el nombre de
Fuente. Estos emisores a su vez tienen dos formas distintas de actuacin, teniendo en cuenta
si se genera cada partcula de forma independiente a las dems o bien solo se crea una nueva
cuando otra previamente creada acaba de morir, existiendo en ste caso siempre el mismo
nmero de partculas vivas.
Suelen ser usados en aspectos del escenario como elementos del clima (lluvia, nieve, etc.);
detalles que incumben a las caractersticas del entorno (como hojas cayendo en un bosque,
papeles impulsados por el viento cerca de una ciudad, etc.); o por ejemplo un lugar en el que
sea necesario que se emita algn elemento de forma ininterrumpida (una fuente de agua, las
chispas de una bengala, etc.).
Hojas
En pantallas con temtica naturaleza se emitirn de forma continua partculas con forma de
hoja (variando entre distintos sprites de hojas) desde el borde superior de la pantalla, con un
movimiento constante hacia abajo-derecha, pero la cantidad de velocidad que lleven en
ambos ejes ser aleatoria, generndose en el momento de su creacin, de modo que cada hoja
no solo podr ser diferente visualmente sino que tambin cambiar en direccin y velocidad
respecto de las dems, mejorando el realismo de la escena. Se eliminan cuando salen de la
pantalla lo suficiente.
Ceniza
Similar al emisor de partculas de tipo Hoja, estas partculas se desplazan por la pantalla con
velocidad aleatoria, pero esta vez tienen como direccin abajo-izquierda. Se emitirn en
pantallas con temtica post-apocalptica.
50
Eduardo Garca Rello
ProyPeqBomba
Cuando se realice la habilidad BombaEnerga, se crear primero un disparo pequeo que ser
el que luego detone en una explosin mayor. Durante este disparo pequeo se generarn una
serie de partculas con forma de destello que saldrn desde el centro del proyectil, dando la
sensacin de que est cargado de energa y la va desprendiendo. Una vez se elimine el disparo
tambin lo har este emisor.
ProyGrandeBomba
Al igual que pasa con ProyPequBomba, se emitirn una serie de destellos pero en esta ocasin
mientras transcurra la explosin de la BombaEnerga.
Transmutar
Cuando el jugador realice la habilidad Transmutador se generarn una serie de partculas en la
mano de ste, indicando que se est llevando a cabo esta habilidad. Cuando se pare de realizar
tambin desaparecer el emisor.
3.4 Gestor de Recursos

Debido a la gran cantidad de contenido que puede llegar a necesitarse a la hora de desarrollar
un videojuego es imprescindible la utilizacin de un sistema que permita gestionar de manera
eficiente todo recurso que se genere, de forma que, por ejemplo, no existan objetos
duplicados innecesariamente, crendose solo cuando se necesiten y eliminndose cuando ya
no sean tiles. Todo este proceso ha de llevarse a cabo de forma ajena al desarrollador, de
modo qu este solo se preocupe de desarrollar el gestor y, una vez completado, sea ste el
que se encargue de todo conforme avanza el proyecto.
De este modo se ha decidido incluir un gestor de recursos en el proyecto, el cual se encargar

de la creacin, comprobacin y eliminacin de contenidos de todo tipo.
El gestor de recursos posee varios vectores de distintos tipos, acorde a los contenidos que
maneja, de modo que sea el gestor el que los contenga y sean las dems clases las que
soliciten cada recurso para trabajar con ellos. De esta forma evitamos que las clases creen
estos recursos, ahorrndonos confusin en la estructura de cdigo (quin hace qu, cundo y
51
Eduardo Garca Rello
dnde), as como evitando que mltiples instancias de una misma clase pudiesen crear el
mismo contenido muchas veces.
Su comportamiento est definido por una serie de mtodos que se dividen en tres grupos:
- Creacin de contenido: son aquellos en los que se crea nuevo contenido, como
pueden ser objetos de clases como Sprite, Ente, Rectngulo o Textura. ste contenido
se almacena en los vectores que posee el gestor. Un aspecto a tener en cuenta es que
cada vez que se solicita la creacin de un nuevo elemento primero se comprueba el
vector correspondiente para ver si ste elemento ya ha sido creado previamente, en
cuyo caso no se crear de nuevo, saliendo directamente del mtodo.
- Devolucin de contenido: son aquellos mtodos en los que se devuelve un elemento
de los que tiene almacenados, siendo solicitado por cualquier otra clase del proyecto.
Son los comnmente llamado getters.
- Eliminacin de contenido: son mtodos a los cuales se les pasa una indicacin de qu
objeto han de eliminar (pudiendo pasrseles el nombre del elemento o el propio
elemento) de modo que si sta indicacin coincide con los datos de uno de los
elementos almacenados en el vector correspondiente, ser eliminado y sacado de
ste.
- Vaciado de vectores: son mtodos que eliminan todos los elementos de dentro de
stos y posteriormente dejan el vector a tamao 0.
De este modo, gracias a estos mtodos y vectores, se puede controlar en todo momento
cuntos elementos se han creado y si stos son los correctos, evitando duplicados y
decidiendo cundo se crean y cundo se eliminan de forma ms directa, reduciendo as el
coste en memoria del videojuego y por tanto optimizndolo.
Al tratarse de un objeto que ha de ser creado una nica vez, el gestor de recursos ha sido
diseado para ser una clase Singleton, de modo que muchas otras puedan trabajar con l sin
necesidad de crear nuevas instancias.
3.5 Motor de Fsicas

El motor de fsicas es de las partes ms complejas de disear y desarrollar en un videojuego,
pero es un componente vital para un grandsimo porcentaje de gneros (casi todos realmente)
y por tanto de videojuegos. Ya sean ms o menos elaborados, los motores plantean soluciones
52
Eduardo Garca Rello
a situaciones tan bsicas como la fuerza de la gravedad, impulsos o lo ms utilizado: colisiones

entre cuerpos. De este modo un motor de fsicas puede comprender nicamente una colisin
simple (como es el caso de Tetris o Puzzle Bubble) o bien una gran cantidad de herramientas
que permitan representar complejas situaciones en un entorno (como puede ser cualquier
juego de accin). Algunos incluso juegan con conceptos que no se suelen dar en el da a da
(por ejemplo los viajes entre planetas con gravedad propia en Super Mario Galaxy) o
situaciones que an no se han podido representar en el mundo real pero que han podido
simularse de forma ficcional en un videojuego (como es el caso de la saga Portal).
Debido a la complejidad que desentraa desarrollar un motor de fsicas propio, lo ms comn

es utilizar algunos motores ya existentes, los cuales ofrecen resultados muy realistas con una
integracin sencilla en el proyecto. Sin embargo debido a la motivacin de desarrollar una
librera propia y por tanto un videojuego propio, se ha optado por realizar un motor de fsicas
casi desde cero, utilizando nicamente como base los rectngulos que contiene SFML pero
calculando de forma propia su comportamiento y sus posibles colisiones, entre otras cosas.
3.5.1 Fuerzas
Las fuerzas en este proyecto estn presentes en todos los gneros de varias formas distintas.
Entre ellas la ms utilizada en el mbito de los videojuegos es la fuerza de la gravedad, que en
este proyecto afectar a los gneros de Accin/Plataformas, Shoot Em Up (en pantallas con
descenso vertical) y Carreras. Para ello se ha establecido una variable numrica que establece
la cantidad de gravedad que se aplicar, de modo que todos los elementos que estn sujetos a
sta fuerza (por lo general el personaje principal, los enemigos o los objetos entre otros)
tendrn aplicada esa cantidad a la suma de su velocidad vertical, de modo que se desplacen
acelerando cada vez ms (hasta alcanzar un lmite de velocidad) hacia el suelo.
Aparte de la gravedad existen otro tipo de fuerza presente en varios gneros que simula la
friccin con son el caso del gnero Accin/Plataformas (en algunas pantallas en las que haya
viento) y el de Carreras, en ste ltimo siendo la fuerza horizontal continua durante todo el
gnero, simulando la friccin con el aire a grandes velocidades.
Aparte de las fuerzas permanentes en segn qu pantallas y gneros sean, tambin se han
implementado impulsos para, como su propio nombre indica, impulsar elementos tales como
enemigos, objetos o al propio personaje. Estos impulsos se aplican directamente a stos
53
Eduardo Garca Rello
elementos, alterando su velocidad horizontal y/o vertical segn el impulso empleado, de modo
que por ejemplo si un enemigo est realizando una accin de abalanzarse contra el personaje,
se le aplicar un impulso determinado por esa IA para alcanzarlo; o bien si hemos recibido
dao, lo cual nos impulsar en el lado opuesto a la posicin del origen del golpe; as como por
ejemplo en el sistema de partculas (para emisores de tipo explosin) o cuando lanzamos un
objeto, ya que en el primer caso el impulso ser aleatorio en horizontal y en vertical y en el
segundo caso vendr predeterminado por el lado en el cual est mirando el jugador.
Estos impulsos trabajan de forma ajena a la velocidad que est llevando el elemento afectado
en cuestin, pero sin embargo se combinan perfectamente con ste de modo que es viable la
situacin de que un ente este andando, sufra un impulso y en el aire reciba otro, realizndose
los clculos perfectamente.
3.5.2 Gestor de Colisiones

El punto fuerte de los motores de fsicas es la comprobacin y resolucin de colisiones entre
los diversos elementos del videojuego. Estas colisiones sirven para todo lo que uno quiera
desarrollar ya que existir un cdigo que controle que pasa cuando, por ejemplo, el personaje
colisiona contra un enemigo, o contra un proyectil, o contra un elemento del escenario, o bien
contra un objeto, teniendo adems en cuenta todos los tipos que puedan existir dentro de
cada elemento (una pocin de vida, una de energa, monedas, etc.). No solo las colisiones
sirven para interactuar con el personaje o los elementos del escenario, tambin sirven (como
es el caso de ste proyecto) para la activacin de eventos mediante la colisin del personaje
con tiles invisibles pero con propiedad de colisin, mediante lo cual cuando existe una colisin
personaje-tile de evento, se activar la secuencia que incluye su comportamiento.
Existen, por tanto, innumerables situaciones que tratar de forma personalizada, por lo cual es
necesario que algo las compruebe y resuelva de forma correcta. Por ello, para este proyecto se
ha decidido implementar un gestor de colisiones que est a la espera de cualquier tipo de
colisin entre cualquier tipo de elemento del juego, siempre y cuando ste pueda realizar
colisiones. El gestor contiene una serie de mtodos que le permiten comprobar y resolver
cualquier tipo de colisin, ya sea entre objetos de la clase padre Ente, o entre stos y los
propios objetos de tipo Tile que componen el mapa.
54
Eduardo Garca Rello
3.5.2.1 Colisiones Ente con Ente

Para poder manejar este tipo de colisiones tenemos dos mtodos que nos permitirn
comprobar y posteriormente manejar la colisin de forma correcta, segn sean los objetos de
tipo Ente que colisionen:
- ComprobarColisionesEntes: ste mtodo se encarga de recorrer el vector de
boundings que contiene el gestor de recursos para comprobar si, para cada posicin,
existe otro en el vector que est cerca de ste, de modo que exista la posibilidad de
que prximamente los dos entes dueos de esos boundings entren en colisin. De este
modo, si encontramos un par que estn cerca entre s comprobamos si existe colisin
entre ellos en ese momento, y de no ser as lo desechamos y pasamos a comprobar si
este candidato colisiona con otro de otra posicin en el vector. Si por el contrario
existe colisin entre este par de boundings, almacenamos en la siguiente posicin del
vector de colisiones (que contiene el gestor de colisiones) los dos boundings afectados.
Si tras comprobar todos los boundings no existe ninguna colisin se saldr del mtodo
sin que ocurra nada ms, pero si por el contrario se ha agregado al menos una colisin
al vector de colisiones se llamar en ltimo lugar, antes de salir del mtodo, al mtodo
ManejarColisionesEntes.
Fig. 3.8: Diagrama funcional de ComprobarColisionesEntes
- ManejarColisionesEntes: Este mtodo se encargar de resolver todas aquellas

colisiones que existan en el vector de colisiones. Para ello primero deberemos
descubrir quines son los dueos de cada bounding (es decir, que objeto de tipo Ente
es el que contiene cada bounding colisionado), por lo que, para cada posicin del
vector de colisiones comprobaremos los dos boundings afectados comparando la
variable idPadre que cada uno tiene, de forma que si sta coincide con el idEnte
del Ente que estemos consultando en el vector de entes en ese momento, se
55
Eduardo Garca Rello
almacenar este Ente en una variable que funcione de alias para poder trabajar
posteriormente con l.
Una vez comparemos y encontremos los dueos de esos 2 boundings, se empezar a

resolver las colisiones segn el tipo de Ente que sea cada uno y el tipo de bounding de
estos entes que haya colisionado (ya que no es lo mismo que colisione el bounding del
cuerpo de un enemigo que el bounding de su arma). De esta forma si se da, por
ejemplo, el caso en el que el bounding del cuerpo de un enemigo colisiona con el
bounding del arma del personaje, se ir al caso correspondiente y se aplicar el
resultado que corresponda, en este caso una resta de vida del enemigo y un impulso
hacia atrs de ste.
De esta forma primero se realizar el mtodo ComprobarColisionesEntes, y una vez se tengan

candidatos se llamar a ManejarColisionesEntes, el cual ser el encargado de resolverlas segn
sea el tipo de boundings y entes afectados.
Al realizarse de esta forma resulta bastante sencillo e intuitivo aadir nuevas situaciones, ya
que solo se tendra que ir a ManejarColisionesEntes y establecer nuevas condiciones aplicando
lo que se quiera que pase en ellas, tras lo cual estara ya implementada esta nueva situacin.
3.5.2.2 Colisiones Ente con Tile

Como las pantallas del juego estn construidas mediante tiles, es necesario realizar una serie
de clculos que impidan a los elementos del entorno que los atraviesen si no se desea que esto
pase. Primero es necesario comprobar si un tile colisionable est en un rango prximo al
personaje, comprobando entonces si colisiona con ste, resolvindose despus esta colisin
segn el caso que se d. Por lo general si el tile no tiene ms propiedades que el hecho de que
se pueda colisionar con l, se deber impedir que los elementos lo atraviesen, de modo que si
existe una colisin entre Ente y Tile se har retroceder al Ente hasta una posicin en la que
colisionen pero no se atraviesen el uno al otro (por ejemplo, dejar pegado al suelo a un
personaje que ha cado desde una determinada altura, impidiendo que atraviese el suelo).
Existen bastantes situaciones distintas dentro de un videojuego relacionadas con la gestin de

colisiones, de modo que habr ocasiones que solo necesitemos comprobar si un Ente ha
56
Eduardo Garca Rello
colisionado con un Tile y otras en las que necesitemos comprobar y resolver. Teniendo en
cuenta estas situaciones se han creado los siguientes mtodos: es mtodos:
- ComprobarColisionesTiles: ste mtodo ser utilizado nicamente para la

comprobacin de colisiones, no para su resolucin. Debido a que pueden existir
mltiples capas de mapas de tiles, y por tanto el peso computacional de comprobar
todas y cada una de stas capas es demasiado grande, se ha decidido establecer una
variable a cada capa en la que se indique si sta es de tipo colisionable o no, de
modo que ste mtodo comprobara los tiles solo de aquellas capas en que sta
variable sea cierta, evitando aquellas capas que no contengan tiles de colisin, como
puede ser el fondo.
El mtodo se encargar pues de, como su propio nombre indica, comprobar si existe
algn objeto de tipo Tile cercano al Ente que se le ha pasado, y de ser as comprobar si
colisiona. Para ello se hace uso de un sistema que define una matriz invisible alrededor
del personaje. ste sistema est pensado para entes que no superen los 3 tiles de
altura o anchura, ya que para stos se necesitan crear mtodos especiales guiados por
bounding y no por el propio ente. sta matriz simula 9 tiles alrededor del personaje,
los cuales simulan ser una especie de sensores que determinan si un tile de terreno
(con el cual colisionar) est dentro de ellos o no. Si se encuentra algn tile de terreno
dentro de stos sensores, se continuar comprobando si el tile en cuestin es
colisionable (es decir si su variable esColisionable es true) y si su id es distinto a -1, ya
que ese es el id que tienen los tiles vacos.
Una vez comprobado que el tile en cuestin permite ser colisionado se proceder a
crear un bounding auxiliar que englobe nicamente a ese Tile candidato para colisin.
Se ha elegido crear un bounding auxiliar que englobe al tile aqu ya que crear durante
la carga de mapas un bounding para cada uno de los tiles del juego sera costoso e
innecesario
Acto seguido, se comprobar si existe colisin entre el bounding del cuerpo del Ente y
el que acabamos de crear que engloba al Tile en cuestin. Si existe colisin se saldr
del mtodo devolviendo la posicin de la matriz de sensores en la cual se ha
encontrado el tile que colisiona con el ente.
57
Eduardo Garca Rello
- ManejarColisionesTiles: a diferencia de ComprobarColisionesTiles, ste mtodo no

solo comprueba las colisiones sino que tambin las resuelve. Es el mtodo utilizado por
cualquier entidad que pueda colisionar, ya que es lo que dicta qu hacer en cada
momento si ha habido colisin entre la entidad y un tile del terreno. Al igual que
ComprobarColisionesTiles, tambin utilizar el mismo sistema de matriz de sensores
rodeando a la entidad en cuestin, y tambin asignar un bounding al Tile que se haya
detectado en alguna de las celdas de esa matriz. Acto seguido comprobar si hay
colisin (si el Tile en cuestin es colisionable y su id es distinto de -1, como se ha
explicado antes), y de ser as comenzar a resolverla mediante los siguientes pasos:
1. Para resolver la colisin que haya ocurrido, primero necesitamos llamar a otro
mtodo del gestor de colisiones: ComprobarTamIntersec. Utilizando estos dos
boundings, realizar una serie de clculos que acabarn determinando el tamao de la
interseccin ocurrida entre los dos, tanto en ancho como en alto, algo vital como se
podr comprobar despus a la hora de resolver colisiones.
2. Una vez conseguido el tamao de la interseccin entre boundings el siguiente paso

ser comprobar si el tile en cuestin es un tile especial, es decir, uno con
caractersticas especiales a tener en cuenta (como por ejemplo que el tile sean unos
pinchos, por lo que podra ser necesario segn el caso- restar vida al Ente en cuestin
si choca con ellos), para lo cual se comprobar su tipo de tile, de modo que si su tipo
est vaco no pertenecer a ese grupo de tiles especiales, pero si tuviese especificado
un tipo, fuese cual fuese, s sera necesario resolver detalles propios de stos. De este
modo tenemos dos situaciones:
2.1. Si el tile en cuestin es uno especial, se llamar al mtodo ManejarTilesEspeciales.

La mecnica de este mtodo es parecida a la utilizada cuando resolvamos colisiones
entre entes con ManejarColisionesEntes, ya que lo que se realizar aqu es comprobar
el tipo de tile en cuestin y, teniendo en cuenta cual sea, actuar en consecuencia. De
este modo si el tile resultase ser uno de tipo PinchosSuelo, restaramos vida al Ente y
lo impulsaramos en direccin opuesta al tile en cuestin; si por el contrario es uno de
tipo Plataforma, se comprobar si el Ente en cuestin est por debajo de este,
permitindosele atravesarlo de ser as, hasta que pudiese posicionarse encima y
entonces impedir su cada. Acto seguido se saldra del mtodo y se continuara por el
paso 3.
58
Eduardo Garca Rello
2.2. Si el tile en cuestin no es uno especial, no entraremos a resolver sus

caractersticas especiales por precisamente carecer de ellas, por lo que se pasara al
paso 3 directamente.
3. Tras la situacin que se hubiese dado con respecto a si ha sido o no tile especial, se
comenzar por comprobar las colisiones entre Ente y Tile para ubicar correctamente al
primero, de forma que no lo atravesase. Para ello es necesaria la intervencin de
nuevo del sistema de sensores que se ha implementado en la matriz, de modo que,
teniendo en cuenta la posicin en la cual se ha encontrado al tile en cuestin, se
actuara en consecuencia. Estas comprobaciones de qu posicin de la matriz se han
decidido realizar en un orden concreto teniendo en cuenta cuan mayor sea la
probabilidad de encontrarse con un tile en cada posicin, de modo que, por ejemplo,
la probabilidad de encontrarse un tile debajo del personaje es mucho mayor que
encontrrselo encima de l. Esto es algo subjetivo ya que viene determinado por el
tipo de juego y algunas posiciones no son mucho ms relevantes que otras, pero es
ms ptimo que exista un orden para comprobar primero aquellas ms probables que
las que no, de modo que se puedan ahorrar comprobaciones extra.
As, el orden de prioridades es el siguiente:
Fig. 3.9 - Orden de prioridades a la hora de comprobar colisiones.
En la figura 3.9 podemos ver la matriz de sensores, con las posiciones de sta en azul
y la prioridad de cada una en rojo. Siguiendo este orden, se comenzar primero por la
posicin 7, luego por la 1, por la 5, etc.
59
Eduardo Garca Rello
Por tanto el objetivo es devolver al Ente a una posicin en la que colisione con el tile
en cuestin pero no lo atraviese. Para ello lo que se tendr que hacer es establecer la
posicin del Ente (teniendo en cuenta si es vertical u horizontal el tile colisionado ser
en Y o en X la posicin a modificar, respectivamente) de forma que se quede pegado al
tile sin atravesarlo.
stas seran algunos ejemplos de las posibilidades, escritas en pseudocdigo:

- Si el tile est en la posicin 7 (abajo):
posicionEnteY = posicionTileY offsetEnteY;
- Si el tile est en la posicin 1 (arriba):
posicionEnteY = posicionTileY + offsetEnteY + tamAltoTile;
- Si el tile est en la posicin 5 (derecha):
posicionEnteX = posicionTileX offsetEnteX;
- Si el tile est en la posicin 3 (izquierda):
posicionEnteX = posicinTileX + offsetEnteX + tamAnchoTile;
Como podemos comprobar, en las posiciones 7 y 5 tan solo debemos restar el offset
del Ente en cada orientacin (el offset es la distancia desde el centro hasta el lateral
correspondiente) a la posicin de del Tile en cuestin y esa sera la posicin en la cual
debera permanecer. Con esto estamos consiguiendo que entre el centro del Ente y el
inicio del tile solo exista de distancia el offset del Ente, de modo que lo acabe rozando
pero sin atravesarlo.
Fig. 3.10 - Ente atravesando tiles de terreno.
60
Eduardo Garca Rello
Como se puede observar en la figura 3.10 tenemos un ejemplo de una situacin en la

cual el terreno y el personaje colisionan. El rectngulo rojo corresponde al bounding
del personaje, el cuadrado negro del centro del terreno corresponde al bounding
auxiliar creado para comprobar intersecciones entre Tile y Ente, y la matriz de
cuadrados azules que rodean al personaje es la matriz de sensores que ha servido
para identificar la primera posicin en la cual el tile se ha ubicado (por lo mencionado
anteriormente del orden en prioridades). De este modo se puede comprobar que ha
atravesado por la parte inferior (posicin del a matriz nmero 7) el Tile resaltado, de
modo que se proceder a reubicar al personaje con el pseudocdigo que se ha visto
antes para sta posicin, dejando al Ente encima del Tile en cuestin, como se muestra
en la siguiente figura:
Fig. 3.11 - Ente ubicado correctamente encima del Tile objetivo.
3.5.2.3 Colisiones Ente con Obstculo

El sistema de manejo de colisiones Ente con Obstculo es bastante sencillo una vez visto el de
Ente con Tile, ya que se basa en el mismo principio: reubicar al Ente de forma que se quede
pegado a l sin atravesarlo. Esto se realiza desde el mtodo ManejarColisionObstculos, que
comprende un comportamiento parecido al de ManejarColisionesTiles.
Sin embargo los Obstculos se diferencian de los Tiles en que los primeros pueden actuar
como elementos que no pueden ser atravesados as como tambin poder ser atravesados por
61
Eduardo Garca Rello
los laterales pero no por la parte superior, haciendo el efecto de plataforma, tan solo
cambiando una variable en stos.
De este modo si el Obstculo en cuestin tiene la variable esPlataforma a false, ser

imposible atravesarlo por ningn lado, de modo que solo queda sortearlo o destruirlo; pero sin
embargo si tiene esa variable a true tendr definido que si el Ente no est ubicado por encima
del Obstculo, ste puede ser atravesado sin problemas, a no ser que ser el caso contrario y
que el Ente est ubicado por encima, de modo que cuando caiga sobre el Obstculo y colisione
con su parte superior se quedar ah y no lo atravesar, comportndose como un objeto
slido.
Fig. 3.12 - Obstculo con la variable esPlataforma a true
Fig. 3.13 - Obstculo con la variable esPlataforma a false
62
Eduardo Garca Rello
3.6 Parseadores y sistema de archivos

Como ya se ha hablado anteriormente, ste proyecto sigue la filosofa del diseo genrico,
dejando todos aquellos aspectos que puedan ser modificados en elementos externos para que
puedan realizarse cambios de forma rpida, sencilla e intuitiva, sin afectar negativamente en el
cdigo del proyecto. En este proyecto estos elementos externos son archivos de texto en los
cuales se detallan aspectos claves de los mbitos que engloban (por ejemplo enemigos,
trampas, tiles especiales, etc.). De este modo solamente har falta cambiar el contenido de
stos archivos de texto para modificar las caractersticas de aquellos elementos a los que
afectan, siendo el cdigo el responsable de recoger y aplicar este contenido de forma
automtica.
Esta recogida de datos y posterior asignacin dentro del proyecto ha sido posible gracias al
desarrollo de una serie de parseadores, cada uno encargado de recoger los datos de aquellos
ficheros de texto que se les indiquen. As, tras abrir el fichero en cuestin, comenzarn una
bsqueda de palabras clave en ste, y asignarn el contenido relacionado a estas dentro las
variables del propio cdigo (por ejemplo si en el fichero estn escritos los caracteres
vida=100 el parseador buscar vida= y asignar el 100 a la variable int vida en el cdigo).
Para cubrir todos los aspectos necesarios para el proyecto, se han creado los siguientes
parseadores:
3.6.1 Parseador de Indicadores de Lneas

A veces se da el caso de que en un mismo archivo estn reunidos elementos los cuales son
independientes a los dems, cada uno con sus caractersticas. Un ejemplo de esto es un
archivo que pueda contener todos los diferentes entes dentro de una misma pantalla. Para
evitar llamar y utilizar el parseador de entes mltiples veces, indicando cada vez la lnea del
elemento a mirar dentro del archivo, existe un archivo que sirve para (como su propio nombre
sugiere) indicar la lnea de cada uno de stos elementos, ofreciendo una lista de todos los
elementos distintos que existe en ese fichero de entes, indicando as el nombre de cada uno y
la lnea en la que est ubicado.
Como se ha comentado, ficheros tienen la siguiente estructura:

id:"NombreElemento"
linea:"nLinea"
63
Eduardo Garca Rello
De modo que un ejemplo podra ser:

id:"ChoqueDisparo" linea:" 2"
id:"SpriteFont"
linea:"17"
El parseador se encargar de recoger y almacenar estos elementos, pasndosele cuando se le

llame el nombre del archivo a buscar y el vector de indicadores de lneas en el cual se
almacenarn cada uno de los elementos encontrados, con toda su informacin (nombre y
lnea). Estos vectores no son necesarios ms all del mbito de recogida de stos datos, por lo
cual se suelen crear justo antes de llamar a ste parseador, pasndoselo vaco y rellenndose
conforme se parsea, de modo que tras la llamada a este parseador se tenga el vector listo para
ser utilizado de forma inmediata.
De este modo se ofrece una forma mucho ms sencilla a la hora de recoger otros elementos
en otros parseadores, ya que la mayora tienen mltiples elementos en sus archivos
correspondientes, de forma que ser muy comn la utilizacin de este parseador para agilizar
la recogida de datos. Tan solo habr que recorrer una a una las posiciones del vector de
indicadores de lneas, de forma que si el elemento actual de ese parseador (por ejemplo un
Ente o TileEspecial) coincide en nombre con el indicador almacenado en una determinada
posicin del vector, se empezar a buscar en la lnea que le corresponda en el fichero.
Fig. 3.14 - Ejemplo de asociacin entre un indicador de lnea y su fichero
3.6.2 Parseador de SpriteSheets

Los spritesheets son archivos de imagen con multitud de sprites distintos, los cuales sern
recogidos y utilizados en el juego para representar visualmente aspectos como enemigos,
64
Eduardo Garca Rello
objetos, terreno o efectos entre otras muchas cosas. Por lo general suelen estar organizados
en varios spritesheets distintos, segn la categora que correspondan, de modo que los
distintos sprites que tienen que ver con el personaje principal vayan en uno y los que tienen
que ver con efectos en otro, para evitar confusiones. En ste proyecto se ha seguido esa forma
de organizarlos, separando en distintos archivos de imagen segn qu representen.
Para poder organizarlos de cara a ser utilizados por parseadores, es necesario definir a mano
los distintos detalles de cada uno de los sprites que componen el spritesheet, de forma que se
indiquen aspectos como el identificador del sprite (por ejemplo Correr4); su ubicacin en el
spritesheet (el pixel en la esquina superior izquierda del sprite, es decir, donde inicia tanto en X
como en Y); sus dimensiones (ancho y alto de cada uno); y el centro del sprite en cuestin
(utilizado en cdigo para establecer el centro de transformaciones).
Tras crear el archivo de texto con todos los datos de cada uno de los sprites de un spritesheet,
el parseador se encargar de abrir este archivo (habindosele indicado previamente el nombre
del archivo en cuestin) y recoger todos aquellos datos para cada uno de los sprites,
almacenndolos en un vector de propiedades de sprites que tambin se le habr pasado como
referencia, de modo que almacene posicin a posicin los datos de cada sprite que encuentre
en el archivo de texto, resultando as en un vector rellenado con stos datos. ste vector
originalmente lo tiene cada Sprite creado, de modo que el propio objeto de tipo Sprite
contenga en s mismo el vector con todos los datos necesarios para su posterior dibujado en
pantalla, sabiendo cmo y qu coger para dibujar en cada momento.
3.6.3 Parseador de Animaciones

Aunque se hayan parseado todos los sprites de un spritesheet, no existe ninguna indicacin de
si algunos de stos tienen como objetivo representar los frames de una animacin. Para ello
ser necesario crear unos archivos de texto que contengan todas las animaciones que puedan
existir por cada spritesheet, de modo que el juego aplique esta sucesin de sprites con unas
propiedades determinadas (como el tiempo entre frames o de cuantos frames se compone).
Estos archivos contendrn datos como el nombre de la animacin, el frame en de inicio y de

final de sta, el tiempo que ha de transcurrir a la hora de cambiar de frame, o si la animacin
se repite de forma continua o no. De este modo, una vez parseado el archivo de texto del
spritesheet y el de sus animaciones correspondientes, solo quedar asociarlos dentro del
65
Eduardo Garca Rello
juego. Esto consigue que se puedan crear animaciones nuevas de forma muy sencilla, ya que
para activar una animacin solo se tiene que llamar al mtodo correspondiente (en este caso
CambiarAnimacion) y pasrsele el nombre de la animacin que se quiera. Tras esto el cdigo
buscar de las animaciones disponibles aquella que coincida en nombre con la solicitada,
estableciendo los datos de sta a aquellos con los que trabaja el sistema de animaciones.
Un ejemplo de archivo de animaciones podra ser el siguiente.

nombre:"stand"
frameIni:"0" frameFin:"6" tiempoPorFrame:"0.2" loop:"1"
nombre:"saltar"
nombre:"andar"
nombre:"ataque1" frameIni:"18" frameFin:"21" tiempoPorFrame:"0.2" loop:"0"

nombre:"muerte"
Cabe comentar que el valor de los frames iniciales y finales corresponde a la posicin dentro
del vector de sprites que tenemos en cada Sprite, de modo que si en el caso de la animacin
stand indica que el primero es 0 y el final 6, significar que recorrer ese vector de
propiedades de sprites cogiendo aquellos que pertenezcan al rango 0 6 (inclusive).
De esta forma el parseador solo tiene que abrir el fichero de texto que se le indique, recoger
lnea por lnea todos los datos correspondientes a cada animacin y poner stas nuevas
animaciones cada una en una posicin de un vector de animaciones, el cual se le pasar como
parmetro (y que tambin es originario de un objeto de tipo Sprite).
3.6.4 Parseador de Sprites

Es uno de los ms completos que se han creado para ste proyecto, pues dentro de s mismo
utiliza otros parseadores como son el de indicadores de lnea, el de spritesheets y el de
animaciones.
ste parseador se utiliza para crear todos los sprites que existirn en cada pantalla al momento
de crearse sta, de forma que se dejen establecidos de manera inicial, listos para ser utilizados
conforme se necesiten. Esto es muy til sobre todo a la hora de crear dinmicamente
elementos dentro de la pantalla, ya que ser mucho ms eficiente si se ha cargado todo desde
un principio a, por el contrario, que se vayan creando conforme se necesite, pudiendo
ralentizar el flujo del juego. De esta forma si se necesita en un determinado momento crear
66
Eduardo Garca Rello
cuatro enemigos del tipo que sean directamente se les asignaran sus sprites correspondientes
ya creados (con animaciones y propiedades ya incluidas), en vez d tener que cargarlos en ese
momento. Cuando se cambie de pantalla stos sprites se desecharn y se parsearn los
correspondientes a la siguiente.
Su principal objetivo
ser abrir un archivo de texto (cuyo nombre se le habr pasado
previamente) en el cual se incluyan todos los aspectos a tener en cuenta para crear cada
nuevo sprite, como son:
1. ID del sprite en cuestin (su nombre, el cual servir para identificarlo en el futuro).
2. Nombre del archivo de indicador de lneas que corresponde con su spritesheet (es
decir, aquel que informa de la lnea en la cual empiezan los datos de todos los sprites
individuales dentro de cada spritesheet, evitando que utilice sprites que no le
corresponden).
3. Nombre del archivo de indicador de lneas que corresponde con sus animaciones (de
nuevo puede darse el caso de que en el mismo archivo existan animaciones que no
tengan que ver con las suyas, de forma que cogeramos solo las que el indicador diga).
4. Nombre del archivo de imagen de la textura a utilizar (donde estarn dibujados los
sprites).
5. Nombre del archivo de propiedades del spritesheet (donde se incluyen todos los
datos de los sprites contenidos en la imagen).
6. Nombre del archivo de animaciones (donde estn detalladas todas las animaciones
que contiene ese spritesheet).
Su funcionamiento es el siguiente (se utilizarn estos nmeros como gua):

- Se abre el archivo, cuyo nombre se le ha pasado por parmetro, y se almacena toda la
informacin contenido en l, sprite por sprite.
- Para cada lnea recogida (cada lnea corresponde a un sprite) se comprueba si el nombre de la
textura del spritesheet (4) que posee ese sprite ya existe en el gestor de recursos,
comparndola con las texturas ya existentes. Si no existe le indicar al gestor los datos
necesarios para que se cree y se aada a ste; si por el contrario ya existiese, ste paso se
saltara ya que no hara falta crearla de nuevo.
- Se crea un nuevo objeto de tipo Sprite, asignndole sta textura para que la utilice, y se
establece su nombre (1) correspondiente.
- Se proceder ahora a parsear la informacin contenida en el archivo de propiedades del
spritesheet. Para ello primero se llamar a ParserIndicadorLineas (pasndole el nombre del
67
Eduardo Garca Rello
archivo de indicadores de lneas correspondiente a su spritesheet (2)) para que, acto seguido,
pueda utilizar ParserSpriteSheet (utilizando el nombre del archivo de propiedades del
spritesheet (5)) teniendo en cuenta solo aquellas lneas indicadas por ParserIndicadorLineas,
para que as estos datos queden almacenados en el vector de propiedades de sprite de ste.
- Una vez parseado el spritesheet, se proceder a parsear las animaciones propias del sprite. Se
llamar de nuevo a ParserIndicadorLineas pero esta vez indicndole el nombre del archivo de
indicadores de lneas correspondiente a sus animaciones (3),
tras lo cual se llamar a
ParserAnimaciones (pasndosele el nombre del archivo de animaciones (6)) de forma que

queden almacenadas en el vector de animaciones del propio sprite.
Con esto tendremos un sprite creado con una textura asociada en la cual estn todas las
imgenes que necesita, as como con un vector de propiedades de sprites que indica todos los
aspectos necesarios para su representacin (dimensiones, posicin en la textura,), y un
vector de animaciones que le indicar cuales contiene y cuales puede utilizar.
3.6.5 Parseador de Listas de Enemigos

Los objetos de tipo Ente que tienen como subtipo Enemigo reciben un trato distinto a los
dems objetos Ente, ya que al contrario que proyectiles, objetos o el propio personaje, los
enemigos tienen una serie de caractersticas propias tales como subtipos de enemigos, o
comportamientos de IAs asignados, entre otros.
Esta especializacin hace necesaria una cantidad de informacin extra, por lo que necesitar
tambin un archivo extra en el cual reunir estas caractersticas especiales. En ste archivo se
renen caractersticas como el nombre del enemigo, su dao base, su velocidad, su vida
mxima o las dimensiones del bounding que rodea su cuerpo, as como una lista con todos y
cada uno de los nombres de las IAs que tiene asignadas.
Para recoger y almacenar estos datos se ha creado el mtodo ParserListaEnemigos, que

funciona de forma muy simple: tras cargar el archivo que se le ha indicado (mediante un
nombre, como el resto de parseadores) comenzar a recoger los datos de la primera lnea, los
cuales son el nombre, el dao base, la velocidad, la vida y las dimensiones del bounding. Una
vez tiene estos datos proceder a avanzar de lnea en lnea recogiendo el nombre de la IA que
aparezca en cada una, almacenndolas en un vector de IAs que tiene el propio Ente de tipo
Enemigo.
68
Eduardo Garca Rello
Para asignar correctamente los datos, el parseador recorrer el vector de objetos de tipo Ente
que contiene el gestor de recursos para detectar a aquel que sea de tipo Enemigo y, si lo
encuentra, comparar el nombre de ste con el del que ha recogido en los datos parseados. Si
coincide comenzar a rellenar la informacin de ese enemigo con lo que acaba de parsear.
3.6.6 Parseador de Entes

Junto con el de sprites y el de mapas, el parseador de entes es de los ms complejos que se
han implementado. Su objetivo es, para cada pantalla, cargar al principio todos aquellos entes
que la habitarn, de forma que no se necesite parsear su informacin y crearlos
dinmicamente conforme se necesite. De este modo solo se tendra que coger un tipo de los
que ya existen e insertarlo en el juego, agilizando el proceso y proporcionando una mayor
facilidad de cambio al estar la informacin ubicada en ficheros de texto ajenos al cdigo.
En los ficheros de texto que utilizar el parseador para recoger la informacin de los entes nos
encontramos con datos que variarn dependiendo del tipo de ente que nos encontremos.
Estos son algunos ejemplos de los que se han implementado:
//Jugador
tipoEnte:"SerAtacable" tipoSerAtacable:"Jugador" tipoJugador:"Melee" posX:"14" posY:"12"
// Enemigos
tipoEnte:"SerAtacable" tipoSerAtacable:"Enemigo" tipoEnem:"Murci" posX:"40" posY:"5"
tipoEnte:"SerAtacable" tipoSerAtacable:"Enemigo" tipoEnem:"Clon" posX:"40" posY:"8"
//Obstaculos
tipoEnte:"SerAtacable" tipoSerAtacable:"Obst" tipoObst:"Jarron" posX:"27" posY:"11"
tipoEnte:"SerAtacable" tipoSerAtacable:"Obst" tipoObst:"Bloque" posX:"43" posY:"11"
Como se puede ver, en ste ejemplo existen tres tipos de entes distintos: jugador, enemigos y
obstculos. Dentro de cada uno existen variables propias, como tipoJugador o tipoEnem,
las cuales solo pertenecen a sus respectivos dueos. La posicin est indicada en tiles, de
modo que si, por ejemplo, las dimensiones de los tiles de esa pantalla fuesen 48x48,
significara que el personaje se ubicara en la posicin (14x48, 12x48), es decir, (672, 576).
El funcionamiento de ste parseador se basa en los siguientes pasos:
69
Eduardo Garca Rello
1. Abrir el archivo correspondiente (tras pasrsele el nombre) y crear un vector de

indicadores de lneas, que mostrar dnde estn las lneas de inicio de cada uno de los grupos
de entes en el archivo (en el ejemplo anterior: jugador, enemigos y obstculos).
2. Ubicndose en stas lneas, comenzar a comprobar los datos, mirando primero el tipo de
ente, de modo que realizaremos una seccin u otra del mtodo segn el tipo que sea. De este
modo si se encuentra con un tipo de ente Jugador, crear un objeto de tipo Jugador y lo
rellenar con los datos de la lnea en cuestin, tras lo cual lo aadir al vector de objetos de
tipo Ente que tiene el gestor de recursos. Lo mismo ocurrir para cualquier otro tipo de ente
que encuentre, teniendo siempre en cuenta ste tipo para asignar unos datos u otros.
3. En el caso de haber encontrado enemigos, marcar una variable hayEnemigos a true, de
forma que si tras leer todos los entes se ha dado el caso de que esta variable es true (es decir
que existen enemigos), realizar una accin ms: completar la informacin de stos enemigos
mediante el uso del parseador de listas de enemigos (ParserListaEnemigos), de forma que
queden completos con la informacin caracterstica a cada tipo y las IAs que les correspondan.
Cabe destacar que cuando se inicia el parseador, ste realiza una peticin al gestor de recursos
para vaciar todos los entes ya existentes, de forma que no queden residuos de aquellos que
fueron cargados para otras pantallas.
3.6.7 Parseador de Tiles Animados

En los mapas que se cargarn pueden existir tiles que posean animacin y que por tanto
requieran de datos y comportamientos especiales que los normales no tienen.
Este parseador usa un sistema similar al parseador de animaciones, pero en este caso tratar
con estructuras de tipo TileAnimado y no con objetos de tipo Sprite. En este caso tendremos
los mismos datos que se necesitaban para el parseador de animaciones: un identificador para
la animacin, un frame inicial y otro final, as como un tiempo por frame. Sin embargo en este
caso el identificador hace referencia al id que posee el tile en cuestin, as como los frames
iniciales y finales vienen determinados tambin por el id del tile inicial y el id del tile final.
El funcionamiento de este parseador es muy simple, pues solo consiste en recoger los datos
del fichero cuyo nombre se le ha pasado al parseador, y almacenar estos datos en un vector de
tiles animados que posee el gestor de recursos.
70
Eduardo Garca Rello
El siguiente ejemplo muestra dos ejemplos de frames animados:
Fig. 3.15 - Informacin en archivo de texto y textura en SpriteSheet de tiles animados.
3.6.8 Parseador de Tiles Especiales

Los tiles, adems de poder estar animados, tambin pueden desempear papeles especiales
con respecto al juego, algunos directamente con los entes del escenario y otros ms de cara a
eventos y sensores.
El funcionamiento del parseador es tambin bastante sencillo: abrir el archivo que se le ha

dicho que abra (mediante el nombre de ste, pasado como parmetro), y para cada tile
especial que encuentre agregar una posicin en un vector de tiles especiales que tiene el
gestor de recursos. As, dentro de cada posicin estarn almacenados los datos
correspondientes al tile en cuestin, de modo que ir leyendo y comprobando, gracias a la
variable tipo que encontrar en cada lnea, qu tipo de tile es y por tanto entrando en unos
apartados u otros del mtodo, asignando entonces los datos encontrados a variables propias
de stos tiles.
71
Eduardo Garca Rello
3.6.9 Parseador de Mapas

El parseador de mapas es sin duda el ms complejo que se ha implementado en este proyecto,
ya que supone una gran carga parsear y organizar todos los tiles que componen cada pantalla,
as como las propiedades de cada uno.
Como se ha comentado, se ha decidido desarrollar el videojuego basndose en la elaboracin

de mapas o pantallas construidas por capas de tiles. Estos mapas son realizados por la
herramienta Tiled y guardados en ficheros de tipo XML, donde aparecern organizados por
grupos las propiedades del mapa y el nmero identificador de cada tile.
El mapa est almacenado en una matriz construida mediante 3 vectores: uno para las capas,
otro (incluido en el anterior) para las filas y el ltimo (incluido en el anterior) para las
columnas. De este modo se irn leyendo tile a tile de forma horizontal (columnas) hasta
alcanzar el fin de la fila, tras lo cual se pasar a la siguiente fila, repitindose el proceso hasta
llegar al final de la ltima fila, pasando entonces a la siguiente capa (si la hubiese), y
empezando de nuevo a leer columna a columna, fila a fila. Mediante la forma en la que se ha
estructurado as como por el hecho de usar vectores, no importa el tamao del mapa en capas
o en filas o columnas, siempre se leer y almacenar correctamente.
Para que todos estos tiles cobren sentido y se representen de forma correcta y ordenada, es
necesaria la labor del parseador de mapas, el cual realiza los siguientes pasos, organizados por
los dos mtodos principales que utiliza:
ParserMapa
Es el mtodo principal de ste parseador, trabajando del siguiente modo:
1. Se llamarn a los parseadores de tiles animados y tiles especiales, de modo que queden
almacenados en sus vectores correspondientes y puedan ser comparados posteriormente uno
a uno con los tiles que se hayan parseado.
2. Tras esto se llamar al gestor de recursos para vaciar la matriz del mapa, as como el vector
de tilesets y el de propiedades de capas (cuya funcionalidad se comentar en los siguientes
pasos).
3. Se comenzar a parsear leyendo primero las propiedades generales del mapa, como son el
nmero de tiles en ancho y alto que lo componen o las dimensiones de cada tile.
72
Eduardo Garca Rello
4. Acto seguido se comprobarn si hay propiedades especficas del mapa, y de existir se

parsearn. Estas propiedades pueden ser las que se les quiera indicar en el programa Tiled,
como pueden ser el caso del nmero de capas o la posicin inicial del personaje en el mapa.
5. A continuacin se almacenar el nmero de tilesets que tiene el mapa y se recorrer en
bucle uno a uno stos tilesets, comprobando primero si su textura ya existe en el gestor de
recursos y almacenando la informacin de cada uno, como es la dimensin de cada tile en el
tileset, el espaciado entre uno y otro que existe en l, el nmero de filas y columnas o la
ubicacin del archivo, entre otros. Si el archivo del tileset no se ha encontrado entre las
texturas que tuviese ya cargadas el gestor de recursos se procedera a agregarla a ste.
6. Una vez parseada y almacenada toda esta informacin de los mapas se proceder a llamar a
LeerMapaTiles.
LeerMapaTiles
Es el encargado de parsear uno a uno todos los tiles que componen el mapa, comparando a su
vez si tienen algn tratamiento especial por ser especiales o animados.
Tiled organiza el XML que exporta primero indicando la capa en la que est y luego todos los
tiles que la componen, siendo el parseador el encargado de saltar de lnea cuando se deba
teniendo en cuenta el nmero de columnas indicadas. De este modo podemos distinguir dos
secciones en ste mtodo, dependiendo de si en la lnea que ha ledo ha detectado que es una
de las que indica el salto de capa o si por el contrario es una lnea de tipo tile:
1.1. Si es una lnea de tipo capa lo primero que har es almacenar los datos que se acompaan
a esta lnea en las prximas a ella, que contienen informacin sobre el tipo de capa y sus
propiedades, tales como si es de tipo colisionable, si es de tipo frontal, la velocidad de scroll
que lleva o la dimensin de sus tiles.
1.2. Una vez almacenada la informacin de la capa se proceder a agregarla al vector de capas,
as como creando una nueva fila en el vector de filas de forma que se prepare para incluir la
informacin en sta primera fila de capa. Adems se crear un vector de columnas por el
mismo motivo, ya que habremos empezado una nueva capa y por tanto se encontrar
inmediatamente con una columna nueva en una fila nueva.
2.1. Si por el contrario es una lnea de tipo tile se almacenar primero el nmero que lo
identifica y si es un tile colisionable o no, teniendo en cuenta si est o no en una capa de tipo
colisionable. Si el id (nmero que lo identifica) es 0 significa que es un tile vaco, por lo que
estableceremos su variable dibujable a false, de forma que se ahorre el dibujado de ste tile
por carecer de dibujo.
73
Eduardo Garca Rello
2.2. Ahora se proceder a comprobar si es un tile de tipo especial. Como los tiles especiales
son los que interactan de alguna forma con el usuario o las entidades que han sido creadas
en la pantalla, solo ser necesario comprobar si hay tiles especiales en las capas cuya variable
capaTipoFrontal es cierta, ya que no interesa poner tiles especiales en capas de, por
ejemplo, el fondo porque el usuario no interactuar con ellas. Si esta condicin la cumple y
adems es un tile cuyo id es distinto de 0, se empezar a recorrer el vector de tiles especiales
que se ha almacenado en el gestor de recursos, comprobando si el id de alguno de stos tiles
especiales corresponde con el que se est parseando en ste momento. De ser as se
rellenarn las variables del tile que lo definan como uno especial (tipo de tile especial, si es
dibujable y si es colisionable) teniendo en cuenta lo que tenga establecido ese tile especial que
se ha encontrado en el vector.
2.3 El siguiente paso consiste en crear un nuevo objeto de tipo Tile y agregarlo al mapa. De
esto se encarga la clase Mapa, por lo que se llamar al mtodo NuevoTile que contiene la clase
Mapa para que lo cree con los datos que necesite del tile, como por ejemplo su id, si es
dibujable, si es colisionable, el tileset en el cual aparece o sus dimensiones entre otros.
2.4 Por ltimo lo que queda es comprobar si el tile en cuestin est animado, para lo cual se
recorrer el vector de tiles animados que tiene el gestor de recursos, comprobando uno a uno
el id para ver si coincide con el que est parseando en ese momento. De ser as rellenaremos
las variables que tiene el tile que proporcionan informacin sobre la animacin, como son el
frame inicial y el final o el tiempo entre frames. Se activa por defecto la repeticin de la
animacin (loop) ya que los tiles del escenario siempre estarn en movimiento si poseen
animacin.
Una vez se hayan terminado estos pasos el mapa estar parseado por completo,
independientemente de los datos que tenga de las dimensiones de ste ya que gracias al
desarrollo basado en un diseo genrico da igual cmo se modifique cada pantalla pues
siempre se leer correctamente.
3.6.10 Parseador de Textos

Como se explica en la seccin dedicada al Sistema de Textos, en el proyecto se han decidido
incluir dilogos que permitan contar la historia o simplemente ofrecer indicaciones sobre la
marcha.
74
Eduardo Garca Rello
El objetivo del parseador es recoger los textos que sirvan para dilogos e indicaciones (ya que
existen otros que se generan automticamente, como son los indicadores de dao, que no
precisan de parseador) de forma que se puedan representar por pantalla de forma sencilla y
sin apenas esfuerzo durante la ejecucin.
Su funcionamiento es bastante sencillo y sigue el mismo modus operandi que algunos ya

explicados: primero abre el archivo que se le indique por el nombre que se le pasa por
parmetro, y luego recoger y almacenar en una variable el nombre del texto, as como en
otra todo el bloque de texto correspondiente que aparece despus. Una vez conseguidas estas
dos variables se almacenan en un vector de textos, que ha sido pasado por referencia
previamente, devolvindose ya lleno.
3.7 Entes
En el juego existen una gran cantidad de entidades que contienen propiedades comunes entre
ellos, como es la facultad de realizar colisiones (ya sea con tiles o con otras entidades), poder
desplazarse con velocidad, o la posibilidad de ser animado, entre muchas otras. Estas
entidades se crean gracias a la clase Ente, la cual los dota de todos estos aspectos. En todo
momento los entes reaccionarn a la gravedad (si se ha especificado que un ente en concreto
sea ingrvido) as como tienen la posibilidad de morir, siendo eliminados cuando se detecte
que han muerto.
De este modo tenemos como ejemplo de entes al personaje principal, enemigos, obstculos
como jarrones o rocas, proyectiles, objetos o NPCs. Todos tendrn la posibilidad de colisionar
entre ellos (a menos que se especifique lo contrario teniendo en cuenta la situacin), ser
animados y desplazarse, segn se requiera.
Sin embargo un objeto consumible dista mucho de lo que podra ser el personaje principal o de
un enemigo, por lo que la clase Ente tendr una herencia comprendida por otras subclases,
especializndolos an ms segn se requiera.
3.7.1 Seres Atacables

Dentro de sta clase hija de Ente encontramos a aquellas entidades que contienen aspectos
tales como una cantidad de vida propia o la posibilidad de recibir y de emitir dao a otros
75
Eduardo Garca Rello
seres atacables. En esta categora encontramos tanto al personaje como a los enemigos, as
como a los obstculos que existirn en el juego. Al tener el atributo de VidaActual y
VidaMxima los seres atacables morirn en cuanto su VidaActual sea menor o igual a 0.
3.7.1.1 Personaje Principal

El personaje principal tiene ms caractersticas que cualquier otro ente del juego, ya que tiene
que poder desenvolverse correctamente en todos los gneros, haciendo uso de un amplio
nmero de habilidades y adaptndose a cada situacin sin problemas. Hijo de la clase
SerAtacable, contiene el atributo de VidaActual y VidaMaxima, mostrado por pantalla
mediante el HUD, de modo que pueda recibir dao por parte de los elementos dainos que
vaya encontrando (ya sean obstculos, tiles especiales peligrosos o enemigos) as como
recuperar vida con los objetos que vaya recogiendo o haciendo uso de la habilidad
correspondiente.
3.7.1.1.1 Sistema de Niveles

El personaje ir evolucionando conforme avance en el juego puesto que tras eliminar
enemigos recibir una cantidad de experiencia determinada por el tipo de enemigo destruido.
Esta experiencia se ir incrementando hasta sumar la experiencia mxima que tenga en cada
momento, y una vez superada subir un nivel ms. Tras la subida del nivel el personaje se
quedar con la experiencia que haya sobrado de la subida de nivel, de modo que si por
ejemplo la experiencia para subir nivel es 1000 y el jugador tena 1020 en un determinado
momento, subir un nivel y se pondr con 20 de experiencia, tras lo cual podr ir recolectando
ms experiencia para repetir el proceso.
Al subir de nivel suceden varias cosas: por una parte la cantidad mxima de experiencia para
subir de nuevo un nivel se incrementar, costando as algo ms subir de nivel (evitando que
sea demasiado fcil, teniendo en cuenta adems que conforme avance el jugador los enemigos
sern ms duros y darn ms experiencia an); y por otra parte el jugador recibir un punto de
recompensa para poder distribuirlo entre los atributos de los que dispone.
Al subir estos atributos el personaje mejorar en el aspecto al cual corresponda el atributo, a

tener en cuenta:
76
Eduardo Garca Rello
- FUERZA: determina la capacidad ofensiva del personaje. Subir ste atributo

aumentar la fuerza base con la cual emitir dao al atacar.
- DEFENSA: determina la capacidad defensiva del personaje. Al subir ste atributo se
incrementar la resistencia del personaje, reduciendo el dao que pueda recibir.
- VITALIDAD: determina la vida mxima del personaje. Subir este atributo permite
aumentar el mximo de vida que tendr el personaje.
- ENERGA: determina la energa mxima del personaje. Subir ste atributo aumentar
la cantidad mxima de energa que dispone el personaje.
Para subir cualquiera de stos atributos el jugador simplemente tiene que ir al men de pausa
y, si tiene puntos disponibles, pulsar en el botn al lado de cada atributo para incrementar el
atributo correspondiente. La mejora es instantnea, de modo que en el momento en el que
gaste el punto recibir los beneficios asociados a sta mejora.
Fig. 3.16 Men de pausa con estadsticas
De este modo se ofrece un sistema que permite la evolucin en juego del personaje y por
tanto mejorar la jugabilidad del juego, ya que el jugador puede elegir qu potenciar en cada
momento del personaje, inclinndolo en hacerlo mucho ms ofensivo, defensivo, con mayor
capacidad de supervivencia o mayor facultad para realizar habilidades, o incluso mezclar
atributos y crear un personaje hbrido acorde a sus gustos.
77
Eduardo Garca Rello
A pesar de que el sistema de niveles y de reparto de puntos a atributos es propio (o

mayormente extendido) de gneros como el RPG, se ha comprobado que funciona
perfectamente en otros gneros, como se ha podido demostrar con ste proyecto, ya que se
adapta sin problemas a gneros como el de accin/plataformas o el Shoot Em Up, algo que no
se suele ver.
3.7.1.1.2 Movimientos Base
Aparte de las habilidades el personaje podr realizar una serie de movimientos que
determinan la base de su control. Estos movimientos dependen del gnero en el que est
jugando el jugador en cada momento, pero en esencia tienen un comportamiento similar.
El jugador, tanto en el gnero Accin/Plataforma como en el de Carrera podr hacer que el

personaje salte. Estos saltos vienen determinados por el tiempo que mantenga pulsado el
jugador el botn de salto, de modo que si lo suelta rpidamente el salto tendr poca altura
pero si lo mantiene pulsado ms tiempo la altura ser algo mayor (siempre alcanzando un
mximo para evitar volar).
De este modo segn el gnero encontramos:

- Gnero Accin/Plataformas: en ste gnero el jugador podr desplazarse andando
horizontalmente, de modo que pueda recorrer con total libertad el escenario sin
ningn problema. Junto con el movimiento horizontal en jugador podr saltar para
poder superar obstculos o atacar desde el aire. Tanto el hecho de andar como el de
saltar est condicionado por el terreno, ya que en ste gnero colisiona con los tiles de
tipo colisionable. Tanto al personaje como a cualquier elemento que se desplace
horizontalmente, su movimiento est tambin afectado por un leve rozamiento con el
aire, casi imperceptible, que evita que puedan desplazarse eternamente. En cuanto al
mbito vertical se ver afectado por la gravedad que tenga cada pantalla.
- Gnero ShootEm Up: en ste gnero el jugador podr desplazarse al igual que lo
haca en horizontal, pero como novedad podr hacerlo tambin de forma vertical,
pudiendo desplazarse libremente por toda la pantalla. Al contrario que en el gnero
Accin/Plataformas, en ste gnero el jugador no ser el que desplace la cmara, sino
que la cmara se mover independientemente del jugador, con una velocidad
determinada por el mapa. Aqu no existir ni rozamiento con el aire ni gravedad, pero
si el jugador deja de desplazarse el personaje comenzar a frenar hasta dejar de tener
78
Eduardo Garca Rello
velocidad, de modo que el control no sea confuso y difcil de manejar. En ste gnero
el jugador no podr saltar, ya que sera ilgico pues no hay gravedad. Al contrario que
en el gnero RPG o Accin/Plataformas, colisionar con el terreno que pueda aparecer
supone reducir la vida drsticamente al personaje, por lo que tendr que tener
cuidado de no rozar ningn tile de tipo colisionable.
- Gnero Carrera: este gnero mezcla los dos anteriores, de modo que el jugador podr
desplazarse tanto horizontal como verticalmente pero tambin podr saltar. Solo
podr desplazarse por dentro de la zona de circulacin, ya que est delimitada por tiles
de colisin que daan al personaje si entra en contacto con ellos (aunque reduciendo
menos la vida que en el gnero Shoot Em Up). Existir gravedad de modo que los
saltos puedan realizarse correctamente. En cuanto al movimiento horizontal hay que
tener en cuenta que al ir a gran velocidad cuesta ms acelerar y menos frenar, por lo
que ser ms fcil ir hacia atrs que ir hacia delante. La cmara se desplazar como en
el gnero Shoot Em Up, de modo que no ser el jugador el que la maneje
- Gnero RPG: aqu no existirn fsicas, ya que se ha pretendido desarrollar un tipo de

RPG rememorando los antiguos, tales como Zelda, Final Fantasy o Pokmon, de modo
que el jugador se desplazar por celdas, sin necesitar acelerar para moverse. El jugador
solo podr desplazarse horizontal y verticalmente siempre y cuando la celda contigua
no sea colisionable. La cmara se mover con el jugador, de modo que conforme vaya
avanzando la cmara avanzar con l.
- Gnero Vertical: el movimiento es similar al del gnero Carrera, pero la friccin con el
aire (al descender) ser mayor por lo que costar algo ms desplazarse hacia abajo y
menos hacia arriba. En ste gnero tambin podr desplazarse en horizontal y en
vertical. La cmara se mover con la velocidad que tenga predefinida en el mapa,
independientemente del jugador.
3.7.1.1.3 Habilidades
El personaje (aparte del movimiento base) tendr una serie de habilidades, ya sean innatas o
adquiridas por el escenario. Estas habilidades le sern tiles para sortear los diversos
obstculos que encontrar por el camino. stas habilidades podrn usarse en mltiples
gneros, pero existirn diversas ocasiones en las que no podr utilizarlas si la situacin no lo
79
Eduardo Garca Rello
permite. La mayora de stas habilidades consumen puntos de energa, de modo que el

jugador tendr que sopesar si realizarlas o no teniendo en cuenta si quiere ahorrar energa o
prefiere gastarla y luego recuperarla por otros medios.
Sin embargo a lo largo de la aventura el jugador podr ir consiguiendo una serie de habilidades
para su personaje que le permitirn o bien mejorar en algn aspecto o bien aadirn un
comportamiento nuevo al personaje. Estas habilidades se pueden conseguir ya sea a mitad de
camino o bien tras un evento como puede ser el fin de una pantalla o derrotar a algn
enemigo en concreto.
Las habilidades son las siguientes:
- Espada: el personaje contar con sta habilidad nada ms empezar el juego,

suponiendo su principal forma de atacar en tal momento. Podr atacar en cualquier
direccin (arriba, abajo, izquierda y derecha), pudiendo realizar un combo de dos
ataques si es el ataque es lateral.
Fig. 3.17 Ataque lateral 1
80
Eduardo Garca Rello
Fig. 3.18 Ataque lateral 2
- Ataque Cargado: el personaje podr cargar el ataque de su espada dejando pulsado el

botn de atacar (siempre y cuando sea el primer ataque y no sea el combo de 2
ataques el que est realizando), de modo que tras transcurrido un breve periodo de
tiempo pueda soltarlo y liberar el ataque, produciendo una gran cantidad de dao a
aquellas entidades golpeadas. Consume una pequea cantidad de energa.
Fig. 3.19 Utilizando el ataque cargado
- Pistola: permite al personaje disparar proyectiles con ella, permitiendo as alcanzar

una distancia mayor que con la espada. Esta habilidad no entra en la categora del
resto, de modo que solo se puede seleccionar alternando entre la espada o sta
mediante la rotacin de armas y no la de habilidades (como ocurre en otros casos).
Tiene infinitos proyectiles pero solo puede haber un reducido nmero de ellos en
81
Eduardo Garca Rello
pantalla a la vez, de modo que hay que esperar a que se elimine uno para lanzar el
siguiente tras superar ese mximo. No consume energa.
Fig. 3.20 Disparo con la pistola
- Disparo Cargado: al igual que ocurra con el Ataque Cargado, cuando consiga esta
habilidad el jugador podr activar el ataque cargado manteniendo pulsada la tecla de
ataque, pero en esta ocasin podr liberarlo en cualquier momento, sin necesidad de
que cargue completamente. Sin embargo esto determina el dao producido por el
disparo cargado, ya que cuanto ms se mantenga pulsado mayor dao ocasionar (con
un mximo, de modo que si pulsa ms all de ste solo quitar el mximo posible).
Consume una pequea cantidad de energa
Fig 3.21 Lanzando Disparo Cargado
82
Eduardo Garca Rello
- Esquive: el personaje podr realizar un esquive lateral que ignorar todo dao
recibido durante dicha habilidad, avanzando a la vez a gran velocidad hacia el lado al
que se haya ejecutado. Esta habilidad permite adems que si el usuario salta antes de
acabar el esquive pueda saltar una distancia an mayor. Consume una pequea
cantidad de energa.
- Doble Salto: el personaje podr saltar en el aire, de modo que pueda llegar a una
mayor distancia que antes. Si el jugador ha iniciado un salto podr ejecutar otro en
cualquier momento, si por el contrario el jugador no ha realizado un salto pero est
cayendo desde alguna plataforma podr pulsar en el aire el botn de salto para realizar
un salto en mitad del aire, ya que de otro modo si no tuviese esta habilidad y se
hubiese cado de una plataforma no podra hacer nada por evitar la cada. No consume
energa.
- Regenerador de energa: tras adquirir esta habilidad, el jugador podr ir recuperando

energa progresivamente. El contador de regeneracin no comenzar hasta que no
haya pasado un breve periodo de tiempo desde que se realiz la ltima habilidad que
consuma energa. No consume energa (por motivos evidentes).
- Transmutador de energa: sta habilidad permite que el personaje pueda transmutar

su energa convirtindola en vida, de modo que por cada cierta cantidad de energa se
regenere un poco de vida. Esto podr realizarlo siempre que tenga la energa necesaria
para iniciar la transmutacin. Durante la transmutacin el jugador se quedar
desprotegido y no podr atacar, pero puede detenerse sta habilidad siempre que se
quiera soltando el botn. Consume tanta energa como se quiera transmutar.
Fig. 3.22 Usando transmutador de energa.
83
Eduardo Garca Rello
- Escudo de Energa: el personaje podr, con esta habilidad, protegerse temporalmente

de daos que pueda causarle cualquier elemento del entorno. El escudo comenzar a
parpadear cuando vaya a acabarse, indicando al usuario de ello. Consume una
moderada cantidad de energa.
Fig. 3.23 Escudo de energa rodeando al personaje
- Ametralladora: con sta habilidad el personaje podr mantener pulsado el botn de

la habilidad y, tras un breve periodo de carga, disparar una gran cantidad de disparos
horizontales. Cada disparo consume una pequea cantidad de energa, de modo que
hay que tener cuidado de cunto tiempo hay que mantener activada esta habilidad, ya
que podra consumir toda la energa disponible en cuestin de segundos. Consume
energa por disparo.
Fig. 3.24 Ametralladora mientras se desplaza hacia arriba
84
Eduardo Garca Rello
- Bomba de Energa: sta habilidad permite que, tras su carga (manteniendo pulsado el
botn) se libere un pequeo proyectil que no afectar a los enemigos, el cual recorrer
una determinada distancia para luego detenerse y, tras unos segundos, detonar en una
gran explosin que daar bastante a los enemigos que la colisionen. Esta explosin
durar unos segundos por lo que puede afectar mltiples veces a los enemigos que
sigan colisionndola. Consume una elevada cantidad de energa.
Fig. 3.25 Proyectil pequeo que precede a la Bomba de Energa
Fig. 3.26 Bomba de energa una vez explotando.
3.7.1.2 Enemigos
Durante el juego el jugador se ir encontrando con un amplio nmero de enemigos que
intentarn acabar con su personaje, todos ellos con un comportamiento determinado
teniendo en cuenta su inteligencia artificial.
85
Eduardo Garca Rello
El juego identifica el nombre de cada enemigo de modo que sepa a qu parte dirigirse para
establecerle los datos segn aparecen con el nombre del enemigo correspondiente dentro de
los ficheros oportunos. De este modo cada tipo de enemigo tendr una vida, energa,
experiencia, dimensiones del cuerpo, IAs y dems atributos de forma personalizada, por lo que
cada vez que se cree un enemigo se genere acorde a los datos de cada tipo. Esto permite que
se modifiquen stos datos de forma muy sencilla e intuitiva simplemente acudiendo a los
ficheros correspondientes, permitiendo as generar mltiples enemigos nuevos sin salir del
fichero. De hecho el juego no es el encargado de crear nuevos tipos de enemigos, es el propio
desarrollador el que los especifica fuera del cdigo, siendo ste el encargado nicamente de
recogerlos.
De este modo encontramos enemigos que pueden volar/levitar, arrastrase por el suelo, dar
saltos, embestir al jugador, dispararle, volverse invencibles, etc, todo determinado por la
inteligencia artificial que disponga cada uno.
Al ser de tipo Ser Atacable, los entes creados bajo la clase Enemigo dispondrn de vida y por
tanto pueden ser eliminados. Una vez eliminados stos proporcionarn una cantidad de
experiencia al personaje principal, as como tambin existe la posibilidad de dejar caer un
objeto que pueda ayudarle (como restauracin de vida o de energa, as como un poder
temporal).
Cuando un enemigo recibe dao aparecer su barra de vida sobre l, mostrando la vida actual
de dicho enemigo. Adems de la barra tambin aparecer un nmero mostrando el dao
causado.
Los enemigos solo comenzarn a actualizarse cuando estn dentro de un rango de proximidad
respecto al personaje, de modo que aquellos que estn lejos de ste no se tendrn en cuenta
para actualizarse, optimizando el juego (ya que stos enemigos no tendran forma de afectar al
usuario de ninguna forma).
3.7.1.2.1 Inteligencia Artificial

Se han realizado en total 22 comportamientos distintos que dotan de un gran repertorio de
acciones a los enemigos que los contienen. De este modo existir una amplia gama de recursos
86
Eduardo Garca Rello
para poder elaborar nuevos enemigos y que se puedan adaptar a las situaciones que se
presenten para hacerle la aventura ms difcil al protagonista.
Cada enemigo, por tipo, contiene en un fichero todos sus datos como se ha mencionado antes,
inclusive todas aquellas IAs (como se indica, una por clase), que contiene. Adems del nombre
de la IA en cuestin que deba utilizar, cada una de stas tienen una serie de variables que
definen todas y cada una de sus propiedades, lo que significa que varios enemigos con la
misma IA podrn utilizarla de forma distinta.
Entre estas variables encontramos el dao que pueden efectuar (si son ofensivas), el tiempo
de espera para volver a utilizarla, el nmero de proyectiles a disparar si los tuviese (as como el
tipo de proyectil y velocidad entre otras), el rango espacial en el cual realizar la IA, entre otras
muchas cosas.
Sin embargo, lo que ms cabe destacar de stos datos es que, aparte de aquellos que
simplemente sirven para cambiar variables sin que se modifique el comportamiento en s
(como los comentados anteriormente), existen otros que s permiten alterar el
comportamiento de la IA sin cambiar su filosofa, de modo que una misma IA puede generar
dos, tres o incluso en alguna ocasin hasta 5 comportamientos parecidos pero con aspectos
nicos. Al tratarse modificaciones de una IA base se ha decidido que se puedan elegir as ,
mediante un nmero (indicando la variante de la propia IA que se quiere realizar) en vez de
crearlo en una IA aparte. Gracias a esto, de 22 IAs se podra decir que en realidad existen ms
de una decena extra.
Cabe destacar que todas las IAs tienen un tiempo de espera tras la realizacin, el cual se
especifica al lado de cada IA en su correspondiente fichero, de modo que no volver a realizar
una IA hasta que no se haya superado este tiempo. Aun as se puede establecer a 0 y no
esperar. A su vez, es importante recordar que todos los aspectos esenciales de una IA pueden
ser modificados desde el fichero correspondiente (ya sea velocidades de movimiento, numero
de disparos, tiempos de espera, etc).
A continuacin se detallan cmo se comportan las distintas inteligencias artificiales as como

sus variantes:
87
Eduardo Garca Rello
- PatrullarRandom: el enemigo en cuestin se desplazar horizontalmente en una direccin

durante un breve periodo de tiempo, tras lo cual parar y se mantendr quieto hasta superar
otro lapso de tiempo, retomando tras ello de nuevo el desplazamiento pero en una direccin
aleatoria. Si est cerca de una pared no se desplazar en la direccin en la que sta est.
- PatrullarSeguido: el enemigo se desplazar horizontalmente en una direccin

constantemente. Existen dos variantes:
- Detectando colisin: cuando choque contra una pared lateral cambiar el rumbo y se
desplazar en direccin contraria hasta que vuelva a suceder lo mismo. Se puede
especificar si se desea que se quede parado un determinado tiempo tras chocar.
- Sin detectar colisin: el enemigo seguir eternamente en una direccin sin importar si
colisiona o no.
- Perseguir: si el enemigo detecta en un rango determinado al jugador, se desplazar hacia l a

mayor velocidad. Existen 3 variantes
- En rango: se activa siempre que el personaje haya sido detectado.
- En rango y visto: solo se activar cuando el personaje haya sido detectado y el
enemigo lo est viendo. Si el personaje se aleja de su campo de visin el enemigo
dejar de perseguirle.
- En rango y fijado: si el enemigo est prximo al personaje y ha sido detectado en su
campo de visin lo fijar y no dejar de perseguirle nunca, aunque se aleje de su rango.
- Embestir: si el personaje est dentro del rango de embestida del enemigo, ste embestir al
personaje mediante un impulso en horizontal y/o en vertical para atacarle con su cuerpo. El
nmero de embestidas tambin se puede configurar, de modo que har seguidas tantas como
se haya estipulado. Cabe destacar el hecho de que al poder establecerse el impulso en ambos
ejes, es posible utilizar esta IA para un gran nmero de enemigos distintos, como pueda ser
alguno que salte en vertical solamente para alcanzar al personaje en altura o bien en vertical y
horizontal para emboscarle desde arriba, entre otras.
Tiene 2 variantes:
- En rango: solo la realizar si el personaje est cerca de l.
- En rango y visto: solo cuando est prximo y sea observado lo har.
- Invencible: durante la realizacin de esta IA el enemigo no se mover pero tampoco podr

recibir dao.
88
Eduardo Garca Rello
- Invocar: el enemigo invocar a otro de un tipo determinado para que ataque al jugador.
Podr crear tantos como se haya especificado, de modo que si ha superado este lmite no
podr crear nuevos hasta que los anteriores mueran.
- DispararRecto: el enemigo podr disparar proyectiles (tantos como se haya especificado). Se

puede especificar si los disparos se hacen en horizontal o si se fijar al jugador para dispararle
a l. A su vez existen 4 variantes:
- En rango: solo disparar cuando el personaje est dentro del rango de deteccin.
- En rango y visto: solo si el personaje est en rango y el enemigo lo est mirando.
- Constante: el enemigo disparar sin ningn requisito de forma constante.
- Constante y finito: al igual que el anterior pero con nmero de disparos finitos.
- DispararRadial: el enemigo disparar una serie de proyectiles en varias direcciones, teniendo

en cuenta las variantes de sta IA. Los disparos vienen fijados por stas variantes pero jams
apuntan al personaje intencionadamente. Existen 3 variantes en cuanto a forma de activarse:
- En rango: solo disparar cuando el personaje est dentro del rango de deteccin.
- En rango y visto: solo si el personaje est en rango y el enemigo lo est mirando.
- Constante: el enemigo disparar sin ningn requisito de forma constante.
Pero el punto fuerte de esta IA reside en sus 7 variantes de disparos, permitiendo usar el
mismo modus operandi de disparos pero cambiando stos:
- 8 Direcciones: dispara tanto en cada punto cardinal como en sus bisectrices a la vez.
- En forma de +: dispara 4 proyectiles, uno en cada punto cardinal.
- En forma de x: dispara 4 proyectiles, uno en cada bisectriz de los puntos cardinales.
- 8 direcciones random: al igual que el primero pero solo se emitirn aquellos disparos
cuyo random entre 0 y 1 de 1. Cada vez que se dispara una ronda se realiza el random.
- Direccin aleatoria: realizar a la vez el nmero de disparos que se le indique, pero
cada uno se lanzar en un ngulo aleatorio.
- Direccin aleatoria por cuadrante: al igual que el anterior pero solo se realizar en el
cuadrante que se indique (1: arriba-der, 2: arriba-izq, 3: abajo-izq, 4: abajo-der)
- 3 disparos: realizar 3 disparos (diagonal-arriba, central, diagonal-abajo) en la
direccin en la que est el jugador.
- DispararCurvo: disparar iniciando desde arriba o abajo una serie de disparos, bajando o
subiendo el ngulo (respectivamente) para abarcar 180. Una vez llegue al extremo opuesto
89
Eduardo Garca Rello
repetir el proceso disparando en la otra direccin. Esto cuenta como una ronda, se pueden
especificar el nmero de rondas seguidas desde fichero.
- DispararTanda: dispara 4 proyectiles en unos angulos predeterminados (creando una forma

de ( ) tras lo cual volver a disparar 3 proyectiles abarcando los huecos entre cada disparo de
la tanda anterior.
- Ametralladora: el enemigo subir hasta la parte superior de la parte visible de la pantalla y

comenzar a descender disparando una serie de proyectiles hasta llegar abajo del todo, tras lo
cual se desplazar (ya sin disparar) hasta la posicin desde la cual comenz a realizar la IA.
Tiene dos variantes:
- Disparo horizontal: dispara horizontalmente con respecto a su posicin en Y.
- Disparo al jugador: cada disparo es lanzado apuntando al jugador.
- Electrocutar: el enemigo entrar en modo electrocucin durante un periodo de tiempo,

mediante el cual ser invulnerable, permitiendo adems daar al personaje si ste le ataca
durante la realizacin de sta IA.
- Aplastar: el enemigo se dejar caer en una determinada posicin (horizontal o vertical)

intentando aplastar al jugador ocasionndole gran dao, tras lo cual esperar un determinado
periodo de tiempo y volver a su posicin original. Existen 3 variantes:
- Perseguir: el enemigo perseguir al jugador ubicndose encima de l, y tras pasar un
breve periodo de tiempo se dejar caer para aplastarlo.
- Fijo y en rango: solo aplastar si el jugador est cerca del enemigo.
- Constante: aplastar constantemente, est o no cerca del personaje.
- Kamikaze: el enemigo, tras detectar al personaje dentro de un rango de proximidad, se

abalanzar hacia l incrementando su velocidad hasta chocarse o con l o con un tile
colisionable, generando una explosin daina tras ello. Est pensado especialmente para el
gnero Carrera.
- Misiles: el enemigo fijar la posicin del personaje y le lanzar un misil que caer pasado una
determinada cantidad de tiempo en la posicin fijada.
90
Eduardo Garca Rello
- AparecerDisparar: estando fuera de la cmara el enemigo se adentrar en ella por un lateral y

tras frenar comenzar a disparar. Una vez haya disparado tantos proyectiles como se le
indique, se volver a ir por donde vino para as desaparecer. Existen 2 variantes:
- Horizontal: disparar horizontalmente.
- Fijando jugador: disparar al jugador exclusivamente.
- PerseguirEmbestir: pensado para enemigos de aire, el enemigo perseguir al personaje por

encima si ste est dentro del rango de deteccin, y si tras acercarse supera el rango de
ataque se lanzar a por el jugador para chocar contra l y ocasionarle daos. Tras chocar
contra el suelo comenzar a ascender verticalmente hasta la altura que tena originalmente
cuando lo persegua.
- BatallaRPG: los enemigos con sta IA elegirn de forma aleatoria (teniendo en cuenta una
serie de pesos) uno de los posibles ataques que se hayan especificado en la IA y lo ejecutarn
contra el personaje cuando les corresponda. Los enemigos tambin pueden elegir esperar y
pasar el turno sin atacar.
- RayoLaser: el enemigo cargar un potente y gigantesco rayo lser, lanzndolo despus

durante un periodo de tiempo y ocasionando serios daos al personaje si entra en contacto
con l.
- VolarRecto: el enemigo volar en una direccin constantemente. Se puede especificar si se

desea que el enemigo vaya disparando al jugador mientras se desplaza.
- VolarOnda: el enemigo volar en una direccin horizontal constantemente, elevndose hasta

una determinada altura para luego bajar hasta otra, repitiendo este proceso para dar origen al
nombre de la IA. Tambin se puede especificar si se desea que el enemigo dispare mientras.
- Jefe: es una IA encargada de elegir otras IAs. Diseada para enemigos de tipo Jefe, como su
propio nombre indica, se encargar de elegir aleatoriamente una serie de IAs asignadas a ese
jefe, cada una con un peso determinado (de forma que tenga ms o menos probabilidades de
aparecer), de modo que acabe desarrollando un combate de jefe correctamente. Para cada
jefe e IA que contenga se le puede especificar que se desplace en la pantalla a una
determinada posicin para realizarla, por lo que, por ejemplo, si ha realizado una IA de
Embestir y quiere realizar una de Aplastar, se deber indicar que se desplace a una posicin en
91
Eduardo Garca Rello
la cual est por encima del personaje. Para ello se hace uso de un mtodo que contiene la IA
denominado Desplazar, indicando solamente la posicin permitir que el jefe se desplace sin
problemas.
3.7.1.3 Obstculos
Los obstculos son entes de tipo Ser Atacable que no realizan ninguna accin por s mismos,
simplemente sirven, como su propio nombre indica, para obstaculizar el camino del personaje.
Estos obstculos pueden aparecer con diferentes tamaos y formas, pero todos realizan la
misma funcin.
Mientras que en el gnero de Accin/Plataformas son inofensivos, en el gnero de Shoot Em

Up, Carrera y Vertical son bastante peligrosos debido a la velocidad en la que se desplaza el
jugador, de modo que si choca con ellos recibir dao. Dependiendo de qu tipo de obstculo
sea el dao puede ser mayor o menor, o incluso matar al personaje al instante, por lo que es
importante no chocarse con ellos. Si el obstculo no mata de un golpe significa que tras chocar
contra ste se romper, pudiendo continuar sin ms problemas.
Cuando un obstculo recibe dao se muestra una barra con la vida actual del obstculo, de
modo que se pueda tener esa informacin presente. Adems tambin mostrar un indicador
con la cantidad numrica del dao causado. Cuando la vida del obstculo es menor o igual a 0
se romper, existiendo la posibilidad de que libere un objeto consumible de entre los
disponibles.
En el gnero Accin/Plataformas, el obstculo puede tener dos comportamientos:

- Bloque slido: actuar como un tile de tipo colisin, de modo que no se pueda
traspasar, chocando contra l en cualquier lado.
- Plataforma: en vez de colisionar por todos los lados solo lo har por el de arriba, de
modo que si la parte inferior del usuario no est por encima de la del obstculo, ste
podr ser atravesado. Si por el contrario el jugador cae encima de un obstculo de tipo
plataforma se posicionar encima.
92
Eduardo Garca Rello
3.7.2 Proyectiles
Los proyectiles son un tipo de Ente cuyo nica funcin es la de desplazarse en la direccin en la
cual se ha especificado a la hora de ser creados.
Los proyectiles pueden morir de varias formas, teniendo en cuenta qu comportamiento se

les ha especificado a la hora de su creacin. De este modo un proyectil puede tener o no
activada la variable de colisin con tiles, de modo que si la tiene activada nada ms chocar con
un tile de tipo colisin ser eliminado. Si tiene activado el contador de tiempo de vida,
solamente permanecer vivo como mximo hasta que el tiempo de vida supere el establecido,
eliminndose acto seguido.
Junto con los datos sobre cmo ha de ser eliminado, tambin se le especifica el dao que har,
la velocidad con la que se mover y las dimensiones de su bounding box.
3.7.3 Objetos
Durante el juego el jugador ir descubriendo objetos que le ayudarn de forma inmediata en
su aventura. Estos objetos pueden ser de tres tipos: de recuperacin, potenciadores o de
habilidad.
Objetos de Recuperacin
Los objetos de recuperacin son objetos que en el momento de entrar en colisin con el
personaje le permiten recuperar o bien energa o bien vida. De este modo el jugador
encontrar:
- Recuperacin de vida pequea: recupera la vida en una cantidad reducida.
- Recuperacin de vida mediana: recupera la vida en una cantidad moderada.
- Recuperacin de energa pequea: recupera la energa en una cantidad reducida.
- Recuperacin de energa mediana: recupera la energa en una cantidad mediana.
Potenciadores
Los potenciadores permiten aumentar los atributos del jugador durante un breve periodo de
tiempo. Tras acabar el periodo volver a tener los atributos como los tena antes de coger el
objeto. La probabilidad de que un enemigo u objeto suelte un potenciador es ms reducida
que la de que suelten un objeto consumible debido a los beneficios que representa.
93
Eduardo Garca Rello
Como los potenciadores mejoran atributos, se han creado 4, uno orientado a cada atributo,
pudindose generar aleatoriamente cualquiera de ellos cuando un enemigo u obstculo lo
genere.
Objetos de Habilidades
Los objetos de habilidades son aquellos que al recogerlos proporcionan una habilidad nueva al
jugador. Estos objetos solo aparecen de forma predeterminada en el juego, ya que tienen que
ver con el desarrollo de ste, de modo que aparecern solo en determinados eventos (como
llegar a un punto del juego o vencer a un determinado jefe). Una vez el personaje consiga el
objeto de una habilidad la tendr para siempre.
3.7.4 NPCs
Los NPC (Non Playable Character) son entes que no entran en contacto con el jugador
fsicamente, de modo que no existe colisin entre ellos. Su nica funcin es (aparte de servir
como refuerzo visual a la escena) la de proporcionar informacin al jugador a travs de
dilogos. Un ejemplo de NPC es el letrero que se puede encontrar por varias partes del juego.
Una vez el jugador est lo suficientemente cerca del NPC, podr pulsar la tecla
correspondiente e iniciar as el dilogo que el NPC tiene asignado.
Los NPCs no pueden ser atacados ya que sera algo contraproducente eliminar aquello que
pueda dar informacin vital como tutoriales de juego u otros aspectos.
3.8 Tiles
Como el proyecto consiste en la realizacin de un videojuego multignero, es vital la creacin
de pantallas de todo tipo, por lo que se ha elegido la creacin de mapas basados en tiles
debido a su versatilidad y facilidad de uso, ya que pueden adaptarse a cualquiera de los
gneros ideados para este proyecto.
Para la inclusin de tiles se ha optado por utilizar la herramienta Tiled. Tiled permite la
creacin de pantallas en relativamente poco tiempo, gracias a sus mltiples herramientas y
opciones as como a su interfaz intuitiva (al estilo de programas de diseo grfico).
94
Eduardo Garca Rello
3.8.1 Pantallas basadas en Tiles

Para otro tipo de juegos quizs no sea necesario el uso de tiles (como aventuras grficas) pero
tratndose de gneros como las plataformas, el RPG o el Shoot Em Up, es un aspecto vital
para darles forma.
La clave para la realizacin de tiles que encajen bien en el aspecto visual de la escena es
disearlos de forma que puedan ubicarse muchos tiles del mismo tipo en un escenario sin que
extrae visualmente al usuario por su repeticin o por la falta de coherencia entre ellos. Para
ello se suelen disear de forma que en sus lados (dependiendo del tipo de tile puede ser en
uno, dos, tres o los cuatro lados) exista una coherencia por lo que si se pusiesen seguidos no se
note la repeticin de stos al no notarse donde empieza y donde acaba.
Junto con los tiles, es necesario crear capas (como se ha mencionado antes) para separarlos
por categoras. Dependiendo del posicionamiento de las capas (por orden de aparicin) stas
se sobrepondrn a las anteriores, de modo que la capa nmero 0 sera la del fondo y la 1
podra ser la de colisiones, siendo la 2 una de detalles que estn en el frente.
Adems, a estas capas se les pueden otorgar propiedades que uno mismo puede definir tanto
en nombre como en valor, de modo que, por ejemplo, si indicamos que la capa del fondo
tenga una variable colisiona con valor false, se puede hacer que luego el parseador lea sta
variable y asigne a todos sus tiles que no puedan colisionar. Esto ha sido utilizado en el
proyecto en varias formas, como por ejemplo definiendo la velocidad de desplazamiento que
tendr cada capa (ya que se ha implementado Parallax Scrolling en todas ellas), o si es de tipo
colisionable, entre otras caractersticas.
A la propia pantalla tambin se le pueden proporcionar caractersticas propias definidas por el

usuario, del mismo modo que se haca con las capas (definiendo el nombre de la variable y su
valor). As se pueden definir propiedades globales a sta pantalla, como se ha hecho en el
proyecto al incluir la posicin inicial del personaje en sta o el nmero de capas de tiles que
contiene.
95
Eduardo Garca Rello
Tiled proporciona tambin vas para definir la animacin de tiles o la creacin de objetos
especiales, pero se ha decidido evitar su uso en favor de la creacin de stos contenidos de
forma personal.
3.8.2 Tilesets
Los tilesets son todos aquellos archivos de imagen que conforman cada mapa, de los cuales se
sacan todos los distintos tiles que lo rellenarn. Contienen de forma ordenada (en forma de
matriz de tiles) todos stos, de modo que en cada celda se dibuje los tiles como correspondan.
En tiled se seleccionarn stas celdas de los tilesets y se pintar la pantalla con el contenido
de cada una. Al tratarse de imgenes individuales, por lo general se suele englobar en una
misma imagen todos aquellos tiles que estn relacionados de algn modo, como por ejemplo
que pertenezcan a una misma pantalla formando la capa colisionable, o bien todos aquellos
tiles que forman la capa del fondo, u otro que contenga los tiles de los detalles.
Esto permite que se puedan combinar de mltiples formas, pudindose elegir un tileset para el
diseo de la capa de colisin para cada pantalla pero uno comn a 4 o 5 pantallas que defina el
fondo. Esta versatilidad y su fcil modificacin (ya que solo es volver a pintar cuando se quiera
modificar el aspecto visual de algn tile) agilizan en gran medida la creacin de pantallas.
3.8.3 Tipos de Tiles
Aparte de la representacin visual de cada tile, stos pueden variar en comportamiento a la
hora de ejecutar el juego. De este modo un tile puede representar simplemente una nube que
no pueda ser colisionada, o bien un trozo de tierra que entre en colisin con el jugado
sirvindole de suelo, o incluso un bloque de pinchos que dae al jugador si entra en contacto
con l, entre muchas otras posibilidades.
La definicin de cada tipo de tile puede realizarse mediante tiled (agregando mltiples
variables a cada tile) o bien mediante el propio usuario, desarrollando una serie de
comportamientos y aspectos para tiles especiales que vayan ms all de si colisionan o no, o
de si se han de dibujar o no.
Dentro de estos tiles especiales, se ha decidido implementar los siguientes para este proyecto:
- Plataformas: son tiles que actan como tiles slidos pero nicamente si el usuario
est ubicado encima y est colisionando con ellos. De este modo el usuario podr
96
Eduardo Garca Rello
atravesarlos sin problema por los laterales o por el inferior del tile en cuestin, pero si
por ejemplo salta y se posiciona encima el tile no le dejar avanzar ms hacia abajo.
- Trampas: son tiles que daan al jugador si colisiona con ellos, como pueden ser
pinchos, lava, zonas de calor, etc. Contienen diversas propiedades que las identifican
dentro de todas las que existen, pudiendo catalogarse en estticas, temporales o de
proximidad.
- Sensores: son tiles que detectan colisin pero no afectan a la ubicacin del usuario
como hara por ejemplo un tile del suelo, si no que una vez que detecte la colisin
activar ciertos eventos como dilogos, indicadores textuales, cambios de mapa o
inicio de batallas contra jefes, entre otros. Por lo general suelen ser invisibles de forma
que trabajen sin que el usuario se d cuenta de su ubicacin, pero tambin existen
algunas que son visibles simulando lseres.
- Detalles: son tiles cuya nica funcin es la de resaltar algn aspecto visual de la
escena o directamente proporcionarlo, pero no tienen repercusin de cara a la
jugabilidad. Estos detalles pueden ser gotas de lluvia chocando contra el suelo o
burbujas en el agua, entre otros. Se diferencian de los efectos provocados por el gestor
de efectos o de las partculas del gestor de partculas en que mientras que stos suelen
ser provocados por factores externos, los detalles simplemente son tiles animados que
estn ah de forma permanente.
3.9 Sprites
Los sprites suponen uno de los pilares principales que forman el proyecto, ya que
prcticamente todo lo que se mostrar por pantalla est formado por ellos. Desde el personaje
que maneje el jugador, hasta los enemigos y objetos, pasando por todo el terreno, el fondo e
incluso los indicadores del HUD estarn compuestos de sprites.
SFML proporciona una clase llamada Sprite que incluye aspectos bsicos para tratar con ellos,
como la posibilidad de rotarlos o escalarlos, poder establecer su centro u origen, asignarle una
textura, as como asignarle una posicin en pantalla, entre otros. Adems, es uno de los
elementos clave que la ventana de SFML puede dibujar por pantalla, facilitando mucho las
cosas. De este modo lo esencial a la hora de crear un sprite es establecerle una posicin y
asociarle una textura (y por lo general indicarle qu parte de sta ser la que componga el
sprite, ya que puede haber mltiples dibujos en cada textura), para luego simplemente
mostrarlo por pantalla.
97
Eduardo Garca Rello
Debido a la cantidad de elementos que contiene esta clase as como a su ms que frecuente
uso, se vio que la necesidad de crear dinmicamente elementos tales como enemigos, objetos
o indicadores de muchos tipos era muy alta, y teniendo en cuenta que cada uno de stos suele
usar mnimo un Sprite (teniendo en cuenta la situacin), se comprob que se necesitaran
crear dinmicamente muchos Sprites, aumentando el consumo de recursos y por tanto
aumentando tambin la posibilidad de ocasionar frames congelados en el transcurso del juego.
Ante este problema se decidi cambiar por completo el sistema de creacin de objetos de tipo
Sprite de forma que en vez de que se fuesen creando stos objetos dinmicamente cuando se
necesitasen, se creasen todos una nica vez al principio de la carga de cada pantalla (de modo
que solo se creasen aquellos que se fuesen a utilizar en sta), pudiendo as aliviar bastante el
caos en el cdigo y evitando ste aumento en el consumo de recursos por estar ms
optimizado. De esta forma cuando un elemento del juego necesite, durante la ejecucin de
ste, tener y usar un Sprite, simplemente tendra que pedir una referencia a stos que ya
existan, de modo que al final hubiese un nico sprite para cada tipo de elemento, de modo
que si se hubiesen creado 40 enemigos, todos compartiesen el mismo Sprite, aunque cada uno
lo maneje de una forma u otra.
Tras realizarse el patrn fachada con sta clase, se consigui adaptar sta que proporcionaba
SFML a una propia con el mismo nombre (Sprite), la cual se encargaba tanto de ser la
intermediaria entre el desarrollador y la propia librera SFML, como de la realizacin de nuevas
acciones que se le incluyeron, de forma que sta nueva clase est mucho ms preparada para
su labor a la hora de realizar videojuegos de lo que ya estaba su predecesora en SFML.
3.9.1 Animaciones en Sprites

La principal de estas mejoras aadidas a la clase Sprite es la posibilidad de manejar
animaciones, de modo que cada Sprite animado se encargar de controlar la suya. Toda
animacin utiliza las mismas variables, las cuales indican el frame inicial, el frame actual y el
frame final, as como un tiempo por frame que indica cunto ha de pasar para cambiar entre
frames, o la variable loop que indicar si la animacin se repite una vez se llegue al frame
final o no.
El procedimiento para animar un Sprite es el siguiente:
98
Eduardo Garca Rello
1. Se comprueba si el frame actual es menor que el inicial o mayor que el final (ya que puede
ser que se estuviese realizando otra animacin justo cuando se ha cambiado a la que se ha de
realizar ahora, de modo que el frame actual siguiese siendo el de la anterior), de modo que si
es cierto se establece como frame actual el inicial (empezando as sta animacin).
2. Si el reloj (el cual se inici con el juego) ha superado el tiempo necesario para cambiar de
frame (variable tiempoPorFrame), se sumar 1 al frame actual y se reiniciar el reloj.
3. Si el frame actual es mayor que el frame final (es decir, si se ha sumado 1 al frame actual y
se ha pasado del lmite) y la variable loop es true, se establecer como frame actual el frame
inicial, permitiendo as repetir la animacin de nuevo. Si la variable loop es false, se asignar
el frame final siempre que se cambie de frame, de modo que no se pase de ste.
4. Se asignan los datos del frame actual al sprite, como son la posicin del frame en la textura,
sus dimensiones o su centro, de modo que el Sprite tenga en cada frame un dibujo distinto.
Existen dos tipos de animaciones: una para tiles, otra para trampas y otra para el resto de
elementos del juego (enemigos, objetos, efectos, etc.). Las diferencias entre stos varan segn
qu se est animando, de modo que, aparte de los datos que se asignan a cada tipo de
elemento (paso 4), se pueden encontrar diferencias como en el uso o no de la variable loop,
ya que los tiles siempre tendrn repeticin en la animacin, o en el caso de las trampas de tipo
temporal que se animen nicamente cuando estn activas.
3.10 Gestor de Textos

En el videojuego existirn situaciones en las cuales aparezca texto ya sea en un dilogo, en un
mensaje indicativo en la pantalla, al daar algn elemento mostrando as su dao con nmeros
o bien para informar de algo en pantalla como puede ser la vida o la informacin en mens.
Todos estos textos tienen en comn que estn formados por sprites ubicados en un mismo
spritesheet, de modo que deber existir algo que sepa identificar stos sprites y los muestre
teniendo en cuenta los caracteres que se necesiten representar.
Para ello se ha decidido desarrollar un gestor de textos, que ser el encargado de transformar
las cadenas en un medio que pueda ser dibujado por pantalla con stos dibujos dentro del
spritesheet.
99
Eduardo Garca Rello
3.10.1 Dilogos
Los dilogos son el ejemplo ms claro de lo que se pretenda conseguir con el gestor de textos.
Permiten mostrar por pantalla un texto que va apareciendo progresivamente (con una
velocidad determinada al lado del texto en cuestin en el propio fichero de textos)
especificado desde fichero.
Cuando se detecta que la siguiente palabra no podr caber en la lnea actual se enviar esa
palabra a la lnea siguiente, y cuando se detecta que eso mismo ha pasado pero con el nmero
mximo de lneas en pantalla, se pausar el texto y se tendr que pulsar el botn de continuar
para que borre el texto en pantalla y contine mostrndolo en la primera lnea. De este modo
se generan correctamente dilogos independientemente del tamao del texto.
Adems, es posible especificar en cada dilogo si existe otro texto asociado a ste, de modo
que cuando acabe de mostrar el dilogo comience el que referencia, permitiendo as mantener
una conversacin. Es posible tambin especificar la imagen del autor del dilogo, de modo
que para cada texto lo acompae una imagen representando a quien lo dice, e incluso se
puede especificar si mostrar esa imagen a la derecha del texto o a la izquierda, dando la
sensacin de que estn comunicndose dos entidades separadas entre s, hacindolo mucho
ms intuitivo.
A un dilogo tambin se le puede asociar un evento, de modo que cuando termine se active
inmediatamente. De este modo es viable encontrase con un enemigo de tipo Jefe, entablar un
dilogo y tras acabar ste, iniciarse la batalla.
Fig. 3.27 Personaje enfrente de un NPC que emite dilogo
100
Eduardo Garca Rello
Fig. 3.28 Dilogo emitido por el NPC en concreto
3.10.2 Indicadores
Los indicadores son mensajes en pantalla que permiten, como su propio nombre muestra,
indicar algo. Se puede especificar el lado en el que aparecern, y una vez han entrado en
pantalla por ese lado, la recorrern hasta el centro, donde se quedarn parados (o se movern
a una velocidad pequea, segn se indique en el fichero de textos) hasta pasar un periodo de
tiempo, tras lo cual volvern a moverse, ya sea continuando la direccin que llevaban o bien
regresando (tambin segn se especifique).
Son tiles por tanto para indicar aspectos como la pantalla actual, o bien avisar de si se acerca
un enemigo de tipo Jefe, entre otras cosas.
A estos textos tambin se les puede asociar un evento que ocurra cuando desaparecen.
3.10.3 Creacin de textos

Los ficheros pueden generarse de mltiples formas, teniendo siempre en cuenta qu se quiere
representar con esos textos. De este modo es posible que se quiera mostrar un dilogo o
indicador por pantalla, para lo cual se necesitar cargar desde fichero (pudiendo as ser
modificado de forma muy sencilla e intuititiva), o bien se puede querer mostrar un nmero por
pantalla as como por ejemplo informacin sobre alguna variable que tenga el jugador, como
su vida.
Para ello se ha desarrollado una serie de mtodos y parseadores que permiten satisfacer estas
necesidades.
101
Eduardo Garca Rello
3.10.3.1 Textos generados desde Fichero

Los textos cuyo origen sea un fichero de texto, en el cual se muestre toda la informacin de
cada uno de stos textos, sern procesados para que puedan ser mostrados por pantalla
gracias al mtodo CrearTextosDesdeFichero de la clase GestorTextos.
Tras haberse recogido los textos desde el fichero gracias al parseador de textos, este mtodo
almacenar en un vector de letras todos aquellos datos referentes a cada letra dentro del
spritesheet, de forma que cada posicin del vector contenga una serie de informacin como
puede ser la posicin del dibujo de la letra en el spritesheet, sus dimensiones, su identificador
o su centro.
De esta forma iremos recorriendo carcter a carcter del texto en cuestin, y si el carcter es
alfanumrico o bien es un punto, coma, admiracin o interrogacin, simplemente se meter
en el vector de letras la informacin referente al carcter correspondiente en el spritesheet.
A continuacin se muestra un ejemplo de 2 variables de las que encontramos entre las que
definen un texto:
nomTexto:"Prueba"
texto:"Vuelve aqu, no he terminado contigo!"
Como se puede ver, gracias a la lnea donde pone nomTexto se atribuir un identificador a
ese texto, recogiendo lo que ponga en la lnea de abajo tras el indicador de texto:. Esto
permite almacenar desde un inicio todos los textos de cada pantalla y acceder a ellos de forma
mucho ms rpida, intuitiva y menos costosa al conocer su identificador.
De esta forma se tiene control sobre los textos pudindose modificar en cualquier momento
sin que afecte en lo ms mnimo al cdigo ya que ste lo realizar correctamente.
As, si queremos mostrar indicadores de pantalla como, por ejemplo, el nombre de la pantalla
nada ms entrar en ella solo tendremos que establecer un 0 en la velocidad, mostrndose el
texto completo de forma instantnea.
102
Eduardo Garca Rello
3.10.3.2 Textos generados desde Nmero

Sin embargo existen otras ocasiones en las cuales el texto no proceda desde ficheros, sino que
se genere de forma dinmica durante la ejecucin, siendo imposible predefinirlo antes. Un
ejemplo de estos textos es el que se muestra cuando se daa alguna entidad, de forma que se
muestre unos caracteres numricos indicando la cantidad de dao infligido (como ya se ha
explicado en el apartado Gestor de Efectos).
Estos textos varan segn muchas situaciones por lo que sern necesario crearlos
dinmicamente en el momento en que se necesite. Para ello se ha desarrollado el mtodo
CrearTextosDesdeNumero, mediante el cual, pasndosele la cadena con los nmeros del dao
generado, se comprobarn qu nmeros son y se recoger la informacin correspondiente a la
posicin, dimensiones, centro e identificacin del dibujo de dichos nmeros dentro del
spritesheet en el que aparecen. Una vez se tiene esa informacin se guarda en una posicin
del vector de letras para que el juego se encargue de dibujarlos adecuadamente gracias a stos
datos.
3.10.3.3 Textos generados desde Cadena de caracteres

Existirn situaciones en las que se requiera mostrar alguna informacin puntual o bien un
indicador en algn men, es decir, aspectos que varan con el flujo del juego y que no se
pueden prever en ningn momento, por lo que no es viable ponerlos en fichero, pero tampoco
son nmeros, por lo que tampoco podremos usar el sistema anterior.
Para ello se ha elaborado un mtodo llamado CrearTextosDesdeString, que permite convertir
cualquier cadena de carcter a formato sprite y mostrarlo as por pantalla. Esto es
especialmente til en el mbito de mens, como por ejemplo el de pausa en el cual se
muestran los atributos y estadsticas del jugador, ya que si solo se pusiesen nmeros no se
podra saber a qu corresponde cada uno.
3.11 Gestor de Mens

En el juego existen una serie de mens en los cuales el jugador puede navegar, ya sea para
iniciar partida como para subir los atributos al jugador , as como para elegir habilidades, entre
otras cosas.
Para cubrir la necesidad de mens en el juego se ha ideado este gestor, que permite la
creacin de cualquier tipo de men independientemente del nmero de botones de una
103
Eduardo Garca Rello
manera relativamente sencilla. Una vez definido el Sprite que compondr todos los botones el
men, se crea en el gestor posicionando los botones en el lugar que se quiera en pantalla.
Cuando estn posicionados solo queda definir qu har cada botn, de modo que cuando se
pulse realice la accin sin problemas.
De este modo existe un mtodo encargado de controlar en qu botn se encuentra el jugador

y hacia donde puede ir, impidiendo que se site sobre aquellos botones que estn en estado
bloqueado (los botones pueden tener mltiples estados, los ms usados son SinFoco,
ConFoco y Bloqueado). Este mtodo tambin controla cuando el jugador pulsa el botn de
aceptar en un determinado botn, marcndolo como que ha sido pulsado.
De este modo cuando un botn ha sido pulsado se comprueba cual ha sido y se acta en
consecuencia, de modo que si estamos en el men principal y se ha pulsado sobre Iniciar
Partida se llamar al cdigo que iniciar una nueva partida y se desactivar el men principal.
Men Principal
Es el men que aparece nada ms cargar el juego. En l podremos iniciar una nueva partida,
cargar una ya existente o salir del juego.
Men de Pausa
Aparte de pausar el juego (como su propio nombre indica), tambin permite volver al men
principal y abandonar la partida, continuar la partida quitando la pausa o bien poder distribuir
los puntos que tenga pendientes tras subir de nivel, en uno de los posibles atributos de los que
dispone el jugador (fuerza, defensa, vitalidad y energa). Cuando no le queda ningn punto los
botones de asignacin de puntos de cada atributo se bloquean de forma que no pueda
distribuir ninguno.
Men de Batalla RPG

Este men es algo particular ya que se compone a su vez de varios submens. Primero el
jugador podr seleccionar una de las 4 posibilidades iniciales, ya sea Atacar, Habilidades,
Defensa o Huir.
Si elige atacar, aparecer un submen con la lista de enemigos en combate, de modo que
podr elegir a cual atacar. Una vez atacado, el submen de enemigos desaparecer y hasta
104
Eduardo Garca Rello
que no termine el turno de ambos contrincantes no podr volverse a manejar el men base de
batalla.
Si elige usar una habilidad, aparecer un submen de habilidades con aquellas que posea. Tras
elegir una aparecer el submen de enemigos para elegir el objetivo de sta. Cuando la realice
sobre algn enemigo desaparecern tanto los submens de habilidades como de enemigos,
volviendo al men base cuando le toque elegir al jugador.
Si elige defenderse, el jugador podr recuperar un determinado porcentaje de energa, as

como bloquear los siguientes ataques de los enemigos hasta el siguiente turno, reduciendo su
dao considerablemente.
Si elige huir el combate acabar, volvindose a ubicar en la pantalla RPG.
Si el jugador consigue ganar el combate, un ltimo submen aparecer indicando la

experiencia obtenida.
Aparte de estos mens, el men de batalla RPG cuenta con un apartado donde se indica la vida
actual y mxima, as como la energa actual y mxima del jugador. Aparte de ello tambin se
indica la accin que se est realizando hasta tomar una nueva, de modo que se recuerde qu
se ha hecho el ltimo turno.
3.12 Gestor de Audio

Para manejar todos los efectos de sonido y la banda sonora del juego se ha implementado un
gestor de audio. El gestor se encargar de cargar todos los sonidos y melodas de la pantalla
actual, as como de cambiar el estado de cada elemento sonoro, pudiendo as reproducir,
pausar o detenerlo en cualquier momento con solo una llamada a un mtodo indicando el
nombre del elemento sonoro al que se hace referencia y la accin a realizar.
El gestor es capaz de ubicar sonidos en el espacio, de modo que si ubicamos el listener (u

oyente) en la posicin que tenga el personaje en cada momento podremos apreciar como si se
ha reproducido un sonido medianamente lejos ste se oye con menor intensidad que si
estuviese ms cerca de l. Esto proporciona una mayor inmersin en el juego y da una mayor
sensacin de realismo.
105
Eduardo Garca Rello
Junto con esta ubicacin espacial dentro del juego, los sonidos tambin permiten ser
escuchados con mayor intensidad en un altavoz u en otro (o en los dos) segn sea el caso, de
modo que si un proyectil ha impactado a unos metros del personaje por su parte izquierda
se oir algo ms en el altavoz izquierdo que en el derecho.
3.13 Controles
Al contar con mltiples gneros dentro de un mismo videojuego existirn diversas situaciones
en las que se deba manejar de una u otra forma. Sin embargo se ha mantenido el mismo
esquema para todos los gneros ya que no era necesario un cambio significativo en la forma
de manejarse.
De este modo tenemos por una parte las teclas de direccin, encargadas de dotar movimiento
al personaje, el cual variar segn el gnero (ya que en algunos puede desplazarse horizontal y
verticalmente y en otros solamente en horizontal).
Por otra parte tenemos la tecla X, encargada de hacer que el personaje salte si el gnero lo
permite. Esta tecla tambin ser la encargada de aceptar el botn del men en el cual el
jugador se est ubicando en cada momento.
Al pulsar la tecla C realizaremos el ataque seleccionado en cada momento, ya sea proyectiles si

se tiene seleccionada la pistola o cuchillada si se tiene sta seleccionada. Si mantenemos la
tecla pulsada (y tenemos las habilidades correspondientes) podremos cargar el ataque, sea
disparo o cuchillada.
Para evitar activar el men de dilogos si se est realizando un salto, as como para permitir
precisamente saltar y atacar en frente de algn NPC que lo proporcione, se ha utilizado la tecla
S para iniciar dilogos y continuarlos.
Para poder acceder al men de pausa se puede utilizar la tecla Intro.
Se ha otorgado a la tecla A la posibilidad de cambiar de habilidad dentro de las disponibles en

cada momento, indicndose en la interfaz cual se tiene seleccionada.
106
Eduardo Garca Rello
Para utilizar estas habilidades se ha de pulsar la tecla Z.
3.14 Eventos
A lo largo del juego sucedern una serie de eventos de varios tipos, que dan mayor jugabilidad
y ayudan a la inmersin y realismo del propio juego.
Estos eventos pueden ser opcionales u obligatorios, dependiendo de la importancia de cada

uno.
El jugador puede activar un evento de varias formas, ya sea voluntariamente pulsando la tecla
de inicio de dilogo frente a un NPC (por ejemplo), o bien chocando contra un tile sensor
(invisibles, ubicados en el momento de crear el mapa). En este ltimo caso suelen ser
obligatorios, y lo ms normal es que sean nicos, es decir, que no puedan repetirse de nuevo.
Entre los eventos encontramos los siguientes.

- Inicio de dilogo: ya sea pulsando la tecla correspondiente frente a un NPC o
chocando contra un tile de dilogo, se indicar al gestor de textos que inicie la
conversacin correspondiente a dicho evento.
- Cambio de pantalla: cuando se d este evento la pantalla se ir oscureciendo

progresivamente (con fade out) para pasar a cargar otro mapa y mostrarlo de forma
progresiva del mismo modo pero con un fade in. Una vez activado este evento el juego
dejar de llamar al Update de todas las entidades (para evitar problemas), pero s se
mantendrn las animaciones.
- Inicio de batalla con un jefe: cuando se active este evento la cmara se fijar en la
posicin en que estaba (a no ser que se haya activado con el jugador estando en el
aire, ante lo cual se fijar la cmara en el eje X y cuando ste caiga a tierra, en el Y),
activando a su vez el comportamiento correspondiente al jefe en cuestin. A su vez, el
jugador no podr alejarse ms all de los bordes de la pantalla, que actuarn como
paredes con colisin, evitando as que salga del campo de visin de la cmara y por
tanto que se aleje de la batalla.
107
Eduardo Garca Rello
- Inicio de texto indicativo: al activar el evento un texto indicativo pasar por la parte
superior de la pantalla. Esto se suele utilizar cuando, por ejemplo, en el gnero Shoot
Em Up el jugador se acerca al encuentro con un jefe.
- Indicadores de obstculos: en el gnero de Carrera existen una serie de obstculos en

el camino que daarn o acabarn con la vida directamente del protagonista, por lo
que, sumado a la gran velocidad con la que transcurre esta pantalla, se ha decidido
poner una serie de indicadores que avisen de que un objeto se acerca en una
determinada posicin de la carretera, mediante un aviso intermitente con una
exclamacin en el lado derecho de la pantalla.
4. Conclusiones
Tras haberse completado el proyecto se ha echado la vista atrs y se han comparado tanto los
objetivos propuestos como los detalles personales que se esperaban realizar con el resultado
obtenido tras tanto tiempo de desarrollo, pudindose decir sin lugar a dudas que se ha
completado satisfactoriamente todo lo establecido, y ms an de aquello propuesto
inicialmente, quedndome no solo satisfecho con el resultado final sino tambin algo ms
importante: orgulloso por cmo ha quedado.
Ya que inicialmente el proyecto consista en la elaboracin de un videojuego multignero que

pudiese abarcar al menos tres gneros propuestos originalmente (Accin/Plataformas, Shoot
Em Up y RPG), y tras ver que no solo se han incluido esos tres sino que tambin se han
elaborado dos formas de jugar el de Accin/Plataforma, adems de poder crear el gnero de
Carreras as como el gnero hbrido Vertical, sumado a todos los elementos incluidos en el
motor del videojuego que originalmente no estaban planeados (sistema de partculas, sonido
ubicado en 2D, tal nmero de enemigos implementados y de comportamientos, habilidades
del protagonista, etc.), se puede concretar sin temor a equivocarse que el resultado ha sido
todo un xito, tanto en el mbito del proyecto final de grado como en el mbito personal por
lo que supone el tener tanto un juego original como un propio motor de videojuegos
completamente funcional de cara ya no a este, sino tambin a posteriores proyectos.
Durante el proyecto se han tenido que realizar numerosos cambios y modificaciones ante
situaciones que originalmente no estaban planificadas, llegando en algunos casos a retrasar la
108
Eduardo Garca Rello
elaboracin del proyecto (vase la utilizacin de Box2D), pero sin embargo tras seguir la
planificacin original se ha podido realizar paso a paso todo lo establecido.
Todos estos aspectos han quedado reflejados en la herramienta Cloud, la cual se ha utilizado
todos y cada uno de los das desde que se integr en el proyecto, pues ha servido de gran
ayuda para la planificacin de ste, as como para realizar un seguimiento y suponer un escudo
ante problemas que hayan podido surgir durante la elaboracin del proyecto gracias al
repositorio que incluye.
Gracias al planteamiento seguido y al desarrollo genrico se ha podido elaborar un motor que

permite realizar cambios sin apenas tocar el cdigo (de hecho en la gran mayora de casos sin
siquiera tocarlo), ya sea creacin de mapas, eventos, dilogos, enemigos, modificacin de la IA
de los enemigos, o la creacin de eventos activados por sensores, facilitando as la creacin de
contenido para cualquier videojuego de una forma rpida y sencilla. A pesar de que esto
estaba planificado desde el principio, no se ha podido ver el verdadero potencial hasta que se
ha puesto en marcha todo este sistema, demostrando con creces que ha merecido la pena
orientarlo de este modo.
Por tanto, de todo lo diseado y desarrollado si se tuviese que elegir lo que destaque por
encima de lo dems, se podra decir que sta posibilidad de no tocar cdigo y sin embargo
poder crear contenido nuevo desde fichero sera la que sobresaldra del proyecto.
Casi 800 horas de trabajo, aproximadamente 17.000 lneas de cdigo, ms de 250 sprites y 30
sonidos originales, 22 tipos de inteligencia artificial distinta (modulables), entre otras muchas
cosas, han permitido que el proyecto vaya a buen puerto una vez terminado.
5. Lneas futuras
Gracias al hecho de haber realizado este proyecto mediante un diseo genrico se ha
conseguido realizar una librera propia con la cual se puedan desarrollar nuevos videojuegos
siguiendo los mismos pasos seguidos para la realizacin de ste. Gracias al sistema de archivos
y sus correspondientes parseadores se pueden cambiar por completo los elementos que
definen un videojuego, tales como pantallas, enemigos, eventos u objetos de una forma
mucho ms sencilla e intuitiva.
109
Eduardo Garca Rello
Adems se puede comprobar tras la realizacin del proyecto que se pueden desarrollar
videojuegos de cualquier gnero con stas herramientas, puesto que se han aadido gneros
completamente distintos entre s y no solo han funcionado correctamente si no que han
coexistido en un mismo juego sin problemas. De este modo con crear nuevos tipos de
enemigos y objetos en los archivos de texto, crear nuevas pantallas con la herramienta Tiled y
dibujar nuevos spritesheets y tilesheets se podra tener un juego completamente distinto sin
necesidad de tocar apenas cdigo (segn se necesite).
As, el proyecto puede ser utilizado en el futuro para aadir nuevas herramientas a la librera o
incluso para desarrollar nuevos videojuegos multignero (o con gnero nico) gracias a ella.
6. Agradecimientos
Me gustara agradecer a las siguientes personas su ayuda y apoyo durante la realizacin de
ste proyecto, ya que me han podido ayudar a que este proyecto llegue a buen puerto,
fomentando adems que haya sido una grata experiencia realizarlo.
Por impartirme los conocimientos que me han permitido realizar este proyecto:
- Carlos Jos Villagr Arnedo.
- Francisco Jos Gallego Durn.
- Fidel Aznar Gregori.
- Miguel ngel Lozano Ortega.
Por sus consejos y ayuda para poder encauzar este proyecto:

- Carlos Jos Villagr Arnedo.
- Francisco Jos Gallego Durn (y por sus hachazos que indicaban el buen camino).
A mis compaeros y amigos que me han apoyado moral y tcnicamente:

- Javier Snchez Riquelme.
- Roberto Gmez Dav.
- Ral Ibarra Dez.
- Carlos Meca Lpez.
- Pedro Lpez Jimnez.
110
Eduardo Garca Rello
Por su apoyo incondicional a mi familia y amigos, as como por seguir querindome y

soportndome tras pasar das y das trabajando en mi habitacin casi sin verlos.
Por su inmenso apoyo moral, as como por siempre estar ah para ayudarme, a mi pareja
Noem.
Y por ltimo pero no menos importante, dedicarle el juego a mi gran amigo y hermano Leo,
por haber sido una inmensa fuente de motivacin y superacin personal a lo largo de todos
estos aos.
7. Bibliografa
[1] Laurent Gomila, tutoriales y API de SFML (http://sfml-dev.org/resources.php)
[2] StackOverflow, portal de preguntas y respuestas orientadas al mbito informtico
(http://stackoverflow.com/)
[3] OpenGameArt, portal
de recursos artsticos para videojuegos de uso gratuito
(http://opengameart.org/)
[4] Raywenderlich, portal de tutoriales sobre videojuegos (http://www.raywenderlich.com)
[5] Increpare, generador de sonidos Bfxr (http://www.bfxr.net/)
111

Tesis-Videojuego Multigenero GARCIA REILLO EDUARDO

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tesis-Videojuego Multigenero GARCIA REILLO EDUARDO

Transféré par

Droits d'auteur :

Formats disponibles

Grado en Ingeniera Multimedia

Trabajo Fin de Grado

Eduardo Garca Rello

Eduardo Garca Rello

3.3.2 Emisores de tipo Fuente............................................................................................. 50

Eduardo Garca Rello

3.8.3 Tipos de Tiles .............................................................................................................. 96

Eduardo Garca Rello

Eduardo Garca Rello

Figura 3.20 Disparo con la pistola ......................................................................................... 82

Eduardo Garca Rello

Eduardo Garca Rello

Y si ha llegado a tantsimas personas la aficin por jugar videojuegos es principalmente por su

Eduardo Garca Rello

1.2 Videojuegos Multignero en la actualidad

Eduardo Garca Rello

Fig. 1.1: Metal Slug usando Accin / Plataformas

Fig. 1.2: Metal Slug usando Shoot Em Up

Eduardo Garca Rello

Fig. 1.3: Metal Slug usando Shoot Em Up con scroll vertical

Fig. 1.4: Chrono Trigger usando RPG por turnos

Eduardo Garca Rello

Fig. 1.5: Chrono Trigger usando el gnero de carreras

Eduardo Garca Rello

1.4 Objetivos del proyecto

Crear una librera propia

Eduardo Garca Rello

un Gestor de Efectos, un Sistema de Partculas, varios Parseadores para cada necesidad

Implementar mltiples gneros

Fusionar los gneros de forma justificada

Crear mltiples gneros independientes entre s e incluirlos toscamente en un solo juego es

Eduardo Garca Rello

Bien entrada la maana de un da cualquiera, mientras Vidheim an dorma, ocurri lo que

Cerca de donde l estaba se podan or las carcajadas de un desconocido que contemplaba la

Eduardo Garca Rello

2.2 Objetivo del juego

Eduardo Garca Rello

2.3 Mecnica del juego

Eduardo Garca Rello

El personaje ir adquiriendo experiencia conforme elimine enemigos, permitiendo as que

Eduardo Garca Rello

2.4 Metodologa empleada

Fig. 2.1: Diagrama de etapas en FDD

Eduardo Garca Rello

2.5 Gneros incluidos

2.5.1 Accin / Plataformas

Eduardo Garca Rello

Como ya he comentado, se suelen integrar otros gneros o subgneros en el de plataformas

Esta combinacin de gneros (accin + plataformas) se ha establecido como situacin base

Accin Cuerpo a Cuerpo

Eduardo Garca Rello

El jugador podr disparar lateralmente sin necesidad de pulsar la tecla de direccin

Eduardo Garca Rello

El escenario se desplazar de forma horizontal a una velocidad constante, de modo que

A lo largo de la pantalla el jugador ir consiguiendo habilidades y poderes que le ayudarn a

En el caso de ste proyecto se ha decidido incluir ste gnero debido a su importancia y

Eduardo Garca Rello

En ste proyecto se ha decantado por incluir el ltimo grupo de los mencionados

La carrera se desarrollar en horizontal, con una vista parecida a la que ya se mostraba en el

Eduardo Garca Rello

La pantalla ir desplazndose a gran velocidad verticalmente, de modo que el usuario ha de

Eduardo Garca Rello

2.6 Herramientas utilizadas

Eduardo Garca Rello