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.

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

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

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

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.

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.

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

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