UNIVERSIDAD REY JUAN CARLOS I

Proceso completo de creación deun videojuego: Temet Nosce. ___________________________________________________________________

Máster en informática gráfica, juegos yrealidad virtual

Luis Hijarrubia BernalTutor: Alfonso Cuadrado Alvarado

Julio 2015

A los que han reído conmigo y a la persona que ha soportado tener un novio pegado a un ordenador

durante el máster y proyecto.

Índice de contenidoCapítulo 1: Introducción..................................................................................................5

1.1 Resumen.............................................................................................................51.2 Descripción del proyecto........................................................................................51.3 Objetivos del proyecto...........................................................................................61.4 Metodología utilizada en el proceso de desarrollo......................................................61.5 Estructura de la memoria.......................................................................................8

Capítulo 2: Gestión del proyecto.......................................................................................92.1 Introducción.........................................................................................................9

2.1.1 Objetivo........................................................................................................92.1.2 Visión global..................................................................................................9

2.2 Visión general del proyecto...................................................................................102.2.1 Restricciones...............................................................................................102.2.2 Entregables.................................................................................................102.2.3 Evolución del plan de desarrollo software........................................................11

2.3 Organización del proyecto....................................................................................112.3.1 Roles y responsabilidades..............................................................................11

2.4 Proceso de gestión..............................................................................................122.4.1 Estimaciones del proyecto.............................................................................122.4.2 Plan del proyecto..........................................................................................122.4.3 Seguimiento del proceso...............................................................................14

2.5 Recursos humanos del proyecto............................................................................162.6 Seguimiento y control del proyecto........................................................................17

2.6.1 Gestión de requisitos....................................................................................172.6.2 Control de calidad........................................................................................172.6.3 Informes y medidas......................................................................................172.6.4 Gestión de riesgos........................................................................................172.6.5 Gestión de configuraciones............................................................................18

2.7 Gestión de riesgos...............................................................................................182.7.1 Propósito.....................................................................................................182.7.2 Identificación y análisis de riesgos..................................................................182.7.3 Plan de acciones y monitorización...................................................................23

Capítulo 3: Concepto inicial............................................................................................253.1 Tipo de juego.....................................................................................................253.2 Título.................................................................................................................253.3 Trama argumental...............................................................................................263.4 Ambientación.....................................................................................................263.5 Personajes.........................................................................................................343.6 Diseño del juego.................................................................................................39

3.6.1 Mecánicas...................................................................................................393.6.2 Controles....................................................................................................393.6.3 Cámara.......................................................................................................412.6.4 Items..........................................................................................................412.6.5 Gestión de la salud.......................................................................................413.6.6 Comportamiento del veneno..........................................................................423.6.7 Interacción con el mundo exterior..................................................................423.6.8 Estética ......................................................................................................43

Capítulo 4: Estado del arte............................................................................................454.1 Concepto...........................................................................................................454.2 Ambientación.....................................................................................................464.3 Jugabilidad.........................................................................................................474.4 Mecánicas..........................................................................................................48

Capítulo 5: Herramientas de desarrollo............................................................................515.1 Equipo y herramientas empleadas.........................................................................51

5.1.1 Entorno de trabajo.......................................................................................51

1

5.1.2 Gestión del proyecto.....................................................................................515.1.3 Redacción de la documentación......................................................................525.1.4 Herramientas de modelado de diagramas........................................................525.1.5 Herramientas de modelado 3d.......................................................................535.1.6 Edición de imagen........................................................................................545.1.7 Edición de sonido.........................................................................................545.1.8 Captura y edición de vídeo............................................................................55

5.2 Motor del juego y entorno de desarrollo.................................................................565.3 Assets y librerías.................................................................................................59

Capítulo 6: Análisis del sistema......................................................................................636.1 Perspectiva del producto......................................................................................636.2 Funciones del producto........................................................................................636.3 Características de los usuarios..............................................................................636.4 Restricciones generales........................................................................................646.5 Requisitos estructurales.......................................................................................64

6.5.1 Diagrama de clases......................................................................................646.5.2 Descripción de clases....................................................................................656.5.3 Restricciones OCL.........................................................................................66

6.6 Requisitos de comportamiento..............................................................................666.6.1 Requisitos funcionales...................................................................................666.6.2 Requisitos no funcionales..............................................................................67

6.7 Otros requisitos..................................................................................................676.7.1 Requisitos gráficos........................................................................................67

Capítulo 7: Diseño del sistema.......................................................................................697.1 Introducción.......................................................................................................697.2 Pautas del Diseño de la Arquitectura......................................................................70

7.2.1 Arquitectura propuesta..................................................................................707.2.2 Descomposición en subsistemas.....................................................................717.2.3 Topología del sistema....................................................................................72

7.3 Diseño de subsistemas........................................................................................727.3.1 Diagramas de clase de diseño........................................................................72

7.4 Diseño de niveles................................................................................................767.4.1 Curva de dificultad........................................................................................79

Capítulo 8: Implementación...........................................................................................818.1 Blog de desarrollo...............................................................................................818.2 Implementación del personaje..............................................................................82

8.2.1 Modelado del personaje.................................................................................828.2.2 Texturizado..................................................................................................86

8.2.3 Rigging y animación.........................................................................................888.3 Implementación de los enemigos..........................................................................89

8.3.1 Ciego..........................................................................................................898.3.2 Veneno.......................................................................................................90

8.4 Implementación de la cámara...............................................................................918.4.1 La cámara en el cambio de gravedad..............................................................96

8.5 Migración a Unity 5.............................................................................................978.5.1 Iluminación.................................................................................................978.5.2 Sonido........................................................................................................988.5.3 Efectos......................................................................................................1008.5.4 Otros........................................................................................................101

8.6 Escenario.........................................................................................................1028.6.1 Skybox......................................................................................................1028.6.2 Escenario mediante terrain..........................................................................1048.6.3 Escenarios modelados.................................................................................1058.6.4 Limites de los escenarios.............................................................................107

8.7 Efectos.............................................................................................................1088.7.1 Efectos de imagen......................................................................................1088.7.2 Interrupciones............................................................................................109

2

8.7.3 Sistemas de partículas................................................................................1098.7.4 Efecto Hitchcock.........................................................................................1098.7.5 Efecto túnel...............................................................................................1108.7.6 Estela de la espada.....................................................................................112

8.8 Otros...............................................................................................................1138.8.1 Colocar la espada.......................................................................................1138.8.2 Ragdoll......................................................................................................1138.8.3 Power-up...................................................................................................1148.8.4 Control......................................................................................................1158.8.5 Interfaz de usuario.....................................................................................1168.9 Pruebas........................................................................................................117

Capítulo 9: Uso...........................................................................................................1199.1 Requisitos........................................................................................................1199.2 Instalación.......................................................................................................1199.3 Configuración....................................................................................................120

9.4 Controles.....................................................................................................1209.5 Menús..............................................................................................................121

Capítulo 10: Conclusiones y trabajo futuro.....................................................................12310.1 Conclusiones...................................................................................................123

10.1.1 Modelo de desarrollo.................................................................................12310.1.2 Trabajo en grupo......................................................................................12310.1.3 Complejidad de los juegos actuales.............................................................12410.1.4 Aprendizaje personal.................................................................................124

10.2 Trabajo futuro.................................................................................................12510.2.1 Mejorar el control......................................................................................12510.2.2 Mejorar el comportamiento del veneno........................................................12510.2.3 Ampliar niveles.........................................................................................12510.2.4 Lucha contra el enemigo final.....................................................................12610.2.5 Mejorar cinemáticas..................................................................................12610.2.6 Versión para móvil....................................................................................12610.2.7 Publicar el juego.......................................................................................127

Referencias................................................................................................................129Apuntes y trabajos..............................................................................................129Blogs.................................................................................................................129Libros y artículos................................................................................................129Películas y series.................................................................................................130Videojuegos.......................................................................................................130Vídeos...............................................................................................................131Webs.................................................................................................................132

3

4

Capítulo 1: Introducción

1.1 Resumen

La presente memoria supone la documentación sobre el desarrollo del proyecto “TemetNosce”, videojuego presentado como trabajo final de máster en el máster en informática grá-fica, juegos y realidad virtual de la Universidad Rey Juan Carlos.

El proyecto comenzó como trabajo obligatorio de la asignatura de Tecnología de juegos,donde habitualmente se realiza el desarrollo de un videojuego en grupo, pero al ser ademásdel trabajo de esa asignatura el trabajo final de máster, en este caso lo desarrollé en solitario.Después de finalizar la asignatura con buenos resultados, preferí hacer mejoras sobre elproyecto, para poder tener un mejor trabajo final de máster.

El proyecto consiste en el desarrollo completo de un pequeño videojuego. Y la intenciónprincipal es la de poder plasmar una ambientación única en un viaje introspectivo.

1.2 Descripción del proyecto

Se trata del desarrollo de un videojuego, corto, pero completo, haciendo un recorrido portodos los roles involucrados en una producción de este tipo. En él se pondrán de manifiesto losconocimientos adquiridos a lo largo del máster.

El juego tiene como concepto principal el viaje de un héroe por dentro de su propio sub-consciente. Y será un juego de plataformas. La ambientación para sugerir ese mundo irrealdonde las normas son muy diferentes a las del mundo real es el punto más importante a con-seguir.

En el desarrollo las áreas más importantes en las que trabajar son:

• Ambientación, crear y utilizar los recursos artísticos y técnicos apropiados para re-flejar el viaje por el subconsciente del héroe.

• Trama argumental, crear una historia en la que transcurra el viaje del héroe y la na-rrativa apropiada para contarla.

• Diseño de personajes, todo el proceso, desde la idea inicial hasta la integración en el

5

mundo del juego de los diferentes personajes del juego, tanto principales como secun-darios.

• Gameplay, desarrollo de mecánicas de juego y comportamiento de los enemigos en eljuego.

• Interfaz de usuario, tanto el manejo que tendrá el usuario una vez comience la par-tida como las acciones que podrá realizar mediante menús.

1.3 Objetivos del proyecto

Los principales objetivos del proyecto son los siguientes:

• Investigación de los videojuegos ya existentes con temática o funcionamiento similar yanalizar sus propuestas.

• Afianzar e incrementar los conocimientos sobre el entorno de desarrollo Unity3D.

• Conocer y aprender a utilizar librerías, técnicas y prácticas habituales en los desarrollosprofesionales.

• Mejorar el uso de las herramientas de modelado, texturizado y animación aprendidas enel máster, así como familiarizarse con otras nuevas. Así como la integración de los ele-mentos producidos en estas herramientas en el entorno final.

• Desarrollar un videojuego llamativo, partiendo de una serie de ideas a transmitir yconsiguiendo aplicar los conocimientos adquiridos para que la ambientación pretendidasea la adecuada en el producto final.

• Aprender los distintos roles que se asumen en el desarrollo de videojuegos y lasproblemáticas de cada uno para poder comunicarse mejor con compañeros de equipoen futuros desarrollos.

• Conseguir un juego funcional y entretenido, que aunque corto tenga todos los ele-mentos básicos de un videojuegos.

• Creación de la documentación técnica asociada al proyecto.

1.4 Metodología utilizada en el proceso de desarrollo

Habría que hablar realmente de al menos dos metodologías en el proceso de desarrollo.Una durante el desarrollo del proyecto como parte de la asignatura de Tecnología de juegos yotra en la parte exclusiva como trabajo final de máster.

Estoy habituado a usar la metodología de desarrollo de software, propuesta por elProceso Unificado de Desarrollo (RUP), que junto con el Lenguaje Unificado de Modelado (UML)constituye la metodología estándar más utilizada para el análisis, diseño, implementación ydocumentación de sistemas orientados a objetos. Pero este desarrollo no es un desarrollo desoftware como los proyectos anteriores que he realizado, sino de un producto software, perocultural, y por eso la metodología no se puede aplicar a todos los pasos del proyecto.

En la parte de proyecto desarrollada para la asignatura si intenté seguir esta metodo-logía (RUP), para una iteración planificada, y con posterioridad iterar más veces de cara al

6

trabajo final de máster. El ciclo de vida de RUP se caracteriza por:

• Estar dirigido por casos de uso: Los casos de uso reflejan las necesidades de losusuarios y guían el proceso de desarrollo ya que los modelos que se obtienen, comoresultado de los diferentes flujos de trabajo, representan la realización de los casos deuso.

• Centrado en la arquitectura: La arquitectura describe los elementos del modelo queson más importantes para su construcción, los cimientos del sistema que son nece-sarios como base para comprenderlo, desarrollarlo y producirlo económicamente.

• Iterativo e Incremental: El software se desarrolla en iteraciones (secuencia planifi-cada de actividades), cada una de las cuales evoluciona incrementalmente.

El ciclo de vida de RUP se divide en 2 etapas (etapa de ingeniería y etapa de producción)y 4 fases (inicio, elaboración, construcción y transición). Cada fase define un conjunto de obje-tivos, actividades, productos y evaluación de hitos. Estas fases tienen varias iteraciones y unhito con un conjunto de artefactos.

• Fase de inicio: Se definen la visión, los objetivos y el alcance del proyecto, tantodesde el punto de vista funcional como del técnico, obteniéndose como uno de los prin-cipales resultados una lista de los casos de uso y una lista de los factores de riesgo delproyecto. También se obtiene un plan inicial de proyecto.

• Fase de elaboración: En esta fase se completa el análisis de los casos de uso, seestablece una arquitectura base sólida, se desarrolla un plan de proyecto ajustado parala fase de construcción y se eliminan los elementos de mayor riesgo para el desarrolloexitoso del proyecto. Se realiza la mayor parte del análisis y el diseño de la aplicación.

• Fase de construcción: A lo largo de las distintas iteraciones se van incorporandofuncionalidades en las distintas construcciones, obteniendo versiones utilizables (alfa ybeta).

• Fase de transición: Con la versión beta como entrada se obtiene una versión final quese le entrega al usuario.

7

Figura 1: Diagrama de flujos de trabajo del proceso unificado

Gracias a este método de desarrollo pude reaccionar a tiempo a riesgos que surgierondurante el desarrollo del proyecto como parte de la asignatura, ya que debido a la intensidadde la carga de trabajo en el segundo cuatrimestre del máster y una serie de malas decisiones yfalta de experiencia al realizar ciertas tareas, sufrí retrasos severos en el plan y tuve quereajustar la planificación.

Una vez entregado el proyecto para la asignatura preferí cambiar una serie de artefactosdel proyectos que formaban parte del núcleo del mismo. Por lo que más que de una nuevaiteración, podemos hablar casi de comenzar una nueva implementación del proyecto.

La metodología a partir de este punto varió, intentando desarrollar componentes funcio-nales debidamente probados que se pudieran usar finalmente para el diseño final del juego.Funcionando más parecido a un estudio real donde unos departamentos desarrollan compo-nentes que se usan para ir realizando el juego en otros departamentos. Este uso es el de COTS(Commercial off-the-shelf), en un caso particular en el que sostengo los roles de desarrolladorde los componentes y de su usuario final.

Este tipo de desarrollo por componentes hizo más complicada la planificación de la se-gunda parte del proyecto, ya que al centrarse en la consecución de cada componente hasta suestado final, se perdía la perspectiva de desarrollo del proyecto completo.

1.5 Estructura de la memoria

El desarrollo de la memoria queda estructurado en capítulos, tal y como desgloso acontinuación:

• Capítulo 1: Introducción: El presente capítulo, dedicado a aportar una visión generalsobre el tema que se intenta tratar con el proyecto y presentar los objetivos del mismo.Además estableceré un marco para comenzar el desarrollo del proyecto para tenertodos los aspectos de trabajo a la vista y poder cumplir con los plazos de desarrollo.

• Capítulo 2: Gestión del proyecto: Donde se concreta el plan de desarrollo, la gestiónde riesgos y la planificación y calendarización de tareas.

• Capítulo 3: Concepto inicial: En este capítulo se describen las ideas narrativas,artísticas y lúdicas sobre las que se basará la construcción del juego.

• Capítulo 4: Estadio del arte: Se hace un estudio de videojuegos existentes conaspectos en común al del videojuego en desarrollo, comprobando como hanimplementado esos aspectos y si son de utilidad en el presente desarrollo.

• Capítulo 5: Herramientas de desarrollo: En este capítulo se estudia el hardwareutilizado para desarrollar así como el software: motor, herramientas, librerías, assets...También el porqué de esas decisiones y las ventajas de estos programas.

• Capítulo 6: Análisis del sistema: Se especifican los requisitos recogidos para laaplicación y los diagramas oportunos para definir el sistema.

• Capítulo 7: Diseño del sistema: Documentación sobre cómo se va a implementar laherramienta, incluyendo arquitectura, subsistemas y patrones. Además se especifica eldiseño de niveles del juego.

• Capítulo 8: Implementación: Documentación relativa al proceso de implementacióndel juego, los problemas surgidos y las pruebas realizadas.

• Capítulo 9: Uso: Relata como instalar y utilizar el juego.

• Capítulo 10: Conclusiones y trabajo futuro: Resumen de lo conseguido con eldesarrollo del proyecto y posible trabajo con el que continuar y ampliar el proyecto.

8

Capítulo 2: Gestión del proyecto

2.1 Introducción

2.1.1 Objetivo

El objetivo del Plan de desarrollo software es recopilar toda la información necesaria parallevar a cabo la gestión, control y seguimiento del proyecto. En él se describe el “Plan inicial dedesarrollo de software” que será de utilidad para tener un perfecto conocimiento de las acti-vidades a llevar a cabo y su respectiva calendarización. Será fundamental para dirigir y super-visar la correcta evolución con respecto al cumplimiento de las fechas y previsiones definidasinicialmente así como de los recursos asignados. [2]

Este plan de desarrollo de software contiene el plan global que será seguido en el proyecto. Enél se incluyen los planes de fases e iteraciones que se seguirán durante el desarrollo del pro-ducto basándose en el Proceso Unificado.

2.1.2 Visión global

El presente plan de desarrollo de software contiene la siguiente información:

• Visión general del proyecto: proporciona una descripción de los objetivos, el alcancey las restricciones del proyecto.

• Organización del proyecto: describe la estructura de la organización del equipo detrabajo,incluyendo roles y responsabilidades.

• Proceso de gestión: detalla la calendarización, indicando las fases principales, suscorrespondientes hitos y los artefactos a entregar. También describe el proceso deseguimiento y control del proyecto teniendo en cuenta el control de calidad así como lagestión de requisitos, riesgos y configuraciones.

9

2.2 Visión general del proyecto

2.2.1 Restricciones

La aplicación debe cumplir las siguientes restricciones:

• Se debe realizar un análisis y seguimiento de los riesgos asociados al desarrollo del sis-tema.

• Se debe seguir el modelo de Proceso Unificado (UP) rigurosamente.• El producto debe ser fácil de usar. Se aplicarán técnicas de diseño de juegos para evitar

un tutorial de controles al inicio del juego.• El producto debe ser visualmente atractivo.• Se deben aplicar técnicas y conocimientos de informática gráfica al producto final. • La entrega del producto y de toda la documentación técnica asociada debe realizarse

antes del 15 de Julio de 2015.

2.2.2 Entregables

A continuación se enumeran cada uno de los artefactos que serán generados y utilizadosdurante el proyecto y que constituyen los entregables. Los artefactos aparecerán listadossegún la fase de desarrollo a la que pertenecen:

Fase de inicio

• Plan de desarrollo de software.• Documento de gestión de riesgos.• Plan de la 1a iteración de la fase de inicio.• Documento de especificación de requisitos software.• Especificación inicial de casos de uso.• Plan de la 1a iteración de la fase de elaboración.

Fase de elaboración

• Modelo de análisis.• Modelo de diseño (incluye la arquitectura del sistema).• Plan de la 2ª iteración de la fase de elaboración.• Prototipo de interfaz de usuario.• Plan de la 1a iteración de la fase de construcción.

Fase de construcción

• Modelo de despliegue.• Versión alfa del producto.• Documento de casos de prueba.• Plan de la 2ª iteración de la fase de construcción.

10

• COTS finales. • Versión beta del producto.• Documento de resultados de las pruebas.• Plan de la 1a iteración de la fase de transición.

Fase de transición

• Versión final del producto.• Vídeo promocional del producto.• Manual de instalación.

Cabe destacar que todos los artefactos son objeto de cambios a lo largo del proceso de desa-rrollo, por lo que, únicamente al finalizar dicho proceso, se dispondrá de una versión definitivay completa de cada uno de ellos. Sin embargo, el resultado de cada iteración y los hitos delproyecto están enfocados a conseguir un cierto grado de completitud y estabilidad de la listade artefactos.

2.2.3 Evolución del plan de desarrollo software

El plan de desarrollo del software se revisará quincenalmente y se refinará antes del co-mienzo de cada iteración con el objetivo de comprobar que la realización del proyecto cumplelo planificado para que, en caso contrario, se actúe consecuentemente.

2.3 Organización del proyecto

2.3.1 Roles y responsabilidades

El equipo del proyecto se compone de un único miembro que desempeñará los siguientesroles:

Rol Competencias

Jefe de proyecto Encargado de planificar, dirigir, realizar el seguimiento y controlarel proceso de desarrollo del proyecto.

Diseñador 3d Realiza las labores de modelado, rigging, texturizado y animaciónen componentes integrables en el proyecto.

Ingeniero de Software Encargado del análisis y diseño del sistema. Desempeñará dife-rentes subroles en función de la actividad que tenga encomendadaen cada momento. Entre dichos subroles destacan el de analista desistema, arquitecto, diseñador de componentes y diseñador de lainterfaz de usuario.

Diseñador de niveles Realiza las labores de construcción del mundo ludoficcional a partirde las piezas creadas por los demás roles.

11

Desarrollador Encargado de la implementación de la aplicación a partir de losmodelos generados por el rol Ingeniero de software y el diseñador3d. Genera COTS y trabaja en su integración en el producto final.

Probador Encargado de definir y llevar a cabo el plan de pruebas delsistema.

2.4 Proceso de gestión

2.4.1 Estimaciones del proyecto

Para realizar la estimación de costes y tiempos asociados a este proyecto se debe teneren cuenta que se trata de un trabajo de final de máster, por lo que los costes del esfuerzo seconsideran nulos ya que no se va a recibir ninguna retribución económica por el trabajo. De lamisma forma, el resto de costes (indirectos, de hardware y de software) no son aplicables eneste proyecto.

2.4.2 Plan del proyecto

En esta sección se presenta la organización en fases e iteraciones y el calendario delproyecto. Hay que tener en cuenta que es un proyecto atípico, ya que al haber sido trabajopara una asignatura y posteriormente trabajo final de máster hay dos planificaciones dife-rentes, cada una con su fase de transición y con entregables finales. Por ello a continuación semuestran dos planes, como si se tratasen de dos planificaciones independientes.

El desarrollo se llevará a cabo en base al modelo de proceso unificado. Cada planificaciónse dividirá en fases, con una o más iteraciones en cada una de ellas. Las siguientes tablasmuestran la distribución de tiempos y el número de iteraciones de cada fase así como los hitosque determinan el final de cada una de ellas:

Planificación para la asignatura Tecnología de juegos.

Fase Iteración Duración Hitos

Inicio 1 30 horas Creación del Plan de desarrollo y de los documentosde diseño incial y de riesgos.

Elaboración 1 40 horas Validación de los modelos de análisis, diseño y datos.Línea base y descripción de la arquitectura.

Construcción 1 280 horas Entrega de la versión beta del sistema, redacción deldocumento de resultados de los casos de prueba yvalidación del modelo de despliegue.

Transición 1 40 horas Entrega de la versión final del sistema junto a ladocumentación final, demostraciones y vídeos.

12

Planificación como trabajo final de máster.

Fase Iteración Duración Hitos

Inicio 1 50 horas Creación del Plan de desarrollo y de los documentosde diseño incial y de riesgos.

Elaboración 1 60 horas Validación de los modelos de análisis, diseño y datos.Línea base y descripción de la arquitectura.

Construcción 1 640 horas Entrega de los componentes COTS, redacción del losdocumentos de resultados de los casos de prueba yvalidación del modelo de despliegue.

2 340 horas Entrega de la versión beta del sistema, redacción deldocumento de resultados de los casos de prueba yvalidación del modelo de despliegue.

Transición 1 80 horas Entrega de la versión final del sistema junto a ladocumentación final, demostraciones y vídeos.

A la hora de realizar la planificación inicial del proyecto se ha tenido no se han tenido encuenta fines de semana ni periodos vacacionales, dependiendo de la fase del proyecto hecombinado el desarrollo con la asistencia a clase, por lo que el desarrollo se realizabamayoritariamente en esos periodos. Durante el periodo de desarrollo como trabajo de fin demáster lo he realizado como si fuera un trabajo, con 40 horas semanales repartidas en 6 días.En la parte final de ambas entregas se aumentó la carga de trabajo hasta el máximo permitidopor mi salud.

El diagrama de Gantt asociado al plan de fases de la parte de Tecnología de juegos es elsiguiente (meses de 2014):

13

Figura 2: Diagrama de Gantt de la primera parte

Y el diagrama de Gantt asociado al plan de fases de la parte de trabajo final de máster esel siguiente (meses de 2014 y 2015):

2.4.3 Seguimiento del proceso

Se va a resumir la organización y resultados, en términos organizativos, del proyecto encada iteración de cada fase. En esta sección voy a considerar primer desarrollo al hecho para laasignatura de Tecnología de juegos y segundo desarrollo a la ampliación como trabajo final demáster.

Primera iteración de la fase de Inicio del primer desarrollo.

Esta iteración se realizó al inicio del segundo cuatrimestre del curso, ante la necesidad deiniciar el proyecto y presentarlo ante el profesor y los compañeros. Aquí se dieron las ideasiniciales, objetivos y pretensiones del proyecto.

14

Figura 3: Diagrama de Gantt de la segunda parte

Primera iteración de la fase de Elaboración del primer desarrollo.

También al iniciar la asignatura de Tecnología de juegos, tuvimos que entregar un docu-mento de diseño inicial al profesor, Marcos García Lorenzo (de aquí en adelante Marcos), y sehizo bajo plazo y de forma satisfactoria, aunque se señalo la preocupación por las excesivaspretensiones de un proyecto a realizar por una sola persona.

Primera iteración de la fase de Construcción del primer desarrollo.

Al ser un proyecto unipersonal y por la naturaleza del mismo hubo problemas graves enesta iteración. No estoy especializado en la parte artística, sino en la técnica y tengo pocaexperiencia con herramientas de modelado, por lo que el diseño del personaje principal, todo elproceso de modelado, texturizado, rigging y animación fue mucho más largo de lo planeado.Esto supuso un serio rebalanceo de los tiempos del proyecto y de las pretensiones del mismo.

Marcos insistió en las sesiones de seguimiento del proyecto en la necesidad de que nofuera tan perfeccionista, acortar los tiempos de cada tarea para tener un producto funcional yposteriormente iterar para mejorar características.

En la parte final del cuatrimestre terminé el resto de asignaturas y tuve tiempo completo,ya sin clases presenciales y sin otras asignaturas para el desarrollo de este proyecto, lo quesupuso un gran avance y la consecución de los objetivos propuestos de forma satisfactoria.

Primera iteración de la fase de Transición del primer desarrollo.

En Julio de 2014 debía entregar el proyecto para la asignatura de Tecnología de Juegos.Esto supuso la transición del producto hacia una forma final. Lo conseguí, ya que aunque corto,el juego tenía todas las piezas de un videojuego: cinemáticas, personaje controlable por elusuario, enemigos controlados por IA, escenario, cámara, mecánicas de plataformas y lucha,ambientación, un monstruo final, sonido, música...

Entregué el videojuego en forma de ejecutable, además de un post morten, vídeodemostrativo y realicé la presentación del juego. El resultado final en la asignatura fuesatisfactorio con una calificación de 9,5.

Primera iteración de la fase de Inicio del segundo desarrollo.

Una vez que retomé el desarrollo como parte del trabajo final de máster me replanteeobjetivos y hubo un proceso de investigación técnico para planear los hitos del proyecto y laorganización del mismo.

Decidí desarrollar elementos COTS, piezas autónomas y probadas que se van a necesitaren el momento del diseño de niveles. También abrí un blog de desarrollo en el que cuento laexperiencia de desarrollo, inspiración, problemas y soluciones encontradas. Esperando poderayudar a otros nóveles en el desarrollo de videojuegos y además esto me obliga a irdocumentando cada paso del proyecto, y hace mucho más fácil construir la memoria final. [4]

15

Primera iteración de la fase de Elaboración del segundo desarrollo.

Estudio las posibilidades técnicas del proyecto con el nuevo enfoque y decido loselementos COTS que se necesitan desarrollar. Esta iteración tiene una revisión, después dehaber pasado a la siguiente fase debida a un evento externo. Y es que en Abril se lanzo Unity5, y decidí migrar la aplicación a la nueva versión, por lo que tuve que replantear el análisis ydiseño de algunos de los componentes.

Primera iteración de la fase de Construcción del segundo desarrollo.

Ha sido la iteración más larga del proyecto, durante varios meses he desarrollado piezasindividuales que he utilizado para fabricar el producto final. Cada pieza se ha ido desarrollandoy probando de forma independiente. El proceso se ha alargado un poco más de lo previsto, yaque descarté algunas piezas y las volví a hacer de otra forma. Cuando decidí migrar a Unity 5,algunas piezas tuvieron que ser rehechas y otras adaptadas.

Segunda iteración de la fase de Construcción del segundo desarrollo.

Parte de esta iteración se solapó un poco con la anterior, ya que aunque idealmente unadebería haber dado todas las piezas terminadas a la siguiente empecé a construir los nivelesantes de tener todas las piezas lista por el retraso que había en la iteración anterior.

Primera iteración de la fase de Transición del segundo desarrollo.

El trabajo final de máster se debía entregar como tarde en Julio de 2015, esto hizo quehubiera que cerrar las iteraciones comprometiendo algunos de los objetivos. Aún así la conse-cución global de la aplicación es satisfactoria.

2.5 Recursos humanos del proyecto

Se dispone de un equipo con un único miembro, yo, Luis Hijarrubia Bernal, quedesempeño todos los roles antes mencionados y cuyo trabajo tiene el objetivo de la realizacióndel trabajo final de máster. Tengo experiencia artística muy limitada, pero con experienciaacadémica y laboral en Ingeniería en Informática.

Tengo una leve experiencia anterior al máster en informática gráfica gracias a unaasignatura optativa cursada en la Ingeniería, pero el grueso de los conocimientos son losadquiridos en el máster en informática gráfica, juegos y realidad virtual, por lo que el presentetrabajo supone la prueba de la capacitación adquirida en estos estudios.

16

2.6 Seguimiento y control del proyecto

2.6.1 Gestión de requisitos

Los requisitos del sistema son especificados en el artefacto Documento de especificaciónde requisitos software. Cada requisito tendrá un conjunto de atributos que permitirán realizarsu seguimiento a lo largo de las diferentes iteraciones del proceso de desarrollo.

En el caso de que sea necesaria la introducción de cambios en los requisitos, éstos seránevaluados y aprobados en un Documento de solicitud de cambios como parte del proceso degestión de configuraciones y serán introducidos en versiones posteriores del Documento deespecificación de requisitos software.

2.6.2 Control de calidad

Todos los entregables deben pasar por un proceso de revisión, que permita asegurar quecada uno de los artefactos producidos tenga una calidad aceptable. Para ello se seguirán lasguías de revisión y listas de verificación propuestas en el proceso unificado. Los defectosencontrados en los diferentes procesos de revisión deben ser documentados para permitir suseguimiento y facilitar su corrección.

2.6.3 Informes y medidas

Las medidas del esfuerzo y del tiempo serán tenidas en cuenta a la hora de realizar tantola planificación como el control y seguimiento de las diferentes actividades involucradas en elproyecto, permitiendo de esta forma hacer una estimación del progreso del mismo.

Los Planes de iteraciones sucesivas servirán a modo de informes para conocer el estadoactual del desarrollo. En ellos se enumerarán los criterios para considerar cumplidos los obje-tivos de cada iteración así como se llevará a cabo una evaluación de la situación actual delproceso de desarrollo y del producto. Esta evaluación se basa en las medidas anteriormentecomentadas y en los riesgos.

A partir de es ta información se tomarán las decisiones oportunas para mejorar y ajustarel proceso de desarrollo.

2.6.4 Gestión de riesgos

Durante la fase de inicio se creará un documento con una lista de riesgos asociados al proyectoy sus respectivos planes de contingencia para poder mitigarlos o controlarlos. Esta lista seráevaluada posteriormente para facilitar la gestión de riesgos. Esta información queda registradaen la sección 2.7 de la presente memoria.

17

2.6.5 Gestión de configuraciones

El objetivo de la gestión de configuraciones es mantener la integridad de los artefactosque se generan durante el proceso de desarrollo, garantizando que no se realizan cambiosincon-trolados, disponiendo siempre de la versión adecuada de los productos manejados.

Por ello es fundamental la gestión de solicitudes de cambio, informando de lasmodificaciones producidas para que queden registradas y no den lugar a errores.

Al finalizar cada iteración se actualizará un registro del estado y versión de cada artefactodurante el proceso de evaluación de la situación actual del proceso de desarrollo y del productoque se realiza en el Plan de iteración correspondiente.

2.7 Gestión de riesgos

2.7.1 Propósito

El gestor del proyecto, debe anticiparse a los riesgos que puedan surgir durante elproceso de desarrollo de software y comprender su posible impacto para, de esta manera, sercapaz de afrontar en las mejoras condiciones posibles los posibles problemas que puedan traerconsigo los riesgos identificados. [2]

El propósito de esta sección es, en primer lugar, identificar y realizar un análisis de losposibles riesgos que se puedan dar y, a continuación, establecer unas pautas de monitorizaciónde los mismos y definir un plan de acción para cada uno de ellos que permitan gestionarlos encaso de ocurrencia.

2.7.2 Identificación y análisis de riesgos

En este apartado se describen detalladamente los principales riesgos encontrados y seefectúa un estudio de su probabilidad, impacto y en qué parte del proceso de desarrollopueden ocurrir.

En dicho estudio se utilizan dos tipos de clasificaciones que se enumeran a continuación

La clasificación de categorías de riesgos utilizada en este documento es la siguiente:

• Del proyecto: Aquellos riesgos que puedan estar relacionados con la puesta en marchay toda la documentación asociada.

• Del proceso: Aquellos riesgos relacionados con la gestión del proyecto.• Del producto: Aquellos riesgos asociados al dominio de la aplicación.

La clasificación del impacto de los diferentes riesgos sigue el siguiente criterio:

• Catastrófico: si se produjera el riesgo, se fracasaría en el objetivo.• Crítico: supone una degradación del rendimiento del proceso y del sistema final.• Marginal: consiste en un fracaso de menor grado en un objetivo no primordial.• Despreciable: se trata de un inconveniente menor.

18

19

2. Falta de experiencia

Escenario Debido a la experiencia real del recurso humano en el ámbito de apli-cación es posible que se produzca algún fallo durante su desarrollo.

Contexto Este riesgo puede darse a lo largo de todo el proceso.

Categoría De producto.

Probabilidad 70 %

Impacto Marginal

Creador Cualquiera de los roles del equipo puede verse afectado.

Consecuencias Ralentización en el avance de las diferentes iteraciones.

1. Dificultad en el manejo y aprendizaje de las metodologías

Escenario En el caso de que acontezca el riesgo, debe obtenersedocumentación lo antes posible acerca del proceso unificado.

Contexto Este riesgo se puede dar en todas las actividades relacionadas con lagestión del proyecto y en los procesos relacionados con el producto.

Categoría Del proceso y del producto.

Probabilidad 30 %

Impacto Crítico

Creador Cualquiera de los roles del equipo puede verse afectado.

Consecuencias Necesidad de un mayor número de horas para el aprendizaje yaplicación de las metodologías en el desarrollo del proyecto.

3. Disponibilidad a tiempo parcial de los miembros del equipo

Escenario Debido a que el desarrollo del software es llevado a cabo por unaúnica persona, sobre la cual recaen otra serie de responsabilidadesacadémicas y laborales, es posible que su dedicación al mismo nosea a tiempo completo.

Contexto Este riesgo es mucho mayor durante la parte de asignatura deTecnología de juegos.

Categoría De proceso.

Probabilidad 40 %

Impacto Marginal

Creador Desarrollador

Consecuencias Si las revisiones no son correctas, el error se arrastraría a lo largo delas diferentes iteraciones.

20

5. Modificación de los requisitos

Escenario Debido a la falta de información disponible en un momento dado, anuevas ideas durante el proceso creativo o a eventos externos puedeser necesario modificar los requisitos en las sucesivas iteraciones.

Contexto Este riesgo puede darse a lo largo de todo el proceso pero es muchomás probable en las primeras iteraciones.

Categoría De proceso.

Probabilidad 70 %

Impacto Crítico

Creador Desarrollador

Consecuencias Las consecuencias dependerán de en qué iteración del proyecto seproduzca el riesgo y de la importancia del requisito. Debe tenerse encuenta que en las fases finales esta modificación tendrá un mayorimpacto.

4. Retraso en las planificaciones de las iteraciones

Escenario Debido a una planificación poco realista de las sucesivas iteracionespueden producirse demoras e incumplimiento de las fechas esta-blecidas en el plan de fases.

Contexto Este riesgo puedo darse a lo largo de todo el proceso, en cualquierde las iteraciones, debido a una planificación errónea.

Categoría De proceso, concretamente de gestión.

Probabilidad 70 %

Impacto Crítico

Creador Jefe de proyecto.

Consecuencias Retraso en la entrega de los distintos artefactos así como del pro-ducto final.

21

6. Desarrollo de interfaces incorrectas

Escenario Debido a un mal diseño del software o diseño de mecánicas o dejuego, podemos encontrar con un número excesivo de interfaces,interfaces mal definidas o con una mala comunicación entre dife-rentes interfaces. Se puede aplicar tanto a interfaces entre compo-nentes software como a las interfaces gráficas de usuario.

Contexto Puede aparecer a partir de la etapa de diseño e implementación decada uno de las sucesivas iteraciones, una vez se van haciendopruebas con usuarios.

Categoría De producto.

Probabilidad 30 %

Impacto Marginal

Creador Desarrollador

Consecuencias Reestructuración de los artefactos de diseño.

7. Falta de revisiones efectivas

Escenario Deben hacerse exposiciones de la situación actual y revisiones delproceso y del producto después de cada iteración. Existe el riesgo deque no se hagan o no sean efectivas.

Contexto A lo largo de todo el desarrollo del proyecto.

Categoría De proceso.

Probabilidad 50 %

Impacto Marginal

Creador Cualquier rol del equipo.

Consecuencias Si las revisiones no son correctas, el error se arrastrará a lo largo delas diferentes iteraciones hasta que se localice.

8. Hacer de hombre orquesta

Escenario El desarrollo llevado a cabo por una sola persona implica tener querealizar trabajo en todos los campos: programación, diseño, mode-lado, sonido... Esto puede hacer que haya partes en las que elrecurso tenga menos experiencia o capacidad. Se intentará poner unmayor énfasis del desarrollo en lo que se da bien y buscar solucionessencillas o buscar ayuda externa en los campos que se denespecialmente mal.

Contexto A lo largo de todo el desarrollo del proyecto.

Categoría De producto

Probabilidad 80 %

Impacto Marginal

Creador Cualquier rol del equipo.

Consecuencias Retraso en completar tareas o artefactos que no cumplen la calidadrequerida.

22

9. Sobrecarga en la parte visual

Escenario Es posible que la concentración en conseguir un mundo onírico llenode distorsiones afecte la jugabilidad haciendo el juego difícil o desa-gradable de jugar. Habrá que tener cuidado que cada efecto gráficointroducido no arruine la jugabilidad.

Contexto Durante la fase de elaboración.

Categoría De producto

Probabilidad 40 %

Impacto Marginal

Creador Jefe de pruebas

Consecuencias Fuerza un re-equilibrado del juego.

10. Falta de compresión de trama y objetivos

Escenario Es posible que la historia, extraña y los objetivos del juego no que-den claros al jugador. Se intentará dar todas las pistas que se pue-dan sin sacar de la ambientación del juego y se harán pruebas conpersonas a las que no se haya contado a priori las ideas del juego.

Contexto Durante la fase de elaboración.

Categoría De producto

Probabilidad 40 %

Impacto Marginal

Creador Jefe de pruebas

Consecuencias Se podrían tener que hacer cambios en el diseño de niveles.

11. Restricciones de hardware

Escenario Se pretende que el juego llegue a correr en móviles. Para ello hayque tener en cuenta este objetivo en todas las fases del proyectopara tener texturas adaptadas, la elección de ciertas característicasgráficas, algoritmos de sombreado, complejidad de modelos etc,tendiendo siempre a lo más sencillo computacionalmente, o a tenervarias versiones según la plataforma.

Contexto Durante todas las fases

Categoría De producto

Probabilidad 50 %

Impacto Crítico

Creador Todos los roles

Consecuencias Se podrían tener que hacer cambios en fases tardías del desarrollo,al tener problemas de rendimiento en las fases finales.

2.7.3 Plan de acciones y monitorización

Para finalizar la gestión de riesgos, en este apartado se exponen los diferentes planes deacción para cada uno de los riesgos identificados en el apartado anterior. Se proporciona elescenario en el que podría darse el riesgo, el proceso de monitorización del mismo junto a lospuntos de comprobación oportunos, el tipo de estrategia y los pasos a seguir en caso de que elriesgo se desencadene.

La clasificación utilizada para determinar la estrategia a aplicar a cada riesgo es lasiguiente:

• Evitación del riesgo: previene la ocurrencia del riesgo, reduce la probabilidad a cero.

• Protección del riesgo: reduce la probabilidad y/o consecuencia del riesgo antes deque ocurra.

• Reducción del riesgo: reduce la probabilidad y/o consecuencia del riesgo después deque ocurra.

• Investigar el riesgo: obtener una mayor información para eliminar o reducir laincertidumbre.

• Reservar el riesgo: utilizar la planificación reservada previamente.

• Transferencia del riesgo: reorganizar las cosas para desplazar el riesgo a otra parte.

Se muestra a continuación un resumen de los planes de acción para cada riesgo. El puntode comprobación de cada riesgo con las fases contexto del riesgo. Las estrategias utilizadasson: Reservar para los riesgos 1, 2, 3, 4, 8 y 11; Investigar para los riesgos 5, 9 y 10;Reducción para el riesgo 6 y Protección para el riesgo 7.

23

24

Capítulo 3: Concepto inicial

3.1 Tipo de juego

Es un juego de tipo plataformas, con gráficos en 3D, pero una jugabilidad 2.5D, ya queuna de las dimensiones está bastante restringida por una cámara sobre raíles. En el juegotambién se añaden peleas con enemigos, a espada, no saltando sobre ellos como es habitualen el género, pero no llega a ser un Beat 'em up o un Hack'N'Slash. También hay seccionesque necesitan algo de lógica para ser superadas, pero todo enmarcado dentro del géneroplataformas.

3.2 Título

El título del juego es Temet nosce, la versión latina de la expresión “Conócete a ti mismo”griega (Gnóthi Seautón). He elegido la versión latina porque es más sencilla de escribir yporque es la que se usa en Matrix [27], película que tiene cierta relación con algunas de lasideas del juego.

Barajé varios candidatos y durante la primera presentación de Tecnología de juegosrealicé una encuesta no vinculante entre los alumnos y profesor para ayudar a tomar ladecisión, los candidatos eran:

• Me inside myself

• Mind tales

• Temet nosce

En la encuesta la decisión por Temet nosce fue unánime, y finalmente fue el nombre deljuego.

25

3.3 Trama argumental

Una lucha más entre el bien y el mal está teniendo lugar en un bosque. El héroe deljuego lucha contra un gran monstruo para rescatar a un ser querido secuestrado. El héroevence, pero en un lance del combate el monstruo le ha envenenado.

El juego supone el viaje ludoficcional del héroe por su propio subconsciente luchandocontra el veneno. Es la percepción del protagonista de la lucha de su cuerpo contra el veneno,en un paseo por su subconsciente, y cuanto más efecto le haga el veneno el viaje será másfebril y alucinógeno. Las acciones del mundo real afectarán al subconsciente del héroe y suviaje. Por ejemplo, una hoja que cae en su cara puede hacer que su subconsciente pase a serun mundo verde, o un cañón seco en el subconsciente puede llenarse de agua bebiendo unpoco en el mundo real, dejando ver la metalepsia narrativa que supone el viaje completo. Enun momento del viaje es consciente de dónde está y lo usa a su favor para controlar algunascosas, rompiendo las reglas del mundo que le rodea, como por ejemplo la gravedad.

Finalmente el héroe consigue vencer al veneno, volviendo su consciencia al mundo real.No sin antes descubrir que el monstruo sigue con vida, aunque esta vez será más fácil acabarcon el, ya que el viaje introspectivo le ha servido para conocerse mejor (Temet Nosce) ydescubrir nuevas habilidades.

Esta es la historia original planteada, aunque puede ser recortada por gestión técnica delproyecto. Por ejemplo el personaje del secuestrado puede tener muy poco peso en el juegopara el esfuerzo de diseño y modelado que requiere. O la lucha sorpresa contra el monstruo alfinal del juego puede requerir diseñar un monstruo animado y con IA completa en un escenarionuevo, así que se podría recortar dando como final alternativo el despertar del héroe y elretorno de su consciencia al mundo real tras la lucha interna contra el veneno.

3.4 Ambientación

Mundo externo

Del mundo externo solo se verá un claro de un bosque donde sucederán las luchas contrael monstruo. El bosque será genérico, sin nada en especial para enfatizar todavía más elcarácter fantástico del subconsciente donde jugamos.

Primera fase

La primera fase en el subconsciente del protagonista será a cielo abierto, con decoraciónorgánica. Será la parte más onírica. En un mundo extraño donde no tengo porqué seguir reglasrealistas.

Entre las referencias artísticas a tomar se encuentran:

• Antoni Gaudí: Las formas orgánicas de sus edificaciones, la decoración con cerámicarota y el tono de color según la intensidad de la luz que afecte a una zona se copiarán.En particular se quiere recrear un paseo con columnas oblicuas que se encuentra en elParque Güell.

26

• Earthworm Jim: Los mundos del juego, absurdos en naturaleza y sus fondos conestalagmitas de tierra como agujas hacia el cielo, además del fondo con un estilo algodeferente a la acción en primer plano. [47]

• Beetlejuice: tanto la película [13], como la serie de dibujos animados [17], muestranen el No-Mundo espacios abiertos, arenosos, con rocas y un fondo que no encaja con elprimer plano dando la sensación de mundo de fantasía.

27

Imagen 1: Parque Güell por Gaudí

Imagen 2: Earthworm Jim

• Alicia en el país de las maravillas: Tomada como referencia la película de dibujosanimados de Disney, que muestra un mundo de fantasía donde muchas reglas delmundo real no se aplican, las líneas son intencionadamente curvas y los tamaños y lacontinuidad espacio-tiempo no refleja el mundo real. [15]

• El mago de Oz: Esta película también cuenta un viaje de la protagonista por un mundofantástico antes de poder volver a la realidad, y el camino es bastante cerrado. Por eso

28

Imagen 3: Bettlejuice (película)

Imagen 4: Alicia en el país de las maravillas

me gustaría utilizar la referencia del camino de baldosas amarillas en algún momentode la primera pantalla del juego si el diseño de juegos hace el camino muy lineal. [16]

• Tideland: En las imágenes promocionales de la película se mostraba un mundofantástico donde lo que es real y lo que no se mezclan y en particular me gusta la ideade los árboles boca abajo o al revés. [19]

Otra de las ideas, no adscrita a ninguna referencia cultural, es que el cielo refleje unaproyección de lo que sucede alrededor del héroe en el mundo real. Si bien se es consciente delas dificultades técnicas de esta propuesta.

Segunda fase

En la segunda fase el héroe es consciente de dónde se encuentra y se acerca más a supropia consciencia, por ello esta fase es a cielo cerrado, con un diseño que permita jugarcambiando la gravedad y una ambientación más angustiosa y artificial.

Las mayores referencias artísticas a tener en cuenta son:

• Bettlejuice: También en los interiores la inspiración de Bettlejuice es valiosa, ya quejugando con cosas sencillas, como deformar las formas originales para espacios ano-dinos se consiguen mundos muy oníricos. [13] [17]

29

Imagen 5: Tideland

• Metrópolis: En esta referencia absoluta de la ciencia ficción el ambiente opresivo seconsigue también mediante la arquitectura mostrada, industrial y monstruosa. [21]

• Brazil: Otro ejemplo de arquitectura industrial para provocar una sensación de mons-truosidad, los tubos aquí usados pueden ser obstáculos en el juego. Además la películamuestra un futuro con estética de los años 40. [18]

30

Imagen 6: Bettlejuice (película)

Imagen 7: Metrópolis

Imagen 8: Brazil

• Tron: Las líneas iluminadas sobre los fondos que representan los circuitos en el mundovirtual pueden servir en el juego para representar el flujo de ideas en el subconsciente.Tron es otra película referencia argumentalmente pues supone el viaje del héroe por unmundo fantasioso (virtual en este caso) antes de poder regresar a la realidad. [22]

• Cube: La decoración de las paredes ayuda a crear el ambiente agobiante de estapelícula. [24]

Viaje

Es importante el viaje del personaje desde el mundo real a su subconsciente. Este sehará a través de un agujero de gusano, efecto por el que tengo un gusto personal y que creoes muy apropiado en este momento. Intentaré imitar momentos de tres películas:

• Los mundos de Coraline: Se trata de un túnel que parece orgánico, no es regular yva cambiando su iluminación con un halo de luz que lo va recorriendo. Tienetonalidades azules y rosas. [26]

31

Imagen 9: Tron

Imagen 10: Cube

• 2001: Una Odisea del Espacio: El viaje que se da hacia el final de la película es artís-ticamente maravilloso y me gustaría transmitir algo similar, con mis posibilidades, en eljuego. Aquí las dimensiones se doblan, hay tramos verticales y horizontales, me inte-resan más los verticales que creo que transmiten más. Los colores van variando a lolargo del tiempo, y dan la idea de estrellas que vemos pasar muy rápido, por lo quefuncionan como puntos de fuga del movimiento del viaje. [20]

• La guerra de las galaxias: Cuando las naves espaciales de esta película entran en hipervelocidad, las estrellas, puntos blancos en el horizonte se transforman en puntos de fuga debido a la velocidad. Este efecto también se intentará recrear. Aunque el viaje de la película es más físico, mientras que en las anteriores representaba uno más espiritual por parte de los viajeros. [23]

32

Imagen 11: Los mundos de Coraline

Imagen 12: 2001: Una Odisea del Espacio

Distorsiones

Las distorsiones son, junto al diseño de niveles, la parte más importante de la ambien-tación. Reflejan el estado del personaje, cuanto más efecto hace el veneno (menos saludtenemos), las distorsiones son mayores, lo que hace más difícil jugar y vencer al veneno.

Estas distorsiones pueden ser: ojo de pez, cambio en el contraste o los colores, excesivocegado del sol (sun shaft), remolino en la imagen, ruido sobre la imagen, detección de bordes,tintado de la imagen u otros. No tienen por qué usarse todos, ni todos en la misma parte deljuego. Todo esto se decidirá en el equilibrado del juego, para que las distorsiones no hagan laexperiencia de juego más desagradable de lo necesario.

También se va a usar el efecto dolly-zoom, también conocido como efecto Hitchcock, enel que mientras aleja la cámara, se disminuye el Field of view o viceversa [83]. Con esto seconsigue tener el objeto o personaje de primer plano fijo, pero que la perspectiva del escenariovaríe enormemente dando la impresión de que algo ha ocurrido con el personaje. Quiero usareste efecto para el momento en que el personaje, en el mundo real, siente el efecto delveneno y comienza a encontrarse mal.

El sonido también sufrirá distorsiones, tanto la música como los efectos de sonido,cambiarán su tonalidad, siendo más grave cuando peor esté la salud del protagonista, dandouna sensación más tétrica.

Me gustaría añadir como referencia musical en la primera pantalla alguna versión de Lasánimas del terror, canción que acompaña una escena en Dumbo [14] en la que el elefantesufre alucinaciones después de haber bebido [65]. Creo que es una buena referencia, porqueal igual que Dumbo el protagonista del juego no entiende muy bien en la primera pantalla quees ese mundo alucinógeno por el que está pasando.

Interrupciones

Durante la parte jugable pueden aparecer imágenes en pantalla, interrumpiendo elnormal desarrollo del juego, en forma de pequeños flashazos en la mente del protagonista.

33

Imagen 13: La guerra de las galaxias

Esas imágenes serán algunas de las que tiene el protagonista grabadas en su memoria, lamayor parte referencias culturales. Las imágenes aparecerán de forma aleatoria siendo másprobables cuanto más le haya afectado el veneno. Este recurso es habitual en películas dondeel protagonista tiene repentinos dolores de cabeza y alucinaciones como Pi, fe en el caos. [12]

Para el ruido de cuando se vean las imágenes a modo de interrupción de la señal seusará el principio del titantrón de CM Punk en 2012, antes de la canción Cult of Personality deLiving Colour. [60]

3.5 Personajes

Héroe

El protagonista de la aventura será un humanoide delgado y pequeño, puede serhumano, elfo o similar, incluso no tiene porqué quedar claro en el juego. Me gustaría quetuviera gorro, pañuelo o algo similar en la cabeza. Esto por una parte hace que no me tengaque preocupar mucho por la animación del pelo y me ayudará a distinguir cuando se estádentro del subconsciente y en el mundo real, ya que en el mundo real habrá perdido elpañuelo y estará magullado, pero dentro de sí mismo se proyectará una imagen idealizada enla que se ve perfecto y conserva el pañuelo. Llevará una espada con la que defenderse de losenemigos.

Es un joven valiente, pero no excesivamente maduro, por lo que el viaje que le esperaserá clave en su desarrollo personal. Puede ser bastante irónico, pudiendo dar referencias acultura general o de su mundo particular, tal y como le ocurre al protagonista (sin nombre) delSecret of Evermore. [50]

Como modelos visuales, de una forma ideal tomo el Link adulto de algunos juegos deZelda [41] y “Hero” de Dragon Quest VIII [34], ya que ambos cumplen la estética y funcio-nalidad que necesito del personaje.

Hay un efecto que me gustó desde que vi el vídeo de Kayne West [66], y es el conceptode cara negra, como si tuviera un agujero en la cara. En el vídeo se ve [0:35-0:55] el efectode agujero en la cara, y después [2:05-2:10] tiene una parte donde con la cara negra, lebrillan los ojos en blanco como los lobos de noche. No es la única referencia de este tipo,también está el agujero en la cara de Squall en el final del Final Fantasy VIII [51], lo que diopie a teorías muy interesantes sobre la historia.

Me gusta visualmente este efecto y además encaja con la filosofía del juego. Mi idea esque cuando la vida esté por debajo del 75% la sonrisa del protagonista cambie por un gestomás serio, y la cara se le oscurezca. Al bajar del 50% la cara sea un agujero negro, donde solodistingamos su cicatriz. De esta forma el estado exterior del personaje, cómo le está afectandoel veneno, quedará representado en la cara del avatar con el que está recorriendo su propiosubconsciente. La imagen residual que tiene de sí mismo estará afectada por su estado físico,y en este momento se siente como si algo le estuviera comiendo por dentro. Por último si lavida baja del 25% aparecerán unos ojos blancos brillantes en la cara negra del protagonista,que saca la última fuerza que le queda dentro, su canto de cisne.

34

Monstruo

El monstruo del mundo real tiene que ser grande y aparentemente venenoso. Si final-mente se pudiera luchar contra él tendría que ser sencillo de animar, si solo va a formar partede la historia, podría ser cualquier monstruo genérico de librería.

Si tuviera que modelarse y animarse para poder luchar contra él, estas serían las refe-rencias:

• Fernandeath: Enemigo final del juego de lucha Waku Waku 7, es básicamente unagran bola negra con alas, y otras 4 bolas pequeñas que hacen sus extremidades, esmuy expresivo, ya que es básicamente una cara gigante. [52]

35

Imagen 14: Link (izquierda) y Hero (derecha)

Imagen 15: Kayne West (izquierda y centro) y Squall (derecha)

• Molbol: Enemigo habitual en la saga Final Fantasy, es una gran bola con tentáculos, aligual que Fernandeath, es casi todo cara, teniendo una fusión de cuerpo y cabeza.Siempre es venenoso. En la imagen la versión de Final Fantasy VIII [51] con ciertoparecido a Audry II, la planta de La tienda de los horrores (1986).

• Weezing: Es el prototipo de Pokémon venenoso, evolución de Koffing. Comparte quetiene la cara o caras en un único elemento cuerpo-cabeza. En ser casi una bola conprotuberancias, muy sencillo.

36

Imagen 16: Fernandeath

Imagen 17: Molbol

Imagen 18: Weezing

Secuestrado

Es la figura menos definida. En ningún caso va a ser jugable, ni enemigo y solo tieneimportancia para la historia, no durante el gameplay. Podría ser una chica tipo princesa,aunque eso sería muy tópico, un perro, robotito... Si me gustaría que al menos tuviera lacapacidad de hablar por si el juego lleva cinemáticas que ayude a explicar cosas como que elprotagonista ha sido envenenado.

Comenzaré buscando por bancos de modelos libres, para ver si encuentro algo que meencaje, no voy a invertir tiempo en modelar un personaje que no aparece durante la mayorparte del juego, teniendo en cuenta la falta de recursos del proyecto.

La opción de la princesa me llama precisamente por ser la más tópica, para partir de unahistoria inicial muy manida pero llegando a un juego y a un viaje no tan habitual.

Veneno

Habrá 2 tipos de enemigos comunes en el juego, ambos son tipos de venenos, aunqueuno será en veneno genérico y otro el veneno ciego.

El veneno ciego sigue una ruta prestablecida y no reacciona ante el jugador, por lo quesupone más un obstáculo que un enemigo. El veneno genérico si intenta atacar al personaje ytiene su propia inteligencia artificial.

La referencia artística para el veneno ciego es un monstruo del Ni No Kuni [33]. En eljuego español se llama Moko, en inglés Pom Pom. Es un bicho verde, una bola con pequeñostentáculos colgando. Parece fácil de hacer y encaja con el diseño del tipo de veneno genérico,pero se distinguen. Seguramente haga cambios, dejando solo 2 tentáculos y más largos, quelos mueva al hacer su recorrido, para dar la sensación de guardia haciendo su ronda.

Para el veneno genérico tengo una combinación de ideas. Por un lado, el modelo delmonstruo slime de Dragon Quest [34], que es como una gota y me gusta la idea de que cadaenemigo sea como una gota de veneno. Para ser de veneno, en lugar de azul, como el slimeoriginal, tendría que ser verde. Y por otro lado quiero añadir una característica del alcalde dePesadilla antes de navidad [25]. Este personaje tiene dos caras, una delante, amable y otradetrás enfadado. Aunque realmente su estado de ánimo lo da la cara que esté delanteactualmente, porque puede girar la cabeza, eligiendo qué cara mostrar. Así el venenocomenzará mostrando su cara amable, y si le atacamos mostrará otra más agresiva.

37

Imagen 19: Moko

Cuando pensé en que el juego iba a suceder en el subconsciente, un mundo ajeno a lasnormas físicas reales, podría jugar entre otras cosas con la sombra. Pensé que la sombra delhéroe no correspondiera a su figura, que pudiera ser de un caballo, o cualquier otra cosa. Noera el primero en jugar con esto, por ejemplo siempre me gustó mucho el poster promocionalde La amenaza fantasma, donde Anakin proyecta en su sombra a Darth Vader. Y esto me hizopensar que ahí la sombra no correspondía al cuerpo que la proyecta, pero tiene cierto sentido,no es una forma al azar y loca, es la sombra de en lo que se va a convertir. Y empecé a pensarcómo usar la sombra de forma surrealista, pero útil.

Usarla en el héroe tenía varios problemas técnicos para proyectar una sombra que notenga que ver con el modelo y se mueva según la animación interna de éste. Así que penséque sería mucho más fácil usarlo con el enemigo, el veneno, que es poco más que una bola, susombra es fácil, y es un modelo sin animación interna, es decir, no mueve brazos o piernas,solo flota.

Pensé en usar la sombra del veneno para hacer ver su estado. Lo primero si está enreposo o atacando. Si está en reposo su sombra es redonda, la que esperamos por su forma.Si está atacando, la sombra toma forma de triángulo, con uno de los vértices apuntando haciadonde se dirige su ataque. Además la sombra de triángulo se pondrá unas décimas antes deque comience a atacar, avisando al jugador del ataque, y haciendo que pueda esquivarlo siestá muy atento. Además, las sombras estarán bien definidas si el veneno nos está mostrandosu cara de contento, pero si nos muestra su cara de enfadado, la sombra será puntiaguda,tanto la redonda como la triangular.

Cabe la posibilidad de utilizando el mismo personaje de gota de venenos, pero dando ungran tamaño se construya un enemigo final de mitad o final de fase.

38

Imagen 20: Slime

Imagen 21: Alcalde de Pesadilla antes de navidad

Tanto el veneno genérico, como el ciego serán dañino al contacto, así que su ataqueconsistirá en tocar al protagonista. Serán relativamente fáciles de eliminar, aunque pueden serbastante numerosos.

3.6 Diseño del juego

3.6.1 Mecánicas

El juego será un plataformas. Tendremos que avanzar con el protagonista por escenarios,realizando saltos, esquivando agujeros o encontrando el mejor camino para seguir avanzando,y también habrá que eliminar a los enemigos a mamporros. Idealmente los ataques se haráncon espada, si no da tiempo a realizar las animaciones de ataque con espada, se comenzarápor implementar un ataque de tipo proyectil, como por ejemplo lanzar bolas de fuego.

Así las acciones principales del protagonista se reducen a 3: moverse, corriendo o an-dando por el escenario, saltar y atacar. Serán las acciones transversales que se darán durantetodo el juego, aunque en momentos puntuales habrá otras mecánicas.

En la segunda pantalla, tal y como se vio en el prototipo de Tecnología de juegos [69], elprotagonista podrá cambiar la gravedad a su antojo. Transformar esto en mecánica no essencillo, ya que un cambio de gravedad completamente libre haría muy complicado el diseñode niveles, ya que alguien con experiencia en el juego podría ir cambiando la gravedad en losángulos apropiados para pasar todo el nivel como si fuera una caída continua, incluso losnovatos podrían avanzar una buena zona de juego si colocan, por suerte, la gravedad de laforma apropiada. Por ello se necesitan ciertas restricciones. La gravedad solo se podrá cambiartomando como eje de giro el de avance de la cámara. Es decir, que desde el punto de vista deljugador podrá poner la gravedad hacia abajo, derecha, izquierda y arriba, pero no hacia elfondo o hacia la propia cámara. También se necesitará un pequeño tiempo de recuperación trascambiar la gravedad para poder volver a cambiarla, con esto se intenta conseguir que eljugador no pueda volar cambiando la gravedad continuamente.

Otra característica es que si caemos por algún precipicio el personaje no muere comosucede en otros juegos de plataformas, sino que volvemos a caer desde el cielo estrellándonoscontra el suelo en un punto de respawn, y este golpe nos costará una parte de nuestra salud.De esta forma el juego no es tan exigente con una serie de saltos perfectos, pero si que nospenaliza los fallos, además al tener menos salud las distorsiones aumentarán, haciendo másdifíciles los siguientes intentos. El concepto de espacio conectado, de tal forma que salir por unlado supone aparecer por otro es bastante antiguo y se da en clásicos como Pacman oAsteroids.

Otra opción interesante es la de que haya interacción entre el mundo real y el subcons-ciente en el que jugamos. Esta metalépsis podría ser narrativa, o lo que nos interesa en estecaso, lúdica. Por ejemplo que los sucesos del mundo exterior cambien la forma en que vemosel subconsciente o que necesitemos algo del mundo real para poder desbloquear un camino enel subconsciente.

3.6.2 Controles

Aunque el juego inicialmente solo funcione en PC, se va a intentar que pueda funcionaren un futuro en dispositivos móviles y por ello toda la parte de análisis va a incluir también

39

esta posibilidad y se va a desarrollar teniéndolo en cuenta. Por ello los posibles dispositivos conlos que jugar que vamos a tener en cuenta son: teclado, controlador y pantalla táctil.

Las funciones básicas del juego son:

• Movimiento: Se podrá mover al personaje en todas direcciones y de forma inmediatasobre el plano del suelo. Para ello se necesitan 4 teclas, cruceta o joystick (Real ovirtual). El movimiento será siempre encarando la dirección de avance y el giroinmediato.

• Botón de salto: Servirá para saltar, como es evidente. Habrá un salto mínimo y cuantomás tiempo se deje pulsado el botón más alto se saltará hasta un salto máximo.

• Botón de ataque: Al pulsarlo el personaje realizará un ataque, si se pulsa durante eseataque se pasará a realizar otro de combo. También se puede atacar durante el salto.

• Botón de pausa: Pausará el juego y se accederá a un menú.

• Cambio de gravedad: se necesitan 3 botones, o un segundo joystick o una soluciónalgo más creativas para dispositivos móviles. Cambiará la gravedad invirtiéndola o haciaderecha o izquierda según la dirección que se pulse.

• Botón de interacción con el mundo real: Este botón es opcional, solo si se consiguetener varios ejemplos de interacción con el mundo real como para que merezca la penatener un botón de forma explícita para esta acción.

Las configuraciones de movimiento por defecto (ya que en muchos casos se podráncambiar) son:

• Para teclado: Movimiento con las flechas de desplazamiento. Ataque: control. Salto:barra espaceadora. Gravedad: a-w-d. Pausa: esc. Interacción: e.

• Para mando (supongo mando con 2 joysticks o cruceta y joystick): Movimiento conjoystick izquierdo o cruceta. Cambio de gravedad con joystick derecho. Salto con botóninferior y ataque con botón izquierdo. Pausa con el botón que tenga el mando a talefecto (start) e interacción con algún botón que quede libre, preferiblemente select.

• Para pantalla táctil / dispositivos móviles: En la imagen siguiente se puede ver lacolocación de botones sobre una captura del juego Medievil para reflejar la idea. ElJoystick (J) no será fijo, sino que se colocará alrededor de la pulsación del dedo. Elbotón A es el de ataque, S de salto, II es la pausa y O el de interacción con el exterior.Se trabajará en un control mediante giro del dispositivo, de tal forma que la parte de

40

Imagen 22: Diseño de controles en dispositivos móviles

abajo de la imagen en el dispositivo girado sea directamente la gravedad. Por ejemplosi estamos jugando en modo landscape izquierdo, si queremos invertir la gravedadtendremos que girar el dispositivo hasta landscape derecho.

3.6.3 Cámara

La cámara del juego será una cámara sobre raíles. Al dar el salto al 3D los juegos deplataformas tomaron dos caminos. Uno fue el que tomó Mario, con Super Mario 64 [40], elprimer juego en 3D de la franquicia apostó por una cámara virtual con modos automático ymanual. Tanto si el juego intentaba dar la mejor perspectiva, como si el usuario la ajustaba,podíamos mover la cámara alrededor del personaje con libertad, mirando prácticamente encualquier dirección. Esto daba al juego más peso en las exploración, ya que había que recorrerlos escenarios encontrando cosas escondidas. Por otro lado, Crash Bandicoot [37], ofrecía elotro camino, escenarios lineales, con jugabilidad en 2.5D (aunque nos movíamos en los 3 ejes,uno estaba fuertemente restringido), y cámara sobre raíles. Esto permitía un mayor control enel diseño de niveles de lo que nos encontrábamos y en qué orden, con una sucesión deobstáculos, enlazando más directamente con la jugabilidad 2D de los plataformas clásicos.Además la cámara nos aseguraba estar siempre en la mejor posición posible, aunque nopodíamos explorar libremente los escenarios, ni siquiera podíamos ver la parte de atrás dealgunas construcciones.

El elegir el segundo tipo de cámara es por dos razones. Hace más sencillos los controles,hay que tener en cuenta que ya tengo una serie de botones, un segundo joystick o el giro delmóvil comprometidos para el cambio de gravedad. Si la cámara se puede mover necesitaremosañadir otro control en dos ejes (joystick, 4 botones o movimiento) y el total del juego se haríamuy complicado. Además el cambio de gravedad con cámara libre sería problemático, hehecho pruebas con cambio ajustado a los ejes y funciona, pero deja muy poca libertad en eldiseño de niveles y tiene casi el mismo problema de poder avanzar todo el escenario deinmediato eligiendo bien la dirección de la gravedad.

2.6.4 Items

Solo habrá un item en el juego y será el que recupere parte de la vida del personaje.Este item se consigue al acabar con una horda enemiga. Será diseñado como una pirámidedorada. Se recogerá andando por encima. Será permanente hasta ser recogido, es decir, nodesaparece pasado un tiempo. El efecto es inmediato, y no se puede almacenar el item parausarlo más adelante.

2.6.5 Gestión de la salud

Él protagonista tendrá un nivel de salud que se representará por una barra vertical enpantalla. Esta vida tendrá 4 regiones: [0%-25%], [25%-50%],[50%-75%] y [75%-100%].

La vida se irá perdiendo automáticamente en todo momento, pues el protagonista estáenvenenado, y el veneno poco a poco va haciendo su efecto. Esto hace que si nos quedamosparados o atascados mucho tiempo muramos. Pero no se trata de un juego contrarreloj, la vidaque cae automáticamente no será tanta para tener sensación de urgencia, salvo si ya estamosen niveles bajos de vida. La barra de vida brillará cada vez que la vida baje automáticamentepara que seamos conscientes de esa pérdida. Además se podrá perder vida si somos atacadospor el enemigo o si caemos por un precipicio.

41

Se podrá recuperar vida con el item que dejará el veneno cuando acabemos con unahorda completa. Si la vida se acaba moriremos, y al tener una sola vida tendremos que volvera comenzar desde el inicio de la pantalla.

Según la región de vida en al que estemos las distorsiones e interrupciones seránmayores o menores, dificultando el juego. En el nivel 75-100 habrá alguna pequeña distorsióny alguna interrupción muy infrecuente ya que estamos bastante bien, será lo más parecido ajugar un juego normal. Sin embargo el nivel 0-25 tendrá todo tipo de distorsiones en susvalores más altos y las interrupciones serán frecuentes. Los niveles intermedios tendrán susniveles en valores medios respecto a los extremos.

En la primera versión del juego para la asignatura de Tecnología de juegos se cambió unpoco la forma de manejar la salud. No existía item de recuperar vida, pero la vida que caíaautomáticamente era proporcional al número de venenos de la pantalla, por lo que eliminarenemigos hacía que esa perdida constante fuera menor. El problema es que no era muyintuitivo, los jugadores no descubrían este funcionamiento del juego, por lo que preferícambiarlo por el item de recuperar vida, que es un mecanismo más directo.

3.6.6 Comportamiento del veneno

El enemigo común del juego, las gotas de veneno, normalmente estarán reunidos enpequeños grupos, atacando o infectando alguna parte del escenario. Al llegar el protagonista acierta distancia, dejarán sus quehaceres para atacar al personaje. Siempre comenzarán en elmodo tranquilo. Su método de ataque son embestidas hacia la posición del protagonista, yaque hieren por contacto. Las embestidas serán aleatorias en el tiempo, y la posición a la queregresará después de la embestida también.

Cuando ataquemos a una gota con éxito pasará a modo agresivo. En el modo agresivolas embestidas de las gotas serán más frecuentes, veloces y dañinas. Cada gota necesitará seratacada 2 veces para que desaparezca. Al acabar con una horda completa de gotas de veneno,aparecerá un item para que el jugador recupere vida.

Se verá según se ajusten finalmente los parámetros si es obligatorio acabar con todas lasgotas de veneno para poder terminar el nivel (algo lógico a priori ya que queremos limpiar elcuerpo de veneno), o con la disminución de vida automática será suficiente incentivo para quese traten de acabar con las hordas de veneno para conseguir ese item de vida, ya que sin ellono podremos llegar al final vivos.

El veneno ciego por su parte sigue una ruta pre-establecida y morirá al primer toque.Funcionan más como obstáculos que como enemigos, ya que no reaccionan ante el héroe.

3.6.7 Interacción con el mundo exterior

He planeado las siguientes interacciones con el mundo exterior, para la primera pantalla:

• Hoja: Esta interacción ocurre de forma automática. Al protagonista le cae una hoja enla cara. El resultado es que en su subconsciente lo verá todo verde. Al poco le quitaránla hoja de la cara y volverá a ver normal. Pero el tiempo entre el mundo real y elsubconsciente no tiene por que ser el mismo.

• Sacudida: En un momento del juego el protagonista encontrará el camino bloqueado

42

por algún objeto (por ahora piedras, pero estaría bien pensar algo más fantástico), y alpresionar el botón de mundo exterior nos zarandearán. Esto provocará que en elsubconsciente todo acabe por los aires, incluyendo los obstáculos y podremos continuarel viaje.

• Agua: En el avance del protagonista verá un barranco que le separa del camino aseguir. En el fondo del barrando habrá unas piedras. Pulsando el botón de mundoexterno, el protagonista pedirá agua, y le darán un poco de agua a beber. Esto llenaráese barranco de agua, haciendo que las piedras (o algo parecido) floten y podamospasar saltando de una a otra.

3.6.8 Estética

Con todas las mecánicas, la trama argumental y la ambientación busco que el jugadortenga las siguientes sensaciones jugando:

El estar avanzando por un mundo fantasioso, inestable, irreal el jugador tiene que tenercierta sensación de agobio, debido a la perdida continua de salud y a la dificultad de jugar condistorsiones activadas, interrupciones que pueden llegar a asustar...

También busco la sorpresa del jugador al ir descubriendo cada zona de cada pantalla, yque no solo desee avanzar por el reto de hacerlo, sino por descubrir qué más mundos le puedeofrecer el juego.

En la segunda pantalla la estética del juego cambia al añadir una parte de puzzle con lamecánica de la gravedad, por lo que el jugador tendrá entonces un juego con menos descu-brimiento y velocidad de avance, pero con más necesidad de pensar cómo avanzar, menosinmediato.

43

44

Capítulo 4: Estado del arte

4.1 Concepto

No he encontrado ningún juego que tenga el concepto base del juego, una personarecorriendo su propio subconsciente. Aunque si hay juegos con conceptos relativamenteparecidos.

• The Dream Machine (PC): En este juego, una máquina descontrolada se alimenta delos sueños de los vecinos de un edificio y debemos ir entrando a los sueños de cadavecino para desconectar la máquina de ese sueño y rescatar así la consciencia de lapersona. No es exactamente recorrer el subconsciente, pero es similar recorrer sueñosde personas, y tiene un gran trabajo de ambientación, con un estilo común (hecho configuras de arcilla), pero con personalidad propia en cada sueño. [30]

45

Imagen 23: The Dream Machine

• Secret of Evermore (Super Nintendo): En este juego, un joven (sin nombre) entrapor error en un edificio abandonado siguiendo a su perro y acaba siendo trasladado auna realidad virtual (Evermore) construida sobre las fantasías de los miembros de unexperimento 30 años atrás. Es decir el mundo virtual es una reconstrucción adaptadade los momentos históricos favoritos de una serie de personajes, desde la prehistoria aEgipto o la edad media. La historia principal abstracta es la misma, un joven querecorre un mundo virtual que refleja deseos de personas teniendo como meta poderregresar a la realidad. [50]

• Alice: Madness Returns (PC, Playstation 3 y Xbox 360): Este juego y supredecesor dan un nuevo giro a las historias de los libros de Lewis Caroll. En este juegoAlicia, que ha tenido problemas mentales por una gran tragedia personal debe avanzaren un mundo teñido por sus alucinaciones y superar la depresión por culpabilidad queacarrea intentando discernir lo que es real y lo que no. [49]

• Papo y yo (Playstation 3, PC): Es un juego de plataformas en el que un niñomaltratado por su padre alcohólico se evade en un mundo de fantasía basado enfavelas. La realidad tiene su reflejo en este mundo donde su padre es un monstruo y sualcoholismo se transforma en una adicción a ranas que le vuelven violento. [35] [75]

4.2 Ambientación

En cuanto a mundos 3D y ambientación alucinógena u onírica he encontrado de finalesde los 90 dos juegos.

• LSD (PSX): FPS cuyo título deja clara la temática. Aunque a lo mejor le sobra la S deFPS. Ya que no he visto que se dispare, bueno ni se haga nada. La ambientación tieneciertas partes curiosas y poco vistas en juegos. Pero después de ver varios gameplaysno se de que va el juego, que hay que hacer ni nada. Aparentemente no se cogenobjetos, hacen cosas, matan ni revuelven puzzles, solo se anda por mundos extraños.[43] [55]

46

Imagen 24: Secret of Evermore

• Dreams to reality (PC, PSX): Juego de plataformas en tercera persona. Viajamos porel país de los sueños volando de un escenario a otro y recorriendo por dentro algunosedificios, donde además puede haber enemigos y luchamos contra ellos. La cámara eneste juego sigue a la espalda del personaje en todo momento, aunque no se si se puedemover libremente. Tiene un agujero de gusano al principio del juego para llegar almundo de los sueños. El control es muy duro y una vez dentro de un edificio no pareceque estemos en un lugar onírico. Pero parte de la idea de un juego de plataformas 3Den un mundo de sueños y el agujero de gusano son similares a lo que quiero hacer.[31]

4.3 Jugabilidad

En la jugabilidad toma elementos de los siguientes juegos:

• Crash Bandicoot 3 (PSX): De este juego me interesa sobre todo la cámara, que sigueal personaje, pero sin girar en torno a él cuando el personaje gira. Una cámara sobreraíles, pero que funciona muy bien, y nunca nos tapa ni hace cosas raras. Además lamayor parte del movimiento básico del personaje me sirve, aunque en el Crash es máscomplicado. Hay movimiento en todas direcciones, salto y ataque. Pero además nospodemos deslizar, hacer doble salto y plancha en el aire. El ataque es un torbellino y noes dirigido. Toda la estética y animación son tipo dibujos animados. Me gustaríaconseguir el movimiento de cámara y la diversión que tiene su diseño de niveles, perocon otra ambientación. [38] [59]

• Medievil (PSX): El control del personaje en este caso me parece casi igual. Se puedemover libremente en todas direcciones, saltar y atacar. Y el ataque con el arma básicoes una estocada hacia delante, heredado del Ghosts'n Goblins, del que intenta ser unsucesor en 3D en buena medida. No me gusta la cámara, que se mueve libremente y aveces es difícil de gobernar dando problemas de jugabilidad. Además que manejar lacámara en una pantalla táctil es especialmente difícil. La ambientación tipo terrortambién puede tener un aire a lo que busco hacer. [48] [68]

47

Imagen 25: LSD

4.4 Mecánicas

Respecto al uso del cambio de gravedad en la jugabilidad:

• Shutterhand (NES): Este juego es un plataformas / beat'em up en 2D y en una de laspantallas, hay techos especiales que te atraen por lo que vas cambiando de andar porel suelo a andar por el techo, pero no eliges cuando, es automático según la pantalla,pero si aporta algo a la jugabilidad. [36] [56]

• Yo Ninja (Android, IOS): Es un juego de scroll lateral en el que un ninja corre solo yal pulsar la pantalla del móvil cambia la gravedad y se dirige hacia el techo o el suelo.El juego llega a ser frenético al no parar nunca de correr y haber aceleraciones, aunquecon lo limitado de tener una única acción que realizar se vuelve repetitivo por muchoque jueguen con cómo poner los obstáculos en los distintos niveles. [42] [67]

• VVVVVV (Multiplataforma): Juego 2D de plataformas con estética spectrum, es unjuego de plataformas en el que podemos movernos hacia los lados, no podemos saltar,pero si cambiar la gravedad, hacia arriba o hacia abajo, pulsando un solo botón. Estounido a otras mecánicas de diseño de escenario, nunca posibilidades del jugador hacenque el juego sea muy divertido de jugar, es un buen ejemplo de como explotar bien unamecánica sencilla y original. [29] [57]

• Gravity Rush (PS Vita): Este juego de tipo beat'em up en 3D usa algunos poderescomo poder flotar o lo que llama gravity kick, que es una patada en la queaprovechamos el impulso de una gravedad extra para golpear más fuerte. El uso delcambio de gravedad en el juego es limitado y para acciones muy concretas, así que nome sirve para mi juego. [46] [62]

También hay un juego que quiero destacar por la forma en que trabaja la dualidad deestar dentro y fuera de un ser y jugar en ambos sitios:

48

Imagen 26: Shutterhand

• Mario y Luigi: Viaje al centro de Bowser (Nintendo DS): En este juego Bowserabsorbe a Mario y Luigi que deberán recorrer las entrañas de Bowser, mientras esterecorre su propia aventura en el mundo exterior contra un mal mayor. En la pantallasuperior manejamos a Bowser y en la inferior a Mario y Luigi, y la gran mayoría depuzzles del juego tiene que ver la interacción exterior-interior, por ejemplo, que Bowserhaga algo como tomar agua, absorber hielo, echar fuego o moverse para cambiar elecosistema interno y que Mario y Luigi puedan avanzar, o viceversa que Mario y Luigihagan algo dentro de Bowser que le de ventaja fuera. Me gustaría utilizar algo de estetipo de jugabilidad. Aunque en un juego tan pequeño y donde ya tengo otras mecánicasno voy a poder explotarlo ni de cerca tan bien como lo hace la gente de Nintendo. [28][54]

Por último el uso de alucinaciones o cualquier otro tipo de distorsión como elementojugable o narrativo:

• Max Payne 2 (Multiplataforma): Alucinaciones al salir de un hospital. Se usa elefecto de ghosting ya visto en Metal Gear Solid y Twirl con un ángulo bajo pero que vacambiando. [44] [61]

• Batman's Arkham Asylum (Multiplataforma): Parte de alucinaciones jugables porefecto del espantapájaros. El mundo alrededor se comporta raro, los modelos cambian,hay iluminación en blanco a modo de flash. Se oyen voces, y hay cierto efecto deghosting. Buena parte de esta fase consiste en huir de un monstruo gigante. Aquí másque por efectos de imagen, las alucinaciones están modeladas en la naturaleza de lafase. Aunque en el inicio se ve más blur, vortex y cámara con giro en la z. [45] [58]

• Far Cry 3 (Multiplataforma): El protagonista drogado, anda por la jungla. El efecto

49

Imagen 27: Mario & Luigi: Viaje al centro de Bowser

es ghosting, blur, cambio de color, y objetos que se mueven (y normalmente no loharían). Además hacia el final hay un efecto que me gusta bastante de una casa que semueve huyendo del jugador. [53] [63]

• Among the sleep: Este juego es de tipo Survival horror, con la particularidad de queencarnamos a un niño de 2 años. Este cambio hace el juego interesante, ya quemuchas veces no sabremos si estamos viendo algo irreal, o es la forma de verlo delniño. Por ejemplo, podemos ver el mundo distorsionado, pero es porque lo vemos através de un vaso, ya que estamos bebiendo. En el juego se sucede un viajesobrenatural en el que tendremos que huir de monstruos. Durante el juego podemosver varios efectos muy interesantes, como vibraciones fuertes de la pantalla que vemosen momentos clave de las partes más irreales pero también cuando vemos a la madrediscutir, lo que nos podría hacer pensar que todo el viaje del niño es el realidad la formaque tiene de lidiar con los problemas del mundo real. [32]

50

Capítulo 5: Herramientas de desarrollo

5.1 Equipo y herramientas empleadas

5.1.1 Entorno de trabajo

El entorno de trabajo en que se ha desarrollado el proyecto consiste en un portátilLenovo ideapad Y580, que cuenta con procesador Intel Core i5-3210M a 2.5 GHz, 8 GB dememoria RAM DDR3, y procesador gráfico NVIDIA Geforce GTX 660M, con 2 GB de memoriaDDR5. El equipo tiene instalado Windows 8.1.

Para las pruebas además del ordenador descrito se han utilizado también dos portátilesde gama más baja, con tarjetas gráficas integradas Intel y AMD de gama baja, paracomprobar el rendimiento del juego.

5.1.2 Gestión del proyecto

Los diagramas de Gantt, más informales en esta ocasión se han realizado con la aplica-ción LibreOffice Impress, un programa de realización de presentaciones. Es un programa Librellevado por la Document Foundation [77], siendo una escisión de OpenOffice.

Dropbox

Es el servicio más conocido de almacenamiento de archivos “en la nube”. Nos permitetener una carpeta cuyos contenidos se subirán automáticamente a los servidores de Dropbox,y se bajará automáticamente a los ordenadores que compartan contenido. Así podemos tenersincronizados archivos entre dispositivos, y también compartir algunas subcarpetas con otrosusuarios. [78]

Se utilizará este servicio, para mantener una copia consistente del estado del proyecto ysus archivos entre los distintos ordenadores de trabajo y prueba. Al ser un proyecto realizadopor una sola persona no hay conflictos a la hora de actualizar los ficheros, por lo que no hasido necesario utilizar herramientas más avanzadas como subversion. Si bien, dropbox no esuna herramienta de control de configuraciones, ni tan siquiera de control de versiones. Tieneun sistema con el que podemos ver versiones anteriores de un archivo o recuperar archivos

51

borrados, pero no se mantienen según versiones, con notas del cambio de versión y ladocumentación asociada. Aún así se ha preferido utilizar respecto a las alternativas de controlde versiones, por la simplicidad del producto, porque se encontraba ya instalado en todos losequipos de trabajo y porque los sitios web gratuitos para alojar proyectos utilizando estasherramientas de control de versiones, obligan a utilizar ciertas licencias y no se quiere dar esetipo de licencias al proyecto.

Unity3D da ciertos problemas si mantenemos un proyecto completo en una carpetagestionada por dropbox, por ello, la copia de trabajo no está en dropbox, aunque otroselementos del proyecto sí, se han hecho copias de seguridad manuales de la parte en la que nose podía trabajar directamente en dropbox.

5.1.3 Redacción de la documentación

Dispongo de experiencia en Latex, ya que los proyectos final de carrera de la Ingenieríatécnica y de la Ingeniería en Informática los realicé con este lenguaje de preparación de docu-mentos, escribiendo el código sin utilizar editores externos. Soy un gran defensor de Latex ysus bondades, sin embargo esto es para trabajar en Linux, ya que no lo encuentro tan cómodode usar en Windows y los editores WYSIWYG disponibles no son de mi agrado. Teniendo encuenta que varias herramientas a utilizar en el proyecto no están disponibles en Linux, decidíno utilizar Latex y usar esta vez una herramienta más tradicional.

Por ello la documentación ha sido redactada usando LibreOffice Writer, el procesador detextos de la suite LibreOffice, un proyecto escindido de OpenOffice y que supone una suiteofimática libre, multiplataforma y compatible con la mayor parte de formatos generalistas. Heaprendido el uso de herramientas como las referencias cruzadas que ofrece la herramientapara intentar alcanzar una calidad en la memoria lo más cercana posible a si hubiera estadoredactada y maquetada en Latex. [77]

5.1.4 Herramientas de modelado de diagramas

StarUml

Para modelar la aplicación he elegido la herramienta StarUML dada la familiaridad con lamisma tras haberla utilizado en las cuatro asignaturas de ingeniería del software y en losproyecto final de carrera de las ingeniería técnica y superior, por lo que es la herramienta en laque tengo mayor experiencia. A su favor se encuentra que es una herramienta de softwarelibre, aunque solo disponible en Windows, y que pese a ser simple da funcionalidad a todos losaspectos se necesitan.

Dia

Editor de diagramas libre, basado en GTK+ y disponible para Linux, Windows y Mac. Creatodo tipo de diagramas, aunque hay programas más sencillos de usar y con resultados másaparentes, se utilizará cuando no haya otro programa específico que cubra el tipo de diagramaque se desee realizar.

52

5.1.5 Herramientas de modelado 3d

3ds Max

Es una de las herramientas por antonomasia del modelado en 3D y la animación. Elsoftware es propietario, pero la URJC facilita el acceso a licencias académicas a los estudiantes.Es un software de Autodesk, al igual que Maya, y hemos usado ambos en el máster, aunque enMaya fueron unas prácticas de iluminación. La parte de modelado, rigging y animación lahemos aprendido en 3ds Max y por esa razón ha sido el programa elegido para estas tareas.Se trabaja con la versión de 2011.

Estas son las tareas para las que se va a utilizar el programa:

• Modelado: tanto de personajes, como de items y escenarios. Se utilizarán las posibili-dades de modelado en base a formas básicas, polígono a polígono, extruyendo yusando splines.

• Mapeado UV: para la mayoría de modelos, haré este paso en la misma herramienta.Usando las herramientas de mapeado por formas y/o desenrollado UVW sobre textura.

• Rigging: posee esqueletos funcionales ya hechos, pero en algunos casos los personajesa desarrollar no encajarán en esos esqueletos y se necesitará crear una base de huesosdesde cero.

• Skinning: tanto si vamos a usar esqueletos CAD por defecto como si hemos hechonuestro propio esqueleto, necesitamos asociarlo a la malla, para que el esqueletomueva el modelo poligonal.

• Weighting: muy unido al anterior, consiste en ajustar el peso de la influencia de cadahueso en cada vértice de la malla. Hay herramientas en este software para hacerlo mássencillo, pero en las ocasiones más peliagudas hay que elegir vértice a vértice lainfluencia de cada hueso.

• Animación: aunque se usan librerías para algunas de las animaciones, algunasnecesitan retoques y otras no se encuentran por lo que hay que animar desde cerousando el programa. El programa puede realizar una animación desde una serie deframes clave, interpolando los intermedios y también puede rellenar todas lasposiciones intermedias para dar una animación completa al motor del juego.

Zbrush

La herramienta de Pixologic da otra visión del modelado, permitiendo esculpir. Permiterealizar detalles en los modelos de alto detalle, pasando a modelos de detalles más bajo ytransmitiendo los detalles creados a mapas de normales. También es bastante útil a la hora demodificar modelos. No se tienen conocimientos previos de este software, por lo que parte delinterés de usarlo es el aprendizaje del mismo por su extendido uso en la industria de losvideojuegos. Se ha utilizado la versión 4R6.

53

Roadkill

Este programa es mucho más humilde que las suites anteriores, ha sido creado por unasola persona, Andy Swann, y es un programa para una tarea muy específica, el mapeado UV.[79]

En los casos en que el mapeado ha sido muy complejo por tratarse de modelos con ungran número de polígonos y se han tenido dificultades con 3ds max, se ha preferido utilizarRoadkill, ya que es más sencillo de usar, y al ser más específico es más fácil ver lasherramientas disponibles para este problema en concreto, ya que en los ides monstruosos aveces se pierde la perspectiva. Se ha utilizado la versión 1.1.

5.1.6 Edición de imagen

Photoshop

El programa de Adobe es el estándar de facto de la industria de los videojuegos, ademásde serlo también en muchos otros campos. En el máster lo hemos utilizado para las prácticasde texturas y también hemos tenido seminarios para aprender a usarlo.

Lo utilizo para crear texturas, retocarlas, crear logotipos, rótulos, y en general cubrirtodas las necesidades de crear o retocar imágenes en dos dimensiones. Se ha utilizado laversión CS6.

The Gimp

Considerado como la versión libre de Photoshop, es mucho más humilde en comparación,pero dispone de una gran versatilidad gracias a la posibilidad de crear efectos mediante scriptsen Pyton. Esto hace que haya librerías de efectos de imagen disponibles, creados por lacomunidad que hacen muy sencillo dar efectos artísticos a las imágenes o crear logotipos yrótulos bastante aparentes usando un solo comando.

Por ello se usa junto a Photoshop, para crear algunas de las texturas que se usan en eljuego. Se utiliza la versión 2.8.14.

5.1.7 Edición de sonido

Audacity

Es la alternativa libre a los editores de sonido comerciales. En él podemos recortar,mezclar y aplicar efectos, como reducción de ruido, cambio de tono o desvanecimientos devolumen. Se utiliza la versión 2.0.5. A pesar de que el programa sufre de bugs y puedecerrarse perdiendo el avance, es fácil de usar, trabaja con mp3, el formato más usado y setiene experiencia con él.

54

5.1.8 Captura y edición de vídeo

Los vídeos de promoción del juego, los del blog de desarrollo del juego y los videos pre-renderizados que se muestran durante el juego necesitan ser capturados y editados, para ellose han utilizado diversos programas y aparatos.

ActivePresenter

Este programa está pensado para realizar presentaciones en forma de vídeo o diapo-sitivas, pero entre las herramientas que trae está una capturadora de vídeo bastante potente,donde podemos elegir destacar el puntero del ratón, ocultarlo, la fuente de audio, el programao área de pantalla a capturar y da la posibilidad de guardar el vídeo en bruto, sin procesar porningún codec, lo que hace que tenga más calidad y podamos elegir un formato más ligerodespués de haber editado el vídeo. Se utilizó la versión 3.9.

Hypercam 2

Este software tiene como única funcionalidad la captura de vídeo. Permite bastantes posi-bilidades, como activar la grabación mediante una tecla, compresión de vídeo mediante varioscodecs diferentes, grabar sonido o puntero de ratón... La calidad del vídeo depende del codec,y en algunos casos se producen desfases entre imagen y sonido en el vídeo. Pero es el mássencillo de usar y para muchas capturas sencillas se ha utilizado satisfactoriamente. La versiónusada es la 2.28 de la rama de 64 bits.

Avermedia Game Capture HD II

En la segunda parte del proyecto se ha dispuesto de esta capturadora externa. Permitealmacenar vídeo de alta calidad, 1080p a 30 fps o 720p a 60 fps, grabando directamente a undisco duro externo usb, tomando como entrada una señal hdmi. Los vídeos capturados tienenuna velocidad de bits de unos 16.000 kbps, con sonido estéreo a 128 kbps.

La capturadora permite la grabación de vídeos en alta calidad y además no exige rendi-miento extra al ordenador que está ejecutando el juego, ya que la captura y la codificación del

55

Imagen 28: Capturadora externa

vídeo se realiza en la capturadora externa, gracias a esto se pueden conseguir vídeos degameplay a altas tasas de refresco.

Windows movie maker

Este programa de edición de vídeo está disponible de forma gratuita para los usuarios deWindows, y en muchos casos está instalado por defecto, y es bastante fácil de usar, siendoideal para hacer montajes sencillos. A veces es algo restrictivo, incluso dando menos opcionesen versiones actuales que en otras anteriores. Sin embargo ofrece muchas opciones pararenderizar los vídeos en diferentes formatos y calidades y es ideal para el montaje rápido devídeos, sobre todo para neófitos en la edición de vídeo. Se ha utilizado la versión de 2012.

Sony Vegas

El programa de edición de vídeo de Sony es uno de los más utilizados, entre los editoresligeros, no tiene todas las posibilidades que ofrece Premiere, pero es más que suficiente parala mayor parte de ediciones de vídeo no profesionales, incluso para algunas dentro del mundoprofesional.

Permite la edición de vídeo, recortar, poner efectos de vídeo y audio, transiciones y tieneuna enorme amplitud de formatos para renderizar el vídeo final. Además alguno de los modosde renderizado cuentan con aceleración por gpu usando CUDA u OpenCL.

Se contaba con experiencia con este software, por lo que su uso no supone un reto parael alumno. La versión utilizada es la 13.

5.2 Motor del juego y entorno de desarrollo

En este caso ambas cosas corren a cargo de Unity3D, una solución completa que facilitaun motor de juego y un entorno de desarrollo integrado (ide). Este entorno es el que se nosenseña a usar en el máster y la práctica de Animación por computador (AC) es obligatoria-mente en este entorno. La práctica de Tecnología de juegos, primera parte de este proyecto,se podía hacer con cualquier motor, pero decidí hacerlo en Unity3D, por la experiencia previa,porque todos los demás compañeros también lo hicieron en Unity3D y así podíamosconsultarnos cosas los unos a los otros, y porque pretendía compartir el personaje principal dela práctica de AC con el del presente juego.

Unity 3D es un motor complejo, multiplataforma, multisistema, con varias libreríasgráficas y muchos sistemas internos. Al trabajar con él podemos elegir que la aplicación finalsea para ordenador, móvil, tablet, consolas... y si queremos que sea para Windows, Linux,Mac, Android, IOs... o una combinación de ellos, incluso podríamos tener una aplicación web oflash. También podemos elegir, a veces forzados por la elección anterior, si la aplicación va autilizar OpenGL, DirectX 9, DirectX 11...

Además al tener una versión gratuita bastante competente y de uso extendido, es uno delos entornos de desarrollo de videojuegos con más comunidad, por lo que existen numerosostutoriales, vídeos explicativos, foros resolviendo dudas, wikis y herramientas gratuitas o depago de terceros que pueden hacer más sencillo un desarrollo.

Como entorno ofrece, entre otras, las siguientes herramientas, que son las más impor-tantes para el proyecto:

56

• Importación de assets FBX: Permite incorporar mallas, con rig y animaciones en elformato nativo de Autodesk, por lo que nos permite utilizar todo lo que generamos con3DS max.

• Creación de primitivas 3D: Puede crear sus propios modelos, aunque siempreprimitivos: cubos, esferas, capsulas, planos...

• Motor de colisiones: Permite configurar la comprobación de colisiones entre objetos ypodemos programar eventos ante las colisiones.

• Motor de física: Dispone de su propio motor de física que nos permite de formasencilla tener gravedad, inercia en los objetos, momento angular y en general unadinámica realista.

• Editor de terrenos: Tiene su propio editor de terrenos donde crear desde el entornosuelo exterior y poblarlo de vegetación.

• Iluminación pre calculada: Permite calcular mapas de iluminación para entornosestáticos, lo que da un mayor realismo en los escenarios.

• Sondas de iluminación: Permite situar sondas (probes) por el escenario para dar unailuminación a los objetos dinámicos interpolada según la iluminación estática precalculada.

• Sistemas de partículas: Permite crear sistemas de partículas complejos, incluyendocálculo de colisiones de las partículas a nivel global o su ordenación hacia la cámara.

• Animación: Permite realizar animaciones desde el propio editor, si bien está pensadopara animaciones externas, tales como objetos que se mueven, no para lasanimaciones internas de personajes.

• Sistemas de control de animaciones: Se pueden controlar las animaciones internasde los personajes mediante un sistema en código y ante un nuevo sistema visual,Mecanim, mucho más avanzado, con mezcla de animaciones y transiciones máscomplejas.

• Control de sonido: Permite la incorporación de emisores de sonido y de receptores, yla configuración de los mismos y del sistema para lograr un efecto de inmersión en eljuego al escuchar cada sonido según la distancia y posición del emisor respecto alpersonaje.

• Ragdoll: Se pueden crear muñecos de trapo y activarlos a tiempo, esto hace que lareacción de los personajes ante un golpe o a la hora de morir sea más realista, ya quecaen como un peso muerto y cada vez es diferente ya que no se usa una animaciónpredefinida.

• Texturas complejas: Entre las texturas que se pueden utilizar están las Texturas 3D,texturas procedurales o video texturas.

• UI: Permite crear interfaces de usuario para mostrar menús, barras de vida o energía,marcadores de puntuación, armas, balas...

• Navegación: Dispone de un sistema para crear mallas de navegación, esto permite alos personajes conocer los caminos disponibles para llegar a otra posición.

• Scripts: Permite la creación de código de juego en scripts en varios lenguajes, siendolos principales c# y javascript.

• Shaders: tiene su propia forma de realizar shaders e integrarlos con el renderizado delmotor. Se pueden escribir en HLSL y GLSL. La aplicación es capaz de generar losshaders GLSL de forma automática desde los de GLSL.

• Efectos de imagen: Se pueden controlar efectos de post-proceso, desde niebla aefectos sobre la imagen completa como antialiasing o tonemapping.

57

Algunos de las características mostradas son exclusivas de la versión de pago en Unity 4,pero eran necesarias para el proyecto como los efectos de imagen o las video texturas.

Unity 5

Durante la Games Developer Conference de 2015 [81], el equipo de Unity anunció ellanzamiento de la nueva versión de Unity de forma inmediata. La nueva versión destaca por elcambio en el modelo de negocio, la versión gratuita trae todos los elementos que tenía laversión de pago anteriormente, y la versión de pago nos da acceso a procesamiento en la nubede la iluminación de la escena. [82]

Entre las novedades de esta versión están:

• Materiales físicamente plausibles: Nuevos materiales más cercanos a los productosfísicamente correctos. Permite materiales consistentes independientemente de lailuminación.

• Sondas de iluminación en HDR: Las sondas de iluminación (probes), pueden fun-cionar ahora en HDR (alto rango dinámico), además de integrar nuevos tipos de sondaspara los reflejos metálicos.

• Iluminación global en tiempo real: El nuevo motor de iluminación tiene términosglobales, rebotes de la luz, que se pueden precalcular, pero también tiene partes quefuncionan en tiempo real. No es una iluminación global total, pero van introduciendopartes. El nuevo motor se basa en la tecnología de Geometrics Enlighten.

• Mezclador de sonido: Nueva interfaz con la que podemos crear canales de audio deforma jerárquica, poner efectos en tiempo real, y hacer streaming de audio entrecanales para evitar repetir un efecto costoso en varios canales. También se puedenguardar configuraciones del mezclador e interpolar entre ellas.

58

Imagen 29: Comparación de iluminación global en tiempo real desactivada (izquierda) y activa (derecha)

• Mecanim: Mejoras substanciales en mecanim, el sistema de configuración de anima-ciones. Además los proyectos de ejemplo de Unity 5 utilizan mecanim y facilitan assetsque hacen más sencillo el salto a la nueva herramienta.

• Cambios en el motor físico: Mejora del rendimiento del motor físico e integración dePhysX 3.3.

• Nueva UI: Sistema de creación de usuario mucho más avanzado que permite crear lasinterfaces de forma similar a como funciona el css en las páginas web.

Se tomó la decisión de hacer la migración del proyecto a Unity 5 a pesar de lanzarse lanueva versión apenas 4 meses antes del plazo de entrega del proyecto. Uno de los aspectosque inclinaron la balanza fue que las características de pago en Unity 4 que se necesitabanpara el proyecto como los efectos de imagen, en versión 5 están disponibles en la versióngratuita. Además los nuevos sistemas de iluminación, mezcla de sonido y las mejoras en el deanimación iban a mejorar sustancialmente la calidad final del producto.

5.3 Assets y librerías

En la elaboración del proyecto he usado bastantes librerías y assets proporcionados porterceros y que han hecho el desarrollo del proyecto mucho más sencillo.

TubeRenderer

Utilicé esta librería para crear tubos en tiempo de ejecución desde código y es la basepara los efectos de túnel que se realizan para el viaje entre el mundo real y el subconscientedel personaje. [80]

Permite crear tubos, con o sin base, cambiando la forma del tubo, el número de trozosque lo forman, el radio y posición de cada uno. También incluye una serie de ejemplosbastante buenos e inspiradores.

59

Imagen 30: Mezclador de sonido de Unity 5

Itween

Librería que permite animar, mediante interpolación de valores, casi cualquier cosa enUnity. Entre otras cosas: animar el movimiento de objetos, color, velocidad de reproducción desonido, tamaño, rotaciones, vibración de objetos o hacer que un objeto encare una dirección.Incluso podemos hacer que interpole valores de cualquier característica de cualquier objeto deUnity, aunque no esté entre las funciones iniciales de iTween.

También tiene otras posibilidades como hacer rutas (implementadas como splines) ytransformar posiciones del las coordenadas del spline al mundo real, recorrer la misma...

iTween Multipath

Esta extensión a la librería anterior permite encadenar rutas de forma automática. Hacemuy sencillo crear recorridos de cámara o rutas predefinidas para los personajes. Lo utilizopara los recorridos del veneno ciego, que recorren una serie de rutas encadenadas en forma debucle.

MK Glow System

Creado por Michael Kremmel, es un sistema de materiales, con un script de post procesode imagen que hace que esos materiales tengan un efecto de brillo alrededor bastanteaparente. Lo utilizo para dar más brillo a la estela de la espada o al item de recuperar vidaentre otros.

X-WeaponTrail

Este asset permite la creación de una estela para el recorrido del arma, perfecto paraespadas como la que usa el protagonista. Permite dando los puntos extremos del arma lacreación de la estela y diferentes materiales y efectos. Tiene algunos problemas, como lacreación de la estela solo en una cara, que debo solventar.

Lava Flowing Shader

Este shader da la impresión de lava fluyendo, gracias a unos materiales en conjuncióncon shaders que hacen que las coordenadas UV del material cambien con el tiempo.Cambiando un poco las texturas y añadiendo otros efectos lo voy a usar para dar un aspectoúnico al item de recuperar vida. También lo utilizo para dar un aspecto especial a algunaspartes del escenario.

60

KTK Effect

Uso un paquete de prueba en el que dejan 6 efectos de partícula de forma gratuita. Usoalgunos de ellos, modificados para el efecto de respawn, cuando el jugador cae por unprecipicio y vuelve a aparecer en un punto de retorno.

KY Magic Effects

Paquete con 10 efectos de partículas, utilizo algunos de ellos, modificados y combinadospara el giro de gravedad del personaje.

Korea native trees

Colección de árboles Koreanos, un total de siete árboles, usando el nuevo sistemaintegrado SpeedTrees, que permite definir un árbol por ramas y hojas. Las texturas son fácilesde modificar para cambiar el color a los árboles y que puedan tener un aspecto más original.

Vine Bush Package

Colección de parras, vides y arbustos, con poligonización relativamente baja, alrededorde unos 1000 polígonos cada uno. Todos los arbustos usan las mismas texturas, por lo que esmás complicado hacer cada arbusto de un color.

Yughues Free Metal Materials

Buen pack de materiales, aunque son para la versión 4 de Unity se transforman bien enmateriales de la versión 5, y las texturas están bastante bien lo que permite crear diferentesmateriales metálicos y de cristal de forma sencilla. Contiene 42 materiales por defecto.

Yughues Free Sand Materials

De los mismos desarrolladores del pack anterior, una compilación de materiales de tipoarena, aunque bien usados puede dar para distintos tipos de terreno. Son 9 materiales deUnity 4 que se transforman fácilmente en materiales de Unity 5.

Yughues Free Pavement Materials

Otro pack del mismo equipo que los anteriores, en este caso son 20 materiales depavimento urbano y rústico, una vez más son materiales de Unity 4 transformables.

Yughues Free Concrete Materials

El último de los packs de Yughues da 20 materiales de tipo cemento, muy útil para suelosurbanos. Son materiales de Unity 4.

61

62

Capítulo 6: Análisis del sistema

6.1 Perspectiva del producto

La función principal del producto es la de ofrecer entretenimiento mediante un juego quetraslade por su ambientación al jugador a un viaje alternativo, y suponga un reto moderado desuperar. Para ello es primordial la facilidad de controles, pero que sean los niveles y la ambien-tación los que supongan el reto para el jugador.

6.2 Funciones del producto

Las función principal del producto es la de poder jugar, pero tiene algunas funciones secun-darias relacionadas.

• Configuración de opciones gráficas y de control.• Créditos del programa.• Función de pausa del juego, con posibilidad de abandono.

6.3 Características de los usuarios

Hay un solo rol de usuario en esta aplicación, el de jugador. Sin embargo si hay dife-rentes tipos de usuario según veamos su experiencia en el mundo de los videojuegos, y segúnel control que utilicen.

Una de las posibles clasificaciones más generales de videojugadores es [11]:

• Casual gamer: Los que juegan ocasionalmente, para distraerse, con ganas pero sininterés en ser los mejores, quizás sin ni siquiera acabar los juegos. Suelen jugar con elmóvil o tablet, y algunos de los juegos que eligen con más frecuencia son mini juegos opuzzles.

• Midcore gamers: Los que consideran que los videojuegos forman parte de sus intereses,

63

destinan tiempo y energía a ellos, pero tampoco hasta un nivel de desvivirse. Acostum-bran a tener videoconsolas, o utilizar un ordenador no especializado en esa función.

• Hardcore gamers: Los expertos, que dedican el tiempo que haga falta a descifrar loscódigos y superar máximas puntuaciones posibles. Pueden jugar en cualquierdispositivo y suelen tener más de uno.

Esta clasificación es útil pensando en los videojuegos como producto. No son cortescartesianos, puede haber jugadores de un tipo que jueguen con dispositivos y juegos de otrotipo. Las personas tenemos múltiples intereses, y los momentos de juego (el tiempo, la inten-sidad) pueden ser muy diferentes.

Este juego está pensado para midcore y hardcore gamers, y por ello se presuponenciertos conocimientos del lenguaje del videojuego. El juego, al ser un plataformas en 3D tienemucho mejor control con mando, pero un jugador acostumbrado podría jugarlo con teclado.Jugarlo con control táctil (móvil, tablet) es posible, aunque menos preciso, pero no hace eljuego casual, ya que no es el género ni tipo de juego para ese público.

6.4 Restricciones generales

Las restricciones generales del proyecto están dirigidas, esencialmente, a las limitacioneshardware, la interfaz con el usuario, consideraciones de seguridad y aspectos legales. Son lassiguientes:

• No se debe necesitar hardware de un fabricante en particular.

• Debe tener un rendimiento adecuado para poder funcionar en dispositivos móviles,aunque sean de alta gama.

• La aplicación debe utilizar tecnologías que no sean dependientes del sistema operativo.

• La interfaz de usuario será estándar dentro del mundo de los videojuegos.

6.5 Requisitos estructurales

6.5.1 Diagrama de clases

Se muestra a continuación el diagrama de clases de la parte creada para el proyecto dela lógica de juego. En la parte de diseño se concretará la relación de estas clases con lossistemas del motor del juego.

64

6.5.2 Descripción de clases

• ControlCentral: Clase central de la lógica del juego, lleva la ejecución de los eventosmás importantes del juego y algunas variables transversales. Además tiene un sistemapara ir actualizando la IA de los venenos.

• InputGeneric: Da la interfaz que deben tener cualquier clase que de control al juego,es el padre en un patrón adaptador.

• KeyboardInput: Interfaz para uso en ordenador. En realidad no solo para teclado, sinotambién para mando, gracias a la capa de control que proporciona Unity.

• PlayerInput: Estructura contenedor de la entrada del usuario para el frame actual.

• DataStorge: Clase persistente que mantiene algunas variables entre pantallas.

• ThirdPersonCharacter: Clase que lleva toda la lógica interna del control delpersonaje.

• CameraMovement: se encarga del movimiento y orientación de la cámara según laposición del jugador, lleva internamente toda la lógica de cámara sobre raíles.

• Track: Ruta, implementación de un spline como colección de puntos.

• Enemigo: Clase genérica que representa un enemigo para el jugador. Tiene lasfunciones en común para todo enemigo como la capacidad de herir y morir.

• Ciego: Un tipo de enemigo que se mueve siguiendo una ruta prefijada.

65

Figura 4: Diagrama de clases de análisis

• Veneno: Otro tipo de enemigo con IA que ataca mediante embestidas al jugador.

6.5.3 Restricciones OCL

Clase Track

Context Track inv:Track.allInstances -> forAll(p1,p2 | p1<>p2 implies p1.id <> p2.id)

Clase CameraMovement

Context CameraMovement inv:Self.tracks >= 1

Clase Ciego

Context Ciego inv:Self.tracks >= 1

Clase ControlCentral

Context ControlCentral inv:Self.dataStorage = 1

6.6 Requisitos de comportamiento

6.6.1 Requisitos funcionales

RF1: Se podrá iniciar partida nueva en el juego.

RF2: Se podrán cambiar los controles y las opciones gráficas.

RF3: Se permitirá moverse al personaje en cualquier dirección del plano.

RF4: El personaje podrá saltar.

RF5: El personaje podrá atacar con la espada.

RF6: El personaje podrá atacar mientras salta.

RF7: Se podrá pausar el juego.

RF8: Se podrá cambiar la gravedad en tres direcciones.

66

RF9: Se podrá recuperar vida recogiendo un item para ello.

RF10: Se podrá eliminar a los enemigos atacándolos.

6.6.2 Requisitos no funcionales

RFN1: Se dispondrá de una barra de vida en la parte izquierda de la pantalla paramostrar el estado de salud del personaje.

RNF2: El nivel intensidad en las distorsiones de imagen y mostrarán el estado de saluddel personaje también.

RNF3: El cambio de gravedad se hará mediante una animación que haga entender lanueva situación.

RNF4: Cualquier daño al personaje provocará que la cámara vibre para mostrar al juga-dor que hemos sido heridos.

RNF5: Cada vez que se eliminen a todos los enemigos de un grupo el último soltará unitem de recuperar vida.

RNF6: Se producirán interrupciones aleatorias con imágenes al azar.

6.7 Otros requisitos

6.7.1 Requisitos gráficos

Los requisitos de librerías gráficas los marcará la plataforma y el soporte que de Unity3D.Que en concreto son DirectX 11 para Windows y openGL para móviles, tablets, Linux y Mac,con diferentes versiones según sistema operativo y dispositivo.

67

68

Capítulo 7: Diseño del sistema

7.1 Introducción

El diseño del sistema es el proceso que modela el dominio de la solución a partir de ladescripción del dominio del problema, obtenida como resultado del análisis. El modelo dediseño es un refinamiento y formalización adicional del modelo de análisis, donde se tienen encuenta las características del entorno de implementación. Consiste en definir la arquitecturadel sistema, incluyendo su organización en subsistemas e interfaces, y el diseño detallado delas clases de diseño. [9]

Los objetivos fundamentales a la hora de llevar a cabo el diseño de la herramienta sonconseguir la mayor rapidez y facilidad de uso y potenciar los factores de calidad, entre los quedestacan:

• Reutilización: el diseño deberá soportar modificaciones del mismo para conseguirversiones mejoradas. El diseño debe cumplir el principio de abierto-cerrado.

• Usabilidad: se debe conseguir una aplicación que el usuario pueda utilizar de modofácil e intuitivo, sin necesidad de muchas instrucciones.

• Portabilidad: conseguir un diseño que pueda ser soportado por diferentes plataformasy controles.

• Eficiencia: la aplicación debe funcionar sin usar un amplio consumo de recursos.

• Fiabilidad: el diseño tiene que poder manejar un gran número de posibles funciona-mientos incorrectos por parte del usuario.

La aplicación del diseño será de calidad si cumple lo siguiente:

• Posea un software tolerante a ampliaciones y posibles cambios.

• Posea robustez, es decir, que el sistema no falle ante condiciones anormales de lamáquina.

Además en este caso no estamos hablando de un producto exclusivamente ingenieril,sino de una expresión artística, por lo que hay que cuidar el diseño artístico: visual,

69

sonoro y lúdico y se tomarán las decisiones apropiadas de diseño en estos campostambién.

7.2 Pautas del Diseño de la Arquitectura

Esta sección describe la arquitectura lógica propuesta para el sistema. Partiendo de laarquitectura actual, o de una típica para la aplicación en desarrollo, se construye laarquitectura en la que estará basada la implementación posterior del sistema. Las principalesactividades de esta fase son el propio diseño de la arquitectura y el diseño de los subsistemas.En la primera se lleva a cabo la descomposición de la aplicación en subsistemas e interfaces yse estudia la topología del sistema y otros aspectos como el rendimiento, el tamaño o laseguridad. En la segunda, el objetivo principal es efectuar la realización de casos de uso-diseño, basándose en la información obtenida durante el análisis y adaptándola al entorno deimplementación. Para finalizar, también se ha incluido el diseño detallado de las clases dediseño, que consiste en la especificación de todas las clases que conforman el sistema deforma más minuciosa y orientada a la fase de construcción del sistema, indicando todos losatributos y operaciones de cada una de ellas y, también, sus principales características.

7.2.1 Arquitectura propuesta

La arquitectura básica es la de un sistema por capas en la que el motor de Unity3D sesustenta sobre las librerías gráficas, según dispositivo o sistema operativo, y la lógica de juegoconstruida por el desarrollador, además de los recursos (gráficos, sonidos...) componen eljuego completo.

Al plantear el diseño según el patrón de Capas, se consigue separar diferentes aspectosde la aplicación y facilitar la flexibilidad y el mantenimiento de la misma. También se consigueasí una mayor escalabilidad y reutilización. Se busca que los componentes de cada capa seanlo más cohesivos posibles y estén en un mismo nivel de abstracción y también que cada capaesté poco acoplada con las anteriores.

De esta forma, las capas principales en que se estructura el juego son:

70

Figura 5: Arquitectura básica

• Librerías gráficas: En esta capa se agrupan las librerías sobre las que se ejecuta eljuego en el dispositivo final.

• Motor de Unity: En esta capa se agrupan todos los componentes del motor del juegoproporcionado por Unity3D.

• Assets: Todos los medios y scripts creados para funcionar sobre el motor y quesuponen el contenido del juego. Tanto los creados para el proyecto como los assets pordefecto de Unity3D o de terceros.

7.2.2 Descomposición en subsistemas

La descomposición en subsistemas es el resultado de la identificación de paquetes deanálisis, cuyo objetivo es organizar el modelo de análisis en piezas más pequeñas y mane-jables que formen un conjunto de paquetes cohesivos y poco acoplados, y de la posterioridentificación de subsistemas y sus interfaces, cuyo objetivo es minimizar el acoplamiento,mejorar la portabilidad del sistema y el aislamiento ante cambios y favorecer la evoluciónindependiente de cada subsistema, con interfaces bien definidas.

En el sistema en desarrollo se han identificado los siguientes subsistemas de aplicación

• Subsistema de lógica de juego.• Subsistema de cámara.• Subsistema de personaje.• Subsistema de enemigos.• Subsistema de escenario.

Posteriormente se definen las dependencias entre subsistemas y se identifican susinterfaces. Tras identificar todos los subsistemas de la arquitectura lógica del sistema se pasa adefinir sus dependencias para identificar las interfaces que les permitan comunicarse entre síde tal forma que se minimice el acoplamiento entre subsistemas.

Las dependencias se establecen entre aquellos subsistemas cuyos contenidos serelacionan entre sí. Las interfaces entre subsistemas definen operaciones que pueden serutilizadas por otros subsistemas sin necesidad de conocer cómo se realizarán dichas opera-ciones basándose en el principio de encapsulamiento.

71

Figura 6: Subsistemas

7.2.3 Topología del sistema

La aplicación es monousuario, monotarea, no es concurrente y si se tienen varias instan-cias de la aplicación corriendo de forma simultánea cada una funciona de forma independiente.El juego está pensado para ser ejecutado como una aplicación para el jugador actual en sumáquina, por lo tanto la topología es de un solo nodo. Se podría acceder a los recursos deforma remota, en otro nodo, incluso aplicaciones como Steam, permiten la ejecución remota,pudiendo ver los gráficos del juego y manejando desde un ordenador pero haciendo loscálculos en otro ordenador. Estas posibilidades no las voya a tener en cuenta en el presentedesarrollo.

7.3 Diseño de subsistemas

7.3.1 Diagramas de clase de diseño

Subsistema de Escenario

Este subsistema se enarga de los escenarios por los que discurre el juego, las colisionescontra ellos, las cubiertas para detectar caídas del escenario y los puntos de respawn en casode caída, además de la iluminación de la escena.

72

Figura 7: Subsistema de escenario

Subsistema de Cámara

Controla todo lo relacionado con la cámara del juego, su movimiento con un sistema deraíles basado en splines, los efectos que se añaden a la imagen una vez renderizada, el controlcentral de sonido y la interfaz de usuario.

73

Figura 8: Subsistema de cámara

Subsistema de Enemigos

Subsistema de los enemigos del juego, donde se controla su comportamiento, losdiferentes tipos de enemigo que hay, su organización en grupos, los power ups que sueltan, yotros funcionamientos internos de cada tipo de sistema como las sombras del veneno o lasrutas que sigue el ciego.

Subsistema de Personaje

Controla el comportamiento del personaje, es el subsistema que más cerca está deljugador, ya que es lo que controla directamente. Por eso la mayor parte del subsistema es unagran clase de control de personaje, lo más complejo del juego, con un animador con todas lasposibles animaciones y transiciones del hérore. También se maneja el paso a ragdoll al morir,los sonidos del personaje, los distintos efectos de partículas que se usan en diferentes circuns-tancias y la estela de la espada.

74

Figura 9: Subsistema de enemigos

Subsistema de Lógica de juego

Es el subsistema central del juego, aquí se controlan los eventos del juego, hay unrepositorio con acceso a las principales entidades del juego que facilita la comunicaciónefectiva entre subsistemas sin paso de mensajes. También contiene las clases donde serecogen los controles del usuario, con un patrón adaptador [10] para poder cambiar fácilmentede controles, como añadir los controles de gravedad, e implementar nuevos controles como losde pantalla táctil en el futuro.

También tiene la parte de persistencia para poder pasar datos de una pantalla a otra yeventualmente guardar la partida si el juego fuera lo suficientemente largo.

75

Figura 10: Subsistema de Personaje

7.4 Diseño de niveles

He intentado dar la importancia apropiada al diseño de niveles, aunque no tengo conoci-mientos apropiados y no es competencia del máster, he estado aprendiendo por mi cuentasobre el diseño de niveles, incluso he hecho niveles con herramientas para otros juegos comoPortal 2 , para ir aprendiendo. [5]

Por ello se van a especificar en la presente memoria los motivos de las elecciones deldiseño de niveles. Solo para la versión definitiva del juego y no para lo hecho en Tecnología dejuegos, ya que entonces no se tenía esto en cuenta ni se había estudiado sobre ello.

76

Figura 11: Subsistema de lógica de juego

Aprendizaje de la mecánica de salto

Esta parte está inspirada en la primera pantalla del Super Mario Bros [39]. Como sepuede ver en la imagen hay 3 tuberías seguidas, cada una más alta que la anterior. Laintención de este diseño es que el jugador aprenda que si deja el botón pulsado saltará másalto, sin tener que avisar explícitamente al jugador de este comportamiento. Así la primeratubería la saltará fácil, pero la segunda solo con pulsar no lo conseguirá e instintivamenteintentará apretar más el botón para saltar más, y con la última aprende cual es el máximo dealtura que puede saltar si deja el botón apretado el tiempo máximo. Esta misma formulatrasladada al 3d la he utilizado en la primer parte de la primera pantalla, con 3 listones quesuperar, cada uno más alto que el anterior.

77

Imagen 32: Nivel 1 de Temet Nosce

Imagen 31: Nivel 1-1 de Super Mario Bros

Aprendizaje de la mecánica de obtención de power up

Quiero dar la oportunidad al jugador para que diseñe su estrategia ante el juego, irdeprisa esquivando enemigos para que le quiten la menor vida posible, o eliminar grupos deenemigos para recuperar vida con el power up que dejan y así poder avanzar más lento yseguro. Pero para que elija estas opciones debe saber que las tiene y cuándo va a obtener unpower up.

En la primera parte de la pantalla los enemigos que hay son ciegos, que son mássencillos, siguen una ruta pre-determinada y no reaccionan ante el jugador, por lo que casi soncomo obstáculos. Mueren con un solo toque, por lo que son fáciles para ir tomando contacto dela distancia que hay que tener para que un ataque de espada impacte en el enemigo.

En esta parte el diseño de niveles consiste en estrechar el escenario donde está el primerenemigo, así casi obligamos al jugador a pelear contra ese enemigo. Consiste en un grupo deun solo rival, por lo que si el jugador lo elimina obtendrá un power up. Así aprenderá queacabar con los enemigos tiene recompensa. Acto seguido viene un pasillo bastante estrechocon un grupo de 2 enemigos. También es difícil esquivarlos, por lo que lo más normal es que elenemigo intente acabar con ambos y así verá que el primero que elimina no deja power up,pero el segundo sí. Es fácil que así vea que se obtiene un power up al acabar con una serie deenemigos, y ya tenga la capacidad para decidir si acabar con los enemigos o esquivar en lossiguientes encuentros, ya en escenarios más anchos.

Zonas de plataformas

Después de aprender a saltar en la primer parte del juego, y tener pequeñas diferenciasde altura para avanzar en algunos momentos, después de la zona de columnas llega el primerdesafío de saltos, sitio donde si fallamos caeremos al vacío, aunque en este juego caer al vacíosupone volver a un punto de respawn y perder un poco de salud. Por eso las plataformaspueden ser algo más complicadas que en otros juegos, ya que no morimos inmediatamente.No hay que pasar todas del tirón y a la primera.

Las zonas de saltos están compuestas por una serie de plataformas y tenemos que saltarde una a otra hasta conseguir alcanzar la zona siguiente, son bastante tradicionales. Laprimera zona de plataformas tiene las plataformas bastante juntas y se asciende, lo que haceque los saltos sean más fáciles, pero no da la impresión de zona regalada, porque al ser haciaarriba parece que cuesta más llegar a las plataformas de la dificultad real. La segunda zona deplataformas es hacia abajo y con las plataformas bastante separadas, hace que esta zona desaltos sea bastante más complicada que la primera. Y la tercera zona tiene sorpresa, ya quealgunas plataformas se caen al ponerse en contacto con ellas, por lo que mediante prueba yerror hay que aprender qué plataformas son las que no se caen y por las que podemosatravesar.

He dudado respecto a esta última mecánica. Tiene cierto aire injusto, ya que un buenjugador no tiene más facilidades que uno malo, es puro azar, las plataformas que resistirán notienen ninguna señal distintiva. No me parece un buen diseño de niveles en general, pero eneste caso lo voy a utilizar por la misma razón por las que era tan popular en los juegos de los80. El juego es muy corto, y me parece aceptable, sin abusar, poner alguna parte de dificultadinjusta, o al azar. Esto hace que hasta los jugadores más experimentados tengan problemas enpasarse el juego, a lo mejor pasan esta zona, pero perdiendo mucha vida y ya no puedenpasarse el juego. Así que tendrán que volver a empezarlo, alargando la vida del mismo. Yademás tendrán ganas de hacerlo, puesto que ahora se saben qué plataformas son lascorrectas y les resultará más sencillo.

78

Zonas de avance y disposición de enemigos

Después del primer grupo de dos enemigos descrito, viene una zona con columnas másancha, con otros dos enemigos que hacen ronda en rutas más amplias. En esta parte sesugiere que los enemigos son opcionales, además entre las columnas por la izquierda no haylímite, por lo que si el jugador quiere o está torpe se puede caer. Después de la primera zonade plataformas hay un escenario con una fosa en mitad del escenario y sin límites por ningunode los lados, nos podemos salir de la plataforma por varios lados, aunque es bastante ancha lazona y no será de forma accidental habitualmente. Después de la fosa está el primer enemigode tipo veneno, en un espacio bastante amplio para que no nos agobie con sus ataques.

La siguiente parte después de una zona de plataformas tiene varias fosas, hay que teneralgo de cuidado por donde se avanza, pero no es muy complicada, después tiene un grupo detres venenos, y en esta ocasión si hay límites laterales en el escenario, aunque es ancho, porlo que el agobio de lidiar con tres a la vez es mayor. En la última sección, en la que vemos enverde, no hay fosas, pero el escenario es muy estrecho y retorcido, por lo que los cuatrovenenos que nos encontramos suponen un obstáculo bastante grande con el que lidiar.

Enemigo Final

El enemigo final es un gran veneno, y está rodeado de ciegos, que funcionan comoobstáculos. Así pues es el mayor reto de la pantalla, es fácil que muramos y tengamos querepetir la pantalla intentando llegar con una mayor cantidad de vida hasta él. Se ajustará alfinal el número de espadazos que aguanta y la vida que quita y velocidad que tiene paraconseguir ese ajuste de dificultad deseado.

7.4.1 Curva de dificultad

Según lo visto anteriormente voy a componer la curva de dificultad deseada para elprimer nivel, de hecho voy a representar la dificultad añadida por tipo de elemento, y la totalpor encima. Las zonas del gráfico son las siguientes:

• [1]: Inicio (zona de movimiento)

• [2]: Tres listones para aprender a saltar

• [3]: Primer enemigo

• [4]: Pasillo de cristal (2 ciegos)

• [5]: Zona de columnas (2 ciegos, abierto por un lado)

• [6]: Primera zona de plataformas.

• [7]: Zona de árboles (foso, primer veneno)

• [8]: Segunda zona de plataformas.

• [9]: Zona metálica (fosos, tres venenos)

79

• [10]: Tercera zona de plataformas.

• [11]: Zona verde (cuatro venenos)

• [12]: Enemigo final.

Como dice la leyenda se tiene en cuenta la dificultad por zona de plataformas, enemigosy escenario, es decir que tengas que esquivar fosos, te puedas caer por los laterales o elcamino sea difícil de seguir. La curva verde es el total de dificultad sumando las partes, yvemos que sigue el patrón ascendente deseado sin grandes subidas, salvo en el enemigo final,y que no se desinfla, solo en la zona [10] hay menos dificultad que en la anterior, lo cual esintencionado como pequeña zona previa al monstruo.

80

Figura 12: Curva de dificultad

Capítulo 8: Implementación

8.1 Blog de desarrollo

La primera cosa que hice al finalizar la entrega de Tecnología de juegos y empezar aplantearlo como trabajo final de máster fue crear un blog para hablar del desarrollo del juego.El blog se llama Un novato en (desarrollo de) videojuegos [4], y mi intención era ir contandolas ideas sobre el juego (y sobre el juego de Animación por computador, y cualquier otropequeño desarrollo de videojuegos que hiciera de forma no profesional), los problemas ysoluciones a los que se enfrenta un novato como yo, y sobre todo las pequeñas leccionesaprendidas para que otra gente que esté empezando en desarrollo puedan saber lo que no hayque hacer. Hay una segunda razón para realizarlo y es para ir teniendo una serie de entradasdonde contase los problemas de desarrollo y así tener más fácil realizar la memoria delproyecto, sobre todo el presente capítulo.

Hice versiones de varios personajes famosos del mundo de los videojuegos cambiandosus colores característicos por cerámica de tipo Gaudí, y así unir algunas de las inspiracionesdel juego con el blog.

81

Imagen 33: Blog "Un novato en (desarrollo de) videojuegos”

El blog ha tenido un éxito considerable teniendo en cuenta lo específico que es y la faltade publicidad, y al finalizar junio de 2015, con menos de un año de vida ha superado las 4.000visitas, y pienso continuar la labor explicando los detalles de última hora del proyecto, asícomo sus ampliaciones y otros proyectos personales sobre videojuegos en los que meinvolucre.

8.2 Implementación del personaje

El proceso de creación del personaje es lo que más tiempo ha llevado en las dos partesdel proyecto, tanto para tecnología de juegos, como para el trabajo final de máster. Y esnormal, es el elemento principal del juego, está continuamente en pantalla y es lo que controlael jugador, por eso es más complejo de modelar, animar y programar comportamientos.

8.2.1 Modelado del personaje

Primera versión

Para tecnología de juegos se hizo un modelo genérico. La idea era poder utilizarlo tantoen esta asignatura, como en Animación por Computador, asignatura que no había completadoen el primer cuatrimestre. Y esta última me obligaba a hacer un modelado desde 0, a mano, locual es especialmente complicado para alguien de perfil técnico y con poca mano para eldibujo. Por eso seguí un tutorial de modelado en 3DS Max [64].

Fue una mala decisión, me dio muchos problemas. No por el tutorial, que es bastantebueno, sino porque no elegí bien. Miré el vídeo por encima, parecía que se entendía, pasé a losminutos finales para ver el resultado, y vi un modelo que parecía completo, la imagen estabacon zoom así que no se le veía la cabeza, pero parecía ya acabado. Me engañé yo solo. No vique no tenía manos, tampoco tenía cabeza. Y de hecho lo de hacerlo completo era solo unaprueba de concepto, solo estaba hecho a la mitad, sin reflejar. Yo pensaba que si en ese vídeohacía un personaje en una hora y pico, por mal que se me diera en 3 o 4 horas yo lo tendríatambién. Además este tutorial estaba pensado para un personaje desnudo, y el mío iríavestido, así que estuve forzado a incluir cambios sobre la marcha.

Y uno de los mayores errores fue no comprobar la complejidad del modelo. Algo que porotra parte no es tan sencilla en estos tutoriales. Así que me costó como dos tardes completarel vídeo. Seguí con los demás vídeos del tutorial, para las manos, cabeza, y pegarlo todo. Entotal entre 3 y 4 horas de tutorial que se convirtieron en meses de trabajo (al tener tan pocotiempo para esa asignatura con las demás acechando), seguramente unas 20 horas de trabajoneto. Hay que tener en cuenta que agobiado por la dificultad de modelarlo, y como tenía quehacer entregas quincenales, fui desarrollando prototipos de otras cosas y el modelado delpersonaje se fue dilatando.

82

Imagen 34: Modelado del cuerpo (izquierda) y una mano (derecha)

Cuando por fin tuve el modelo completo, resultó ser un monstruo bastante feo y de26.000 polígonos. Lo de que fuera feo es mi culpa, al narrador del tutorial le quedaba bastantemejor. Cosas de ser novato y poco diestro en la materia. Pero su personaje parecía tener losmismos polígonos o más. Estamos hablando de un personaje nivel Playstation 3. Un personajeque un ordenador mueve de sobra. Pero que no es lo que buscaba. Yo quería un personajesencillo, de unos pocos miles de polígonos, que pueda mover bien un móvil. Y que ademásfuera sencillo para el resto de pasos, porque tener un personaje tan complejo convirtió en unapesadilla los siguientes pasos del desarrollo del personaje para un novato como yo.

Además por la forma de construir el modelo y su fin en ese turorial tuve una serie deproblemas. El primero fue el culo. Me di cuenta que el tutorial era para alguien desnudo, y queel mío iba a ir vestido, entonces un culo en el que se notaban ambas nalgas no me servía, yaque aunque le pusiera textura iba a parecer un héroe en leggins, y no quería pasar por ahí.

El origen del problema viene en la forma de modelar el culo. Si pones una forma más omenos redondeada en una mitad del cuerpo para el culo, cuando espejas el modelo, quedacomo dos bultos independientes. Aunque estirases el bulto del culo justo hasta el punto desimetría no quedaría natural, sino que quedaría como una esfera que se corta bruscamente,como si tuviera un cañón. Entonces, y siguiendo el tutorial, se llevaba el bulto del culo más alládel eje de simetría, y al espejar queda bien. Esto supone que en realidad una parte de unanalga se incrusta en la otra nalga. Y que varios vértices quedan hechos un batiburrillo pormedio. Así que el proceso de ir cogiendo vértices e intentando sacarlos para que pareciera más

83

Imagen 35: Modelado de la cara (izquierda) y oreja (derecha)

Imagen 36: Montaje de las piezas y espejado

plano, como llevando pantalón fue enrevesado y tedioso.

Dando vueltas al modelo también descubrí que tenía la parte de atrás del cráneo y lanuca bastante raras. Parecía que tenía dos protuberancias en el cráneo y una cresta en lanuca. Esto se debe a que debí hacer uno de los pasos a destiempo o mal. Se recomendabaescalar un poco el borde del cuerpo para hacer la forma de la columna al espejar. Yo debíhacerlo a más parte de la que se debía. La solución llegados a estas alturas del modelado:corregir a mano, vértice a vértice. Es cierto que 3Ds max tiene una herramienta de relajaciónde vértices que para poner cosas al mismo nivel está bien, pero si la usas mucho acabaaplanando todo, y para el cráneo necesitaba una forma redondeada.

Segunda versión

Es uno de los mayores cambios que quería hacer, el personaje del juego entregado paraTecnología de juegos era feo, tenía demasiados polígonos y estaba mal animado, así quequería rehacer el personaje por completo.

Consciente de mis limitaciones en el apartado artístico decidí no volverlo a hacer desde 0,sino utilizar un modelo humanoide base de baja poligonización y desde él ir modificando paraque se pareciera a lo que se pretendía.

El nuevo modelo no tenía modelada la cara, ni ojos ni boca, todo iría pintado en latextura, casi es preferible, para el nivel que puedo conseguir es más sencillo pintar 4 carascaracterísticas en textura, tipo dibujo animado e ir cambiando de una a otra que hacer elrigging y animación facial para cada circunstancia. Y el número de polígonos baja mucho. Entodo lo demás tiene una poligonización más baja, con menor nivel de detalle, no tiene porejemplo marcadas las líneas de la mano, pero esos detalles tampoco se veían por la distanciade la cámara. Y el nuevo modelo, es sencillo, pero mucho más bonito, está mejor hecho.

El modelo que he utilizado estaba compuesto por varios subobjetos sin unir, así que unade las principales tareas fue unir esos trozos, y modelar los cambios que quería. El nuevomodelo tiene unos 2.000 polígonos, un grado de magnitud menos que el anterior. Tuve la duday así lo mantuve hasta etapas posteriores de si dejar un abrigo largo al personaje o quitarlo,finalmente opté por lo segundo para facilitar las animaciones.

84

Imagen 37: Nuevo personaje sin (izquierda) y con (derecha) abrigo largo

También modelé una espada, tipo katana, para el personaje. La espada tiene solo un filoy no doble como la mayor parte de modelos occidentales y que son para los que encontrabatutoriales.

Tampoco ha sido todo coser y cantar, y el nuevo modelo ha tenido sus problemas,algunos de los cuales se detectaron y tuvieron que solucionar en fases posteriores delproyecto, lo cual siempre supone mayor molestia y tiempo requerido.Del primero me di cuentacuando empecé a probar el personaje en Unity, y vi que el faldón visto desde dentro no sedibuja, o si miras dentro de la manga, es transparente. En 3DS max no me ocurría, y es quetenía desactivado el culling. Existe la posibilidad de activar el renderizado por las dos caras enUnity, pero si lo haces es para toda la escena. El impacto en rendimiento es brutal. No soloeso, sino que la iluminación comienza a fallar, y se ven efectos raros. No parece buenasolución.

La forma más sencilla de solucionar esto es coger los trozos donde hay este tipo deproblemas, en mi modelo el faldón y las mangas de la camisa, duplicar esa geometría y dar lavuelta a las normales en los duplicados para que ahora el duplicado sea la parte interior deesas prendas. Así que supone añadir nueva geometría y cambiar la topología del modelo. Dehecho 3DS max te da un aviso cuando quieres bajar en la pila de modificadores de que eso noes buena idea. Pero hice el proceso, pensando que con suerte se comportaría bien y con darpeso en el proceso de skin a los nuevos vértices ya lo tendría funcionando. Ni siquiera eso hizofalta, fue tan bien que los valores de los huesos para cada vértice nuevo también seduplicaron, así que al volver a la parte superior de la pila la nueva geometría se movíaexactamente igual que la de origen. Todo perfecto y un problema menos.

He tenido varios problemas al darme cuenta de que había triángulos que no estabanunidos al animar el modelo, o que sobraba o faltaba un vértice aquí o allá, siempre iba bien,pero eran cambios pequeños. El otro cambio que me dio más miedo fue a la hora de cerrar lamano para agarrar la espada. El esqueleto de CAD para personaje de juego trae cuatro dedos,ya se sabe por eso que se inventó Walt Disney de que con 4 dedos se pueden hacer todos losgestos importantes de la mano. No se me ocurrió en ese momento extender la mano con unquinto dedo antes de empezar el skinning, sino que pensé que como no iba a hacer muchaanimación con los dedos, era mejor asociar los dedos anular y corazón al mismo hueso y quelos dos se moviesen a la vez.

Y eso funciona bien, o eso parecía. Cuando he intentado cerrar la mano para que sujetela espada me he encontrado que la posición inicial del anular era más cerrada que el corazón.Así que al cerrar ese hueso, el anular atravesaba el mango de la espada antes de que elcorazón pudiera parecer que estaba cerrado alrededor de la espada. La solución: volver almodelo, y estirar el dedo anular, moviendo vértice a vértice para que quede igual que elcorazón, y rezar para que el skinning no se haya movido mucho al volver en la pila demodificadores hacia arriba. Me temía que de repente un vértice quedase muy separado y alanimarse el dedo quedase deformado. Pero todo fue muy bien, al volver a la animación no

85

Imagen 38: Espada sujeta con la mano cerrada

había nada raro, y ahora si podía cerrar los dos dedos a la vez y que ninguno atravesase elmango de la espada.

8.2.2 Texturizado

Primer personaje

Una de las consecuencias de tener un modelo tan complejo es que todos los pasosposteriores se dificultan. Y uno de ellos es el mapeado UV. Después hacer el mapeado con laherramienta que trae 3Ds max sólo conseguí un rebujo de líneas cruzadas en lo que seríaimposible pintar nada sin dar el mismo color a 14 partes y no saber qué estás pintando.Intenté modificar los parámetros y se consigue algo donde se distinguen algunas partes, perohay muchas partes pequeñas sueltas que no se sabe bien qué son, otras no tienen unaproporción aceptable o tienen un patrón de corte horrendo.

Intenté arreglarlo un poco, pero o no supe usarlo, o 3Ds max es muy complicado paraesta tarea. Un compañero de clase me recomendó usar Roadkill UV [79], un programaespecializado en el mapeado UV, y me enseñaron a usarlo un poco varios compañeros. Ymucho mejor. La tarea era lenta, tediosa y larga, pero al menos sabía por donde meterlemano. Este programa lee archivos OBJ, ves el modelo en 3D a un lado y el mapeado a otro, ypuedes ir dando cortes al modelo e ir colocando las piezas. Fueron 3 días de trabajo (aunqueno muy concentrado), pero a base de mucha paciencia, e ir escogiendo arista a arista cadasitio por el que quería meter un corte, y colocando las cosas, al final tuve un mapa UV dondese reconocían las cosas y podía pintar cada parte del cuerpo sabiendo lo que hacía.

Teniendo el mapa UV, ya podía pintar la textura. Supongo que quienes hagan esto bienno se saldrán al colorear y sacaran detalles preciosos. Yo me limité a cubrir con colores eintentar que quedase decente en pantalla. Aquí ya no se depende tanto de la complejidad delmodelo, pues tienes que pintar lo que sea la resolución de la textura y ya está, en este casoera 1024x1024. Pintas una imagen de ese tamaño, bien sea un modelo con más o menospolígonos. Aunque si se pueden tener problemas, que siguen teniendo que ver con el mapeadopero se notan aquí. Lo tuve por ejemplo con los ojos. Son superficies con muchos polígonos enmi modelo, pero que ocupan muy pocos píxeles. Si los pongo muy grandes en el mapa estoydedicando muchos píxeles a un espacio muy pequeño del modelo, y si los pongo máspequeños, es posible que un píxel de textura corresponda a varios polígonos, haciendo muydifícil pintar detalles como el iris, o la pupila. Lidiando como pude con estos problemas,finalmente tuve la siguiente textura, que se ve así en el modelo.

86

Imagen 39: Intentos de mapeado UV con 3DS

Segundo personaje

El proceso en el segundo personaje fue mucho más sencillo, puesto que el modelo baseya tenía hecho el mapeado UV, y solo tuve que retocar alguna cosas, como la espada ydirectamente ir pintando las texturas que quería sobre las que venían por defecto. Además elmodelo estaba hecho con un multimaterial y tenía 6 texturas diferentes, lo que facilita eltrabajo, aunque hay veces que confunde un poco hasta que encuentras el orden de separaciónde las texturas.

En esta ocasión elegí una mezcla de negro y morado, con gorro, como quería desde lafase de concept. Y poner el logo del juego en el pecho del personaje. Elegí el color moradoporque me gusta y porque es un color que representa la muerte en ciertas culturas y podríarepresentar a alguien ahogado, no tan lejos del personaje, completamente envenenado (y elverde está cogido por el propio veneno). También puedo aludir al significado cultural del color,“Color de transformación al más alto nivel espiritual y mental, capaz de combatir los miedos yaportar paz. Tienen un efecto de limpieza en los trastornos emocionales.“

Al tener un multimaterial con varias texturas, fue además más sencillo y más eficiente enejecución cambiar la cara del personaje, con el efecto agujero en la cara deseado. Así creécuatro texturas diferentes de cara para utilizar según el nivel de vida del personaje.

87

Imagen 40: Mapeado UV (arriba izquierda), Textura (abajo izquierda) y modelo con textura (derecha)

Imagen 41: Las cuatro texturas de la cara según el nivel de salud

8.2.3 Rigging y animación

En el caso del rigging el trabajo ha sido bastante parecido en ambos casos, he usado unesqueleto CAD, por lo que no he tenido que construir el esqueleto hueso a hueso y poner lasdiferentes restricciones de movimiento. La mayor parte del proceso ha sido el skinning yweighting. Sobre todo en el caso del primer modelo que al estar peor hecho y tener tantosvértices, a veces ajustar bien el movimiento ajustado a cada hueso acababa siendo en irvértice a vértice dando la influencia de cada hueso, y con más de 10.000 vértices era unproceso complejo y largo. Con el segundo modelo mucho más sencillo el proceso fue másrápido, con algún problema menor en articulaciones como por ejemplo la rodilla.

Animación del primer personaje

En el primer personaje, también por exigencias de Animación por computador, tuve quehacer las animaciones a mano, usando 3Ds Max. Grabando en frames clave los movimientosdeseados de los huesos y dejando que el programa interpole lo demás. Aquí no influye lacomplejidad del modelo, ya que se anima en base a los huesos. Aunque normalmente al iranimando salen a la luz problemas de skinning y hay que retocar lo anterior.

Hice animaciones para correr, salto con cada pierna, ataque con la mano y levantarse delsuelo. Las animaciones son bastante malas, incluso para haber sido animadas a mano. [70]Sirvieron en su momento para que el juego funcionase, pero no quería que la versión finaltuviera estas animaciones, que son muy mejorables.

El sistema de animación que se utilizó en esta primera versión fue el que se puede hacermediante código en Unity, esto supone elegir animaciones, incluso hacer transiciones conblending entre animaciones. Pero esto es bastante limitado comparado con los sistemas deanimación más modernos.

Animación del segundo personaje

Las animaciones utilizadas para la versión definitiva son una mezcla, siendo muchas deellas de bibliotecas de animación para Unity, y otras pocas hechas a mano con 3Ds max, perocon más tiempo y paciencia que las anteriores. Por eso estas animaciones son mucho mejores[73]. Hay animaciones para andar, correr, un combo con la espada, salto, ataque con la espadasaltando, idle, las animaciones de cambio de gravedad y la de levantarse del suelo. Lasanimaciones de levantarse del suelo, gravedad y ataque con espada están hechas a mano y las

88

Imagen 42: Esqueleto CAD (izquierda) y pesado de hueso (derecha)

demás son de biblioteca.

El sistema de animación también cambió, pasé a usar Mecanim, que es una máquina deestados finitos para las distintas animaciones. ¿se tienen mejores animaciones con Mecanim?No, las animaciones serán las mismas pero se usan mejor y es más sencillo hacer cosas máscomplejas. Mecanim no es un sistema para crear animaciones, sino para usarlas. Tendrás quedarle las animaciones hechas de forma externa exactamente igual que hasta ahora. Lanovedad es que para usarlas en lugar de hacer todo por código harás mucho con un editorvisual y con muchas más opciones y potencia.

También se pueden crear capas de animación y con una máscara de movimiento hacerque se aplique una máquina de estados solo a la parte de la máscara. Por ejemplo es útil paratener en una capa las animaciones de usar distintos armas y en más general el movimiento delcuerpo, así no hace falta hacer animaciones para cada combinación, por ejemplo: andar-pistola, andar-escopeta, correr-pistola, correr-escopeta. Tendríamos que hacer esas anima-ciones con el método tradicional, con capas, solo necesitamos andar, correr, disparar pistola ydisparar escopeta. Y todas las combinaciones las genera mecanim mezclando animaciones. Situviéramos muchas más armas la ventaja de animaciones aisladas frente a combinación seríatodavía mayor.

Podemos hacer blending de animaciones, y controlarlo en la máquina medianteparámetros. Es esencial para eventos no binarios, como un joystick. En los juegos de hace unpar de generaciones, aunque tuviéramos control con joystick, si dabas un poco en unaandaban y a partir de cierto punto corrían, era binario igual, pero con joystick. Pero con elblending podemos controlar completamente la animación, con 2 o 3 animaciones: andar correry opcionalmente esprintar, y dejando que el sistema mezcle las animaciones. Así, suponiendo 2animaciones, si pulsamos el joystick hacia delante un 20%, tendrá un 80% de andar y un 20%de correr, y si lo presionamos hasta el fondo solo correremos, con toda la gama intermedia demovimientos. Esto puede hacer que tengamos jerarquías de blending, y mezclar varios tipos demovimiento, y si usamos capas podemos tener unas muy buenas animaciones, aunque elsistema puede ser muy complejo y acabar teniendo bugs en las animaciones.

No solo esto, sino que mecanim permite añadir nuevas opciones sobre las animaciones,como curvas, eventos o interrupciones. Esto hace más fácil controlar la máquina de estados, yqué ocurre en ciertos casos. Además permite realizar de forma más sencilla parte de la lógicadel juego al asociar funcionamientos a momentos de las animaciones, o dar valores en curvaspara ajustar colliders, por ejemplo.

8.3 Implementación de los enemigos

8.3.1 Ciego

Este fue el segundo enemigo en idearse y construirse, y solo existe en la versión detrabajo final de máster, pero al ser el más sencillo he preferido hablar de él primero. El modeloes muy sencillo, una esfera con dos extremidades. En total menos de 200 polígonos. En estaocasión el mapeado UV lo tuve que hacer en 3DS max, porque Roadkill UV no me dejaba hacerlo que yo quería, dar más resolución a la parte delantera de la cara que a la trasera ya que allítendrá la cara.

Este personaje al tener extremidades necesita una animación interna al moverse. Hetenido que crear una jerarquía de huesos por primera vez. Hasta ahora siempre había animadocosas con esqueletos estándar, sobre todo humanoides, así que usaba huesos prefabricados.Es la primera vez que he tenido que coger y crear un hueso, colocarlo en su sitio, poner elsiguiente unido... Aunque este caso es fácil, cada brazo lleva solo 3 huesos, y no he tenido queponer límites de movimiento ni nada así, porque solo iba a hacer una animación y más o

89

menos sencilla.

El proceso de skinning tuvo sus problemas, ya que solo quería que los huesos movieranlos brazos y el resto del cuerpo quedase sin movimiento, 3Ds funciona bien así, pero al pasar aUnity me encontré que todo el cuerpo se movía con uno de los huesos, no permite vértices sinhueso asociado y da 100% de asociación con el primer hueso de la jerarquía. Además delmovimiento de las extremidades quise dar algo de animación Squash & Stretch [1], para queel resto del cuerpo se deformase con el movimiento. Lo hice escalando el modelo directamentey en 3DS max quedaba bien, pero Unity no coge animaciones que no estén asociadasdirectamente a un hueso. Para terminar Unity solo reconoce animaciones de un únicoesqueleto, en este caso tenía 2 esqueletos independientes, uno para cada extremidad.

La solución a los 3 problemas fue añadir un hueso más. Un hueso que uniera las 2extremidades en un solo esqueleto. Asociar los vértices del cuerpo a ese hueso para que elcuerpo no se moviera con uno de los brazos y aplicar el escalado al hueso para lograr laanimación Squash & stretch. [71]

El movimiento en Unity se implementó de forma bastante sencilla, utilizando el scriptiTween Multipath, puedo construir caminos en el editor de forma visual, y configurarlo para queel ciego siga cada ruta, continuando con la siguiente al finalizar la actual. Los contactos con elpersonaje, su arma y la posible muerte del ciego se dan forma en un pequeño script gracias alcollider. Y por último se utilizó un sistema de partículas para el efecto de la muerte.

Se agrupan los ciegos en grupos y con un script se asegura la pertenencia a un grupo yque el último enemigo de un grupo deje un power up al morir.

8.3.2 Veneno

Este enemigo fue único enemigo de la versión del juego de Tecnología de juegos y elmismo modelo se ha usado para el trabajo final de máster, siendo de las pocas cosas que nohe rehecho. El modelo tiene 224 triángulos, es muy sencillo, una esfera estirada en uno de los

90

Imagen 43: Modelo de veneno ciego

Imagen 44: Veneno con diferentes sombras

polos.

El mapeado UV fue trivial y este modelo no tiene animación interna, por lo que nonecesité ponerle huesos ni realizar ninguna animación. En Unity tiene además un material conalgo de brillo y efecto halo.

Para poder lograr las sombras como quisiera he utilizado un proyector en Unity. Seconfigura como una proyección de cámara, y se elije un material con la textura que queremosproyectar. Puede haber problemas, por ejemplo la sombra se proyectaba por todo el escenarioy era porque no estaba la textura marcada como clamp. En Unity 5 además tuve el problemade que proyectaba hacia los dos lados, es decir, hacia arriba y hacia abajo. Después de buscarmucho el problema encontré que era por los nuevos materiales de proyector de esta versión deUnity, en los que necesitaba una textura concreta de cutoff para que no pasara la dobleproyección consistente en una textura en blanco con la columna pixel más a la izquierda ennegro. Además del proyector cada venenos tiene 2 efectos de partículas, uno que está siempreactivo como si fuera soltando una estela al moverse, y otro que se usa cuando muere. Lamuerte cambia entre versiones. En la primera caía al suelo y explotaba en el contacto con elsuelo, en la segunda muere directamente ante el mandoble del héroe. Esto se hace así porquepodía dar problemas si el veneno caía en algún foso y no llegaba a tocar suelo.

El mayor reto del veneno es hacer la inteligencia artificial para programar su compor-tamiento. Básicamente quería que tuviera algo de movimiento bamboleando arriba y abajo, yque cada cierto tiempo al azar atacase al personaje, que solo se moviera cuando el personajeesté cerca, que después de atacar se retire en una dirección al azar, y que si está cabreadoataque más o más deprisa.

En la primera versión tenía 3 toques y había una probabilidad de 50% de que seenfadase al recibir daño. En la versión final he reducido a 2 toques y siempre se enfada alrecibir el primer toque.

Para hacer el sistema algo más eficiente cada Veneno no examina la distancia al rival osu IA en cada frame sino que el control central va haciendo que un veneno distinto lo haga encada turno. Realmente creo que he acabado ahorrando en algo que no era crítico, perotampoco queda mal, porque el veneno a veces tiene entre medio segundo o un segundo detiempo de reacción y queda natural.

La comprobación de la altura del suelo se hace lanzando un rayo hacia abajo, con unamáscara para solo tener en cuenta suelo y obstáculos. Dependiendo de la altura obtenida secalcula el siguiente destino del bamboleo. Primero se movía usando un seno, después usandocon una función de suavizado utilizando iTween. También hice el movimiento de bamboleo másrápido si el veneno estaba enfadado.

En la versión de Unity 5 tuve que hacer varios cambios en el comportamiento y en laescala, ya que os venenos tendían a desaparecer. También tuve problemas con los límites delos escenarios abiertos. Cambié algunas cosas, ahora los venenos no se activan por proximidaddel personaje principal, sino cuando éste entra en una caja, que es la caja de acción delveneno. Se intentó redirigir al veneno cuando salía de esta caja, pero hay veces que no hacencaso, y no puede tener choque físico contra ella, o el personaje principal también se chocaría.La solución a esto es tener otra segunda caja contenedora, y que los venenos si choquenfísicamente con ella y aprovechar la pirámide de cruces físicos de Unity para que solo detectecolisiones con los venenos y no con el héroe.

8.4 Implementación de la cámara

Uno de los mayores quebraderos de cabeza del juego y que ha pasado por muchasversiones. De hecho hay ocho entradas en el blog sobre la cámara del juego, voy a intentarresumir su implementación a continuación.

91

Al principio, en las primeras aproximaciones al juego usé un modelo de cámara muysencillo situado detrás del personaje y que se movía y giraba con él. Hacía complicadosalgunos movimientos, atravesaba objetos y no era manejable. Por otro lado como he dichoanteriormente, no quería una cámara que pudiera manejar el usuario por la dificultad de loscontroles. Tener 2 ejes de movimiento, 2 de libertad de cámara y 3 botones para el cambio degravedad es demasiado. Por ello se eligió una cámara sobre raíles.

La primera tentación es la de crear una cámara muy sencilla que funcione rodando por uneje. Por ejemplo en el eje z, así que la posición x e y será fija en diseño y la posición en z serála del personaje, un poco más retrasado. Es una forma sencilla de implementar, y tienes un raila lo largo de z, se podría hacer para cualquier eje y dirección. Pero ese es el problema, estásobligado a que sean ejes para que sea tan sencillo. Si en tiempo de diseño quieres un corredoren 15º, la cámara no mirará a lo largo del corredor al no ser perpendicular a los ejes. Es unarestricción demasiado fuerte para el diseño.

Aunque ya tenía algo de experiencia usando splines como rutas para la cámara por lapráctica de la montaña rusa en OpenGL de la asignatura de Rendering Avanzado, hacerlo amano, y que funcionase como quería como cámara en tercera persona iba a ser muchotrabajo, y probablemente poco eficiente, por eso, después de ver lo que iTween Path podíahacer decidí usarlo para la cámara.

Una vez que se tiene una ruta en forma de spline hay que pensar cómo calcular en queposición del spline debería estar la cámara según donde esté el personaje. La solución quetomé, intentar dividir los splines en trozos más pequeños, a ser posible parábolas, aunque siuso algunos de 4 o 5 nodos. Entonces, cometiendo un pequeño error, tomar como recta launión entre el primer y último nodo y proyectar la posición del personaje sobre la líneaanterior. La longitud de la proyección en esa línea, será la que tomemos como distancia delpersonaje. Los splines funcionan parámetricamente con un parámetro [0-1], así que ladistancia de la línea que une los nodos la tomo como uno, y la distancia que tomo que tiene elpersonaje al nodo inicial será una fracción menor que uno.

Realmente estoy tomando la posición del personaje, teniendo únicamente en cuenta suposición en el eje que une los nodos extremo del spline. Funciona bien si el spline no es muycurvado ni hace cosas raras, para que la aproximación de la unión de los nodos extremos porlongitud del spline sea aceptable (probé a hacerlo con la longitud real del spline, iTween lacalcula, pero funcionaba peor).

Por la forma de tomar la posición del personaje la cámara solo avanza o retrocede si semueve en la dirección del spline, pero se queda en el mismo sitio si el jugador mueve solo a laizquierda o la derecha. Esto hace que si el escenario es demasiado ancho el personaje puedasalir fuera de lo que se ve en pantalla. Para resolver este problema y no tener tanto problemade diseño en los escenarios decidí que la cámara girase siguiendo siempre al jugador, de talforma que siempre estuviera centrado en la imagen, pero solo se moviera a lo largo de la rutamarcada.

Esto sería para un trozo, pero en realidad hay varios, y hay que hacer bien el empalmeentre ellos. Si en diseño tienes cuidado y pones el inicio de un trozo como el final del anterior ycon una orientación parecida (no hace falta que sea C1) solo hay que saltar al siguiente splinecon posición 0 cuando lleguemos a la posición 1 del actual. Pero no es tan sencillo, porque laposición de la cámara no es exactamente la del jugador. La cámara la retraso una distancia fijaen coordenadas del spline, pero dependiendo de la longitud de éste. Por ejemplo en un splinede longitud 100 la distancia será de 0.08, pero en uno de 200 será de 0.16, por poner unejemplo. Siempre hablando de distancias entre [0,1]. Entonces el problema lo tenemos en queaunque el personaje haya pasado ya al siguiente spline, la cámara sigue en el anterior. Por loque estamos extrapolando su posición más allá del límite de ese spline. Yendo hacia atrás nospuede pasar lo contrario, que al restar esa distancia de cámara, de menos que 0, por lo quedebemos ir yendo al spline anterior. El sistema así tomado funciona bastante bien.

El primer problema que surgió tiene que ver con la decisión de hacer que la cámara seorientase hacia el personaje. De esta forma adelante no es adelante. Es decir que si estamosjugando y queremos ir al fondo de la pantalla, lo más normal es que pulsemos la tecla de

92

arriba (o joystick hacia arriba) y ya está. Pero si hacemos esto es bastante probable que elpersonaje se desvíe a un lado. Así que a la hora de jugar es bastante molesto, porque hay quecorregir la posición constantemente y da la impresión de estar reconduciendo todo el rato alpersonaje que tiende a desviarse de donde queremos. ¿Y esto por qué pasa? Pues por lacombinación controles según cámara + cámara sobre raíles + apuntar al personaje. Ya que ladirección que supone “hacia delante” depende de la orientación de la cámara y esta orientaciónse mueve cuando el personaje lo hace, pero la cámara lo hace sobre un raíl.

También sufría parpadeo entre tomas al cambiar de spline. Es algo raro, de estas cosasque no suelen pasar y que puedes pasar el juego sin verlo, pero si se te ocurre andar más a laizquierda de lo normal, por ejemplo, de repente pasa. La imagen parpadea entre planos, si nosmovemos un poco ya deja de hacerlo. Siempre he pensado que era un problema de precisión,que en una parte se volvía loco porque en unos frames la cámara le daba en la posición 0.001de un spline y en otro frame en la 0.999 del spline anterior. Eso efectivamente haría queparpadease entre los 2 splines y algo cambiase el plano. Pero no sería tan brusco. Porque enesos planos parpadeantes vemos el correcto, pero el otro no tiene nada que ver, la cámara seva a cuenca. Así que seguramente quede en algún estado inestable, una posición negativa delspline o algo así, que hace que el spline se extrapole más allá de los límites permitidos y hagacosas raras. Otro problema es que según la forma del spline la distancia de la cámara alpersonaje no es constante y es algo difícil de solucionar.

Esto eran los problemas de la primera versión de la cámara, con la que funcionaba eljuego en la versión entregada en Tecnología de juegos, los siguientes cambios son ya para laversión de trabajo final de máster.

Una de las medidas fue pasar a usar trozos de spline más cortos, con número fijo denodos y separación constante entre nodos. Esto lo hago para intentar evitar que la cámaraesté más lejos o cerca según el trozo de spline que nos toque.

Otra es la triangular por cada unión entre nodos y no por el trozo de spline completo. Esdecir, en la versión anterior se calculaba la posición más cercana del spline de formaaproximada tomando la recta que unía primer y último trozo. Ahora mido la distancia delprotagonista a cada nodo del spline y calculo la posición respecto a la recta que une esosnodos (con alguna comprobación extra). En teoría esto debería hacer que haya menos errorentre la aproximación de la posición y el recorrido del spline, haciendo que la distancia alpersonaje sea más constante.

El siguiente añadido es hacer que los splines se superpongan, el final de uno con elprincipio del siguiente. De esta forma en las zonas de transición entre trozos de spline laposición será interpolada entre los dos splines. Es una de las razones por las que uso 5 nodospor spline, así cada trozo de spline tiene 4 espacios entre nodos. La parte 0-25% estácompartida con el spline anterior, la parte 25%-75% es exclusiva del spline en curso y la parte75%-100% se comparte con el spline siguiente. Además la posición es más cercana al primerspline cuando comienza el segundo y más cercana al segundo cuando el primero se va aterminar.

Por ejemplo en la posición 80% de un spline (y por lo tanto 5% del segundo), la posiciónserá un 80% del primer spline y un 20% del segundo; si tomamos la posición 90% del primerspline (15% del segundo), entonces la posición final será de 60% el primer spline y 40% elsegundo. Aquí cuando hablo de % de un spline me refiero a la variable paramétrica querecorre el spline (0-1) y cuando me refiero a porcentajes de uno u otro spline utilizados para laposición es literalmente a cuanto aporta la posición de cada spline a la posición final.

Para el error de control de personaje, en la nueva versión la cámara va apuntando en ladirección de avance del spline y no al personaje. Eso hace que haya que tener cuidado en eldiseño de escenarios para que no sean muy anchos y que el personaje no pueda quedar fuerade cámara.

Esta cámara funciona mejor, pero también tiene problemas. Lo primero, problemas en losextremos del escenario, se arreglan, pero eso añade código extra para casos marginales.Orientar la cámara en la dirección del spline no es tan sencillo. Intento usar la posición anterior

93

del jugador, y funciona relativamente bien cuando avanza hacia delante, pero si va hacia atrásen el escenario no funciona bien. Podría arreglarlo enfrentando el vector forward del personajey de la cámara y teniendo en cuenta su producto escalar. Pero no era el único problema, habíamomentos que se volvía loco y no sabía hacia donde enfocar. Así que al final funciona tomandoun segundo punto en una posición más avanzada. Es decir si la tiangulación me da que laposición del personaje es 0.45, pues pongo la cámara en 0.25 para que se vea el personaje ycalculo su posición en coordenadas del mundo y también calculo las coordenadas en posicióndel mundo del 0.35, así la cámara estaría en el 0.25 pero mirando hacia el 0.35. Esto funcionabien, y con un par de comprobaciones para casos extremos funciona.

Otro problema y muy gordo es encontrarte con un bucle infinito. Y esto pasa en algúnpunto raro de los empalmes de splines. Imaginemos un punto justo al extemo (el extremo seráel 100% del primer spline y el 25% del segundo), pruebo para el primer spline y me da100.04%, entonces como ya me paso del primer spline intento coger valor del segundo splinesolo, y me da por el error de triangulación 24.95%, por debajo de 25% así que todavía tengoque volver al primer spline y hacer la mezcla de los 2, pero en el primero me vuelve a dar100.04% etc etc etc. Fijándome un poco de donde vengo, puedo romper ese infinito. Si vengode pasar de un spline al anterior, uso el primero y no vuelvo al segundo, aunque me pase del100% ya que la función del spline extrapola bastante bien.

El mayor problema que me encontré fue el rendimiento. El juego con el sistema decámara anterior funcionaba a unos 60 fps, solo cambiando la cámara (tengo ambos códigosfuncionando y puedo comparar en las mismas condiciones), con el nuevo sistema funcionaentre 20 y 30 fps. Cuando se acerca a 20 fps se hace desagradable jugar, se nota que no vafluido.

El tener que hacer la comprobación de distancias para ver entre que dos nodos triangulary no hacer directamente la de todo el spline es más caro. Y en el peor de los casos, en el casode transición hay que hacerlo 2 veces, uno para cada spline, y a la hora de evaluar la posicióndel mundo que tiene ese valor de spline se puede hacer hasta 4 veces, 2 para la posición decámara si está entre 2 splines y 2 para la dirección si pilla también entre splines.

Investigué si por la forma de hacer el código, o porque no se sacar rendimiento a c# oalgo así tenía esa pérdida de rendimiento. Intenté cosas como volver a la evaluación única porspline, pero con las normas de nodos adquiridas en a nueva versión, y a hacer una caché deposiciones del spline para no tener que hacer varias evaluaciones por frame. También a ver unpoco el cambio entre splines, que a veces queda un poco brusco con el nuevo sistema, aunqueno se vuelve loco como en el anterior. Los problemas de rendimiento parece que no eran deltodo debidos a la cámara, sino a unos problemas internos de Unity con la espera de repintadoque cierto uso de la cpu sacaba a la luz y cambiando algunas configuraciones volví a tenerbuen rendimiento usando el nuevo sistema de cámara.

Después de tener funcionando esta versión todavía hice una tercera cambiando aspectosde la cámara. Mantuve tener trozos de spline de 5 nodos, con nodos equidistantes, y donde elúltimo tramo de un spline y el primero del siguiente se suponerponen haciendo una transiciónsuave entre un spline y el siguiente en esa parte en común. Lo que al final se quedó fuera fuela aproximación de la posición del personaje al spline por trozos de spline. Volví a aproximar elspline como una recta para saber a qué altura del spline está el personaje. En mis pruebas nose nota diferencia entre las dos aproximaciones y es más barata.

Uno de los problemas que tenía desde el principio de los tiempos y que pensaba que elusar la transición suave entre 2 splines se iba a arreglar era el de los puntos muertos en losempalmes de splines. El problema es básicamente una zona muerta que no cubre ningúnspline. Incluso he tenido implementaciones en que este problema daba un bucle infinito al usarrecursividad y me tocaba matar Unity. Si no el problema es que hay un punto en el queestando el personaje quieto, la cámara vibra entre dos tomas, que a lo mejor son muycercanas, pero la sensación de parpadeo entre las dos es horrorosa, y no solo es si te pillaquieto en ese sitio, al pasar por él, aunque solo vibre una vez, se nota que ha pasado algoraro. Este problema ocurre incluso con los splines superpuestos. Ya que esto realmente loúnico que consigue es desplazar los valores donde ocurre, pero sigue ocurriendo. Un ejemplo

94

práctico: posición en el spline 1: 100.01%, hay que dibujarlo en el spline 2, donde tiene laposición 24.95%, en el siguiente frame: 24,5% es menor a 25%, así que debe dibujarse en elspline 1. Y así tenemos un parpadeo constante, si cada frame se coloca la cámara en un sitioun poco distinto. Claro, es que teniendo todo un tramo para hacer los cambios, lo hago en elmismo punto al avanzar y al retroceder, separando los dos puntos clave no tengo eseproblema. Así ahora al avanzar se cambia de un spline al siguiente cuando alcanza el 100% (ysigue por el 25% del siguiente), pero al retroceder, se hace cuando bajo del 15% del spline(siguiendo hacia abajo por el 90% del spline anterior). Y así, por mucho error de aproximaciónen los empalmes que haya, no puede ser de un 10% y no tengo ese fenómeno del parpadeo.

Relacionado con esto está el error de índice fuera de rango que obtenía a veces y que nosabía de donde venía, y el problema es el mismo. Cuando llego al 75% de un spline se tomaposición respecto a ese spline y respecto al siguiente y se va interpolando entre las 2. Porejemplo: 0.8 en un spline en realidad tomo un 80% de la posición del primer spline al 0.8 y un20% del segundo spline al 0.5. Justo al llegar a 0.75, puede pasar que el segundo spline mede un valor de -0.02, por ejemplo, y ese valor negativo es lo que me hacía saltar por los airesel método para calcular posiciones de spline de iTween. Por encima de 1, el método extrapolavalores muy bien, pero por debajo de 0 peta. Sabiendo esto y añadiendo unos clamps por ahíla solución era fácil, lo difícil era darse cuenta del problema, sobre todo porque se daba enocasiones contadas, no era fácil de reproducir.

Otro problema era la orientación de la cámara. Para no hacerlo caro intenté aprovechar laúltima posición de la cámara y la actual para ir enfocando hacia la tangente. El primer errorsaltaba inmediatamente: si el jugador se paraba la posición anterior y la actual son la misma yla cámara se pone a mirar para cuenca. Solución fácil: comprobar la posición, si es la misma yel jugador no se ha movido pues no hacemos caso y seguimos con la anterior posiciónregistrada. Pero volvemos a tener un problema de precisión. ¿Y si el jugador se ha movido muypoco? ¿Y si no se ha movido pero por un problema de precisión Unity cree que si? En estoscasos puede que los operadores de comparación fallen al ser dos cifras muy parecidas y hagalo que lo debe, ponerme la cámara mirando al revés. Es un caso raro, pero he conseguidodando vueltas por algún punto conflictivo que la cámara mire justo hacia el sitio contrario dedonde debería. ¿Y qué hago? ¿Pongo un umbral de movimiento? Esto podría tener unproblema, que alguien se moviese muy muy despacio y la cámara no le siguiera al no detectarel movimiento.

Lo podría hacer acumulado, no tomar una nueva posición para la orientación hasta queno se haya desplazado un mínimo desde la anterior, pero sigo teniendo problemas. A veces dasaltos, porque el diferencial usado para separar los puntos no es siempre el mismo y se notamucho el tirón. Intenté también usar posiciones pasadas cuando sea posible e inventarlas conun desplazamiento sobre el spline cuando no. Aquí el parpadeo era evidente, la diferencia deorientación cuando se usaba uno u otro método era muy evidente. Tras descubrir que losproblemas de rendimiento no eran por la cámara pude dejarme de tanta tontería y tomarsiempre dos medidas de cámara para poder orientarla. Ahora si la cámara acaba en unaposición x (en spline) calculo su posición en coordenadas del mundo y la posición de x+0.1 ypongo la cámara a mirar en la dirección de la tangente generada por estos dos puntos. Así elmovimiento de la cámara es bastante suave.

El último problema que tuve fue la orientación inicial de la cámara. El jugador empiezaalgo por detrás del punto 0 de la cámara, y tanto la posición de la cámara como la auxiliarpara orientación quedaban por debajo de 0, siendo clampeadas a 0 y teniendo otra vez lacámara mirando para cuenca. Con un poco de precaución del orden en que hacer la suma devalores extra y los clamps esto también se solucionó.

Al migrar a Unity 5 todavía hubo más cambios en la cámara, ya en su forma final. Eneste nuevo proyecto la escala es bastante pequeña, así que el hueco que dejo entre la posicióndel personaje y la de la cámara era tan grande que se me acababa el trozo de escenario quetengo antes de que la cámara comenzase a moverse. Así que tuve que bajar esa distancia.Puedo caer en un problema de precisión por usar una escala más pequeña. La otra opción erareescalar todo lo que tenía, modelos, escenarios, potencias, efectos de partículas, es muchomás trabajo.

95

También cambié el movimiento de la cámara para que no sea directo. Hasta ahora almoverse el personaje se triangulaba su posición respecto a la ruta de la cámara y se movía lacámara al sitio donde debería. Ahora en lugar de mover la cámara directamente se mueve elpunto de objetivo de la cámara y se va interpolando la posición de la cámara para que seacerque suavemente al punto objetivo.

He puesto un parámetro para ajustar el suavizado del acercamiento de la cámara alpunto deseado. Y he estado jugando con ese parámetro y el de distancia de acercamiento de lacámara al personaje. Si la cámara se adapta lentamente el jugador quedará muy lejos cuandocorra. Y si corre hacia la cámara incluso podría salir de plano. Si se pone más rápido esadistancia es menor, pero hay que tener cuidado que al pararse el personaje y llegar la cámaraa destino el personaje no quede cortado en el plano.

Al final y aprovechando el suavizado pude poner una cosa que tenía ganas: la distanciade cámara dependiente de la dirección del personaje. Es algo que me di cuenta hacían en elCrash Bandicoot [38] y que tiene mucho sentido. Es tan fácil como alejar la cámara si se andahacia la cámara y ponerla más cerca si se anda hacia el fondo. Hice la comprobación con elproducto escalar de los vectores forward de cámara y personaje, y dependiendo del signo se siel personaje anda hacia el fondo o hacia cámara y pongo una distancia de cámara u otra, y elsuavizado de cámara se encarga de que esa transición sea más o menos suave.

El resultado final es una cámara más suave, y que nos da algo de aire si andamos haciaatrás para que veamos hacia donde vamos, pero sigue de bastante cerca al personaje si vamoshacia delante para poder ver la acción bien, no demasiado pequeño.

Aún con todos estos esfuerzo la cámara ocasionalmente tiene algún error. Con elsuavizado de cámara muchos de los problemas se han hecho más livianos, pero siguehabiendo zonas donde la cámara sigue al personaje más cerca y otros donde se nota el cambiode spline. Además de que por un mal diseño de niveles el personaje puede quedar fuera decámara, algo que ya habíamos aceptado en el diseño.

8.4.1 La cámara en el cambio de gravedad

Cuando estuve utilizando el SuperCharacter controller, quería asegurarme de que podíahacer el cambio de gravedad con ese nuevo controlador de movimiento, por eso lo estuveadaptando para poder usarlo, y en la demo en la que venía este controlador la cámara estabahecha de tal forma que se movía con el ratón, o con un segundo joystick. Y así lo estuveprobando, tuve que hacer que la cámara girase con la gravedad y adaptar los giros de ratón ala nueva posición de la gravedad. No fue algo trivial, aunque lo conseguí en un par de díasgracias a los conocimientos de cuaternios. Y la práctica me vino bien para cosas que tuve queprogramar después.

Aquí el concepto que saqué es el de cambio de gravedad desde el eje más cercano alforward de la cámara. Y funciona bastante bien, aunque hubiera restringido la libertad en eldiseño de niveles. [72]

Cuando hice la migración a Unity 5 y descarté el SuperCharacter controller en favor delcontrolador de Unity, tuve que rehacer la parte de cambio de gravedad y adaptar esemovimiento al tipo de cámara que usaba en el juego final.

La solución fue tener cuatro trazados, uno por cada posible cambio de gravedad, y segúnla gravedad en ese momento la cámara irá por un raíl u otro. Además como tenemos elsuavizado de cámara, a la hora de pasar de uno a otro se hará automáticamente de formaprogresiva.

Necesito suavizar 3 valores ahora, la posición de la cámara, hacia donde mira, y el vectorup. Este último es nuevo, ya que hasta ahora dábamos por supuesto que arriba era arriba,pero al cambiar la gravedad el concepto de arriba ya no está tan fijo. A la hora de implementar

96

esto tuve bastantes problemas. Utilizaba la posición, vector forward y vector up del transformde la cámara como referencia actual e iba modificando su posición haciendo Lerps tomandocomo meta el valor de cámara deseado. Pero no conseguía que el vector up cambiase, siemprequedaba como el vector up normal (y+). Después de bastantes pruebas comprobé que teníaque ver con el vector forward, al dar valor a este se sobrescribía el up. Algo que no tienemucho sentido, pues yo puedo estar mirando hacia delante y estar haciendo el pino o estar depie normal, un vector no debería afectar al otro.

Probé a ir girando la cámara al igual que hago con el personaje, aprovechar la mismafunción que va girando uno y girar el otro. Pero no funcionó bien, no gira o gira, pero al llegaral giro máximo vuelve a la posición inicial. Finalmente conseguí que funcionase como se esperausando la función LookAt. Esta función toma dos parámetros, el punto hacía el que mirar y elup. Cambia un poco el concepto, no toma el vector forward sino un punto hacia el que mirar.Son cosas complementarias, pero yo lo tenia hecho para sacar el forward, así que me tocócambiar un poco esa parte. Por otra parte no hay un punto “LookAt” en el transform, así queno puedo ir haciendo una transición hacia ese punto directamente, por lo que guardo un valoractual al margen para poder seguir usando Lerp sobre el valor. Con esto funciona bien en girosde 90º y hace un cambio algo brusco en los de 180º, pero podría aceptarlo. Bueno, cuandofunciona bien, el botón responde y el personaje no se queda girando de forma infinita singravedad como si hubiera salido al espacio. [74]

8.5 Migración a Unity 5

Con el anuncio de salida inmediata de Unity 5 en Marzo y viendo sus características,decidí probarlo y una vez probado decidí intentar migrar el proyecto a Unity 5 para poderutilizar sus bondades. No pude migrar el proyecto tal cual, Unity tiene una herramienta parahacerlo, y me dio un proyecto de Unity 5 desde lo que tenía de Unity 4. Pero no funcionabanada y empecé a tener errores muy raros. Así que abrí un proyecto nuevo, desde cero y fuiimportando y transformando cada pieza. Tuve que adaptar algunos script, puesto que hayfunciones que han dejado de funcionar en el nuevo Unity. Hay cosas que hubo que cambiarcompletamente y otras adaptar. Voy a hacer un pequeño recorrido por las más importantes.

8.5.1 Iluminación

El cambio más importante en Unity 5 es el nuevo sistema de iluminación y los nuevosmateriales. Ahora se tiene algo de iluminación en tiempo real, unas pinceladas, y los nuevosmateriales son physically based. Esto supone que hay que cambiar todos los materiales usadosa los nuevos, incluso de aquellos assets de terceros. No es muy difícil, de hecho los nuevosmateriales son más fáciles de configurar. Y salvo alguna pequeña excepción solo hay que elegirel nuevo tipo de material que usar y configurar un poco algún parámetro a nuestro gusto.

Al empezar un proyecto nuevo las luces las puse desde cero, así que ya las configuré conlas nuevas características, así como la configuración de iluminación de la escena y el motor depre-cálculo de la iluminación (Beast). Esto me dio algún problema. En Unity 5 no está marcadopor defecto que se generen las coordenadas UV de iluminación en los modelos. Esto hace quela iluminación de elementos estáticas quede mal, como si tuviera un patrón de sombras raropor encima, como si estuviera sucio. Y fue bastante complicado encontrar el problema contantas opciones, ¿resolución del mapa? ¿parámetros mal equilibrados? ¿defecto en el modelo?.Tras encontrar la opción que daba problemas toda la iluminación fue bien, configurando lasluces o añadiendo alguna extra en alguna zona he conseguido una iluminación que me guste.

Otro problema que tuve con Beast fue en la zona de árboles, cuando usaba los árboles

97

Koreanos es que debían ser demasiado que mapear para el motor de iluminación y se mequedaba Unity congelado durante horas, incluso en varias ocasiones me colapsó el ordenadorcompleto. Probé muchas configuraciones diferentes, intentando aligerar la carga, pero nuncaconseguí que funcionase. Tuve que dejar esos árboles como objetos dinámicos para que Beastno se metiera con ello. Después de tener un problema de rendimiento, decidí cambiar esosárboles por otros más sencillos y con los nuevos árboles ya no tuve problemas con Beast.

8.5.2 Sonido

Unity 5 ha traído también nuevos controles de sonido, y la verdad es que hacía falta, unavez más pasamos de algo bastante básico a un control completamente profesional. Visto porencima puede parecer que han metido una mesa de mezclas y ya, pero tiene bastante másprofundidad.

Las mesas de mezclas son Mixers, nuevos elementos que creamos, y serían elequivalente en sonido al Animator que usamos con Mecanim. Son elementos con su propiaventana de edición. En un Mixer podemos crear lo que serían canales de la mesa de mezclas,que se llaman Groups. En principio es parecido a un canal en una mesa de mezclas, pero conañadidos. Los Groups del Mixer son una jerarquía donde el sonido de los hijos pasa por el canalpadre. Es decir si tenemos una jerarquía típica familiar en un Mixer (abuelo, padre, nieto), elgroup nieto tiene su sonido, que pasará al padre, si el padre tiene reducción del 50%, llegaráun 50% del volumen del nieto al abuelo, y si el abuelo tiene otro 50% de reducción el sonidofinal que escucharemos será un 25% de lo que sonase en el nieto.

Ahora cuando ponemos un AudioSource en algún lado, además del clip a reproducir yotras configuraciones, tenemos que elegir un group de una mesa que será por donde sonaráese sonido. Similar a si el AudioSource fuera un reproductor o un vinilo y lo enchufamos a uncanal de la mesa. Con la diferencia de que aquí podemos enchufar todos los AudioSource quequeramos al mismo group.

Tenemos además efectos de sonido en tiempo real que podemos añadir en una pila acada canal. Efectos como reverberación, eco, reducción por tonos, limitadores de pico devolumen, cambio de velocidad, distorsiones... Y siempre el de control de volumen(Attenuation) que es un efecto obligatorio en cada group. Funcionan como una tubería, cadaefecto da su salida al de debajo y por lo tanto el orden afecta al resultado.

Hay que tener en cuenta que estos efectos en tiempo real pueden ser exigentes para laCPU, por lo que es recomendable juntar los sonidos y aplicar el efecto solo una vez. Es decir sitenemos una escena en una cueva y queremos que haya eco, es mejor juntar los sonidos dediálogos, fx y demás y aplicar el eco sobre el total que aplicar un eco a cada tipo de sonido.

Para poder hacer esto mejor nos dan los comandos send y recieve. Nos permite ponercomo un efecto más en la pila un receive para un canal y enviar sonido desde otro(s). Asípodríamos tener un canal para el efecto de eco y enviar lo que nos interese hacia él y el efectose haría solo 1 vez mejorando el rendimiento. También podríamos haber hecho estoaprovechando la jerarquía, hacer todos los groups que necesiten eco hijo del group que tieneel efecto, ¿qué ventajas nos da hacerlo con send y recieve?

Uno es que podemos poner varios send a canales distintos. Esto nos permitiría mandar elsonido de fx al canal que hace eco y también al que hace reverb (suponiendo que tengamosesos efectos separados por algo), y que cada efecto se aplique sobre el sonido original. Si lohicieramos con jerarquía uno de los efectos se aplicaría sobre el resultado del otro. Y la otragran ventaja es que podemos elegir el volumen de envío en send. Esto hace que aunquetengamos varios sonidos distintos yendo al mismo efecto no tenemos por qué tener el mismonivel de volumen en todos. Por ejemplo, imaginemos que queremos reverb en música y fx, silo hacemos por jerarquía, podemos ajustar el volumen de música, fx y reverb, pero el volumende reverb será el mismo para música y fx, no podemos ajustar eso. Con send y recieve

98

podemos poner la música al 80% de volumen, y enviar al 50% con send (tendríamos un 40%de reverb en música), y el fx al 100% con un send del 80% (tendríamos un 80% de reverb enfx), y todo eso sin tocar la atenuación del group del reverb. Es muy versátil y eficiente, ajustarvolúmenes es una multiplicación más y tenemos mucho control sobre efectos complicado entiempo real sin mucha sobrecarga de CPU.

Y ya la cosa que me ha encantado son los snapshots, que son copias de la configuraciónde todos los parámetros de un Mixer. Esto nos permite pasar de una configuración de sonido aotra de forma fácil, podemos ajustar todos los parámetros en el editor (incluso con el juego alplay), y guardarlos como un snapshot, y configurar de forma completamente distinta para otromomento u otra zona de juego que tiene sonido diferente y guardarlo como snapshot, y luegoen código con una sola línea pasar de una a otra, incluso con transición suave entre ellas.

Teniendo todo esto lo que quiero conseguir en el juego es:

• Poder controlar (incluso dar la opción al usuario en la configuración) el volumen demúsica y efectos de juego (espada, curación, quejidos...) por separado.

• Poder cortar el volumen de todo el sonido del juego cuando suene una interrupción, quese note también que se interrumpe el sonido normal del juego con esa interferencia.

• Un efecto de corte de frecuencias altas en el menú de pausa.

• Poder poner un efecto de reberveración y eco ajustable a todos los sonidos y bajar elpitch de la música según el estado de salud del personaje.

• Que la transición entre estados del personaje sea suave.

Mi jerarquía de groups en el mixer es la siguiente: tengo un group padre (Master) y 4hijos directos: Music, Effects, Reverb e Interrupción. Los nombres son bastante descriptivos,un group para la música ambiente, otro para efectos de sonido, otro para el efecto dereverberación y eco; y otro para el sonido de las interrupciones.

En el group de reverberación recibo los sonidos que me quieran mandar en lo alto de lapila, después viene la atenuación (así puedo controlar el volumen del eco) y después vienenlos efectos de reverberación y eco. Lo que recibe este canal son la salida de los canales demúsica y efectos.

Cuando hablo de transiciones entre estados, no solo quiero poder hacer una transicióncuando cambie el estado, sino que el sonido esté constantemente cambiando entre los 2extremos del estado en el que estemos, para conseguir un efecto de cambio constante, al igualque haré con los efectos gráficos. Espero conseguir un efecto parecido a cuando estamosmareados, que no es algo constante sino que a veces se nos va más la cabeza, como si el

99

Imagen 45: Audio groups de mi audio mixer

mareo se fuera haciendo más fuerte en algunos momentos. Así pues si tenemos la vida al66%, el sonido iría alternando entre los efectos para el 75% y 50%. Por lo que necesito 5estados de sonido: 0, 25, 50, 75 y 100 para cubrir los 4 estados de salud que tiene el juego.

Lo del menú de pausa con el corte de altas frecuencias lo hacen en el tutorial de Unity[7] y me parece muy buena idea. No quitas el sonido al juego (al estar pausado seguramenteno haya efectos de sonido al no moverse nada), y la música se sigue oyendo, pero como sihubieras cerrado una puerta, que no es solo una reducción de sonido, sino que los agudosdesaparecen, los medios casi también y solo se escucha un poco de los bajos, parecido a estarfuera de una discoteca. Me pareció buen efecto para el menú de pausa, donde sigues en eljuego pero no jugando, es como cerrar una puerta al juego, pero no te has ido de esa casa.Este efecto lo coloco en el master, y no me hace falta usar send y recieve ya que va a afectar atodos los sonidos.

Todo esto lo quería hacer con snapshots. Tendría una para cada estado sonoro (100, 75,50...) y otras dos para los casos de interrupción y pausa. En cada snapshot están los valoresque necesito: volumen, pitch, nivel de send a eco, el recorte por frecuencias, etc. La idea eshacer transiciones largas (10 segundos) entre los dos extremos del estado de salud (entre 100y 75 por ejemplo) y transiciones rápidas (de 0.1 segundos por ejemplo) para pasar a lossnapshots de interrupción o pausa.

El problema es que no funciona. Bueno, funciona, pero raro. Porque los snapshotscambian todos los parámetros. Entonces al hacer una interrupción, a lo mejor el pitch estaba a92 (un valor entre 90 y 100 es normal cuando estamos entre los snapshots de 100 y 75), y alir a Interrupción se pone al 100, pero es normal en la interrupción, el problema es al volver dela interrupción, tengo que volver a 100 o a 75, en cuyo caso sería poner un pitch de 90 o 100,si paso de 92 a 100 de forma inmediata, aunque sea con una interrupción de por medio senota mucho el cambio de tono. Y si no cambio rápido de interrupción a normal, sino que voylento para que no se note esa transición el volumen también irá lento y tardaré 10 segundosen volver a subir el volumen, inaceptable.

Así que he cambiado un poco la forma de plantearlo, he dejado los snapshots solo paralos estados de juego normal (100, 75, 50...) y los de interrupción y pausa ya no lo hago comosnapshot, sino desde código, exponiendo ciertos parámetros. En un mixer se pueden exponerciertos valores, de los groups, efectos, de lo que sea, tenemos que exponer el parámetroexplícitamente y darle un nombre, de forma muy parecida a como se hace en Mecanim. Perotenemos que tener en cuenta que una vez que modificamos un parámetro expuesto porcódigo, deja de formar parte del snapshot y ya no hará caso a los cambios de snapshot (hastaque lo liberemos).

Así que expongo 4 parámetros, por un lado el volumen de los canales de música, fx yreverb. Y el cuarto es el nivel de corte del filtro de paso bajo. Así cuando hay una interrupciónpaso el volumen de los 3 primeros de 0db (volumen “a tope”) a -80 db (silenciado). Y a lainversa cuando la interrupción acaba. De normal la frecuencia de corte del filtro de paso bajoes de 22000 HZ (es decir no corta nada que oigamos los humanos), y al pausar, cambio porcódigo ese valor a 250 HZ, con lo que se corta todo sonido más agudo que esa frecuencia.

De esta forma cuando vamos a una interrupción, la transición entre estados sigue sucurso y al volver de la interrupción estamos en los mismos valores o muy cercanos de antes deirnos y no notamos nada raro.

8.5.3 Efectos

Casi todos los elementos que estaban en la versión Pro de Unity 4 han pasado a laPersonal en Unity 5. Entre ellos: Efectos de post-proceso, video texturas y light probes,además mejorados.

100

Cambia un poco la forma de usarlos, pero muy poco. Los efectos de imagen, vistos porencima parecen los mismos y con los mismos parámetros que en la 4pro, lo único es que ahoraestán en un namespace distinto, por lo que tendremos que añadir un using o más calificadorescuando lo usemos en código. Las demos los usan mucho, a veces se pasan con el Depth ofField, que tiene poco tamaño focal, y se ve todo borroso por todos lados. Son muyinteresantes, muchas veces son cosas que no piden mucho rendimiento de comer, al hacersesobre la imagen final, y mejoran mucho la calidad gráfica.

El video como textura está muy bien, tanto para reproducir vídeos prefabricados, en planintro, como para algunos efectos chulos. Por ejemplo la mayoría de juegos de guerra cuandotienen grandes escenas al fondo, explosiones, inundaciones... son vídeos, incluso los soldadosde fondo, cuando vemos muchos son un video proyectado sobre cuadrados planos. Cambia unpoco la forma de usarlo, tampoco mucho, y me ha parecido más fácil la forma de importarlos,casi funciona solo. Aunque me ha dado problemas en el proyecto actualizado de 4pro a 5, hetenido que reimportar cosas para que funcionase.

Los light probes casi no he trabajado con ellos. Son bolitas que pones por el suelo, y secalcula para ellos en pre-cómputo la iluminación en ellas a alta calidad y luego se usan paracalcular la iluminación de objetos móviles (como personajes) interpolando entre la iluminaciónde algunas de esas esferas. La novedad, además de estar en la versión gratuita es que ahorapueden funcionar en HDR. Y además al crear elementos estáticos, como escenario, Unitycoloca probes de forma automática, por lo que puedes beneficiarte de ellos sin tener nada quehacer. Solo debes preocuparte si deseas mayor resolución en algún punto en concreto.

8.5.4 Otros

Con Unity 5 además vienen ejemplos usando Mecanim (los personajes de ejemplo deUnity 4 no lo usaban) y han añadido bastantes cosas a este sistema, por lo que utilizarlo escasi obligatorio, la diferencia en la calidad de las animaciones finales en muy grande.

La UI también cambia completamente, aunque también han añadido la nueva UI a laversión 4 de Unity en sus versiones más altas, el cambio respecto a la anterior es muy grande,la nueva permite la interacción de forma mucho más sencilla, se maqueta de forma similar acss y se puede animar con una maquina de estados de mecanim.

Aún así mecanim tiene algunos problemas, a veces no ejecuta los eventos de animaciónde las animaciones, sigo sin saber por qué, algo muy difícil de detectar, y a lo que he intentadodar solución haciendo algunas cosas de otra forma.

El editor es ahora de 64 bits, lo que en teoría mejora el rendimiento en las cpumodernas. Además el editor tiene compatibilidad nativa con Visual Studio, ya no se dependede Monodevelop para la edición de código, aunque si para la compilación, ya que el código c#corre sobre Mono. También se ha iniciado el soporte de compilación directa a c++ con IL2CPPde momento solo disponible para IOS, pero prometen que estará disponible para lascompilaciones de PC pronto.

Tiene integración con el formato de creación de árboles Speedtree, aunque la velocidadno es su principal característica, los árboles Koreanos que utilicé estaban hechos conSpeedtree y tenían bastante mal rendimiento y la poca efectividad de los Speedtrees en Unity5 es un tema recurrente en los foros de Unity.

101

8.6 Escenario

8.6.1 Skybox

En la primera versión del juego el Skybox fue uno de un pack de la asset store llamadoSkybox Volume 2. Así que fue usarlo directamente y ya está.

En la versión final quería darle algo más de encanto al Skybox, una de las primeras ideasfue poner el cubemap al revés. Es decir que el cielo fuera suelo y el suelo fuera el cielo,montañas por encima de la cabeza y nubes bajo tus pies. Así además me serviría como primerreferente de que la dirección de la gravedad en un mundo imaginario no tiene por que ser lanormal. Pero no funcionaba, el fondo llamaba demasiado la atención, y parecía completamentedesconectado del escenario que vamos pisando. Daba la sensación de que el escenario estabaflotando dentro del skybox, algo que es cierto pero que no debería notarse tanto.

Entonces comencé la búsqueda de skyboxes por Internet, buscando alguno que pudieramodificar para darle un estilo interesante y que pegase con el estilo visual por el que quierollevar al juego. Encontré uno tipo fantasía, pero sin pasarse, cielo azul, montañas, y la luna dedía. Está hecho por “The Mighty Pete”, estaba distribuido bajo licencia GNU GPL 2, así quepuedo usarlo, hacerle perrerías, etc, lo que quería... salvo una pequeña restricción que hace yque me ha parecido muy graciosa:

“No tienes permiso para convertir este Skybox en un tipo con pérdida como jpg. Losiento, pero si he esperado 4 días a que se renderizase, puedes poner archivos más grandes ylimpios. Además solo salva espacio en disco, en memoria ocupa lo mismo y es más lento paraconvertir para el motor del juego.”

Así que respetaré su voluntad, voy a cambiar su imagen, pero mantendré en formatotarga para que no se enfade. Para entender algunos problemas que he tenido hay queentender el concepto de cubemap que se usa para el skybox. Son 6 texturas que hacen lasparedes de un cubo desde dentro, y encajan perfectamente. Aunque tradicionalmente semuestran como 1 imagen plana, como si fuera uno de estos recortables de figuras geométricasque hacíamos de pequeños. Así que el skybox original es algo así:

Una vez que he juntado todo en una imagen, me pongo a hacer pruebas de posibles

102

Imagen 46: Skybox antes de los efectos

tratamientos gráficos. Aunque photoshop sea el gran programa de retoque fotográfico delmundo, para estas cosas prefiero usar The Gimp, ya que tiene algunos efectos y plugins muyinteresantes y con más posibilidades que los que trae por defecto photoshop, además como sepueden programar en Phyton, es fácil encontrar packs con auténticas maravillas de lacomunidad. Aunque creo que casi todo lo que he hecho es con el plugin Gimpressionist, quepermite efecto muy curiosos. Me quedé con los que más me gustaron y como no me decidíapor un estilo u otro publiqué en facebook y el blog [4] la siguiente imagen para pedir consejo.

El resultado fue que ganó la 5 seguida por la 2. Y un compañero me sugirió que quedaríamuy bien la 2 con una leve animación. Así que pensé cómo podría hacerlo. O bien conseguíadar el efecto al cubemap en gpu con un render to texture, o bien tenía muchos cubemaps e ibacambiando de uno a otro. Tenía preocupación por el impacto en rendimiento de ambas cosas.Por un lado el proceso de 6 imágenes de 512x512 en gpu (y que las uniones entre ellasqueden bien, no se pueden tratar por separado) y por el otro la memoria que se puedenecesitar. Con querer una animación remotamente fluida, de 2 segundos, a 15fps, serían 30cubemaps, y cada uno son unos 6 megas, me iría a unos 180 megas de memoria de vídeo solopara el fondo. Lo cual en un pc gamer es una chorrada, pero en algunos entornos puede tirarabajo el juego. De todas formas no encontré nada hecho para gpu, ni una forma sencilla dehacerlo, miré el código fuente de Gimp, pero implementar eso en GPU es casi un proyectoentero, al menos una práctica. Y aún haciéndolo estático, el problema de los bordes entrecaras en la versión modificada eran lo suficientemente gordos como para llevarme unascuantas horas y si tenía que repetir eso 30 veces para la animación (además al azar, no sepuede controlar mucho la generación), el tiempo para el fondo se me iba de las manos, así queesa bonita idea se ha caído por ahora.

El efecto número 5, que es como si estuviera hecho con palillos de colores, no funcionababien en el juego, los palillos eran demasiado grandes y parecía que el fondo estaba demasiadocerca, además hacer el empalme de esos palillos grandes en diferentes direcciones era jodido.Por otro lado, el 2, el de tipo Van Gogh tiene esos remolinos que van siguiendo las pinceladas,y que hace que si no se siguen esas figuras de una cara a otra se note mucho el corte. Es muydifícil de encajar. Así que lo siento por los que votaron, pero pasé a usar el tipo 3, que tiene lasformas más pequeñas que el tipo 5, y no tiene grandes formas que unir, aunque si unadirección de pintado.

103

Imagen 47: Distintos estilos aplicados al Skybox

Lo que hice fue cuadriplicar cada tapa, es decir tener 4 techos y 4 suelos, y poner cadauno en su sitio para que las transiciones entre cada pared y su suelo y techo fueran tenidas encuenta por el algoritmo de pintado. Tras eso “solo” tenía que unir los 4 techos y los 4 suelos enuno de cada. Y lo hice por triángulos, se nota un poco en la dirección de las pintadas en eltecho, pero no se nota una línea clara de pegado cutre, aunque no lo haya hecho así, elresultado final es como si hubiera cambiado el desarrollo del prisma al siguiente.

Posteriormente retoqué el color. Si el skybox representa algo muy lejano no deberíaverse el color muy vivo. Tal vez el cielo sí, pero las montañas deberían tener un color con tonomás azulado para que parezcan más lejanas.

8.6.2 Escenario mediante terrain

En la versión del juego presentada en Tecnología del juego los escenarios eran en sumayoría distintos terrenos de los que trae Unity. Pero tuve varios errores.

El escenario que diseñé tenía montañas para limitar el camino a seguir, incluso en unprincipio pretendí que los precipicios fueran parte del terreno muy hondos, pero no funcionó.Para esto hay que entender cómo funciona un terreno. Es como un campo de alturas. Es decirun plano, y cada punto del plano tiene una altura marcada. Así que es imposible tener unapared completamente plana en vertical, siempre va a haber un poco de pendiente. Ya que parahacer una pared completamente vertical necesitaríamos que un punto tuviera al menos 2alturas distintas. La del mínimo y la del máximo. Y eso no se puede hacer en un terreno,incluso podríamos entrar en un debate matemático sobre si eso haría que el terreno dejase deser una función. El caso es que puedes hacer que un punto el terreno tenga altura 0, y en el deal lado tenga altura 3000, pero eso significa que todos los puntos intermedios en un sistemacontinuo existen, y por Bolzano al final si nuestro héroe se esfuerza, al tener desnivel, a basede saltos puede ir escalando. Y en el caso de abismo, puedes ir cayendo poco a poco por lapared y no se detecta la caída.

A los fosos le podía dar la solución de no ponerles fondo, hacer que fueran agujeros alvacío, y para evitar que el jugador pudiera escalar podía poner paredes invisibles, planos concollider pero sin malla que renderizar. Esto unido a la restricción de diseño que imponen losterrenos y a algunos problemas encontrados para detectar colisiones a gran velocidad contraterrenos (que son un plano al fin y al cabo) me llevaron a tomar la decisión de hacer losescenarios exteriores modelados también. En la decisión influyó que la demo de Super-Character Controller se usaban escenarios modelados y funcionaba muy bien. Temía que al

104

Imagen 48: Skybox usado finalmente (sin recortar)

necesitar colliders de tipo malla hubiera problemas de rendimiento.

8.6.3 Escenarios modelados

Las ventajas de modelar los escenarios son que puedo hacer formas más complejas,doble nivel de suelo, paredes verticales, zonas con techo, y curvas, muchas curvas que enterrenos es complicado de conseguir.

Necesito esas curvas porque quiero usar formas inspiradas en Gaudí. Lo primero que heintentado es tener unas paredes curvas en la primera parte de la primera pantalla, y eso meha permitido aprender a usar NURBS para el modelado 3D.

En la primera parte las paredes tienen una doble curvatura, una en su borde superior,que se hará más bajo o más algo dependiendo de la zona y con curva suave. Y la segundasobre el plano, ya que esta habitación tiene silueta de balón de rugby o de barca, más ancha elmedio y acabando en punta. Al tener dos curvaturas es algo más complicado que solo crear unplano NURBS a medida.

Lo he hecho con una técnica que me parece más sencilla y potente. Crear varias curvasplanas y unirlas mediante un NURBS (un spline al final), al que podré ajustar el número depolígonos para la aproximación en 2 ejes. El primer paso es dibujar una curva plana, para ellouso una curva NURBS con vértices de control. Es parecido a una curva de Bezier, pero aquí noseñalamos puntos exactos por los que tiene que pasar la curva y sus pendientes, sino puntosde control y una curva se genera automáticamente para pasar cerca (no por encima) de esospuntos, pero siendo una curva suave.

Después clono esta curva y deformo las copias, escalando para hacer que la curva sea allímás alta o baja, y las coloco donde quiero para obtener esa forma de barca, o al menos una delas paredes. Espejo estas curvas para tener la pared del otro lado idéntica, y añado una nuevacurva para poder cerrar la curva al inicio.

Entonces creo una superficie NURBS usando la herramienta U Loft Surface. Solo hay queelegir cada curva en orden y las va uniendo mediante una superficie. Lo bueno es que estorecoge las curvas como puntos de control, pero no como malla definitiva, entonces podemoscontrolar la malla que aproxima la superficie deseada de distintas formas y varias de ellasparamétricas. La que me hace por defecto tenía más de 2000 polígonos, así que cambié asuperficie regular, y puedo elegir por parámetros u y v el número de polígonos en cada eje.Elegí 6 divisiones en vertical y 22 para todo el recorrido de la pared. Total: algo menos de 300polígonos. Y sin embargo tiene bastante buena pinta. Hay que tener en cuenta que estabausando terrenos de 250.000 polígonos, así que aunque necesite varias zonas de unos pocosmiles de polígonos para hacerlo modelado, tendrá mejor rendimiento.

105

Imagen 49: Modelo hecho con NURBS y multimaterial

Me interesa poder crear los escenarios como una o varias piezas que pueda escalar ycolocar en Unity. Y cada una de esas piezas puede estar formada por varios objetos. En el casoque vimos de la primera parte de la primera pantalla, el suelo, los obstáculos y las paredes. Ypoder elegir libremente el material de cada uno de estos elementos por separado. Incluso elmapeado de texturas.

Lo primero es dividir el objeto dando identificadores de material a cada zona quequeramos. Para ello tenemos que tener todo como un solo objeto y en editable poly. Una vezque elegimos un polígono (o varios) o un subelemento podemos darle un id de material. Yo hedividido el objeto en 6. El primero la parte no visible del cubo que hace de suelo (lados y partede abajo) para ponerla en negro. Después el plano que hace de suelo. Estos con selección porpolígonos. Ya mediante selección por elementos doy identificadores al NURBS de las paredes ya los 3 obstáculos. Podría haber dado el mismo id a los 3 obstáculos, ya que seguramentelleven el mismo material, pero he preferido separarlos para poder elegir la proyección de latextura de cada uno por separado.

Después aplico el modificador unwrap UVW, y eligiendo la selección por caras hay unacajita donde puedo decir que me seleccione elementos por su id de material y seleccionar eltipo de proyección de cada uno, su unwrap y ver como lo colocamos para las texturas. Para elsuelo con una proyección planar va perfecto (al fin y al cabo es un plano), para el resto de lacaja suelo casi que da igual la proyección porque va a ir en un color negro sin textura. Para losobstáculos el mapeado de tipo caja va perfecto. Por último para el NURBS, aunque deja usarmapeado por splines, no si eso lo soporta Unity y en cualquier caso será más costoso que usarotro tipo, así que para esta forma en concreto me parece apropiado usar cilíndrico. Una vezque está el gizmo del cilindro, lo giro, indica con una arista verde donde se empalmará latextura aplanada. Aprovechando que el NURBS tiene una zona abierta, giro el cilindro para queel empalme de textura pille fuera del modelo.

De cada mapping se puede abrir la ventana de UVW y mover cada aplanamiento,ponerlos todos en una textura, o ir renderizando para cada objeto una por separado, segúnqueramos hacerlo. En este caso por separado. Se puede crear un material de tipo multi, con 6sub-materiales. Le doy a cada uno un color plano para asignar al modelo y ver que funcionabien la separación. A partir de aquí podríamos modificar cada submaterial, poner texturas,bump-mapping o lo que sea. No necesariamente en 3DS, puedo usar materiales de Unity oshaders para hacer efectos como cristal con refracción.

Una de las inspiraciones que quería usar en el juego era Gaudí y en concreto una seccióndel Parque Güell. Tiene una galería donde la pared está inclinada, enfrentada a una columnascon el mismo ángulo. Visto a lo largo de la galería tiene un poco forma de oreja. Así queaprovechando la práctica creando formas con NURBS (realmente comencé a usar esas formaspara poder hacer cosas así). Comienzo haciendo la forma de oreja sobre el plano con unNURBS plano con vértices de control. Esta vez no hice solo la curva que ve el jugador, sino quelo cerré para que se genere un artefacto sólido más que una superficie. Después se vaclonando la curva plana por el terreno para generar la curva del pasillo en la superficie y seune todo mediante un Loft U.

La gran duda de todo el modelado era cómo hacer las columnas. Comencé haciendo elNURBS sin la parte de las columnas, poniendo cilindros, y sesgándolos (modificador skew), ydespués uniendo vértice a vértice la parte de arriba de la columna con el resto del tejadillo delNURBS. Pero se notaba un huevo que era un empalme, la iluminación se hacía muy diferente.

Así que el siguiente intento fue hacer que el NURBS llegase hasta el suelo por la parte delas columnas como una segunda pared, e ir usando esos polígonos de pared para generarcolumnas. Es un trabajo de chinos, pero queda bien. Para generar cada columna de plantahexagonal necesito dos pasos. Tengo dos planos, así que por delante y por detrás ya deberíaestar, me falta poder cerrar a cada lado. Por la cantidad de polígonos de la aproximación de lasuperficie tengo 1 tira vertical que será columna y la siguiente vacío. Así que puedo usar lasparte de pared que serán hueco para cerrar la columna por ese lado. Así que tengo que romperla pared por ahí (break de vértices), y reunirlos (weld) cada uno por su lado, después juntoaristas de las paredes de delante y detrás para crear un lado de la columna. La otra pared la

106

genero duplicando vértices y creando polígonos nuevos, eligiendo vértice a vértice las esquinasdel nuevo polígono. Ya solo queda ajustar todos los lados de la columna para que tenga radiodeseado. Y repetir con otras 10+ columnas.

Después he adaptado el cubo que hace de suelo, metiendo cortes y haciendo que siga lalínea de columnas para que el jugador se caiga si sale del pasillo de columnas. Y por último unproceso de mejora del número de polígonos. EL NURBS está aproximado regularmente, así quetengo el mismo número de polígonos donde se ve, que por la parte de atrás que no meinteresa. Por eso me puse a unir vértices, fusionar aristas... hasta dejar la parte de atrás delmodelo con muy pocos polígonos. Así ahorré unos 400 polígonos, dejando el total del NURBSen 960, y el suelo son 24 más. Son más que los de las partes anteriores del escenario, peroaún así es un número muy aceptable, sobre todo por el juego con la iluminación que me va adar esta zona.

El resto de zonas de escenario tienen menos complicación, la mayor parte son cajasmodificadas vértice a vértice para dar el aspecto deseado. Las zonas de plataformas se hanhecho repitiendo un elemento sencillo en forma de gema con materiales distintos en cadarepetición.

Las zonas a cielo cerrado se hacen con las paredes como cubos y no como planos, paraque no podamos atravesar si caemos a mucha velocidad, un problema que se puede dar conplanos teniendo colisiones discretas.

8.6.4 Limites de los escenarios

Hay varios problemas relacionados con el borde del escenario. Uno es que la cámara al irsiempre por detrás del personaje podría atravesar parte del escenario si el jugador llega atocar el borde del escenario. Si hago que la ruta de la cámara no llegue tan lejos, entonces elpersonaje podrá atravesar la cámara y podremos ver medio personaje.

La solución a este problema ha sido colocar elementos invisibles en lugares estratégicos.No se notan, no es como una pared invisible que te impide ir más allá cuando el escenarioparece abierto. Aquí simplemente se desplaza un poco el límite del escenario, el jugador creeque ya está chocando con el límite, pero no atraviesa la cámara.

Otro problema es el de la detección de caída del personaje. Parece algo trivial, pero no loes. Usando terrenos como en la primera versión la solución que tomé fue tomar la caída comouna diferencia de altura respecto al último suelo pisado. Así que se debía ir controlando laaltura del suelo cuando estábamos sobre un terreno y comprobar si estábamos muy pordebajo de esa altura cuando estábamos en el aire. Esta solución tiene algunos problemas, laaltura es única, por lo que no podemos hacer que el avance natural del juego conlleve un gransalto hacia abajo. Y si alguien consiguiera caer poco a poco por una ladera de un precipicio nose detectaría la caída.

En la versión de Unity 5 del juego las caídas se detectan con unos box collider invisiblescolocados debajo del escenario. Cada pieza de escenario lleva su detector de caídas y asípodemos detectar en qué parte nos hemos caído para hacer el respawn.

Es un problema mayor cuando hay cambio de gravedad en la segunda pantalla. Ahora yano podemos caer solo en una dirección sino en 4. Por ello se usan 4 box collider que forman unprisma sin tapas. De esta forma según qué box collider detecte la caída sabremos qué puntode respawn dar.

El respawn es un problema asociado con los límites del escenario. En las primerasversiones de la práctica de tecnología de juegos se intentó dar una solución global yautomática, reaparecer en el último sitio por el que hubieras andado antes de caerte. Pero estono era tan fácil, saber cual es el último punto no era trivial. Intenté hacerlo lanzando rayoshacia abajo, a veces aparecíamos demasiado al borde y volvíamos a caer. La noción deaparecer un poco más atrás es muy buena pero no es fácil de implementar, en la dirección de

107

la cámara podría no haber más terreno, he llegado a tener bucles infinitos, o podría ser unobstáculo de poca longitud y caer al vacío otra vez al intentar echar el punto de respawn haciaatrás.

La solución tomada fue tener puntos fijos de respawn y según donde caigamos y cuál dedonde vengamos decidir cuál usar. Por ejemplo si estamos entre los trozos de escenario 1 y 2cuando caemos volveremos al 1 si veníamos del 1 y volveremos al 2 si veíamos del dos,intentando así que el respawn no nos adelante en nuestra dirección de movimiento.

En la versión final de Unity 5 hay 4 puntos de respawn por escenario, uno para cadadirección de la gravedad y se hace el respawn allí sin mirar de donde veníamos, ya quesuponemos que el jugador siempre va a avanzar y no a intentar hacer la pantalla al revés.

8.7 Efectos

En esta sección voy a aglutinar todos los efectos realizados para dar un mejor aspectoestético y dar ambientación al juego. Entre ellos los efectos sobre imagen, las interrupciones,los efectos de partículas...

8.7.1 Efectos de imagen

Uno de los aspectos más importantes de la ambientación es el uso de efectos de imagencuando el personaje está bajo de vida para mostrar el efecto que le hace el veneno y dificultarla jugabilidad. Para poder usar estos efectos en la primera versión hubo que utilizar la versiónpro de Unity 4.

Los efectos que utilicé fueron: Edge detect, el realidad lo usé para teñir de verde lapantalla en el trozo de escenario que jugamos así; Twirl, para retorcer la imagen en pantalla;Fisheye, hace que el centro de la pantalla se vea hinchado; Contrast Enhance, cambia muchoel contraste de color dando colores más exagerados y Sunshaft que emula que el sol pordetrás de los límites del escenario nos deslumbra.

Al pasar a Unity 5 prescindí de alguno de los efectos y comencé a usar otros. De losnombrados anteriormente quité Fisheye ya que su efecto era el que menos se notaba. Añadíotros efectos que no son distorsiones sino para mejorar la imagen final. Estos son:Tonemapping, usé uno adaptativo, que ajusta el rango de iluminación visible y su escala segúnla iluminación en cada momento; Correción de color por curvas, mejora el color final, y puedohacer colores más vivos e irreales y Antialiasing; intenta evitar los dientes de sierra, he usadovarios, pero todos sobre la imagen final, el que mejor rendimiento tiene es el FXAA3.

Pero hay un problema en el Tonnemapping adaptativo Reinhard implementado en Unity,ante ciertas circunstancias y combinaciones de repente deja la pantalla en negro. Es un fallointolerable con el que he estado intentando lidiar. Se que se lleva especialmente mal con elFXAA3, y suele aparecer a partir de puntos concretos del escenario. Sin embargo no he sidocapaz de evitarlo, y con otros tipos de antialiasing es menos frencuente, pero siempre puedeaparecer. Así que para asegurarme no tener el problema debería prescindir del tonemapping ola solución final, usar uno de pago de la asset store que no de el problema del que viene pordefecto en Unity. He decidido esto, porque había partes del juego que quedaban muy bonitascon el tonemapping adaptativo.

Todos los efectos usados tienen parámetros que se controlan por script para conseguir elefecto buscado, por lo que vamos viendo como los efectos afectan más o menos dependiendodel momento y los máximos que dan depende del estado de salud del protagonista.

108

Se han usado más efectos para hacer las interrupciones pero eso lo voy a comentar en lasiguiente sección.

8.7.2 Interrupciones

Las interrupciones muestran imágenes del subconsciente del héroe como si fueran unainterferencia de su cerebro, mostrando que algo no funciona bien, por eso son más frecuentescuanto más nos afecte el veneno.

En la primera versión esto se hacía con un plano en el escenario muy lejano con supropia cámara que mostraba la imagen de la interrupción. Sobre esa cámara se usaba el efectode ruido de grano que traía Unity 4. Al cambiar a Unity 5 este efecto dejo de funcionar bien ypasé a utilizar el efecto Noise and grain, similar. Además vi otra forma de hacerlo, en lugar detener ese sitio al margen para la imagen la empecé a mostrar usando el efecto screen overlayque directamente muestra una imagen sobre la pantalla, si la imagen es lo suficientementegrande y opaca tapa la pantalla entera que es lo que se buscaba.

Las interrupciones se muestran al azar, se encarga el control central de ello, y tiene unarray de probabilidades según el estado de salud. Durante la interrupción, de 0.6 segundos, eljuego continúa, la acción no se para, por lo que podemos seguir jugando ese tiempo, pero aciegas.

8.7.3 Sistemas de partículas

En el juego se han usado varios sistemas de partículas. En la primera versión el ataquedel héroe se hacía con un efecto de partículas, para simular fuego, por lo que esas partículastenían que detectar colisiones para saber si golpeaban al enemigo. Los propios enemigostenían otros sistemas de partículas decorativos y uno especial para cuando explotaban. En laescena de creación del enemigo final también había un sistema de partículas mientras elmonstruo final iba creciendo. Se usaban también efectos de partículas decorativos, unasburbujas al principio, una lluvia de sangre después y unas partículas doradas que salían delsuelo en la zona verde.

Estos efectos decorativos causaban confusión en los jugadores, ya que pensaban quetenían algún efecto, bueno o malo. Por eso en la siguiente versión decidí reducir el uso de estetipo de sistemas de partículas.

En la versión final del juego hay sistemas de partículas en el veneno igualmente, hayefectos diferentes para la muerte del veneno y del ciego. Se utilizan en el respawn y en elcambio de gravedad hay varios combinados.

Algunos de los efectos son configurados a mano, otros son modificaciones de los quevienen en los ejemplos de Unity 5 y otros son efectos modificados de algunos paquetesofrecidos en la asset store.

8.7.4 Efecto Hitchcock

Estaba pensando en cómo haría una cinemática en la que se viera cómo el veneno afectaal protagonista. Y cómo luego haría la transición entre el subconsciente del héroe y el mundoreal. Fue aquí cuando en mi cabeza quedaba muy bien que ante la acción del veneno se vieraun efecto Hitchcock.

Este efecto, al que le doy ese nombre, y mucha gente lo llama efecto vértigo, por su uso

109

en la película homónima (además de en muchas otras), según wikipedia se llama travellingcompensado y los ingleses lo suelen llamar dollyzoom [83], lo cual como nombre de técnicasea seguramente el más acertado.

En el mundo del cine este efecto se hace desplazando la cámara hacia delante mientrasse hace el zoom hacia fuera, o al revés, moverse hacia atrás mientras se aumenta el zoom. Lode mover la cámara hacia delante y hacia atrás para que no quede movido es mejor hacerlocon un dolly, y hacer el zoom a mano suave pero continuo tiene su miga, pero se hace todocon una cámara cualquiera. De hecho alguien con una cámara normal y algo de mano subido aun patinete puede lograr un efecto casi profesional.

En el mundo virtual es todavía más sencillo de hacer. La cámara la podemos mover, yhacer un travelling es muy sencillo, estamos acostumbrados a mover objetos, animarlosmediante distintas técnicas, y no nos hace falta un dolly ni nada que se le parezca. Y por otrolado aplicar zoom tampoco es difícil, el parámetro FOV (field of view) que tienen las cámarasvirtuales que se usan en los motores 3D nos sirve. Y también podemos animar este cambio deFOV, igual que animamos la mayor parte de cosas en gráficos. Y lo bueno es que elmovimiento es tan suave como queramos, no tiene porqué ser lineal, puede ser cuadrático, ouna curva personalizada, que el efecto empiece suave, de un tirón bestia y luego vuelva aacabar suave. A mano es muy difícil hacer algo así, virtualmente es elegir la curva adecuada.

8.7.5 Efecto túnel

Este efecto fue un trabajo de investigación para la asignatura de Rendering Avanzado,por lo que voy a resumir su implementación y emplazo al lector a la memoria del proyecto deinvestigación [3] si desea profundizar más.

Primero hice la geometría del túnel, comprando una librería que ayudó en el trabajo. Lalibrería que uso se llama Tuberenderer [80], es capaz de renderizar cilindros dándole lospuntos por los que tiene que pasar el cilindro y la anchura en cada punto. Además vienenejemplos para gestionar varios cilindros. Con algo de configuración conseguí tener renderizadopor la parte interna del cilindro, que no dibuje las tapas, mapeado UV bien hecho, todo deforma procedural.

La idea era generar trozos de cilindro e irlos encadenando para formar el túnel, de formaque los que quedasen detrás de la cámara se regenerasen al final de los trozos existentes paralograr un efecto de túnel infinito. Además de variar aleatoriamente el radio del cilindro parahacer el túnel más dinámico y que se pareciera más al túnel de Coraline, la dirección de loscilindros debía variar para que no se vea como van apareciendo nuevos trozos en el horizonte.Así normalmente los giros que va haciendo el túnel no nos permiten ver más allá del finalgenerado.

Comencé intentando mover los trozos de cilindro hacia la cámara, encadenando losmovimientos dentro del cilindro y entre cilindros. Y funcionaba relativamente bien en recto,pero en cuanto intentaba poner curvas relativamente fuertes para tapar el horizonte, noconseguía que el túnel pasara por la cámara. Así que cambié la estrategia y finalmente es lacámara la que se mueve por dentro de los cilindros, en la dirección que marque el trozo decilindro actual. Así la cámara se mueve según la velocidad marcada interpolando entre puntosde un cilindro y saltando de un cilindro al siguiente cuando se acaba por el que iba.

Tanto las direcciones como los radios de los cilindros se generan aleatoriamente, pero conla filosofía de cambios pequeños locales de los mapas de Perlin, pero en lugar de estar pre-calculados, se van tomando pequeños movimientos aleatorios desde el punto anterior,controlando el gradiente local y los máximos y mínimos globales.

Tuve un problema en los empalmes, ya que a veces se veía la parte de fuera y se notabamucho. La solución que mejor funcionó fue hacer cada inicio de trozo nuevo un poco másancho que el anterior. Esto hace que recorrido en el sentido que se recorre no se noten loscortes, aunque si lo recorriéramos en sentido contrario se notaría mucho. Aún así algo del

110

problema queda si la cámara es muy poco cuadrada (por ejemplo 16:9) ya que por los lados seve más de lo que estaba planeado.

Para hacer los efectos tuve que programar mis primeros shaders en Unity, que añade unacapa de abstracción bastante grande. Dentro de cada shader de Unity, además de poderespecificar una serie de shaders de vértices o fragmentos, podemos configurar las pasadas,opciones de transparencia, niebla, modos de filtrado de las texturas, realizar renderizadosmultipasada con varios shaders en cada pasada... por lo que supone al configuración delrender completo y puede ser complejo encajar todas las piezas: propiedades que se darán alshader en el editor, uniforms, atributos de entrada, pasadas... Y tuve algunos problemas conesta capa de Unity.

No deja declarar arrays globales en los shaders. Lo cual me dio problemas a la hora deintentar dar colores proceduralmente en algunos efectos. Tampoco deja declarar estructuraswhile y for si no es capaz de desenrollar los bucles. Esto hizo que no pudiera hacer muchascosas como tenía pensadas, aunque finalmente conseguí los efectos de forma bastanteparecida a como quería.

Para la parte del túnel de Coraline [26]: Quería que el túnel tuviera tonos azules,morados, violetas, como en la película. El pintado de colores fue procedural. Se asignancolores a una cierta distancia y se repiten. Una operación módulo por centenas. E interpoloentre los dos colores más cercanos según donde nos encontremos. Después añadí ruidomediante textura para dar más granularidad al túnel, aunque no se consigue del todo eseefecto de piedra fluorescente que parece en el original.

Después quise añadir los haces de luz. En la película de Coraline el túnel parece emitir luzy tiene anillos de luz que van recorriendo el túnel. Trasteé con el tiempo de simulación dentrodel shader, es decir pasar como parámetro de la cpu a la gráfica cuánto tiempo lleva corriendoel programa, cosa que Unity facilita; y con la distancia en coordenadas sin transformar ytransformadas para intentar el efecto. Quería que los haces de luz fuera hacia el fondo y másrápido que la cámara, que nos fueran adelantando, pero no conseguí que quedasenequidistantes y efectivamente adelantasen a la cámara. Si conseguía que se movieran por eltúnel pero no más rápido que la cámara. Así que les cambié en sentido y ahora van hacia lacámara, aunque bastante despacito, sí se aprecia que los haces de luz se mueven.

Para el efecto de 2001 [20]: usé post proceso de imagen y efectos de partículas. Con unefecto de ojo de pez muy distorsionado en solo una de las direcciones consigo que el túnel seacasi como un desfiladero, como el efecto de la película. Aunque solo hasta que se acerca a lacámara, al hacerlo en espacio de pantalla, al final se nota la curvatura del truco.

He tenido que cambiar bastante la forma de colorear de Coraline, para añadir máscolores, que no fueran iguales en izquierda y derecha y que no cambiase el color a la vez enambos lados, para que se pareciera más al efecto buscado. Y que los colores no fueran tanprevisibles en su orden, aunque esto provoca que a veces haya saltos bruscos de color, y nosea interpolado suave. Aunque no importa, ya que la película también lo hace más bien brusco,siempre de toda una mitad a la vez como yo.

Por otro lado he hecho un truco con la distancia de las coordenadas de pantalla en elshader de fragmentos para conseguir una animación que oscurezca los bordes de la imagen.No me gustaba que el color llegase hasta el final de la pantalla, y el efecto hace que el negrose coma parte de la imagen de forma radial, más como el efecto buscado, y además ayuda aocultar la curvatura del ojo de pez.

Pero en la escena de 2001, no eran solo colores planos, había efecto de punto de fugasobre luces, y otras tramas de forma regular. Si hubiera hecho las tramas como texturahubiera quedado muy repetitivas y predecibles por lo que no las he incluido, pero si los puntos.He usado un sistema de partículas, y después de jugar un buen rato con los parámetros, elmaterial de las partículas, la textura y demás he conseguido que las particulas añadan unefecto con el que estoy bastante contento. Además activo y desactivo al azar estas partículas,dando una mayor probabilidad a la activación que a la desactivación. Para que las partículas sevieran mejor y funcionasen como puntos de fuga, añadí el efecto de post-proceso de motion

111

blur.

Para la última parte del túnel, la de hipervelocidad tipo Star Wars [23], volví a recurrír alos efectos de post-proceso. Conseguir que puntos se transformen en líneas por la velocidad esbastante sencillo gracias al motion blur. La idea es tener una textura de un campo de estrellasen el túnel, y que en cada frame no se borre y se dibujen en la nueva posición, con lo queveríamos como se mueven las estrellas, sino que se vaya pintando encima, así lo que vemoses la línea que compone la trayectoria de cada estrella. Y así es, lo malo es que al ser un fondocompletamente negro, los puntos blancos pierden color enseguida y quedaban unas líneasgrises que tenía miedo ni se vieran con el proyector en la presentación que debía hacer. Asíque también he añadido un efecto para controlar el contraste y poder corregir de nuevo esosgrises a blancos. Aún así no se podían ajustar bien los dos filtros para conseguir líneas deltodo. Si hay efecto de velocidad, pero no llegan a ser líneas puras.

Pero la mayor gracia del efecto de salto al hiperespacio es precisamente el salto, elmomento en que las estrellas dejan de ser puntos y pasan a ser líneas. Y si tenía estos efectosconstantemente no se vería. Por eso pongo y quito el motion blur al azar con una animaciónrápida para poder tener un efecto similar al buscado.

8.7.6 Estela de la espada

Para el efecto de estela de la espada usé el sistema X-WeaponTrail disponible en la assetstore. Básicamente al arrastrar el asset para que cuelgue de la espada, coloca dos bolas, unaroja y otra azul, y tienes que situar cada una en cada extremo de la espada y él hace el efectode estela con el movimiento de la espada creando un spline que vaya cubriendo el recorrido.Puedes elegir el material de la estela y opciones de generación, aunque con nombre algoconfusos alejados de la naturaleza matemática del spline. Por ejemplo “Max frame” en realidadparece tener más que ver con el número de puntos de control del spline. Pero con los valorespor defecto o toqueteando un poco tienes una estela funcional instantánea.

Combiné texturas en el material, usando algunas que vienen en el mismo paquete deltrail, una tiene una esquina blanca y el resto transparente, ayuda a crear el efecto más blancoen el extremo y menos cerca de la base, en cierta forma el blanco representa la velocidad de laespada. Y luego para rellenar el resto una textura de rayos morada que de un poco de aspectomágico al espadazo.

Me encontré el primer problema, la estela solo se crea en una cara. Es decir si damos elespadazo hacia la derecha de la pantalla veremos bien la estela, si lo damos hacia la izquierdaveremos la cara oculta de la estela, y no veremos más que un bordecito, no la estela completa.Eso hace que el efecto quede raro. Es una cosa habitual en gráficos, los polígonos solo serenderizan por un lado, así que tenía dos opciones. La primera crear un shader para renderizarese material por los dos lados y la segunda duplicar la geometría. Resulta que en Unity salemás rentable renderizar el doble de triángulos a una cara que la cantidad inicial a una. Por esoen su momento dupliqué las mangas y el faldón del personaje para que tuviera parte interna, yaquí he seguido el mismo proceso. Poner una segunda estela, invirtiendo los puntos de control,es decir, dar como principio el punto que se supone que es el final y viceversa. Con eso yatengo una estela por los dos lados y se ve siempre igual.

En la demo que venía con el sistema de trail, había dos efectos de estela, una blancaparecida a la que estaba usando, y otra con un rollo transparente distorsión, donde la estelahacía ver el fondo distorsionado, me gustaba como quedaba. El problema es que al usar elmaterial de ese efecto en mi escena, no funcionaba bien, es un shader que venía con elsistema de trails, pero por alguna razón que se me escapa a mi no me funcionaba como en lademo. Utilicé combinado el efecto de glow del paquete MKGlow para el efecto final de estela.

112

8.8 Otros

8.8.1 Colocar la espada

Parece algo trivial, pero he tenido bastantes problemas colocando la espada en la manodel personaje. En 3DS max se pueden realizar restricciones de asociación, y por lo tanto unir laespada a la palma de la mano para que la espada se mueva según la mano del personaje. PeroUnity no reconoce estas asociaciones.

Intenté colocar la espada como parte del mismo modelo, pero Unity no deja tenergeometría sin un hueso asociado, así que tuve que asociar la espada al hueso de la mano delpersonaje. Pero esto también me daba problemas con el blending de algunas animaciones.

Finalmente aprendí a exponer trozos del esqueleto del personaje, por lo que pude tenerel hueso de la palma de la mano en Unity, en la jerarquía y poder colgar de él la espada.Aunque el objeto de la espada no coincidía en orientación con su transform, por lo que siañadía un collider para detectar colisiones de la espada no quedaba bien orientada y tuve queponer un empty colgando de la espada para poderlo orientar correctamente y al poner elcollider en el empty que coincida con la espada.

8.8.2 Ragdoll

Para la muerte del personaje he querido usar una ragdoll, esto hace que el personajecaiga mediante simulación física y cada muerte sea distinta y dependiendo del entorno, nocomo una animación que siempre es igual.

Unity tiene un asistente para crear ragdoll al que le tenemos que decir las articulacionesdel esqueleto del modelo y unos pocos parámetros de peso y resistencia. Pero el ragdoll haceque el personaje parezca muerto. En algunos tutoriales sugieren tener dos modelos uno que semueva y cambiarlo por el ragdoll cuando tenga que morir. Pero eso no funciona bien. Lo quehice fue activar y desactivar los colliders y algunas de las opciones de los rigidbody que añadeeste asistente, y de esta forma se puede alternar entre el uso normal del personaje y el controlfísico de ragdoll.

Al pasar a Unity 5 y al control con mecanim, tuve que volver a adaptar el manejo de unaragdoll. Ya tuve en su momento problemas con mecanim, porque no me mostraba todos loshuesos del personaje, y descubrí que podía hacer que se mostrasen los que yo quisieraexponiéndolos. Así pude hacer que se vieran las palmas de la mano, para colocar la espada enuna mano y poner un collider en la otra, para que el brazo no atraviese paredes. Siguiendo elmismo procedimiento expuse todas las partes que necesitaba, pelvis, fémures, pantorrillas,tobillos, brazos, antebrazos, cabeza... y monté una ragdoll como había hecho siempre, y... nofunciona.

Pasa algo un poco raro a veces, y es que el personaje queda quieto, con su animación deidle, pero se desplaza un poco, como si se deslizase sobre hielo. Pero por lo demás, da igualcómo configure la ragdoll o cada una de las partes, isKinematic, isTrigger, anular el animator,sigue sin funcionar. Simplemente no se cae al suelo, le coloco código para poder hacer que secaiga al dar a un botón, tal como hacía en Unity 4, y no se cae. Después de darle vueltas eintentar muchas configuraciones, del modelo, en código, en el editor, nada. Lo más queconseguí es que se cayesen los colliders de las partes, pero el cuerpo del personaje noacompañaba. En una de esas caídas me di cuenta del problema. Los transforms expuestos sonde solo lectura, te dan la posición de esa parte del cuerpo, pero no la puedes modificar como sifuera un objeto normal, por eso las propiedades físicas de la ragdoll no hacen nada en este

113

caso.

Miré tutoriales en youtube y a la gente le salía el modelo con toda la jerarquía de huesos.Cuando expones huesos, salen todos al mismo nivel, no como jerarquía, así que vi que no esque los hubieran expuesto, tenía que ser otra cosa. No usaban rig legacy, tenían humanoidigual que yo. Llegué a pensar que era por el modelo en sí, lo mismo por la forma en queestaba hecho el mio es por lo que no funcionaba, era un problema de mi asset. Y aquí estuveapunto de dejarlo. Según estaba dando las últimas vueltas por Unity, mientras pensaba en quetendría que conseguir una animación de muerte y hacerlo como animación y no como Ragdolldi con la clave.

En la parte de rig, hay un checkbox que dice “optimize game objects”, y ¿quién no quiereoptimizaciones? Pues resulta que este era el problema, el no exponer la jerarquía del personajees la optimización, y si se expone, solo en lectura. Si desmarcas ese check ya se puedeacceder a la jerarquía completa desde el inspector y hacer una ragdoll.

Una vez ajustados los colliders que añade la ragdoll, veo que funciona, tengo puesto enun botón para que se muera y en otro para resucitar y cada vez cae en una posición distinta,que es lo que se busca. Pero surgen los problemas. El personaje sigue moviéndose solo, sigueel modo hielo. Después de diversas pruebas veo que deja de hacerlo si dejo desactivada laopción isKinematic en todas las partes de la ragdoll cuando el personaje está vivo. Y entoncessurge otro problema. Con el Kinematic desactivado deja de funcionar ¡la estela de la espada!,sigo sin entender por qué, pero ahora la estela son paredes de unos 10 metros de profundidady queda horrible.

Después de hacer muchas pruebas (pero muchas muchas) encontré un apaño para queno pasase, y es quitar los Kinematics de las partes de la ragdoll, menos del brazo (solo la partesuperior, no el antebrazo) izquierdo, y así parece que entra en el equilibrio por el cual elpersonaje no se mueve solo, como si se lo llevase el viento, y la espada tampoco hace unaestela rara. Bueno, tampoco estoy seguro si ahora la estela no hace un recorrido un pelín raro,pero comparado con la barbaridad anterior, está muy bien.

Hay un paso más de mejora en la ragdoll y es ajustar los joints. Así podemos elegircuales son los ángulos máximos de cada articulaciones, en giro y al doblarse y otras cosascomo la resistencia de rotura. No están mal configurados de inicio, a lo mejor algo laxos conlos giros, y con la resistencia a rotura en infinito. Si vamos a usar mucho ragdolls (porejemplo, en los enemigos que matemos cada 2 por 3) es bueno ajustar todo para evitar que sevean cosas raras de vez en cuando. O también podemos buscar lo contrario, poner valoresbajos a la resistencia a rotura da situaciones bastante graciosas con piernas alargándose por elescenario como si fueran chicle, porque los huesos se rompen, pero la piel se estira, y es muycurioso. En mi caso, como solo puede morir el héroe y no es algo que pase demasiado(espero), y tampoco tengo el suficiente conocimiento de anatomía para hacer maravillas, losajustes que he hecho han sido muy pocos.

8.8.3 Power-up

Al hacer el power up tenía en mente esas pildoritas de vida que dejaban caer algunosenemigos en Megaman, al ser en 3D lo más lógico era pensar en algún tipo de esfera más omenos decorada, pero una esfera son muchos polígonos y aún así vista pequeña se nota queno es perfecta. Así que preferí ir a otro tipo de figura más sencilla y al final me quedé con unapirámide cuadrangular. Son 8 polígonos, 4 triángulos que salen de la cúspide y otros 4 quehacen la base. Muy sencilla.

Quería que tuviera algo de aspecto especial, así que busqué formas de hacer que tuvierauna textura en movimiento. Tras curiosear las substancias, al final las dejé porque parecía quegeneraban texturas proceduralmente pero no eran dinámicas, o no supe hacerlo. Pero vi unefecto de lava en movimiento en la assetstore, y me lo descargué y el efecto era bastante

114

sencillo, solo mueves las coordenadas UV del modelo. Así que personalizando un poco lastexturas y usando un material de tipo MKGlow conseguí el efecto de objeto brillante y enmovimiento, aunque de cerca se aprecia muy bien, de lejos se ve algo, pero hay que fijarse,tampoco destaca mucho, y eso que lo he dejado más bien grandecito para ser un power-up.

He tenido que poner un box collider y rigidbody al power-up, hacer que se cree al acabarcon un grupo de enemigos (en las pruebas y en el vídeo ese grupo es de un solo enemigo) yque al cogerlo desaparezca y recupere algo de vida el protagonista.

8.8.4 Control

En la primera versión el control del personaje se hacía con un controlador propio demovimiento. Incluido un salto con altura fija. Funcionaba bien para las animaciones que habíaentonces, pero era insuficiente.

En esa versión ya estaba implementado el patrón adaptador que daba una capa deabstracción al control del usuario, permitiendo de forma sencilla añadir nuevos controles en elfuturo como pantalla táctil. En la versión final esta adaptación es todavía más sencilla gracias auna capa de abstracción de controles que añade Unity 5.

Para la versión del trabajo de fin de máster quise mejorar considerablemente el control.Durante un tiempo estuve utilizando un controlador hecho como parte un proyecto de haceruna versión en HD del Mario 64 conocido como Super Character Controller [6]. Cambiaba laforma de detectar las colisiones del motor de Unity y daba ventajas, por ejemplo al bajar unapendiente no bajaba a saltitos como pasaba con el controlador por defecto de Unity. En lademo del proyecto comencé a usarlo, arreglé algún error como un intento infinito de subircuestas demasiado inclinadas. Después adapté el controlador a mis necesidades, puse saltoincremental, e implementé el cambio de gravedad.

El cambio de gravedad fue complejo, hay varios aspectos que implementar, la animacióndel cambio de gravedad, la orientación de la cámara, el movimiento del personaje teniendo encuenta la nueva orientación y el movimiento de la cámara. Tome la solución de hacer el giro decámara según el eje canónico más cercano al forward de la cámara. Las animaciones parahacer los cambios de gravedad suave los hice con cuaternios, ya que se comportan muy bienen las interpolaciones. Para ajustar los movimientos de personaje y cámara tuve que usaralgunas multiplicaciones por unas matrices de permutación que me inventé. Y esas matrices depermutación se generaban con unas multiplicaciones sencillas sobre la matriz actual paraajustar a la nueva gravedad. También cambiaba la gravedad en las físicas de Unity para que elresto de objetos también se comporten como se espera en un cambio de gravedad. [72]

Finamente al migrar a Unity 5 decidí utilizar el controlador de movimiento que viene conla nueva versión del entorno, por lo que todo el trabajo hecho con el Supercharacter controllerse deshechó. Aún así merecía la pena, ya que el nuevo controlador estaba integrado conMecanim y tenía parte de lo que quería out of the box.

Pero también tuve que hacer cambios, quité las animaciones de torcer e hice que elpersonaje encarase automáticamente la dirección de movimiento, es más de dibujos animados,menos realista, pero tampoco quería un control muy realista ni el juego tiene ese aspecto. Otrocambio fue la posibilidad de hacer un salto incremental. Y posteriormente añadí la posibilidadde varias levemente la dirección del personaje en el aire, para hacer más sencillos algunossaltos. Este salto no funciona tan bien como esperaba, aunque al tener tanta relación con laparte física de Unity lo implemento en la función FixedUpdate, pero sigue dando problemas aveces en los que la altura máxima alcanzada no es la misma. Y esto hace muy complicadohacer un buen diseño con una curva de dificultad ajustada. Por otro lado añadí todos losmovimientos de ataque con la espada y la lógica que hay detrás y su combinación con otrosmovimientos como el salto.

115

Tuve que hacer para este controlador también todo el código para el cambio de gravedad.Las ideas son las mismas que las utilizadas en el Super Character controller y reutilicé buenaparte del código matemático implementado. Pero al usarlo en un proyecto real tuve muchosmás problemas, pequeños errores, la mayoría relacionados con mecanim, y que hacían que milógica de cambio de gravedad no funcionase correctamente en casos marginales. Solucionétodo lo que pude detectar y el cambio de gravedad es un sistema bastante robusto en elproducto final.

8.8.5 Interfaz de usuario

En la primera versión del juego había que utilizar el sistema de UI de Unity disponible enese momento, que era bastante malo. Así que la interfaz consistió en la barra de vida a laizquierda de la pantalla y en el menú del inicio del juego, no había menú de pausa. Estaversión de la UI consistía básicamente en un script que posicionaba los elementos en pantallade forma relativa según el tamaño de la misma.

En Unity 5 se dio el salto al nuevo sistema de UI, compuesto por componentes deescena, que puedes toquetear en el editor. Funciona un poco como CSS, tenemos un canvas,que es un espacio sobre el que poner componentes de interfaz y tienen características deresponsive web. Podemos decidir como se comporta un elemento al redimensionar la pantalla,si debe estar a una distancia fija de un borde, debe hacerse más estrecho proporcionalmente,mantener tamaño, en un eje, en varios... Además podemos decidir de qué forma se interpretauna imagen. Por ejemplo si tenemos una imagen de fondo para un botón podemos elegircortes sobre la imagen de tal manera que se redimensione la parte central, dejando los bordescomo en el original. Tiene también varios modos de renderizado, 2d en plan hud en pantalla, ocon cierta perspectiva, o 3D en el mundo del escenario, para poner, por ejemplo, un bocadillojusto sobre la cabeza de un personaje.

Se pueden animar los controles, tienen varias sencillas por defecto como cambiar el colordel elemento (por ejemplo botón) en los diferentes eventos (pasar el ratón por encima,pulsar...), o poner diferentes sprites. Pero podemos hacer cualquier animación personalizadausando el animador y mecanim, con un diagrama de estados igual que con un personaje, parahacer cualquier cosa que se nos ocurra, botones que se hacen gigantes, usar shaders, poner lapantalla boca-abajo, lo que sea.

También mejora mucho el sistema de eventos, podemos trabajar el comportamiento delos elementos sin salir ni del editor. Por ejemplo un slider que cambia el volumen de la músicase podría hacer sin ninguna línea de código. Aunque siempre podemos hacer que los eventossobre la UI vayan a funciones propias y hacer el código que queramos.

Otra cosa añadida son las máscaras. Lo que en los ejemplos es una gran idea y permitemejorar el aspecto de los elementos del UI. Pero no consigo que hagan lo que quiero, mefaltan detalles en las explicaciones oficiales. En teoría las máscaras permiten dar la forma quequeramos a los elementos, mostrando o no la imagen de la máscara. Mi idea era hacer unabarra ancha de vida y con una máscara recortarlo para que parezca un matraz redondo, concuello largo y redondo abajo, pero que esa parte redonda sea parte de la barra, no decoración.La cosa es que no funciona. Si lo hago sobre los sliders no coge la forma que debe si lo hagoen un panel del que cuelguen los sliders, el panel se recorta pero los hijos no. Tampocoexplican el tipo de imagen que debe ser la máscara. ¿Qué se recorta? ¿Lo transparente? ¿Lonegro? ¿Lo blanco?

Al final como he hecho que funcione la barra de vida es poniendo dos barras verticales,una amarilla con fondo transparente debajo y otra roja encima. De esta forma cuando noshacen daño la roja baja rápido pero la amarilla baja más lento y así podemos darnos cuenta decómo de gorda ha sido la hostia que nos hemos llegado. Las barras son sliders sin tirador, solopara mostrar la cantidad de vida. Están ajustadas como strech en vertical y left en horizontal.

116

Es decir mantienen el tamaño y el margen a la izquierda en el redimensionado horizontal y sedeforma ante el redimensionado vertical.

Para el menú de pausa creé un estado de sonido con un filtro de paso bajo, de estaforma la música suena como taponada cuando se abre el menú. Creé un pequeño Hud para elmenú de pausa, dentro del canvas de UI creo un panel que será el menú de pausa y dentro lasopciones.

He añadido en el input un botón para la pausa, en teclado el esc. Al poner la pausa seactiva el panel de UI de pausa, se cambia el parámetro del fitro de paso bajo para que lamúsica de fondo suene como queríamos, y además hay que parar el juego claro, sino las cosasse seguirían moviendo.

Para parar el juego solo tenemos que poner la escala de tiempo a 0. Es como parar eltiempo virtual del juego, literalmente pausar nuestro mundo virtual. Con esto dejan defuncionar animaciones, físicas, interpolaciones, temporizadores, todo. Menos la música, que esjusto lo que queremos. Aunque con la última actualización de Unity 5 menor hasta la fechamecanim también se mueve aún con la escala de tiempo a 0, por lo que hay que parar losanimadores a mano.

Pero surgió un problema. No se movían las cosas pero si se registraban las teclaspulsadas. Esto es que si pausamos el juego, pulsamos salto y quitamos la pausa, el jugadorsaltará. Y claro eso no se puede permitir, que manejemos al personaje con el juego pausado,aunque las acciones no sean inmediatas.

8.9 Pruebas

En la primera entrega, la de tecnología de juegos, las pruebas fueron exclusivamente lasque hizo el desarrollador durante el proceso de desarrollo del proyecto. Al entregar se hicieronpruebas con usuarios para ver las reacciones al probar el juego y tomó en cuenta el resultadode estas pruebas para enfocar el siguiente desarrollo.

Al hacer el desarrollo como piezas COTS, cada componente desarrollado para la versiónfinal fue probado individualmente hasta conseguir que el componente estuviera libre de fallos.Aunque muchas veces en el proceso de integración se generaban nuevos errores al funcionarunas piezas con otras. En esta ocasión además de las pruebas de desarrollador se han idorealizando pruebas con usuarios en distintas etapas del desarrollo.

117

118

Capítulo 9: Uso

9.1 Requisitos

Actualmente solo he incluido la compilación para Windows de 64 bits. Por ello se necesitaun Windows de 64 bits instalado a partir de Windows 7 o Windows Vista SP2. Esto se debe a lanecesidad de DirectX 11. Es posible que funcione en versiones anteriores de Windows si seinstalase esta versión de DirectX, pero no lo he probado.

Se requiere una tarjeta gráfica compatible con DirectX 11 y con al menos 512MB dememoria. También son necesarios 2 GB de memoria RAM (el juego no utiliza tanto, pero elpropio Windows consume la mayor parte).

No se ha determinado un procesador mínimo, el juego funciona bien con procesadores dedoble núcleo de gama baja, he llegado a probar con éxito en un procesador de doble nucleo a1,8Gh.

Finalmente el juego ocupa algo menos de 300 MB en el disco duro, por lo que se necesitaeste espacio para poder copiarlo, seguramente el doble para poder descomprimirlo una vezbajado.

9.2 Instalación

El juego realmente no necesita instalación, basta con descomprimir el zip de distribucióny ejecutar el juego. Se debe tener instalado previamente DirectX 11, sino se puede obtener dela página de DirectX o en la del fabricante de la tarjeta gráfica.

El juego necesita la capeta temet_nosce_data en el mismo directorio que la aplicación,téngalo en cuenta si va a mover la aplicación. Por otro lado un acceso directo al ejecutable dela aplicación funciona perfectamente y también se puede agregar el juego a librerías comoSteam creando su propio lanzador.

119

9.3 Configuración

Las configuraciones disponibles del juego se dan en una pantalla previa, en el lanzador.Éste dispone de dos pantallas, la primera para las opciones gráficas, donde podemos elegir laresolución de pantalla, aunque la aplicación fuerza a que sea 16:9, la calidad de los gráficos, loque afecta a cosas como la distancia de pintado o la calidad de las texturas, el monitor dondequeremos que se vea el juego, en el caso de tener varios conectados, y si queremos jugar apantalla completa o no.

En la segunda pestaña de esta ventana se pueden personalizar los controles, y esoscambios se almacenan en la configuración de la aplicación, por lo que no tendremos quecambiarlos cada vez que juguemos. Por defecto se puede jugar con teclado y con la mayorparte de mandos que reconoce Unity sin tener que configurar a mano. Pero siempre podemospersonalizarlos a nuestro gusto y es bastante sencillo, pudiendo pulsar directamente el botónque queremos asignar a una acción.

9.4 Controles

El juego tiene controles implementados para manejar con teclado y mando, aunque sepuedes personalizar como se ha visto en el apartado anterior y no todos los mandos tienen lamisma disposición de botones, voy a explicar cuáles son los controles por defecto.

• Movimiento: En teclado son las flechas de movimiento y en mando el joystick izquierdoo cruceta. Aunque es habitual moverse con wasd en teclado, al tener que usaractivamente el control izquierdo y la barra espaciadora eran muchos botones juntos, yademás necesito otros botones para el cambio de gravedad.

• Salto: En el teclado con la barra espaciadora y en mando con el segundo botón (que enel caso de los mandos que he usado es el botón de abajo de los 4 de la derecha).

• Ataque: En el teclado es el control izquierdo y con mando es el primer botón (en losmandos probados correspondía al mando de la izquierda de los 4 de la derecha deldispositivo).

120

Imagen 50: Configuración gráfica (izquierda) y de controles (derecha)

• Pausa: En el teclado es Esc, y usando mando es el botón 10, que habitualmentecorresponde con el botón start o pausa.

• Cambio de gravedad: Usando las teclas awd del teclado o con el joystick derecho en elmando.

9.5 Menús

El menú de la pantalla inicial del juego tiene 3 opciones, casi autoexplicativas:

• Comenzar partida: Empieza el juego, ¡a jugar!

• Créditos: Muestra los créditos, tanto en el desarrollo, de las librerías y medios utilizadosy los agradecimientos.

• Salir: Cierra el juego y vuelve al escritorio.

El menú de pausa del juego tiene dos opciones:

• Continuar: Cierra el menú de pausa y se vuelve a la partida.

• Salir: Sale a la pantalla inicial del juego.

121

122

Capítulo 10: Conclusiones y trabajo futuro

10.1 Conclusiones

10.1.1 Modelo de desarrollo

En la versión para proyecto final de máster he intentado mejorar la forma de desarrollarde la primera versión, pero ambas han sido bastante malas, y al final ambas han sido por lamisma razón. Para tecnología de juegos tuve problemas con la parte artística, que me llevómucho tiempo, y cuando quise utilizar todo en Unity tenía problemas por todos lados. Por esoen la versión final decidí ir generando componentes comprobados para evitar que al realizar eljuego tuviera el problema de tener errores simultáneos de varios sistemas a la vez.

Pero volví a tener el problema del excesivo tiempo que me llevan los aspectos artísticos,y además en este caso al tener un nivel de exigencia mayor respecto al resultado que queríase hizo todavía más crítico.

Me reafirmo en que en este tipo de proyectos debería utilizar un sistema de desarrolloincremental, comenzando siempre por la jugabilidad. Teniendo montado un juego funcionalhecho con cubos, cápsulas y esferas en escenarios planos, donde las mecánicas principales deljuego funcionen, y poco a poco ir añadiendo aspectos, modelando, creando los escenarios... ymejorando aspectos como la física del juego, pero siempre partiendo de una base jugable.

10.1.2 Trabajo en grupo

En el desarrollo de videojuegos siempre voy a intentar trabajar en grupo. No me importatrabajar solo en otro tipo de proyectos, pero en videojuegos preferiría no volver a pasar poresto. A lo sumo hacer algún prototipo, pero no intentar hacer un juego completo otra vez.

No soy artista, y aunque este ejercicio me haya ayudado a aprender mucho sobre eltrabajo de esta rama y haya mejorado mucho personalmente en este aspecto, tengo quereconocerlo, no soy artista. Por eso es mejor dejar ese trabajo a los especialistas, van aconseguir un resultado mucho mejor que el mio y en mucho menos tiempo, desde el punto devista del producto no hay color.

Y no solo por el aspecto artístico, espero poder contar con más gente para futuros

123

desarrollos para tomar mejores decisiones. Cuando haces las cosas solo hay muchas veces queno ves bien todos los pros y contras de cada decisión, o te puedes encabezonar en algunaidea, y seguramente con un buen ambiente de grupo se hubieran encontrado alternativas quehubieran hecho que el desarrollo hubiera tenido menos tiempos muertos.

10.1.3 Complejidad de los juegos actuales

Me refiero sobre todo a los juegos en 3D, y los juegos que intentan seguir la estela de laindustria, usando herramientas similares a las de los grandes juegos. Hay herramientas muybuenas que permiten hacer cosas muy complejas de forma sencilla en las distintas ramas deljuego. Sistemas de animación como mecanim que permiten hacer blending de animaciones,todo tipo de transiciones o animar por capas; sistemas de partículas con los que hacer efectosincreíbles y simulaciones físicas, Sonido envolvente con efectos y un control profesional,Materiales basados en física e los primeros trazos en iluminación global...

El problema es que dominar todos es complejo y muchas veces la interacción entre ellosno es sencilla y aunque los ejemplos sencillo de cada uno son triviales y la mayor parte denecesidades quedan cubiertas de forma sencilla, cuando necesitas hacer algo que sobrepasaesos usos básicos se nota que son sistemas complejos y es muy complicado hacer ciertascosas manteniendo estos sistemas y la calidad que exigen.

Esto apoya todavía más la locura que es intentar hacer un juego de estilo moderno,usando todos estos sistemas, intentando innovar y que sea artísticamente agradable hecho poruna sola persona. Hay ejemplos de juegos, pero no de este estilo. Hay juegos en 2dimensiones hechos por una sola persona o un equipo muy pequeño que si han tenido un granéxito, incluso ganando juegos. Hay algún juego en 3D hecho por una sola persona, normal-mente artista, gracias a las facilidades ofrecidas por motores como Unity, pero normalmenteson juegos con jugabilidad limitada, con el controlador en primera persona o con interfacesrestringidas como puede ser un click and point. Y en los que he podido probar tenían algunosproblemas con las partes más técnicas como la detección de colisiones.

10.1.4 Aprendizaje personal

Es la parte más valiosa del proyecto. La realización del mismo me ha permitido aprendermuchas cosas sobre herramientas y sistemas en concreto, también sobre el proceso decreación de un videojuego y sobre informática gráfica en general.

A lo mejor lo que he aprendido sobre Unity, mecanim o su sistema de partículas no mesirve en un futuro porque no vuelvo a trabajar en este entorno. Sin embargo la filosofía detrásde estas herramientas es transversal y la mayoría de entornos de desarrollo de videojuegos dealto nivel tienen una forma de trabajar parecida, por lo que todo lo aprendido será de granutilidad.

Sobre el proceso de creación de un videojuego he aprendido mucho, he tenido que hacertodos los roles, creo que esto me ayudará a comunicarme mejor con mis compañeros o conotros departamentos dentro del desarrollo de proyectos futuros en mi vida profesional.

Y todo lo aprendido en el máster se ha ampliado o reforzado gracias al proyecto. Desdelas restricciones que ofrecen las tarjetas gráficas y problemas de rendimiento, hacer shaders,modelar, iluminación local y global, incluso en cierto momento del proyecto intenté trabajarcon simulación de telas.

Todo lo aprendido no es porque haya salido bien, seguramente las mayores leccionesaprendidas son por los numerosos errores cometidos durante el proceso. Además la creación

124

del blog donde tener que escribir sobre lo que estaba haciendo y presentarlo a los demás meha ayudado a interiorizar más lo que hacía y los posibles errores, viendo las cosas más enperspectiva que si solo hubiera desarrollado.

10.2 Trabajo futuro

10.2.1 Mejorar el control

Aunque he dedicado una parte importante del desarrollo y ha mejorado mucho desde laversión para tecnología de juegos, sigo sin estar conforme con el control. Los saltos no sonintuitivos y a veces se quedan cortos y otras van demasiado largos. No es fácil aprender acontrolar cómo se hacen los saltos.

Y tampoco me gustan los ataques, con espada se ataca algo mejor que echando fueracon la mano, pero aún así los combates son tediosos, y hay veces que tenemos que estardemasiado cerca del enemigo para poder acertarle. Me gustaría que el control de los ataquesse pareciera más a los juegos hack n' slash, con cosas automatizadas, movimientos másexagerados y la posibilidad de atacar mientras corremos para que no se cambie tanto el ritmoentre avanzar y luchar.

10.2.2 Mejorar el comportamiento del veneno

La IA del veneno hace que tenga un comportamiento errático a veces, en ocasiones nonos ataca o se pierde por el escenario. Además su patrón de ataque es bastante básico, al azary no reacciona ante el protagonista. Me gustaría poder arreglar los primeros problemas, paratener un comportamiento sólido del veneno, aún con ataques al azar y desarrollar una nuevaversión del veneno que reaccione mejor ante los movimientos del personaje, para hacer másdifícil las últimas partes del juego.

10.2.3 Ampliar niveles

El juego sigue siendo corto. En el primer nivel hubiera podido hacer más cosas, añadirpequeños puzles de interacción para que el avance no fuera solo andar, saltar y pelear. Y conun buen diseño de niveles todavía hay espacio para alargar esa pantalla sin que se hagarepetitivo.

Pero donde más se podría ampliar es en la segunda pantalla. El cambio de gravedad dapara mucho más de lo mostrado, se pueden realizar puzles realmente ingeniosos aprove-chando la física de los cambios de gravedad, y se podría alargar mucho esa pantalla sin que sehiciera pesado jugarla. Aquí un buen diseño de niveles es indispensable, pero las posibilidadesdisponibles son muchas.

125

10.2.4 Lucha contra el enemigo final

En los planes originales de la historia estaba que al despertar el personaje descubrieraque no había acabado con el enemigo que le había envenenado y le tocaba luchar contra él denuevo, pero esta vez aprovechando algunas de las cosas que había aprendido después del laintrospección por su propio subconsciente. Esto daba sentido al título del juego, Temet Nosce,conócete a ti mismo. Pues todo el recorrido del juego servía para conocerse mejor y usar eseconocimiento en esa batalla final.

Finalmente no se pudo incluir por falta de tiempo y la complejidad que supone elmodelado de un mundo completamente diferente y un monstruo funcional con sucomportamiento contra el que poder luchar. Pero si me gustaría poder añadir esto al juego enun futuro para dar un cierre mejor al juego.

10.2.5 Mejorar cinemáticas

Es la forma de contar la historia en este juego y es clave para que se entienda unplanteamiento tan extraño. Por eso quiero mejorarlas. Es una de las cosas en las que más heacusado la falta de artistas, y que el tiempo se me ha echado encima.

Me parece buena decisión no haber dedicado más tiempo del necesario a esto, prefierotener un mejor juego desde el punto de vista jugable y más flojas las cinemáticas y no alrevés, pero si es cierto que si puediera contar con algún artista podrían mejorar mucho.Además no son tantas, sobre todo es mejorar la intro y el final del juego.

10.2.6 Versión para móvil

En bastantes partes del proceso se ha tenido en cuenta la intención de que el juegofuncionase en dispositivos móviles. Ahora mismo es realizable, pero no trivial. Habría queimplementar el control en pantalla táctil, con joystick virtual, botones y el giroscopio para elcambio de gravedad. Este último control creo que sería muy divertido y haría el juego único,aunque habría que comprobar si el diseño de pantallas se adapta a ese nuevo control, ya quevolver a tomar los mandos del personaje tras un cambio de gravedad es mucho máscomplicado en una pantalla táctil que con teclado o mando.

Por otro lado los modelos y escenarios tienen un numero de polígonos suficientementebajo como para que funcione sin problema en dispositivos móviles y otros elementos como lacámara está especialmente pensada para que su uso sea sencillo en estos dispositivos.

Lo que si que habría que estudiar y recortar son los efectos de post proceso de imagen.El mayor problema de rendimiento del juego es en CPU, algo más reducido en dispositivosmóviles, y donde muchos tienen una resolución igual de alta o mayor que las de losordenadores de sobremesa. Algunos efectos solo funcionan con DirectX 11, por lo que esosefectos habría que cambiarlos por otros y hay efectos que por rendimiento tendrían quedesaparecer como pueden ser el antialiasing o el tonemapping y esto podría conllevar tenerque volver a ajustar la iluminación y materiales de casi todo el juego.

126

10.2.7 Publicar el juego

Este es el único paso del proceso que no he podido aprender. El momento de empaquetarla aplicación, cumplir los requerimientos de alguna tienda online y poder poner el juego adisposición general. Eso no significa que no vaya a publicar el juego en el blog para quiénquiera usarlo. Pero no es el mismo nivel de exigencia que publicar en una tienda. Aún poniendoel juego gratis, debido a su corta duración, pero tener que empaquetar con unos estándares decalidad es un paso a superar. Además de tener en cuenta los comentarios de los jugadores yestar preparado para cualquier mantenimiento que necesite.

No solo eso, sino la parte de promoción del juego, saber moverlo, conseguir jugadores,es otra materia a tener en cuenta, y muy importante, se juega más a un juego regular bienvendido que a uno excelente que no te enteras que existe.

También me hubiera gustado aprender como se puede poner publicidad dentro del juegoen la versión móvil para aprender cómo funciona esa publicidad, cómo se integra y elseguimiento que necesita, las estadísticas que puedes acceder y las actualizaciones a realizarsegún esas estadísticas.

127

128

Referencias

Apuntes y trabajos

[1] Cuadrado Alvarado, A. (2014). Apuntes de la asignatura Modelado y comportamiento de personajes. Máster en informática gráfica, juegos y realidad virtual, Universidad Rey Juan Carlos, Móstoles, Madrid.

[2] De la Fuente Redondo, P. (2011). Apuntes y prácticas de la asignatura ingeniería del software ii. Ingeniería en Informática, Universidad de Valladolid.

[3] Hijarrubia Bernal, L. (2014). Memoria WORMHOLE EFFECTS. Rendering Avanzado, Universidad Rey Juan Carlos, Móstoles, Madrid.

Blogs

[4] Hijarrubia Bernal L. (2014-2015). Novato en (desarrollo de) videojuegos. 2014-2015.Disponible en: http://novatoenvideojuegos.luishijarrubia.com/ [2015, 5 de Junio]

[5] Hijarrubia Bernal L. (2015, 25 de Febrero). Crítica a mi nivel de Portal 2. Novato en (desarrollo de) videojuegos. Disponible en: http://novatoenvideojuegos.luishijarrubia.com/2015/02/critica-mi-nivel-de-portal-2.html [2015, 26 de Junio]

[6] Ross R. (2014-2015). Super Character Controller. Disponible en: https://roystanross.wordpress.com/downloads/ [2015, 30 de Junio]

[7] Unity Technologies (2015, 7 de Mayo). AudioMixer and AudioMixer Groups. Unity Tutorials. Disponible en: https://unity3d.com/learn/tutorials/modules/beginner/5-pre-order-beta/audiomixer-and-audiomixer-groups [2015, 29 de Junio].

Libros y artículos

[8] Hunicke R., LeBlanc M. y Zubek R. (2004). MDA: A Formal Approach to Game Designand Game Research.

[9] Jacobson I., Booch G. y Rumbaugh J. (2000). El Proceso Unificado de DesarrolloSoftware. Addison Wesley.

[10] Larman C. (2005). Applying UML and Patterns — Introduction to OOA/D andIterative Development. Prentice-Hall (8ª edición).

[11] Tost G. y Boira O. (2015). Vida Extra. Los videojuegos como nunca los has visto.

Grijalbo.

129

Películas y series

[12] Aronofsky D. (1998). Pi, fe en el caos.

[13] Burton T. (1988). Bettlejuice.

[14] Disney (1941). Dumbo.

[15] Disney (1951). Alicia en el país de las maravillas.

[16] Fleming V. (1939). El mago de Oz.

[17] Geffen D. y Burton T. (1989-1998). Bettlejuice (serie de televisión).

[18] Gilliam T. (1985). Brazil.

[19] Gilliam T. (2005). Tideland.

[20] Kubrick S. (1968). 2001: Una Odisea del Espacio.

[21] Lang F. (1927). Metrópolis.

[22] Lisberger S. (1982). Tron.

[23] Lucas G. (1978). La guerra de las galaxias.

[24] Natali V. (1997). Cube.

[25] Selick H. y Burton T. (1993). Pesadilla antes de navidad.

[26] Selick H. (2009). Los mundos de Coraline.

[27] Wachowski L. y Wachowski A. (1999). Matrix.

Videojuegos

[28] AlphaDream y Nintendo (2009). Mario & Luigi: Viaje al centro de Bowser.

[29] Cavanagh T. (2010). VVVVVV.

[30] Cockroach Inc. (2011-2014). The Dream Machine.

[31] Cryo Interative (1997). Dreams to reality.

[32] Krillbite Studio (2014). Among the sleep.

[33] Level 5 y Ghibli (2011). Ni no kuni.

[34] Level-5 y Squaresoft (2004). Dragon Quest VIII.

[35] Minority (2012). Papo y yo.

[36] Natsume (1991). Shatterhand.

[37] Naughty Dog (1996). Crash Bandicoot.

[38] Naughty Dog (1998). Crash Bandicoot 3: Warped.

[39] Nintendo EAD (1985). Super Mario Bros.

[40] Nintendo EAD (1996). Super Mario 64.

[41] Nintendo EAD (1998). The Legend of Zelda: Ocarina of Time.

[42] o2sun (2012). Yoo Ninja!.

[43] OutSide Directors Company (1998). LSD: Dream Emulator.

[44] Remedy Entertainment y Rockstar Vienna (2003). Max Payne 2: The Fall of Max Payne.

130

[45] Rocksteady Studios (2009). Batman: Arkham Asylum.

[46] SCE Japan Studio (2012). Gravity Rush.

[47] Shiny Entertainment (1994). Earthworm Jim.

[48] Sony Computer Entertainment (1998). Medievil.

[49] Spicy Horses (2011). Alice: Madness Returns.

[50] Squaresoft (1995). Secret of Evermore.

[51] Squaresoft (1999). Final Fantasy VIII.

[52] Sunsoft (1996). Waku Waku 7.

[53] Ubisoft Montreal, Ubisoft Massive, Ubisoft Shanghai y Ubisoft Red Storm (2012) Far Cry 3.

Vídeos

[54] 3Djuegos. Vídeo Mario & Luigi: Viaje al Centro de Bowser - Trailer oficial (JPN)., Disponible en: http://www.3djuegos.com/4484f12001/video/mario-luigi- viaje-al-centro-de- bowser/trailer-oficial-jpn [2015, 9 de Junio]

[55] Youtube (2008, 8 de Octubre). LSD (PSX Game): Day 1. Disponible en: https://www.youtube.com/watch?v=PLcgLd8153g [2015, 8 de Junio]

[56] Youtube (2009, 9 de Enero). Shatterhand (NES) Playthrough - Area E [4 of 6]. Disponible en:https://www.youtube.com/watch?v=tZdrWA_QDZc [2015, 8 de Junio]

[57] Youtube (2009, 11 de Septiembre). VVVVVV Gameplay video. Disponible en: https://www.youtube.com/watch?v=sf06P-_1lkU [2015, 8 de Junio ]

[58] Youtube (2010, 13 de Enero). Batman's Arkham Asylum Scarecrow Hallucination 2. Disponible en: https://www.youtube.com/watch?v=9v2O9OFPY3U [2015, 9 de Junio]

[59] Youtube (2010, 17 de Julio). PSX Longplay [031] Crash Bandicoot Warped. Disponible en: https://www.youtube.com/watch?v=Z2lemj-MCaY [2015, 8 de Junio]

[60] Youtube (2012, 29 de Enero). WWE CM Punk 2012 Titantron and Theme Song. Disponible en:https://www.youtube.com/watch?v=S30uz9RP894 [2015, 6 de Junio]

[61] Youtube (2012, 12 de Mayo). Skidd Plays: Max Payne 2 TFOMP - 001 – Hallucinations. Disponible en: https://www.youtube.com/watch?v=IZX7rxXiFrg [2015, 9 de Junio]

[62] Youtube (2012, 13 de Junio). Gravity Rush : Gameplay Trailer. Disponible en: https://www.youtube.com/watch?v=yucx-ZS4SKY [2015, 9 de Junio]

[63] Youtube (2012, 10 de Diciembre). Efectos de las drogas en Far Cry 3 (Alucinaciones). Disponible en: https://www.youtube.com/watch?v=M2xPn9aPBJc [2015, 9 de Junio]

[64] Youtube (2012, 14 de Noviembre). PO3DM Lecture #07 Body Model. Disponible en: https://www.youtube.com/watch?v=bsuK0H8qcrk [2015, 27 de Junio]

[65] Youtube (2013, 28 de Abril). Las ánimas del terror. Disponible en: https://www.youtube.com/watch?v=xyoTYzvLb34 [2015, 6 de Junio]

[66] Youtube (2013, 23 de Julio). Kanye West - BLKKK SKKKN HEAD (Explicit). Disponible en: https://www.youtube.com/watch?v=q604eed4ad0 [2015, 15 de Junio]

[67] Youtube (2013, 5 de Diciembre). Yoo Ninja! (Android). Disponible en: https://www.youtube.com/watch?v=jFETOoFeGRw [2015, 9 de Junio]

131

[68] Youtube (2014, 1 de Marzo). PSX: MEDIEVIL LONGPLAY: PAL (ENGLISH): (HD). Disponible en: https://www.youtube.com/watch?v=sFpw9GnJI6o [2015, 8 de Junio]

[69] Youtube (2014, 1 de Agosto). Gravedad – Prototipo del juego en Unity3D. Disponibleen: https://www.youtube.com/watch?v=o9RKWTJEcjM [2015, 8 de Junio]

[70] Youtube (2014, 9 de Agosto). Temet Nosce y Zamburguesas. Animaciones Pre Alpha. Disponible en: https://www.youtube.com/watch?v=t9sDpMBdPSI [2015, 28 de Junio]

[71] Youtube (2015, 13 de Enero). Temet Nosce [Pre-alpha] - Animaciones internas veneno ciego. Disponible en: https://www.youtube.com/watch?v=lc-R__LJFuU [2015, 28 de Junio]

[72] Youtube (2015, 27 de Enero). Temet Nosce [Pre alpha] - Control del personaje y gravedad. Disponible en: https://www.youtube.com/watch?v=f7hdyfcgwgk [2015, 28 de Junio]

[73] Youtube (2015, 17 de Marzo). Temet Nosce [Pre alpha] - Migración a Unity 5: Movimiento. Disponible en: https://www.youtube.com/watch?v=9bSaqUWxLDo [2015, 28 de Junio]

[74] Youtube (2015, 25 de Abril). Temet Nosce [pre alpha] - Gravedad competa. Disponible en: https:// www.youtube.com/watch?v=J0eD2yFVhyI [2015, 28 de Junio]

[75] Youtube (2015, 4 de Mayo. Papo & yo #1 - Más pesao que una favela en brazos - Gameplay comentado. Disponible en: https://www.youtube.com/watch?v=Q3WdG7tSFxw [2015, 2 de Julio]

Webs

[76] Berkebile B. (pixelplacement). iTween for Unity. Disponible en: http://itween.pixelplacement.com/index.php [2015, 13 de Junio].

[77] The Document Foundation. The Document Foundation. Disponible en: https://www.documentfoundation.org/ [2015, 12 de Junio].

[78] Dropbox. Dropbox – tus cosas, siempre contigo. Disponible en: https://www.dropbox.com/ [2015, 12 de Junio].

[79] Pullin Shapes. Roadkill UV Tool. Disponible en: http://www.pullin-shapes.co.uk/page8.htm [2015, 12 de Junio].

[80] Sixth sensor (2014, 27 de Agosto). Tube Renderer. Disponible en: http://sixthsensor.dk/code/unity/tuberenderer/ [2015, 13 de Junio].

[81] UBM Tech (2015, 6 de Marzo). GDC 2015 | March 2-6, 2015. Disponible en: http://www.gdconf.com/ [2015, 13 de Junio].

[82] Unity Technologies (2015, 1 de Marzo). Unity – Unity 5.0. Disponible en:

https://unity3d.com/es/unity/whats-new/unity-5.0 [2015, 13 de Junio].

[83] Wikipedia (2015, 8 de Junio). Dolly Zoom (en inglés). Disponible en: http://en.wikipedia.org/wiki/Dolly_zoom [2015, 6 de Junio].

132