Revision: 2.0.0 
 
GDD Template Written by: Benjamin “HeadClot” Stanley 
 
 
1
 
 
 
 
 
 
 
 
 
 
 
 
 
 
License  
If you use this in any of your games. Give credit in the GDD (this document) to 
Alec Markarian and Benjamin Stanley. We did work so you don’t have to.   
 
Feel free to Modify, redistribute but ​not sell​ this document. 
 
 
TL;DR - Keep the credits section of this document intact and we are good and 
do not sell it. 
 
 
 
 
 
 
 
 
 
 

2
Resumen
Temática / Locación y Género
Mecánicas principales (core) - Brief
Requerimientos de plataforma
Modelo de monetización
Miras del proyecto​ (scope)
Presupuesto y tiempos
Equipo
Licencias (programas y ​plug-ins​)
Referencias
Descripción del proyecto (Brief):
Puntos principales
Controles
Game Flow
Pacing
Oleadas
Mecánicas principales (core) - Justificación
Disparo
Dash
Trail
Narrativa
Sinopsis
HIstoria
Gameplay (diseño de experiencia y nivel)
Diseño de experiencia
Diseño de nivel (puntaje y oleadas)
Reparto de enemigos (puntajes y patrones)

Sistema procedural
Procedimientos de assets
- 2D
Texturas de personajes (tranformaciones y enemigos)
Menús (en progreso)
HUD
- 3D
Personajes (tranformaciones y enemigos)
Color de personajes
Diseño de escenarios
- Sonido
- Programación
-Sonido
- Animaciones

3
 
Resumen 

4
Temática / Locación y Género 
“greet the light” es un juego con temática de supervivencia en un 
entorno minimalista del género shoot ‘em up. Algunos referentes de este 
género son THOTH (2016, Double Fine Productions) y Geometry Wars (2003, 
Microsoft Game Studios) 

Mecánicas principales (core) - Brief 

El  jugador  tiene  que  sobrevivir  haciendo  uso  de  las  distintas 
transformaciones  para  obtener  el  mayor  puntaje  posible  hilando  eliminaciones 
de enemigos.  
Dependiendo  la  situación  y  el  tipo  de  enemigos  a  los  que  se  enfrente  se 
tendrá  que  decantar  por  una  u  otra  transformación.  La  aparición  de  enemigos 
depende de la existencia de sonido; por tanto, los niveles tienen como duración 
lo que dure su canción determinada.  
 

 
 
Los tres diferentes tipos de transformación son: 

- Disparo:​ ​Es un disparo como en cualquier otro juego top down. Sirve 
para generar distancia con los enemigos. 

5
  

- Dash:​ ​Implica moverse más rápido a través del nivel. En el momento que se 
aprieta y se aumenta la velocidad puede eliminar enemigos. 
 

 
- Trail:​ Su funcionamiento está basado en la línea de las motos de la 
película Tron (Lisberger, 1982). Sólo que en nuestro caso se puede activar y 
desactivar de acuerdo a las necesidades del jugador. 
 

 
6
Requerimiento de Plataforma 
 
● Windows PC (gama media) 
 
Requisitos mínimos del sistema  Requisitos óptimos del sistema 
   
CPU: Procesador Intel® Core™  CPU: Procesador Intel® Core™ 
i5-2300  i5-7300 
GPU: Gráficos HD Intel® 2000 2GB  GPU: Nvidia 950 3 GB 
RAM: 4 Gb de memoria  RAM: 8 Gb de memoria 
HDD: 2 Gb de disco duro  HDD: 2 Gb de disco duro 
  SoundCard: 5.1 canales/ integrada o 
  externa 
● PS4 
 
Características del sistema PS4 
 
CPU: Procesador AMD Jaguar 1.8 GHz 
GPU: AMD GPGPU-capable Radeon GCN 
RAM: 8 GB de memoria GDDR5  
HDD: 500GB / 1TB 
SoundCard: AMD TrueAudio 

Modelo de monetización  
Teniendo ya la información acerca de nuestros competidores directos e 
indirectos, sus valores de mercado y ventas. Hemos visto que el precio de 
nuestro competidores directos fluctúa en los rangos de $5 (​140​) a $15 dólares 
(​Geometry Wars 3: Dimensions Evolved​). 
Por esa razón hemos decidido que el precio tentativo de nuestro juego 
será de ​$4,99 dólares (juego base)​, ya que está en el punto medio entre un 
juego indie de poco contenido (como lo es 140) y otras producción que si bien 
son indie son de mayor tamaño (como Hotline Miami 2 que cuesta $14,99). 
Además, siguiendo el ejemplo del propio Hotline Miami (siendo un juego en el 

7
que también la banda sonora es muy importante) habrá un paquete de: ​Juego 
+ Banda Sonora​ en ​$9.99 dólares​.  

Miras del proyecto (scope) 

 

Presupuesto y tiempos 
 

Equipo 
1. Nombre: ​Miguel Quezada 
Área: Dirección de arte, UI, programación (core gameplay) y 
diseño de niveles (integración musica/enemigos) 
Responsabilidad: Hacer cumplir deadlines del equipo y 
presentación del proyecto a terceros 
2. Nombre:​ Ulises Olvera 

8
 Área: Diseño de niveles (diseño de oleadas), programación 
(puntaje y manejo de transformaciones) y animación  
Responsabilidad: Hacer cumplir deadlines 
3. Nombre: ​Pablo Ramírez (Aladar) 
Área: Banda sonora, diseño sonoro (UI) y diseño de niveles 
(música procedural) 
Responsabilidad: Hacer cumplir deadlines  
 

Licencias (programas y plug-ins) 

A. Programas 
a. Maya (licencia de estudiante) 
b. Photoshop (licencia de estudiante) 
c. Unity 2017(versión personal) 
d. Substance (licencia de estudiante) 
B. Plug-ins 
a. FMOD (licencia para indies - solo requiere acreditar al plug-in 
en los créditos del proyecto) 
b. Koreographer (plug-in para Unity / Precio: 36$ dólares) 
 

Referencias 

En general la filosofía de la dirección de arte de este juego es “hacer 

menos con más” y la “forma sigue a la función”. Por ello como línea general se 
eligió al movimiento ​Light and Space,​ el cual destaca por su manejo simple y 
definido del color en el espacio. 
Otra  parte  importante  para  definir  la  dirección  de  arte  fue  el  libro 
Interaction  of  Color  ​de  Josef  Albers  para  definir  paletas  de  colores  para  los 
distintos personajes y escenarios. 

9
  
Akhob d​e James Turrell y la portada de Interaction of Color de Josef Albers 

En cuanto al diseño de personajes en el juego, la referencia principal 

fueron formas de vida primitivas como los trilobites o fitoplancton para dar un 
aire minimalista y primal tanto al personaje del jugador como a los enemigos, 
sin caer en que el estilo minimalista fuera muy parecido al de juegos como (​140 
o ​THOTH​) 

 
A la izquierda un ejemplo de filo plankton y a la derecha uno de trilobite 
 
 
Por otro lado, en cuanto a gameplay, las principales referencias fueron 
Geometry Wars​ y ​Rez​ (2001, Sega). El primero por la cuestión de la experiencia 
dinámica arcade que proporciona -mecánicas sencilla en un entorno que se va 
volviendo progresivamente desafiante- y el segundo por su revolucionaria (para 
su tiempo) integración de música con gameplay -el cual es un objetivo que 
perseguimos con este proyecto-. 
 
 
 
 
 

10
  

Descripción de Proyecto (Brief): 

 
“greet  the  light”  nace  de  la  necesidad  de  trabajar  el  audio  de  un  videojuego 
fuera  del  pipeline  usual  de  la  industria  de  videojuegos,  el  cual  es  heredado 
directamente  del  cine.  En  él,  el  audio  (diseño  sonoro  y  banda  sonora)  es  lo 
último  que  se  deja  en  el  desarrollo  de  la  producción,  en  la  parte  de  la 
postproducción. 
En  nuestro  caso,  la  idea  es  tener  a  nuestros  compositores  de  la  banda 
sonora  desde  el  principio  del  proceso  creativo  y  a  lo  largo de la producción del 
proyecto.  Esto  debido  a  que  la  banda  sonora  será  la  base  para  desarrollar  las 
mecánicas  mediante  su  interacción con el sistema de aparición de los enemigos 
y los patrones de movimiento de los mismos 

Puntos principales 
 
● Perspectiva top down en el que el jugador utiliza distintas 
transformaciones (disparo, dash y trail) para enfrentarse a oleadas de 
enemigos generados y movidos a partir de clips de audio. 
 
● Alto​ pacing ​con el objetivo de meter al jugador en un estado de éxtasis 
en conjunto a la interacción del audio con la luz y la generación de 
enemigos (4 tipos) 
 
● Música procedural a partir de probabilidades desarrollado a través de un 
código en C# que incide en el desarrollo del nivel, mediante: Respawn de 
enemigos, patrones de enemigos y animaciones de enemigos. 
 

11
 ● Diseño de oleadas dependiente de la música, que hace al jugador 
internalizar el funcionamiento de la pieza para saber qué enemigos 
vienen.. 
 

Controles 

  
 

Game Flow  

 
12
 

Pacing 

 
Como se puede ver en la gráfica, el ritmo planteado para los niveles del 
juego está basado en el principio de que ​a mayor cantidad de enemigos, será 
mayor la cantidad de tensión del jugador. ​Al final de los niveles existirá un 
decremento en su cantidad para bajar esta tensión. 
De acuerdo a la estructura de la canción convertida a procedural vimos 
con Pablo una duración aproximada que mantuviera coherente la estructura, la 
cual quedó en dos minutos (119 segundos; es decir, un loop de 7 segundos 
multiplicado por 17 veces). La canción de forma lineal dura poco más de 5 
minutos, pero al momento de hacer pruebas del alpha con ésta para el sistema 
de enemigos, llegaba un tiempo en que la concentración de la gente bajaba. 
Esto resulta un inconveniente, ya que queremos que nuestro jugador esté en un 
estado constante de vigía y ofensiva. A mayor brevedad de la experiencia, 
serán menos las distracciones y por tanto, mayor la concentración. (Baron, 
2012, 
http://www.gamasutra.com/view/feature/166972/cognitive_flow_the_psychol
ogy_of_.php​) 
 
 
 
 
 
 
 
 

13
 

Oleadas 

 
La aplicación de la aleatoriedad en juego no es completamente sin 
deliberación. Para esta cuestión ayudó el sistema procedural de probabilidades 
de los clips de audio explicado más a detalle en la sección ​Diseño de oleadas. 
Básicamente, cada forma geométrica en la imagen superior es un patrón 
a seguir por un determinado tipo de enemigos ligado a un clip de audio (que lo 
hace aparecer y animar) 

14
  
La justificación de qué tanta influencia tiene la aleatoriedad en nuestra 
experiencia de juego viene del video de Extra Credits llamado ​The Price of 
Randomness (​ https://www.youtube.com/watch?v=ry2xz5yYZwY), en él se 
establece el ​Portnow’s Postulate​ ​que establece una razón de aleatoriedad apta 
para un juego en base al tiempo invertido en una partida. 
La fórmula es la siguiente: 
 
Frustración del jugador ​(FR)​ = Tiempo invertido en la partida ​(t)​ * 
Porcentaje de perder ese tiempo ​(Pt) 
 
El despeje para obtener el porcentaje de perder el tiempo de partida es 
el siguiente: 
 
Porcentaje de perder ese tiempo ​(Pt)​ =  
Frustración el jugador ​(FR)​ / Tiempo invertido en la partida ​(t)   
 
En nuestro juego, por ejemplo queremos que la frustración de nuestro 
jugador sea de un porcentaje de .5. ​(FR = .5)​ y la duración de la partida por el 
track es de 2 minutos ​(t = 2)​, p
​ or tanto el porcentaje de perder el tiempo de la 
partida debería ser: 
Pt = .5/2 
Pt = .25 
Pt = 25% 
15
 Es decir, de cada cuatro partidas jugadas, 1 ocasionará molestia en el 
jugador por los factores, lo cual no es un porcentaje tan alto considerando lo 
breve de la experiencia y la facilidad con la que se puede volver a jugar el 
nivel.​Al 

Mecánicas principales (core) - Justificación 

Disparo (tiempo ilimitado) 

● Se decidió que esta fuera la 
transformación principal 
debido a su variedad de rango 
para manejar cantidad de 
enemigos, pero a cambio de 
eso se le dio poca fuerza a las 
balas para que el jugador vaya 
recurriendo a otras soluciones 
para hilar combos. 
   
 

Dash (tiempo - 7 segundos)   

● Esta transformación nace de 
la necesidad de tener una 
forma rápida de escapar de 
grupos importantes de 
enemigos al estar rodeados de 
ellos. Su impulso permite 
poner a contracara de los 
enemigos que te siguen por 
default e ir buscando a otros 
que se mueven por patrones 
para continuar con tu cadena. 
 
 
 
 
 
16
 

Trail (tiempo - 12 segundos) 

● El trail cumple una doble 
función dentro de los niveles: 
Puede servir para cortar el 
paso de los enemigos con 
patrones de movimiento 
anticipadamente o como 
escudo a enemigos que se 
dirigen al jugador 
 
 
 
A lo largo de las sesiones de prueba (con conocidos, personas que 
pasaban, alpha y SAE Arcade), los tiempos de transformaciones han cambiado y 
el pacing de los patrones también. 
En general, el comportamiento de los enemigos se ha diversificado de 
tal forma que no sólo se depende para el desarrollo de los niveles en el 
spawning por topes de frecuencia de enemigos que siguen al jugador y que 
permite darle interés al acto de ir hilando un combo para obtener la mayor 
puntuación posible. 
 

17
  

Narrativa 
Sinopsis 

El énfasis del juego está en la experiencia arcade, pero existe un factor 

por medio de distintas frases antes de los niveles que permite al jugador 
deducir una narrativa implícita dentro del juego y llegar a sus propias 
conclusiones. 

Historia 

El  juego  trata  de  que  este  personaje  que  controlamos  está  buscando  el 
origen  de  su  universo  y  el  por  qué  de  sus  cambios  atravesando  múltiples 
obstáculos.  Básicamente,  encontrarse  con  la  luz.  El  diseño  de  los  niveles  y  el 
aspecto  en  texturas juegan un papel casi narrativo a la hora de jugar. Gracias a 
los  frases  en  los  tiempos  de  carga de los niveles podemos entender un poco del 
contexto, el mismo gameplay es el que te va revelando la historia.  
El  jugador  tiene la opción de seguir una historia o simplemente ignorarla, 
como  tal  el  juego  no  tiene  un  aspecto narrativo muy marcado; sin embargo, no 
carece de él porque está embebido en la esencia del juego. 

18
Gameplay (diseño de experiencia y nivel) 

Diseño de experiencia 
Como se dijo previamente en el documento, el objetivo en los niveles es 
superar las distintas canciones con la mayor puntuación posible.  
El jugador tiene que entrar en un estado de dinamismo para conjugar las 
distintas transformaciones y lograr aumentar su número de cadena, logrando 
así multiplicar y multiplicar muchos puntos. 
El sistema de cadenas existe para motivar al jugador a tomar una 
estrategia agresiva en su aproximación a los enemigos, en lugar de una pasiva 
(que era una actitud común en pruebas iniciales del juego) 

  

19
Diseño de nivel (puntaje y oleadas) 

 
Para lograr un diseño con sincronización musical de los sistemas de enemigos 
recurrimos a Koreographer, un plug-in para Unity que permite sincronizar audio 
con eventos de ​gameplay p ​ or medio de marcadores en una pista de audio y 
tener estos por categorías llamadas eventos en el plug-in. 
Éste tiene una función llamada “OnMusicalShoot()”, la cual permite 
registrar los marcadores de tiempo bajo una unidad de tiempo diferente al 
Update(), que es más correspondiente a cómo transcurre el audio.  

 
Patrones de movimiento de los enemigos. Cada figura de líneas blancas representa un patrón 
 
Para linkear cada clip de audio indivudual se utilizó el sistema de 
reproducción de audio del plug-in (Multi Music Player), el cual requiere de un 
archivo Koreography (manager de los eventos) por clip y tiene la opción de 
agregar manualmente un componente Audio Source individual.   

20
  
Multi Music Player de Koreographer que permite controlar los manager de eventos de los clips en un solo lugar 
 
En nuestro caso, los Audio Source se fueron agregando por GameObject a 
cada clip (cada GameObject está nombrado acorde a la forma de su patrón de 
movimiento, los cuales son una secuencia de puntos por script). La 
organización quedó de la siguiente manera: 
 
GameObject del loop Archivo de audio

LoopHexagono agu_Loop_A

LoopCruz agu_Loop_D

LoopSierra agu_Loop_F

LoopDNA agu_Loop_G

LoopCuadrado agu_Loop_H

LoopTriangular baj_Loop_H

LoopDiamante baj_Loop_C

LoopEstrella baj_Loop_B

LoopRectangular base_Loop_B

LoopDosLineas base_Loop_H

LoopDosSierras medios_Loop_A

LoopDosTriangulos medios_Loop_B

LooPentágono medios_Loop_C
 

21
 De los 13 clips de audio de 7 segundos en los que se dividió ​Ice Church​, se 
les agregaron eventos de 3 categorías: spawn, movement (se pausa o avanza en 
el) y animación (algún giro en los intervalos de pausa). 

 
Multi Music Player de Koreographer que permite controlar los manager de eventos de los clips en un solo lugar 
Dentro de Koreographer hay dos categorías de marcadores de eventos, 
los Span (que cubren un periodo de tiempo) y los OneOff que sólo ocurren 
cuando se llega a cierta marca dentro del clip.  
Para el sistema de spawn los que se utilizaron fueron los OneOff, 
mientras que para el movimiento en los patrones y las animaciones se usaron 
los Span, procurando dejar intervalos de pausa en el movimiento para las 
animaciones (al ser la mayoría de enemigos basados en espirales o tentáculos, 
todas las animaciones son de giros) Éste es un ejemplo aplicado a 
LoopHexagon: 
 

 
A la izquierda se ven los eventos Span de la categoría Anim y a la derecha se ven los de categoría movimiento. 
Nótese que en los intervalos de movimiento es cuando pasa la animación. 
Al script que identifica el patrón a seguir de cada prefab de enemigo se 
le agrega un OnMusicalShot() para que registre estos eventos y haga las pausa 
de acuerdo a lo que esté pasando en el clip o la animación correspondiente. 

22
 Script de HexagonPath para seguir el patrón. Al encontrar un evento que tenga como producto un int, avanzará, 
pero si no, no. 
Por otro lado, el sistema de spawning depende directamente del manejo 
procedural de los loops -explicado en la siguiente sección-, ya que es 
dependiente del volumen que tengan los clips en cierto momento preciso. 
Entonces, dependiendo de las probabilidades que hayan salido, serán los 
enemigos que saldrán.  

 
Script del sistema de spawning de HexagonLoop, el cual registra el volumen de su Audio Source correspondiente al 
tener un evento OneOff 

23
Reparto de enemigos (puntajes y patrones) 

Los puntajes son en base 5 y de una cantidad que multiplicada pueda 

redondearse y se note una cantidad importante de puntaje para aumentar a 
esta sensación de exageración de las capacidades del jugador en el espacio del 
nivel. 
 
Enemigo  Puntos que da Patrones a los que pertenece 

25  1. LoopHexagono 
2. LoopCruz 
  3. LoopSierra 
4. LoopDNA 
5. LoopCuadrado 
(grupo de Agudos 
de la canción) 

50 1. LoopTriangular 
2. LoopDiamante 
3. LoopEstrella 
(grupo de Bajos de 
la canción) 

100 1. LoopRectangular 
2. LoopDosLineas 
(grupo de Base de 
la canción) 

24
 150  1. LoopDosSierras 
2. LoopDosTriangulos 
3. LoopPentagono 
(grupo de Medios 
de la canción) 

Sistema procedural 
Este sistema funciona a partir de reproducir los clip de audio -con una duración 
de 7 segundos y 4 barras de 130 bpm todos-de los que dependen los loops. 
Todos están activos, pero no todos con volúmen. 
Lo que hace el sistema es a partir de probabilidades de grupos regir que 
clip será el que suene a partir de un sistema de fades (fade-ins y fade-outs). 
 

Nombre del grupo Archivo del grupo Probabilidad dentro del grupo

Agudos 1. LoopHexagono 1. 5%
2. LoopCruz 2. 10%
3. LoopSierra 3. 33%
4. LoopDNA 4. 50%
5. LoopCuadrado 5. 2%

Bajos 1. LoopTriangular 1. 10%

2. LoopDiamante 2. 70%
3. LoopEstrella 3. 20%

Base 1. LoopRectangular 1. 33%

2. LoopDosLineas 2. 34%
3. (Silencio) 3. 33%

Medios 1. LoopDosSierras 1. 33%

2. LoopDosTriangulos 2. 34%
3. LoopPentagono 3. 33%

25
 Por medio de la función InvokeRepeating se hace el manejo de los ​fades 
que permite la variación dentro de la canción. La función ChangeLoop() 
corresponde a cuando entran los ​fade-ins​ y la función FadeLoop() a cuando 
entran los ​fade-outs​. (Nótese que las funciones tienen tiempos diferentes 
debido a que tiene que haber un espacio entre una y otra para que no se 
encimen.) 

 
Sistema de invokes que permite cambiar de loops periódicamente al nivel mientras se reproduce 
 
Inicialmente, este sistema no tenía principio ni fin, por lo que Ulises y yo 
tuvimos que ver con Pablo una duración aproximada que mantuviera coherente 
la estructura, la cual quedó en dos minutos (119 segundos; es decir, un loop de 
7 segundos multiplicado por 17 veces).  

 
 
 
 
 
 

26
Procedimientos de assets 
- 2D 
- Texturas de personajes (tranformaciones y enemigos) 

 
En los primeros prototipos el glow de las transformaciones del personaje y 
enemigos iba a ser por Emissive Map, pero el sistema de Post Processing de 
Unity resultó un inconveniente, ya que al sacarle el Bloom que queríamos a los 
mapas, el resto del nivel también erá afectado. Ejemplo: 
 

27
 Gameplay con Bloom general de Post Processing aplicado 
Debido a esto, se tomó la decisión de darle el glow a personaje y 
enemigos por shader para tener control de cuánto brillo tiene cada parte de los 
mismos. 
El shader solo admite color sólido y tiene una variable de intensidad, la 
cual se conecta al componente individual de Bloom de la cámara (sin necesidad 
de tener otras cosas del Post Processing como lo son: Aberración Cromática o 
Motion Blur). 
 

 
Material de personaje con el Glow shader aplicado 

 
Gameplay con Glow shaders aplicado en personajes y enemigos 
 
 
 
 

28
 
- Menús (En progreso) 

 
Las interfaces se hicieron de tal forma que coincidieran con el estilo 
artístico general del juego.  
La herramienta de Photoshop llamada Mosaico fue vital para esto, ya que 
se usó a las gradientes aplicadas para lograr el escalonamiento y traspaso de 
los colores gradual. Para repartir los diferentes assets de cada escena se usó la 
herramienta Generar Recursos de Imagen, la cual ofrece las diferentes 
secciones de la escena por partes al estar en carpetas individuales sin 
necesidad de armar un tileset aparte del mockup. 
La jerarquía es la siguiente: 
 
Title Screen -> Main Menu -> Shuffle 
Level Select -> Nivel 1 / Nivel 2 
Options -> Controls 
Exit Settings 
Credits 

29
  
 
- HUD 

 
Lo primero que se hizo para definir el HUD establecer una arquitectura 
de información, ésta quedó definida por los siguientes 3 datos que debería dar: 
 
1. Salud 
2. Tiempo de transformación  
3. Transformación actual 
 
Por medio de pruebas de usabilidad se fue depurando el HUD hasta llegar 
al estado de la derecho. A diferencia de la primera propuesta, ésta muestra el 
estatus de las otras dos transformaciones con el fin de dar feedback continuo al 
jugador y que con ello, él pueda armar estrategias acorde a qué tan llena está 
una u otra barra 

30
  

- 3D 

- Personajes (transformaciones y enemigos) 

El  diseño de personajes en un principio para los bocetos para los bocetos fue en 
base a dos reglas: 
1. Las transformaciones de los personaje se basarán en rectas 
2. Los enemigos se basarán en curvas 

 
Concepto de personajes en sucio y vectorizado 

31
  
Modelado de bocetos para pruebas de color y glow 
En  cuanto  a  referencias,  para  mantener  esta  sensación  de  pureza dentro 
del  juego  nos  basamos  en  formas  de  vida  muy  primitivas  (tanto en forma como 
en tiempo de existencia) como los son los trilobites y el fitoplancton. 
 

 
Comparativa de referencias con diseño de personajes 

32
 Por  otro  lado,  para  las  transformaciones  del  personaje  hubo  una  reglas 
más  al  ir  diseñando  su  forma.  ​Todas  las  las  transformaciones estarán basadas 
en una figura básica. 
Esto queda claro a primera vista: 
● La transformación de disparo está basada en cuadrados 
● La transformación de dash está basada en triángulos 
● La transformación de trail está basada en trapecios 

 
Transformaciones de personajes 

- Color de personajes 

 
Prueba A/B de paletas de color 
Para  el  definir  una  paleta  de  color  para  los  personajes  y  otra  para  los 
enemigos  recurrimos  a  la  técnica  conocida  como  ​gamut  mapping,​   la  cual  sirve 
para  limitar  una  paleta  de  color  en  base  al  círculo  cromático.  Las  paletas  de 

33
enemigos  y  transformaciones  del  personaje  están  en  polos  opuestos  del círculo 
cromático para expresar su oposición. 

 
Gamut mapping. Recuperado de: https://ar.pinterest.com/pin/371054456771769294/?lp=true 
En  la  primera  encuesta  de  concepto  se  hizo  una  prueba  A/B  para  probar 
las  paletas,  pero  los  resultados  no  fueron  satisfactorios.  Por  lo  que  al  ​gamut 
mapping  l​ e  adherimos  otra  herramienta:  la  cuenta de Twitter ​colorschemez​, la 
cual  es  un bot que publica distintas paletas de color. En ella buscamos de entre 
las  paletas  las  más  cercanas  a  nuestra  propuesta  y  volvimos  a  hacer  pruebas 
A/B. 

 
Pruebas A/B de paletas de color en neón(izquierda) y proporciones de paletas de color (derecha) 

 
Pruebas A/B de paletas de color en neón(izquierda) y proporciones de paletas de color (derecha) 

34
 En  este  caso  las  encuestas  resultaron  más  favorables  y  nos  permitieron 
comenzar  a  trabajar  en  la  siguiente  etapa  de  diseño  de  los  personajes:  la 
aplicación de gradientes. 

 
Opciones de gradientes para personajes y enemigos 
 

- Diseño de escenarios 

 
Superficie de revolución. Recuperado de: https://es.wikipedia.org/wiki/Superficie_de_revoluci%C3%B3n 
Para  hacer  referencia  a  esta  onda  planetaria  que  envuelve  a  la  historia,  las 
superficies  de  los  niveles  tendrán  formas irregulares (superficies de revolución) 
que comuniquen esta idea, pero no del todo para darle un toque de fantasía. 

35
  

 
Conceptos de escenarios y placeholder de escenario para alpha 

 
Segundo concepto de escenario 
 
Para coincidir con la vibra oceánica que tienen tanto personajes como 
enemigos, se decidió cambiar el tipo de material del escenario a uno de perla.  
Inicialmente, era un material más blanquecino, pero su color absorbía la 
luz de los personajes. Por ello, para el final se tomó la decisión de sí mantener 
el holograma de perla, aunque con una textura más oscura. 

36
  
Perla aplicada de la versión final 
 

- Programación 

37
- Sonido 

 
Para el audio en el juego se dividió en dos secciones: Nivel y Menús. La 
canción del nivel se dividió en loops de la siguiente forma: 
 
 
GameObject del loop Archivo de audio

LoopHexagono agu_Loop_A

LoopCruz agu_Loop_D

LoopSierra agu_Loop_F

LoopDNA agu_Loop_G

LoopCuadrado agu_Loop_H

LoopTriangular baj_Loop_H

LoopDiamante baj_Loop_C

LoopEstrella baj_Loop_B

LoopRectangular base_Loop_B

38
 LoopDosLineas base_Loop_H

LoopDosSierras medios_Loop_A

LoopDosTriangulos medios_Loop_B

LooPentágono medios_Loop_C
 
Para los sonidos del menú se hizo un asset list: 

 
 
- Animaciones 
 

39
 En cuanto a animaciones, el trabajo se dividió en dos categorías: Menús y 
Enemigos (que son dependientes de la música). 
Todas las animaciones de Menús fueron por script, mediante un manager 
que movía, escalaba o rotaba tomando en cuenta un ​offset d ​ e la posición 
original del asset. 
Por otro lado, se decidió que para los enemigos al estar basados en 
espiral y curvas en general, su sistema de rig estuviera basado en el usual de 
las colas. 

 
 
 

40