martes, 23 de diciembre de 2014

Implementación de la cámara - segunda versión

Creo que este es el primer artículo sobre algo de desarrollo posterior a la presentación del juego en Julio. Trabajo fresco. Y es la segunda vuelta de tuerca sobre la cámara, y ya digo que no es la definitiva.



En el artículo sobre la implementación de la cámara ya expliqué que utilizaba splines para hacer una cámara sobre raíles, y en errores en la implementación de la cámara todo lo malo de esa primera versión, y que se resumen en este vídeo:



Una de las medidas es pasar a usar trozos de spline más cortos, con número fijo de nodos y separación constante entre nodos. Esto lo hago para intentar evitar que la cámara esté más lejos o cerca según el trozo de spline que nos toque. Por otras razones que vienen después, uso trozos de 5 nodos y separación de 10 unidades entre nodos.




miércoles, 17 de diciembre de 2014

El bug "cabra montesa"

No sé si habrá muchos autores dispuestos a subir un vídeo de un bug de su juego, de esos gordos y extendidos a lo largo del juego y que se puede cargar todo. Más cuando todavía no tienes claro del todo como solucionarlo, aunque la solución mostrada en el vídeo parece funcionar en principio.





El error sucede por el uso de terrenos. Intento usar uno para hacer el escenario exterior, con montañas que limiten el camino a seguir, incluso en un principio 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 decir un plano, y cada punto del plano tiene una altura marcada. Así que es imposible tener una pared completamente plana en vertical, siempre va a haber un poco de pendiente. Ya que para hacer una pared completamente vertical necesitaríamos que un punto tuviera al menos 2 alturas 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 de ser una función. Da igual, el caso es que tu puedes hacer que un punto el terreno tenga altura 0, y en el de al lado tenga altura 3000, pero eso significa que todos los puntos intermedios en un sistema continuo existen, y por Bolzano y esas cosas al final si nuestro héroe se esfuerza al tener desnivel, a base de saltos, puede ir escalando. Y en el caso de abismo, puedes ir cayendo poco a poco por la pared y no te acabas de dar la hostia nunca.




miércoles, 10 de diciembre de 2014

Mecánica de caída al vacío

Cuando quise que Temet Nosce tuviera partes de plataformas también había que definir cómo iban a funcionar. Aquí es donde surgió una de las mecánicas medianamente novedosas del juego, aunque no inventé nada nuevo del todo.

Caída en Temet Nosce


La primera elección es si las plataformas son tipo montañas que ir escalando, pero siempre caes en algo, si es desde mucha altura con salto; o del tipo abismo, donde caes al vacío. Normalmente en los juegos de este tipo al caer al vacío mueres, y tienes que volver a comenzar la pantalla o desde el último checkpoint.

Eso no me convencía porque en este juego me parecía importante sentir el agobio, esa lucha contrarreloj contra el veneno, y volver a empezar una y otra vez desde el principio te sacaba de la ambientación, además de romper la continuidad. Se puede hacer que vuelvas a aparecer en el punto desde el que has fallado el salto, pero para penalizar el fallo, y que el que falla no esté en las mismas condiciones que el que hace el salto bien deberíamos perder algo de vida. Pero ¿reaparecer parpadeando y perdiendo algo de vida? La excusa me parece pobre.

martes, 25 de noviembre de 2014

Zamburguesas: ajuste de dificultad

Esta entrada dice cosas de perogrullo, y que aún así hice mal. Es tan fácil como: da a probar tu juego a terceros, fíjate como juegan y ajusta la dificultad para ellos. Cuando estás en mitad del desarrollo tu propia experiencia con el juego casi no cuenta.

Zamburguesas

Para ello voy a contar lo que pasó con el juego de las zamburguesas. Es un juego de una mecánica sencilla, solo hay que pulsar un botón en el momento adecuado para ir avanzando zamburguresas y llegar hasta el final. Así que el mayor ajuste de dificultad es decidir cuánto tiempo dejas para que se pulse el botón. Tiene más letra pequeña, por ejemplo cómo afectan las zamburguesas falsas, o si dejas ir en direcciones equivocadas. Aquí tomé la decisión de que si pisas una falsa el tiempo para dar al botón es mucho menor, de esa forma se puede superar si estás muy atento, pero es probable que si pillas una falsa te caigas. Por otro lado decidí que si se podía ir en direcciones que llevasen al agua en lugar de a una zamburguesa, el jugador tiene que estar atento hacia donde salta. También dificulta más o menos el número de zamburguesas falsas que haya.



martes, 18 de noviembre de 2014

Interrupciones

En algún momento de la fase conceptual se me ocurrió que al estar dentro de una persona envenenada, en su subconsciente tendrían que pasar cosas raras, como cuando tienes fiebre. Y una de las cosas que se me pasaron por la cabeza fue que se vieran imágenes al azar que puedas tener por en la memoria. Como crear una serie de recuerdos del personaje sería complicado decidí que fueran iconos de la cultura pop que podríamos tener cualquiera en la memoria. Cosas como Alien, Terminator o unos dibujos animados de cuando éramos pequeños. Y esto acabó derivando en iconos pop que a mi me apeteciera poner.

Interrupción Venom


Desde el punto de vista de la ambientación queda muy bien, ya que da la impresión de que están pasando cosas raras, de estar en un sitio no real, y visto desde los ojos de alguien. Además hace cierta gracia intentar reconocer cada imagen en un espacio tan corto de tiempo y distorsionada.

miércoles, 5 de noviembre de 2014

Ataque del personaje: detección de colisiones

Una vez que el protagonista lanza llamaradas, y que el veneno se mueve y embiste falta que eso sirva para algo. Hay que detectar si el veneno consigue golpear al protagonista, o la llama al veneno, y en ese caso bajar vida, hacer ver al jugador que eso ha sucedido, etc.

En este caso es un poco más fácil que en la versión final, ya que ahora tenemos fuego, externo al cuerpo del protagonista, partículas que pueden chocar o no con el veneno. Aquí las reglas son claras, si una partícula de fuego colisiona con el veneno, sufre daño. Si el protagonista colisiona con el veneno, el protagonista sufre daño. Pero en el caso de atacar con espada, si forma parte de la malla del personaje y van las animaciones juntas tendré problemas. ¿Cómo detectas si al atacar has dado con la espada o con otra parte del cuerpo al veneno? Si estás atacando y das con la espada es normal que el veneno sufra daño, pero ¿Y si el veneno embiste y choca contra la espada del héroe quieto? Sería muy raro que dejando al personaje quieto el veneno se fuera dañando al chocarse contra la espada. Con todo esto tendré que pegarme, ahora voy a volver a lo que ya he resuelto.


Sphere collider
El sphere collider no cubre el pico de arriba, pero se ajusta bastante bien.


viernes, 31 de octubre de 2014

Ataque del personaje: Sistema de partículas

El héroe tiene que poder atacar al veneno. Ante la falta de tiempo, para la versión alfa decidí cambiar el tipo de ataque. Tenía la animación de levantar la mano y tenía que salir algún tipo de ataque de la mano, sabía que lo iba a hacer con un sistema de partículas pero no sabía bien cómo lo quería.

Llamarada

¿Y qué es un sistema de partículas? En gráficos se basan en los sistemas de partículas físicos, con representación por sprites. En la práctica, podemos hacer un efecto visual, basado en cientos o miles de sprites. Cada partícula es un cuadradito plano con una textura, digo bien, un sprite; que podemos hacer que se mueva, cambie, nazca, muera etc. Para ser precisos, no tienen porque ser spirtes, pueden ser mallas pequeñas en 3D, pero yo todas las que he visto son con sprites.


viernes, 24 de octubre de 2014

Sobre el control de los juegos 3D

Voy a pasar a comentar la forma de ataque del personaje. En los siguientes artículos explicaré cosas más técnicas, pero en éste voy a hablar de cosas más teóricas, reflexiones que estoy haciendo, incluso divagar sobre los controles en los juegos.

A la hora de jugar a la alpha de Temet Nosce encuentro que atacar a los enemigos es difícil, no porque ellos opongan mucha resistencia, sino porque el sistema de control es desesperante a veces, acabas frustrado. Esto me ha llevado a pensar mucho en los controles.


Metal Slug

Partiendo de los juegos en 2D, juegos como Contra o Metal Slug. Nos podemos mover a izquierda o derecha con los lados de la cruceta. No podemos movernos libremente hacia arriba o abajo, eso lo da la gravedad por un lado, y desde el punto de vista del control tenemos un botón de salto. Es decir que todo el movimiento del personaje se limita a 3 botones: izquierda, derecha y salto. Por otro lado podemos disparar. Siempre en la dirección que estamos mirando, no podemos disparar de espaldas, lo que es hasta lógico, pues no podrías apuntar. Pero no tenemos por qué disparar siempre en plano. Los botones de arriba y abajo de la cruceta nos ayudan a apuntar el disparo en vertical. Así pues tenemos mezclado en la cruceta el movimiento del personaje y la dirección del disparo, aunque en vertical si podemos desligarlo, con el botón de salto, saltando (movimiento hacia arriba) mientras disparamos hacia abajo. Es un sistema de control que con pequeñas modificaciones se universalizó en los shooters y plataformas 2D durante los 80 y los 90, que es intuitivo y sencillo, una cruceta y 2 botones para moverse y disparar como queramos. Y si está bien equilibrado cogeremos el control desde muy pronto, y el juego podrá ser difícil, pero no podremos echarle la culpa a los controles.


viernes, 17 de octubre de 2014

Túnel wormhole: Hipervelocidad

Me quedaba de hablar del tercer efecto de túnel, el que estaba basado en el salto al hiperespacio en La guerra de las galaxias. No me gusta el resultado, es más, no lo usaré en la versión definitiva del juego. El tiempo que tenía para hacer este efecto fue muy pequeño, ya tenía que acabar de hacer la memoria y el video demostrativo, así que probé varias cosas que tenía en mente y dejé lo más parecido a lo deseado.



Hipervelocidad Star Wars


La primera idea era conseguir hacerlo de forma completamente procedural con shaders. Tomando como ejemplo este shader de toyshader: https://www.shadertoy.com/view/Msl3WH Os funcionará si tenéis un navegador que soporte webgl. Algo como lo de ese shader, pero para conseguir un efecto más cercano a Star Wars.




miércoles, 8 de octubre de 2014

Ragdolls en Unity3D

La entrada de hoy es una introducción y un pequeño tutorial al uso de un elemento muy habitual en juegos, el ragdoll. ¿Y eso qué es? Físicamente lo más parecido que podemos pensar son los dummys para las pruebas de choque en vehículos. 


En un juego, si tiramos a un personaje desde 1000 metros y hay gravedad caerá, pero depende como esté hecho, caerá de pie, o rebotará y caerá de lado, pero como un todo, como si fuera una estatua. Es muy poco realista. Imaginemos que un personaje recibe un tiro, y cae como un pisapapeles al suelo, la risión. Y ahí es donde entran los ragdoll, son sistemas que se encargan de hacer que las caídas de un cuerpo no animado sean naturales, que un brazo vaya por un lado y el otro por el otro, que se le doblen las rodillas al caer...




lunes, 6 de octubre de 2014

Túnel wormhole: 2001

El segundo efecto túnel que quería conseguir es la famosa escena de 2001: una odisea del espacio, no he encontrado el vídeo con la música original de la película, y puestos a elegir una sustitución me ha gustado este con Daft Punk. El túnel empieza como por el minuto 3. Aunque sea del final de la película lo podéis ver sin miedo a que haya spoilers, en general podéis ver cualquier trozo de 2001 sin spoilearos, porque ni viendo la película entera vais a estar seguros de qué va, qué ha pasado o cual es el mensaje. Se han escrito libros enteros al respecto, así que viendo 5 minutillos no pasa nada.






El efecto es maravilloso, del año 68, y todavía creo que es la escena con efectos especiales que más ha llenado una pantalla en la historia del cine. Se te llenan los ojos de colores, ver eso en un cine es maravilloso, una explosión sensorial. He intentado acercarme a la primera parte del túnel, la que es vertical, y he cogido ciertas características a imitar, sabiendo que no podría conseguir el mismo efecto exacto en el tiempo que tenía. El túnel vertical, que cada pared, izquierda y derecha pueda tener características diferentes, o colores distintos y que por las paredes no solo venga color de fondo, sino también líneas de otros colores.



Túnel 2001


sábado, 4 de octubre de 2014

Túnel wormhole: Coraline

Voy a pasar a comentar los 3 efectos que quería conseguir en el túnel. El primero es el de la película de Coraline. Me venía bien la propia forma conseguida en el túnel geométricamente. El primer paso era colorear el túnel y lo hice de forma procedural, mediante shaders.

Coraline

Para los profanos en informática gráfica: un shader es un pequeño programa que se ejecuta en tarjeta gráfica en una parte concreta del cauce de cálculos gráficos. Al ser la gráfica en realidad ciento de procesadores paralelos, cada uno tiene conocimiento de lo que esté manejando (su vértice, un fragmento a pintar...), pero no de los demás. Y podemos pasar una serie de parámetros desde el programa principal (cpu) al shader para que cambie su comportamiento. Acabo de resumir meses de estudios en un párrafo, pero espero que os hagáis una idea.

Túnel temet nosce

viernes, 26 de septiembre de 2014

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

Shaders en Unity3D
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...



miércoles, 24 de septiembre de 2014

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.

lunes, 22 de septiembre de 2014

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.




viernes, 19 de septiembre de 2014

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.


miércoles, 17 de septiembre de 2014

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. 





miércoles, 3 de septiembre de 2014

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.


lunes, 1 de septiembre de 2014

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.




viernes, 29 de agosto de 2014

Efecto Hitchcock

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



Este efecto, al que le doy ese nombre, y mucha gente lo llama efecto vértigo, por su uso en la película homónima (además de en muchas otras), según wikipedia se llama travelling compensado y los ingleses lo suelen llamar dollyzoom, lo cual como nombre de técnica sea seguramente el más acertado. Para mi el ejemplo que más se acerca al efecto que buscaba no es de Hitchcock, sino de Spielberg, en Tiburón, en el minuto 2 del vídeo.





miércoles, 27 de agosto de 2014

iTween Path: Ejemplos de uso

Ya he presentado los paths de iTween y los plugins relacionados. En este artículo voy a hablar sobre el uso que he dado a estos paths en los dos juegos de los que hablo en este blog.

Movimiento de cámara inicial en las Zamburguesas


Spline Zamburguesas

Antes de darnos el control en cada partida se muestra un poco el escenario en un movimiento de cámara inicial, como se puede ver en numerosas ocasiones en el vídeo del gameplay del juego. En la imagen adjunta se puede ver en rojo el path que sigue la cámara.

Lo único que hay que hacer una vez que tienes el path, es añadir un componente de tipo evento iTween a la cámara y configurarlo para que se mueva por ese path, en este caso elegí que lo hiciera en un tiempo dado (5,5 segundos). Lo malo de esto es que la velocidad que toma no es constante y depende de la distancia entre nodos, por eso es mejor dejarlos más o menos equiespaciados para que no se noten acelerones y frenazos.

lunes, 25 de agosto de 2014

iTween Path:Splines sencillas en Unity

La he presentado iTween, y he mostrado unos ejemplos de uso de mis juegos con este plugin de unity. Voy a seguir insistiendo con iTween, y que conste que no me llevo comisión.

iTween


En el plugin básico, además de la clase iTween, y una clase de eventos, viene otra clase, iTweenPath, con la que podemos crear rutas como splines sobre una serie de nodos. Si estáis más acostumbrados a los programas vectoriales es muy parecido a las curvas de Bezier. Pero es que además en el asset store se ofrece otro plugin, también gratuito, para poder crear en el editor, visualmente, estas rutas. Se llama iTween visual editor.

Hay un tercer plugin relacionado, también disponible en la asset store, y al igual que los otros dos, gratuito. Se trata de iTween multipath, un plugin para manejar distintos paths de forma conjunta. Este me parece útil porque los ejemplos que trae sirven para entender iTween Path, tampoco he llegado a usarlo mucho, aunque le veo posibilidades que voy a contar.

viernes, 22 de agosto de 2014

iTween: Ejemplos de uso

En al entrada anterior hice una presentación al plugin iTween. En esta voy a poner unos ejemplos del uso que he dado a este plugin en las 2 alphas de los juegos que presenté. Todo esto como parte del camino para llegar a la cámara que usé para los juegos.





En el vídeo se pueden ver todos los ejemplos de los que voy a hablar. Para ser sincero, la verdad es que no todos esos ejemplos estaban hechos con iTween en el momento de presentar los juegos, y en los vídeos que se mostraron, la mayoría si, y los demás los incluyo porque ahora estoy transformando ese código, que estaba hecho más rudimentario a iTween para tener un código más sencillo y uniforme. 


miércoles, 20 de agosto de 2014

Plugin de animación en Unity: iTween

Quiero explicar los problemas que he tenido con la cámara del juego, pero para llegar allí tengo que pasar por un par de plugins de Unity, que además son bastante útiles para multitud de cosas, por eso puede que me extienda varias entradas.

El plugin principal sobre el que descansan los demás es iTween. Es gratuito y está en la tienda de Unity. Lo que venden son packs con ejemplos, para que cojas ese código directamente, o aprendas el rendimiento que se le puede dar. Aún así con la documentación básica se puede tirar bastante bien.

Básicamente iTween ofrece la posibilidad de animar cosas de forma fácil. Y cuando digo animar cosas no es solo mover objetos, sino animar un cambio de color, de sonido, escalados, orientaciones, movimientos predefinidos, recorridos por splines, cámaras... 

lunes, 18 de agosto de 2014

Protagonista: Rigging y animación

Hasta aquí el personaje principal tenía el modelo hecho, arreglados los defectos, y ya lo he vestido. Así que para terminar solo queda que se mueva y haga cosas.

Rigging




Para poder animar un personaje, primero hay que ponerle huesos. Lo hice con un esqueleto predefinido de la colección CAT de 3Ds max, por lo que no tuve que hacer el esqueleto en si, hueso a hueso, poner las restricciones, uniones... pero si la parte final, el skinning, donde se asigna qué parte de la malla se ve afectada por el movimiento de cada hueso.


Rigging

miércoles, 13 de agosto de 2014

Protagonista: mapeado UV y textura

Hice un modelo mucho más complejo de lo que quería, y ya el reparar algunosdefectos se convirtió en pesadilla. Tenía el modelo completo, y pasado por chapa, faltaba pasar por pintura (es decir texturas) y que se pudiera mover.



Mapeado UV




El primer paso para poder pintar el modelo, es tener una conversión del modelo en 3D a un plano 2D donde poder pintar. Esto es el mapeado UV, y lo que se espera es que esté desenrollado de tal manera, que en una imagen 2D se pueda ver un poco las manos, parte de delante de la camiseta, una pernera... cosas reconocibles para poder pintar. Después de decirle al 3Ds max que hiciera el mapeado sólo conseguí un rebujo de líneas cruzadas en lo que sería imposible pintar nada sin dar el mismo color a 14 partes y no saber qué estás pintando (imagen superior). Intenté modificar los parámetros y se consigue algo donde se distinguen algunas partes, pero hay muchas partes pequeñas sueltas que no se sabe bien qué son, otras no tienen una proporción aceptable o tienen un patrón de corte horrendo.



Mapa UV de mierda
Mapa UV malo

lunes, 11 de agosto de 2014

Protagonista: Arreglillos en el modelo

Como conté en la entrada anterior, después de muchas horas de trabajo, tenía un personaje con 10 veces más polígonos de lo que quería, que no se parecía a lo que quería y feo, hecho por un novato y con poca mano.



Personaje
Pero los problemas estaban lejos de acabarse. La complejidad del modelo y otros errores hicieron que el resto del proceso de creación del personaje fueran un pequeño infierno. Me planteé varias veces tirar el personaje y volver a empezar, algo que haré ahora que tengo más tiempo. Pero entonces no me podía permitir arriesgarme a perder el tiempo empezando de 0, para en el peor de los casos volver a acabar en un sitio parecido y con mucho menos tiempo.



Así que voy a ir haciendo un recorrido por las distintas fases que le quedaban al personaje para poder meterlo en Unity y jugar con él. Lo primero, y de lo que trata este artículo: arreglar algunos defectos.


viernes, 8 de agosto de 2014

Protagonista: Modelado

Aparte del prototipo que hice en clase, la primera piedra del juego fue el diseño del personaje. Elegí empezar por aquí, porque como ya he dicho iba a compartir el personaje entre el juego Temet Nosce y el mini-juego de las zamburguesas. Así que si tenía el personaje, con todo, con huesos y animado, podría avanzar en paralelo en ambos juegos.

Además de que eso de llevar ambos a la vez fue imposible por la carga de trabajo del segundo cuatrimestre, no recomendaría trabajar en este orden. Creo que lo mejor es comenzar por prototipos, con toda la jugabilidad posible, hechos con cajas y esferas, y una vez que sea divertido en esta versión de “playdoh” pasar a hacer modelos y efectos para conducir esa jugabilidad a un juego completo.

Pero bueno, yo empecé por el personaje esta vez. Aunque me habían enseñado algo sobre como hacer un personaje (algo por encima), y si había echado unas cuantas horas pegándome con rigging y animaciones (con resultados decentes), era la primera vez que tenía que empezar desde 0 y hacer un personaje. Para TJ no hubiera necesitado hacerlo desde 0, pero para AC si, era parte de lo que se evaluaba. Además como ya conté en la entrada de ¿por qué hacerlo solo?, así aprendo como es el proceso de crear un personaje desde 0, y todos los problemas que puede llevar (que fueron muchos).

Como habían pasado meses desde que me lo habían enseñado y no había practicado, estaba bastante verde. Así que comencé a buscar tutoriales, sobre todo por youtube. Quería un personaje sencillo, básico, a mi nivel. Y buscaba que fuera con 3Ds Max, que era la herramienta que me habían enseñado y que tenía instalada. Tenía cierto sentido, aprender a hacerlo en lo que se supone por currículo que se manejar, y no perder el escaso tiempo que tenía en aprender otra.



miércoles, 6 de agosto de 2014

Protagonista: Diseño e inspiración

El protagonista de la historia es a quien el jugador va a manejar, y está constantemente en pantalla, por eso debe ser al que más tiempo se dedique. Y así ha sido, aunque los resultados no han sido los mejores. En este post voy a contar las intenciones, el equivalente al artwork (si yo fuera capaz de hacer semejante cosa) y en los siguientes explicaré como el diseño se fue yendo por donde no quería.

Protagonista de Temet Nosce
Yo soy muy malo dibujando, todo con práctica se aprende, pero yo necesitaría varias vidas para aprender a hacer los bocetos que veo hacer a otros en segundos. Por eso lo que en la mayoría de juegos es arte previo, creado por una artista, en mis proyectos en solitario, son imágenes de otros medios ya existentes que me sirven de referencia para expresar lo que quiero conseguir.

lunes, 4 de agosto de 2014

Gravedad: prototipo de mecánica de cambio de gravedad.




Todo tiene unos inicios. Temet Nosce lo tiene, y la asignatura de Tecnología de juegos lo tuvo. En esta asignatura tuvimos de entrada un par de sesiones intensivas donde teníamos que desarrollar un prototipo de un juego. Se hacía en grupos, pero al igual que el resto del juego, porque iba a ser proyecto fin de máster, tuve que hacerlo solo.



En la práctica tenía unas 6 horas de trabajo para presentar un prototipo al resto de la clase. Lo de ir solo en este caso fue una ventaja. Al tener el tiempo tan limitado, tener que ponerse de acuerdo entre varias personas en qué hacer, que hace cada uno y luego unirlo puede suponer más tiempo que el ahorro de varias personas trabajando en paralelo.



Mi idea fue jugar con la gravedad, que el usuario pudiera cambiar la gravedad de la escena para superar obstáculos. Comencé con una cápsula como personaje moviéndose por el escenario. La mayor parte del pequeño desarrollo se lo llevó lo que era en realidad la prueba: cómo hacer el cambio de gravedad, dónde poner la cámara, el movimiento del personaje... Es decir como encajaría esta mecánica en un juego.


viernes, 1 de agosto de 2014

Temet Nosce: Explicación del título

Temet Nosce

El juego se llama Temet Nosce, pero eso ¿qué significa? ¿Qué idioma es? ¿Por qué ese nombre tan raro? A eso voy a dedicar esta entrada, a contar de donde sale este título y la forma peculiar que tuve de elegir el título.

miércoles, 30 de julio de 2014

Las Zamburguesas


Antes de hacer el juego Tecmet Nosce, tenía que hacer un pequeño juego o una escena de un juego para Animación por computador. Se esperaba que demostrásemos que podíamos modelar algo, animarlo, insertarlo en Unity y manejar una cierta jugabilidad programando lo necesario, además de utilizar efectos de partículas. 


 

Para ese pequeño juego decidí hacer las Zamburguesas. Una prueba de humor amarillo en la que los concursantes tenían que saltar por unas piedras en un lago turbio, siendo algunas piedras falsas, provocando caídas.

lunes, 28 de julio de 2014

Las sombras del veneno II: Implementación

Esta va a ser la primera entrada algo técnica del blog. Tampoco mucho, la mayoría de conceptos se pueden entender siguiendo la lectura, aunque con conocimientos sobre generación de sombras y algo de Unity se saca todo el jugo.

Proyector de Unity


En la primera parte del artículo sobre las sombras del veneno, hablaba sobre la idea de que la sombra de un objeto fuera diferente a la que se espera que proyecte como recurso gráfico y narrativo.

Todo tenía buena pinta, pero llega el momento de ¿y eso cómo lo hago?. Partimos de la primera idea, que el héroe tuviera la sombra de otro ser. Por ejemplo que la sombra tuviera alas, como si fuera un Ángel.

miércoles, 23 de julio de 2014

Las sombras del veneno I: Diseño


En el mundo del 3D se nos enseña la importancia de la sombra de los objetos. Ayuda mucho a situarlo, sino muchas veces no sabemos si un objeto está situado más alto o más lejos de la pantalla.

Cuando pensé en que el juego iba a suceder en el subconsciente, un mundo ajeno a las normas físicas reales, podría jugar entre otras cosas con la sombra. Pensé que la sombra del héroe no correspondiera a su figura, que pudiera ser de un caballo, o cualquier otra cosa. No era el primero en jugar con esto, por ejemplo siempre me ha gustado mucho este póster.

Sombra Darth Vader Anakin Skywalker


martes, 15 de julio de 2014

El modelo del veneno



Es el enemigo común del juego, el que te vas encontrando constantemente. Tenía unas referencias claras en la cabeza que se resumen en una sola imagen.



Slime, Pesadilla antes de navidad, verde

¿Por qué hacerlo yo solo?

En general no es algo bueno para el producto. Tienes que hacerlo todo tú, y es imposible que se te de bien todo. En mi caso, por la rama de la que vengo se me da mejor toda la parte técnica, programación, IA, shaders gráficos... Y sin embargo flojeo en la parte artística: modelado, texturas, animaciones...

Por eso el producto mejor sería mejor en equipo, si consiguiera compañeros que suplieran mis carencias. Y además el desarrollo sería bastante más rápido. Al no ser bueno en estos campos, el tiempo que tengo que dedicar a ellos para lograr algo no demasiado cutre es muy alto y retrasa todo el desarrollo.

Temet Nosce

Así se llama el juego del que trata el blog. En esta entrada voy a explicar un poco de qué va.



Imaginemos un escenario típico de juego. El héroe luchando contra el monstruo final para rescatar de su secuestro a un ser querido. Consigue derrotar a base de mandobles a la temible bestia, misión cumplida. Pero sin darse cuenta, en un lance del combate, el monstruo le ha herido... y envenenado.



Así que nos trasladamos al subconsciente del héroe, que será donde jugaremos, desarrollando en forma de juego cómo el protagonista interiormente siente la lucha contra el veneno.




¿Mi primer juego?


Para mi lo es. Aunque técnicamente no es cierto.

Creo que va a hacer 10 años que descubrí el mundo de la programación, cuando comencé un ciclo superior de informática. Y el poder hacer videojuegos siempre ha sido algo que estaba ahí, me gustaba, curioseaba, he leído libros y hecho cosillas. Pero siempre me parecía algo que superaba a los conocimientos que tenía en ese momento. Hasta que habiendo terminado la carrera decidí ponerme en serio con ello y hacer un máster para poder aprender todo lo que quería.

lunes, 14 de julio de 2014

Presentación

Este blog trata sobre el desarrollo de mi primer videojuego. Aunque no solo va a ser eso, voy a recopilar todas las decisiones, problemas y soluciones que ya he tenido en el transcurso del desarrollo del mismo, y de algún proyecto satélite más.

Soy Ingeniero en informática (por la Universidad de Valladolid), y estoy a falta de proyecto para terminar el máster en informática gráfica, juegos y realidad virtual de la URJC. Precisamente el juego que va a ser el eje central de este blog va a ser mi proyecto de fin de máster.