lunes, 26 de diciembre de 2016

Texturización. Nuestro pipeline.

En esta entrada explicaremos nuestro pipeline cuando hacemos un modelo 3D en blender. No os vamos a descubrir ningún misterio si sabéis algo del tema, pero ya que no os podemos contar más detalles del nuevo proyecto porqué, como ya sabéis, trabajamos en nuestros ratos libres, nos parece buena idea comentar cualquier tema que pueda interesarle a alguien.

Lo primero de todo, necesitamos el modelo en 3D. Un modelo en 3D nunca está finalizado hasta que no esté posicionado en las coordenadas (0, 0, 0) y con su UV hecha.

Lo de las coordenadas es para poder mover el modelo de un programa a otro sin tener sustos de posicionamiento. Por ejemplo, cuando importamos un objeto a unity y queremos aplicarle alguna funcionalidad, puede ser de vital importancia que sus coordenadas no vengan con algún desfase heredado, ya que programar algún comportamiento se puede convertir en una auténtica tortura. Este punto lo desarrollaremos un poco más en un artículo futuro, ya lo veréis :).

La UV es necesaria, a parte de para "pintar" el modelo, para cuando exportemos e importemos el modelo. Ya que se llevará consigo esa información y así podremos aplicarle la textura que queramos en cualquier software.

Pero, ¿qué es una UV? Pues es el modelo en 3D "abierto en canal" para poder texturizarlo en un editor de imágenes (como photoshop, gimp, etc) o incluso desde el propio blender, si tenéis cierta maña para pintar encima.

Lo más importante es saber donde hacer los cortes para que en la malla desplegada resultante se vean lo menos posible esas juntas. Para un modelo sencillo como una caja, no hay mucho misterio, pero para un modelo más o menos complejo, es relevante encontrar la mejor manera de hacer esos cortes y a la vez enfatizar esas partes donde es más importante tener más resolución. Por ejemplo, para un personaje, dependiendo de su finalidad, podría ser muy interesante que la parte de la cabeza ocupe más espacio en la UV que el resto del cuerpo, ya que va a tener más detalle.

No nos extenderemos en como se hace una UV porqué hay miles de tutoriales por internet y tampoco somos unos gurús del tema, pero solo con hacer una simple búsqueda en google, podremos ver ejemplos de distintos modelos. También podréis encontrar información en la página de unity sobre UV que puede ser interesante.

Ahora sí, lo que os queríamos comentar era nuestro itinerario una vez hecho el modelo en 3D.

A diferencia de con el Torii, "colorearemos" los modelos de distinta forma. Ya avanzamos en el primer tip del blog por donde irían los tiros hablando de los atlas de color. Para nuestro nuevo proyecto hemos decidido simplificar el proceso. En vez de crear una imagen para cada modelo, crearemos una imagen base y la usaremos en todos los modelos.

Podríamos ir a lo bruto y no molestarnos en hacer las UV, coloreando directamente los polígonos, pero si más adelante cambiamos la manera de hacerlo, tendríamos que hacer todas las UV de golpe y sería demasiado tedioso. Realmente no se notaría la diferencia de si hacemos correctamente la UV o no, pero es más por un tema de orden y limpieza.

Así que una vez terminamos de modelar, hacemos la UV y distribuimos los trozos de esa UV que nos interesen en los colores que creamos de nuestro atlas de color.

Por ejemplo, si tenemos como modelo un coche, crearemos su UV haciendo los cortes en la malla correspondientes y pondremos el chasis en el rojo, las ventanillas en el azul claro, las gomas de las ruedas en el negro, etc.

Pero como una imagen vale más que mil palabras, os mostramos como quedaría la UV de un macetero con el atlas de color que hemos realizado para tener todos los colores básicos en un solo archivo:
UV y atlas de color de un modelo sencillo.


De momento hemos decidido que crearemos varios atlas de color. Usaremos uno base para todo donde estarán todos los colores genéricos (rojos, azules, verdes, amarillos, etc). Pero además creemos que estaría bien tener atlas específicos para zonas concretas de la ciudad o incluso modelos. Por ejemplo, tener un atlas de color de todos los verdes posibles para las zonas de bosque, ya que si usamos el atlas base, nos faltarían tonalidades. Y aprovechando esta situación, donde tendremos las UV's de los árboles posicionadas, podríamos cambiar el atlas de color de tonos verdes por uno de tonos naranjas para los árboles de otra zona y cambiarlo todo de golpe sin necesidad de rehacer las UV's. It's magic!

Aplicando esta manera de trabajar, podemos crearnos un atlas (o los que necesitemos) para añadir texturas más complejas a los modelos. Por ejemplo, podríamos tener un atlas para las señales de tráfico, donde en vez de colores tendríamos las imágenes de los stops, límites de velocidad, etc.

Evidentemente, todo esto es factible hacer si el estilo que se le quiere dar al juego acompaña. En nuestro caso, seguimos con el estilo cartoon, por tanto, podemos permitirnos el lujo de crear una textura con colores planos. Incluso para nuestro atlas de señales de tráfico, el pupurri de imágenes no desmerecerá el resultado final, ya que no es necesario que tenga miles de píxeles de resolución porqué se verá desde lejos.

Para acabar con el artículo, os dejamos nuestro primer atlas de color para que podáis utilizarlo si os gusta :).
Atlas de color de Un juego a ratos.
De momento, eso es todo en cuanto a texturización. Cuando haya más novedades en un futuro, os las contaremos. Y, por favor, si tenéis cualquier pregunta o queréis hacer alguna aportación o corrección, no dudéis en comentar, ya que nosotros también estamos aprendiendo a base de prueba y error :).

jueves, 22 de diciembre de 2016

TIP#1. Atlas de color.

Inauguramos sección de nuestros tips  para hablar un poquito de blender. Así, nuestro primer tip de la sección será para comentar maneras de texturizar.

Hasta ahora lo que hemos ido haciendo para texturizar (para Torii, por ejemplo) era crear el modelo en 3D, sacar su UV y "pintarla" desde el propio blender o desde cualquier programa editor de imágenes.

Otra manera de conseguir lo mismo, "colorear" un modelo, es con un atlas de color. Que básicamente se trata de poner en una sola imagen todos los colores que necesitemos y aplicar esa textura al modelo. La única diferencia será que cuando creemos la UV, posicionaremos cada parte del modelo en el color que nos interese.

Como veréis, es el mismo proceso pero al revés. Con el primer método, hacemos la UV, posicionamos las partes como mejor creamos para texturizar correctamente y "coloreamos". Con el atlas de color, hacemos primero la textura que creamos y al hacer la UV posicionamos las partes del modelo en el color que necesitemos.

Por ejemplo, si tenemos como modelo un coche, crearemos su UV y pondremos el chasis en el rojo, las ventanillas en el azul claro, las gomas de las ruedas en el negro, etc.

Este método es especialmente útil cuando creemos que podemos aprovechar una misma textura para varios modelos.

Además, se puede crear un atlas de color con texturas, de manera que podemos tener una única textura con imágenes y no colores planos. A continuación os mostramos una imagen para todos conocida de Minecraft que explica lo que comentamos:
Textura de minecraft.
Textura de Minecraft.
Con este proceso conseguimos evitarnos hacer una textura por modelo, ahorrando espacio y tiempo. Además, podemos crear nuevas texturas mucho más fácilmente y aplicarlas solo arrastrando la nueva imagen al modelo.

lunes, 19 de diciembre de 2016

Algunos detalles del nuevo proyecto.

Aunque aún nos faltan por cerrar muchos detalles, queríamos comentar un poco más lo que tenemos en mente del nuevo reto para que no suenen a chino los artículos que vayamos subiendo. Si en algún momento cambiamos alguna decisión, lo iremos explicando durante el proceso.

Ya hemos avanzado que queremos hacer algo con coches y después de una lluvia de ideas y meditar un poco los pros y contras de cada una, nos hemos decidido por hacer que el coche sea el protagonista y los objetos que transporte una parte muy importante de la jugabilidad. Habrá una historia de fondo con su hilo argumental, pero, a falta de desarrollarla, de momento decidimos que sea un juego de misiones que el jugador realizará en todo momento con el vehículo que lleve en ese instante.

La historia está aún por pensar en detalle. Seguramente tiraremos por algún argumento cliché, como el del chico/a que trabaja para alguna organización criminal (mafia, quizás) y tenga que ir subiendo su rango a través de las misiones que le darán puntos según lo bien que lo haga. Eso si, intentaremos darle algún toque creativo a falta de una idea innovadora.

Dadas esas premisas el escenario será urbanita, aunque podría ampliarse a zonas rurales (pueblecitos), zonas desérticas, montañosas, etc.

Aunque no hemos detallado mucho, lo importante ahora es saber que:
  • El jugador llevará un vehículo.
  • El escenario será una ciudad con posibilidad de ampliar zonas como desiertos, zonas rurales, montañosas, etc.
  • Los objetos que el jugador transporte en su vehículo serán una parte importante de la jugabilidad y el argumento.
  • El jugador tendrá que realizar misiones para mejorar su rango y avanzar en la historia final.

Estilo

Aunque esta vez no tenemos ningún modelo ya hecho que nos "obligue" a seguir un estilo concreto, decidimos seguir con nuestro amado estilo cartoon.

Dada la idea que teníamos con lo que queríamos hacer, hemos pensado que estaría bien añadirle un toque lowpoly. Porqué al querer hacer una ciudad, tenemos pensado que se vea el juego desde cierta altura. Quizás una vista isométrica. Todas estas premisas hace que para nosotros cuadre el estilo.

Además, a parte de que nos gusta mucho ese toque, no hay que olvidar que también nos irá bien por un par de cosas. No tenemos que detallar tanto los modelos y no habrán tantos polígonos en pantalla, que siempre viene bien para tener un buen rendimiento.

lunes, 12 de diciembre de 2016

Nuevas ideas y nuevo funcionamiento del blog.

Hola a todos!

Bien, como habréis podido ver todos los artículos que hemos ido subiendo son de hace relativamente poco. Este blog lo hemos empezado una vez pasado un tiempo de haber acabado el proyecto del Torii.

Pero aunque no hicimos el blog mientras desarrollábamos el proyecto, toda esta información la íbamos guardando en un documento, así que plasmarla aquí no ha sido demasiado costoso.

Por cierto, no olvidéis pasar por el artículo de la demo y probarla :).

Pero, ¿y ahora?. Pues estamos empezando un nuevo desafío. Ya veremos en que acaba, y ya veremos si acaba, pero nuestra intención es la de ir publicando (ahora sí) artículos explicando como va el nuevo reto, más o menos, a la vez de su desarrollo.

Estamos barajando diferentes posibilidades sobre el nuevo proyecto, pero algo que de momento sabemos es que pensaremos en "algo" que tenga que ver con coches. No nos podemos extender demasiado en la historia que tendrá, puesto que de momento no tenemos una idea concreta, pero si que nos hacía gracia tirar por algo totalmente distinto.

En un principio incluso pensamos en hacer algo en 2D, para dar un giro radical a lo que habíamos hecho hasta ahora, pero después de varias pruebas lo dejamos en stand by para seguir por la línea tresdesera como hasta ahora.

De momento no podemos decir mucho más, porqué aún estamos concretando temática y reorganizando el blog, así que intentaremos avanzar más información la semana que viene :).

El blog

También os queríamos comentar como funcionará el blog a partir de ahora. Aunque no cambiaremos demasiado el funcionamiento, si que nos gustaría avisar de lo que puede pasar.

Como no tenemos el proyecto terminado, a diferencia de con el anterior, iremos actualizando cuando podamos. Hasta ahora publicábamos un artículo cada lunes y jueves prácticamente.

A partir de ahora, intentaremos seguir publicando un nuevo artículo los lunes (o martes a muy tardar). Ese será nuestro mínimo que intentaremos respetar. Lo de los jueves ya no lo tenemos tan claro.

Pero si que nos gustaría inaugurar una nueva sección de tips (mayormente sobre unity o blender) donde os comentaremos cosas que nos hemos ido encontrando, ya sean problemas y soluciones, pequeños tutoriales o explicaciones genéricas. Siempre, evidentemente, orientado a todo lo que vayamos necesitando para el nuevo proyecto.

Si todo va bien, y podemos ir generando cada semana un artículo sobre el nuevo desafío, intentaremos que los tips se publiquen en un segundo día durante la semana (podríamos retomar los jueves como rutina), pero no lo sabremos hasta que veamos si podemos generar un mínimo de contenido semanal.

Lo que sí sabemos es que no siempre habrán artículos de este tipo, sólo cuando nos vayamos encontrando con algo suficientemente interesante como para pararnos un minuto y pensar sobre el asunto. Si tenéis alguna recomendación o queréis que miremos algo concreto, no dudéis en decírnoslo en los comentarios o a nuestro mail :D.

Dicho esto, sólo queda empezar de nuevo. No sabemos como irá, pero seguro valdrá la pena!

lunes, 5 de diciembre de 2016

El juego.

A continuación, os incrustamos a Torii en esta entrada. Para poder ver el resultado final os daremos dos maneras de hacerlo.  Una, desde este mismo blog. Eso si, para que no se cargara el juego solo por entrar a la página, lo hemos puesto dentro del mismo artículo. Tendréis que darle al botón de "Continúa leyendo" que aparece abajo para ver el contenido entero del artículo. Dentro veréis que tras esperar uno o dos minutos (dependiendo de vuestra conexión) se cargará el juego.

La segunda manera, y la que os recomendamos, es vía un enlace que hemos puesto dentro del artículo. Podréis verlo mucho más grande e incluso podréis verlo a pantalla completa si apretáis el botón azul de la parte inferior derecha. No sabemos porqué, pero desde el propio blog, este botón no funciona :(.

Esperemos que os haya gustado el proceso :).

jueves, 1 de diciembre de 2016

El final de Torii.

Se acabó. Hasta aquí habíamos llegado. Ya teníamos una primera versión del juego terminada y sólo nos quedaba decidir si la continuábamos mejorando añadiendo todas esas cosas que se habían quedado en el tintero y añadir nuevas, o bien dejarlo por terminado.

Optamos por la segunda. Cansados de tantos meses dedicando gran parte de nuestro tiempo libre al proyecto tuvo su desgaste. Pero no fue una decisión amarga, al contrario. Quedamos muy contentos con el resultado a pesar de los inconvenientes y que acabó siendo un "walking simulator", sabiendo, claro está, que había cosas que podrían haber quedado mucho mejor.

Resultado final del Torii.


Estos son algunos números:

Tiempo invertido. Empezamos a planificar en el mes de agosto de 2014 y sacamos la primera versión del juego en abril de 2015. Aunque hace prácticamente una semana actualizamos ciertas partes del código programado con la nueva versión de unity (versión 5.4.2)* y poder subirlo con a las nuevas versiones de los navegadores. Podríamos decir que invertimos parte de nuestro tiempo libre durante 8 meses.

Dinero invertido. Estos números son fáciles. Compramos un pack de la asset store por unos 25 euros.

Espacio total. La carpeta que contiene el juego ocupa 3,65 GB.

Pero vamos a hablar de las cosas buenas con las que nos quedamos y de las malas que nos hubiera gustado mejorar.

Si ahora tuviéramos que empezar seguramente intentaríamos mejorar el modelo. Hacerle la retopología de la malla de nuevo para crearla acorde a los requerimientos de un videojuego como limitar los polígonos necesarios.

Volver a hacer el rig y su pesado da mucha pereza, pero viendo lo poco que necesitamos para las animaciones, seguramente se podría haber hecho un sistema de huesos más sencillo que el que tiene ahora.

También nos hubiera gustado intentar mejorar el rendimiento, ya que apenas hemos invertido tiempo para mejorar la caída de FPS cuando hay demasiados polígonos en pantalla. Al final no hicimos nada al respecto porqué la única solución que se nos ocurría era o limitar los objetos en pantalla (algo que ya redujimos bastante cuando empezamos a darnos cuenta del problema) o programar las distancias y que solo cargase los objetos a cierta distancia. El problema de la segunda opción es que el mapa es muy pequeño y decidimos que para esta vez, mejor dejarlo así.

Cabe decir que no sabemos que ha pasado con la versión que teníamos anteriormente, pero al modificar el código para esta nueva versión de unity (la 5.4.2)* y poder volver a sacar una versión actualizada del juego, hemos notado que va bastante peor que antes. Y ya no decimos con respecto a verlo ejecutado desde el propio unity donde va infinitamente mejor que en el navegador.

Aquí llegamos a un punto que nos gustaría mejorar. El recurrente "lo dejamos así porqué no tenemos tiempo". Aunque no sabemos muy bien como podríamos cambiar eso cuando "sólo" le estamos dedicando tiempo libre. Y en realidad, este tipo de decisiones las vivimos en el día a día de nuestras profesiones donde nunca hemos estado en un proyecto donde existiera el tiempo infinito para poder hacer el producto perfecto.

Solo nos queda destacar las partes buenas con las que nos quedamos del proyecto y en nuestro caso, es el proyecto en si. Estuvo chulo hacerlo y ha quedado resultón. Es una versión light de lo que pretendíamos, pero tampoco nos quedamos muy lejos de la meta.

Al final podemos decir que hemos aprendido un montón de cosas nuevas. Muchas de ellas han sido por las malas. Y aunque algunas no las hemos podido mejorar, nos hemos quedado con la lección aprendida para la próxima.

En definitiva, acabamos cuando teníamos que acabar y pasado un tiempo, pensaremos en el siguiente proyecto para empezar.

Esperamos que toda esta información que hemos puesto en el blog os haya resultado útil. En el próximo artículo pondremos el juego disponible para que lo probéis si queréis.

¡Hasta la próxima!

*unity 5.4.2 ya no es la versión más nueva, justo estos días se ha actualizado unity a la 5.5.

lunes, 28 de noviembre de 2016

Sonidos, música y portada.

Audios

Para los sonidos no fue muy difícil encontrar recursos, aunque si que nos ocupó su tiempo encontrar justo los que queríamos.

Para los sonidos del juego usamos la web del banco de recursos del ministerio donde puedes obtener casi cualquier tipo de efecto. También se pueden encontrar sonidos en otras páginas, como por ejemplo en Youtube.

Estos sonidos fueron las pisadas del ninja dependiendo del suelo. Siempre suena el mismo sonido de tierra excepto cuando está pisando madera, como la del puente. Lo hicimos sacando distintos sonidos de cada tipo (tanto para el suelo como para la madera) y se aplicó mediante código cada uno de forma aleatoria, así no da la sensación de que siempre suena igual cada pisada.

También están los sonidos del agua corriendo. Algo muy sutil al ser un estanque, pero lo suficiente para que se oyera y diera sensación de paz. Sensación que se mantiene durante el resto del escenario al usar sonidos de pajaritos cuando el ninja se acerca a los árboles. En este caso lo que hicimos es aplicar los sonidos en función de la distancia, haciendo que conforme más te acerques a los árboles o al agua suene más fuerte que si estás a unos metros.

Y para acabar, el último sonido que pusimos fue precisamente el primero que se puede oir. El portón que se cierra cuando pasas de la pantalla de créditos y accedes al juego y da a entender que nuestro personaje ha entrado en la aldea.

Para la música fuimos a buscar una canción que fuera libre de derechos para su uso. En nuestro caso, usamos la canción "Oriental Emotions" de Matti Paalanen. Si nos fijamos, veremos los iconos de la licencia Creative Commons que nos dirán que podemos usar la canción siempre y cuando pongamos en los créditos al autor, no ganemos dinero con ello y no creemos una obra derivada.

Aunque hicimos que la música se pudiera reproducir en un bucle sin que se notara demasiado el corte, no creamos una obra derivada puesto que el resultado no respira un aire nuevo. Es la misma canción y no hemos añadido ningún tipo de efecto o arreglo musical.

Esta canción suena durante en la pantalla inicial de créditos y durante el juego. Nos pareció muy acorde con la ambientación que le queríamos dar. No solo porque sea oriental sino por la paz que transmite va muy afín con el resto de elementos.

Tanto para los sonidos como para la música es importante leer los usos que se le pueden dar. Porqué incluso cuando no quieres hacer dinero, puede que estés infringiendo su licencia. En nuestro caso, nos relajamos bastante precisamente por eso, porqué no íbamos a sacar beneficios. Y aunque siempre se tiene que comprar el recurso cuando es necesario pagar por su uso libre, hay algunos recursos que desgraciadamente no es tan fácil encontrar su fuente original, y no sabes si lo estás usando correctamente.

Al final lo pones en una balanza y si hubiera algún problema habría que retirarlo hasta dar con una solución.

UI

Aunque creemos recordar que para la versión de unity que usamos de primeras lo llamaba GUI, a partir de la versión 5 es UI. Se trata del menú inicial donde se suelen poder configurar las opciones y escoger los tipos de partida y demás menesteres.

En nuestro caso, y dada la sencillez de la demo, decidimos usarlo solo como interludio para que el juego no empezara de repente una vez descargado el paquete de unity.

Además pensamos que seria un buen sitio también para poner los créditos, ya que como se queda en una demo de lo que podría haber sido la pantalla de descanso del personaje, no habrá ningún tipo de límite de tiempo ni objetivos.

Así que ya que iba a ser sencillita, decidimos hacer una portada algo especial, con un diseño de logotipo original y usar algunas tipografías chulas. Eso si, siguiendo la estética tranquila y sosegada que no diera pie a pensar que iba a ser un juego de acción después de darle al botón para empezar.

Portada Torii.


Este es el diseño final del logotipo de Torii y parte de portada del menú UI después de unos bocetos y varias pruebas en unity. Las tipografía escogidas son de Google Fonts. Para el logotipo y las letras en inglés es una llamada Poiret One. Para los créditos, aunque aún no los podáis ver, es la Roboto Condensed.

La referencia es clara, la bandera japonesa. Usamos su motivo y sus colores para el diseño.

Realmente no es necesario ni mucho menos la creación de un logotipo para un proyecto como este. Podríamos haber creado el menú desde unity directamente, con las mismas instrucciones y listo. Nadie se hubiera dado cuenta, pero al final, son los pequeños detalles los que le dan otro aire.

Para nosotros algo como un diseño, escoger una tipografía, diseñar una marca en definitiva es como darle personalidad al proyecto. Que todo tenga un sentido y que fluya de manera natural es importante.

jueves, 24 de noviembre de 2016

El cerezo en flor.

La flor del cerezo japonés (o sakura) es de las cosas más bonitas y simbólicas de Japón. Y la imagen de los pétalos de sus flores que caen creando tupidas alfombras rosadas en primavera es de todos conocida.

Esa misma imagen queríamos transmitir en el juego con la caída de los pétalos de los cerezos del escenario. Especialmente con el cerezo que está justo al lado del torii, ya que es la primera escena que el usuario ve al empezar la partida.

Queríamos poder crear distintas zonas de generación de pétalos en cada árbol y que estos, una vez caídos, se quedaran en el suelo durante unos minutos.

El generador de pétalos es un objeto rectangular que se coloca en la copa del cerezo dónde queremos que genere los pétalos. Cada pétalo tiene un comportamiento individual y cae siguiendo una curva constante, la cual se incrementa levemente justo antes de caer al suelo y dónde éste gira para ponerse horizontal y quedarse sobre el terreno.

En la siguiente imagen se muestra como quedarían colocados los generadores de pétalos en uno de los árboles del escenario:

Cerezo con los generadores de pétalos visibles.

Como se puede observar en la imagen, el cerezo tiene 4 generadores (són los cubos delimitados por líneas verdes). Y estos están más o menos colocados para que en cualquier parte de la copa del árbol se vea caer pétalos. También se colocó un collider en el tronco del árbol para que el ninja no lo traspasara cuándo estuviera muy cerca.

La idea para cada generador era que crease un pétalo cada segundo en una posición aleatoria de toda la zona del cubo. Una vez generado el pétalo, éste ya actúa de forma independiente de los demás. Mientras va cayendo, se detecta cada cierto tiempo la distancia con el suelo. Además siempre cae encarado hacia el ninja, así nunca se verá un pétalo de lado y visualmente será más bonito.

Para darle más variedad visual se generan hasta tres pétalos de distintas tonalidades.

Una vez el pétalo detecta que está cerca del suelo empieza a girarse hasta coger la posición horizontal, para que se quede en el suelo y no desaparezca hasta pasados unos minutos. En ese momento prácticamente se encuentra en el suelo y cuándo se detecta que lo toca se desactiva el código para ese pétalo. Pasados unos minutos, desaparece para no consumir muchos recursos, pero permanece lo suficiente como para que se pueda ver una alfombra de pétalos bajo el árbol, dándole el efecto que estábamos buscando en un principio.

Una vez creado el efecto y aplicado a los árboles, nos fijamos que el cerezo que está justo al lado del puente deja caer sus pétalos encima del riachuelo. A estos pétalos, una vez tocan el agua, les aplicamos una pequeña rotación y un movimiento horizontal hacia la misma dirección de la corriente, con lo que dio como resultado un efecto muy bonito el cual puede ser visto cuando el usuario pasa por encima el puente y mira hacia la izquierda.

Resultado final

A continuación se muestra un vídeo de unos de los cerezos del mapa con el resultado final. Si queréis ver la imagen inicial del juego con los pétalos cayendo o el efecto de los pétalos en el riachuelo, os invitamos a que esperéis a ver el resultado final en el propio juego y verlo por vosotros mismos :).



Esperamos que os haya sido útil :).

lunes, 21 de noviembre de 2016

Peces II. Comportamiento y codificación.

El comportamiento de los peces ha sido la parte de programación más divertida del juego, debido a las premisas que se debían de tener en cuenta.

Su movimiento tenía que ser por toda la zona de agua del estanque y riachuelo y además que no chocaran entre ellos ni con el terreno que limita toda la zona. El límite vertical era la propia superficie del agua, pudiendo sacar un poco la aleta superior. En cuanto a profundidad, tenían que dejar cierta distancia con el fondo del estanque para que normalmente se movieran más por la zona superior y fueran más visibles vistos des de fuera del agua.

Aunque el objetivo no era hacer un simulador con un comportamiento muy real si que trabajamos el comportamiento para que desde fuera del agua diera un resultado creíble.

Antes de hacer el movimiento se buscamos vídeos de referencia de peces de estanque para ver su movimiento y su comportamiento, el cual es un movimiento bastante tranquilo y normalmente impredecible. Podéis ver cómo realizamos el modelo y su animación en el post donde explicamos sus animaciones.

Para los peces se utilizó un Character Controller para controlar mejor su movimiento y las animaciones según su velocidad, para que así, cuando apenas se moviera, la animación del modelo también fuera más lenta que cuando fuera más rápido.

Igual que hicimos con el ninja, los peces también tienen un componente Animator para la animación. Aunque en este caso, como se puede observar en el siguiente gráfico, la gestión de la animación era bastante más simple que el ninja.

Diagrama del componente Animator de los peces.
En este caso el modelo sólo tiene una animación, la cuál se activa siempre cuándo se mueve. Para que visualmente se vea mejor, hay una relación entre la velocidad de la animación y la velocidad del pez, así cuándo se mueve a baja velocidad la animación también es más lenta.

Para hacer un comportamiento más impredecible de los peces se utilizaron iteraciones basadas en la aleatoriedad. Así, por ejemplo, en cada iteración, el pez tiene un 60% de probabilidades de moverse hacia delante y un 70% de girar hacia la derecha o izquierda. Además también se le añade una pequeña probabilidad de movimiento vertical, para que pueda aproximarse a la superficie del agua o pueda sumergirse a cierta profundidad.

En el siguiente video se puede ver una de las primeras pruebas de movimiento, que aunque de tan cerca puede parecer robótico, buscábamos encontrar un comportamiento que desde fuera el agua quedara resultón.



En cada iteración también se controlan todos los objetos que el pez tiene a su alrededor, ya sea el propio terreno del estanque u otros peces que se mueven cerca. Dependiendo de la distancia de los objetos que tiene cerca, al pez se le mandan unas acciones a realizar. Así por ejemplo, si se está acercando al límite del estanque pues se le sube la probabilidad de rotación para que vaya girando para no chocar. Aunque intentando que este giro tampoco fuera un movimiento brusco.

Otro ejemplo sería cuando el pez se mueve en paralelo a la pared del estanque. Si está cerca de esta pared el pez ya no intenta moverse hacia allí porque lo más probable es que colisionara, por lo que o sigue recto o gira hacia dirección contraria.

Para detectar los objetos que el pez tiene cerca en cada iteración se utilizó la función Raycast de la clase Physics de unity, la cual permite, dada una dirección, trazar una línea recta hasta que colisione con un objeto y además saber el tipo de objeto y la distancia que hay hasta él. Esta información es muy útil para saber en todo momento lo que el modelo tiene a su alrededor y por lo tanto actuar correctamente para evitar colisiones.

Finalmente, también se controla la distancia del pez con la superficie del agua y con el fondo del estanque. Así podíamos hacer que siempre se moviese por la parte superior del agua.

Para la presentación final de los peces en el estanque y riachuelo, se colocaron un número de peces adecuado para que siempre se viese movimiento bajo el agua. Además se colocaron unos colliders verticales en algunas zonas para delimitar que los peces no se fueran muy lejos de su punto de partida y para que no se acumularan todos en un mismo sitio y que otros lugares del estanque se quedaras vacío.

Resultado final

En el siguiente video se muestra el movimiento final, que con el efecto de refracción del agua, nos queda un resultado bastante aceptable.



Esperamos que os haya sido útil :).

jueves, 17 de noviembre de 2016

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 :).

lunes, 14 de noviembre de 2016

Escenario III. Fase final.

Ya llegábamos a la parte final del proyecto. Con el paso del tiempo, nos dimos cuenta que los últimos cambios significativos del proyecto vinieron casi de golpe.

Las últimas versiones de las animaciones, de los modelos, los últimos cambios a las texturas junto con los nuevos modelos conseguidos de los packs que habíamos obtenido, los habíamos juntado prácticamente a la vez.

Todo eso con las últimas vueltas a la codificación hicieron que casi de un día para otro empezáramos a ver la luz. Pero no en el sentido que ya estábamos acabando (¡que también!). Sino que de repente todo empezó a tener forma. Y era justo la forma que nos habíamos imaginado desde un principio.

Vista cenital del mapa en fase III.
Vista del mapa en fase III.
Colocamos desde el propio unity el agua verdosa, típica de estanques. Desde el programa le puedes configurar su comportamiento. El movimiento, la medida de las ondas del agua, corrientes, etc. En nuestro caso, lo configuramos todo lo más sutil posible, dado que era un estanque y el riachuelo tampoco podía llevar mucha velocidad.

Además añadimos terreno por las afueras del mapa para tapar esas zonas que quedaban sin contenido. Lo hicimos con la herramienta Terrain de unity. Muy sencilla de usar y las montañitas que creamos daban el pego.

En realidad si las miras un poco se ven impuestas. ¿Cómo es posible que es una extensión así, no se vean más montañas al fondo y bosques? Cierto. Pero una vez dentro del juego, no te das cuenta.

jueves, 10 de noviembre de 2016

Recursos externos. ¿Necesario o despilfarro?

Hasta ahora habíamos sorteado muy bien la necesidad (o tentación, según se mire) de adquirir recursos de pago. Lo íbamos montando todo a nuestro ritmo como podíamos.

Si habéis seguido el proyecto, sabréis que siempre insistimos en la falta de tiempo y en tener que decidir en cada momento hasta donde podíamos pulir tanto un modelo como una animación. Incluso en sacar la tijera y tener que recortar.

Pero nunca nos pareció que lo que dejábamos a medias o, mejor dicho, a sabiendas que el resultado final podría ser mucho mejor, minaba demasiado de alguna manera el resultado final del conjunto.

Lo podemos resumir en que lo poníamos en la balanza y hasta ahora se compensaba. Efectivamente. Hasta ahora.

Una vez teníamos los objetos más grandes (casas, campo de tiro, estanque, etc) nos dimos cuenta que se veía vacío. Incluso después de poner otros tantos objetos de atrezzo (cubetas, cubos, banquetas, etc), ¡seguía vacío!. Nos faltaba esa chispa que hace que todo cuadre, que todo tenga fluidez.

Decidimos que teníamos que hacer vegetación. Mucha vegetación. Árboles, flores, hierbas, etc. Y, a poder ser, de distintos tipos y colores. Y así fue. Nos pusimos a ello. Hicimos algún hierbajo, pero aún no era suficiente. Lo seguimos intentando y... nos rendimos. Necesitábamos más de todo y no encontramos manera para motivarnos y seguir haciendo distintos tipos de vegetación y eso afectaba al resultado final. No acababa de convencernos como estaba quedando.

Cabe decir que estábamos en una de las últimas fases del proyecto, y aunque habíamos tenido otros bajones antes, este era muy peligroso. Porqué era un punto donde a todo le faltaba aún una vuelta más. No teníamos muchas cosas con el resultado final acabado. Un momento clave.

Así que antes de que acabáramos sin motivación alguna, encontramos este pack en nuestro baúl de recursos y nos lo replanteamos. Un pack completo de vegetación con árboles, hierbas y plantas de distintos tipos y colores y además un conjunto de rocas muy molonas que supimos aprovechar muy bien. Porqué si, lo compramos.

Pack de vegetación de la Asset Store.


Nos costó unos 25 dólares. ¡Pero qué bien invertidos!. Tuvimos la suerte que una vez puesto todo, encajaba muy bien. Nos ayudó a rellenar todos esos huecos vacíos que teníamos y a darle riqueza visual a todo el conjunto.

Este pack de vegetación no fue el único. También usamos uno gratuito que te ofrecía hasta 4 tipos de cielo cartoon, además de modelos de piedras, setas y vegetación. Aunque inicialmente nos hubiera gustado crear un sistema de tiempo climático, pudiéndose hacer de noche o incluso lloviznas, al final solo hicimos uso de uno de los cielos que nos gustó mucho. También supimos aprovechar algún modelo, como las setas.

Pack de cielos gratis de la Asset Store.


Finalmente usamos texturas hechas por nosotros y algunas que encontramos de búsquedas de artistas en Google y Pinterest. Cuando se buscan recursos hay que mirar bien si cuando son gratuitas se pueden usar. Incluso si son de pago, a veces también hay que revisar qué uso se les puede dar. Pues aunque intentamos ver la procedencia de las imágenes para confirmar que las podíamos poner, no siempre lo conseguíamos.

Al final decidimos poner las que más nos gustaban confiando en que como en nuestro caso no pretendíamos ganar dinero con el proyecto no nos íbamos a encontrar con problemas. Y siempre se podía retirar el juego si a alguien le molestaba.

Evidentemente, y con tiempo, lo mejor es intentar hacerlo uno mismo si se puede. Pero no solo por dinero, sino porqué siempre mola decir que es todo 100% homemade. Ahora bien, si por cualquier cosa no se llega, existen recursos en la red que valen mucho la pena. Y como os hemos mostrado, hay también recursos gratuitos que están a la altura de los de pago.

Ya sea porqué no se tiene tiempo, porqué no se es un experto ilustrando, o porqué uno no ha tocado un programa 3D en su vida, es importante tener en cuenta todo lo que se ofrece en la red. En la propia Asset Store existen modelos texturizados, animaciones, código o funcionalidades para poner cielos, nubes o partículas. Una verdadera pasada que puede darle ese toque que le falta a nuestras aplicaciones.

Pero tanto si miramos en tiendas oficiales como en cualquier otra página, es muy importante saber para qué vais hacer vuestra aplicación (si pretendéis sacar provecho o no) y comprobar qué podéis usar ese material.

lunes, 7 de noviembre de 2016

Escenario II. Segunda fase.

Una vez teníamos el escenario en unity, solo había que refrescar los objetos para que el programa detectara las actualizaciones y se refrescara automáticamente. Así llegó un momento donde trabajar se hacía bastante fácil.

Se hacía un objeto, se ubicaba en el mapa y se seguía trabajando. La siguiente actualización del objeto, se exportaba en la carpeta del juego y cuando volvías a abrir unity, ya se podía ver la mejora.

Como os mostraremos en las siguientes capturas, podréis ver que ya hay algunos objetos texturizados aunque algunos no fueran la versión final.

Vista cenital del mapa en fase II.
Vista del mapa en fase II.
En esta fase tanto el ninja como los peces aún están sin animar. Aunque ya se podía ver parte del comportamiento que se creó a partir de la programación y que detallaremos en artículos próximos.

A parte de las texturas del suelo y de las casas, las pequeñas diferencias que se pueden apreciar son objetos nuevos, como la vegetación del estanque y algunas rocas para delimitar zonas.

Realmente parece poco trabajo cuando te pones a listar elementos, y es normal. Casi todo el trabajo que había en este punto era de programación y 3D que aún no estaba incorporado en el mapa.

En la próxima y última actualización del escenario es cuando realmente se podrán ver grandes diferencias :).

jueves, 3 de noviembre de 2016

Peces I. Modelo, rig y animaciones.

De la misma manera que hicimos con el ninja, os contaremos como fue el proceso de los peces. Esta vez es algo bastante más simple.

Para el estanque queríamos incorporar las famosas carpas Koi. Aunque parece que son originarias de China, fue Japón quién las difundió.

Carpas Koi.
Primero decidimos buscar a ver si encontrábamos algún recurso ya hecho que nos pudiera venir bien y ahorrarnos trabajo (para variar). Y aunque alguna cosilla encontramos, al final decidimos hacerla nosotros.

Primero, porqué lo que encontramos que nos podía servir era de pago. No olvidemos que necesitábamos un modelo en 3D con su textura y rig. Eso de por si, ya era complicado encontrar algo gratuito. Como para encontrar algo que también tuviera una animación simple del movimiento de un pez.

Pedíamos demasiado. Así que puestos a meternos en faena, decidimos intentar hacerlo nosotros. Como era algo que no se vería en excesivo detalle al estar en el agua, hicimos algo sencillito pero resultón.

Modelo 3D del pez.
Usamos de referencia un modelo hecho (el verde) que se pareciera lo más posible a la forma de la carpa y modelamos nuestro pez con blender. Como era bastante sencillo se hizo rápido. Después sacamos las texturas haciendo su UV para su posterior texturizado donde usamos varias imágenes para componer una final que tuviera los colores típicos de este tipo de peces. Una vez teníamos una, hicimos de distintos colores para tener más variedad.

Finalmente, creamos un rig y su pesado para poder animar a nuestra carpa.

Rig del pez.
La animación la hicimos rápido porqué no teníamos mucho tiempo, y tampoco no nos obsesionamos con que quedara perfecta ya que no se apreciaría lo suficiente al estar bajo el agua verdosa del estanque. Además el rig que hicimos era muy simplón precisamente porqué no lo vimos más necesario que otras cosas. En cualquier otro tipo de circunstancia o si el juego fuera de pescar peces, hubiéramos tenido que darle mucho más cariño en este paso para poder hacer animaciones más refinadas.

Para poner un ejemplo de lo mucho más que podríamos haberlo hecho, si os fijáis en la cola de una carpa koi veréis un movimiento muy bonito e hipnótico. En cambio el pez que hemos animado parece robótica, como si fuera de madera y no se pudiera doblar.

Para encontrar referencias, nos vimos algunos vídeos de Youtube donde se veían carpas reales en movimiento. También encontramos este tutorial que nos fue bastante útil e interesante. Aunque en nuestro caso solamente constaba del siseo del pez bastante sosegado. Ni siquiera animamos las aletas :(.

Decir los fallos que tiene la animación no es una manera de decir que uno puede hacer el trabajo a medias y nadie lo notará o quedará igual. Eso es una falacia. Cuando nosotros explicamos con detalle que se podía haber hecho mejor lo hacemos porqué consideramos importante reseñar que en un proyecto así, incluso en el más sencillo, hay mucho trabajo y al final tienes que decidir donde quieres poner las pocas horas de las que dispones.

En este caso concreto, como el modelo iba a estar en el estanque, pensamos que no se notarían tanto los detalles y que mejor sería invertir ese tiempo en mejorar las que sí se notarían o en añadir nuevas para dar más riqueza al conjunto.

Volviendo a la animación, de igual manera que con la animación del ninja, se animó sobre el sitio. Luego desde unity, se añadió el comportamiento del movimiento con código. Todo el tema de los peces y su comportamiento final lo comentaremos en un próximo artículo de igual forma que hicimos con el ninja.

A continuación, os dejamos con un pequeño video donde se puede ver la sencilla animación del pez:



Esperamos que os haya resultado útil :).

lunes, 31 de octubre de 2016

Escenario I. Primera fase y colliders.

En una entrada anterior en la que os explicábamos nuestras referencias, os mostrábamos un pequeño croquis de lo que queríamos que fuera el escenario completo de la aldea.

Lo siguiente que necesitábamos para empezar a trabajar era un mapa en 3D. Teníamos que empezar a situar cosas por un escenario para poder empezar a interactuar con los distintos elementos.

Aunque os explicaremos con un poco más de detalle las fases del movimiento de los distintos personajes, en esta primera fase del escenario los situamos para poderlos mover por el mapa y empezar a hacer uso de los colliders. No son más que una especie de cajas invisibles que ponemos en los objetos con los que nuestro ninja o nuestros peces deberían de chocar y no atravesar.

Hicimos uso de un par de tipos de colliders. Cuando queríamos que los personajes, por ejemplo el ninja, chocara completamente contra una construcción y no hubiera ningún tipo de interacción, usábamos un collider que ocupara todo el objeto. Por ejemplo para las casas, usábamos una caja. Así cuando el personaje intentara pasar, no podía.

En cambio, si necesitábamos que pudiera entrar en una edificación, usábamos el propio objeto como collider. De manera que todo lo que fuera malla 3D actuaba como pared invisible y el ninja podía pasar por la puerta y entrar dentro porqué era hueco, pero no podía atravesar las paredes porqué la malla actuaba como tope.

De la misma manera se configuró el puente, una zona por donde el personaje debía poder pasar por encima y no hundirse.

Para los peces, nos bastó con delimitar la zona del estanque y río con colliders y ya no pasaban de ahí.

Pues bien, para poder empezar a configurar este tipo de cosas e ir más allá y programar el comportamiento de los personajes (algo que explicaremos con más detalle en próximos artículos) necesitábamos un primer escenario.

Al igual que con todo el proyecto en general, empezábamos algo muy básico para ir detallando poco a poco sobre lo que teníamos hecho.

Empezamos con un plano y pusimos cajas directamente desde unity para marcar los sitios donde habrían edificaciones. Mientras se trabajaba con eso, se iban trabajando los modelos en 3D desde blender. Y así, y sin tener todos los modelos ni sus versiones finales, obtuvimos una primera versión más digna de enseñar del escenario.

Vista cenital del mapa en fase I.
Un modelo de casa duplicada varias veces, el granero, el campo de tiro, el puente y nuestro torii más una serie de objetos sueltos formaban parte de esta primera fase del escenario.

Si nos fijamos un poco, tenemos al personaje principal con los brazos en T (está aún sin animar) y los peces que no son más que pequeños ladrillos que se mueven por el estanque vacío.

Vista del mapa en fase I.
Aún así, suficiente para trabajar con los colliders y para empezar a programar el comportamiento de nuestro ninja y los peces.

Esto no hacía nada más que empezar.

jueves, 27 de octubre de 2016

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

lunes, 24 de octubre de 2016

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
Torii y puente
Cerezo en flor
Cerezo en flor
Dianas de tiro, banco periodo Edo, puente y carro.
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.
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.

jueves, 20 de octubre de 2016

Referencias I. Periodo Edo.

Ponerse a realizar cualquier trabajo, sobretodo si es creativo, sin una referencia con la que basarse es muy complicado. Y aunque fuera posible obtener un buen resultado, desde nuestro punto de vista, se habría desaprovechado que el resultado final fuera mejor.

Necesitamos algo con lo que empezar, y más cuando no sabes exactamente que es lo que quieres.

Así que la manera más fácil e inmediata era buscar referencias reales del Japón tradicional, intentando acotar la búsqueda a objetos del periodo Edo. Aunque nuestra intención era intentar ser fiel a esa época, no podemos garantizar que todo lo que encontramos perteneciera a ese período.

Por tanto, tal y como dijimos en el post anterior, nos conformábamos con que todo tuviera una coherencia sin saber si estábamos siendo fieles al rigor histórico...

Encontramos mucha información, entre ella, una web donde aparecen fotografías en 360 grados de lo que parece un set que imita el estilo de las construcciones del periodo Edo.


Casas con el estilo de construcción de periodo Edo.
Vista de las casas y puente con el estilo de construcción del periodo Edo.
También encontramos la web de lo que parece un museo ambientado en un pueblo (¿ficticio?). Incluso hay un mapa en PDF y en cada ítem que aparece en el mapa, se puede ver una descripción de la construcción. Algunas tienen la especificación qué pertenecen al periodo Edo, cómo esta.


Aldea

Con la información que encontramos, ya éramos capaces de tener una idea de como tendrían que ser esos elementos, algunos de los cuales, teníamos incluso referencias claras.

Des de un principio queríamos añadir distintos tipos de casas de los habitantes de la aldea, un pozo, un puente que pasara por encima de un río pequeño, una zona de tiro, el típico atrezzo de una escena (árboles, barriles, cajas, vallas, distinto tipo de vegetación, etc.) y el famoso Torii.

Pero ¿que pasaría si quisiéramos poner un objeto y no tuviéramos referencias claras? Habría que inventar. Para eso es necesario investigar qué materiales se usaban por aquel entonces.

En aquella época parece que el material más común para las construcciones civiles era mayoritariamente la madera.

Así pues, cuando no se tenga referencia con la que trabajar usaremos madera o materiales que se usaban por aquel entonces para resolver la duda.

Después nos pusimos a pensar en una lista de objetos para modelar que estaría bien que apareciesen en la aldea de descanso.
  • Torii. La puerta de entrada al pueblo.
  • Puente. Para poder pasar por encima del río que separa la entrada de la aldea con la propia aldea.
  • Río. Pequeño río que atravesará el pueblo, acabando en un pequeño estanque.
  • Letreros. Señales que indiquen los caminos donde llevan a distintas zonas (campo de tiro, estanque y aldea).
  • Estanque. Donde habrán distintos tipos de vegetación, piedras y los famosos Kois. Carpas grandes típicas de China y Japón.
  • Campo de tiro. Zona de entrenamiento donde habrán dianas para poder practicar tiro en cuanto se añadan las animaciones para ello. Mientras tanto, será otro tipo de construcción.
  • Casas u otras construcciones. Casas de aldeanos, o construcciones típicas como un granero, establo o granja.
  • Pozo. Pequeño pozo que estará entre las casas.
  • Árboles. Cerezos que estarán por todo el escenario por temas estéticos y para separar zonas. Y si se puede otro tipos de árboles.
  • Atrezzo. Distintos objetos para dar variedad al escenario. Carros, barriles, cajas, etc.


Torii

Después de tanta referencia y ver distintas imágenes, nos encantó darle un protagonismo especial a un elemento muy conocido de Japón. El Torii. Además tiene un significado muy especial que nos venía muy bien para nuestra pequeña demo.

El Torii es una construcción que suele estar en las entradas de los templos o santuarios para dar la bienvenida al visitante.
Torii.
Y así decidimos que en la demo se empezaría justo delante de un Torii, que aunque no haríamos ningún templo o santuario, si serviría para dar la bienvenida a nuestro ninja a la aldea de descanso. Y no solo eso, también le daría el nombre a nuestro juego.

Para acabar, volver a hacer hincapié en la búsqueda de referencias. Es tan importante que además, en nuestro caso, nos dio el nombre al proyecto :).