desarrollo de un videojuego estilo
TRANSCRIPT
-
Agradecimientos
Dedicatoria
Citas 1.
Desarrollo de un
videojuego estilo
Arena Shooter
Grado en Ingeniería Multimedia
Trabajo Fin de Grado
Autor:
Iván Pomares Rastrollo
Tutor/es:
Carlos J. Villagrá Arnedo
Enero 2022
1
Índice de contenidos ÍNDICE DE CONTENIDOS ................................................................................................................ 1
ÍNDICE DE IMÁGENES ..................................................................................................................... 3
ÍNDICE DE TABLAS .......................................................................................................................... 6
1. JUSTIFICACIÓN ............................................................................................................................ 8
2. MARCO TEÓRICO ......................................................................................................................... 9
2.1 INTRODUCCIÓN ........................................................................................................................... 9 2.2 ANTECEDENTES........................................................................................................................ 11
2.2.1 Quake 3 Arena ................................................................................................................ 11 2.2.2 Unreal Tournament ......................................................................................................... 15
2.3 ANÁLISIS Y EVOLUCIÓN ............................................................................................................. 19 2.3.1 Comparación de características: Similitudes ................................................................. 19 2.3.2 Comparación de características: Diferencias ................................................................. 26 2.3.3 Análisis evolutivo (evolución) ......................................................................................... 30 2.3.4 Conclusión ...................................................................................................................... 39
2.4 PSICOLOGÍA DE LA FRUSTRACIÓN .............................................................................................. 40
3. OBJETIVOS ................................................................................................................................. 44
3.1 SUBOBJETIVOS ......................................................................................................................... 44
4. METODOLOGÍA ........................................................................................................................... 46
4.1 METODOLOGÍA DE GESTIÓN ....................................................................................................... 47 4.1.1 Herramientas de gestión ................................................................................................ 48 4.1.2 Hitos ................................................................................................................................ 49
4.2 METODOLOGÍA DE DESARROLLO ................................................................................................ 50 4.2.1 Herramientas de desarrollo ............................................................................................ 51
4.3 MOTOR DEL JUEGO ................................................................................................................... 52 4.3.1 Motor propio con Irrlicht .................................................................................................. 53 4.3.2 Unity ................................................................................................................................ 53 4.3.3 CryEngine ....................................................................................................................... 53 4.3.4 Unreal Engine 4 .............................................................................................................. 54
5. ANÁLISIS ..................................................................................................................................... 55
5.1 FUNDAMENTOS BASE ................................................................................................................ 55 5.2 GESTIÓN DE RIESGOS ............................................................................................................... 57
5.2.1 Identificación ................................................................................................................... 58 5.2.2 Análisis ........................................................................................................................... 60 5.2.3 Planificación .................................................................................................................... 64 5.2.4 Monitorización y control de riesgos ................................................................................ 71 5.2.5 Revisión .......................................................................................................................... 71
5.3 ANÁLISIS DAFO ....................................................................................................................... 72 5.4 ANÁLISIS DE REQUISITOS .......................................................................................................... 76
5.4.1 Requisitos funcionales .................................................................................................... 76 5.4.2 Requisitos No Funcionales ............................................................................................. 77
6. DOCUMENTO DE DISEÑO DEL VIDEOJUEGO (GDD) ............................................................. 78
6.1 BETTERNAMEPENDING ............................................................................................................. 78 6.1.1 Historia del juego ............................................................................................................ 78
6.2 TEMÁTICA Y ESTÉTICA ............................................................................................................... 79
2
6.3 JUGABILIDAD ............................................................................................................................ 80 6.4 MECÁNICAS .............................................................................................................................. 83
6.4.1 Movilidad ......................................................................................................................... 83 6.4.2 Armas ............................................................................................................................. 84 6.4.3 Salud y armadura ........................................................................................................... 85 6.4.4 Recogibles ...................................................................................................................... 85 6.4.5 Modos de juego .............................................................................................................. 88
6.5 ESTADOS DEL JUEGO ................................................................................................................ 92 6.5.1 Menú principal/Pantalla de título .................................................................................... 92 6.5.2 Menú de pausa ............................................................................................................... 93 6.5.3 Buscador de partida........................................................................................................ 93 6.5.4 Partida: juego .................................................................................................................. 94 6.5.5 Opciones ......................................................................................................................... 95 6.5.6 Inventario ........................................................................................................................ 96 6.5.7 Tienda ............................................................................................................................. 96
7. DESARROLLO ............................................................................................................................. 97
7.1 ENTORNO DE TRABAJO.............................................................................................................. 98 7.2 INTRODUCCIÓN A UE4 ............................................................................................................ 100 7.3 PERSONAJE CONTROLABLE ..................................................................................................... 101 7.4 RECOGIBLES .......................................................................................................................... 105 7.5 ARMAS ................................................................................................................................... 108
7.5.1 Proyectiles .................................................................................................................... 109 7.6 HUD ...................................................................................................................................... 112 7.7 MENÚ Y OPCIONES.................................................................................................................. 114
8. CONCLUSIONES ....................................................................................................................... 117
8.1 OBJETIVOS PRINCIPALES ......................................................................................................... 118 8.2 SUBOBJETIVOS ....................................................................................................................... 119
9. BIBLIOGRAFÍA Y REFERENCIAS ............................................................................................ 121
10. GLOSARIO DE TÉRMINOS..................................................................................................... 123
3
Índice de imágenes
Imagen 1. Maze War en un Imlac PDS-1D en el Museo Histórico de Ordenadores (Bruce,
2011). ..................................................................................................................................... 9
Imagen 2. Captura promocional de la demo de Q3A (id Software, 1999). ......................... 11
Imagen 3. Captura de la sala central de PRO_Q3DM13 (Quake III Arena, 1999). ............ 12
Imagen 4. Plano del mapa PRO_Q3DM13, usado en partidas competitivas (Maximir93,
2021). ................................................................................................................................... 12
Imagen 5. Captura de una partida de UT99 en Deck-16 (Unreal Tournament, 1999). ....... 15
Imagen 6. Captura de la parte superior de Deck-16, nótese que al fondo hay recogibles pero
que al igual que los que se encentran más cerca de la cámara, son difíciles de identificar
(Unreal Tournament, 1999). ................................................................................................ 16
Imagen 7. Pollice Verso, 1872, popularizó el gesto de "pulgar hacia abajo". Museo de Arte
de Phoenix (Gérôme, 1872) ................................................................................................. 19
Imagen 8. De izquierda a derecha: botas anti-gavedad, invisibilidad y damage amplifier
(FANDOM, 2009) ............................................................................................................... 23
Imagen 9. Posibles rutas para recoger la armadura roja (triángulo rojo) o la mega salud
(círculo azul) y sus correspondientes opciones para continuar (Quake III Arena, 1999). .. 24
Imagen 10. Captura de UT99 demostrando la discreción de los objetos recogibles (Unreal
Tournament, 1999). ............................................................................................................. 28
Imagen 11. Visor usando su habilidad para ver enemigos a través de las paredes (Quake
Champions, 2017). ............................................................................................................... 31
Imagen 12. Aquí se puede observar cómo los recogibles saltan a la vista y como el Quad
tiene un contador hasta que aparezca (Quake Champions, 2017). ...................................... 32
Imagen 13. Población de jugadores de QC desde su lanzamiento en Steam, captura tomada
el (7-9-2021) (Gray, 2012). ................................................................................................. 33
Imagen 14. Población de jugadores de Q3A y QL desde su aparición en la tienda de Steam,
capturas tomada el (7-9-2021) (Gray, 2012). ...................................................................... 34
Imagen 15. Captura de una partida de QC, nótese cómo el enemigo está resaltado y cómo
encima suyo (más bien dónde se encontraba hace un instante) se indica el daño que se le ha
causado (Quake Champions, 2017). .................................................................................... 34
Imagen 16. Jugador realizando el shock combo contra un jugador (Unreal Tournament 3,
2007). ................................................................................................................................... 35
Imagen 17. Captura de una partida de CTF con vehículos (Unreal Tournament 3, 2007). 36
Imagen 18. Población de jugadores de UT3 y UT99 a día (8-9-2021) (Gray, 2012). ......... 37
Imagen 19. Captura del buscador de servidores de UT4 (9/9/2021) (Unreal Tournament 4,
cancelado). ........................................................................................................................... 38
Imagen 20. Diagrama de flujo de la metodología ágil basada en scrum (Genaro J., 2012). 47
Imagen 21. Captura del tablero de Trello del 4º hito del proyecto ABP (Atlassian, 2011). 48
Imagen 22. Captura de la interfaz de Clockify, apartado de informe detallado (Clokify). . 49
Imagen 23. Representación conceptual del modelo iterativo e incremental (Enciende la Luz
SL, 2018). ............................................................................................................................ 50
Imagen 24. El logo de Octocat junto al de GitHub (GitHub, 2013, 2018) .......................... 51
4
Imagen 25. El logotipo de Blender – Software libre multiplataforma, dedicado a la edición
tridimensional (Blender Foundation, 2014). ....................................................................... 51
Imagen 26. Logo de Visual Studio (Microsoft, 2019). ........................................................ 52
Imagen 27. Logo de Irrlicht (Irrlicht Project, 2012). ........................................................... 52
Imagen 28. Logo de Unity (Unity Technologies, 2011)...................................................... 52
Imagen 29.. Logo de Unreal Engine (Epic Games, 2013). .................................................. 52
Imagen 30. Logo de CryEngine (Crytek, 2013). ................................................................. 52
Imagen 31. Diagrama de flujo del proceso de gestión de riesgos (Sommerville, 2005). .... 57
Imagen 32. Diagrama de un análisis DAFO (Dirección General de Industria y de la
Pequeña y Mediana Empresa, 2020). .................................................................................. 72
Imagen 33. Diagrama de los estados de juego. Fuente: elaboración propia. ....................... 92
Imagen 34. Boceto del menú principal. ............................................................................... 92
Imagen 35. Boceto del menú de buscar partida. .................................................................. 93
Imagen 36. Boceto del menú de opciones. .......................................................................... 95
Imagen 37. Boceto del menú del inventario del jugador. .................................................... 96
Imagen 38. Boceto del menú de la (posible) tienda. ........................................................... 96
Imagen 39. Captura de las opciones del proyecto. .............................................................. 98
Imagen 40. Captura de las plantillas de proyecto. ............................................................... 98
Imagen 41. Captura de Visual Studio con la configuración para conectar un repositorio
GIT. ..................................................................................................................................... 99
Imagen 42. Captura del explorador de archivos de UE4 mostrando las blueprints de los
distintos elementos creados. .............................................................................................. 101
Imagen 43. Captura del editor de la blueprint del personaje en la que se muestra el
resultado final. ................................................................................................................... 102
Imagen 44. Captura de los grafos de eventos de la plantilla del jugador. ......................... 103
Imagen 45. Captura más en detalle de la simulación del ciclo de partida, justo debajo está
la lógica que oculta o muestra la malla en 1ª o 3ª persona, que ya se implementó en código
C. ....................................................................................................................................... 104
Imagen 46. Captura del editor de Pickable_BP, a la derecha se encuentran, bajo el nombre
de Pickable, los parámetros mencionados. ........................................................................ 105
Imagen 47. De izquierda a derecha: HealthPickUp_ BP,Pickable_BP y ArmorPickUp_BP,
las plantillas base de las cuales heredarán los distintos recogibles de cada tipo. .............. 106
Imagen 48. Resultado final de los recogibles básicos. Nótese el resaltado y el código de
colores para su fácil identificación. ................................................................................... 106
Imagen 49. Recogibles de armas, cada uno con su color identificativo. ........................... 107
Imagen 50. Aspecto inicial de la plantilla de WeaponComponent_BP. ............................ 108
Imagen 51. Variables que definen a un arma. ................................................................... 109
Imagen 52. La clase proyectil junto al resto de clases de C, nótese cómo es la única que
carga un aspecto visual notorio. ........................................................................................ 109
Imagen 53. Captura del editor mostrando un proyectil. .................................................... 110
Imagen 54. Efecto de explosión tras detonar una granada en un oponente. El área roja
oscura alrededor de la explosión delimita la zona de daño. .............................................. 111
Imagen 55. Captura del editor del HUD del jugador ......................................................... 112
5
Imagen 56. Captura de la función que asigna el valor de la salud al componente del HUD.
........................................................................................................................................... 112
Imagen 57. Captura del menú principal. ........................................................................... 114
Imagen 58. Captura del menú de inventario. ..................................................................... 114
Imagen 59. Captura del menú de opciones. ....................................................................... 114
Imagen 60. Captura de la blueprint del nivel. Arriba: enlace con el evento del jugador.
Abajo: contenido de la función. ......................................................................................... 115
Imagen 61. Funciones que modifican las opciones del Anti-Aliasing y la calidad de
sombras. ............................................................................................................................. 115
6
Índice de tablas
Tabla 1. Comparación de armas entre Q3A y UT99. .......................................................... 20
Tabla 2. Equiparación entre armas. Alt.: disparo alternativo, Def.: disparo principal (por
defecto). ............................................................................................................................... 21
Tabla 3. Objetos recogibles en Q3A y UT99. Fuente: elaboración propia. ........................ 23
Tabla 4. Descripción de los disparos primario y alternativo de las armas de UT99. .......... 26
Tabla 5. Riesgos de tecnología identificados. Fuente: realización propia........................... 58
Tabla 6. Riesgos de organización identificados. Fuente: realización propia. ...................... 58
Tabla 7. Riesgos de herramientas identificados. Fuente: realización propia. ...................... 59
Tabla 8. Riesgos de requerimientos identificados. Fuente: realización propia. .................. 59
Tabla 9. Riesgos de estimación identificados. Fuente: realización propia. ......................... 59
Tabla 10. Riesgos personales identificados. Fuente: realización propia. ............................ 59
Tabla 11. Riesgos no clasificados identificados. Fuente: realización propia. ..................... 59
Tabla 12. Riesgos catastróficos. Fuente: realización propia. .............................................. 61
Tabla 13. Riesgos serios. Fuente: realización propia. ......................................................... 62
Tabla 14. Riesgos tolerables. Fuente: realización propia. ................................................... 63
Tabla 15. Estrategias para los riesgos de Herramientas. Fuente: realización propia. .......... 64
Tabla 16. Estrategias para los riesgos de Tecnología. Fuente: realización propia. ............. 65
Tabla 17. Estrategias para los riesgos Personales, parte 1. Fuente: realización propia. ...... 66
Tabla 18. Estrategias para los riesgos Personales, parte 2. Fuente: realización propia. ...... 67
Tabla 19. Estrategias para los riesgos de Organización. Fuente: realización propia. .......... 68
Tabla 20. Estrategias para los riesgos de Estimación. Fuente: realización propia. ............. 69
Tabla 21. Estrategias para los riesgos de Requerimientos. Fuente: realización propia. ...... 70
Tabla 22. Estrategias para los riesgos no clasificados. Fuente: realización propia. ............ 70
Tabla 23. Riesgos con su correspondientes identificadores potenciales. Fuente: realización
propia. .................................................................................................................................. 71
Tabla 24. Requisitos funcionales ......................................................................................... 76
Tabla 25. Requisitos no funcionales. ................................................................................... 77
Tabla 26. Premisas de diseño de las armas. ......................................................................... 85
Tabla 27. Tipos de botiquines con sus valores y efectos. .................................................... 86
Tabla 28. Tipos de armaduras con sus valores. ................................................................... 86
Tabla 29. Tabla de powerups. .............................................................................................. 87
7
8
1. Justificación
Este proyecto tiene dos razones de ser. La primera y tal vez un poco obvia es terminar
el grado de Ingeniería Multimedia y por eso el proyecto se presenta de esta forma: una previa
investigación o análisis teórico con su posterior desarrollo software basado en dicho análisis.
Y la segunda es hacer un videojuego con el cual poder pasar buenos ratos con mis amigos o,
incluso, con desconocidos. Esto nace del hecho de que llevo jugando videojuegos desde muy
pequeño; mi padre los instalaba en el ordenador y yo como tonto los jugaba, y difícilmente
podría olvidar el día en el que me instaló el UT99. Tal vez fuera un poco demasiado joven
por aquel entonces, pero igualmente, me cautivó como ningún otro. Desde ese momento,
tengo afinidad por los shooters en primera persona, aunque afortunadamente mi repertorio
no se limita exclusivamente a dicho género, ya que son muchos los juegos con los que me
he echado unas buenas risas. Estos juegos me han acompañado a lo largo de mi vida aunque,
de la misma forma que me han ayudado a seguir adelante, algunas veces también me lo han
puesto difícil para pasar algún que otro examen…
En resumidas cuentas, la finalidad de este proyecto es de concluir esta etapa de mi formación
como profesional y para tal hito veo necesario darle algún simbolismo.
En este documento se van a tratar los distintos aspectos de los arena shooters mediante una
investigación inicial, un análisis a partir de dicha investigación y una posterior
implementación práctica de los conocimientos adquiridos. Cabe mencionar que existe un
Glosario de términos al final de este documento, el cual recoge los términos técnicos
específicos del tema a tratar.
9
2. Marco teórico
En este apartado se van a tratar la mayor parte de los aspectos teóricos del proyecto, en
concreto, los de investigación. Para ello a continuación se encuentra una pequeña
introducción que servirá para ubicar el proyecto en su contexto y explicar de qué trata.
2.1 Introducción
Desde sus inicios con Maze, los shooters han estimulado ese lado morboso de las
personas que despierta la fascinación por dispararle a cosas. Por supuesto que disparar a
cosas en un videojuego es divertido, sin embargo, en la vida real no tanto; y es por eso por
lo que el poder acribillar enemigos sin ninguna repercusión judicial o moral hace a los
shooters uno de los géneros más divertidos. Pero como todos los géneros de videojuegos, los
shooters se han ido dividiendo en otros subgéneros que se especializan en ciertos aspectos
del género que los contiene, como por ejemplo y en el cual se centra este proyecto, los arena
shooters.
Los arena shooters empezaron siendo un modo de juego multijugador de algunos shooters
como DOOM, Unreal o Quake, considerados los padres del género. Debido al éxito de este
modo de juego las próximas entregas de estas sagas (a excepción de DOOM) estarían basadas
en torno a este y tendrían especial énfasis en el apartado multijugador. Por otro lado, la
campaña un jugador consistiría en una serie de enfrentamientos como en el multijugador
pero contra una IA creciente en dificultad, su intención no iba más lejos de dar una
experiencia offline y permitir practicar contra bots mientras el jugador se familiariza con los
controles y las mecánicas.
Imagen 1. Maze War en un Imlac PDS-1D en el Museo
Histórico de Ordenadores (Bruce, 2011).
10
Sin embargo, a lo largo de los años este subgénero ha ido decayendo o, en su defecto, los
jugadores lo han ido dejando de lado a favor de otros subgéneros. Uno de los motivos que
han causado este abandono es la pronunciada curva de aprendizaje que hace que las
diferencias de habilidad sean abismales a partir de cierto punto, de manera que, por un lado,
los jugadores nuevos pueden sentirse abrumados antes de empezar y por otro, los jugadores
casuales se estancaran en algún nivel de habilidad y al no progresar y aburrirse, acabarán por
marcharse a otro juego. Además, el entorno siempre ha sido muy competitivo y, a pesar de
que muchas comunidades siempre han sido acogedoras, el espíritu perfeccionista de un juego
basado en la agilidad y rapidez de reacción irremediablemente se va a acabar manifestando
en todos los jugadores. La victoria se hace más satisfactoria y se siente más merecida de esta
forma, pero según las circunstancias, sobre todo cuando la diferencia de habilidad es muy
grande, la derrota puede llegar a ser mucho más frustrante y en el momento en el que algo
resulta frustrante se deja de hacer, especialmente cuando se trata de una elección propia
como es jugar a un videojuego.
En las siguientes páginas se hará un breve análisis de algunos juegos arena shooter,
explicando sus mecánicas, diferencias y similitudes, y luego se profundizará un poco en la
psicología de la frustración.
11
2.2 Antecedentes
En este apartado se va a hablar de los dos máximos referentes del género. Se hablará
de su contexto y se definirá la dinámica del juego introduciendo aspectos relevantes que se
irán tratando a lo largo del documento. La intención es también establecer un punto de
partida y unas bases comunes para los siguientes apartados.
2.2.1 Quake 3 Arena
Quake 3 Arena (Q3A) fue publicado por id en diciembre de 1999 y supuso una
revolución del género de los shooters puesto que, a diferencia de anteriores títulos de la
misma saga, solo se centraba en el aspecto multijugador, en concreto, en el modo
deathmatch. Este consiste en enfrentarse a otros jugadores en un mapa preparado para ello
(conocido como arena) en el que el jugador que cumpla un cupo de eliminaciones o, en su
defecto, el que más eliminaciones tenga cuando el tiempo de la partida expire, resultará el
ganador de la partida. A este modo de juego también se le conoce como FFA del inglés free-
for-all (todos contra todos).
Al comenzar una partida el jugador aparece en el mapa y tiene dos armas: una sierra circular
como arma melee y una ametralladora con algo de munición. Por el mapa, aparte de
adversarios, se pueden encontrar otras armas, munición para estas, orbes de salud en distintos
formatos y trozos de armadura que reducirán el daño recibido a la salud en ⅔.
Imagen 2. Captura promocional de la demo de Q3A (id Software, 1999).
12
Por otro lado, cabe destacar la existencia de recogibles especiales como son la inyección de
adrenalina, el teletransportador personal, o los powerups como el quad damage o haste, que
alteran nuestro daño o velocidad respectivamente. Estos últimos duran por un tiempo
limitado y, al morir el portador, caen al suelo para poder ser recogidos, en cuyo caso, su
duración será la restante.
Por lo que respecta al movimiento, podemos movernos en cualquier dirección combinando
las 4 direcciones cardinales básicas y además podemos saltar. Un añadido a este esquema es
lo que se conoce como “strafe jumping”, que consiste en realizar una serie de movimientos
con la cámara mientras se pulsan las teclas apropiadas de movimiento para acelerar al
personaje por encima de la velocidad máxima. Esto originalmente era un bug pero acabó por
convertirse en una de las piedras angulares del juego, puesto que moverse más rápido no
solo implica ser un objetivo más difícil de acertar sino que también supone llegar antes a los
recogibles especiales o realizar rotaciones más rápidamente y sorprender al oponente.
Con respecto a esto último, un aspecto importante del diseño de mapas es que estos son
cíclicos, como se puede observar en la Imagen 4, y se pueden recorrer todas las salas solo
caminando hacia adelante, lo cual permite al jugador centrarse en una única dirección y
garantiza que siempre habrá al menos un camino de huida y al menos un camino de
intercepción.
Imagen 4. Plano del mapa PRO_Q3DM13, usado en
partidas competitivas (Maximir93, 2021). Imagen 3. Captura de la sala central de PRO_Q3DM13
(Quake III Arena, 1999).
13
Otro aspecto importante son las armas y su variedad, sobre todo esto último, ya que es lo
que permite que cada arma se especialice en cumplir roles específicos. Esto a su vez le da al
jugador una visión definida de las posibilidades de cada arma, permitiéndole escoger la más
adecuada para cada situación. Más adelante se entenderá por qué, en un shooter, esto es vital.
A continuación, se proporciona una breve descripción extraída del manual del juego:
Gauntlet: Sierra circular con rango cuerpo a cuerpo y es una de las armas iniciales. Eliminar
a un jugador con este arma hace que el locutor anuncie que el jugador eliminado ha sido,
además, “humillado”.
Machine Gun: Arma automática de poca pero sostenida potencia de fuego. Una buena
precisión a corta y media distancia junto con una reserva de munición generosa hacen de
esta un arma inicial relativamente poderosa.
Shotgun: Escopeta clásica, dispara 11 perdigones de 10 de daño en un amplio cono con
dispersión aleatoria. Es una mejora directa del Gauntlet y, a pesar de que los perdigones
tienen alcance infinito, la dispersión hace que cualquier enfrentamiento distinto del CQB sea
contraproducente.
Plasma Gun: Arma que dispara bolas de plasma a alta velocidad que causan daño en una
pequeña área alrededor del punto de impacto, buena precisión a media distancia y la misma
cadencia que la Machine Gun. Sin embargo, la principal diferencia entre ambas reside en
que los proyectiles de plasma tienen tiempo de vuelo, a diferencia de los de la Machine Gun,
que es hitscan. Por ello resulta más eficaz para saturar al oponente con fuego de supresión.
Lightning Gun: Arma que dispara un flujo continuo de electricidad que causa poco daño
por tic pero con alta cadencia. Acaba rápidamente tanto con los oponentes como con las
reservas de munición. A diferencia de la mayoría de las armas, su alcance es bastante
limitado lo cual la restringe a medio rango como máximo.
Grenade Launcher: Lanzagranadas que dispara granadas con una corta trayectoria
parabólica y que explotan tras unos breves instantes a menos que impacte contra un jugador,
en cuyo caso explotará instantáneamente. Su daño y su cadencia son similares a las del
lanzacohetes. Sin embargo, las granadas tienen un radio de explosión más amplio que los
cohetes a costa de un alcance más limitado. Más que un arma, es una herramienta de area
denial (negación de área).
14
Rocket Launcher: Arma que dispara cohetes que causan daño masivo en impactos directos
y en el área circundante al impacto. El cohete se mueve relativamente despacio y la cadencia
de disparo es lenta con tal de justificar tal abrumadora potencia de fuego. Además, la
explosión del cohete causa un empuje sobre los jugadores desde el punto de impacto, lo que
permite no solo catapultar a los oponentes hacia arriba para impedirles el movimiento, sino
que además permite al usuario realizar rocket jumps aportando una gran ventaja a la
movilidad del jugador.
Railgun: Arma de largo alcance y gran daño que además es hitscan y es capaz de eliminar
oponentes sin armadura. Una vez más, para compensar tal obscena potencia de fuego la
cadencia de disparo es la más lenta de todas y además el disparo deja un rastro azul siguiendo
la trayectoria del proyectil.
BFG10K: Híbrido entre la Plasma Gun y el Rocket Launcher, dispara bolas rápidas de un
material irradiado con media cadencia y considerable AoE con gran daño por proyectil. Es
el arma más poderosa del juego (se denomina superarma) y tanto bots como jugadores
humanos te lo harán saber amablemente en el chat.
Como se podrá deducir, por motivos de equilibrio, unas armas harán más o menos daño pero
eso no quita que la experiencia de usarlas no se sienta satisfactoria. Sí es cierto que existe
una tendencia en la que las armas con más daño por disparo resulten más divertidas, pero
esto no hace que eclipsen a las que tienen menos daño, ya que estas suelen tener más cadencia
y eso también resulta entretenido.
El motivo de proporcionar esta información, aparentemente irrelevante, es debido a que una
gran parte de la experiencia de juego de un shooter son las armas. El cómo se sienten, lo que
hacen, cómo suenan y cómo se ven, tan trivial como inquietante.
15
2.2.2 Unreal Tournament
Publicado por Epic Games el 30 de noviembre de 1999, salió a la venta tan solo 3
días antes que Q3A. A pesar de esa pequeña diferencia en las fechas de publicación, Unreal
Tournament 1999 (UT99) ofrecía una mayor variedad de gameplay con respecto a Q3A
como son las mecánicas adicionales de las armas, interacciones con los mapas y más modos
de juego a parte del deathmatch, mutadores incluidos. Al igual que Quake, UT99 también
poseía una “campaña un jugador”. La IA es completamente editable: dificultad, apariencia,
precisión y estado de alerta entre otros parámetros. Aparte, la IA es capaz de dar y obedecer
órdenes, lo cual la convierte en un elemento sumamente inmersivo.
Análogamente, al empezar una partida el jugador aparece en un lugar aleatorio del mapa, en
el cual se pueden encontrar recogibles de salud, armadura, armas, munición y powerups.
Estos mapas también siguen el mismo principio de diseño que en Q3A y son cíclicos, con
algunos callejones en los que encontrar un arma poderosa o algún recogible interesante.
Por lo que respecta al movimiento del personaje, aparte de desplazarse normalmente,
también es posible esquivar (dando un pequeño salto casi instantáneamente) en una dirección
con una rápida doble pulsación de la tecla de movimiento en cuestión.
Imagen 5. Captura de una partida de UT99 en Deck-16 (Unreal Tournament, 1999).
16
Adicionalmente, se pueden realizar saltos más altos a costa de salud mediante el uso de lo
que se conoce como “piston jump” con el arma melee. También se puede realizar un “piston
dodge” de la misma manera.
Los mapas tienen un diseño cíclico con algunas salas con callejones sin salida. También se
puede apreciar cierta verticalidad en los niveles pese a que no hay muchas herramientas para
jugar con ella convirtiéndola en una ventaja.
Todas las armas tienen un modo de disparo alternativo/secundario que les otorga gran
versatilidad en innumerables escenarios, pero pocas veces se salen del rol que por diseño se
les ha asignado.
A continuación se expone una lista de estas con una breve descripción extraída del propio
juego:
Impact Hammer: Arma melee por defecto, el disparo primario carga el pistón que se suelta
automáticamente al acercarse a un oponente realizando gran cantidad de daño. El disparo
secundario realiza un ataque rápido y puede reflejar proyectiles.
Enforcer: Arma de fuego por defecto, se trata de una pistola con cadencia, precisión y daño
moderados cuyo disparo secundario sacrifica precisión por cadencia (y estilo). También es
posible duplicar el daño si se encuentra otro Enforcer ya que es posible llevar uno en cada
mano.
Imagen 6. Captura de la parte superior de Deck-16, nótese que al fondo hay recogibles pero que al igual que
los que se encentran más cerca de la cámara, son difíciles de identificar (Unreal Tournament, 1999).
17
Bio Rifle: Arma que dispara proyectiles tóxicos a media distancia que se adhieren a
superficies. Su disparo secundario permite cargar un disparo más potente que en caso de
impactar a un oponente tiene altas probabilidades de eliminarlo y en caso de fallar este gran
proyectil se despieza en pequeños trozos al impactar. Es posible desatar una reacción en
cadena al detonar proyectiles cercanos entre sí.
Shock Rifle: Rifle semiautomático de energía. Su disparo principal consiste en un láser de
energía instantáneo y el secundario en una bola de tamaño medio de plasma que se mueve
lentamente. Con esta arma se puede hacer un combo que consiste en disparar a la bola del
disparo secundario con el láser del primario para causar una gran y letal explosión. Esto se
conoce como shock combo o combo de choque.
Pulse Rifle: Rifle que dispara rápidamente bolas de plasma con alta cadencia. Su disparo
secundario consiste en un haz continuo de plasma de alcance limitado que impide que los
oponentes puedan usar su habilidad de esquivar.
Ripper: Arma automática que dispara sierras circulares que rebotan con la capacidad de
hacer impactos críticos a la cabeza. El disparo secundario consiste en un disco que explota
al impactar.
Minigun: Ametralladora con alta cadencia y poco daño, pero con bastante precisión. El
disparo secundario duplica la cadencia, pero reduce la precisión a la mitad. Es básicamente
la versión grande del Enforcer.
Flak Cannon: “Escopeta” que dispara 8 trozos de metal a media distancia en patrones
aleatorios con daño moderado por proyectil. El disparo secundario lanza una granada con
gran caída que explota al impactar y lanza 5 trozos de metal aleatoriamente.
Rocket Launcher: Arma que dispara cohetes lentos que causan daño masivo al impactar.
Manteniendo el botón de disparo pulsado, es posible cargar hasta 6 cohetes que se dispararán
en una línea horizontal, a menos que se pulse el botón secundario mientras se cargan, en
cuyo caso saldrán haciendo una espiral pequeña. Aparte, el disparo secundario convierte a
los cohetes en granadas de espoleta retardada. De nuevo, manteniendo pulsado el botón es
posible cargar hasta 6 granadas que se dispararán a la vez, a menos que se pulse el botón
primario en cuyo caso se lanzarán en rápida sucesión.
Sniper Rifle: Rifle de alta precisión que dispara proyectiles con daño grave, puede hacer
impactos críticos a la cabeza. Su disparo secundario consiste en un zoom.
18
Redeemer: Super arma que dispara un super cohete que se mueve muy lentamente. Este
causa una pequeña explosión nuclear al impactar, aniquilando a todo lo que se encuentre en
su radio de acción. El disparo secundario te permite controlar al cohete y detonarlo a merced.
Es posible destruir el cohete sin causar la explosión con un disparo certero. “Crimen de
guerra portátil” -Anónimo.
Translocator: No es un arma en sí, dispara una baliza a la que teletransportarse con el
disparo secundario. Es posible eliminar a los oponentes si en el momento de teletransportarse
hay alguien sobre la baliza. Alternativamente, si la baliza es destruida, el jugador morirá al
intentar teletransportarse. Solo está disponible en modos de juego por equipos y de objetivo
(como capturar la bandera) o si se activa un mutador. Se considera un “arma” extra.
Chainsaw: Arma melee extra que reemplaza al Impact Hammer (es necesario activar un
mutador) y que como ataque principal empieza a girar la cadena para causar daño masivo
(por tics). Como disparo secundario hace un barrido horizontal con la capacidad de infligir
un impacto crítico en la cabeza.
Como se puede observar, existen ciertas similitudes con Q3A, pero la existencia de modos
de disparo alternativos otorga una interesante capa de complejidad. Póngase por ejemplo el
combo de choque: el objetivo ya no es acertar a un oponente sino a un proyectil que, a su
vez, necesita estar bien posicionado cerca del enemigo. Esta es una forma alternativa más
complicada de derrotar a un jugador, pero sumamente satisfactoria cuando se consigue
realizar exitosamente.
19
2.3 Análisis y Evolución
Como se puede comprobar, ambos juegos tienen bastante en común en lo que
corresponde a la propuesta que plantean, y si bien sus diferencias pueden llegar a pasar
desapercibidas al ojo inexperto, a nivel conceptual resultan mucho más obvias y muestran
un claro enfoque distinto en el proceso de diseño. A continuación se hará una comparación
entre similitudes y diferencias y posteriormente se hará un análisis de la evolución de cada
uno de los títulos por separado.
2.3.1 Comparación de características: Similitudes
Para comenzar, se analizarán las similitudes entre ambos títulos para establecer las
bases que definen un arena shooter, por lo que en adelante, a menos que se indique lo
contrario o se puntualice algún matiz, todo es cierto para los dos juegos.
2.3.1.1 Concepto
La primera premisa es la arena. Este término se refiere a un lugar espacioso en el
que se llevan a cabo actividades deportivas o musicales y teatrales y que permite la asistencia
de un público que pueda disfrutar del espectáculo... Aunque lo importante aquí es la
etimología de la palabra: durante la época del Imperio Romano, los combates entre
gladiadores y bestias en el Coliseo se llevaban a cabo en un suelo cubierto de arena para que
ésta absorbiera la sangre derramada. Esto no solo define por un lado la temática y objetivo
del juego, sino que también dictamina tanto ciertas mecánicas como el diseño de niveles.
Por un lado, el objetivo del juego consiste en eliminar al mayor número de adversarios para
resultar el vencedor y, por otro, los jugadores empiezan con el mínimo equipamiento que les
permite defenderse, lo cual los obliga a buscar por el mapa, un lugar cerrado y sin posibilidad
de escapatoria, armas mejores y más potentes que, además, pueden obtener al derrotar a un
oponente. También necesitan munición
para poder seguir usándolas y armadura
para resistir daño o salud para curar sus
heridas. Estas semejanzas con la arena de
los gladiadores son los pilares del género y,
como tales, condicionan otros aspectos de
este, como son las herramientas de
destrucción. Imagen 7. Pollice Verso, 1872, popularizó el gesto de "pulgar
hacia abajo". Museo de Arte de Phoenix (Gérôme, 1872)
20
2.3.1.2 Armas
Dichas herramientas, vulgarmente denominadas armas, sirven al propósito de
derrotar a los oponentes y por más simplista que pueda sonar esto, hay un pesado proceso de
diseño (y posterior balance) por el cual se enfatiza el concepto de herramientas.
En ambos juegos se puede apreciar una curiosa similitud entre las armas, pese a que sus
diseños son completamente distintos, obviando la mecánica de disparo secundario de UT99
de la cual se hablará más adelante. Por un lado, el número de armas con las que se comienza
es el mismo: dos, pero resulta más interesante que se empiece con una arma melee y otra de
poca potencia considerada de defensa personal hasta encontrar otra mejor. Tómese la Tabla
1 como referencia.
También resulta llamativa la existencia de armas
que cumplen la misma función como son el Bio Rifle
y el Grenade Launcher como negadores de área, el
Sniper Rifle y la Rail Gun como armas de largo
alcance y gran daño, o especialistas en CQB como
son el Flak Cannon y la Shotgun. Luego están otras
similitudes absurdamente obvias como son el
Rocket Launcher (creativamente denominado así
en ambos juegos) para diezmar oponentes a cualquier distancia menos a quemarropa, o el
Redeemer y la BFG10K, cuya función es borrar a oponentes del mapa simplemente
poniéndoles el cursor encima y con ello, causar cierto descontento a dichos jugadores. Pero
no todas las similitudes son tan aparentes, por ejemplo el disparo secundario del Pulse Rifle
cumple la misma función que la Lightning Gun, que es derretir las defensas del oponente.
Esto, de nuevo, demuestra que la variedad de armas no solo es un atractivo del juego, sino
que es necesaria, ya que permite la especialización de estas, es decir, permiten al jugador
escoger la herramienta más adecuada a la situación. En la Tabla 2 se muestra las
correspondencias entre armas y la naturaleza del disparo. Además, nótese cómo están
agrupadas a su vez por su funcionalidad principal (largo alcance, negación de área,
autodefensa, supresión etc.).
Q3A UT99
Total armas 9 11(13)*
Semiautomáticas 5 8
Automáticas 4 3
De proyectil 4 6(7)**
Hitscan 5 5(6)**
Tabla 1. Comparación de armas entre Q3A y UT99.
*contando las armas extra
**teniendo en cuenta los disparos alternativos
Fuente: Elaboración propia.
21
Q3A UT99 Auto Semiauto Proyectil Hitscan
Gauntlet Impact Hammer X X
Machine gun Enforcer X X
Minigun X X
Minigun (alt.) X X
Shotgun Flack Cannon X UT99 Q3A
Plasma
Gun
Pulse Rifle X X
Ripper X X
Lightning
Gun
Pulse Rifle (alt.) X X
Grenade Launcher Flack Cannon (alt.) X X
Shock Rifle
(combo) X Alt. Def.
Bio Rifle X X
Rocket Launcher Rocket Launcher X X
Ripper (alt.) X X
Railgun Sniper Rifle X X
Shock Rifle X X
BFG10K Redeemer X X
Tabla 2. Equiparación entre armas. Alt.: disparo alternativo, Def.: disparo principal (por defecto).
Fuente: elaboración propia.
Si bien en UT99 hay mayor variedad de armas (sin contar las extra) que en Q3A, estas ven
cierto solapamiento de roles (ver Tabla 2) que no supone una redundancia gracias a los
disparos alternativos. Sin embargo, la menor “variedad” de Q3A permite analizar mejor qué
roles son necesarios para tener un repertorio de armas equilibrado, de manera que casi en
ningún escenario (de combate) posible exista la posibilidad de que no haya al menos una
herramienta adecuada. Como último apunte respecto al tema, cabe destacar cierta tendencia
de diseño que puede parecer obvia pero que tiene mucha más influencia sobre los jugadores
de la se podría esperar. Y esa tendencia es la relación entre cadencia, tipo de gatillo
(auto/semi) y daño. Las armas con gran cadencia suelen ser automáticas y con daño
mediocre, mientras que las armas con muy baja cadencia acostumbran a ser semiautomáticas
22
(y en caso de ser automáticas, tienen la suficiente cadencia como para no parecerlo, un clic
un disparo) y realizar una gran cantidad de daño.
A esta relación, hay que sumar el hecho de que a mayor cantidad de daño, más difícil suele
resultar acertar el disparo, o se penaliza mucho por fallar uno (es más difícil acertar con las
armas de proyectil y las armas de hitscan suelen tener un largo intervalo de disparo). Aunque,
por supuesto, esto no se aplica a las superarmas, cuya función es fastidiar al resto de
jugadores. Estas armas, que requieren mayor habilidad, acaban siendo las favoritas de los
jugadores porque resultan satisfactorias de usar.
2.3.1.3 Recursos
Sin embargo, estas armas de poco servirían sin munición, y sin salud por encima de
0. Continuando con la analogía, el jugador necesita recursos, lo cual no es un problema en
sí, ya que la arena está repleta de ellos en forma de recogibles; el problema será acceder a
ellos. Pero detalles aparte, el jugador tiene varios recursos básicos que gestionar los cuales
se pueden dividir en tres categorías arbitrarias: salud, armas y tácticos. No se ha mencionado
previamente pero a estas alturas es necesario indicar que el jugador dispone de una barra de
salud y otra de armadura. Dentro de la categoría de salud entran los orbes de salud/botiquines
y la armadura; está última funciona de forma distinta en cada juego, pero su función básica
es reducir el daño hecho a la salud en un porcentaje consumiéndose por el daño que absorbe.
Más adelante, cuando se mencionen las diferencias entre ambos títulos, se profundizará en
esto. También cabe mencionar la capacidad de sobrecargar la salud por encima de 100 y
hasta 199. Esta empezará a decaer de forma natural hasta quedarse en 100 en Q3A, pero no
en UT99. Asimismo, también es posible sobrecargar la armadura por encima de 100 y hasta
200 puntos de armadura en Q3A, y hasta 150 puntos en UT99. Sin embargo, al funcionar de
forma distinta en cada juego, solo decaerá en Q3A. Es posible sobrecargar la armadura
gracias a recogibles especiales como son la mega salud o el cinturón de protección. Véase la
Tabla 3 para una mejor referencia.
Objeto
Juego Salud Armadura Táctico Powerup
Q3A
Orbes:
• 5 HP
• 25 HP
• 50 HP
• Megahealth: 100 HP
Tipos:
• Trozo: +5 pts.
• Ligera: +50 pts.
• Pesada: +100 pts.
• Botiquín personal
• Teletransportador
• Battle suit
• Flight
• Haste
• Invisibilidad
• Quad damage
• Regeneration
23
Continuando con los recursos básicos, los que caen dentro de la categoría de armas son las
armas y la munición. Las armas, como ya se ha mencionado previamente, otorgan cierto
nivel de protección (no hay mejor defensa que un buen ataque (Sun-tzu, 500 a. C.)). Incluso
si al recogerlas ya vienen con
algo de munición, el
juego demostrará que es imposible llevar demasiada munición (Murphy & Raanan, s.f.).
Aquí cabe recalcar que el posicionamiento de la munición suele encontrarse cerca del arma
y, además, volver a recoger el arma nos otorgará algo de munición también. Esto último es
una práctica interesante ya que volver a recoger un arma impide que durante cierto tiempo
esta (o más bien, ese recogible en particular) pueda ser adquirida por los oponentes,
especialmente en UT99, ya que tardan más en reaparecer.
Por último pero no menos importante, quedan los recursos tácticos (véase la Tabla 3), los
cuales creativamente reciben este nombre, pues su posesión otorga una ventaja táctica sobre
los oponentes. Estos serían los powerups y otros recogibles especiales como las botas
antigravedad (UT99) o el teletransportador personal (Q3A).
De los recogibles especiales que no son
powerups no hay mucho que destacar en el
sentido de que son herramientas cuyo potencial
se incrementa con la habilidad del jugador para
elaborar estrategias. Sin embargo, los powerups
en sí son otra cosa completamente distinta, pues
otorgan un gran poder a jugadores
generalmente irresponsables. Por lo que
respecta a variedad, Q3A tiene una mayor selección de powerups que UT99, el cual solo
tiene dos, pero para sorpresa de nadie estos dos son los que tienen en común ambos juegos.
Estos son la invisibilidad y el Quad Damage (Q3A) o Damage Amplifier (UT99), que
otorgan al jugador que los recoge, por tiempo limitado, invisibilidad casi total o un
UT99
Tipos:
• Vial +5 HP
• Botiquín +20 HP
• “Barril” +100 HP
Reducción daño:
• Perneras 50% +50 pts.
• Chaleco 75% +100pts.
• Escudo 100% +150pts.
• Botas de salto
• Equipo de buceo
• Amplificador
de daño
• Invisibilidad
Tabla 3. Objetos recogibles en Q3A y UT99. Fuente: elaboración propia.
Imagen 8. De izquierda a derecha: botas anti-gavedad,
invisibilidad y damage amplifier (FANDOM, 2009)
24
incremento sustancioso del daño respectivamente. Lo importante del concepto de powerup
es que, como su nombre indica, incrementan el poder del jugador que lo adquiera,
volviéndose capaz de dominar la arena. Pese a que su duración es limitada, esta es suficiente
para que un jugador gane mucha ventaja con respecto al resto de jugadores, de manera que
sistemáticamente se convierten en recursos muy valiosos por los cuales merece la pena
arriesgarse.
Pero si a todo lo expuesto anteriormente le sumamos el hecho de que los recogibles
reaparecen (lo cual se ha asumido desde un principio), se obtiene un nuevo recurso, o más
bien meta recurso, que es el tiempo.
Gestionar el tiempo de reaparición de todos los objetos, o al menos de los más importantes,
constituye una enorme ventaja sobre los adversarios, ya que saber cuándo va a estar
disponible un recurso permite establecer prioridades y elaborar estrategias mucho más
eficaces. Y eso sin contar el hecho de que, como ya se ha mencionado anteriormente, adquirir
un recogible priva a los otros jugadores de dicho recogible.
2.3.1.4 Movimiento
Como se puede observar, es posible sacarle punta hasta a lo más básico, y a eso
precisamente se va a dedicar el siguiente párrafo porque aún queda otro aspecto importante
a comentar. Y ese aspecto es el movimiento que, como ya se puede suponer, no es tan solo
M
Imagen 9. Posibles rutas para recoger la armadura roja (triángulo rojo) o la mega salud (círculo azul) y sus
correspondientes opciones para continuar (Quake III Arena, 1999).
25
una simple herramienta para ir de un lugar a otro y, si efectivamente esto es para lo que sirve
y para lo que se debería usar, en estos juegos no se limita solo a eso. De todas formas, su
análisis comenzará por el propósito al que sirve, que es ir de un punto A a un punto B
(Imagen 9), pero antes de eso es necesario mencionar que ambos títulos tratan de ser
frenéticos y rápidos, por lo que el movimiento necesariamente es rápido y ágil.
Pero esa rapidez y agilidad no solo se percibe de forma pasiva al desplazarse por un nivel,
sino que los dos juegos otorgan herramientas al jugador para poder desplazarse más rápido,
como son el piston jump, las botas antigravedad, el rocket jump o el strafe jump. Además,
ya se ha hablado de las ventajas de llegar antes a los sitios. Esto, junto con lo explicado
anteriormente sobre el tiempo como recurso, crea la necesidad de moverse rápidamente, ya
que además dicha habilidad convierte al jugador en un objetivo más difícil de acertar, y esto
precisamente es la segunda y muy importante funcionalidad del movimiento: evasión.
El movimiento es una herramienta defensiva, ya que dependiendo de cómo se mueva un
jugador, sus oponentes tendrán más o menos dificultades para eliminarlo. Por ejemplo, un
jugador que use la Rail Gun tendrá más dificultades en acertar a un oponente que se mueva
lateralmente y con un patrón difícil de averiguar que a otro oponente que se mueve en
diagonal y con desplazamiento muy predecible. Pero a todo esto hay que añadir el hecho de
que el movimiento también puede ayudar a acertar más disparos, de manera que algo tan
simple como parecía el desplazamiento tridimensional se convierte en uno de los pilares
angulares del género que cada juego implementa a su manera (o bien como un bug muy
práctico o bien como la capacidad innata de esquivar). En ambos casos, pese a ser una
dificultad añadida, resulta ser algo natural de aprender.
26
2.3.2 Comparación de características: Diferencias
Una vez analizadas las similitudes a grandes rasgos sobre los conceptos más
importantes, ahora es posible comparar las diferencias con una perspectiva más cercana a las
decisiones de diseño de cada propuesta individual.
2.3.2.1 Armas
Una de las principales diferencias y de las más llamativas son los disparos
alternativos de UT99. Estos pretenden complementar al disparo principal y generalmente se
especializan aún más en el rol del arma. Aunque está el caso del shock Rifle, por ejemplo,
que añade la opción de combinar el disparo primario y alternativo para crear un área de
negación que causa daños masivos. Sin embargo, en este caso concreto el arma no pierde en
lo que se basa: para lograr el combo (conocido como shock combo), el jugador deberá acertar
con el disparo principal a un objetivo más pequeño pero la recompensa es potencialmente
mayor que la de acertar al propio oponente. Mientras que, por un lado, esta mecánica
complica más las peleas, por el otro, las vuelve un mundo de posibilidades, por lo que los
jugadores tendrán que esforzarse más en neutralizar al enemigo rápidamente para lo cual
deberán, de cierta manera, predecir sus movimientos. Respecto a esto último y sin entrar
mucho en detalles, resulta sumamente satisfactorio y gratificante predecir exitosamente a un
adversario y derrotarlo en combinación con las habilidades propias del jugador.
Arma Primario Alternativo Arma Primario Alternativo
Impact
Hammer
Mantener pulsado,
carga un poderoso
ataque melee.
Ataque melee
instantáneo de poco
daño y que refleja
proyectiles.
Ripper
Dispara discos
afilados que
rebotan hasta 6
veces.
Dispara discos
que explotan al
impactar.
Enforcer Disparo preciso con
daño moderado y baja
cadencia.
Sacrifica la mitad de
precisión para disparar
al doble de cadencia.
Minigun
Dispara balas
con alta
cadencia y
buena precisión.
Dispara al doble
de cadencia a
costa de la mitad
de precisión.
Bio Rifle Dispara un pequeño
pegote de cieno tóxico.
Carga un proyectil de
cieno más grande que
explota en pequeños
pegotes al impactar.
Flack
Cannon
Dispara
múltiples trozos
de metal en un
cono.
Lanza un
proyectil de
fragmentación.
Shock
Rifle
Dispara un láser que
impacta
instantáneamente.
Dispara una gran y
lenta bola de plasma
que crea una fuerte
explosión si se impacta
con el primario (shock
combo).
Rocket
Launcher
Lanza un cohete
o mantener
pulsado el
gatillo para
disparar hasta 6.
Arroja una
granada o
mantener
pulsado para
lanzar hasta 6
granadas a la
vez.
Pulse
Gun
Dispara bolas de
plasma de tamaño
medio a gran
velocidad.
Dispara un haz de rayo
que hace daño por
segundo.
Sniper
Rifle
Disparo que
casusa daños
masivos.
Enfoque de 8
aumentos.
Tabla 4. Descripción de los disparos primario y alternativo de las armas de UT99.
27
Otra de las diferencias más notables es la existencia de ataques críticos con ciertas armas en
UT99. Estas armas recompensan con daño adicional acertar a la cabeza del oponente, que es
un objetivo mucho más pequeño y, por tanto, mucho más difícil de acertar a diferencia del
torso, por ejemplo. Esto establece una relación directa entre riesgo y recompensa: cuanto
más arriesgado el disparo, más grande la recompensa (recuérdese el previamente
mencionado shock combo).
2.3.2.2 Armadura
Previamente se ha mencionado que la armadura funcionaba de forma distinta en cada
juego y a continuación se explicará brevemente en qué consiste dicha diferencia.
En Q3A la armadura absorbe ⅔ del daño recibido y se consume por una cantidad igual (esto
último es cierto para ambos juegos). Tanto los trozos de armaduras como las armaduras
amarillas y rojas funcionan de la misma manera, independientemente de la cantidad de
armadura que otorgan. En cambio, en UT99 cada pieza de armadura proporciona distintos
porcentajes de protección: las perneras otorgan 50 puntos de armadura y reducen el 50% del
daño recibido, la armadura de cuerpo entero da 100 puntos de armadura y reduce el daño
recibido en un 75%, combinar ambas armaduras otorga un porcentaje de alrededor del 90%
de absorción de daño y, cuando una de las dos armaduras pierda todos sus puntos, se
destruirá, perdiendo así la suma de la reducción. Por si no fuera suficiente, también se puede
equipar el cinturón de escudo que eliminará el resto de armaduras, pero que otorga 150
puntos de armadura y reduce el daño recibido en un 100%. Téngase en cuenta que la
armadura se reduce según el daño que absorba, de manera que un jugador con salud completa
y escudo tiene a efectos prácticos una piscina de salud de 250 puntos. Además, una vez
adquirido el cinturón, recoger armaduras recargará el escudo en su lugar. Nótese que esta
mecánica tiene una sinergia sorprendente con la de los impactos críticos, ya que es posible
destruir completamente el cinturón de escudo con el sniper Rifle y un disparo certero.
28
2.3.2.3 Movimiento
Otro aspecto en el que los dos títulos difieren es el de los esquives Como ya se ha
mencionado anteriormente, en UT99 se puede realizar una maniobra evasiva de forma casi
instantánea para evitar daño. En Q3A, por el contrario, no se puede, pero sí es posible
desplazarse a altas velocidades, lo cual es una forma casi análoga de evasión. Esta mecánica
se menciona debido a su repercusión en el movimiento, ya que lo vuelve más impredecible
y, por tanto, interfiere con el concepto de predecir al oponente.
2.3.2.4 Información para el jugador
Por último pero no por ello menos importante, está el feedback del usuario. Q3A
incorpora por defecto un simple mecanismo de hitmarker que reproduce un sonido cuando
los disparos conectan con un oponente. Mientras que este rasgo puede parecer poco
importante, en realidad resulta ser uno de los más esenciales, ya que esa retroalimentación
permite al jugador saber si lo está haciendo bien y en ocasiones, saber si ha acertado o no un
disparo a un oponente fuera de su campo de visión.
Esta información es de vital importancia para un jugador independientemente de su nivel de
habilidad; si es un novato sabrá que algo ha hecho bien, y si es un veterano, tendrá
información muy valiosa que le permitirá elaborar estrategias mucho más eficaces.
Imagen 10. Captura de UT99 demostrando la discreción de los objetos recogibles (Unreal Tournament, 1999).
29
Y aunque esto de elaborar estrategias eficaces se ha repetido varias veces a lo largo del texto,
es por el simple hecho de que en el género de los arena shooters, a partir de cierto nivel de
habilidad, se exige a los jugadores que piensen fuera del juego (to think out of the box sería
un término anglosajón más apropiado) y que no se limiten a mover el cursor sobre los
oponentes y esperar acertar, si activamente se predice con éxito dónde va a estar un oponente
en cada momento se trivializa el proceso de apuntado y se incrementa la tasa de acierto. Otro
aspecto que cabe destacar con respecto a la información que recibe el usuario serían los
recogibles. En Q3A levitan y rotan sobre sí mismos y las cajas de munición, por ejemplo,
tienen un diseño genérico y comparten los colores (que además contrastan con el mapa) con
las armas a las que pertenecen. Por el contrario, en UT99 los recogibles, en su mayoría,
permanecen estáticos y se pasan un poco desapercibidos como se puede observar en la
Imagen 10, además con el tamaño de imagen es imposible identificar al fondo el bio Rifle
con algo de munición. Este es otro aspecto que no parece muy importante pero que ayuda
enormemente al nuevo jugador a orientarse, aparte de que siendo la vista el método de
obtención de información más rápido y eficaz del ser humano, explotarlo es muy buena idea
a la hora de comunicar cosas al jugador.
2.3.2.5 Soporte para mods
Otra de las diferencias considerables pero más propia del aspecto de la comunidad
de jugadores es el soporte para mods por parte de UT99. Estos son modificaciones añadidas
al juego que alteran su comportamiento o características a voluntad del usuario. Este es un
aspecto clave, pues contribuye a la longevidad de un juego, ya que añade una capa de
rejugabilidad sobre el juego original y la prueba reside en que, a pesar de no ser tan fácil de
desarrollar mods como en UT99, existen muy buenos mods para Q3A.
Aquí concluye el análisis comparativo y pese a que sea extenso en sus puntos, cabe esperar
que se hayan pasado por alto bastantes cosas relativamente importantes por comentar, lo cual
no implica que no se hayan pensado ni valorado, sino que simplemente no se ha considerado
oportuno mencionarlas en este texto.
30
2.3.3 Análisis evolutivo (evolución)
Si desde un principio ninguna de estas dos propuestas hubiera tenido éxito, primero
este proyecto probablemente no existiría y segundo no habría razón que hubiera justificado
posteriores entregas. Sin embargo, ambos títulos gozaron de una muy buena recepción del
público, lo cual llevó a sus respectivas compañías a desarrollar secuelas que tuvieron
necesariamente el mismo éxito. Dado que la lista de entregas es bastante extensa y analizar
cada título individualmente no aportaría mucho, el siguiente análisis se va a centrar
únicamente en las más recientes entregas de ambas franquicias. La idea detrás de este análisis
es ver hasta dónde han evolucionado, qué aspectos han cambiado, cómo se ha adaptado la
propuesta inicial al relativo presente y cuáles son los resultados de dicha adaptación.
31
2.3.3.1 Quake Champions (2017)
Así se llama la última entrega de Quake que intenta reinventarse para el modelo de
negocio actual. Para comenzar, la primera diferencia e implícita en el título es la adaptación
del aspecto principal de los hero shooters en los cuales el jugador “encarna” a un personaje
concreto e individual que se caracteriza por tener sus propias habilidades y/o armas propias,
distintas de las de los demás héroes/personajes. En este caso concreto solo se aplicaría lo de
las habilidades únicas y distintivas, aunque cabe mencionar que a la hora de reaparecer, es
posible seleccionar una de entre tres armas principales, que son una versión menos potente
de las disponibles en el mapa (estas son la machine gun, la shotgun y la nailgun). Asimismo
todos los personajes pertenecen a una “clase” de entre ligero, medio y pesado, las cuales
determinan su máximo de armadura y su velocidad. Volviendo al concepto de hero shooter,
la implementación en Quake Champions (QC) consiste en una serie de características
pasivas únicas a cada personaje y una habilidad activa para la que es necesario pulsar un
botón para activar. Las habilidades pasivas otorgan una ligera ventaja y tienden a sinergizar
con la habilidad activa, la cual puede ser desde acelerar y cargar hiriendo a cualquier
oponente que se cruce hasta wallhack literalmente (algo que es gracioso teniendo en cuenta
que el personaje que tiene esta habilidad habla en ruso y pretende en general parodiar al
clásico y estereotipado “hacker” en los videojuegos).
Imagen 11. Visor usando su habilidad para ver enemigos a través de las paredes (Quake Champions, 2017).
32
Por otro lado, el “bug” que causaba el strafe jumping, al igual que en los posteriores títulos
a Q3A, ya no se considera un bug sino una mecánica más del juego y en este en concreto se
facilita su ejecución, a lo que hay que añadir también una muy conveniente opción en el
HUD para poder visualizar las teclas de movimiento y la velocidad a la que el jugador se
desplaza. Esto permite saber cuándo se está llevando a cabo correctamente la técnica y poder
mejorar.
Y hablando del HUD y la accesibilidad, hay que remarcar algo que ya se había comentado
anteriormente y que se ha mejorado en esta entrega como se puede apreciar en la Imagen 12.
Esto es la adquisición de información por pantalla, dígase (mayor) simplificación de los
recogibles y el establecimiento de un código distinguido de colores resaltantes para poder
identificarlos solo con un breve vistazo, aparte de un indicador de tiempo de reaparición para
los recogibles importantes.
A estos recogibles hay que añadir uno nuevo que es un arma llamada tri-bolt, la cual
sustituye al Grenade Launcher y dispara pequeños explosivos en ráfagas de tres proyectiles
que tardan unos instantes en detonar, a menos que impacten contra un oponente, en cuyo
caso explotan instantáneamente. Adicionalmente, a estas alturas sería conveniente
puntualizar que la Plasma Gun ya había sido reemplazada por la Nailgun en entregas
anteriores. Esto no supone ninguna diferencia pues ambas armas se comportan de igual
manera.
Imagen 12. Aquí se puede observar cómo los recogibles saltan a la vista y como el Quad tiene un contador hasta que
aparezca (Quake Champions, 2017).
33
También es necesario comentar la existencia de distintos modos de juego a parte del FFA y
el Team Deathmatch, como son capturar la bandera o sacrificio (similar a CTF), pero estos
no son muy relevantes (ni para este estudio, ni tampoco para los jugadores aparentemente).
Por último, queda por comentar lo más importante: el modelo de negocio. Inicialmente, para
QC se implementó un modelo de microtransacciones mediante lootbox que posteriormente
evolucionó a un modelo con el conocido pase de batalla el cual propone. También existe
desde un principio un tipo de moneda premium (de pago) para comprar cosméticos, aunque
también es posible adquirir dichos cosméticos con una moneda gratuita que se otorga al
jugador por completar partidas y desafíos diarios. Por último, durante un tiempo limitado
existió la posibilidad de comprar un pack con todos los campeones desbloqueados.
Aparte, se debe comentar la existencia de un sistema de niveles de experiencia y
desbloqueables (cosméticos) ligados a dichos niveles, así como un redundante sistema
social, pero esto es casi que un requisito mínimo para los juegos actuales.
Tras lo expuesto anteriormente, a continuación se va a proceder a valorar el éxito de la
propuesta. Sin embargo, por temor a que este apartado ocupe mucho espacio debido a las
numerosas consideraciones y razonamientos posibles, se hará honor a ese sabio dicho de que
una imagen vale más que mil palabras.
Imagen 13. Población de jugadores de QC desde su lanzamiento en Steam, captura tomada el (7-
9-2021) (Gray, 2012).
34
No es necesario explicar esos números pero sí puntualizar que el pico en esa gráfica se debe
a la actualización que puso el juego gratuito. Por otro lado muchas de las cíticas de la página
de steam se quejan del motor multijugador por el hitreg y de que muchas de las habilidades
consisten en “pulsar un botón y ganar”. A continuación se muestra la misma información
pero de los títulos previos como comparativa, téngase en cuenta que Quake Live (QL) se
supone que es una continuación de Q3A así como QC lo es de QL.
Si algo se puede sacar en claro es que ni el modelo moderno ni el antiguo tienen mucho éxito
hoy en día y que la población que queda en estos juegos es la realmente dedicada.
Imagen 14. Población de jugadores de Q3A y QL desde su aparición en la tienda de Steam, capturas tomada el (7-9-
2021) (Gray, 2012).
Imagen 15. Captura de una partida de QC, nótese cómo el enemigo está resaltado y cómo encima suyo (más bien
dónde se encontraba hace un instante) se indica el daño que se le ha causado (Quake Champions, 2017).
35
2.3.3.2 Unreal Tournament 3 (2007) y Unreal Tournament “Reboot”
Primero se hablará de Unreal Tournament 3 (UT3) y después de Unreal Tournament
“Reboot” (UT4), así como del por qué figuran los dos títulos en este apartado.
UT3 continúa la historia de UT2004, que es considerada una de las mejores entregas de la
saga pero con un lavado de cara tanto a nivel visual como a nivel de jugabilidad gracias al
motor Unreal Engine 3 (UE3). UT3 elimina la posibilidad de esquivar en el aire pero otras
maniobras como los dobles saltos, los esquives en las paredes y los esquives en sí, siguen
siendo posibles; la idea es mantener el combate en el suelo, a diferencia de las entregas
anteriores. Por otro lado, se incrementó el valor de la gravedad haciendo que todos los
objetos fueran más pesados para fomentar aún más dicho combate terrestre y, a su vez,
permitió mayor énfasis en las armas de proyectiles y en los combates CQB como no se había
hecho antes.
Desde UT99 hasta UT3 ha habido cinco entregas, las cuales proponen o descartan cambios
en función de la recepción que tuvieron por parte del público en la entrega anterior. Por ello,
solo se van a valorar los que existen con respecto a UT99. Entre las muchas diferencias, se
destacan cambios como el modo PEM del impact hammer, el cual daña a vehículos y le quita
los powerups a los oponentes al impactar, la adición de un nuevo powerup que incrementa
la velocidad del jugador y la cadencia de sus armas así como la de otro que vuelve al jugador
inmune al daño, o cambios en mecánicas (para volverlas menos abusivas) como, por
Imagen 16. Jugador realizando el shock combo contra un jugador (Unreal Tournament 3, 2007).
36
ejemplo, para contrarrestar la eficacia de los disparos a la cabeza con el Sniper Rifle, la pieza
de armadura del casco otorga inmunidad íntegra contra el primer headshot. También se
puede destacar los modos de juego adicionales, algunos de los cuales permiten el uso de
vehículos para desplazarse y eliminar adversarios, como se puede observar en la Imagen 17.
Estos modos están generalmente basados en objetivos, como puede ser capturar una bandera
o un nodo. Debido a esto último, otra de las notables diferencias es la sustitución del Ripper
por un arma especializada en destruir vehículos denominada Longbow AVRiL. Su disparo
secundario permite fijar un objetivo para el cohete del disparo primario, y es por esto por lo
que esta arma solo se limita a aparecer en casi todos los escenarios donde es posible usar
vehículos. Por otro lado el Pulse Rifle, renombrado como Link Gun, puede usar el disparo
alternativo para arreglar vehículos aliados.
Siguiendo con el tema de las armas, cabe destacar la modificación de comportamiento del
Rocket Launcher, cuyo disparo principal ya no se puede cargar. El disparo secundario
permite cargar hasta tres cohetes los cuales, al igual que en UT99, puede modificarse la
forma en la que se van a disparar pulsando el botón de disparo principal (bombardeo
horizontal, espiral o granadas). Obviando ciertos ajustes de balance, no hay mucho más que
comentar.
Imagen 17. Captura de una partida de CTF con vehículos (Unreal Tournament 3, 2007).
37
El modelo de negocio de UT3 consiste en la venta al por menor con opción de pagar un extra
por una versión limitada de coleccionista, actualmente adquirible mediante descarga digital
en distintos portales y es posible que también exista todavía alguna edición física cuyo
código de activación aún no se haya utilizado. A continuación se muestran unas imágenes
de Steam charts para ver y comprar las poblaciones de UT99 y UT3, téngase en cuenta que
estos juegos fueron añadidos posteriormente a Steam y que, por tanto, la actividad en los
juegos no empieza desde su fecha de publicación.
A continuación se resolverá el misterio de porqué figuran dos títulos en este apartado y qué
significancia tiene su presencia aquí.
Unreal Tournament 4, denominado así por usar Unreal Engine 4 (así como UT3 usando
UE3), también es conocido como el “reboot” de UT99, o como el proyecto fracasado de
desarrollo abierto de Epic. A día de hoy y desde finales de 2018, el proyecto está abandonado
por los desarrolladores, su presencia aquí es más bien simbólica, ya que en este apartado se
tratan las últimas entregas. Sin embargo, pese a que UT4 se encuentra en un estado jugable
y en un principio iba a ser gratuito, podría pasar como una última entrega de la saga, aunque
al tratarse de un proyecto abandonado no le haría justicia, especialmente con UT3 como
precedente. Antes se ha mencionado el desarrollo abierto y su fracaso, en pocas palabras lo
que se pretendía era favorecer a la comunidad compartiendo el código con esta, pero el
equipo subestimó la devoción de los fans y estos acabaron trabajando a un mayor ritmo que
los propios desarrolladores.
Imagen 18. Población de jugadores de UT3 y UT99 a día (8-9-2021) (Gray, 2012).
38
Esto junto con múltiples dramas, entre otros sobre qué dirección debía seguir el juego,
crearon un entorno bastante tóxico y discutiblemente fue gracias al éxito eclipsante de
Fornite, el infame battle royale en el que se centraban los esfuerzos de Epic, que el equipo
pudo abandonar discreta e inelegantemente el proyecto. A día de hoy la versión y el editor
de UT siguen disponibles, permitiendo a la comunidad crear contenido para el juego.
La idea en papel suena bien: la comunidad desarrolla y crea contenido para el juego. Este
contenido se puede monetizar a discreción del creador y en cuyo caso Epic cobraría un
porcentaje. Esto permitiría mantener un presupuesto muy pequeño para el juego mientras
(potencialmente) se harían grandes ingresos, por lo que resultaría un proyecto muy rentable.
Resulta difícil estimar el número de jugadores concurrentes, pues no existe una herramienta
fiable más que el propio buscador de partidas y este no parece indicar mucha actividad. Sin
embargo, existen pequeñas comunidades que realizan partidas en lobbies privados que,
obviamente, son aún más difíciles de rastrear.
Imagen 19. Captura del buscador de servidores de UT4 (9/9/2021) (Unreal Tournament 4, cancelado).
39
2.3.4 Conclusión
Como se ha podido comprobar en los análisis anteriores, ninguno de los dos juegos
ha tenido mucho éxito a la hora de atraer jugadores y los pocos a los que sí atrajo no
permanecieron mucho tiempo y eso sin contar a los acólitos correspondientes de las sagas.
En cada caso el problema ha sido distinto: en QC el desequilibrio entre personajes y el
sistema de red multijugador insuficiente junto con el modelo de monetización un tanto
abusivo; en UT4 la mala gestión y la toxicidad generada por la comunidad que provocaron
el abandono del proyecto; y en UT3, bueno, ser un juego de 2007 sin soporte y tener los
servidores llenos de bots y “hackers”.
Actualmente existen otros títulos relativamente recientes dentro del género de los arena
shooters, pero la mayoría pasan desapercibidos pese a ser buenas propuestas. Sin embargo,
estos tienden a imitar lo previamente establecido, convirtiéndose involuntariamente en
juegos genéricos. Aunque este no sería el caso de Splitgate (1047 Games, 2019), un arena
shooter que añade las mecánicas de portales de Portal (Valve Corporation, 2007) al formato
y que actualmente está teniendo bastante éxito en comparación con sus competidores, lo cual
puede llevar a pensar que lo que le hace falta al género es reinventarse un poco.
40
2.4 Psicología de la frustración
En este apartado se pretende explicar cómo los videojuegos producen frustración, y
a pesar de que este apartado se va a centrar en los arena shooters, la mayoría de los conceptos
son aplicables a prácticamente cualquier tipo de juego. Se advierte al lector o lectora que
este sigue siendo un trabajo del ámbito de la ingeniería multimedia y que este apartado no
se va a extralimitar, es decir, que la psicología se va a emplear como interfaz para
comprender las reacciones y decisiones del usuario.
Para empezar se va a dar una definición del concepto de frustración. Esta se define como
una respuesta emocional relacionada con la ira y la decepción causada por el impedimento
o dificultad de satisfacer la voluntad propia (Jeronimus & Laceulle, 2017). Aunque esta es
la definición más extendida, para conveniencia de este texto se va a citar a mi profesor de 2º
ESO de filosofía, Borja, quien muy apropiadamente la definió, probablemente citando a
alguien muy sabio incluido a él mismo, como “la frustración es lo que se produce cuando
uno no consigue lo que cree que se merece” y, si bien esta definición podría pasar como un
“palabreo estilizado” de la primera, se ha de destacar el concepto de “cree que se merece” el
cual tiene una connotación muy importante.
Más adelante se profundizará en eso pero ahora lo importante es la causa de la frustración,
que puede ser interna o externa. En el primer caso el impedimento proviene de la propia
persona al tratar de satisfacer sus objetivos, deseos o necesidades, especialmente si se
contradicen. En el segundo caso, el impedimento es externo, es decir, que escapa al control
de la persona como un puente derruido para cruzar un barranco o un puzle complicado
(Berger, 2007). Dicho así parece obvio que clase de frustración puede causar un videojuego:
externa cuando se trata de resolver un puzle o enfrentarse a un enemigo muy difícil. Sin
embargo, la mente humana, para bien o para mal, es un poco más complicada de manera que
un videojuego también puede causar frustración interna al jugador. El cómo es muy sencillo:
tan sólo hay que remitirse al concepto previamente mencionado “cree que se merece”.
41
Cuando se llega a cierto nivel de habilidad en un juego hay determinadas tareas que se dan
por supuestas e infalibles. De manera que fallar dichas tareas puede resultar muy frustrante
porque el jugador entra en conflicto con su percepción de sus propias habilidades. Cree que
merece hacer de forma perfecta la tarea, porque ya la ha hecho muchas veces y la ha
practicado hasta la perfección, pero en ese momento en concreto no resulta ser el caso por
un motivo u otro (Craig, D'Mello, Witherspoon, & Graeesser, 2008). Aunque también se
podría decir al contrario, jugadores novatos que no terminen de entender la dinámica del
juego se sentirán frustrados al no poder ni entender lo que sucede, ni ganar (Devilly,
Callahan, & Armitage, 2011).
Aparte, suele pasar con algunos jugadores que creen poseer una habilidad que no tienen y
que, al comprobar (perdiendo o no consiguiendo lo que quieren hacer) que en efecto, no son
tan habilidosos, se frustran. Hasta ahora se ha hablado de la frustración implicando que es
algo negativo para el juego, que lo es (Picard & Jonathan, 2002) , ya que entre otras cosas
promueve el desistimiento de la tarea frustrante en cuestión y eso no es muy conveniente si
se pretende retener a los jugadores. Además la frustración puede obsesionar al individuo y
detener el proceso de aprendizaje natural, es decir, decidir qué resultados obtiene el método
de obtenerlos independientemente de la realidad. Aunque esto también es lo que se busca en
realidad. Una persona con razonable tolerancia a la frustración será más persistente (Szasz,
Szentagotai, & Hofmann, 2011) en llevar a cabo la tarea frustrante y a esto hay que sumar el
hecho de que, cuando comienza la fase de extinción (proceso para hacer desaparecer una
conducta o conjunto de respuestas) ya sea por ejemplo por un castigo como morir o perder
en un videojuego, se reforzará la conducta antes de que esta comience a desaparecer. De
manera que la adversidad sirve como motivación para seguir intentándolo.
Por eso, la frustración, en cantidades apropiadas, es un sentimiento saludable. Su
funcionalidad es indicar al individuo que lo que está haciendo no es efectivo y sugiere que
se debe cambiar el método de afrontar el problema o desistir directamente. Además,
idealmente, aprender en el subsiguiente proceso de adaptación.
Tras lo expuesto resulta apreciable el problema con los arena shooters: o bien de entrada los
jugadores no se divierten y no continúan jugando, o bien los jugadores experimentados
abandonan debido a la acumulación excesiva de frustración. Incluso si algunos jugadores
después vuelven a jugar, la experiencia anterior les predispone a abandonar a la mínima
sensación que evoque la frustración.
42
Para resolver este problema es necesario plantearse que aspectos resultan especialmente
frustrantes en los arena shooters lo cual se hará a continuación.
En ningún orden en particular, las principales potenciales fuentes de frustración son:
• La derrota: Poco hay que hacer con respecto a este, para que existan ganadores debe
de haber perdedores. La forma de paliar esto es siempre recompensando al jugador
por completar la partida independientemente del resultado.
• Ser eliminado: Es una derrota que no gana la guerra al oponente pero
definitivamente le ayuda mucho. Puede parecer que no es muy relevante pero es en
este momento de haber sido eliminado en el que se puede reducir drásticamente la
frustración generada. Por eso es conveniente mostrar el estado de salud del adversario
así como dónde se encuentra, esto le da al jugador información sobre su oponente
como a cuántos disparos estaba de morir. Y con respecto a este tema, antes se ha
mencionado que las armas que causan grandes estragos en los oponentes son muy
satisfactorias, lo cual supone que al mostrar la salud del oponente aparecerá muy
dañada o al contrario, sugiriendo sutilmente al jugador que acertar disparos es una
buena idea.
• Lo impredecible: En un juego determinante lo impredecible son los jugadores y no
las consecuencias de sus acciones. Esto permite a un individuo deducir como va a
transcurrir una situación y planear o reaccionar acorde, lo que proporciona una
relativa sensación de control al jugador. Esto se debe a que no se aliena la
responsabilidad a un elemento impredecible otro del oponente. Lo importante en esto
es que los jugadores son, en realidad, predecibles. En el momento en el cual el
jugador identifica el patrón de comportamiento de otro, aparece la posibilidad de
victoria y la frustración producida por el castigo natural del juego pasa a ser un
elemento reforzante para seguir intentándolo. Pero obviamente repetir el castigo
numerosas veces acabará por hacer que el jugador desista de sus intentos y abandone.
• A nadie le gusta un ganador que siempre gana: Esto es otro aspecto difícil de
solucionar ya que depende mucho de los individuos en el caso concreto. Sin embargo,
ver derrotado a ese jugador inimputable resulta gratificante, por lo que anunciar su
eliminación por parte de otro jugador a todo el servidor puede resultar agradable a
todos excepto al eliminado. Pero este último ya se estaba divirtiendo antes por lo que
pese a “humillante” es muy probable que no le afecte de forma negativa.
43
La lista de elementos potencialmente frustrantes se podría extender hasta ocupar todo el
espacio disponible. Por ello tras haber evaluado los más relevantes al caso, se va a finalizar
este apartado aquí. En resumidas cuentas, se trata de diseñar un juego que tenga en cuenta
estos aspectos para la frustración de los jugadores no supere su umbral de tolerancia, aunque
también hay que tener en cuenta que es imposible crear una experiencia que satisfaga a todos
los usuarios. De manera que el objetivo es que los jugadores que abandonan lo hagan porque
no les gustó el juego y no porque acaben quemados de él.
44
3. Objetivos
Este proyecto tiene como objetivo, por un lado, realizar una investigación sobre qué
aspectos definen a los arena shooters y cómo se puede mejorar la fórmula del género para
que resulte más atractiva a nuevos jugadores y que además se reduzca la tasa de abandono.
Por otro lado, se pretende desarrollar un prototipo de videojuego arena shooter basándose
en los razonamientos y conclusiones a los que se ha llegado en el análisis anterior. A
continuación se concretarán los objetivos, divididos en objetivos y subobjetivos, y se darán
detalles sobre cómo se pretenden lograr.
3.1 Subobjetivos
Los objetivos principales de este proyecto se pueden resumir en dos grandes objetivos,
los cuales se complementan. Sin embargo, el orden de realización es importante, pues sin
los conocimientos que proporciona uno sería imposible lograr el otro. Dichos objetivos son,
en orden:
• Realizar un trabajo de investigación acerca de los videojuegos del género de los
arena shooters, centrándose en los orígenes de las sagas más reconocidas, analizando sus
bases y la evolución de cada fórmula a lo largo del tiempo e indagar, superficialmente,
en los aspectos psicológicos que puedan causar el descontento de los jugadores y
• Desarrollar un documento de diseño de videojuego (GDD) teniendo en cuenta lo
investigado y aprendido de la investigación previa y aplicando lo aprendido sobre diseño
de videojuegos en el curso anterior.
Para lograr el primer objetivo se hará una investigación que se divide en dos grandes
apartados. El primero es un análisis de las primeras entregas de las sagas más reconocidas
de los arena shooters y se complementará dicho análisis con una comparación entre los
títulos. Para terminar este primer apartado se hará, además, un breve análisis de la última
entrega de las sagas. El segundo apartado consistirá en un breve ensayo sobre la psicología
detrás de la frustración que se produce en los arena shooters y que hace el juego menos
accesible al usuario medio.
45
Mientras que el primer objetivo constituye una investigación o un apartado de teoría, el
siguiente se puede considerar una reflexión o el apartado de desarrollo. Para lograr el
segundo objetivo se realizará un documento de diseño de videojuegos razonando las
decisiones de diseño y dando una explicación basada en la información conseguida tras
completar el primer objetivo.
Como se puede observar, el proyecto gira en torno a dos objetivos principales, pero alrededor
de estos orbitan otros objetivos de menor envergadura, por lo cual se categorizan como
subjetivos. Sin embargo, forman parte del enfoque global del proyecto, y que, por tanto, es
necesario puntualizar y completar. Por otro lado, estos subobjetivos recogen las habilidades
y destrezas que se quieren desarrollar, probar y demostrar en conjunto con el proyecto en sí.
Estos son los siguientes:
• Implementar metodologías de desarrollo ágil, ajustadas al contexto.
• Realizar los documentos propios al desarrollo software:
o Análisis y gestión de riesgos
o Documento DAFO
o Análisis de requisitos
• Familiarizarse y adquirir destreza con las herramientas de trabajo propias del
desarrollo software.
• Desarrollar un prototipo con un motor de juego comercial.
• Documentar el proceso de desarrollo y pruebas.
• Desarrollar las habilidades de programación.
El cómo se van a lograr estos objetivos se puede ver en más detalle en el apartado 4 más
adelante.
46
4. Metodología
Para gestionar este proyecto se planteará una metodología ágil basada en SCRUM y
para desarrollarlo se hará uso de un modelo iterativo por prototipos. Con esta organización
se facilitará el desarrollo y permitirá progresar adecuadamente, especialmente en el aparado
de software. Aparte, se establecerán hitos, los cuales se van a definir como conjunto de tareas
que suman una unidad de progreso, cuya finalidad es poder cuantizar los avances del
proyecto y poder definir el estado de este último.
Por otro lado, para el desarrollo software es necesario un Game Design Document o GDD.
Este documento nacerá de una previa investigación sobre los videojuegos precedentes en la
cual se hará un análisis comparativo y otro evolutivo, y se completará con una investigación
acerca de los aspectos frustrantes de estos videojuegos, tan nocivos para el juego como para
el jugador. Con esto se pretenden justificar las decisiones de diseño tomadas en el GDD así
como de enriquecerlo y extenderlo. De la misma manera, como cabe de esperar, se realizarán
los documentos pertinentes propios del desarrollo software tales como el documento de
gestión de riesgos.
47
4.1 Metodología de gestión
Para la gestión de la parte práctica del proyecto se plantea un modelo ágil basado en
SCRUM y adaptado un equipo compuesto por una sola persona. En este modo de trabajo
existen distintos roles ya que está enfocado al trabajo en equipo y su finalidad es agilizar el
progreso del trabajo. Otro aspecto importante es que el trabajo se divide en iteraciones al
principio de las cuales se hace una planificación del trabajo a realizar y al final de las cuales
se entrega software funcionando, idealmente.
Análogamente para la parte teórica se pretende aplicar el mismo modelo puesto que las
ventajas se aplican de la misma manera. El funcionamiento del modelo SCRUM se puede
entender con más facilidad refiriéndose a la Imagen 20.
Aunque mientras que esta metodología beneficia más a grupos más que a un único individuo,
resulta imposible negar que incluso en ese caso también agiliza el desarrollo y permite una
gestión más eficiente del tiempo disponible. Eso sin contar que, en caso de que se triplique
el número de miembros en el proyecto, al ya estar organizado de esta manera, será más fácil
la integración de los miembros y el incremento de la fuerza de trabajo se verá reflejado
inmediatamente.
Imagen 20. Diagrama de flujo de la metodología ágil basada en scrum (Genaro J., 2012).
48
4.1.1 Herramientas de gestión
Estas herramientas sirven para gestionar y contabilizar las distintas tareas necesarias
para completar el proyecto a la vez que permiten establecer la prioridad de dichas tareas.
4.1.1.1 Trello
Esta herramienta proporciona una “pizarra” digital en la cual se pueden poner tarjetas
con el nombre de las tareas y se pueden mover entre listas las cuales indican el estado de la
tarea (por hacer, en proceso, retocando, etc.). También es posible crear etiquetas para
categorizar las tareas y reconocerlas visualmente.
En la Imagen 21 se puede observar un ejemplo real de tablero de Trello de un proyecto
finalizado. En la parte de la izquierda van las “fichas” (tareas) que están por hacer o que se
encuentran en el backlog de la iteración. En el centro, generalmente, se encuentran en las
que se está trabajando, de una manera u otra y por último, a la derecha del todo se van
ubicando las ya finalizadas.
En este caso en concreto, se decidió crear múltiples columnas con la finalidad de poder
monitorizar el estado de la tarea con más precisión: si se está desarrollando, si se está
revisando o si se está puliendo, por ejemplo.
Imagen 21. Captura del tablero de Trello del 4º hito del proyecto ABP (Atlassian, 2011).
49
4.1.1.2 Clockify
Clockify, que es una herramienta de gestión del tiempo, se va a usar con la intención
de contabilizar el tiempo dedicado a cada tarea, esto influirá a la hora de asignar prioridades
pues permitirá ver en qué tareas se está trabajando demasiado y en cuales no se está
trabajando del todo. También es una forma de medir el tiempo “real” dedicado al proyecto.
4.1.2 Hitos
Previamente se han mencionado los hitos como medida del progreso del desarrollo
software, estos son un conjunto de tareas que se deben completar en un determinado plazo
de tiempo. Estos definen el progreso de forma conceptual y ayudan a entender el estado del
proyecto. Al final de cada hito se hará un pequeño informe con las tareas realizadas,
dificultades encontradas y la planificación para el siguiente hito. Este documento se verá
complementado por la información que aportan las anteriores herramientas. El período de
los hitos será de dos a tres semanas.
Imagen 22. Captura de la interfaz de Clockify, apartado de informe detallado (Clokify).
50
4.2 Metodología de desarrollo
Para el apartado práctico, debido a la naturaleza del proyecto, se ha escogido la
metodología de desarrollo por prototipos. Este modelo de desarrollo evolutivo se centra en
la funcionalidad y en la retroalimentación por parte del usuario, por ello el proceso de divide
en distintas etapas, la de diseño rápido, la de creación del prototipo, la del desarrollo y
retroalimentación y la de entrega final. Para este caso en concreto, se propone un prototipado
evolutivo, que consiste en trabajar sobre un único prototipo el cual se va ampliando y
desarrollando con fin de potencialmente poder reciclar código para una versión final, más
centrada en la calidad del software. Esto implica cierta similitud con el desarrollo iterativo e
incremental con respecto a la organización del trabajo, por lo que se tomará como referente.
Otro aspecto importante es el desarrollo modular del software, que permite añadir, modificar
y extraer componentes sin comprometer al resto, lo cual resulta muy útil a la hora de
experimentar y probar cosas nuevas. Por otro lado, los previamente mencionados hitos se
definirán asignándoles una serie de tareas que representen una unidad de progreso, es
importante mencionar que un hito no es una iteración.
Por lo que respecta al desarrollo en sí, es necesario establecer un orden lógico de evolución
el cual se propone en las siguientes líneas. Aunque no se ha de tomar ni como el orden más
apropiado ni como el que se va a seguir exactamente. Primero, es necesario implementar las
funcionalidades más cercanas al jugador como sería el movimiento. Sin embargo, solo se
implementará lo más básico. Las características del movimiento más complejas se
implementarán más adelante. De forma similar se hará con el resto de las funcionalidades,
cuando el jugador se pueda mover necesitará poder disparar y después recoger objetos. Pero
tras ser capaz de recoger objetos, estos, a su vez, tienen que interactuar con el jugador
otorgándole algo, luego el jugador necesita valores que gestionar como son la salud,
armadura y munición… De esta forma, progresando por unidades lógicas y con conciencia
de lo que se quiere hacer, se desarrolla una base sobre la que construir el resto de las
funcionalidades más complejas.
Imagen 23. Representación conceptual del modelo iterativo e incremental (Enciende la Luz SL, 2018).
51
A pesar de esto, es posible que en el mismo momento del desarrollo, por un motivo u otro,
se implemente o se deje de implementar una funcionalidad debido a que las circunstancias
así lo exijan.
4.2.1 Herramientas de desarrollo
Estas herramientas se van a emplear para el desarrollo software y como cabe de
esperar, su utilidad es facilitarlo y agilizarlo.
4.2.1.1 GitHub
Herramienta para el control de versiones del prototipo, es básicamente un repositorio
de código el cual permite tener varias ramas de desarrollo permitiendo así la experimentación
sin riesgo de estropear el trabajo previo a la vez de que permite categorizar los estados del
juego mediante dichas ramas (development, experimental, máster/release, etc.).
4.2.1.2 Blender
Este programa permite crear objetos en 3D y animaciones de forma muy sencilla. Su
licencia gratuita otorga gran flexibilidad, no solo a la hora de crear modelados sino también
por la gran variedad de plugins disponibles capaces de agilizar el proceso creativo o
enriquecerlo. A pesar de disponer de tal libertad, con esta herramienta se busca obtener
modelados temporales con los que representar distintos conceptos en el videojuego o adaptar
otros ya existentes con tal de satisfacer la necesidades inmediatas del proyecto. Su elección
se basa en el precio de la licencia y en la familiaridad con la herramienta.
Imagen 25. El logotipo de Blender – Software libre multiplataforma, dedicado a la edición tridimensional
(Blender Foundation, 2014).
Imagen 24. El logo de Octocat junto al de GitHub (GitHub, 2013, 2018)
52
4.2.1.3 Visual Studio 2019 (Community Edition)
Esta versión gratuita del editor de código Visual Studio
viene con todas las características necesarias pese a ser una
versión simplificada, sin embargo, el motivo de elección por
encima de otro editor como por ejemplo VSCode es debido a
que Visual Studio posee un paquete de desarrollo con motores
como Unity o Unreal Engine que facilitan el desarrollo con
dichos motores. Aparte, estos mismos utilizan por defecto esta
herramienta para la edición de código.
4.3 Motor del juego
Para el desarrollo del prototipo se ha valorado el uso de distintos motores para
videojuegos en los cuales se han encontrado aspectos a favor y aspectos en contra. Tras
evaluar detenidamente dichos aspectos se ha llegado a la conclusión de que el motor más
apropiado para el proyecto es Uneral Engine. Dicho esto, y antes de proceder con la
explicación de dicha elección. A continuación se encuentra un resumido análisis de cada
opción considerada para el desarrollo del proyecto con consideraciones tanto objetivas como
personales.
Imagen 27. Logo de Irrlicht (Irrlicht Project, 2012). Imagen 30. Logo de CryEngine (Crytek, 2013).
Imagen 29.. Logo de Unreal Engine
(Epic Games, 2013). Imagen 28. Logo de Unity (Unity Technologies, 2011)
Imagen 26. Logo de Visual
Studio (Microsoft, 2019).
53
4.3.1 Motor propio con Irrlicht
Irrlicht es un motor muy potente con muchas características y alto rendimiento.
Además, ese alto rendimiento se debe a la posibilidad de trabajar a muy bajo nivel gracias a
una amplia y detalladamente documentada API. También cabe resaltar su versatilidad a la
hora de importar modelados y texturas. Por otro lado, se puede trabajar y desplegar el
proyecto en numerosos sistemas operativos de forma independiente y da soporte a 5 APIs
de renderizado, para poder adaptarse mejor a cada máquina en concreto. Uno de los aspectos
más importantes es que es gratuito y de código abierto. El inconveniente es que hay que
hacer el motor de juego desde cero. Sin embargo, mientras que un motor propio otorga
máxima flexibilidad a la hora de desarrollar y permite ahorrar recursos de forma más
eficiente, la más bien corta experiencia previa supone un esfuerzo que consume mucho
tiempo y que además, no corresponden para el objetivo de este proyecto ya que el producto
final no es lo más relevante.
4.3.2 Unity
Uno de los motores de juegos por excelencia, o más bien por facilidad de acceso ya
que obtener algo “jugable” en Unity es relativamente sencillo. Pero esa relativa facilidad de
desarrollo viene a costa de tener que trabajar en C# y, que precisamente por la experiencia
con el lenguaje, es un aspecto descalificante. Además, el flujo de trabajo no termina de ser
intuitivo. Por último pero no menos importante el motor de físicas necesita bastante trabajo
para el tipo de juego que se plantea. Sin embargo, cabe destacar que Unity es una gran
herramienta para producir prototipos que después se implementarán en otro motor de juegos.
4.3.3 CryEngine
No era una opción inicial debido a su modelo de subscripción de pago, pero
igualmente se ha hecho una breve investigación para terminar de concluir definitivamente
que no es un motor adecuado. Para empezar el motor es fácil de usar tal y como viene, sin
embargo, la mayoría de las herramientas no sirven para un propósito específico o más bien
para algo que se salga del propósito general. Además su motor de físicas no está preparado
para juegos rápidos como es un arena shooter.
54
4.3.4 Unreal Engine 4
Otro de los grandes motores en la industria, Unreal Engine 4 (UE4) es uno de los
más usados en el mercado y hace uso de las denominadas blueprints o plantillas para facilitar
el desarrollo a principiantes. Sin embargo, lo atractivo de esto es la posibilidad de combinar
el desarrollo mediante código (en C++) con dichas plantillas, lo cual permite que las
funcionalidades básicas se implementen en C++ y que el aspecto visual se implemente de
una forma más intuitiva (visual) con las plantillas. Por otro lado su motor de físicas es muy
conveniente para un arena shooter (quizás que sea la evolución del motor con el que se hizo
UT99 tenga algo que ver).
La decisión final de emplear Unreal Engine 4 se debe a, por un lado, la familiaridad con el
lenguaje de programación y, por el otro, al flujo de trabajo que permite separar el apartado
de código del apartado visual, muy adecuado para prototipar. También dicho flujo de trabajo
permite la modularidad de componentes, por lo que manipularlos sin alterar el
funcionamiento de otros es relativamente sencillo. Además de que tras probar el motor se ha
ganado cierta preferencia personal por este.
55
5. Análisis
En este apartado se van a exponer y explicar las consideraciones que se han tomado
para justificar las decisiones tomadas a la hora de diseñar el juego prototipo. También se
incluirá el procedimiento de implementación en software para complementar el contenido
del trabajo.
5.1 Fundamentos base
Antes de comenzar se van a puntualizar brevemente los fundamentos base que
definen a un arena shooter y a los que el juego deberá ceñirse. En este apartado no se van a
explicar a menos que sea necesario para la comprensión del texto o de porqué figura como
fundamento base.
El primer fundamento que se va a tratar es el concepto de arena, todos los recursos que
necesita el jugador están en la arena de un modo u otro. El jugador “no se trae nada de
casa” lo cual conecta con el siguiente fundamento: al reaparecer, ya sea por primera vez o
por enésima, el jugador comienza con un equipamiento mínimo indispensable de una
arma a melee que no gasta munición y otra a distancia que sí.
El siguiente, también relacionado, es que todos los jugadores están en igualdad de
condiciones, es decir, no habrán habilidades especiales o pasivas de personajes.
A continuación, la armadura, independientemente de cómo funcione debe de haber un
recurso que reduce el daño recibido del que preocuparse. También son necesarios powerups
que inclinen la balanza desproporcionadamente durante un tiempo limitado y otros
recogibles que otorguen cierta ventaja táctica (v.gr.: el teletransportador o las botas
antigravedad).
Pasando a otro aspecto, es necesaria una variedad de armas tal que el conjunto de estas
pueda satisfacer las necesidades de casi cualquier escenario de combate posible.
Otro aspecto importante relativo a la arena es su diseño, esta deberá ser cíclica con la
menor cantidad de callejones posibles y los recogibles se emplazarán generalmente fuera
de la zona de paso pero a la vista.
56
El gameplay será rápido y frenético con gran libertad de movimiento. Esta irá acompañada
por elementos interactuables como elevadores o catapultas cinéticas en el mapa que
permitan el desplazamiento sobre todo en el eje vertical. También existirán peligros
ambientales como pueden ser la lava o los acantilados y dañar a un jugador que
posteriormente muere por alguno de estos peligros contará como eliminación.
Estos son los aspectos clave que definen al género de los arena shooters, pero como cabe de
esperar la implementación cambia de unos a otros y la percepción de ellos puede variar según
la persona, para este caso y por ser prácticos lo expuesto anteriormente será en lo que se base
el proyecto independientemente de si son acertados o no terminan de serlo, ya que, en un
mínimo de lo anterior, se tiene que estar de acuerdo.
57
5.2 Gestión de riesgos
Los riesgos se definen como “posibilidad de que se produzca un contratiempo o una
desgracia, de que alguien o algo sufra perjuicio y daño” y dado que la Ley de Murphy estipula
que todo lo que puede ir mal, irá peor (Murphy & Raanan, s.f.) es seguro afirmar que los
riesgos son una amenaza constante a tener en cuenta en todo proyecto que se precie. Es
debido a esto que resulta sensato y necesario identificar dichos riesgos y elaborar estrategias
para contrarrestarlos, para ello primero se identifican y categorizan los riesgos, seguidamente
se valorarán las posibilidades reales de que sucedan así como qué tipo de amenaza
constituyen para el proyecto para así, posteriormente, poder elaborar una estrategia para
prevenir o abordar los problemas que puedan generar los riesgos y en su caso, aplicar un
plan de contingencia. Por último, para poder aplicar dichas estrategias, es necesaria una
forma de monitorizar los riesgos para detectarlos a tiempo. Además este es un proceso cíclico
como se muestra en la Imagen 31 ya que estos aparecen o evolucionan según avanza el
proyecto y, por tanto, es necesario actualizar el documento de gestión de riesgos
(Sommerville, 2005).
Identificació n de
riesgós
Listado de riesgos
potenciales
Ana lisis de
riesgós
Mónitórizació n
de riesgós
Planeació n de
riesgós
Listado de
priorización de
riesgos
Valoración de
riesgos
Anulación de
riesgos y planes de
contingencia
Imagen 31. Diagrama de flujo del proceso de gestión de riesgos (Sommerville, 2005).
58
5.2.1 Identificación
Los riesgos se van a clasificar en distintas categorías según su naturaleza, lo cual
facilita su posterior análisis y gestión. Dicha clasificación de riesgos es la siguiente:
• Tecnología: son los relacionados con las técnicas de desarrollo.
• Organización: son relativos a la planificación de las iteraciones y la distribución del
trabajo
• Herramientas: estos corresponden a los medios para el desarrollo.
• Requerimientos: se refieren a todo lo que tenga que ver con la adquisición y
cumplimiento de estos.
• Estimación: similares a los de organización pero exclusivos de las tareas
individuales en sí.
• Personales: todos los vinculados con la salud y situación personal del desarrollador.
• Otros: todos los que no pertenecen a ninguna de las categorías anteriores.
De la Tabla 5 a la Tabla 11 se recogen los riesgos por sus categorías.
TIPO DE
RIESGO POSIBLE RIESGO
Tecnología
Problemas con el entorno de trabajo (sistema operativo no
responsivo, SO no reconoce las unidades de almacenamiento…)
Fallos de hardware (algún componente del PC deja de funcionar
repentinamente)
Hardware insuficiente (imposibilidad del hardware para saciar los
requisitos del software)
Problemas con la conexión a Internet
Pérdida de los datos almacenados
Problemas al pasar los datos de un programa a otro Tabla 5. Riesgos de tecnología identificados. Fuente: realización propia.
TIPO DE
RIESGO POSIBLE RIESGO
Organización
Mala distribución de las tareas en los hitos (sobrecarga de trabajo,
falta de trabajo, empezar tareas que requieren de otras previas…)
Mala subdivisión de tareas (no dividir bien las tareas en problemas
más sencillos o dividirlas sin considerar unidades lógicas)
Mala distribución del esfuerzo entre el proyecto teórico y el de
código
No contabilizar el tiempo dedicado al proyecto (tiempo y nombre de
la tarea)
No ceñirse a la metodología
No ceñirse a las tareas establecidas para cada hito Tabla 6. Riesgos de organización identificados. Fuente: realización propia.
59
TIPO DE
RIESGO POSIBLE RIESGO
Herramientas
Cierre inesperado del programa o programas
Caída de los servidores de los servicios/herramientas empleadas
Conflictos con Git
Pérdida completa del entorno de trabajo (PC queda inoperable)
Cambio en las licencias de los programas utilizados Tabla 7. Riesgos de herramientas identificados. Fuente: realización propia.
TIPO DE
RIESGO POSIBLE RIESGO
Requerimientos
Cambios en uno o más requerimientos
Cambios drásticos en uno o más requerimientos (incluyendo la
adición o la eliminación)
Mala identificación/descripción de uno o varios requerimientos
Imposibilidad de implementar uno o varios requerimientos Tabla 8. Riesgos de requerimientos identificados. Fuente: realización propia.
TIPO DE
RIESGO POSIBLE RIESGO
Estimación
Sobreestimación de una tarea
Infraestimación de una tarea
Fallar a identificar una tarea crítica
Retraso de una tarea crítica
Introducir una tarea innecesaria
Coste temporal del proyecto superior al estimado Tabla 9. Riesgos de estimación identificados. Fuente: realización propia.
TIPO DE
RIESGO POSIBLE RIESGO
Personales
Enfermedad/dolencia leve
Enfermedad/dolencia grave
Padecer estrés debido a la carga de trabajo
Padecer estrés debido a causas externas al proyecto
Problemas externos al proyecto
Abandono del proyecto
Falta de motivación
Citas médicas
Formación insuficiente
Falta de creatividad Tabla 10. Riesgos personales identificados. Fuente: realización propia.
TIPO DE
RIESGO POSIBLE RIESGO
Otros
Las obras en la fachada del edificio del desarrollador se demoran
Viaje a Irlanda para visitar a la hermana del desarrollador que está
allí de erasmus. Tabla 11. Riesgos no clasificados identificados. Fuente: realización propia.
60
5.2.2 Análisis
A continuación, se evaluará tanto la probabilidad como la gravedad las
consecuencias que pueden tener los riesgos anteriormente expuestos para facilitar su
posterior planificación y monitorización. Para expresar ambos conceptos se hará uso de un
rango de valores (intervalos) arbitrarios explicados a continuación.
Las probabilidades se categorizan entre:
• Muy baja (<10%)
• Baja (10% - 25%)
• Moderada (25% - 50%)
• Alta (50% - 75%)
• Muy alta (>75%)
Y la gravedad se categoriza entre:
• Catastrófico: Causa un gran cambio radical del proyecto o incluso su cancelación,
afecta enormemente al desarrollo del proyecto.
• Serio: Constituye un contratiempo importante, puede afectar al progreso del proyecto
y verse reflejado en el resultado final.
• Tolerable: Se trata de un contratiempo menor, de fácil recuperación cuyo efecto no
tiene por qué verse reflejado en el proyecto.
• Insignificante: Inconveniencia más molesta por su fácil resolución que por el
problema que causa.
En las siguientes páginas se puede encontrar, de la Tabla 12 a la Tabla 14, los riesgos
catastróficos, serios y tolerables, en ese orden y con sus probabilidades de suceder siguiendo
el código de colores previo.
61
TIPO DE
RIESGO POSIBLE RIESGO PROBABILIDAD GRAVEDAD
Herramientas
Pérdida completa del
entorno de trabajo (PC
queda inoperable)
Baja Catastrófico
Tecnología
Fallos de hardware (algún
componente del PC deja de
funcionar repentinamente)
Baja Catastrófico
Pérdida de los datos
almacenados Baja Catastrófico
Personales Abandono del proyecto Muy baja Catastrófico
Enfermedad/dolencia grave Muy baja Serio/Catastrófico
Organización
Mala distribución del
esfuerzo entre el proyecto
teórico y el de código
Moderada Catastrófico
No ceñirse a la
metodología Baja Catastrófico
Estimación
Retraso de una tarea crítica Moderada Catastrófico
Coste temporal del
proyecto superior al
estimado
Baja Catastrófico
Fallar a identificar una
tarea crítica Baja Catastrófico
Requerimientos
Imposibilidad de
implementar uno o varios
requerimientos
Moderada Catastrófico
Tabla 12. Riesgos catastróficos. Fuente: realización propia.
62
TIPO DE
RIESGO POSIBLE RIESGO PROBABILIDAD GRAVEDAD
Herramientas
Conflictos con Git Alta Serio
Caída de los servidores de
los servicios/herramientas
empleadas
Baja Serio
Cambio en las licencias de
los programas utilizados Muy baja Serio
Tecnología
Hardware insuficiente
(imposibilidad del hardware
para saciar los requisitos
del software)
Baja Serio
Personales
Padecer estrés/depresión
debido a la carga de trabajo Alta Serio
Falta de motivación Baja Serio
Formación insuficiente Baja Serio
Organización
No contabilizar el tiempo
dedicado al proyecto
(tiempo y nombre de la
tarea)
Alta Serio
Mala subdivisión de tareas
(no dividir bien las tareas
en problemas más sencillos
o dividirlas sin considerar
unidades lógicas)
Moderada Serio
Mala distribución de las
tareas en los hitos
(sobrecarga de trabajo, falta
de trabajo, empezar tareas
que requieren de otras
previas…)
Moderada Serio
No ceñirse a las tareas
establecidas para cada hito Muy baja Serio
Estimación Infraestimación de una
tarea Moderada Serio
Requerimientos
Mala
identificación/descripción
de uno o varios
requerimientos
Moderada Serio
Cambios drásticos en uno o
más requerimientos
(incluyendo la adición o la
eliminación)
Baja Serio
Otros
Viaje a Irlanda para visitar
a la hermana del
desarrollador que está allí
de erasmus.
Muy alta Serio
Tabla 13. Riesgos serios. Fuente: realización propia.
63
TIPO DE
RIESGO POSIBLE RIESGO PROBABILIDAD GRAVEDAD
Tecnología
Problemas con el
entorno de trabajo
(sistema operativo no
responsivo, SO no
reconoce las unidades
de almacenamiento…)
Alta Tolerable/Serio
Problemas al pasar los
datos de un programa a
otro
Alta Tolerable
Problemas con la
conexión a Internet Moderada Tolerable
Personales
Padecer
estrés/depresión debido
a causas externas al
proyecto
Moderada Tolerable
Problemas externos al
proyecto Baja Tolerable
Citas médicas Baja Tolerable
Enfermedad/dolencia
leve Baja Tolerable
Estimación
Sobreestimación de una
tarea Moderada Tolerable
Introducir una tarea
innecesaria Baja Tolerable
Requerimientos Cambios en uno o más
requerimientos Moderada Tolerable
Tabla 14. Riesgos tolerables. Fuente: realización propia.
64
5.2.3 Planificación
Como es inevitable que los riesgos afecten al proyecto de una forma u otra, a
continuación, en este apartado se aportaran, ordenadas por categorías de la Tabla 15 a Tabla
22, una estrategia para enfrentarse a estos y dentro de esta estrategia se considerarán, siempre
que sea posible, tres actitudes frente al riesgo según el estado de este:
• Prevención: el riesgo está aún por suceder, por lo que se tratará de evitar que suceda
o minimizar las probabilidades de lo haga.
• Minimización: el riesgo ya ha sucedido, por lo que se intentará disminuir su impacto
en el proyecto en la medida de lo posible.
• Plan de contingencia: el riesgo está sucediendo y no es posible minimizar su
impacto, por lo que se deberá de aplicar un plan de acción que considera el peor
escenario posible.
TIPO DE
RIESGO POSIBLE RIESGO ESTRATEGIA
Herramientas
Pérdida completa del
entorno de trabajo
(PC queda inoperable)
-Prevención: Cuidar del PC como si
fuera un hijo.
-Plan de contingencia: Buscar otro
entorno de trabajo como podría ser un
portátil.
Conflictos con Git
-Prevención: Realizar el procedimiento
adecuadamente y con conocimiento de
causa.
-Minimización: Utilizar las herramientas
de Git para solucionar el problema.
-Plan de contingencia: Arreglar de
forma manual el repositorio de Git.
Caída de los
servidores de los
servicios/herramientas
empleadas
-Minimización: Trabajar lo que se pueda
sin las herramientas hasta que vuelvan a
estar disponibles.
-Plan de contingencia: Crear una
versión propia y local de las
herramientas/servicios.
Cambio en las
licencias de los
programas utilizados
-Prevención: Disponer de alternativas
para los programas
-Minimización: Usar las alternativas.
-Plan de contingencia: Adquirir de
forma lícita el software requerido.
Cierre inesperado del
programa o
programas
-Minimización: Realizar guardados
periódicos y evitar lo que pueda causar
los cierres.
-Plan de contingencia: Cambiar de
programa. Tabla 15. Estrategias para los riesgos de Herramientas. Fuente: realización propia.
65
TIPO DE
RIESGO POSIBLE RIESGO ESTRATEGIA
Tecnología
Fallos de hardware (algún
componente del PC deja de
funcionar repentinamente)
-Prevención: Cuidar bien del
hardware.
-Minimización: Prescindir de la
pieza estropeada si es posible o
repararla.
-Plan de contingencia: Adquirir
nuevo hardware.
Pérdida de los datos
almacenados
-Prevención: Realizar copias de
seguridad en la nube
periódicamente.
-Minimización: Recuperar los
datos más recientes de dónde sea
posible.
-Plan de contingencia:
Reelaborar los datos perdidos.
Hardware insuficiente
(imposibilidad del hardware
para saciar los requisitos del
software)
-Minimización: Buscar la
configuración que permita el
trabajo.
-Plan de contingencia: Adquirir
hardware más potente.
Problemas con el entorno de
trabajo (sistema operativo no
responsivo, SO no reconoce
las unidades de
almacenamiento…)
-Prevención: Cuidar bien del
entorno de trabajo y no hacer
experimentos que puedan
perjudicarlo.
-Minimización: Aplicar arreglos
temporales o métodos de
circunvalación.
-Plan de contingencia:
Reinstalar el SO.
Problemas al pasar los datos
de un programa a otro
-Prevención: Saber el proceso y
llevar cuidado de llevarlo a cabo
bien.
-Minimización: Identificar el
problema y resolverlo con
celeridad.
-Plan de contingencia: No pasar
los datos, en su lugar elaborarlos
en la otra aplicación desde cero.
Problemas con la conexión a
Internet
-Prevención: Pagar al ISP.
-Minimización: Buscar otro
punto de acceso o trabajar sin
conexión.
-Plan de contingencia:
Reestructurar el proyecto para no
depender de servicios online. Tabla 16. Estrategias para los riesgos de Tecnología. Fuente: realización propia.
66
TIPO DE
RIESGO POSIBLE RIESGO ESTRATEGIA
Personales
Abandono del proyecto
-Prevención: Mantener la
motivación.
-Plan de contingencia: Es el peor
escenario posible, la única opción
es recuperar la motivación de
alguna forma esperando no haber
perdido mucho tiempo, realmente
poco se puede hacer.
Enfermedad/dolencia grave
-Prevención: Mantener hábitos
saludables.
-Minimización: Reducir
considerablemente la carga de
trabajo hasta estar en condiciones.
-Plan de contingencia:
Reestructurar los hitos para lograr
el mínimo necesario o congelar el
proyecto hasta recuperarse.
Padecer estrés debido a la
carga de trabajo
-Prevención: Realizar actividades
de ocio para complementar a las de
trabajo.
-Minimización: Reducir
temporalmente las horas de trabajo
semanales.
-Plan de contingencia: Recurrir a
un especialista.
Falta de motivación
-Prevención: Mantener un buen
equilibrio entre trabajo y ocio para
no quemarse.
-Minimización: Engañarse a uno
mismo para seguir motivado
(aparentemente funciona).
-Plan de contingencia: Recurrir a
un especialista o recibir apoyo
moral de familiares y amigos.
Formación insuficiente
-Minimización: Investigar y
adquirir el conocimiento
estrictamente necesario para
continuar.
-Plan de contingencia: Modificar
o eliminar la parte de la que se
carece conocimiento o sustituirla
por una de la que sí. Tabla 17. Estrategias para los riesgos Personales, parte 1. Fuente: realización propia.
67
TIPO DE
RIESGO POSIBLE RIESGO ESTRATEGIA
Personales
Padecer estrés debido a causas
externas al proyecto
-Prevención: Realizar
actividades de ocio para
complementar a las de trabajo.
-Minimización: Reducir
temporalmente las horas de
trabajo semanales.
-Plan de contingencia:
Recurrir a un especialista.
Problemas externos al proyecto
-Prevención: Procurar evitar
que los problemas externos al
proyecto afecten a este.
-Minimización: Priorizar o el
proyecto o la resolución del
problema.
-Plan de contingencia:
Solucionar el problema con la
mayor celeridad y ajustar el
horario de trabajo para
compensar el tiempo perdido.
Citas médicas
-Prevención: Procurar no
necesitarlas.
-Minimización: Reestructurar
el horario de trabajo para
acomodar la inconveniencia.
-Plan de contingencia:
Retrasar las tareas o comunicar
una baja médica.
Enfermedad/dolencia leve
-Prevención: Mantener
hábitos saludables.
-Minimización: Reducir la
carga de trabajo hasta estar en
condiciones.
-Plan de contingencia:
Planear el siguiente hito
teniendo en cuenta el nuevo
impedimento.
Falta de creatividad
-Prevención: Mantener una
mente activa en continua
búsqueda de soluciones a
problemas imaginarios.
-Minimización: Posponer las
tareas creativas y reservarlas
para momentos de inspiración.
-Plan de contingencia:
Recurrir a psicotrópicos. Tabla 18. Estrategias para los riesgos Personales, parte 2. Fuente: realización propia.
68
TIPO DE
RIESGO POSIBLE RIESGO ESTRATEGIA
Organización
Mala distribución del
esfuerzo entre el
proyecto teórico y el de
código
-Prevención: No olvidar que el
resultado constituye solo un 10%.
-Minimización: Pausar el proyecto de
código y volver al teórico
-Plan de contingencia: Congelar el
proyecto de código y no volver hasta
que lo que quede del teórico dependa
del de código.
No ceñirse a la
metodología
-Prevención: Ceñirse a la metodología
como si fuera un credo.
-Minimización: Identificar dónde se
está saliendo de la metodología y
rectificar.
-Plan de contingencia: Detener el
desarrollo y reiniciarlo aplicado la
metodología.
No contabilizar el
tiempo dedicado al
proyecto (tiempo y
nombre de la tarea)
-Prevención: Recordar poner el
cronometro.
-Minimización: Poner el cronometro
y añadir una estimación del tiempo ya
empleado.
-Plan de contingencia: Elaborar un
script que inicie el cronometro cada
vez que se toque el ordenador y que se
deba parar manualmente.
Mala distribución de las
tareas en los hitos
(sobrecarga de trabajo,
falta de trabajo, empezar
tareas que requieren de
otras previas…)
-Prevención: Realizar varias
revisiones antes de definir una
iteración.
-Minimización: Reestructurar la
iteración y adaptarse al nuevo plan.
-Plan de contingencia: Detener la
iteración y empezarla de nuevo con el
trabajo correcto
Mala subdivisión de
tareas (no dividir bien
las tareas en problemas
más sencillos o
dividirlas sin considerar
unidades lógicas)
-Prevención: Desgranar los problemas
de varias maneras
-Minimización: Desgranar los
problemas según surjan.
-Plan de contingencia: Detener la
tarea e invertir tiempo en despiezarla.
No ceñirse a las tareas
establecidas para cada
hito
-Prevención: Solo realizar las tareas
establecidas en cada hito.
-Minimización: Terminar o pausar la
tarea y centrarse en las presentes en el
hito.
-Plan de contingencia: Abandonar la
tarea y volver a las establecidas al
hito. Tabla 19. Estrategias para los riesgos de Organización. Fuente: realización propia.
69
TIPO DE
RIESGO POSIBLE RIESGO ESTRATEGIA
Estimación
Retraso de una tarea crítica
-Prevención: Aplicar
correctamente las prioridades.
-Minimización: Aplicar una
prioridad especial y empezar
por la tarea
-Plan de contingencia:
Reestructurar los hitos para
completar la tarea crítica lo
antes posibles.
Coste temporal del proyecto
superior al estimado
-Prevención: Gestionar
eficientemente el tiempo.
-Minimización: Eliminar
tareas menos prioritarias.
-Plan de contingencia:
Posponer la entrega del
proyecto con un mensaje en
fondo amarillo.
Fallar al identificar una tarea
crítica
-Prevención: No fallar a
identificar las tareas críticas.
-Minimización: Añadir
rápidamente la tarea al backlog
y ubicarla en su hito
correspondiente.
-Plan de contingencia: Añadir
la tarea al hito y ponerse a
trabajarla inmediatamente.
Infraestimación de una tarea
-Prevención: Procurar evaluar
bien las tareas.
-Minimización: Desviar
tiempo de otra tarea menos
relevante a esta.
-Plan de contingencia:
Reestructurar el hito para
acomodar a la tarea siempre y
cuando está sea crítica.
Sobreestimación de una tarea
-Prevención: Procurar evaluar
bien las tareas.
-Minimización: Dedicar el
tiempo sobrante a otra tarea.
Introducir una tarea innecesaria
-Prevención: Al introducir una
tarea plantearse como afectaría
su ausencia.
-Minimización: Eliminar la
tarea y reasignar su tiempo a
otra de igual prioridad. Tabla 20. Estrategias para los riesgos de Estimación. Fuente: realización propia.
70
TIPO DE
RIESGO POSIBLE RIESGO ESTRATEGIA
Requerimientos
Imposibilidad de
implementar uno o varios
requerimientos
-Minimización: Dejar para el final
por si se pudiera implementar
entonces.
-Plan de contingencia: Eliminar el
requerimiento a menos que sea uno
crítico, en cuyo caso se habrá de
modificar y/o adaptar para hacer
posible su implementación.
Mala
identificación/descripción
de uno o varios
requerimientos
-Prevención: Procurar analizar los
requerimientos de forma sensata
-Minimización: Cambiar la
descripción/ identificar el
requerimiento.
Cambios drásticos en uno
o más requerimientos
(incluyendo la adición o
la eliminación)
-Prevención: Procurar evitar la
incertidumbre en la definición de los
requerimientos.
-Minimización: Actualizar las
prioridades de desarrollo para
satisfacer los nuevos cambios.
-Plan de contingencia: Reevaluar la
prioridad de los requerimientos y ver
si hay que eliminar alguno.
Cambios en uno o más
requerimientos
-Prevención: Procurar evitar la
incertidumbre en la definición de los
requerimientos.
-Minimización: Modificar el/los
requerimiento/s.
-Plan de contingencia: Eliminar
el/los requerimiento/s si fuera
posible, si no, priorizarlos por
encima de otros. Tabla 21. Estrategias para los riesgos de Requerimientos. Fuente: realización propia.
TIPO DE
RIESGO POSIBLE RIESGO ESTRATEGIA
Otros
Viaje a Irlanda para
visitar a la hermana del
desarrollador que está allí
de erasmus.
-Minimización: Intentar teletrabajar
o leer libros relevantes para el
proyecto.
-Plan de contingencia: Recuperar el
tiempo del proyecto de los días de
descanso y trabajar horas extra el
resto de los días. Tabla 22. Estrategias para los riesgos no clasificados. Fuente: realización propia.
71
5.2.4 Monitorización y control de riesgos
Es necesario poder identificar cuándo un riesgo está a punto de suceder para así poder
aplicar alguna de las estrategias anteriores, por eso en la tabla siguiente se muestran distintos
identificadores potenciales que permitirán detectar con antelación los riesgos.
TIPO DE RIESGO IDENTIFICADOR
Tecnología
Problemas con el PC más frecuentes de lo habitual.
El PC es más lento de lo habitual.
El PC presenta comportamientos anómalos.
Organización El trabajo se amontona o no hay aparente progreso.
Baja productividad
Herramientas Las herramientas dificultan el trabajo en lugar de facilitarlo.
Requerimientos
La suma de los requerimientos no cumple con los objetivos del
proyecto.
Al trabajar en un requerimiento se percibe que no está muy
ajustado a lo que se necesita/ se quiere.
Estimación Falta tiempo para unas tareas y/o sobra para otras.
Se está constantemente reajustando tareas.
Personales Se está perdiendo el foco de atención del proyecto. Tabla 23. Riesgos con su correspondientes identificadores potenciales. Fuente: realización propia.
5.2.5 Revisión
Como se habrá podido observar, aparece un riesgo escrito en color verde. Este riesgo
fue añadido posteriormente a la realización del documento y sirve como ejemplo del proceso
iterativo de la gestión de riesgos.
En un principio no se había considerado en el documento la posibilidad de un viaje, pero
cuando se hizo inminente el hecho de que no se iba a poder trabajar durante 5-6 días fue
necesario reorganizar el trabajo y optimizar el tiempo de trabajo disponible para minimizar
el impacto. Además para minimizar aún más el posible impacto también se buscaron unas
lecturas interesantes que contribuyeran (y contribuyen) al desarrollo del proyecto. De esta
manera se consiguió que el proyecto no fuera muy afectado por el imprevisto y ahora
además, existe una referencia de actuación para una futura situación similar.
Es muy probable que este apartado se vaya modificando, añadiendo nuevas circunstancias y
explicándolas. Con esto queda demostrado que el documento de gestión de riesgos es, en
efecto, un documento orgánico.
72
5.3 Análisis DAFO
Incluso si no es la finalidad de este proyecto, el ámbito comercial representa un aspecto
muy importante ya que con él se puede medir el éxito del proyecto. Por eso resulta muy
interesante realizar un análisis DAFO ya que mediante este es posible comparar la propuesta
del proyecto con las ya existentes. Pero antes de comenzar con el análisis se va a describir
qué es un análisis DAFO para así poder entender por qué es relevante para este proyecto.
DAFO (a veces FODA o SWOT, por sus siglas en inglés) es el acrónimo de Debilidades,
Amenazas, Fortalezas y Oportunidades. El análisis de estos factores permite posicionar, de
forma más o menos realista, un negocio en su mercado (infoautónomos, 2021). Esto permite
elaborar estrategias de negocio más adecuadas a la situación y posición del negocio,
favoreciendo que prospere en el mercado. Otro aspecto relevante es la discriminación entre
factores externos y factores internos. Identificar los factores que afectan desde dentro y los
que afectan desde fuera es identificar qué factores se pueden controlar y cuáles no.
Imagen 32. Diagrama de un análisis DAFO (Dirección General de Industria y de la Pequeña y Mediana Empresa,
2020).
73
Con esa información es posible centrar los esfuerzos en cambiar lo que se puede para
adaptarse a lo que, por el momento, resulta inalterable.
Previamente se han mencionado los términos que constituyen a un análisis DAFO, sin
embargo, estos solo son términos en un acrónimo elegante y buen sonante a menos que se
expliquen a qué hacen referencia o qué significan en el contexto.
Por un lado, las debilidades constituyen las limitaciones en la capacidad de desarrollo del
negocio debido a las características internas de este. Las amenazas representan a todos los
factores externos que hacen peligrar la viabilidad del negocio o representan un obstáculo a
la estrategia empresarial. A si mismo las oportunidades son los factores externos que
benefician al desarrollo y crecimiento del negocio. Y por último las fortalezas, que
corresponden a las ventajas del negocio frente a la competencia (infoautónomos, 2021).
A continuación se presenta el análisis DAFO de este proyecto:
• Debilidades:
o Escasez fuerza de trabajo: solo un desarrollador y con escasas aspiraciones
para ampliar la plantilla, el tiempo de desarrollo se prevé muy largo y la carga
de trabajo susceptible a causar la pausa o el abandono del proyecto.
o Falta de renombre: maldición de todos los estudios y desarrolladores indies,
es la falta de clientes, que acudan por confianza debido al escaso o nulo
porfolio, y la necesidad de crearlos.
o Marketing: en este caso la falta de, las herramientas para hacer (buen)
marketing son las redes sociales y un buen posicionamiento en los motores
de búsqueda mediante técnicas de SEO.
o Presupuesto: limitado por no decir inexistente, sin este es imposible ampliar
la fuerza de trabajo o mejorar el equipo (actualmente un tostador muy caro).
Trabajar por amor al arte es la opción más viable.
74
• Fortalezas:
o Coste de desarrollo: en su estado actual, el proyecto apenas requiere de
recursos para continuar su desarrollo.
o Modelo de desarrollo: este modelo tolera y fomenta la retroalimentación con
la comunidad, de manera que es posible implementar y probar las sugerencias
de los jugadores. El contacto cercano y la búsqueda de las críticas de la
comunidad resulta en el mutuo beneficio.
o Concepto sólido: un juego muy simple y con mecánicas muy fáciles de
aprender, la combinación perfecta para el jugador casual y la ideal para el que
busca amasar gran técnica y habilidad.
o Propuesta renovadora: pequeños cambios en aspectos del género que no
alteran su naturaleza, pero que cambian considerablemente la experiencia de
juego. Es igual (que los títulos ya existentes) pero no es lo mismo.
o Modelo de negocio: se puede adaptar según las necesidades y generalmente
se busca favorecer al cliente. Dicho esto la opción más viable es el
crowdfunding. También la inicial inclinación por permitir contenido creado
por la comunidad favorece la persistencia de esta.
• Amenazas:
o Juegos similares: desarrollados por equipos más grandes y con mayor
disponibilidad de recursos, acapararán mayor audiencia la cual se volverá
más reacia a probar otros títulos de peor calidad (dígase en vías de desarrollo).
o Saturación del mercado: alta probabilidad de sufrir del efecto “shooter
genérico número 87” el cual puede desinteresar sistemáticamente a un
público cansado de juegos FPS.
o Incertidumbre del mercado: el gran público es muy voluble en cuanto a sus
gustos, un género puede tener un gran éxito porque las preferencias de los
jugadores cambian radicalmente (y en una dirección imprevisible). El éxito
de un lanzamiento va ligado al momento de este.
o Elitismo del mercado: el público espera un producto completamente
funcional y pulido, la velocidad de desarrollo puede hacer que el público
potencial pierda el interés en el producto por falta de contenido.
o “Espionaje” industrial: es posible que otra empresa se “inspire” en la idea
y la desarrolle más rápidamente, convirtiendo al proyecto en un “rip off” del
otro juego.
75
o Inquietante auge de los looter shooters: actualmente existe una creciente
tendencia por los looter shooters lo cual puede desviar la atención del
proyecto.
o Ámbito judicial: constituirse como empresa y tributar en Andorra para
acabar en la lista de niños malos de la agencia tributaria.
• Oportunidades:
o Mercado: en auge y con buenas perspectivas para el futuro, es uno de los
sectores que más crece cada año y de los más prósperos.
o Desgaste de las grandes empresas: existe cierto descontento generalizado
con las grandes empresas, las cuales casi ni se molestan en ocultar que la
calidad del producto no es tan relevante como el beneficio que pueda generar.
Esto también se traduce en la falta de propuestas innovadoras o genuinas, es
más rentable ir a lo seguro, lo que funcionó un año funcionará el siguiente
con mejores gráficos.
o Comodín del indie: al tratarse de un desarrollo independiente es más fácil
justificar retrasos o problemas y generalmente el público puede gastar más
paciencia con este tipo de desarrolladoras. Sin embargo, no es algo de lo que
se pueda abusar, pues muy fácil y rápidamente puede resultar
contraproducente.
o Costes de distribución: gracias a la era tecnológica es posible ahorrar
grandes cantidades mediante la distribución virtual.
El análisis DAFO irá evolucionando conforme los elementos internos y externos cambien.
También es interesante realizar uno de estos análisis a las empresas competidoras, lo cual
permitirá ubicar a la competencia en el mercado y encontrar huecos que aprovechar.
76
5.4 Análisis de requisitos
En este apartado se van a identificar los requisitos del proyecto software. Dentro de
estos podemos diferenciar entre requisitos funcionales y no funcionales. Los primeros
definen las funciones del sistema y los segundos definen las características del
funcionamiento.
A continuación se presenta el formato que se va a emplear para identificar los requisitos.
Identificador Nombre Descripción
Código numérico
único para
identificar al
requisito (Id.)
Resumen del requisito Definición y explicación del requisito
5.4.1 Requisitos funcionales
Definen una función o un componente de un sistema. Estos concretan las tareas que
describen en qué se supone que debe lograr el sistema. También deben especifican
concretamente el comportamiento que lleva a un resultado concreto, según la entrada que se
aporte al sistema (Fulton & Vandermolen, 2017).
Id. Nombre Descripción
RF-1 Controlar el personaje El jugador debe poder moverse con el control del
personaje.
RF-2 Interactuar con recogibles Al colisionar con un recogible este otorgará algo al
jugador (salud, armadura, munición, etc.).
RF-3 Disparar El jugador debe poder disparar su arma siempre que
tenga munición de esta.
RF-4 Dañar a enemigos Las armas deben poder dañar a los enemigos.
RF-5 Puntuar Eliminar a un enemigo otorga puntos.
RF-6 Mostrar HUD El juego debe indicar visualmente al jugador su
estado y el de la partida.
RF-7 Cambiar entre armas El jugador debe poder cambiar entre las armas que
tenga.
RF-8 Cargar menú principal El juego debe poder mostrar el menú principal.
RF-9 Cargar partida El juego debe poder cargar un mapa y un modo de
juego para el jugador.
RF-10 Mostrar menú de pausa El jugador debe poder abrir el menú de pausa e
interactuar con él.
RF-11 Abandonar partida El jugador debe poder abandonar la partida y el juego
debe poder abandonarla sin interrumpirse
RF-12 Morir El jugador debe morir, cuando sus puntos de salud se
reduzcan a 0.
RF-13 Terminar partida La partida debe finalizar bajo ciertas condiciones,
mostrando la tabla de puntuaciones.
RF-14 Cerrar aplicación El juego debe poder cerrarse a merced del jugador. Tabla 24. Requisitos funcionales
77
5.4.2 Requisitos No Funcionales
Estos requisitos definen la arquitectura del sistema (Chen, Babar, & Nuseibeh, 2012)
imponiendo limitaciones en el diseño o en la implementación o en ambos. Estos se centran
en aspectos más centrados en lo que debe ser el sistema, como sus cualidades, la calidad de
este, la portabilidad, etc.
Id. Nombre Descripción
RNF-1 Escalabilidad del sistema
El sistema debe estar preparado y diseñado para
potenciales crecimientos a medida que se invierten
recursos en este.
RNF-2 Extensibilidad del juego El juego estará diseñado para que añadir
características o contenido resulte fácil y rápido.
RNF-3 Usabilidad de la aplicación
Los usuarios deben poder interactuar con la
aplicación de forma intuitiva, o en su defecto: la
aplicación es sencilla de operar.
RNF-4 Reusabilidad
Los componentes de la aplicación deben diseñarse
para que puedan ser usados (para otro fin) incluso si
se descartan.
RNF-5 Rendimiento del juego El juego debe poder hacer un uso eficiente de los
recursos de la máquina en la que se ejecuta.
RNF-6 Documentación del sistema
Debe quedar constancia escrita de las decisiones de
desarrollo y diseño, así como de explicaciones y
aclaraciones del código en la medida de lo posible.
RNF-7 Seguridad y privacidad
El sistema debe garantizar la seguridad de los
usuarios así como de mantener sus datos e
información protegidos/anónimos.
RNF-8 Facilidad de modding
El contenido del juego debe ser fácil de modificar
por los usuarios, añadir/cambiar modelados,
texturas, etc.
RNF-9 Eficacia del juego El juego debe satisfacer lo establecido en el GDD.
Tabla 25. Requisitos no funcionales.
78
6. Documento de diseño del videojuego (GDD)
Como en todo proyecto software, es necesario un documento que defina qué hace
dicho software. Para este caso, el documento recibe el nombre de Documento de diseño del
juego o GDD por sus siglas en inglés de Game Design Document y en él se detallarán todos
los aspectos de diseño del juego. Desde aspectos triviales como el género del videojuego
hasta otros más complejos como son las mecánicas. Este documento sirve como registro de
las decisiones de diseño tomadas y como referente las para futuras.
6.1 BetterNamePending
BetterNamePending es un FPS Arena Shooter en el cual los jugadores se enfrentan
entre sí en frenéticos combates a muerte en múltiples modos de juego.
6.1.1 Historia del juego
Este realmente no es un tipo de juego que necesite historia por lo que está se irá
creando a medida que haga falta para justificar ciertos aspectos del juego. Como para
justificar por qué los jugadores se han de enfrentar o porqué reaparecen tras morir. Sin
embargo, esto no supone que se vaya a dejar de lado este aspecto, ya que crear un mundo
con el que los jugadores puedan simpatizar o entender de alguna manera siempre causa
buenas impresión con respecto a este. Por eso lo que se pretende es dar pinceladas del mundo
mediante lore explícito en por ejemplo descripciones de objetos o de forma implícita con
diseños de mapas o personajes por ejemplo. De esta manera la historia siempre queda en
desarrollo y a libre interpretación, por lo que también resulta expandible. A continuación se
explica el mundo detrás del videojuego.
El juego se desarrolla en un futuro distópico de una realidad alternativa en el que la
humanidad casi ha alcanzado el culmen de la existencia como especie. Sin embargo, la
civilización se enfrenta ahora a un inminente cataclismo debido a la falta de recursos para
satisfacer a una siempre creciente población y a las continuas guerras que, además, arrasan
los terrenos habitables. Por ello, la diferencia entre clases se ha vuelto abismal y el valor
de la vida humana se ha degradado a excepción claro, de la alta sociedad. Este selecto
grupo de personas posee grandes riquezas y controla y condiciona a empresas y naciones,
su modo de vida consiste en el lujo, el vicio y el exceso sin reparar en el coste o en las
consecuencias.
79
Precisamente fue uno de estos individuos quien creó el programa de televisión, para el
entretenimiento de sus semejantes, que se conoce como betternamepending, que consiste en
un macabro juego en el que personas, que aspiran a una vida mejor, se enfrentan entre sí
en combates a muerte.
Bajo la promesa de fama y fortuna, los concursantes pagan su derecho a participar en los
combates, sus vidas no corren peligro realmente ya que la avanzada tecnología biomédica
permite crear múltiples clones a los que transferir su conciencia, aunque los costes de este
proceso corren a cuenta del concursante. Debido a la fama del programa, muchas empresas
buscan publicitar sus productos o servicios ofreciéndoselos a los participantes para que los
muestren en sus combates, convirtiendo así al programa en uno de los negocios más
lucrativos de la historia.
Los jugadores encarnan a una de estas personas anónimas, que van desde el trabajador medio
endeudado con las mafias, pasando por soldados retirados con problemas psicológicos y
hasta criminales en el corredero de la muerte que participan por una oportunidad de redimir
sus almas.
6.2 Temática y estética
El juego tendrá una temática más bien futurista distópica y su estética combinará
distintos elementos del ciberpunk, industrialismo, neo militarismo, alta tecnología (high-
tech) y eco-arquitectura, entre otros, con fin de enriquecer la percepción del mundo y
expresar la razón de ser de este. Lo importante no es la disparidad entre los elementos sino
su agrupación y pertenencia a las distintas “facciones” del mundo. Más adelante se
encuentran las paletas y las normas de diseño para cada estilo de elemento.
Por otro lado un aspecto importante a comentar es el diseño de los personajes, estos serán
voluminosos y “rectangulares” ya sea por sus ropajes o armadura. El motivo de esto es más
bien funcional ya que se busca que estos tengan grandes y rectangulares hit boxes para que
sean más fáciles de identificar y de acertar.
También se pretende darle al juego una doble personalidad, por un lado será serio y realista
mientras que por el otro será desenfadado y absurdo. La intención de esto es expresar la
ambivalencia de una civilización decadente, empezando por los protagonistas en sí, y darle
al jugador la posibilidad de crear situaciones que sirvan como alivio cómico a su merced.
80
En todo caso las dos personalidades estarán presentes pero alguna de ellas será ligeramente
predominante, según el momento dado.
6.3 Jugabilidad
La jugabilidad se puede definir como la experiencia de juego percibida por el jugador
y que está influenciada por distintos atributos y propiedades (González Sánchez, Padilla Zea,
& Gutiérrez, 2009). Estos atributos se pueden resumir en satisfacción, learnability
(capacidad de aprendizaje), eficacia, inmersión, motivación, emoción y socialización. Cada
uno de estos, a su vez, utiliza distintos conceptos o atributos para su medición, sin embargo,
es la suma del todo la que realmente define la experiencia de juego. Y es debido a esto último
que resultaría difícil exponer los atributos de uno en uno sin solapar conceptos y repetir las
mismas cosas una y otra vez. Dicho esto, a continuación se describe la jugabilidad teniendo
en cuenta lo mencionado anteriormente.
Para empezar, las mecánicas básicas del juego son triviales de aprender pero es debido a esta
simplicidad que masterizarlas llevará su tiempo y esfuerzo. La curva de aprendizaje empieza
a crecer logarítmicamente una vez aprendidas todas las mecánicas del juego. Además el resto
de las mecánicas se construyen sobre estas básicas, lo que permite al jugador avanzar a su
ritmo. Por eso un mayor domino de las mecánicas supone nuevas formas de divertirse dentro
del juego y no son estrictamente necesarias para obtener la victoria. De manera que
simplemente jugando por jugar se puede aprender y mejorar, aparte de que, indirectamente,
se incentiva al jugador a aprender y a mejorar eliminando así la potencial frustración por la
falta de habilidad, pues siempre hay algo que aprender.
Por otro lado, si bien es necesario que existan ganadores y perdedores, esto es un requisito
sine qua non única y exclusivamente para llegar al final del juego. El jugador en ningún
momento estará ni obligado ni presionado a ganar puesto que la diversión reside en
demostrar talento y habilidad o en su defecto, en el proceso de obtención de la victoria. Esto
pretende eliminar el componente de decepción, o al menos mitigarlo. Así mismo e
irremediablemente, el juego causará frustración y especialmente a aquellos jugadores que se
lo tomen muy en serio (jugadores con actitudes muy competitivas). Sin embargo, esto es
algo natural en el proceso de aprendizaje y de juego además de tan inevitable como necesario
(Swink, 2008).
81
Otro aspecto importante es el balance. Mediante la edición de los distintos valores (de daño,
salud, armadura, tiempos, etc.) se pretende recompensar generosamente al jugador por
realizar bien las tareas y tomar la decisión acertada acorde con la situación. También el
balance constituye un importante elemento contra la frustración, pues la percepción de
“justicia” hace que el sentimiento de frustración se vuelva irracional y se deseche.
Intencionadamente no se va a entrar mucho en detalle en este aspecto, pero la intención es
que “hacer las cosas bien” sea satisfactorio a un nivel muy humano, por ejemplo: las armas
que causen mucho daño por disparo acostumbrarán a tener un sonido muy profundo al
disparar, anticipando la gravedad de los daños. Al acertar se mostrará por pantalla el daño
hecho acompañado del sonido indicador, levemente alterado para sonar más imponente. Este
tipo de satisfacción tiene la capacidad de ventilar grandes cantidades de frustración, ya que
la voluntad del jugador se está imponiendo y de forma muy efectiva.
Lo que tiene que ver esto último con lo anterior son las pautas de diseño en ese aspecto,
idealmente el TTK será siempre de más de 2 disparos y menos de 10, asumiendo un oponente
al 100% de salud y 0% armadura. De la misma manera, curarse y reabastecerse será igual de
sencillo e irán acompañados por sonidos y efectos visuales complacientes, acorde con la
inmediata necesidad del jugador que acaba de satisfacer.
Esto causará que las peleas se sientan más bien cortas, pero unido a los cortos períodos de
reaparición queda compensado. También, cada cierto un número de muertes el período de
reaparición se hará ligeramente más largo para que el jugador pueda rebajar su tensión y
tener un respiro “forzado”, también contribuyente a ventilar la decepción y la frustración.
Por otro lado, el movimiento basado en inercia hará que sea más fácil de predecir la siguiente
posición de un oponente. Esto junto con la ausencia casi total de acciones instantáneas o
impredecibles harán que el juego se perciba como más “justo”, que como ya se ha
mencionado antes, vuelve irracional la frustración. Así mismo las físicas serán similares a
las del mundo real, de esta manera su percepción será más natural. Gracias a esta cercanía al
mundo real, el jugador estará más de acuerdo con lo que suceda. Además, como nada sucede
sin “haber empezado a suceder”, el componente impredecible se reduce al oponente, lo cual
ya se daba por supuesto.
82
Pasando a otro tema, el jugador podrá realizar burlas en cualquier momento, dichas burlas
irán de hacer que el personaje haga alguna pose a que haga un bailecito cutre (manteniendo,
obviamente, el carácter desenfadado). Mientras que esto parece algo tóxico (que lo es) la
forma en la que se enfoca lo convierte en algo más bien absurdo. Por un lado, tras eliminar
a un oponente habrá una pequeña ventana de tiempo en la que realizar la burla forzará al
eliminado a verla, pero las burlas serán ininterrumpibles, dejando vulnerable al jugador y
dado que se trata de un juego más bien rápido, es muy probable que el jugador eliminado
vea la inminente muerte de su ejecutor. Esta justicia poética hace que el jugador que ha sido
eliminado enfoque positivamente su frustración pues su adversario no es invencible.
Como ya se ha mencionado antes, las burlas se podrán hacer en cualquier momento por lo
que a pesar de ser burlas, no tienen por qué usarse para tal propósito sino que se pueden
utilizar para la comunicación no verbal entre jugadores. Además algunas burlas serán
cooperativas de manera que cualquier otro jugador pueda unirse creando así, situaciones
absurdas en las que olvidarse de que va el juego. Estos pequeños alivios y la posibilidad de
crearlos en cualquier momento, otorgan a los mecanismos naturales de auto protección
contra la frustración en el cerebro una herramienta para mitigar las emociones negativas.
Por último, ragdolls. Si bien a muchos jugadores les puede resultar desagradable ver cómo
su avatar es brutalmente eviscerado, ver cómo sale catapultado de forma surrealista en una
torpe y macabra coreografía, estampándose en paredes y objetos hasta llegar al suelo, puede
resultar incluso más violento y cruel. Sin embargo, debido a la ausencia de vísceras, el
surrealismo fruto de un motor de físicas arrastrando un muñeco de trapo por el nivel y lo
absurdo de las posiciones graciosas en las que terminan los avatares, los ragdolls causan,
por el contrario, un efecto más cómico. Aunque también apelan al rechazo visceral natural
(valle inquietante), lo hacen de una forma más empática puesto que se alejan de la realidad
y toman una dirección más humorística. Por ello forman parte del conjunto de pequeños
alivios que rompen la monotonía del juego, ayudando así a los jugadores a tomarse la derrota
con algo de humor.
83
6.4 Mecánicas
La forma que tienen los jugadores de interactuar con el mundo virtual del juego es a
través de sus mecánicas. Estas definen qué puede hacer un jugador y cómo, son normas que
el jugador deberá aprender para relacionarse con el mundo del juego. Y si bien dichas normas
se exponen, a continuación, como posibilidades o libertades, hay que tener muy en cuenta
que la prioridad del sistema es definir que no puede hacer el usuario ya que, en realidad, las
normas sirven para poner límites a la libertad del jugador.
6.4.1 Movilidad
Como ya se ha mencionado previamente, el movimiento será tridimensional y tendrá
inercia. Lo cual supone que el avatar del jugador no se empieza a mover a máxima velocidad
de forma instantánea, sino que habrá un pequeño período de aceleración, o deceleración en
su caso. De manera que desplazarse lateralmente, por ejemplo, será más predecible y natural
pero sin percibirse lento o torpe. Otro aspecto importante es que no habrá forma de aumentar
la velocidad más allá del límite establecido salvo mediante fuerzas físicas (como explosiones
o gravedad). Así mismo, de normal, el jugador disfrutará de un poco de control aéreo, aunque
será posible incrementar dicho control agachándose y haciendo strafing (moverse
lateralmente). El jugador no podrá realizar un doble salto pero sí agacharse en el aire para
ganar altura.
6.4.1.1 Básico
El movimiento básico será en el plano horizontal, pulsar la tecla de movimiento
añadirá la aceleración en la dirección correspondiente pudiendo pulsarlas simultáneamente
en cualquier combinación. Si la combinación de las aceleraciones es 0, el personaje no se
moverá. Saltar añadirá un componente de aceleración vertical pero este no influirá en la
aceleración en el plano horizontal, a menos que se realice la técnica de Strafing en cuyo caso
si se podrá acelerar ligeramente por encima de la velocidad máxima.
6.4.1.2 Rocket jump
Rocket Jumping es una técnica que consiste en emplear la explosión de un cohete
para propulsarse a grandes alturas. A pesar de recibir el nombre de Rocket jump, este no
estará limitado a explosiones de cohetes, sino que cualquier explosión o proyectil que genere
una fuerza podrá emplearse para realizar Rocket Jump.
84
6.4.1.3 Strafing
Strafing en este contexto se refiere a la técnica que consiste en, mientras se está en el
aire, pulsar únicamente una de las teclas de movimiento lateral mientras se mueve la cámara
en esa misma dirección. Esto otorga gran control aéreo y permite acelerar por encima del
límite de velocidad. Pulsar la tecla de movimiento frontal sistemáticamente impide realizar
la técnica de Strafing.
6.4.2 Armas
Para las armas se implementará un novedoso sistema de variaciones que permitirá al
jugador cambiar entre variantes del mismo arma en cualquier momento. Para ello se
establecerá una arma “de stock” que defina la funcionalidad base del arma y luego las
variantes se comportarán de forma distinta y/o cambiarán la forma de usarla. Con esto se
podrá tener poca variedad de tipos de armas pero un buen surtido para escoger el tipo en sí.
Más adelante se explican los detalles. Por otro lado, a menos que se indique lo contrario, las
armas consumirán la munición directamente de las reservas del jugador. Estas se encontrarán
en el mapa y podrán ser recogidas por cualquier jugador, a excepción de las armas iniciales.
Respecto a esto último, cada jugador empezará con un arma melee y otra a distancia con las
que defenderse. Recoger un arma cuando ya se había adquirido recarga parte de su munición.
Cada arma tendrá su variante de “stock” la cual establecerá la naturaleza del arma y podrá
tener múltiples variantes alternativas. Estas variantes tendrán valores y comportamientos
modificados y además podrán afectar a otros valores del jugador de forma pasiva y mientras
están equipadas, como por ejemplo la velocidad de movimiento. También podrán tener
habilidades o propiedades especiales como los impactos críticos bajo ciertas condiciones o
absorción de vida tras realizar cierta cantidad de daño. Así mismo, estas alteraciones podrán
presentarse como un disparo secundario de manera similar a UT99. A todo esto hay que
mencionar que la alteración de los valores no ha de ser siempre positiva, las variantes deben
proporcionar una alternativa al modelo de stock, no ser directamente una mejora. Además,
las variantes podrán interactuar entre ellas (sinergias) para poder elaborar combinaciones y
estrategias. El jugador puede escoger, en cualquier momento, usar el arma de stock o una
variante de esta pero en el mapa solo habrá un recogible, que será el del arquetipo del arma
de manera que el recogible será el mismo pero cada jugador adquirirá una variante diferente.
Adicionalmente existirá la posibilidad de permitir una opción que aleatorice la variante que
se recoge. Por otro lado, cabe remarcar la ausencia de algúnn tipo de superarma o similar.
85
A continuación en la Tabla 26 se recogen las armas de “stock” con algunas de sus premisas
de diseño.
Melee -Super corta distancia
-Auto defensa
-Humillar/mostrar habilidad
Pistola -Semiauto, daño y alcance medio, media cadencia
Escopeta -Gran daño a corta distancia
-Castigar a oponentes que se acerquen
Ametralladora -Supresión
-Derretir armadura
-Poco daño, gran cadencia
Lanza granadas -Negación de área, daño medio/bajo
-Proyectil con parábola, retardo de explosión
Lanza cohetes -Gran daño en impactos directos, cadencia baja
-Proyectil con trayectoria recta, pequeña área de daño
Francotirador -Largo alcance
-Muy baja cadencia, gran daño Tabla 26. Premisas de diseño de las armas.
6.4.3 Salud y armadura
Todos los personajes tendrán los mismos valores de salud y armadura y no
dispondrán de ninguna habilidad o trato especial. Los valores máximos serán de 100 de salud
y 100 de armadura con posibilidad de sobrecargar la salud hasta 150. La salud sobrecargada
irá decayendo con el tiempo hasta llegar a 100. La armadura reducirá en ⅔ el daño recibido
• Salud: Su valor inicial será el máximo, 100. Será posible sobrecargarla hasta
150 pero el excedente decaerá a razón de 1Hp/s.
• Armadura: Su valor máximo es 100 y no será posible obtener un valor por
encima. Esta reducirá en 2/3 el daño recibido y se consumirá en el proceso.
Por otro lado no habrá efecto “shield gate”, es decir, si el daño excede lo que
la armadura puede absorber, el daño restante se hará a la salud en lugar de no
aplicarse.
• Daño: No habrá daño por caída. Y el daño por autolesión estará reducido en
un 33, 3̅% salvo donde se indique.
6.4.4 Recogibles
Se categoriza como recogible todos los objetos que puede recoger el jugador del
mapa, esto incluye salud, armadura, armas, munición, powerups y otros. Otros es una
categoría “cajón desastre” para futuras implementaciones. Como norma general, los
recogibles aparecerán sobre una plataforma que mostrará el tiempo que queda para que
aparezca el recogible al ternando con el icono del recogible, aunque cada tipo de recogible
tendrá su plataforma específica.
86
Además se hará uso de un código de colores llamativo para facilitar su distinción. Aunque
la información más importante acerca de los recogibles es lo que hacen y el tiempo que
tardan en reaparecer. A la hora de diseñar mapas no tienen por qué aparecer todos los
recogibles.
6.4.4.1 Salud
La salud aparecerá por el mapa en distintos formatos, tendrá un tiempo de reaparición
en función de la cantidad de salud que recupere (formato). También se ha contemplado la
posible existencia de efectos de estado/alterados que reduzcan la salud. En la Tabla 27 se
recogen los tipos de botiquines con sus valores más relevantes.
Tipo Curación T. Reaparición Sobre curación Efectos extra
Pequeño 15 HP Bajo Sí (10Hp) -
Mediano 35 HP Medio No Cura efectos de estado
Grande 75 HP Medio No Cura efectos de estado
Máximo 150 HP Largo Sí (50Hp) Cura efectos de estado Tabla 27. Tipos de botiquines con sus valores y efectos.
6.4.4.2 Armadura
La armadura funciona como una barra de salud adicional. Está también se encontrará
en distintos formatos y su tiempo de reaparición variará en función de la armadura que
otorguen. La funcionalidad de la armadura será reducir el daño recibido a la salud en ⅔
consumiéndose en el proceso. En la Tabla 28 se encuentran los tipos de armadura con sus
valores.
Tipo Armadura (pts.) T. Reaparición
Parche 5 Bajo
Placas 25 Bajo
Chaleco 50 Medio
Traje juggernaut 100 Largo Tabla 28. Tipos de armaduras con sus valores.
6.4.4.3 Munición y armas
Por un lado la munición solo se presentará en un formato y recargará munición de
todas las armas. La cantidad de munición recargada dependerá del tipo de arma y del arma
en sí. Además, su tiempo de reaparición será corto y aparecerán junto a otros recogibles,
adicionalmente en se encontrarán en relativa abundancia en los mapas.
87
Por otro lado los recogibles de las armas presentarán el icono del arquetipo del arma y
otorgarán al jugador el arma que tenga seleccionada. También recoger el arma cuándo ya se
ha adquirido otorgará un pequeño porcentaje de la munición máxima.
6.4.4.4 Powerups
Los powerups aparecerán el lugares de difícil acceso y/o concurridos. Su tiempo de
reaparición será muy largo y solo habrá uno o dos por mapa, aunque es posible que los
powerups roten, es decir, que no siempre aparezca el mismo en el mismo sitio. Además, una
vez recogidos por un jugador, empezará un contador que marca su duración, la cual variará
según el powerup pero será muy limitada en cualquier caso. A continuación se encuentra
una lista de los powerups.
Powerup Descripción Efecto Duración
(s)
Amplificador
de daño
Amplifica el daño del usuario en un
500%.
Las armas del jugador brillan
intensamente de color rojizo y
el jugador desprende un aura
roja que se proyecta en las
inmediaciones.
60
Regeneración
Otorga regeneración pasiva de salud
que regenera 10 HP/s + el porcentaje
de salud perdida. Puede causar sobre
curación.
Un aura verde junto con
cruces de salud del mismo
color emana del jugador. 45
Armadura
experimental
Otorga un 100% de reducción de
daño y vuelve al usuario inmutable
frente a las fuerzas físicas e inmune a
los efectos de estado (si ya padecía de
alguno, lo elimina).
La armadura del jugador brilla
de color azul intenso y
desprende luz de ese mismo
tono en las inmediaciones.
45
Camuflaje
activo
Vuelve casi invisible al jugador. Al
disparar el jugador pierde
parcialmente la invisibilidad y de
forma gradual se volverá más visible.
El cuerpo del jugador brilla de
color morado, con una
intensidad inversamente
proporcional al porcentaje de
invisibilidad
60
Overclock de
sistema
Triplica la cadencia de todas las
armas, su daño y la velocidad de
movimiento. Además otorga
regeneración de salud (5 HP/s)
Un aura de color amarillo
anaranjado junto con flechas
hacia arriba del mismo color
emana del jugador.
30
Munición
infinita
Otorga munición infinita a todas las
armas. Al terminar su duración deja
todas las armas al máximo de
munición
Las armas del jugador brillan
de color dorado y el jugador
emite pulsos en el suelo del
mismo color.
30
Tabla 29. Tabla de powerups.
88
6.4.5 Modos de juego
Un videojuego con un único modo de juego tiende a ser aburrido, por eso es ideal
diseñar varios modos que brinden un nuevo set de normas o un nuevo objetivo. Esto permite
mantener al juego fresco y proveer a los jugadores con nuevos desafíos y entretenimientos.
Así mismo, se pueden distinguir entre modos todos contra todos y por equipos. A
continuación se describen los modos de juego sin entrar en detalles como el número de
jugadores o el tiempo de partida, ese tipo de valores corresponden a un proceso de balance.
6.4.5.1 Modos free-for-all
Son los modos que premian la habilidad individual y en los que el objetivo principal
suele ser eliminar oponentes de forma indistinta.
6.4.5.1.1 Combate a muerte (Deathmatch)
Los jugadores se enfrentan entre sí con el objetivo de eliminar al mayor número de
adversarios posible. El ganador será el jugador que antes llegue al cupo de eliminaciones.
Básicamente el clásico infalible combate a muerte, no es nada novedoso pero tampoco pasa
de moda.
6.4.5.1.2 Último en pie (Last man standing)
Similar al combate a muerte pero con un número máximo de reapariciones por
jugador. El objetivo de este modo es ser el último jugador vivo, para ello cada jugador tiene
unas vidas limitadas que pierde con cada muerte. Además cada jugador reaparecerá cada vez
con todas las armas y algo de armadura, y a medida que vaya perdiendo vidas se incrementará
el valor de la armadura y sobre salud inicial. Otro aspecto importante es el robo de vidas:
eliminar a un jugador cuando no tiene vidas recompensará al jugador que lo ha eliminado
con una vida extra (no afecta a la cantidad de armadura y salud extra por vida).
A medida que los jugadores se vayan quedando sin vidas el mapa se irá quedando vacío. Por
eso cuando solo queden dos jugadores estos estarán marcados, es decir, podrán verse a través
de las paredes con tal de agilizar el fin de partida.
89
6.4.5.1.3 Torrente sanguíneo (Bloodrush)
En este modo los jugadores tendrán que gestionar un recurso especial al que se va a
denominar como energía. Esta se presenta como una barra que se va reduciendo a buen ritmo
y representa la capacidad del jugador para reaparecer. De manera que cuando la barra se
vacía por completo si el jugador es eliminado no podrá reaparecer. La forma de rellenar esta
barra es mediante eliminaciones. Para hacer las cosas más interesantes, cada cierta cantidad
de tiempo de incrementará la tasa de drenaje de energía, forzando a los jugadores a buscarse
entre sí para conseguir energía. Permanecer sin energía mucho tiempo (para una
indeterminada definición de “mucho”) herirá gradualmente al jugador pero nunca será letal.
De la misma forma y para evitar partidas muy largas entre pocos jugadores, cuando queden
menos de 5 jugadores estos serán marcados cuando se queden sin energía y cuando solo
queden 2, estarán permanentemente marcados. La victoria será para el último jugador que
preserve algo de energía.
6.4.5.1.4 Dominación (Domination)
Los jugadores compiten por un recogible especial denominado orbe. El objetivo
consiste en poseer el orbe durante cierta cantidad de tiempo. Además, el orbe al ser adquirido
por un jugador, le cura hasta el máximo de sobre salud y le rellena la armadura por completo,
además también otorga munición infinita y le marca los recogibles de salud y armadura. Sin
embargo, el propio jugador será marcado para el resto de los jugadores quienes, además,
podrán ver el estado de salud el jugador con el orbe. Cuando el poseedor del orbe sea
eliminado, el orbe caerá al suelo para ser recogido por cualquier jugador, pero el jugador que
eliminó al portador recibirá un pequeño incremento temporal de velocidad una pequeña
curación como recompensa.
6.4.5.2 Modos por equipos
Son los modos en los que un jugador coopera (más o menos) con otros jugadores
para lograr un objetivo. Estos objetivos suelen ser más complejos y requieren de la ayuda de
los compañeros de equipo para conseguirlos. Por ello, eliminar jugadores suele pasar a
segundo plano como un medio para el fin. Se presupone la división en dos equipos de los
jugadores en la partida.
90
6.4.5.2.1 Combate a muerte por equipos (Team Deathmatch)
Idéntico al combate a muerte de todos contra todos, sin embargo, ahora las bajas del
jugador se suman a las de sus compañeros de equipo y gana el equipo que logre el objetivo
de eliminaciones o en su defecto, el que más tenga cuando se acabe el tiempo.
6.4.5.2.2 Capturar la bandera (CTF)
Modo clásico de capturar la bandera. Los equipos deben capturar la bandera de la
base enemiga y llevarla hasta la suya para puntuar. El equipo ganador será el que llegue a
una determinada puntuación.
6.4.5.2.3 Rey de la colina (King of the Hill)
Los equipos compiten por capturar y controlar un punto en el mapa. Similar a
dominación, el objetivo es controlar el punto durante un tiempo determinado. Para capturar
el punto los jugadores deberán permanecer dentro de este durante unos segundos, a más
jugadores del mismo equipo más rápida será la captura. Si dos jugadores de equipos
contrarios entran en el punto, este estará en disputa, lo cual supone que no podrá ser
capturado y que el cronometro de captura se quedará congelado (el equipo que lo ha
capturado no progresará en su objetivo).
6.4.5.2.4 Codicia (Greed)
En este modo los jugadores tendrán que gestionar un nuevo recurso denominado
“criptomonedas”. Este se obtiene al eliminar oponentes pero se deja caer al suelo al morir en
formato orbe. Cualquier jugador puede adquirir ese dinero y sumarlo al suyo. El objetivo es
extraer un determinado número de criptomonedas y para ello existen dos zonas que se han
de capturar y funcionan de forma similar como en el rey de la colina. Solo es necesario
capturar una zona y en el momento de hacerlo, todos los jugadores (del mismo equipo) que
estén en dicha zona perderán todas sus criptomonedas para añadirlas al marcador. Sin
embargo, serán recompensados con una curación masiva y munición ilimitada por un corto
periodo de tiempo.
Para poner las cosas interesantes, cuantas más criptomonedas acumule un único jugador
mayor será su multiplicador de obtención, de manera que cuantas más tiene, más gana. A
partir de cierto umbral el jugador aparecerá marcado para el equipo contrario y además, a
cuantas más acumule, mayor será la recompensa del jugador que lo elimine.
91
Como normas más técnicas:
• Los orbes tienen un tiempo de vida limitado, si no se recogen antes desaparecerán y
se perderán las monedas.
• Se darán criptomonedas bonus por hazañas como rachas de bajas, tiempo portando
gran cantidad de monedas o disputar una zona.
• Las zonas, una vez capturadas, volverán a ser neutrales y capturables.
• No hay cantidad mínima de monedas para capturar una zona.
92
6.5 Estados del juego
En cada momento el juego se encontrará en un estado: o en los menús o en el juego,
y estos determinarán por un lado cómo interactúa el usuario con el juego y por el otro qué es
lo que puede hacer. Además es necesario que exista un flujo entre estados, el cual se ha
representado en la Imagen 33.
A continuación se explican en detalle cada uno de los elementos del diagrama anterior.
6.5.1 Menú principal/Pantalla de título
En este menú el usuario podrá navegar entre las distintas opciones nada más empezar
el juego. Podrá buscar una partida para jugar, modificar la configuración del juego
(opciones), customizar su personaje o salir del juego.
Imagen 34. Boceto del menú principal.
Imagen 33. Diagrama de los estados de juego. Fuente: elaboración propia.
Tienda
93
6.5.2 Menú de pausa
Este menú es similar al menú principal salvo por la diferencia de que este solo se
accede desde la partida. En este menú también será posible modificar tanto las opciones
como la customización del personaje y además se podrá buscar otra partida mientras se
juega.
En este caso en concreto, el menú se abre mientras se está jugando lo cual no detiene el juego
sino que abre la interfaz del menú principal por encima, pero en lugar del botón de salir del
juego estará el de abandonar partida.
6.5.3 Buscador de partida
En este submenú se podrán buscar partidas mediante una sencilla interfaz que dé a
elegir el modo de juego. También será posible abrir un menú oculto que permita filtrar
servidores y partidas mediante distintos parámetros, así como la conexión directa a un
servidor.
Imagen 35. Boceto del menú de buscar partida.
94
6.5.4 Partida: juego
Este es el estado del sistema en el que el usuario está jugando al juego. Este estado tiene a
su vez otros sub-estados que dictan la dinámica de las partidas. Estos son:
• Pre-partida: En este estado el servidor está esperando a que se unan todos los
jugadores. Los que ya lo han hecho pueden ir calentando en el juego enfrentándose
entre sí en una pseudo partida en el mismo mapa y con normas especiales (no hay
objetivo, todos empiezan con todas las armas y máxima munición, no se puede
puntuar, etc.). Una vez se unan todos los jugadores o expire el tiempo de pre-partida,
comenzará una cuenta regresiva para anunciar el comienzo de la partida de verdad.
• Partida: Este es el estado que buscaba el jugador. En él, todos los jugadores pueden
actuar según el objetivo y las normas del modo de juego. Básicamente lo que se
espera del sistema.
• Post partida: En este estado ya se ha acabado la partida, se arrebatará el control
sobre el personaje al jugador y se le anunciará el resultado de la partida. A
continuación se mostrará una pequeña animación estilo “pose de victoria” realizada
por los avatares de los ganadores según corresponda. Por último se mostrará la tabla
de puntuaciones y comenzará una cuenta regresiva para comenzar otra partida.
Salvo en las transiciones entre sub-estados, el jugador podrá acceder al menú de pausa y
realizar cualquier acción que en él pueda.
95
6.5.5 Opciones
En este submenú se podrán editar la configuración de distinto parámetros del juego
como son la calidad gráfica, la interfaz de usuario, las asignaciones de teclas, el sonido, etc.
Imagen 36. Boceto del menú de opciones.
96
6.5.6 Inventario
En este submenú el jugador podrá ver que armas lleva equipadas y qué cosméticos.
Como ya se ha mencionado anteriormente podrá modificar sus elecciones en cualquier
momento. Idealmente los cambios que realice tengan efecto al abandonar el menú.
6.5.7 Tienda
En este menú será posible obtener nuevos cosméticos. No se pretende integrar nada
similar para ningún hito del prototipo, pero es sí es algo que definitivamente se ha de tener
en cuenta y por eso hace acto de presencia en este documento.
Imagen 38. Boceto del menú de la (posible) tienda.
Imagen 37. Boceto del menú del inventario del jugador.
97
7. Desarrollo
En este apartado se va a exponer el desarrollo del proyecto software, explicando sus
componentes principales y cómo se han implementado. También se tratarán aspectos del
motor y del entorno de desarrollo, así como de la dinámica de trabajo en general.
Cabe mencionar que en este apartado no se va a hacer un tutorial paso a paso sobre cómo se
ha realizado el proyecto. Aquí se van a mencionar los aspectos, problemas, sistemas y
soluciones que se consideren relevantes o interesantes para el documento. No se van a
explicar ni en detalle ni grosso modo los aspectos menos relevantes del proyecto. También
téngase en cuenta que este apartado se ha ido redactando en la medida de lo posible conforme
se iba progresando, por lo que es posible que a medida que se avance en la lectura algunos
aspectos cambien en gran medida. Si los cambios son relevantes, se hará mención de ellos.
Tras formular las guías temáticas de este apartado, a continuación se expone la
documentación del desarrollo del primer prototipo, comenzando por el entorno de trabajo,
seguido de los aspectos clave del personaje. Después se hablará de los distintos elementos
con los que interactúa el jugador y se terminará con las opciones y los menús.
98
7.1 Entorno de trabajo
El primer aspecto para tratar es el entorno de trabajo, en el cual se incluye al motor,
editor de código y Git, entre otros. También se va a explicar la dinámica de trabajo y el
funcionamiento de las herramientas. Para ello se va a enfocar este apartado como si fuera
una pequeña guía y se va a describir cómo se puso en marcha el proyecto.
El primer paso comenzó en Unreal Engine, con la creación de un proyecto a partir de la
plantilla de FPS y en los ajustes del proyecto, una de las opciones más importantes a activar
es la de desarrollo en C++ y la de usar contenido inicial, cortesía del propio motor.
Inmediatamente después de crear el proyecto, tanto el editor de Unreal Engine como el de
Visual Studio se abren con la escena de la plantilla del FPS y sin ningún fichero fuente
seleccionado respectivamente.
Imagen 40. Captura de las plantillas de proyecto. Imagen 39. Captura de las opciones del proyecto.
99
El siguiente paso es crear un repositorio GIT. Para ello y partiendo del resultado del paso
anterior, en Visual Studio se hace click en el desplegable marcado en rojo de la Imagen 41
y se abrirá la interfaz visible en la misma imagen. Una vez allí es bastante intuitivo lo que
hay que hacer y en unos sencillos pasos ya está creado el repositorio de GIT.
Una vez creado el proyecto ya está listo para empezar a trabajar en él.
Imagen 41. Captura de Visual Studio con la configuración para conectar un repositorio GIT.
100
7.2 Introducción a UE4
Antes de comenzar, se va a hacer una breve introducción a los conceptos básicos de
Unreal Engine 4 con tal de facilitar la lectura de los siguientes apartados.
En primer lugar UE4 nos propone unas clases predefinidas con una serie de características.
Estas clases se especializan en distintas funciones que puede necesitar un elemento de un
videojuego, las que más se han utilizado en este proyecto son: AActor, APawn y ACharacter.
La clase AActor es la clase base para los objetos/elementos que se pueden colocar o generar
en un nivel (AActor, Unreal Engine Documentation). Estos pueden contener distintos
componentes que controlan y definen su comportamiento. Generalmente todos los
objetos/elementos que aparecen en un nivel son actores, por eso es común denominarlos
simplemente, actores. Otro aspecto importante es la replicación en red de sus propiedades,
lo cual hace esta clase ideal para elementos como los recogibles.
La clase APawn (peón) es la clase base de todos los actores que pueden ser poseídos por una
IA o por un jugador. Es la representación física de la entidad en cuestión, no solo
visualmente, sino también representa cómo interactúa con el mundo: las colisiones, su
posición y rotación, etc. (Pawn, Unreal Engine Documentation).
Por último, ACharacter (personaje) es una subclase de APawn que tiene la habilidad especial
de caminar y moverse por el nivel (Pawn, Unreal Engine Documentation). Contiene diversos
componentes distintivos de los APawns como son el SkeletalMeshComponent (componente
de malla esquelético) que permite emplear mallas con animaciones complejas o el
CapsuleComponent (componente de cápsula) el cual sirve para calcular colisiones y tiene
forma de cápsula, ideal para un personaje bípedo (Character, Unreal Engine
Documentation).
Otro aspecto que se va a tratar en gran volumen en las siguientes páginas son las plantillas o
blueprints. Estas plantillas son un sistema de programación (orientado a objetos) visual
basado en nodos que permiten crear elementos del juego desde el propio editor de Unreal
Engine. Los objetos definidos por plantillas reciben ese mismo nombre, por eso de ahora en
adelante se empelará el término blueprint/s para referirse a este concepto.
101
7.3 Personaje controlable
El punto lógico de partida es el personaje, o más concretamente el jugador en sí. La
plantilla ya viene preparada con un jugador con las opciones básicas ya incluidas, sin
embargo, dicho jugador se va a desechar y se va a crear uno nuevo, no desde cero sino
reciclando algunos de los componentes del predefinido.
También se aprovechará esta oportunidad para explicar el proceso que se va a seguir a la
hora de crear componentes.
El procedimiento es simple, primero se crea la clase en C++ y después se crea la plantilla
(blueprint de ahora en adelante) a partir de ésta. En la clase de C++ se implementará la
funcionalidad básica y el comportamiento que define al jugador. Luego en la blueprint se
editará el aspecto visual del componente, es decir, los elementos gráficos de los que se
compone y que pueda necesitar el código. En la Imagen 42, a la izquierda, se puede ver la
estructura de carpetas que se ha usado, separando el contenido de las clases y las plantillas
de código. A estas alturas cabe remarcar la facilidad de poder modificar el comportamiento
o el aspecto visual de un componente sin afectar al otro.
Para el personaje en sí, es necesario definir o más bien enlazar la entrada del teclado para
poder moverse. Esto está ampliamente documentado en el manual de UE4 pero lo importante
de esto es que, al necesitar implementar esas funciones manualmente del componente
controlador del movimiento, es posible añadir funcionalidades extra. Como por ejemplo
quitarle el control al jugador sobre su personaje cuando muere con un simple condicional.
Imagen 42. Captura del explorador de archivos de UE4 mostrando las blueprints de los distintos elementos creados.
102
Otro aspecto que resaltar es el hecho de que la clase base de la que hereda el personaje es
ACharacter, una clase base que incluye por defecto ciertos componentes como son una
cámara, un componente de cápsula (colisiones) y una malla, además del componente
controlador del movimiento.
Estos son editables desde la plantilla pero son insuficientes para este caso. Por ello se le
añade un componente extra de malla, de forma que el principal almacenará el modelado que
ven otros jugadores y el extra el que ve el propio jugador (vista desde primera o tercera
persona). Al inicializar el actor simplemente se le preguntará al controlador de movimiento
si se controla localmente y en función a la respuesta se ocultará una malla o se mostrará la
otra. Luego, cuando el jugador sea eliminado se ocultará la malla de primera persona y se
mostrará la de tercera, así el jugador podrá ver su propio ragdoll.
Imagen 43. Captura del editor de la blueprint del personaje en la que se muestra el resultado final.
103
Por otro lado, será el jugador quién implemente la lógica de interactuar con recogibles.
También simulará mediante un blueprint el ciclo de juego, debido a que para implementar
correctamente este modelo es estrictamente necesario hacer el juego multijugador, algo que
por limitaciones de tiempo y experiencia con la herramienta no es posible.
Otro ejemplo que demuestra la gran polivalencia de las plantillas es el sistema de strafe jump.
Idealmente este se debería implementar sobre escribiendo el componente de controlador de
movimiento, creando una clase hija con su propio comportamiento o incluso creando un
nuevo controlador de movimiento, algo que requiere, respectivamente, saber cómo funciona
el controlador de movimiento y cómo interactúa con los elementos internos de UE4 o
directamente saber cómo funciona UE4 internamente.
Aunque es posible, para el objetivo de este proyecto no resultaría asequible. Por eso en su
lugar simplemente se modificará, mediante la blueprint del jugador, el comportamiento del
controlador de movimiento. Logrando así, algo bastante similar al strafe jump (estrictamente
hablando, es strafe jump pero implementado haciendo “trampas”).
Imagen 44. Captura de los grafos de eventos de la plantilla del jugador.
104
Como se puede observar en la Imagen 44, es más sencillo implementar ciertas cosas en las
plantillas y posteriormente pasarlas a código C como demuestran los nodos fuera de algún
comentario (fondo gris claro), vestigios de pruebas que se implementaron en código. Aunque
también es cierto que a veces por cuestiones de diseño es mejor implementar un
comportamiento en la plantillas.
Imagen 45. Captura más en detalle de la simulación del ciclo de partida, justo debajo está la lógica que oculta o muestra
la malla en 1ª o 3ª persona, que ya se implementó en código C.
105
7.4 Recogibles
Para crear la clase de recogibles, el planteamiento es crear una clase recogible en la que
definir el comportamiento general de los recogibles, y después crear los recogibles concretos
con su comportamiento y atributos característicos. También se va a aprovechar este apartado
para profundizar en la metodología de trabajo. Para ello primero se crea la clase recogible
denominada Pickable.
Esta será la clase padre de la que el resto de recogibles heredarán y que, por tanto, deberá
implementar el comportamiento básico de los recogibles. En este caso en concreto, el
comportamiento común a todos los recogibles es el de rotar sobre sí mismos y desaparecer
durante un periodo de tiempo tras interactuar con ellos.
Lo importante a la hora de crear esta clase es hacer que la variable que almacena el tiempo
de reaparición (cooldown) sea editable por la blueprint. De esta forma será posible cambiar
su valor mucho más fácilmente y sin necesidad de recompilar todo el código. Como paso
final, se crea una blueprint (Pickable_BP) de esta clase y se le otorga desde esta un modelado
y una hitbox cúbica independiente al modelado. Esta servirá únicamente para comprobar su
funcionamiento, dado que no se hará uso de este componente posteriormente.
Imagen 46. Captura del editor de Pickable_BP, a la derecha se encuentran, bajo el nombre de Pickable, los parámetros
mencionados.
106
Una vez hecho esto a continuación el paso lógico es crear las subclases de recogibles. Como
ejemplo se van a utilizar los recogibles de salud ya que existen diversos tipos de ellos.
El primer paso es crear una clase que herede de Pickable la cual se va a denominar
HealthPickUp. En esta subclase solo hay que implementar la variable que almacena la salud
que recupera y la función que la devuelve. A continuación se crea una blueprint
(HealthPickUp_BP) con esta clase y análogamente a la anterior se le da un modelado y una
hitbox. Ahora el siguiente paso es crear una blueprint hija de la anterior y cambiar los valores
de la salud que recuperan y el tiempo que tardan en reaparecer así como del modelado para
su fácil identificación.
Imagen 48. Resultado final de los recogibles básicos. Nótese el resaltado y el código de colores para su fácil
identificación.
Imagen 47. De izquierda a derecha: HealthPickUp_ BP,Pickable_BP y ArmorPickUp_BP, las plantillas base de
las cuales heredarán los distintos recogibles de cada tipo.
107
Para el resto de recogibles se hace algo similar. Solo es necesario darles parámetros únicos
en una subclase de Pickable y rellenarlos en la plantilla, sin olvidar por su puesto, su aspecto
visual. También cabe mencionar que ya que la lógica de interacción con los recogibles la
implementa el jugador, se le asigna una etiqueta a cada tipo de recogible para que la clase
jugador pueda discriminarlos fácilmente, lo cual lleva a una situación muy curiosa: los
recogibles de munición recuperan una cantidad fija, sin embargo, dicha cantidad viene
definida en las propiedades del arma (explicado más adelante) de manera que los recogibles
de munición solo necesitan saber su tiempo de reaparición, lo cual, a su vez, hace que su
clase padre sea directamente Pickable.
Otro recogible del que no se ha hablado es el de las armas. Estos funcionan de manera
peculiar ya que su función es crear un nuevo actor (el arma) y de un tipo en concreto. Por
ello lo único que almacena esta plantilla es el tipo, y en función de él se cambia el color de
la malla para que sean fácilmente identificables por el jugador.
Imagen 49. Recogibles de armas, cada uno con su color identificativo.
108
7.5 Armas
La clase en la que se implementa la lógica de las armas recibe el nombre de
WeaponComponent, que hereda de APawn. La blueprint que implementa la clase, recibe el
nombre de WeaponComponent_BP. Aunque esta sería la primera iteración del sistema,
posteriormente se cambiará la implementación por una más práctica y sencilla. El motivo
por el cual se implementó inicialmente así es debido a que entonces el sistema de recogibles
estaba en sus primeras iteraciones y, por tanto, su funcionamiento aún no estaba asentado,
de manera que la plantilla hará como recogible provisional.
Lo primero es definir qué aspectos componen a un arma, como el daño, la cadencia de fuego,
desviación o el tipo de proyectil. Con respecto a esto último existen dos tipos de proyectiles,
hitscan o proyectil (valga la redundancia). El primero no tiene propiedades especiales, es
invisible, intangible e instantáneo que impacta con lo primero que se topa, y si es un jugador,
le hace daño. El segundo, tiene sus propiedades físicas como la velocidad, gravedad y
coeficiente de rebote, entre otros. Es visible y tiene un modelado asignado además de un
sistema de partículas para simular explosiones, si corresponde.
Imagen 50. Aspecto inicial de la plantilla de WeaponComponent_BP.
109
Una vez implementados los inicializadores y los
mecanismos para disparar, la lógica de disparo es
muy sencilla: primero se comprueba si hay
munición. Si la hay se efectúa un raycast si el
arma es hitscan o se crea un proyectil en caso
contrario. Es en la propia clase del arma en la que
se comunican el jugador que dispara con el que es
disparado, aunque idealmente esta clase debería
llamar a una función del servidor que decidiera si
se ha acertado o no y comunicara dicha decisión
a ambos jugadores. Pero para este caso, será el
arma (o el proyectil) quien comunique si se ha
eliminado al oponente y consecuentemente pedirá
sumar un punto a la puntuación del jugador que
dispara.
En última instancia y tras haber implementado el sistema de recogibles, se decidió que las
armas no necesitaban de alguna representación gráfica y que, por tanto, no era necesario
implementarlas en una blueprint. Así, el recogible del arma se encargaría de crear e
inicializar un nuevo actor en forma de arma y se lo pasaría al jugador para que este se lo
asociara. De esta forma es posible tener un mismo modelado para el arma, el cual se
almacena en la blueprint del jugador y en función de qué arma tiene equipada (se discriminan
por tipos) se cambian los materiales del modelado.
7.5.1 Proyectiles
Para la implementación de los proyectiles se ha creado su propia clase y, a diferencia
de la mayoría de las clases, estos no tienen su implementación en plantilla al igual que las
armas, pero a diferencia de éstas, si necesitan de una representación gráfica.
Imagen 51. Variables que definen a un arma.
Imagen 52. La clase proyectil junto al resto de clases de C, nótese cómo es la única que carga un aspecto visual notorio.
110
Por ello la implementación gráfica se lleva a cabo enteramente en código C. Esto es debido
a que, por el modo de funcionamiento de UE4, la función de creación de actores no admite
parámetros de creación de manera que la única forma de inicializar los valores es a posteriori.
Además, una vez asignada una malla al componente ésta no se puede cambiar en tiempo de
ejecución, por lo que todos los proyectiles actualmente tienen el mismo aspecto pero con
comportamientos distintos.
La solución a esto es tan sencilla como crear clases hijas de la clase proyectil que se
construyan con su malla apropiada. Además esto permitiría especializar la implementación
de la lógica de los proyectiles (si rebotan o explotan, bajo qué condiciones, etc.) en lugar de
la actual implementación que contiene todos los comportamientos en la misma clase, y que
por falta de tiempo, se dejó así.
7.5.1.1 Explosiones
Al menos dos de los arquetipos de armas se basan en munición explosiva, lo cual
supone que fallar un impacto directo no es sinónimo de no causar daño. Al contrario que el
resto de las clases, las explosiones se implementan íntegramente en blueprint. Estas
contienen el efecto de partículas por un lado, un campo emisor de fuerza y una hitbox. El
primer componente es el puramente visual, el segundo se encarga de empujar al jugador en
la dirección opuesta (para hacer Rocket jump, por ejemplo) y el tercero es el computa el
daño y en caso de ser letal, a quién se le dan los puntos. En la Imagen 54 se puede ver el
resultado final en acción.
Imagen 53. Captura del editor mostrando un proyectil.
111
Con respecto a esto último un dato curioso es que el arma tiene como propietario al jugador,
cuando crea un proyectil este hereda el mismo propietario y de forma similar lo hacen las
explosiones.
Imagen 54. Efecto de explosión tras detonar una granada en un oponente. El área roja oscura alrededor de la explosión
delimita la zona de daño.
112
7.6 HUD
La interfaz de usuario se implementa creando un blueprint de herramienta (widget) de
interfaz de usuario. Al abrir dicha plantilla hay un lienzo en el cual se puede empezar a
colocar los componentes que se consideren oportunos.
Como se puede observar en la Imagen 55 el HUD no está muy recargado, pues se pretende
mantener lo más simple (y minimalista) posible. Los valores 000 y 111 corresponden a la
salud y la armadura respectivamente. En el centro, el número superior corresponde al
temporizador de partida y el inferior a la velocidad del jugador. A la derecha del todo, en la
esquina superior se encuentra el contador de la puntuación del jugador y abajo, en amarillo,
la munición del arma equipada.
Imagen 55. Captura del editor del HUD del jugador
Imagen 56. Captura de la función que asigna el valor de la salud al componente del HUD.
113
A través de estos elementos se va a representar la información que el jugador necesita
conocer en todo momento. Para darles valores es necesario crear funciones en la clase del
jugador que devuelvan los valores y llamarlas desde la plantilla de interfaz como se muestra
en la Imagen 56. Un elemento que destacar en dicha imagen es el nodo de GetPlayer
Character, el cual toma como valor de entrada el índice 0 que se refiere al primer jugador
que se carga, es decir, el primer controlador de movimiento que se crea que corresponde al
jugador local, algo relevante para el diseño multijugador. Otro aspecto que remarcar es el
nodo que redondea el valor devuelto por GetHealth, lo cual permite mostrar de forma más
agradable el dato de salud del jugador. Esto se aplica a todos los elementos informativos no
discretos del HUD.
114
7.7 Menú y opciones
El menú principal es un caso especial. Para implementarlo se ha creado un nuevo nivel
vacío que cuando se carga asocia una herramienta de interfaz que representa el menú. Esta
interfaz funciona de forma similar a la del HUD, lo único que cambia es que el juego no
captura el cursor por lo que el usuario es libre de clicar e interactuar con los elementos que
ve en pantalla.
Con respecto a su implementación, los botones de Play y Quit que se pueden apreciar en la
Imagen 57 ejecutan unos comandos que cargan un nivel o cierran el juego respectivamente.
Los otros dos botones alteran mutuamente la visibilidad de sus correspondientes apartados
en la zona azul oscuro de la derecha. En las imágenes Imagen 58 e Imagen 59 se puede ver
el apartado del inventario y el de las opciones, respectivamente.
Imagen 57. Captura del menú principal.
Imagen 58. Captura del menú de inventario. Imagen 59. Captura del menú de opciones.
115
Cuando finaliza una partida el jugador es devuelto al menú principal. Para ello el nivel se
acopla a un evento que inicia el jugador para que se vuelva a cargar el menú (Imagen 60).
Las opciones funcionan de forma similar a los botones de Play y Quit, ejecutando un
comando en la consola de UE4. Sin embargo, a diferencia de los anteriores, es necesario
parametrizar dicho comando. Para ello se emplea un campo de opciones del que se puede
recuperar el índice del ítem seleccionado, capturando el evento de cambio de selección y
sabiendo el índice del ítem que está seleccionado es posible elaborar los comandos.
En la Imagen 61 se puede ver más claramente cómo funciona el sistema de opciones.
Imagen 60. Captura de la blueprint del nivel. Arriba: enlace con el evento del jugador. Abajo: contenido de la función.
Imagen 61. Funciones que modifican las opciones del Anti-Aliasing y la calidad de sombras.
116
Para casos como el anti-aliasing se ponen comandos predeterminados ya que el índice no es
suficiente, para otros como las sombras se puede usar dicho índice para confeccionar el
comando.
La opción de escala de resolución a pesar de usar un control deslizante funciona de manera
similar a las sombras, pero con sus normas particulares para que no genere un comando con
valores inválidos o redundantes (cambios tan sutiles que no surtirían efecto) y así lograr que
la opción funcione correctamente.
117
8. Conclusiones
En este apartado se va a evaluar, por un lado y de forma objetiva, los resultados
obtenidos contrastando los objetivos propuestos y los objetivos logrados. Por el otro se hará
una evaluación personal del trabajo con un enfoque más orientado a la reflexión.
En el apartado 3 de este documento se proponen una serie de objetivos y subobjetivos que a
continuación se van a evaluar, en el mismo orden en el que en dicho apartado se presentan.
También en el apartado 3 están todos los detalles acerca de los objetivos que más abajo
puedan haberse omitido.
118
8.1 Objetivos principales
En primer lugar, el trabajo de investigación realizado es extenso y detallado. Se han
analizado los referentes más icónicos del género de los arena shooters, en concreto la
primera y la última entrega de cada saga. Se han comparado y analizado similitudes y
diferencias. Aunque también habría sido conveniente analizar las entregas promedias, para
tener una mejor perspectiva de su evolución, u otros juegos similares, para enriquecer el
contexto.
También, de dicha investigación, se ha obtenido mucha información acerca de cómo
funcionan las mecánicas potencialmente frustrantes y de cuáles son los aspectos clave para
enfrentarse a las principales fuentes de frustración.
En segundo lugar, el documento de diseño de videojuego (GDD) que se ha elaborado está
completamente basado en la investigación y análisis previos. A lo largo de todo el GDD se
justifican las decisiones de diseño remitiéndose a la información adquirida previamente. Los
aspectos relacionados con las mecánicas y las bases del juego han sido rigurosamente
confeccionados e incluso en los apartados menos relevantes para el proyecto, como podría
ser la estética, se han introducido detalles inspirados en el análisis previo. Aun así, los
apartados más creativos del GDD han sido sutilmente relegados a un segundo plano.
119
8.2 Subobjetivos
Siguiendo el orden en el que se presentan en el apartado 3.1, se ha logrado
implementar las metodologías ágiles, especialmente sobre el apartado de desarrollo software
que, además, se basa desde un principio en iterar prototipos. También se han redactado los
documentos de análisis y gestión de riesgos, el documento DAFO y el de análisis de
requisitos. Estos documentos han permitido seguir y encauzar el desarrollo del proyecto.
Con respecto a las herramientas de trabajo, su uso ha estado muy polarizado a lo largo del
proyecto. En un principio, las herramientas de gestión fueron las más usadas y eso permitió
entender mejor su funcionamiento. Sin embargo, hacía el final del proyecto, la herramientas
más usadas pasaron a ser las de desarrollo y eso permitió adquirir mayor habilidad con ellas.
Continuando con el siguiente punto en la lista, se ha conseguido realizar un prototipo
siguiendo las directrices y las normas establecidas en el GDD, respaldadas en el documento
de requisitos. Por un lado, se han implementado todos los requisitos funcionales e incluso se
han añadido algunas funcionalidades que no están contempladas. Por otro, los requisitos no
funcionales se han logrado casi por completo, sin embargo, a pesar de la parcialidad en la
consecución de los requisitos, el sistema cumple con las expectativas.
Seguidamente y relacionado con lo anterior, la documentación del proceso de desarrollo.
Dicha documentación cubre los detalles más importantes del desarrollo indagando en los
aspectos técnicos más interesantes. Sin embargo, en circunstancias ideales esta
documentación se habría redactado, en su totalidad, a medida que se realizaba el proyecto
software.
Por último pero no menos importante, el trabajo en el prototipo ha permitido mejorar las
habilidades de programación y sobre todo mejorar la calidad del software producido.
120
121
9. Bibliografía y referencias
1047 Games. (24 de mayo de 2019). Splitgate.
Atlassian. (13 de septiembre de 2011). Trello. Obtenido de trello.com/
Berger, D. V. (2007). Frustration. Obtenido de Psychologist Anywhere Anytime:
http://www.psychologistanywhereanytime.com/emotional_problems_psychologist/
pyschologist_frustration.htm
Blender Foundation. (2014).
Bruce, D. (20 de Abril de 2011). Image tiré de la démo du jeu Maze War sur Imlac (2004)
tiré de la vidéo d'une vidéo de Bruce Damer sur youtube.com. Obtenido de
https://www.youtube.com/watch?v=ZgT9IgRlrvI&ab_channel=brucedamer
Chen, L., Babar, M. A., & Nuseibeh, B. (2012 de Noviembre de 2012). Characterizing
Architecturally Significant Requirements. 30(2), 38-45. doi:10.1109/MS.2012.174
Clokify. (s.f.). clokify-detailed-screenshot-dark.png. Obtenido de
https://clockify.me/assets/images/brand-assets/clockify-detailed-screenshot-
dark.png
Craig, S., D'Mello, S., Witherspoon, A., & Graeesser, A. (2008). Emote aloud during
learning with AutoTutor: applying the facial action coding system to cognitive–
affective states during learning. 777-788. doi:10.1080/02699930701516759
Crytek. (7 de septiembre de 2013). CryEngine Nex-Gen(4th Generation). Obtenido de
crytek.com
Devilly, G., Callahan, P., & Armitage, G. (04 de 2011). The Effect of Violent Videogame
Playtime on Anger. Australian Psychologist, 47, 98-107. doi:10.1111/j.1742-
9544.2010.00008.x
Dirección General de Industria y de la Pequeña y Mediana Empresa. (22 de mayo de
2020). Obtenido de dafo.ipyme.org: https://dafo.ipyme.org/Home
Enciende la Luz SL. (19 de enero de 2018). Iterativo e incremental. Obtenido de
https://www.youtube.com/watch?v=_qUlL01th2s
Epic Games. (27 de junio de 2013). SVG version of Unreal Engine 4 logo. Obtenido de
https://www.unrealengine.com/en-US/
FANDOM. (24 de Julio de 2009). Items. Obtenido de unreal.fandom.com:
https://unreal.fandom.com/wiki/Unreal_Tournament#Items
Fulton, R., & Vandermolen, R. (2017). Requirements - Writing Requirements. En Airborne
Electronic Hardware Design Assurance (págs. 89-93). CRC Press.
Genaro J., R. (29 de noviembre de 2012). Desarrollo en Cascada (Waterfall) VS
Desarrollo Agile (SCRUM). Obtenido de northware:
https://www.northware.mx/blog/desarrollo-en-cascada-waterfall-vs-desarrollo-
agile-scrum/
Gérôme, J.-L. (1872). Pollice Verso.
GitHub. (16 de abril de 2013, 2018). Obtenido de https://github.com/logos
González Sánchez, J. L., Padilla Zea, N., & Gutiérrez, F. L. (2009). From Usability to
Playability: Introduction to Player-Centred Video Game Development Process. (M.
122
Kurosu, Ed.) Human Centered Design, 65-74. doi:https://doi.org/10.1007/978-3-
642-02806-9_9
Gray, J. (julio de 2012). Obtenido de steamcharts: https://steamcharts.com/
id Software. (1999). q3ademo.jpeg. Obtenido de
https://archive.org/details/QuakeIiiArenaDemo
infoautónomos. (20 de 05 de 2021). analisis-dafo. Obtenido de infoautonomos.com:
https://www.infoautonomos.com/plan-de-negocio/analisis-dafo/
Irrlicht Project. (29 de diciembre de 2012). The Irrlicht Engine Logo. Obtenido de
http://www.irrlicht3d.org/images/irrlicht_new_logo.png
Jeronimus, B., & Laceulle, O. (2017). Frustration. (V. Zeigler-Hill, & T. Shackelford,
Edits.) Encyclopedia of Personality and Individual Differences, 1-5.
doi:10.1007/978-3-319-28099-8_815-1
Maximir93. (19 de Enero de 2021). PRO_Q3DM13_levelshot.jpg. Obtenido de
https://quake.fandom.com/wiki/Quake_III_Arena?file=PRO_Q3DM13_levelshot.jp
g
Microsoft. (2019). Obtenido de https://visualstudio.microsoft.com/
Murphy, E. A., & Raanan, A. (s.f.). Murphy Laws Site - War Laws. Obtenido de Murphy
Laws Site - The origin and laws of Murphy in one place.: http://www.murphys-
laws.com
Picard, R., & Jonathan, K. (Febrero de 2002). Computers that recognise and respond to
user emotion: theoretical and practical implications. Interacting with Computers,
14(2), 141-169. doi:10.1016/S0953-5438(01)00055-8
Quake Champions. (22 de agosto de 2017). Bethesda Softworks.
Quake III Arena. (2 de Diciembre de 1999). id Software.
S.-t. (. (500 a. C.). 孫子兵法 (El arte de la guerra de Sun Tzu).
Sommerville, I. (2005). INGENIERÍA DEL SOFTWARE (7ª ed.). (M. A. Galipienso, A. B.
Martínez, F. M. Lizán, & J. T. Jover, Trads.) Madrid, España.
Swink, S. (2008). Game feel: a game designer's guide to virtual sensation (1st ed.).
Morgan Kaufmann Publisheres.
Szasz, P. L., Szentagotai, A., & Hofmann, S. G. (2011). The effect of emotion regulation
strategies on anger. Behaviour Research and Therapy, 49(2), 114-119.
doi:10.1016/j.brat.2010.11.011
Unity Technologies. (1 de febrero de 2011). The official logo of Unity, used to represent
the company as well as the Unity Editor. Obtenido de http://unity3d.com/es/public-
relations/brand
Unreal Tournament. (30 de noviembre de 1999). Epic Games.
Unreal Tournament 3. (19 de noviembre de 2007). Epic Games.
Unreal Tournament 4. (cancelado). Epic Games.
Valve Corporation. (19 de Abril de 2007). Portal. Valve Corporation.
123
10. Glosario de términos
En este apartado se recogen y definen los términos los cuales el lector/a no tiene por
qué estar familiarizado.
Términos
AoE: Area of Effect, área de efecto. Generalmetne de daño o effectos negativos. ............. 14
arena shooters: Juegos de disparos de tipo arena...................................................... 9, 19, 44
backlog: Apartado para las tareas pendientes. ............................................................... 48, 69
battle royale: Modo de juego en el que numerosos jugadores se enfrentan entre sí hasta que
solo quede uno em pié. .................................................................................................... 38
CQB: Close Quarters Battle, pelea cuerpo a cuerpo o en su defecto, en espacios cerrados a
muy corta distancia. ............................................................................................. 13, 20, 35
crowdfunding: recaudación de fondos. Se trata de financiar un proyecto o producto
mediante la pequeña aportación de muchos individuos interesados en este. .................. 74
Damage Amplifier: Potenciador de UT99 que incrementa el daño en un 300%. ................ 23
deathmatch: Modo de juego en el que los jugadores se enfrentan entre sí. ................. 11, 15
feedback: Retroalimentación. .............................................................................................. 28
FFA: Free-For-All o Todos Contra Todos. Modo de juego en el que los jugadores se
enfrentan entre sí sin equipos. ................................................................................... 11, 33
FPS: First Person Shooter, juego de disparos en primera persona. .............................. 78, 99
gameplay: Experiencia de juego, en pocas palabras...................................................... 15, 56
GIT: Sistema de control de versiones gratuito y de código abierto ................................. 4, 99
hacker: Para este contexto se refiere al jugador que hace trampas en los videojuegos. ...... 31
hackers: según la RAE "es todo individuo que se dedica a programar de forma entusiasta, o
sea un experto entusiasta de cualquier tipo". Sin embargo, para el caso de los
videojuegos el término más apropiado es tramposo. También más apropiado aún es el de
lamer o script-kiddie, los cuales hacen referencia a la persona que, sin ningún
conocimiento técnico o teórico, hacen uso de programas de "hacking" desarrollados por
otros para sus fines maliciosos como hacer trampas en los videojuegos. Es importante
diferenciar entre la gente que se dedica a encontrar debilidades en un sistema y de los
payasitos que solo quieren amargar el día a la gente. ...................................................... 39
haste: Potenciador de Q3A que incrementa la velocidad de movimiento y la cadencia en un
30%. ................................................................................................................................. 12
hero shooter: Juego de disparos en el que los personajes tienen sus habilidades y
cualidades, propias y únicas. ........................................................................................... 31
hit boxes: Se refiere a la "caja" que envuelve al jugador y detecta las colisiones con este. 79
hitmarker: Indicador visual (o sonoro) que se activa al impactar o dañar a un oponente. .. 28
hitreg: hit registration, registro de impacto. En un juego multijugador se refiere al sistema
que se encarga de detectar los impactos y notificarlos a los clientes. ............................. 34
hitscan: método de cálculo de colisiones de disparos que posiciona el impacto directamente
donde se está apuntando de forma instántanea. ................................................... 13, 14, 22
HUD: Heads Up Display, interfaz del usuario. Muestra la información relevante para el
jugador como la salud, munición y tiempo de partida. .................................................... 32
124
lootbox: Caja de botín. Contiene uno o varios objetos de valor que se seleccionana de una
lista según su probabilidad asignada. Para abrirla suele ser necesario pagar con dinero
real. .................................................................................................................................. 33
looter shooters: Juegos de disparos que se basan en realizar incursiones en zonas y
recolectar el máximo valor de objetos. Se caracterizan por un PVP muy intenso ya que al
morir usualmetne se pierde todo lo obtenido en la incursión, incluyendo el equipamiento
que se llevaba. Su principal atractivo es el alto riesgo de las decisiones, especialmente
aquellas relacionadas con la codicia. ............................................................................... 75
microtransacciones: Estrategia de negocio que consiste en añadir contenido al juego por el
cual se debe pagar una pequeña cantidad de dinero. ....................................................... 33
mutadores: Modificaciones en los modos de juego sin alterar las normas básicas (de ahí las
mutaciones). ............................................................................................................... 15, 18
piston dodge: Técnica similar al piston jump pero en el plano horizontal, generalmente con
el apoyo de una pared. ..................................................................................................... 16
piston jump: Técnica que consiste en disparar el Impact Hammer contra el suelo para saltar
más alto, similar al rocket jump. ................................................................................ 16, 25
plugins: Complemento de un programa que se relaciona con otro y le añade
funcionalidades generalmente específicas. ...................................................................... 51
powerup ................................................................................................................... 23, 35, 87
powerups: Potenciadores que otorgan al jugador un estado alterado positivo o beneficioso.
.................................................................................................................................. passim
quad damage: Potenciador de Q3A que incrementa el daño en un 400%. ......................... 12
ragdolls: Animación procedural de los motores de físicas que sustituyen a las animaciones
de muerte. ................................................................................................................ 82, 102
reboot: Se refiere a una reanimación de una entrega de un videojuego. ............................. 37
rip off: se traduce por estafa, en el ámbito de los videojuegos se refiere también a un juego
que es una copia casi exacta de otro con la intención de sacar dinero (ergo una estafa). 74
rocket jumps: Técnica que consiste en emplear la fuerza de la explosión de un cohete,
generalmente disparado a los pies, para catapultarse en el aire y lograr grandes alturas.
................................................................................................................................... 14, 25
rotaciones: estrategia que consiste en migrar la posición defensiva a otra sala para
sorprender al oponente y forzarle a cambiar la zona que defiende. Similar a una
emboscada. ...................................................................................................................... 12
shooters: Juegos de disparos......................................................................................... passim
strafe jumping: Técnica que consiste en aprovechar la acceleración lateral en el aire para
acelerarse por encima de la velocidad máxima ................................................... 12, 25, 32
Strafing: Técnica que consiste en acompañar el desplazamiento lateral aéreo con un giro de
la cámara, esta combinación produce una aceleración del personaje y otorga mayor
control aéreo. ................................................................................................................... 84
Team Deathmatch: Deathmatch pero por equipos, generalmente dos. ............................... 33
TTK: Time To Kill, "tiempo para matar". Se refiere a cuantos golpes se necesitan dar de
media para eliminar a un jugador. ................................................................................... 81
wallhack: trampa que permite ver a los oponentes a través de las paredes. ........................ 31