Vale, a ver.
Hay dos cositas muy importantes cuando se trata de utilizar la API de Unity.
Vale, los métodos de la API de Yuni, que ya los conocéis.
No diré todos, pero conocéis bastantes.
Ya estuvimos hablando del Estat de la Weich de lineup y todos estos que ocurren al inicio durante lo
que es el gameplay.
Están los ÁB dats, está todo lo que tiene que ver con eventos de o más enteros, más clico o lo que
sea.
Hemos visto On Animator Mu y están los adaptes que está el DOIT normal, corriente o normal y corriente
que es para actualizar, que se utiliza para reproducir cambios constantes.
Está el bucle fijo, el fix tap that que ocurre a un interval a un intervalo de tiempo determinado que
es el mismo en el que corre todo el motor de físicas, el motor de físicas, la propia implementación
utiliza el fix tap para hacer que todo lo que tiene que ver con un movimiento de física sea independiente
de los frames.
Vale.
Y en nuestro caso tenemos también el leyte app de que es lo último que se ejecuta después de los ataques,
tipicamente para hacer limpieza, correcciones o asignar variables.
De hecho, el Lay Tap Day hubiera sido el sitio ideal para colocar esto.
Tengo una APDAYC que hace los cálculos delmovimiento y es el Lait Tap de quien se los transmite al animator
a la animación.
Lo que pasa es que mejor que el Lait App doit on Animator Muff para poder recuperar esto.
Básicamente vale, porque esto sólo será llamado cuando realmente hay un cambio en la animación y tiene
sentido.
Vale, porque el movimiento va a ser la combinación de las teclas por un lado, más la animación por
otro lado.
De hecho, fijaros como aquí además se nota muy bien.
Cuanto más rápida es la animación, más se mueve el lemor.
Vale, entonces fijaros que si le hago venir para acá veis que lo que camina va acorde a la animación.
De hecho, si yo tomara la animación de caminar, que es ésta de aquí, la de WOC y le pusiera velocidad
2.
Fijaros ahora aquí, no aquí.
Veis que ahora como camina más rápido, también se mueve más?
Lo veis?
Entonces esta es la forma perfecta de sincronizar lo que hace un artista con el propio controlador.
Lo veis?
Evidentemente, si aquí le pongo velocidad 20 a la animación, hasta luego.
Veis que parecen los dibujos animados?
Falta el Coyote Correcaminos.
Lo veis?
Esta es la forma ideal cuando queréis que todo vaya sincronizado.
Cuando queréis que todo esté de la mano, pues al final la propia animación necesita transmitirle parte
de la información al controlador.
Fijaros que no todo depende del jugador ahora.
Ahora depende además de cómo está hecha la animación y qué configuraciones tiene idiomas.
Incluso podría ser una forma de establecer un PowerUp en un momento dado.
Un pavo podría venir aquí, cambiarle la velocidad a la animación en base a un parámetro.
Os acordáis los parámetros de las animaciones?
El propio editor aquí tendría un parámetro multiplayer.
Nosotros por código cambiaríamos el multiplayer del Animator base al PowerUp y el PowerUp, pues lo
que haría sería multiplicar ese valor por el de aquí.
Ahora me da error porque no tengo ninguno que es numérico de tipo flow.
Pero fijaros cómo realmente solo cambiando un parámetro del Animator y transmitiéndose aquí a esta cosa,
podríais conseguir una dimensión adicional en lo que es el propio videojuego jugar con la velocidad.
De modo que aquí el invento vale float.
Spit modificar por defecto es 1 es el valor por defecto de esta cosa, y lo que hacemos es que aquí
paga.
Va desapareciendo a estas.
Aquí hoy hacemos que este Spit esté multiplicado por el mismo, dijo ayer lo ves?
De modo que qué ocurre cuando yo le doy al play?
Ocurre que si alguien por código, por defecto, la animación, animaciones de la velocidad que es si
alguien por código viene aquí me pone que el espectro de falleras 3.
Pues ahora lo veis.
Solo cambiando el valor de esa variable yo le puedo transmitir a John Lemmon el modificador que se le
debe aplicar a la velocidad.
Y eso se utiliza mucho.
Se utiliza mucho.
Por ejemplo, hay power apps que te hacen inmune o te hacen invencible o te hacen más fuerte.
Lo que hacen es acelerar las animaciones.
Punto.
Ya está.
Vale, esto sería así de fácil.
De acuerdo.
Lo mismo es si que yo.
Lemon pisa una una telaraña y que encima de la telaraña vaya más lento en el suelo.
Podría tener una telaraña sobre la telaraña, un trigger y que el trigger lo que hiciera es ponerle
el speed body fallera 0,5.
De modo que cuando yo lemon se quiere mover sobre la telaraña boom, boom, boom tú.
Vale, lo veis?
Fijaros que es una tontería y que es combinar cosas que ya sabéis.
De acuerdo, entonces esto serían la forma de introducir una variable adicional en el caso que quisierais
implementar mecánicas de este estilo.
Yo no lo haría, pero bueno, os lo dejo por si queréis toquetear el speed modificar, colocar una variable
tipo float en el controlador y transmitirle la información en base a ciertas condiciones.
Entonces aquí lo bueno que tenemos cuando conocemos la API de de Unity echo poneros el gráfico que ya
os he puesto varias veces y Unity o Appia y order o methods.
Cuál era?
Creo que era este.
Sí, vale, este de aquí, fijaros que la parte de inicialización primero se despierta todo el mundo.
Una vez despiertos se activan, se resetean y se inicializa.
Vale, aquí la parte del motor de físicas es la que debería utilizar el fix tab doit en lugar de la
normal y corriente.
De hecho, fijaros que la propia el propio motor de físicas tiene métodos relacionados con cambios en
las animaciones, animaciones que tienen que sufrir modificaciones o que necesitan una serie de parámetros,
o que la propia física dictamina cómo se van a ejecutar como la nuestra.
Luego vendría el sistema de inputs que ya los conocéis.
Cualquier click, el app doit el bucle general de la lógica del juego y al final el Lait Update antes
de proceder al renderizado, el bullying, el post procesado y toda la parte visual de parafernalia
que añadimos en su momento.
Vale.
Hay algunos adicionales para pintar mismos en pantalla y demás.
Pero bueno, la idea es que yo que acabo de hacer ahora, acabo de meter la lógica de actualización
en el app day, pero corregir el movimiento en el Animator MU.
Osea que lo que ocurre en Humphreys se actualiza en el siguiente.
Lo ves?
Así que sí que me me he preocupado de que el Animator corra a tiempo con el bucle de físicas unanime
y Tormund para que los dos vayan de la mano.
Rising Body es el es del motor de físicas y el rigging body ocurre, o sea, es modificado a la par
que clonan y Meito Ormuz.
Por tanto, es modificado aquí de acuerdo como parte del motor de físicas.
Sin embargo, estoy ignorando que todo esto de aquí.
Va a ocurrir en el siguiente Froy.
O sea, el cambio que hago en el Froy MX es aplicado en el editor Mofen en frame X+1.
Esto significa que el unanimi tormos realmente es invocado por el motor de físicas, porque estoy utilizando
elementos de física en su interior.
Ojo, no quiere decir que todos los animator MOOCs usen motor de físicas.
Aquí abajo tenéis cambios en las animaciones que podrían formar parte de la lógica del juego.
Vale, podrían formar parte y venir después de la dáte como cambios en los estèn machines.
Disparar un evento u otro.
Vale.
Aquí podríamos detectar cambios en las animaciones, pero resulta que todos aquellos son Animator Muff
forman parte de cambios internos del motor de físicas.
Así que primero se invoca el Animator Muffy y luego se invoca el Sabbath.
Y habrá un problema porque el Cuaternidad que está asignado dentro del APDAYC toma el valor Humphreys
más tarde.
Siempre hay una pequeña discrepancia.
Esto es algo que te lo han contado una vez o a ti te da absolutamente igual porque no te das cuenta?
Vale, entonces, ahora que sabéis el orden de ejecución, un animator Muff viene antes de todo esto,
salvo que aquí decidamos utilizar el APDAYC correcto.
Y por eso el APDAYC correcto es Fix Taddei.
En este caso, porque estáis toqueteando variables que son utilizadas como parte del motor de físicas
y por tanto se deben utilizar dentro del fixture dáte y no dentro de la DOIT.
Qué ocurre después?
Vale, esto es la parte más dura de aprender de Unity.
Aprender es el orden de ejecución de estas cosas y saber cuándo hay que invocar una cosa u otra.
Y es un poco lo que decíamos ayer, que es que cuando no sabes programar nada te da igual ponerlo en
el AT y tener el fix that Drayton.
Deleitas date enfrentar no se va a dar cuenta a nadie, pero cuando sabes realmente lo que está ocurriendo,
podría haber casos en los que no tuviera ningún sentido aplicar el cambio.
Un cuaternidad más tarde vale el cambio del cuaternidad, un frame hasta entonces, para asegurarnos
de que el vector de movimiento y de rotación están configurados y que el inventor Muff se mueve exactamente
con los cambios especificados.
Lo único que tenemos que hacer es cambiar que en lugar de utilizar el APDAYC, utilicemos el Fix that
date en su lugar.
El Fix that de recordad no tendría por qué llamarse a cada frame, podría ocurrir menos veces, de hecho
ocurre menos veces por defecto, ocurre 50 veces por segundo, mientras que aquí estamos desperdiciando
un montón de valores.
Si esto corre a 180 frames por segundo, estaba calculando 180 4 reuniones, de los cuales sólo 50 de
ellos se aprovechaban porque estaba haciendo el idiota y encima los aprovechaba un fragm más tarde que
así que no se nota.
Pero ahora acabo de reducir el número de llamadas que voy a hacer a este método.
A ver, aquí hay mucha chicha, estoy haciendo muchos cálculos.
Vale que son cálculos triviales.
Lo único que tiene un poco de complicaciones este y este.
Pero oye, que estoy haciendo yo aquí?
Un montón de cálculos inútiles.
Entonces ahora habremos pasado de hacer 180 cálculos al segundo a hacer solo 50, que esos 50 además
son necesarios para Elona Animator.
Estas son las cosas más difíciles de hacer bien en Unity.
O sea, cualquiera puede usar Unity.
Casi nadie lo puede usar.
Bien, vale, pasa por muchos años de experiencia haberos pegado muchas hostias.
Y cómo me hubiera dado cuenta si hubiera puesto un debug?
Punto Lock me hubiera puesto un back to lock.
Cada vez que llamamos al Animator Muff o dentro del Apdayc, me habría dado cuenta de que yo estaba
calculando mucho más de lo que realmente necesitaba.
Ahora sí que van de la mano y por tanto, ahora puedo venir aquí y probarlo.
Voy a haber diferencia?
Pues lo más normal es que no vaya a haber diferencia.
Pero ahora sabéis que está más optimizado.
Os daríais cuenta si aprietas el profe Weiler de ver cuántas veces se llama 1 y cuántas veces se llama
otro.
En este caso.
Va a ocurrir lo mismo que antes.
Aquí está el bicharraco.
Vale, se mueve para un lado, se mueve para otro.
Vale.
Lo que pasa es que ahora los dos van de la manita.
Bueno, a mi me.
Buena pregunta.
Hasta ahora teníamos aquí, dentro del taime del Tatooine, que era el que utilizábamos como parte del
del fix de la DOIT normal y corriente.
Cuando lo movais al fix tap that.
Hay una variante que no está en el Tatin, sino que Sixt del Tatooine es el equivalente al del Tatooine.
Pero que se utiliza en los métodos de Fix.
Vale.
Estaría mal utilizar el Tatin?
No estaría mal.
Pero la velocidad de giro no sería exactamente la que vosotros habéis pedido.
Porque vosotros llamáis a menos veces al método que antes.
Por tanto, el tiempo entre uno y otro es mayor.
Pero estáis utilizando el del Tatin del App Taito original.
Por tanto.
La cantidad de movimiento se vería reducida con el fix del Tatooine.
Es el equivalente.
Es decir.
Cuánto ha pasado desde el tiempo anterior?
A ver, es un número.
Es cero coma cero dos.
Podríamos poner por cero coma cero dos, pero si alguien lo cambia en el input, en el Project Settings,
creéis que se cambia?
Entonces, si cambiamos el Tatin por el fixed del Tatooine, ahora vais a estar utilizando el valor
que siempre está definido aquí en los Project Settings.
Y como os decía, por defecto es cero coma cero dos.
Si al final lo importante recordar es que en Unity por defecto si no cambiáis nada se llama al fix that
de 50 veces al segundo.
Siempre en todos los casos, las pocas preguntas.
La respuesta es sí, siempre y en todos los casos, porque esa es la función del fix, del Tatooine,
del fix and that.
Entonces ahora deberíais ver exactamente lo mismo que antes, lo que ahora estáis utilizando un intervalo
fijo.
Dicho sea de paso, a ver cuando el juego corre a tantos frames por segundo os da un poco igual, pero
tiene una ventaja es que el Fix Update nunca va a bajar de velocidad.
Podrá tardar más o menos en renderizar, pero siempre irá a la misma velocidad.
Por tanto, el movimiento será llamemoslo más justo, será más acorde al motor.
Si hubiera una bajada de frames da igual el fix del tratabamos seguiría moviendo, aunque el motor de
render in tardara en moveros.
Vale, es más justo el otro podría llevar a cabo a injusticias del tipo.
Joder, es que me he movido, pero ha habido una bajada de Freinet.
Vale.
Mientras que si no el movimiento lo calculá.
Algo que es independiente del frame lo mueve, lo coloca, lo pone y funciona.
Sí.
Por tanto, ya tenemos otra cosa lista.
Tenemos el controlador de Lemon y fijaros cómo hemos podido comunicar de forma super amena nuestro script
que utiliza el motor de físicas y un Rishis body para moverse con el.
El Animator es la combinación de los dos la que me da esta cosa.
Y de hecho, este movimiento tan característico de Lemon con los otros no lo había podido hacer porque
hasta ahora siempre he usado cubos o personajes muy muy Minecraft, no muy cuadrado, donde las animaciones
no se prestaban a ello.
Este sí y de hecho podéis entender por qué le han puesto tanto mimo a la animación para poder jugar
precisamente con aspectos un poco más avanzados del motor en este caso.
Sí, vale, estupendo.
Pues ya tenemos aquí al lemon.
Y ya le podemos poner la casa encantada.
Vale, vamos a poner la casa.