Túnel wormhole: Shaders en Unity

Aunque para realizar los diferentes efectos del túnel utilicé mezcla de cosas, jugando con geometría, efectos de partículas, efectos de post-proceso... lo que hay en común en todas y era la primera vez que utilizaba eran shaders en Unity. 

Unity añade una capa de abstracción bastante grande a los Shaders, que en realidad supone control sobre el renderizado completo. Tiene varios tipos de shaders (que son más que shaders), pero me he restringido a los que son un reflejo de lo que se entiende por shader fuera de Unity. Dentro de cada shader de Unity, además de poder especificar una serie de shaders de vértices o fragmentos, podemos configurar las pasadas, opciones de transparencia, niebla, modos de filtrado de las texturas, realizar renderizados multipasada con varios shaders en cada pasada... por lo que supone al configuración del render completo y puede ser complejo encajar todas las piezas: propiedades que se darán al shader en el editor, uniforms, atributos de entrada, pasadas...

Túnel wormhole: geometría del túnel

La primera parte para tener efectos de tipo túnel es tener el túnel geometricamente. Luego ya se ponen efectos chulis, pero hay que empezar por el túnel.

Y aquí tengo que presumir de haber tomado una buena decisión, comprar una librería para hacerlo. No se si es cosa de informáticos, ingenieros, estudiantes o qué, pero lo veo mucho, en mi mismo el primero. Tendemos a hacerlo todo. Nos parece fácil, “bah, esto lo hago en dos tardes, y a mi gusto, y mejor que ese otro”, “si son dos chorradas, te haces un par de clases y hace lo mismo”. Y sí, es verdad, podría haberme hecho una librería que hiciera trozos de cilindro desde código y me diera las funciones que necesitaba, y además se adaptaría mejor a mis necesidades al estar hecha ad-hoc, y no tendría que invertir tiempo en aprender el funcionamiento de una librería externa. Pero cuando tienes que tener esto funcionando en unas semanas, y la parte del túnel no es lo vital, sino los efectos, y tienes otras cuantas prácticas en el mismo tiempo, con lo que al final podrás dedicar 4 o 5 días de trabajo a esto, pues si que es la mejor decisión gastarse una pequeña suma de dinero (creo que me costó menos de 10 euros) y tener una librería que genere la geometría tal y como la necesitas, y que se coman otros los problemas de como hacer el mapeado UV de esa geometría, dar opción de ver el cilindro por dentro o por fuera o que el cilindro no sea regular, sino que pueda ser tipo zigzag. Hacer un cilindro es relativamente sencillo, pero el demonio está en los detalles y en desarrollar todas esas pequeñas cosas es en lo que podría haber dedicado unos días que hicieran que no llegase a entregar a tiempo.

La librería que uso se llama Tuberenderer, es capaz de renderizar cilindros dándole los puntos por los que tiene que pasar el cilindro y la anchura en cada punto. Además vienen ejemplos para gestionar varios cilindros.

Con algo de configuración conseguí tener renderizado por la parte interna del cilindro, que no dibuje las tapas, mapeado UV bien hecho, todo de forma procedural.

Túnel wormhole: inspiración

Este es el primero de una serie de artículos sobre el efecto túnel que hay en la intro del juego (bueno y en la outro para el que se lo haya pasado). Este efecto lo realicé como proyecto de investigación en la asignatura de Rendering Avanzado, así luego podría usarlo en el juego y mataba 2 pájaros de un tiro.

La idea era hacer un efecto túnel (o wormhole), que siempre me ha gustado mucho. De hecho ya en un corto de la adolescencia hicimos un efecto de este tipo de forma casera (enlace al corto), aunque ese efecto lo explicaré en mi página web personal cuando la estrene en unos meses. Pero en esta ocasión, para el juego me propuse hacer 3 tipos de túnel y que fuera cambiando de un tipo a otro. Y me basé en películas como inspiración para los 3 tipos de túnel.

Símbolo de Temet Nosce: La triqueta

Podría comenzar esta entrada con lo que cuento al final, incluso poner solo eso, y quedaría genial, pero no es verdad. Voy a explicar toda la verdad sobre el símbolo del juego: la triqueta.

Errores en la implementación de la cámara

Ya he explicado como implementé la cámara en Unity para Temet Nosce. Una cámara sobre raíles, montada con trozos de spline. Todo parecía muy bonito, pero el demonio está en los detalles, y aquí hay mucho demonio. Cuando empiezas a usarla en más escenario y salen errores, que puedes evitar que salgan en un vídeo promocional, pues son cosas puntuales, pero no se pueden dejar en el juego. 

Implementación de la cámara

Después de hablar de un plugin de splines de Unity, usos que le di y hablar de forma más teórica sobre los distintos tipos de cámara que se pueden dar en un juego, llega el momento de que cuente qué cámara quiero, cómo la plantee y qué problemas me dio.

¿Qué tipo de cámara quería? Sobre raíles. Me parece más fácil para el jugador este tipo de cámara, el juego no tiene componente de exploración, así que solo serviría para complicar los controles. De esta forma también tengo la posibilidad de en tiempo de diseño de nivel decidir qué enseño y qué no al jugador. Aunque esto también complica esa fase, es una de las fases que más quiero aprender, así que me va bien. Además de cara a que el juego pueda funcionar en dispositivos móviles creo que ayuda a que los controles sobre pantalla táctil no se compliquen.

Como ya he dicho mi modelo de cámara era el de Crash Bandicoot 3, pero llegaba el momento de implementarla. La que viene por defecto con el obrero de Unity, y por lo tanto base para crear un personaje 3D es de las que van siempre a la espalda del personaje y giran con él.

Tipos de cámara en los juegos 3D

La cámara es uno de los elementos clave en un juego en 3D, y es un elemento poco agradecido, si está bien hecha nadie se acordará de ella, se quedarán con otros aspectos del juego, pero si la cámara es un dolor condenará el juego y te acordarás de ella y de los antepasados del que la hizo durante toda la partida.

Ya en el mundo 2D la cámara ya era importante. Por ir al ejemplo más claro que todos tenemos en mente: Mario Bros. Hay estudios completos del diseño de estos juegos, incluida su cámara, aunque a veces no la llamen así. Por ejemplo, Mario suele estar centrado en pantalla de tal manera que el scroll de la cámara se desplaza con el personaje. Pero en la primera pantalla Mario comienza a la izquierda de la pantalla, y la cámara no está centrada, para que sin tener que ponerte flechas, avisos, ni un aburrido tutorial, de forma instintiva vayas hacia la derecha. En Super Mario Bros 3 se añaden niveles con scroll automático en los que si te despistas el avance de la cámara te puede aplastar contra algún obstáculo. Aquí la cámara y su movimiento se convierte en un elemento más de diseño del juego y da una nueva jugabilidad a algunas pantallas.

Los habrá, pero yo no recuerdo casos de cámaras que se cargasen un juego en 2D. Un plataformas 2D básico puede hacerse con 3 botones. Dos para ir a izquierda y derecha y otro para saltar. Claro que luego se añadían más, poder agacharse, atacar, correr o hacer muchas cosas, pero lo básico son esos 3.

Al pasar a 3D los controles se complican y la cámara pasa a ser crucial. Comenzando con los controles: ¿ahora cuantos necesitamos? Moverse sobre una superficie necesita 4 botones o un joystick y otro para saltar. Hemos pasado de 3 mínimo a 5 mínimo. Pero además si damos libertal para mover la cámara podemos necesitar otros 4 botones o un segundo joystick, de esta forma pasamos de 3 a 9 botones en el control más básico de algunos juegos, triplicando el número de teclas que debemos controlar. Si la cámara es buena, acierta los ángulos y tenemos que tocarla poco a mano, entonces nos ahorraremos casi la mitad de la complejidad de los controles.

Y luego está la cámara. Ahora seguramente pase algo menos, pero los que jugamos mucho en las 2 primeras generaciones de consolas en 2D (playstation, saturn, dreamcast, N64, Playstation 2, gamecube, xbox) seguro que hemos coincidido con juegos que era doloroso jugarlos. Cámaras que se giraban en el momento más inoportuno, quedarnos vendidos ante el enemigo, no conseguir mirar hacia donde queremos, quedarnos encallados y no saber como salir, que la cámara atraviese paredes u objetos, o peor, que no los atraviese, sino que nos tape completamente la pantalla haciéndonos avanzar a ciegas. Seguro que la mayoría de estas cosas os ha recordado a algún juego.

Me voy a centrar en juegos con cámara en tercera persona y a ser posible tipo plataformas, para ir a comparar directamente con lo que quiero usar en mi juego. Aunque seguramente haya más formas si clasificamos con un grano más fino, voy a clasificar las cámaras en 3 tipos: Fijas, sobre raíles y las que dejan al usuario elegir la vista.