Problemas en el movimiento del personaje

Este artículo va a ser un poco un cajón de sastre sobre todos los aspectos del movimiento del personaje que no he tratado ya. 

En la parte de ataque finalmente he dado 3 movimientos de ataque, lo cual lleva 7 animaciones, las cosas se complican. Si damos al botón de ataque el personaje dará una estocada, y si no hacemos nada más volverá a posición neutral. Eso ya son 2 animaciones. Pero si mientras da la primera estocada, volvemos a dar al botón de ataque hará un segundo ataque, un combo. Así que hace falta la animación del segundo ataque y la de volver a posición neutral desde el segundo ataque. Ya van 4 animaciones, y también he dado opción a atacar mientras estamos en el aire. Esto es un poco más complicado, tiene la animación de coger impulso en el aire para dar el golpe, después una pequeña animación de 2 frames que es la de caer dando el espadazo, que al no saber cuánto vamos a caer necesitamos una pequeña en bucle, y por último la de acabar de caer y recoger hacia atrás. En total 7.

Efecto de estela

Ya tengo el personaje con todas sus acciones básicas del juego cubiertas, anda, corre, salta, cambia la gravedad y ataca con la espada. Esto último es nuevo, en el próximo artículo explicaré varios problemas que he tenido juntando todos los movimientos, los tipos de ataque de espada, etc, en este quiero explicar como he hecho el efecto de estela al atacar con la espada.

Una vez que tienes las animaciones de los espadazos y lo programas para que los de al dar a un botón, te encuentras que es algo soso. Así que empecé a buscar cómo hacer que la espada tuviera un efecto de estela, estuve viendo videos de Medievil y tiene ese efecto, una estela blanca, y me di cuenta que era útil por varias razones, te da tiempo a ver qué dirección toma un movimiento de espada, queda visualmente curioso, y también disimula un poco si la animación no es excepcionalmente buena.

Colocar un arma en Mecanim

Hoy estoy contento, he conseguido solventar un problema que llevaba arrastrando meses, con buen resultado, me abre unas cuantas posibilidades y además lo he hecho trasteando, no encontré la solución en don google. El problema de unir la espada a la mano del personaje.

No es la primera vez que escribo sobre este problema, hice un artículo sobre cómo poner la espada en la mano al personaje en 3Ds max. El problema era que el formato FBX no soportaba las restricciones con las que se hacía, así que no funcionaba en Unity. Eso, y cómo lo solucioné metiendo la espada como parte del mismo modelo lo comenté en otro artículo sobre los problemas de exportar de 3Ds max a Unity. Eso hacía que funcionasen bien las animaciones de Mecanim sobre un modelo con espada, pero la espada era parte del cuerpo. Eso me preocupaba ya que no podría poner un collider solo a la espada para ver si golpeaba a un enemigo. Pero ahora me encontré otro problema, los sistemas que hay para hacer estelas (trails), para dar ese efecto cuando se moviese la espada, no funcionan bien si no tenemos la espada como una parte independiente.

Salto incremental con el controlador de Unity 5

Con el movimiento del personaje ya conseguido me faltaba mejorar algunas cosas, por ejemplo hacer el salto incremental, que cuanto más tiempo dejemos pulsado el botón de salto más alto salte. Algo sencillo en principio, además que ya lo tenía hecho en el controlador viejo, pero las cosas a veces se complican.

La idea básica es dar un impulso inicial al salto cuando se presiona el botón y en cada frame ir aumentando un poco ese impulso si el botón sigue pulsado hasta un tiempo máximo de pulsación del salto. En peras y manzanas: Si pulsas el botón una décima de segundo saltará 1 metro, si pulsas 3 décimas saltará 2 metros, si pulsas medio segundo saltará 3 metros y si dejas el botón pulsado 35 años saltará 3 metros igual que es el máximo.

Migración a Unity 5: cambio de gravedad

En el último artículo dejamos al personaje moviéndose por la escena. Quería como siguiente paso ver si era capaz de hacer una de las partes que tenía hechas en el SuperCharacterController pero no integradas en mi proyecto, las referentes al cambio de gravedad.

Al ser un ejercicio académico lo más importante aquí es aprender. Por eso aunque el trabajo realizado en los cambios del controlador de personaje anterior no se va a usar en el juego final, todo lo que me tuve que pegar con los giros, cuaternios y direcciones de la gravedad me sirvió para aprender y poder realizarlo en el nuevo controlador en menos tiempo. Incluso algunas de las funciones, como la que calcula los ejes más cercanos a un vector las he podido reutilizar.

Migración a Unity 5: El personaje en movimiento

Al final me he puesto en marcha en la tarea de migrar el juego a Unity 5. He tenido que comenzar un proyecto desde 0 e ir añadiendo las piezas que tengo poco a poco. Hay cosas que tendré que sacrificar, otras hacerlas de otras maneras, pero va a aumentar la calidad, y puedo hacerlo todo con la versión gratuita sin recurrir a la pro de formas poco limpias.

Lo primero ha sido colocar el Skybox (al que por cierto he dado una capa de niebla azulina para que parezca más lejos), el personaje, e internar que se mueva correctamente. El sistema de controlador para personaje que tiene incluido Unity 5 es bastante mejor que la mierda que tenía hecho el obrero en la versión anterior. Así que he probado si podía usar su sistema, mortificándolo a mi gusto para que funcione como el que tenía, y fiarme también de su sistema físico y de colisiones. Esto significaría tirar el trabajo que hice adaptando el SuperCharacterController, pero creo que merece la pena. Lo tenía funcionando en un proyecto aislado, de prueba, y estaba teniendo problemas para integrarlo con el proyecto del juego. Y tampoco se llevaba bien con las animaciones de Mecanim.

Primeras impresiones de Unity 5 (II)

En el último artículo ya comencé a contar mis primeras impresiones sobre Unity 5. En este voy a seguir con algunos elementos más, y no creo que sea el último.

Elementos Pro a Personal

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

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

Primeras impresiones de Unity 5 (I)

La semana pasada en la GDC se anunció la liberación inmediata de la versión definitiva de Unity 5. Que básicamente mete mejor iluminación, y casi todo lo de pago en Unity 4 es gratis en Unity 5. Así que me he puesto a curiosear con la nueva versión, para ver sus posibilidades y si puedo migrar mi proyecto de 4 Pro a 5 Personal y así poder usar algunas nuevas características. Voy a exponer mis primeras impresiones.

Mecanim

Mejora la interfaz para usarlo y añaden más complejidad, que hacen más sencillas algunas cosas. Ahora hay una columna en el editor de Animator para ver los parámetros y las capas, para que estorben menos en el diagrama de la máquina de estados.

También mejora las formas de hacer el blending de animaciones. Aunque mucho de este trabajo se ha ido metiendo en la versión 4 en sus diferentes actualizaciones, lo que había hablado en el artículo de introducción a Mecanim era lo que se podía hacer desde la 4.0. Ahora hay más opciones para hacer el blending.

Skybox de la primera pantalla

Una de las cosas con las que quería trabajar es el Skybox. Ese fondo del juego inalcanzable que ponemos. Normalmente se trabaja con cielos, horizonte, eligiendo entre nublado, día, noche y poco más. Y quise hacer algo distinto. Si estamos en un mundo onírico y fantasioso no es muy inmersivo que el fondo sea de lo más normalucho.

Una de las primeras ideas fue 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 primer referente de que la dirección de la gravedad en un mundo imaginario no tiene por que ser la normal. Pero no funcionaba, el fondo llamaba demasiado la atención, y parecía completamente desconectado del escenario que vamos pisando. Daba la sensación de que el escenario estaba flotando dentro del skybox, algo que es cierto pero que no debería notarse tanto.