MEMORIA ESCRITA DEL PROYECTO

Juan Antonio Vicente Pastor

9 de diciembre de 2021
Tutor: Álvaro Villa
1s2122

1
ÍNDICE

1. INTRODUCCIÓN ..................................................................................... 4

1.1 Motivación ................................................................................................ 4

1.2 Objetivos propuestos ................................................................................ 4

2. METODOLOGÍA, TECNOLOGÍAS Y HERRAMIENTAS .......................... 4

2.1 Metodología.............................................................................................. 4

2.2 Herramientas ............................................................................................ 5

2.3 Tecnologías .............................................................................................. 8

3. DESARROLLO DEL PROYECTO .......................................................... 11

3.1 Idea ........................................................................................................ 11

3.2 Preproducción ........................................................................................ 11

3.3 Estimación de recursos y planificación ................................................... 11

3.4 Producción ............................................................................................. 12

3.5 Testing y pruebas ................................................................................... 12

4. CONCLUSIONES ................................................................................... 13

4.1 Objetivos alcanzados ............................................................................. 13

4.2 Conclusiones del trabajo ........................................................................ 13

5. GLOSARIO............................................................................................. 31

6. BIBLIOGRAFÍA ...................................................................................... 33

7. ANEXOS ................................................................................................ 35

Página 2 de 36
ÍNDICE DE ILUSTRACIONES

Figura 1. Interfaz de 3dsMax. Fuente: Elaboración propia ......................................... 5

Figura 2. Interfaz de zbrush. Fuente: Elaboración propia........................................... 6
Figura 3. Interfaz de Character Creator. Fuente: Elaboración propia ......................... 6
Figura 4. Interfaz de Unity 3D. Fuente: Elaboración propia........................................ 7
Figura 5. Interfaz de Substance Painter. Fuente: Elaboración propia. ....................... 7
Figura 6. Interfaz de Marvelous Designer. Fuente: Elaboración propia...................... 8
Figura 7. Modelo realizado en Character Creator. Fuente: Elaboración propia. ...... 14
Figura 8. Boceto de NPC. Fuente: Elaboración propia............................................. 14
Figura 9. Modelo realizado en 3dsMax. Fuente: Elaboración propia. ...................... 15
Figura 10. Modelo realizado en 3dsMax. Fuente: Elaboración propia. .................... 16
Figura 11. Modelo realizado en 3dsMax. Fuente: Elaboración propia. .................... 16
Figura 12. Rig facial realizado en 3dsMax. Fuente: Elaboración propia................... 17
Figura 13. Rig realizado en 3dsMax. Fuente: Elaboración propia. ........................... 18
Figura 14. Ropa realizada en Marvelous Designer. Fuente: Elaboración propia. .... 22

Página 3 de 36
1. Introducción

1.1 Motivación
Tras observar varios videojuegos de este tipo se han observado ciertas
carencias que, en mi opinión, pueden ser implementadas, mejorando la inmersión en
el videojuego y haciendo de éste una experiencia más realista.
1.2 Objetivos propuestos
1.1.1. General:
• Sentar las bases para el desarrollo de un videojuego de supervivencia
con mecánicas más realistas que las observadas en títulos actuales.
1.1.2. Específicos:
• Terreno deformable en tiempo real.
• Implementación de dinámicas de fluidos realistas, que interaccionen con
el mundo y su modificación en tiempo real.
• Sistema de escalada.
• Sistemas de gestión y producción de recursos.
• Sistema de erosión natural del terreno.
• Sistema de climatología que influya en el mundo y sus habitantes.
• Sistema de construcción, integración en terreno de construcciones
abandonadas.
• Definir cantidad de animaciones necesarias.
• Bases de sistema de IA.
• Sistema de simulación de ropa.

2. Metodología, tecnologías y herramientas

2.1 Metodología.
Se ha utilizado el sistema de modelado en low poly en herramienta de
modelado, añadir detalles en herramienta de esculpido y realización de bake de
detalles en la herramienta destinada para ello. Se elige este sistema pues, teniendo
definidos los objetos a modelar, considero que se ahorra mucho tiempo evitando el

Página 4 de 36
proceso de retopología, si bien es cierto que ya existen herramientas que automatizan
este proyecto lo cierto es que siempre hay que solucionar pequeños errores que
surgen en el proceso. Para el modelado de props y animales se ha optado por
combinar 3ds max, por tener un conocimiento más profundo y automatizado de esta
herramienta del que se tiene de Maya, con Zbrush para modelado en alta polinización.
Con el avance de tecnologías y programas tales como Character Creator.
MakeHuman y, el más reciente, Metahuman, se considera innecesario invertir tiempo
en el desarrollo de personajes humanoides, por lo que se utilizaran estas soluciones
para el desarrollo, en caso concreto de este proyecto se ha utilizado Character Creator
para la realización del modelo del avatar controlado por el usuario, pues es un
programa del que ya tengo licencia y que es capaz de exportar a los motores gráficos
más utilizados en la actualidad.
Se han reutilizado los scripts necesarios para el control de los diversos
elementos en el proyecto, todos de elaboración propia, en cualquier caso, se han
necesitado modificaciones para adaptarlos a las nuevas animaciones y estados.

2.2 Herramientas
Se ha decidido usar las siguientes herramientas, en todos los casos es
debido a la experiencia que se tiene con ellas, lo que repercute en menores
tiempos de desarrollo.
• Autodesk 3ds max.

Figura 1. Interfaz de 3dsMax. Fuente: Elaboración propia

Página 5 de 36
 • Pixologic Zbrush.

Figura 2. Interfaz de zbrush. Fuente: Elaboración propia.

• Reallusion Character Creator.

Figura 3. Interfaz de Character Creator. Fuente: Elaboración propia

Página 6 de 36
 • Unity.

Figura 4. Interfaz de Unity 3D. Fuente: Elaboración propia.

• Adobe Substance Painter.

Figura 5. Interfaz de Substance Painter. Fuente: Elaboración propia.

Página 7 de 36
 • Virtual Fashion Inc Marvelous Designer.

Figura 6. Interfaz de Marvelous Designer. Fuente: Elaboración propia.

2.3 Tecnologías
2.3.1. Simulación de terreno con voxel.
Se ha estudiado la posibilidad de realizar el terreno mediante el uso del
sistema de voxels.
El voxel queda definido como un pixel con valor de profundidad, además de
sus valores de posición x e y, esto implica que el pixel deja de ser un componente
de hardware de la pantalla a un punto en la resolución de renderizado de la cámara.
La idea fue desarrollada hace varios años y estudiada como posible sustitución al
sistema de polígonos, pero pocos títulos han sido realizados usando este método,
pues la necesidad de realizar cálculos por cada pixel en cada fotograma es
demasiado grande, más teniendo en cuenta las resoluciones actuales.
Actualmente hay varios títulos que han hecho uso de un sistema similar, en el
que se crean chunks para modelar todos los componentes visibles en pantalla. Un
chunk no es mas que una forma geométrica, generalmente un cubo, que se usa a
modo de pixel de grandes dimensiones, y que, a su vez, puede ser descompuesto
en varios chunks mas pequeños, este sistema lo que consigue es utilizar una figura
geométrica en 3d, de tamaño configurable, a modo de ladrillo para fabricarlo todo,
de este modo se consiguen las ventajas del uso de voxel pero sin llegar a

Página 8 de 36
sobrecargar el sistema, a costa, eso sí, del realismo de los objetos creados, que
quedan escalonados, como si estuviesen hechos de bloques de construcción.
En los últimos años han ido surgiendo varios plugins que solucionan ese
problema en gran parte, pues aunque sigue existiendo el concepto de chunk y este
sigue usándose, al objeto creado se le da un acabado gracias a un añadido de los
chunk, pues cada uno de esos esta configurado con uno puntos desde los que se
puede construir una malla en tiempo real entre cada uno de esos puntos y otro
punto del chunk mas cercano, todo este sistema es configurable, de tal modo que
pese a crear un terreno con esos chunk se obtiene un resultado suavizado, mas
adaptado a lo que vemos en el mundo real. Este sistema posibilita que el terreno
sea excavable, pues cada vez que se elimina un chunk la malla de alrededor se
recalcula para ofrecer una apariencia consistente, esto hace que acciones como
cavar una cueva en el terreno sean posibles, aspecto que no se puede realizar en
una malla poligonal clásica en tiempo real. Este sistema es capaz de formar un
terreno por capas, imitando sedimentos y, por lo tanto, materiales, pues cada chunk
es configurable como cualquier otro objeto de la escena.
Como parte negativa hay que destacar lo limitado del tamaño del mapa que
se puede crear, teniendo en cuenta que cada chunk necesita ser recalculado en
cada frame, por lo que este sistema de suavizado no se esta aplicando a
aplicaciones multijugador. Existe, no obstante, la posibilidad de crear un sistema
hibrido, pues al suavizar la malla por este sistema se crea una malla poligonal, que
puede ser usada en tiempo real como terreno poligonal, evitando el calculo de todos
los chunk, hasta el momento en el que se vaya a modificar el terreno, en el cual se
pueden cargar los chunk de un cierto radio y recalcular la malla generada en tiempo
real de una zona lo suficientemente pequeña como para no suponer una carga
excesiva para el sistema, dado que a cada frame se recalcula el suavizado al
terminar la edición del terreno este vuelve a quedar como una malla sólida, con sus
modificaciones realizadas de forma poligonal. Esto supone un cambio, pues aunque
los entornos 3d existen desde hace décadas lo cierto es que siguen siendo un
entorno tridimensional sobre un mapa bidimensional, lo que implica que no se
pueden crear arcos, cuevas ni ningún sistema que implique que haya dos
superficies en las mismas coordenadas pero a distinta altura integrado en el mismo
terreno, recordemos que la creación de terrenos mediante el sistema incluido en los

Página 9 de 36
motores gráficos tiene grandes ventajas en cuanto a gestión de recursos, añadir
objetos para crear estos arcos o cuevas supone aumentar esa carga de trabajo, por
lo que este es un paso importante que, no obstante, tiene sus limitaciones y
carencias a día de hoy.
En cualquier caso, es un sistema que merece la pena ser estudiado, pues
supone el siguiente paso, junto a la dinámica de fluidos en tiempo real, de cara al
aumento del realismo en los videojuegos.
2.3.2. Escalada.
Para desarrollar este sistema se han tenido en cuenta diferentes ejemplos
existentes en la actualidad en el mercado, que han resultado bastante simples, pues
la sensación que se consigue es la de estar flotando cerca de la pared.
Se han buscado nuevas alternativas, una de ellas, la base para el sistema
que se quiere implementar, consiste en realizar las animaciones necesarias para la
escalada pero usando las herramientas de simulación dinámica del motor grafico
para controlar las IK del rig del modelo a utilizar, esto permite un grado de realismo,
con balanceos, saltos, movimiento, etc., muy buenos, pero que aún así necesita de
un elemento, los agarres, que deben ser colocados manualmente por todas las
superficies que se considere que se quiera usar en la escalada, esto agarres no son
mas que formas geométricas, visible o no, etiquetadas como tales, de tal modo que
se puede controlar por código. El principal problema de este método consiste en el
tiempo de desarrollo que conllevaría el mapear todo el mapa de un juego
multijugador con este sistema, es decir, de forma manual, además de tener que
controlar la profundidad a la que se coloca, si es visible o no, colocarlos a cierta
distancia para que el jugador pueda utilizarlos, etc. Por lo que se ha desarrollado
una idea para solucionar este problema.
En todos los motores gráficos existen una serie de parámetros relacionados
con el texturizado del terreno, que permiten usar cierta textura en cierta inclinación
de la malla o a ciertas alturas, un sistema similar se usa para automatizar procesos
en ciertos títulos para diferenciar cuando se tiene que usar la animación de andar
por una pendiente o saltar para superar el obstáculo. La idea es utilizar dicho
sistema para analizar todas las mallas del mapa, durante el proceso de desarrollo,
para encontrar diferencias de profundidad de la malla en donde se puedan realizar
esos agarres, eso podría hacerse analizando texturas (AO o bump), analizando

Página 10 de 36
superficies geométricas que sean creadas en programas externos (montañas,
paredes verticales) o de forma manual en el caso de las geometrías destinadas al
sistema de construcción. Esto permitiría un considerable ahorro de tiempo, un
aumento de la sensación de realismo y un reto importante para los jugadores, pues
nadie sabría donde hay una vía segura por la que llegar a una cima, aumentando la
vida útil del titulo obligando a explorar todo el mapa para encontrar esos caminos.
Como añadido resultaría en una oportunidad para añadir ciertas estadísticas que
permitieran, por ejemplo, llegar a puntos de apoyo mas lejanos cuanto mayor sea el
valor de estas.

3. Desarrollo del proyecto

3.1 Idea
La idea principal es integrar terreno y agua que puedan ser modificables e
influir en ecosistemas del mundo, ser usados como arma o como defensa. Así mismo
se incluirán otras acciones, tales como la escalada y sistema de gestión y obtención
de recursos que tendrán una visión más realista, aprovechando el terreno modificable;
huyendo de piedras que vuelven a aparecer tarde o temprano, necesitando plantar
árboles para seguir produciendo madera, usando lo extraído al fabricar cuevas, etc.
Se realizará sobre la base de un videojuego de tipo supervivencia, en el cual
se pueden aplicar de forma más adecuada estas ideas, siendo más influyentes que
en cualquier otro tipo de videojuego.
3.2 Preproducción
• Se definen los objetivos a alcanzar.
• Se recopila documentación técnica (voxel y dinámica de fluidos).
• Se definen las herramientas a utilizar.
• Se definen número de animaciones.
• Se define la composición del esqueleto.
3.3 Estimación de recursos y planificación
Se estiman necesarias 580h para la realización de este proyecto, según
Anexo1.
4.3.1. Se requieren los siguientes recursos:
• Ordenador con S.O. Windows (700€ aproximadamente).

Página 11 de 36
 • Intel I7 o similar.
• 64 Gb RAM.
• Tarjeta gráfica compatible con DirectX11.
4.3.2. Herramientas:
• 3ds Max. Licencia desde 6.063€ por 6 años.
• Zbrush. Licencia desde 895€ (perpetua) 179$ (perpetua zbrush core).
• Character Creator. Licencia perpetua 142€.
• Unity. Usada versión gratuita.
• Substance Painter. Licencia desde 126€.
• Marvelous Designer. Licencia desde 39$/mes (personal).
3.4 Producción
• Modelado de avatar.
• Creación de Props y npcs.
• Texturizado.
• Rig.
• Creacion de animaciones.
• Modelado de ropa.
• Exportado a Unity el avatar completo para su integración y pruebas.
• Desarrollo teórico de los objetivos de programación a alcanzar.
• Simulación de terreno.
• Simulación de dinámica de agua.
• Climatología.
• Erosión.
• Inteligencia artificial y los scripts necesarios para el control de cada elemento
y funcionalidad.
• Terreno deformable. Se ha estudiado la vía de usar voxel para la creación del
terreno
• Se exportan a Unity los modelos de props y npcs.
• Se integran todos los elementos.
• Se solucionan errores en la integración.
3.5 Testing y pruebas
Se comprueba que todos los elementos reaccionan según planeamiento.

Página 12 de 36
4. Conclusiones

4.1 Objetivos alcanzados

• Recopilación de documentación.
• Elaboración de base teórica de las funcionalidades a implementar.
• Creacion e integración del avatar.
• Creacion de scripts para control del avatar.
• Los objetivos de programación relativos a la simulación solo se han podido
realizar, en fase teórica, debido a un cambio en la situación laboral que redujo
el tiempo disponible para la parte practica de todo el proyecto a tres semanas,
utilizadas para la creación de un nivel de demostración de los parámetros
requeridos en el trabajo de fin de grado y a la elaboración de la documentación
requerida.
4.2 Conclusiones del trabajo
A nivel general se ha constatado la necesidad de un profundo trabajo en la
preproducción, para dejar todos los aspectos bien definidos, así como ocupar parte
de la preproducción en comprobar la compatibilidad entre todos los aspectos que
rodean las decisiones tomadas, haciendo especial hincapié en las características del
motor grafico que, a fin de cuentas, será la herramienta base para generar el proyecto.
Temas como que tipo de esqueleto es capaz de manejar para las simulaciones
dinámicas, que tipo de archivos, limitaciones, configuración de las unidades de
medida en los programas de modelado, que tipo de formatos de animaciones puede
manejar, que particularidades tiene en cuanto a físicas y simulaciones son aspectos
muy a tener en cuenta a fin de evitar posteriores problemas de compatibilidad que
aumentaran considerablemente el tiempo de desarrollo y los recursos materiales y
humanos destinados a solucionarlos.
Otro aspecto que cabe destacar es la importancia de un control de versiones y
copias de seguridad, en mi caso al ser un proyecto pequeño y con pocos medios no
he podido disponer de ellos, teniendo varios problemas irrecuperables que me han
obligado a perder mucho tiempo realizando acciones que ya había terminado.
• Modelado:

Página 13 de 36
 Se modela el modelo del protagonista en Character Creator 3, siendo
consciente de los parámetros evaluables en este proyecto este es el único modelo
realizado en esta técnica, con el fin de ahorrar tiempo en el proceso más costoso,
si bien se elimina el esqueleto creado en la aplicación. Se incorporan modelos de
elaboración propia, con rig propio, en caso necesario y texturas elaboradas bien
mediante imágenes o bien mediante Substance Painter.

Figura 7. Modelo realizado en Character Creator. Fuente: Elaboración propia.

Figura 8. Boceto de NPC. Fuente: Elaboración propia.

Página 14 de 36
 Figura 9. Modelo realizado en 3dsMax. Fuente: Elaboración propia.

Conclusiones:
En este aspecto cabe destacar pocos problemas, el principal se refiere a la
configuración de unidades de medida en la herramienta de modelado utilizada, esto
no genera un problema grave con Unity, pues el escalado no genera problemas,
aunque quizás los genere en animaciones dinámicas, pero si los ha generado con
otras herramientas, en este caso Marvelous Designer, que tienen un espacio de
trabajo muy limitado y cuya capacidad para escalar elementos esta bastante
limitada, siendo insuficiente en este caso. Ha habido otros problemas, que
relaciono con errores en la herramienta de modelado, en el que estando el modelo
correctamente y realizando el rig y el pesado de vértices de forma satisfactoria, al
realizar las animaciones se han observado desplazamientos de vértices que,
incluso eliminando toda la animación, no recuperaban su posición, teniendo dos
opciones, obviar ese error si era leve o tener que rehacer todo el trabajo cuando el
error era demasiado perceptible.
• Props y npcs.

Página 15 de 36
 Se recopilan modelos de elaboración propia, props y modelos orgánicos. Se
utilizan varios modelos de elaboración propia que fueron creados anteriormente,
siguiendo cursos y manuales, muchos de ellos realizados años atrás, con el fin de
ahorrar todo el tiempo posible.

Figura 10. Modelo realizado en 3dsMax. Fuente: Elaboración propia.

Figura 11. Modelo realizado en 3dsMax. Fuente: Elaboración propia.

Conclusiones:
La realización de props y npcs debe estar en línea con la calidad del avatar
principal, en caso contrario se calidad destacará empobreciendo el resultado final.
• Rig.

Página 16 de 36
 Se intenta utilizar un rig completo, con limitaciones de ciertos movimientos,
controles y rig facial por huesos y controladores, se adjunta como archivo
complementario. No obstante y pese a que el rig es perfectamente adaptable y
escalable solo es efectivo con la configuración de medidas que se usó en su
creación. Esto no implica problema alguno en Unity, pues se puede escalar sin
problemas, en Marvelous Designer, no obstante, si supone un problema, pues
resulta un archivo demasiado grande para su espacio de trabajo y no se puede
subsanar el error ni escalando al máximo posible. Debido a la complejidad de este
rig y la problemática que supone el tiempo no se valora realizar uno adaptado al
sistema de medidas de Marvelous Designer pues si bien se podría realizar en
estático y después escalarlo no podrían simularse las animaciones, que es el
objetivo de usar esta herramienta.
Se crea, por lo tanto, un rig más sencillo, usando, para mayor ahorro de
tiempo, el sistema biped incluido en 3dsMax, usando las animaciones del anterior
esqueleto como guía para crear los keyframes con este esqueleto.

Figura 12. Rig facial realizado en 3dsMax. Fuente: Elaboración propia.

Página 17 de 36
 Figura 13. Rig realizado en 3dsMax. Fuente: Elaboración propia.

Conclusiones:
Es estrictamente necesario conocer las capacidades del motor grafico en
cuanto a configuración del esqueleto, máxime si se quieren usar animaciones
dinámicas pues es necesario tener un rig acorde al que usa el motor grafico para
ello. Es conveniente, para evitar retrasos, hacer una prueba inicial de
compatibilidad de unidades de medición entre todas las herramientas que se vayan
a utilizar.
Otro punto a tener en cuentas es realizar todos los rigs en base a un
esqueleto básico que sea escalable, permitiendo de este modo reutilizar las
animaciones entre todos los elementos del mismo tipo.
• Se crean las animaciones básicas del modelo controlable.
Se crean las animaciones de andar, trotar, correr, saltar, idle, escalada,
ataque y fabricación en un banco de trabajo.
Estas animaciones se consideran las necesarias para la realización de la
demo. Sin embargo, el número de animaciones necesarias para realizar un

Página 18 de 36
proyecto de este tipo resulta demasiado amplio como para poder realizar las en tan
poco tiempo y sin recurrir a captura de movimientos, pues a las ya mencionadas
acciones habría que sumar otras muchas, ataques con diferentes configuraciones
de armas, con ambas manos, con una mano, con una mano que ataque y otra que
defienda, ataques melee y a distancia, de nuevo con una o dos manos, de pie,
agachado, tumbado, cayendo, etc.
Las animaciones para las estaciones de fabricación estaban pensadas para
ser modulares, de tal forma que, si una estación requiere de un horno, una prensa
y un yunque, se reproduzca una animación en el uso de cada elemento, así mismo
cada estación requerirá de los componentes necesarios para la realización de esa
estación. Así mismo las zonas de fabricación pueden tener diferentes alturas y
tamaños, no es lo mismo usar un horno para fabricar acero que un horno de joyería,
por lo que deberían de tener varios tamaños y un punto de referencia para que la
animación se reproduzca en ese punto, no tiene mucho sentido usar un horno
estando en la parte de atrás en lugar de estar en la ventana de entrada a este.
Para dotar de mayor realismo al mundo también debería haber varias
animaciones aleatorias para diversos estados como idle o dormir, por citar algunos
ejemplos, de tal forma que no dé la impresión de ser repetitivo.
Para las animaciones de escalada se quiere optar por un sistema de
escalada dinámico, que, si bien tenga una base y una postura de escalador, las
manos y pies se dirijan al punto de apoyo de forma dinámica, gestionado por el
motor gráfico, en este caso Unity.
Conclusiones:
Hay que definir en la fase de preproducción todas las necesidades en cuanto
a animaciones, objetos a emplear, situaciones, modos de movimiento, tipos de
armas y de acciones a realizar, en que estado y con cuantas variaciones. Si bien
no hay problema en añadir cambios en fases posteriores si permite agilizar los
procesos de sincronización en Unity y de gestión de tiempo y recursos, hacer un
rig y realizar las animaciones en un mismo periodo de tiempo permite familiarizarse
con ese sistema, si en pasos posteriores se realizan incorporaciones de
animaciones estas necesitaran un nuevo periodo de adaptación a ese sistema.
Esto también se aplica a las pequeñas modificaciones que dotan de personalidad
a cada personaje, si hay un corte en el desarrollo de animaciones, ya sea por paso

Página 19 de 36
del tiempo o por cambio de animador, se notara el cambio en esos pequeños
detalles, por mucho hincapié que se haga en seguir la misma línea.
• Se realiza el texturizado, rig y animación de los props y npcs definidos.
Los objetos realizados con anterioridad han mantenido sus texturas, si bien
para los desarrollados durante este proyecto se ha usado Substance Painter para
el texturizado, dada la facilidad con la que se obtienen resultados decentes y su
capacidad para exportar los mapas necesarios para una integración rápida en
Unity.
Para los rigs necesarios se ha usado el sistema más simple posible, debido
a lo limitado del tiempo de desarrollo.
Las animaciones realizadas en este campo son muy básicas, movimientos
básicos de andar, correr y reaccionar ante la presencia.
Para los npcs se quiere romper con la dinámica de una persona que está
permanentemente en un mismo lugar en la misma pose, por lo que las animaciones
deberían incluir varios estados, e incluso en su comportamiento no estar siempre
en el mismo sitio, andar para llegar a su lugar desde su casa, volver al terminar el
día, moverse, estar realizando sus actividades etc.
En cuanto a las criaturas que pueblan el mundo, la intención es que estas
criaturas reacciones de forma distinta en cada situación, dependiendo de si hay
solo uno de ellos, si se enfrentan en superioridad o inferioridad numérica, si son
carnívoros o herbívoros, agresivos o mansos, si el ambiente que los rodea es
agresivo, si hay luchas cerca, si algún jugador o npc ha intentado cazarlos en un
plazo de tiempo definido, etc.
Conclusiones:
Si bien es cierto que los personajes secundarios, npcs, criaturas y props
quizás no requieran tanta atención como lo personajes principales también es
cierto que una excesiva dejadez o simplificación de estas entidades puede echar
por tierra un gran trabajo sobre los actores principales, aunque de una calidad
inferior, una poligonización inferior y una cantidad de animaciones infinitamente
inferior es importante no descuidar este campo, pues es necesario mantener una
cierta consistencia en todos los aspectos para tener cierta sensación de realismo
e inmersión en el mundo desarrollado.
• Se modela la ropa del avatar en Marvelous Designer.

Página 20 de 36
 Se realiza el modelado de unas prendas muy básicas en esta herramienta,
con la intención de que aparente ser una ropa muy básica, creada con fibras
vegetales muy bastas o con piel muy gruesa.
Durante el cálculo de las animaciones de la ropa surgen varios problemas
relacionados con geometría que se engancha y atraviesa la ropa, obligando a
seguir un proceso de simulación - retoque de animaciones – simulación que
conlleva varios días de trabajo hasta que la simulación resulta aceptable, pues
aunque el problema sigue surgiendo en algunos puntos son frames que quedan
fuera de las animaciones a usar en Unity, en espacios estáticos en la animación
destinados a que la ropa dejase de moverse después de una animación.
Al final la simulación se percibe un problema, las animaciones realizadas
con esta herramienta no consisten en frames, sino en partículas móviles, de tal
forma que las animaciones no pueden usarse en Unity. Las animaciones fueron
exportadas en formato allembic, pues es el que mejor se adapta y no daba
problemas en 3dsMax, pero después de buscar información y realizar varias
pruebas, no se puedo realizar una conversión a frames, pues Marvelous Designer
exporta estas partículas y cada frame de la animación consiste en la creación de
un nuevo objeto con estas partículas, con lo que realmente no existe una malla.
Se puede realizar una retopología de la ropa, en base a los patrones
generados en Marvelous Designer, para después adaptarla al modelo con las
físicas calculadas, conservando las uvs, y realizar la animación a través del clásico
sistema de copiar las influencias del esqueleto sobre el avatar al modelo de la ropa,
ajustándose este a los movimientos de las animaciones del avatar, pero perdiendo
el detalle de la simulación, quedando arrugas rígidas en la ropa, pero el objetivo a
alcanzar es una simulación realista, por lo que se desecha esta idea.
La siguiente opción a valorar, mientras se sigue buscando información para
convertir la animación a malla fotograma a fotograma, consiste en usar el sistema
de simulación de tejidos de Unity, pero este sistema da ciertos problemas al
atravesar la piel del avatar por errores de cálculo en tiempo real, se intentan varias
configuraciones, que poco a poco van haciendo que el tejido no caiga hasta el
infinito, mejoran las intersecciones con la piel del avatar y, en definitiva, se adaptan
mejor a lo buscado, no obstante requieren una cantidad de tiempo que no está
disponible, evidentemente es algo fácil para alguien que se dedica a ello, pero no

Página 21 de 36
para alguien que desconoce los parámetros y tiene un plazo de tiempo muy
ajustado.
Finalmente, y aunque no se borran los archivos, la idea de usar ropa
dinámica queda para desarrollar en un futuro.
Existen diversos plugins para conseguir un resultado bastante bueno en
relación a la simulación en tiempo real de ropa, pero todos ellos de pago, por lo
que no se usa esa vía.

Figura 14. Ropa realizada en Marvelous Designer. Fuente: Elaboración propia.

Conclusiones:
Dada la cantidad de plugins que existen en el mercado, todos de pago,
queda claro que la simulación en tiempo real y con resultados aceptables sí es
posible, pero exige un desembolso o un tiempo de desarrollo y conocimientos
importantes. Es, sin duda, unos de los aspectos que debe mejorar Unity, pues otros
rivales en su ámbito (Unreal Engine, Cryengine) si son capaces de manejar de
forma nativa y sin muchos problemas este tipo de simulaciones, sobre todo en lo

Página 22 de 36
que nos implica, la adaptación a un modelo orgánico sin tener errores de
superposición con la malla de estos.
En cuanto a Marvelous Designer creo que sería posible exportar sus
simulaciones como mallas animadas por frames, pero no he conseguido encontrar
solución para este problema, si bien se puede subsanar simulando cada una de las
animaciones por separado y en un bucle repitiendo varias veces la misma
animación, de tal forma que se consiga un comportamiento estable de las
partículas, definiendo los tiempos de cada animación en Unity. Al tratarse de un
tipo especial de objeto, este sistema requeriría cargar en tiempo real cada
animación como un objeto distinto, estando todas incluidas como hijos del modelo
del avatar, activando y desactivando cada uno de estos objetos por código en cada
momento, lo que implicaría que todas las animaciones de este objeto, que serian
cada una de ellas un objeto distinto, deberían cargarse en memoria desde el inicio,
lo que resultaría imposible en un titulo que esta orientado hacia el multijugador. No
obstante, y aunque requiere mucho trabajo sí seria posible usar este sistema en
otros tipos de juego que este orientados a un modo de juego de un solo jugador y
con pocos personajes en pantalla, eso sí, con un ingente consumo de recursos.
• Se exporta a Unity el avatar completo para su integración.
El exportado a Unity se realiza sin problemas, no obstante los problemas
derivados de usar el rig de biped no tardan en aparecer, problemas en los que el
avatar atraviese el suelo al realizar un salto, debería agacharse y elevarse, pero en
lugar de esto el root, situado en la cadera, baja hasta el nivel del suelo realizando
la animación de agacharse, con lo que los pies acaban debajo del suelo, para
después reproducir los frames de la elevación sin elevarse, todo ello se soluciona
retocando los parámetros, pero sin poder usar algunos de ellos, pues 3dsMax
trabaja con Zup y Unity lo hace con Yup, esto significa que si bien se realiza una
reconversión que en el modelo no da problemas, no pasa lo mismo con el
esqueleto, que aunque no da problemas al exportar ni al reproducir las animaciones
en Unity no realiza una conversión de sus ejes locales, por lo que cualquier intento
de enlazar un hueso del esqueleto como root o controlador acaba con el avatar
girado 90º, quedando tumbado en el suelo.
Una vez subsanados y configurados todos los problemas el modelo se
comporta según lo esperado.

Página 23 de 36
 Conclusiones:
Si bien he usado 3dsMax por mi grado de automatización en el modelado
con esta herramienta lo cierto es que usa un sistema de coordenadas distinto al
que usa Unity, en muchos aspectos no constituye ningún problema, pues se realiza
una conversión de ejes al exportar en fbx sin mayores complicaciones; el problema
viene dado en los rigs, hasta donde he podido comprobar, pues las IK’s y los
sistemas de control de los huesos no sufren esa conversión, sino que la conversión
se produce al pasar los parámetros, que en lugar de ser Y=Y serán Y=Z, esto no
da problemas, pero si los da el intentar referenciar algo al esqueleto dentro de
Unity, pues el esqueleto sigue manteniendo su sistema de referencia y, en la
practica totalidad de los casos, Unity no tiene herramientas internas que puedan
realizar una conversión entre ambos sistemas de coordenadas, con lo que el
esqueleto queda inutilizable en este aspecto.
Los materiales son otro tema a tener en cuenta, no hay mayor problema
usando Substance Painter que marcar un preset para exportar los mapas y
automáticamente exporta los necesarios para Unity, pero con otras aplicaciones
que no tienen esta funcionalidad hay que tener bien claro que acabado se quiere
conseguir y saber que mapas se tienen que realizar y el proceso para crear ciertos
tipos de mapas, que algunos exigen combinar dos mapas en una mediante
diversos procesos, como punto positivo cabe destacar que estos procesos están
claramente definidos en su documentación.
• Programación.
Todo el trabajo de programación ha quedado en fase teórica pues resulta
imposible implementarlo por cuestiones de tiempo.
• Terreno deformable. Se ha estudiado la vía de usar voxel para la creación
del terreno.
Se han seguido varios trabajos acerca de usar voxels para la
creación del terreno, existen varios plugins desarrollados siguiendo el
mismo sistema, todos usan el mismo sistema, se basan en unos “chunk”
que son los voxels, cubos de un tamaño predeterminado como los que se
usan en Minecraft, que son los que conforman el mundo, para conseguir
un resultado mas realista se utilizan una serie de funciones matemáticas
que realizan una interpolación entre esos cubos con ciertos parámetros de

Página 24 de 36
 ruido para realizar un terreno que no este escalonado, el comportamiento
es similar al obtenido mediante subdivisión de mallas. Esto permite la
creación de cubos con diferentes características y materiales, permitiendo
la creación de terrenos con capas de sedimentos, obteniendo un efecto de
terreno real al excavar e ir encontrándose con capas distintas, a las que se
pueden aplicar valores distintos de dureza, tipo de material, etc. Esto ultimo
es un gran añadido a la hora de realizar un sistema de recolección de
recursos, pues permite identificar cada cubo como un material recolectable
distinto.
No obstante, son de pago y, aunque generan un resultado
aceptable tienen ciertas limitaciones:
o Tamaño de mundos pequeños, lo que hace que tengan un uso muy
limitado, haciendo que sean imposibles de usar en un juego multijugador
ya que en escenarios extensos tienen problemas de estabilidad de
físicas.
o Los “chunk” son de un tamaño bastante considerable, medio metro o un
metro en unidades del motor gráfico, lo que, a pesar de la interpolación
realizada para dar un acabado mas realista, impide alcanzar el realismo
que se quería conseguir, modificándolo se podría conseguir un aspecto
mas realista con cubos de tamaño mas pequeño, pero eso aumentaría
exponencialmente la cantidad de cálculos necesarios, afectando a las
físicas y a la estabilidad, consumiendo una cantidad de recursos (RAM,
procesador, tarjeta gráfica) inasumible por la mayoría de usuarios.
• Simulación dinámica de agua. Se estudiado varias metodologías distintas.
o La primera de las opciones se basa en la simulación mediante
partículas, lo que acarrea una carga importante en el sistema y no
cumple el objetivo de rellenar valles o hendiduras en el terreno.
o La segunda opción se basa en generar el agua a través de voxel,
realizando una interpolación entre cada cubo al mismo nivel que en el
terreno, pero al ser zonas mas pequeñas si se pueden usar cubos mas
pequeños, la parte negativa consiste en que para simular las físicas,
reflejos y causticas de este sistema se requiere el cálculo de la posición
de cada partícula desde cada punto de vista, es decir, si hay varios

Página 25 de 36
 jugadores en la misma zona viendo una cascada realizada con este
sistema, cada uno de los jugadores tendrá su propia visualización de la
cascada y su propia versión de las físicas calculadas, esto, siendo
meramente visual, no afecta, pero en el momento que varios jugadores
intenten desviar el agua o controlarla por algún medio se produciría una
importante inestabilidad del sistema, pues esos cálculos deberían
hacerse sincronizadamente desde todos los puntos de vista, calculando
varias interacciones al mismo tiempo y elevando el consumo de
recursos hasta niveles peligrosos para la estabilidad.
o Por lo tanto, queda demostrado que actualmente no se puede usar este
sistema en juegos multijugador, por lo que el método más aceptable
para conseguir la mayor parte de objetivos marcados en este aspecto,
sea usar canales prefabricados; si se hace una zanja, que esta no
produzca una marca en el suelo, sino que implique la colocación de un
prefab con agua con forma de zanja, en caso de que este por debajo
del nivel de la superficie de agua más próxima y que este enlazada con
esta fuente de agua.
• Erosión.
Se han consultado varios plugins relacionados con la erosión en tiempo
real, en todos ellos se utilizan terrenos creados con voxels para simular capas
y tener la posibilidad de controlar la erosión de cada voxel, por lo que este
sistema esta limitado por la capacidad de creación de terreno por este medio,
además de la imposibilidad técnica de usar agua dinámica mas allá de juegos
para un jugador y con recursos altos, por lo que esta opción queda descartada,
usando, para terrenos que lo requieran, una actualización cada cierto tiempo
por establecer, de toda la orografía del terreno, estos cambios sí se pueden
realizar a través de simulaciones, para luego implementar la malla resultante
a modo de actualización.
• Climatología.
Se ha estudiado como este aspecto puede afectar al juego. Se ha optado
por la creación de ciertas variables para cada evento de climatología, tipo
humedad, temperatura, visibilidad, aumento de sed, aumento de cansancio,

Página 26 de 36
 que influirán en el jugador en base a los parámetros que tenga su avatar y el
equipo que este tenga activo.
• Inteligencia artificial. Se han estudiado alternativas más realistas al NavMesh.
Se han investigado diversas opciones, siendo la mas llamativa un sistema
de visión, extensible a audición y olfato, que será implementado en cada
criatura o enemigo. El proceso consiste en renderizar una escena muy básica
desde la perspectiva de cada objeto, en una resolución muy baja y con colores
muy limitados, de tal forma que en el nivel de dificultad mas alto el jugador
aparecería en color rojo y el resto del mundo en color blanco, de este modo y
ajustando valores de tiempo de exposición a su visión/oído/olfato se podrían
regular los niveles de dificultad de la IA, usando más tarde el NaveMesh para
llegar al objetivo, en caso de no poder implementar un sistema de movimiento
distinto y, de nuevo, marcando la dificultad en cuanto al seguimiento en
función de parámetros como el tiempo sin ver al usuario, la capacidad de este
de esconderse, etc., abriendo el abanico a ciertas posibilidades como el uso
de camuflajes o la importancia de lavarse.
• Scripts.
Se han reutilizado scripts de trabajos anteriores, modificándolos o
completándolos cuando ha sido necesario.
• Sistema de escalada.
Se ha investigado sobre sistemas para implementar esta función y se han
encontrado dos vertientes:
o La primera consiste en modificar la dirección del movimiento según
las normales de la superficie a escalar, este resultado produce una
sensación plana e incluso flotando en la pared.
o La segunda opción consiste en utilizar un sistema de animaciones
dinámicas para escalar, basado en el control del rig por parte de
Unity y de unos puntos de apoyo definidos como tal, en este caso si
hay plugins gratuitos que ofrecen buenos resultados. Su
comportamiento básico consiste en llevar las manos y los pies a
puntos con una etiqueta determinada, para ello se precisa de un
conjunto de animaciones de escalada, tales como balanceo, subir,

Página 27 de 36
 bajar, etc., que luego serán combinadas con el movimiento de las
manos y pies que realizaría Unity a través de las IK.
La opción que se está valorando, a modo de innovación, consiste en
u8tilizar el segundo sistema, pero sin usar puntos de apoyo. Esto se
conseguiría analizando todas las superficies que tengan una inclinación
superior al valor máximo que se tendría para poder pasar andando o
corriendo, de tal forma que, bien por analizar las texturas (ambient oclusion
por ejemplo) o bien por analizar las normales del modelo, se coloquen objetos
vacíos identificados como escalables en todos aquellos puntos que cumplan
con unos requisitos establecidos, un cierto valor en el color de las texturas de
ambient oclusion o normal map o bien en aquellos puntos que excedan de un
valor de volumen con respecto a los polígonos que les rodean (este ultimo
seria de gran valor en sistemas como nanite de Unreal Engine). Este sistema
permitiría automatizar este proceso en cualquier superficie, así como poder
incluir valores como la fuerza, la agilidad, la habilidad y la resistencia para
poder controlar las posibilidades de cada avatar de avanzar escalando,
asimismo se automatizaría la gestión de superficies escalables y abriría una
nueva forma de exploración, pues no todo se podría escalar, ni se podría tener
la certeza de llegar a cierto punto escalando ni todos los jugadores podrían
acceder a los mismo puntos, pues cobrarían mucha importancia las
habilidades desarrolladas, así como la capacidad de exploración, alargando
de este modo considerablemente la vida del juego para todos aquellos que se
enfocan en la exploración de mundos abiertos y añadiendo un componente
muy estratégico en aquellos juegos que tienen la posibilidad de atacar bases
de otros jugadores.
• Se exportan a Unity los modelos de props y npcs.
El exportado no produce problemas. Se usa el exportado en fbx para
facilitar la integración, ya que si bien Unity acepta el formato *.max, se suelen
producir errores que bloquean el motor gráfico, teniendo que finalizar el
proceso desde el administrador de tareas, pues nunca llega a terminar con el
proceso. Se ha comprobado este hecho, si bien en algunos modelos es un
proceso rápido en otros, incluso de menor complejidad de malla, el proceso

Página 28 de 36
 no terminó en las ocho horas que estuvo funcionando, en este punto se finalizó
el proceso tomando la decisión de realizar todo el exportado en formato *.fbx.
• Sistema de construcción.
Este sistema ha quedado sin desarrollar, solo se ha teorizado. Se han
marcado unas bases para la realización del sistema, entre estas están la
adopción de un sistema de carga sobre muros, haciendo que el peso de la
construcción afecte a la estabilidad de los distintos componentes que la
componen, haciendo que el proceso de construcción sea más técnico que en
los sistemas que suele aplicarse actualmente; de este modo el uso de pilares,
vigas, soportes y cimientos tengan más importancia. Todo esto se
implementará usando valores según el tipo de material con el que se
construya. En el proceso de construcción se mostrarán los elementos con un
“mapa de temperatura” que indicará en que puntos la construcción es más
débil, quedando en manos del jugador y en función de su tiempo, recursos e
intencionalidad, colocar los elementos necesarios para mejorar la estabilidad
y durabilidad de la construcción.
• Se integran todos los elementos.
En este paso el único problema detectado consiste en el escalado de los
objetos y calidad de los materiales. Dado que el proceso ha sido meramente
estático, es de prever que en el momento en que haya interacciones entre
varios elementos se precise de la modificación de los parámetros y los scripts
que estos elementos precisen para su correcto funcionamiento, así como
solucionar problemas de constraints, seguimiento de objetivos, etc.
• Se solucionan errores en la integración.
Se han detectado pocos errores, a los ya mencionados relacionados con
sistemas de coordenadas, escalado y calidad de los materiales, se suman
aquellos relacionados con la interacción de animaciones en tiempo real; casos
como darse la mano, choque de espadas, tropezar con otro avatar animado..,
estas situaciones pueden resolverse creando animaciones para tales eventos,
aunque el mayor grado de realismo se consigue realizando estas
interacciones de forma dinámica en base a una animación realizada a tal
efecto, se puede realizar una animación del retroceso producido por tropezar
con un elemento y controlar los parámetros según la altura y orientación del

Página 29 de 36
 choque, así como la fuerza etc., para lograr una sensación más realista en
estos aspectos.
• Vías futuras
o Utilizar programas que agilicen la creación de contenido (Character Creator,
Metahuman), que agilicen los tiempos de desarrollo, siempre manteniendo
un nivel de calidad alto.
o Usar repositorios de modelos gratuitos con licencia para ser usados en
producciones, preferiblemente repositorios de objetos escaneados a fin de
conseguir objetos de gran calidad listos para ser implementados, ahorrando
tiempo en modelado y texturizado.
o Realizar esqueletos base para cada tipo de criatura, esto permitirá
adaptarlos a cada modelo y aprovechar animaciones. Character Creator y
Metahuman cuentan con un proceso de rig automático y de buenos
resultados, estos rigs se pueden usar como base, añadiendo huesos según
necesidades
o Utilizar, como base, animaciones de captura de movimientos, agilizando el
proceso de tal forma que, aunque retocando estas animaciones, se reduzca
considerablemente el tiempo dedicado a este proceso.
o Desarrollo o compra de un plugin que permita simular ropa en contacto con
el cuerpo en tiempo real e investigar sobre la posibilidad de que se
produzcan cortes o desgarros al contacto con ciertos objetos.
o Automatizar lo máximo posible el proceso de implementación de cada
objeto, orgánico o inanimado, en Unity a fin de marcar un flujo de trabajo
que permita optimizar todos los procesos a realizar dentro del motor gráfico.
o Investigar sobre posibilidad de transformar terreno voxel en superficie de
malla, a fin de aligerar la carga de trabajo del sistema, y sustituir esta malla
de nuevo por terreno voxel dentro de un radio limitado, cuando el jugador
equipe una herramienta que sea capaz de modificar ese terreno (picos,
palas, explosivos) para reconvertir en malla esa zona una vez el jugador la
abandone o pase un tiempo desde que ha desequipado la herramienta.
o Seguir investigando la posibilidad de usar agua dinámica.
o Si bien ya se ha planteado un sistema alternativo a la erosión en tiempo real,
el objetivo es seguir investigando sobre esta posibilidad.

Página 30 de 36
 o Seguir perfilando y añadiendo detalles al sistema propuesto sobre
climatología.
o Seguir investigando mejoras en cuanto a IA.
o Implementar todas las funciones en scripts que permitan su adaptación a
diferentes avatares y objetivos.
o El resultado de usar los objetos en formato fbx resulta satisfactorio para la
mayor parte de los elementos, por lo que no se plantea usar otro formato.
o Implantar el sistema de construcción previsto, este deberá adaptarse en
caso de que se encuentren vías para la constitución de un terreno
modificable en tiempo real, así como un sistema de simulación de fluidos
que permita interaccionar con este tipo de construcciones. Determinar de
forma coherente, según el tipo de material, la capacidad de integración en
el terreno, así como las consecuencias que tendría la erosión sobre estas
estructuras en caso de abandono.
o Investigar el sistema dinámico de colisiones para recrear un sistema mas
realista y dar variedad a las reacciones en este aspecto.

5. Glosario

• IA. Inteligencia artificial.

• Low poly (baja polinización). Sistema de modelado que usa la menor cantidad de
polígonos posible, usada para realizar el modelo base o una versión con la que
reducir el consumo de recursos de la aplicación desarrollada.
• Hig poly (alta polinización). Modelo con gran cantidad de detalles y polígonos,
usado para definir los detalles necesarios para ser luego traspasados mediante
el proceso de bake de texturas.
• Bake. Proceso por el cual los detalles de la geometría de un modelo en alta
polinización son impresos en los polígonos de un modelo en baja polinización.
• Prop. Todo aquel objeto en un entorno virtual que no realiza ningún tipo de
acción de forma activa.
• Zbrush. Herramienta de esculpido digital desarrollada por Pixologic.
• 3dsMax. Herramienta genérica de modelado y animación desarrollada por
Autodesk.
• Maya. Herramienta genérica de modelado y animación, propiedad de Autodesk.

Página 31 de 36
• Character Creator. Herramienta de modelado paramétrico de modelos
humanoides, desarrollada por Reallusion.
• Metahuman. Herramienta de modelado paramétrico de modelos humanoides,
propiedad de Epic Games.
• MakeHuman. Herramienta de modelado paramétrico de modelos humanoides,
desarrollada por The MakeHuman team.
• Substance Painter. Herramienta de texturizado de modelos, propiedad de Adobe.
• Marvellous Designer. Aplicación especializada en simulación de tejidos para
animación 3D, desarrollada por Virtual Fashion Inc.
• Voxel. Pixel con valores de posición (x, y, z) en un espacio 3D, en algunos
ámbitos se denomina voxel a los chunk.
• Chunk. Forma geométrica tridimensional, generalmente un cubo, constituida por
un conjunto de voxel (generalmente 16x16 voxel), utilizada en sustitución de los
voxel individuales con la finalidad de reducir la necesidad de recursos para su
representación. Un símil sería voxel = granos de arcilla, chunk = ladrillo de
arcilla.
• Unity. Motor grafico propiedad de Unity Technologies.
• Motor grafico (engine). Conjunto de herramientas destinadas a realizar
simulaciones graficas.
• NPC. Non playable character. Modelo que no puede ser controlado por el
jugador pero que “habita” el entorno.
• Modelado. En cuanto a terminología informática, proceso de creación de una
figura geométrica, puede ser por creación de polígonos o por modificación
(esculpido) de una superficie ya existente.
• Texturizado. Adaptación de una imagen a cada polígono creado en el modelado.
• Rig. Proceso que conlleva la creación de un esqueleto virtual, con la finalidad de
dotar de movimiento a un modelo, ajuste de sus parámetros e influencia
(pesado) de cada hueso sobre los vértices que componen ese modelo.
• Hueso (bone). Objeto virtual que simula un hueso real, con la finalidad de
controlar de forma más sencilla las animaciones.
• Animación. Secuencia de imágenes que da sensación de movimiento. En el
ámbito 3D esta se consigue mediante la modificación de las posiciones de los

Página 32 de 36
 vértices que forman un modelo, generalmente se usa un esqueleto virtual a fin
de facilitar ese control.
• Modelo. Forma virtual tridimensional, generalmente creada por polígonos.
• Script. Archivo con instrucciones a ejecutar por el sistema durante la simulación.
• Simulación dinámica. Tipo de interacción realizada en tiempo real en base a
unos parámetros establecidos, no a un movimiento preestablecido.
• Formato. Sistema de codificación de un archivo.
• Físicas. Conjunto de instrucciones destinadas a simular el comportamiento de
las fuerzas físicas del mundo real.
• Interpolación. Técnica por la cual se crea un objeto o imagen que sirva de
transición entre dos objetos o imágenes con parámetros diferentes, ya sea con
formas distintas o en posiciones diferentes.
• Frame. Fotograma.
• Keyframe. Fotograma clave, se usan como fotogramas de referencia para la
creación del resto mediante interpolación.
• Root. Objeto raíz, a partir de este se realizan todas las acciones, es aplicable al
objeto “padre” del que dependen todos los objetos situados en su árbol
jerárquico.

6. Bibliografía

• Eric Stephen Lengyel, 2010, Voxel-based terrain for real-time virtual simulations.
University of California, Davis, USA.
• Gerrit Greff. 2009. Interactive voxel terrain design unsing procedural techniques,
Stellenbosch University, Matieland, South Africa.
• Borja Cerezo Redondo. Sin fechar. Desarrollo de videojuego FPS con Unity 3D,
Universidad de Valladolid, Valladolid, España.
• Bjorn Curt Davis. May 2013. California State University, Northridge, USA.
• Daniel Gutiérrez García. Julio de 2017. Sistema para el desarrollo y gestión de
videojuegos en Unity3D. Escola Tècnica Superior d’Enginyeria Industrial de
Barcelona, Barcelona, España.

Página 33 de 36
• David Fernández Molina. 2013/2014. Scares For Sale: Diseño y desarrollo de un
videojuego en Unity 3D. Inteligencia artificial y animación. Universitat Politècnica
de València, Valencia, España.
• Carlos Sánchez & Ángel Romero. 2018/2019. Creacion de mundos mediante
generación procedural en Unity. Universidad Complutense de Madrid, Madrid,
España.
• Jiaqui Jin. 26 de Junio de 2020. Video game development with Unity. Universidad
de La Laguna, La Laguna, España.
• https://docs.unity3d.com/es/current/Manual/index.html

Página 34 de 36
7. Anexos

Página 35 de 36
Página 36 de 36