Ninja II. Comportamiento y codificación.

En esta entrada vamos a ver con mayor detalle la codificación del ninja. Cómo hacemos para que a partir del modelo 3D y sus animaciones el personaje se mueva por el escenario cuándo el usuario le envíe las órdenes por teclado.

Las premisas de su comportamiento eran la de poder moverse por la aldea y mirar hacia cualquier dirección. Eso si, no podría dar marcha atrás. Para eso tendría que girar sobre sí mismo hacia la dirección a la que el usuario quisiera ir. Se podía haber hecho un comportamiento más complejo con sus respectivas animaciones, pero acotamos las funcionalidades finales a lo que teníamos hecho.

Para el movimiento se usó un Character Controller aplicado al ninja, el cual permite poder desplazarse por el terreno y tener un mayor control sobre el modelo. También nos permitía controlar las animaciones dependiendo de la acción que el personaje fuera a realizar.

Además, el ninja tiene configurado el componente Animator, el cual permite asignar las animaciones del modelo 3D a diferentes estados y relacionarlas entre sí. En el siguiente gráfico, sacado directamente de unity, podemos ver las restricciones que aplicamos a las animaciones de nuestro modelo:

Diagrama del componente Animator del ninja.

Las restricciones de las animaciones fueron básicas, ya que sólo teníamos la animación de idle (reposo) y la animación de ciclo de andar. Como se puede ver, entre las dos animaciones principales creamos unos movimientos intermedios (acelerar y frenar) los cuáles son parte de la animación del ciclo de andar y que hacen unión junto con la animación de reposo, para que el cambio entre animaciones no fuera tan brusco.

Las flechas del gráfico simplemente indican la restricción entre cada animación. Por ejemplo, de la animación de idle sólo se puede pasar a la de accelerate (acelerar), ya que no tendría sentido que pudiera pasar a la de brake (frenar) porque el ninja ya está parado.

En el componente Animator también definimos unas variables para poder poner los condicionales en cada flecha del gráfico. En nuestro caso la variable era la velocidad del personaje. Así pues, dependiendo de esa variable se le aplicaría una animación u otra.

Para aplicar cada animación es tan fácil como calcular su velocidad y actualizar la variable playerSpeed del componente Animator. En las siguientes líneas de código se puede ver un ejemplo resumido de como lo calcularíamos y le aplicaríamos la animación correspondiente:

function Start () {
  anim = GetComponent(Animator);
  controller = GetComponent(CharacterController);
}

function FixedUpdate () {
  velocity = Vector3(controller.velocity.x, 0, controller.velocity.z).magnitude;
  anim.SetFloat("playerSpeed", velocity);
}

El código está muy resumido pero solo es para mostrar que una vez se tienen creadas las restricciones entre animaciones, aplicar la animación concreta no es complicado. Lo que hacemos en el código es obtener la magnitud del vector velocidad en los ejes X y Z y aplicamos esa velocidad a la variable playerSpeed del componente Animator.

El personaje se puede controlar con las teclas AWSD o con las flechas de dirección. Para este caso solo se ha tenido en cuenta la disposición QWERTY para el teclado, pero con más tiempo se podría haber hecho una pantalla de configuración de teclas y que el usuario pudiera asignar las acciones de movimiento a sus teclas preferidas.

Para el movimiento de la vista una cámara sigue constantemente al ninja y si cambia de dirección lo sigue con un movimiento suave. La vista se puede controlar con el ratón en cualquier momento aunque el modelo esté en movimiento.

Cuando el usuario deja de mover el ratón durante unos segundos la vista se posiciona de nuevo detrás del ninja. Con este comportamiento se permite al usuario poder visualizar cualquier parte del escenario donde el pueda ir.

El movimiento de la cámara se ha limitado en algunas zonas para controlar que el usuario no pueda ver fuera del mapa. Por ejemplo, en el límite del pueblo donde hay el muro la cámara no puede traspasarlo y ver lo que hay en el exterior. También se ha aplicado el mismo comportamiento para las casas del pueblo y evitar que el usuario pueda ver su interior.

Resultado final

Seguidamente se muestra un video del movimiento final del ninja.



Esperamos que os haya sido útil :).

Ninja I. Diseño, modelo, rig y animaciones.

Modelo

Como ya avanzamos, usamos un modelo 3D realizado en blender ya hecho. Eso nos aportaba muchas cosas. Algunas buenas, unas no tanto y otras que simplemente nos aportaban cosas, ni buenas ni malas.

Por una parte nos ahorraba horas de trabajo porque ya estaba hecho de principio a fin. Ese punto fue decisivo. No disponíamos de tiempo para dedicarnos a hacer un diseño, modelarlo en 3D, texturizarlo y hacerle su correspondiente rig y su pesado (explicamos este proceso un poco más abajo).

Hay que pensar que ese modelo había que animarlo, y eso ya es mucho trabajo. De hecho, tuvimos que recortar gran parte de trabajo de animación, pero eso lo explicamos más adelante en el post.

Además, nos proporcionaba un contexto (Japón tradicional) y un estilo (cartoon). Este punto ni es positivo ni negativo. O se acepta o no se acepta. Pero como ya comentamos, nos venía muy bien porqué la ambientación que venía implícita nos gustaba mucho. No había que pensar en demasiado en el tema.

Ahora vienen los puntos negativos, que son unos cuantos. Todos estos puntos son del modelo en si. Este personaje fue el primer personaje de principio a fin que hizo una parte del equipo. Al ser el primero, salió con sus cositas.

El modelo se hizo con la idea de hacer algún corto o pequeñas animaciones. Es decir, estaba enfocado a animación y no a videojuegos. Eso es un problemón, ya que hay diferencias muy grandes entre hacer el modelo para una cosa u otra. El número de polígonos, quizás, es de lo que más se tiene en cuenta.

Otra cosa bastante evidente es que el modelo está hecho con polígonos de 4 lados. En animación hay que evitar los triángulos (entre otras cosas), que es justo lo contrario de lo que pasa cuando modelas para videojuegos. Aunque cuando se importa en unity el propio programa los transforma a triángulos, se debería hacer en el momento de modelado.

Pero además de que no estaba hecho para videojuegos, tenía los errores típicos que hace uno cuando empieza, y es que la malla no está muy limpia. Eso se nota mucho en los hombros, por ejemplo. Este tipo de cosas hace que aparezcan problemas cuando se anima (también lo explicamos más adelante en el post).

A pesar de todo ello, decidimos aceptar sus limitaciones en pro de todo el trabajo que nos ahorraba.

Rig y animación

El rig es el sistema de huesos que se crea en el modelo para poderlo animar. Además de los huesos hay que realizar el pesado para decirle al hueso que vértices de la malla debe mover. Hablando mal, seria decirle a cada hueso que parte de "chicha" del personaje le corresponde.

El modelo tiene un rig muy sencillito. Apenas tiene 4 cositas en el rig facial (mover la cabeza, cejas, ojos, orejas y mandíbula). La mayor parte del trabajo está en el cuerpo. Aunque tampoco le sacamos mucho provecho, ya que el número de animaciones se redujo muchísimo.

Teníamos pensado tener diferentes animaciones según las acciones que podría hacer el modelo, pero al final se quedó en un idle* muy sencillo y muy sutil y en un ciclo de andar neutro.

En un inicio queríamos que pudiera andar, correr y lanzar estrellas en el campo de tiro. Además, queríamos un par de idle diferentes. Uno muy sutil para que no se vea el modelo parado y también queríamos añadir alguna más con el personaje mirando de lado a lado, o cambiando de pie. Nos flipamos bastante. No es que quisiéramos hacer animaciones de luchas complejas, pero ya nos costó bastante acabar con las básicas. Además, llegamos a un punto de desgaste que había que cuidar mucho para no dejarlo sin acabar.

Pero finalmente se quedó solo con el idle sencillo y con el ciclo de caminar normal solamente :(.

Las animaciones, así como el modelo, tienen muchos fallos. A parte de la dificultad que lleva realizar un ciclo de andar, salieron algunos fallitos por culpa de la malla y su pesado. Cuando se realizan las animaciones o posados de un modelo en 3D es cuando aparecen los fallos de una mala disposición de los polígonos. Por muy bien que hagas el pesado, siempre toca arreglar este tipo de cosas.

Con blender se pueden resolver estas cosas arreglando la parte "rota" con el sculpt (es una funcionalidad con la que esculpir directamente sobre el modelo como si fuera de barro). Por ejemplo, en los hombros cuando se mueven los brazos a veces se ve un parpadeo en la malla. Para intentar arreglarlo hubiéramos tenido que esculpir para resolver ese fallo y animarlo de manera que aparezca el arreglo cuando la malla se rompe.

Pero como la textura del modelo era de azul oscuro y apenas se notaba en unity, decidimos que mejor sería invertir el tiempo en otras cosas más urgentes.

La animación del ciclo de andar se hizo sobre el sitio. Es decir, en blender no movemos al ninja en uno de los ejes para avanzar, sino que lo animamos todo en el mismo sitio para que luego desde unity se pueda configurar el movimiento más fácilmente. Esto lo explicaremos con más detalle en un próximo artículo.

A continuación os mostramos un pequeño video donde se puede ver el rig del ninja y como está animado:

Resultado final

Para poder usar las animaciones en unity, había que exportar el modelo a formato FBX. Desde el programa se importaba y detectaba las animaciones perfectamente.

Como ya hemos avanzado, más adelante os explicaremos más cosas sobre el personaje una vez ya en unity. Las fases de movimiento, las distintas animaciones y como se resolvieron algunas cosas con código. Ahora os dejamos con el resultado final del personaje en blender.

Esperamos que os haya resultado útil :).

*idle es un ciclo de reposo que se activa cuando el modelo en 3D no se mueve para que no parezca inanimado, por ejemplo, la respiración del personaje

Referencias II. Escoger un estilo.

Hasta ahora hemos hablado de referencias en general, sobretodo para escoger una ambientación y que todo tenga el mismo aire.

A continuación os mostraremos unos cuantas referencias más concretas de algunos de los objetos que queríamos poner en la demo...

Torii y puente

Cerezo en flor

Dianas de tiro, banco periodo Edo, puente y carro.

También encontramos referencias interesantes de ilustradores profesionales, como la que encontramos para el muro que delimita toda la aldea. En este caso es una ilustración de la ilustradora M. H. Chen.

Ilustración de distintos tipos de muros de M. H. Chen.

Croquis del mapa de la aldea

Nos hubiera encantado tener las suficientes dotes artísticas como para ponernos a diseñar en 2D los objetos y así poder concretar un estilo sin tener que hacerlo directamente en 3D. Ganas tiempo y aporta mucha riqueza al resultado final.

Las ideas siempre funcionan muy bien en la cabeza, nunca fallan. Hay que ponerlas sobre papel para comprobar que la idea se tiene muy clara y poder resolver más rápidamente las dudas que surjan.

Una vez que teníamos la lista de los objetos que más o menos queríamos que aparecieran, nos hicimos un croquis del mapa de la aldea (a la izquierda del texto).

Estilo

A la vez que uno busca referencias para decidir la ambientación, los personajes e incluso la historia o motivo de la demo, pensamos en un estilo concreto.

En nuestro caso, una vez más, al querer usar el ninja ya creado, el estilo cartoon también venía implícito. Se podría haber intentado hacer algo más trabajado e intentar combinar el personaje con una ambientación menos caricaturesca. Pero una vez más, esa falta de tiempo y recursos nos obligó a seguir con el mismo estilo que el que tenía nuestro personaje principal.

Hay que dejar claro que nunca nos molestó que usar un diseño del personaje principal ya hecho nos hizo aceptar una serie de cosas de forma obligada. La temática de Japón y el estilo cartoon que nos daba el ninja nos parecían fenomenales :). Aportaban mucha riqueza y es un tema universal que siempre gusta.

En el próximo post nos pondremos con las manos en la masa y os mostraremos detallitos de nuestro protagonista.

Cómo. Qué. Quién. Dónde. Cuándo. Por qué.

Una vez analizadas las herramientas que queríamos usar y después de realizar tutoriales e ir probando el entorno de Unity (nuestro Cómo), nos lanzamos a realizar un brainstorming para sacar ideas de que podríamos hacer nuestra primera incursión en el mundillo dominguero de los videojuegos.

Sabíamos que queríamos algo en 3D. Ya tenemos el Qué. Por tanto, poco o mucho, necesitaríamos un montón de material en tres dimensiones y, a no ser que hiciéramos un juego de carreras (espaciales o no) necesitaríamos a un protagonista… ¡animado!

Aún no habíamos empezado y la perspectiva ya se tornaba complicada...

Personaje. En Blender

Pero se dio el caso que nuestra parte tresdesera del equipo había diseñado, modelado y riggeado* un personaje en 3D completamente con Blender. Y por si fuera poco, era un ¡ninja!… ¿hay algo que mole mas que un ninja? Así que ya teníamos protagonista bytheface, nuestro ansiado Quién.

Nos embarcamos en crear algo ambientado en Japón que nos permitiera usar a nuestro nuevo amigo y nos ahorrara faena para poder desarrollar la idea sin que una montaña de trabajo casi infinita se nos viniera encima.

Que el personaje sea un ninja ya pone muchas cosas en contexto, y la cultura japonesa está implícita y nos resuelve el Cuándo y el Dónde.

Para la ambientación miramos qué épocas podían estar chulas para buscar referencias y que existieran los ninjas. Investigando en Google sobre ellos, dimos con un artículo interesante que hablaba sobre las épocas donde los ninjas tuvieron un protagonismo importante. Después de ver distintas épocas y períodos, nos decidimos por el que más nos gustó: el periodo Edo.

Periodo Edo. Artista: Kano Einō (Japanese, 1631–1697).

Nos gustó porqué su arquitectura era lo más parecido a lo que teníamos en mente. Torii, estanques decorativos, tejados en U, etc., son algunas de las características que más conocemos de Japón y que se empezaron a usar en esta época.

Eso es muy importante porqué si hay que modelar escenarios y props* hay que saber en qué momento de la historia estará ambientado. No es lo mismo modelar un coche en los años 80 que en la época actual.

Nos confesaremos antes de empezar. Esto no será un ejemplo de rigor histórico. Simplemente necesitábamos una referencia en la que basarnos para modelar las distintas cosas y que no parecieran de épocas totalmente diferentes.

Pensar que solo buscar trabajo de documentación para la ambientación y crear los diseños conceptuales para definir el estilo ya es una profesión en si misma, así que no nos podíamos permitir el lujo de invertir demasiado tiempo en estas tareas porqué corríamos el riesgo de quedar estancados. Al fin y al cabo, con crear algo con cierta coherencia nos bastaba. Simplemente era tener algo en lo que basarnos para no partir de cero.

Aunque, para ser sinceros, después estuvimos viendo objetos de otras épocas y mucha diferencia no veíamos. Suponemos que escoger Japón como tema central tiene estos inconvenientes, siendo una cultura tan tradicional.

Por tanto, antes de empezar, pediremos disculpas por nuestros errores garrafales históricos que puedan existir, y si herimos la sensibilidad de algún ojo experto.

Bien bien, nos queda solo el Porqué. Ahí va la segunda confesión. Nos flipamos. Aunque creemos que no se nos fue de las manos. Y eso es importante.

Pensamos en un juego más o menos viable. Si. Un juegazo entero con sus niveles y sus bosses. Pero no lo pensamos con detalles, sino con una idea que podría funcionar. A partir de ahí, nos dijimos que la parte que desarrollaríamos seria la típica escena del juego donde el personaje principal se detiene para entrenarse y subir niveles, descansar, curarse, comprar armas y pociones de salud, etc. Esta seria nuestra pequeña aldea de descanso.

Es decir, pensamos en un juego que podría estar guai, pero acotamos mucho lo que podríamos y no podríamos hacer. Creemos que esa es la clave para no rendirse ni aburrirse de la idea. Haz algo que creas que puede funcionar pero sabiendo donde están tus límites.

Eso no quita que no te acabes flipando y pensando en muchas más cosas para hacer de las que realmente se puede. A nosotros nos pasó y nos seguirá pasando. Siempre te flipas, hay que aceptarlo, es un hecho. Es más, si un día no pasa, es para preocuparse. Si cuando uno piensa en hacer algo que le gusta mucho no se viene arriba es que no tiene la suficiente ilusión.

Siempre piensas en todas las cosas que te gustaría que estuvieran hechas. Esas ideas salen principalmente de nuestro bagaje como jugadores, con lo cuál es normal pensar en cosas que nos pueden venir más o menos grandes. Al fin y al cabo, no nos podemos comparar con empresas que sacan productos para hacer negocio y poniendo una inversión y recursos importantes.

¡Por fin! ya teníamos todas las incógnitas resueltas. Ahora era cuestión de empezar a planear el escenario para saber que elementos nuevos había que crear para poder buscar referencias, modelarlos y texturizarlos.

A esa lista de props había que sumarle qué acciones podría hacer el personaje principal para empezar a planificar las animaciones.

¡Bufff! Cuánto trabajo se nos vino encima. En los siguientes posts veremos los primeros modelos que hicimos.

*crear el rig de un personaje es crear el sistema de huesos para poder animar un personaje u objeto.

*los props son los objetos y atrezzo que crearemos para el juego