Bueno, hasta ahora el enemigo ya les hemos dado el poder de rebotar, pero sólo rebota si mi player
le da un golpe.
Si mi player se acerca a lo que debo hacer es lo contrario y lo tengo que indicar al enemigo que se
acerque donde está mi player, que lo persiga por toda la isla y que el propio choque implique un rebote
y que, por tanto, al hacer que rebote me lo mande fuera de la isla.
Vale recordar que la gracia de tener el material este al final es la de que el choque te empuje lejos,
asi de facil.
Entonces si yo hago que el enemigo venga con fuerza hacia mi, el propio rebote me enviará a Mordor
basicamente.
Vale, podéis imaginar que si quiero que el enemigo venga al player, voy a necesitar otro escribe.
Vale, entonces vamos a la carpeta de los scripts y vamos a crear un script que voy a llamar Enemy,
porque va a ser la lógica del enemigo y se lo voy a dar al enemigo, que para eso se llama igual que
el script, lo arrastramos al enemigo y abrimos el script.
Rayder
El enemigo se mueve por fuerzas físicas otra vez porque le hemos metido un body y lo que quiero es pues
oye, que siempre vaya con fuerza.
Esa es la palabra clave con fuerza al al enemigo del enemigo que sería el play herbales.
Ahora, cuidado, los nombres van a ser muy divertidos.
Cuando ahora hable del enemigo del enemigo es el pledge.
Vale, entonces si son involutivo, es el enemigo del player, es el enemigo.
El enemigo del enemigo es el player.
Así que en cuanto a lógica, no será tan diferente de la del player.
No será tan diferente de la del jugador, en el sentido de que lo voy a mover porque tiene un rishis
body y le vamos a aplicar una fuerza de colisión.
La diferencia estará en el objetivo el Player Controller.
Os acordáis cuando lo hemos programado hace un rato?
Aplicaba una fuerza en la dirección forward del punto focal, la coordenada relativa del punto focal.
Os acordáis?
Entonces mi enemigo que va a tener que hacer, pues va a tener que hacer exactamente lo mismo.
Pero la dirección cuál va a ser su forward?
No la dirección que el enemigo con el jugador.
El vector que desde aquí une, la posición donde está el enemigo, donde está el player.
Ese vector tendrá que ser la dirección en la que se mueva.
Así parecerá que persigue al jugador, de modo que he visto desde aquí arriba si esto es mi enemigo.
La dirección a la que se tiene que mover sería el vector que empieza en el enemigo y acaba en el player.
Y si en un momento dado yo muevo el enemigo y lo coloco por allá, ahora debería moverse en esta dirección.
Veis que la dirección cambia a cada instante porque depende de donde está el player.
Entonces, este es el caso perfecto en el que volvemos a necesitar una variable adicional, como ya
ocurría con el focal point focal, para que lo utilizado para poder mover el player en dicha dirección,
independientemente de cuál fuera la dirección en la que miraba el punto focal para el enemigo, esto
va a ser exactamente lo mismo.
Es decir, voy a necesitar las tres mismas variables que tenía en el player, es decir, un body privat
Ranjit Body y ya sabéis como es una propiedad del propio objeto de la propio comportamiento.
Es más, rebajã rising body.
La fuerza de choque la voy a hacer públic float fors como lo llamen Fort Valio, Bofors, Mouffe, Fors.
Y el tercero y último es hacia dónde quiero ir, qué dirección pleura.
Entonces antes lo hicimos público para poder arrastrarlo.
Os acordáis?
Podemos volverlo a hacer público para arrastrarlo.
O si preferís, ya optamos por la manera segura que es Privat Gay Movie Player.
Y si lo hacéis así, lo que tenéis que hacer en el arte es localizar al player en primer lugar.
Así que el barra baja Ricky Body será el componente de diamantes Ranjit Body Body, al cual mientras
que el player lo vamos a localizar haciendo igual a Gay Mob en mayúscula puntofijismo.
Y si lo habéis llamado player escribis player si le habéis llamado bola escribir bolas y le habéis llamado
Antonio Banderas escribis.
Antonio Banderas Se puede usar etiqueta porque sólo hay uno correcto.
Por tanto, ya tenemos asignado régimen body, tenemos asignado el player que básicamente haberle llamado
player.
Si lo queréis hacer más genérico, en lugar de players le podéis llamar Target y el target podría ser
el player, pero podría ser un punto del escenario.
Podría ser un povera.
Si quisierais que los enemigos fueran a por otras cosas de este estilo sería lo mismo.
La diferencia con respecto a lo que hemos hecho hasta el momento va a ser la siguiente.
Y es que en el Android acordaos que el Player Controller uno localizaba el axis vertical para saber
qué cantidad había que mover y luego aplicaba una fuerza relativa al punto focal.
Aquí el forwarding ya no sirve para nada en el enemigo.
No, no lo controlamos nosotros, sino que automáticamente podéis llamar a barra baja Ranjit Body para
aplicar la fuerza Authors.
Y ahora viene lo divertido.
Cuál es la dirección en la que tengo que mirar?
Pues siempre es el vector que une el centro del enemigo con el centro del player.
Correcto.
Cuando tenemos dos puntos del espacio, dos posiciones, el vector que las une siempre es destino,
menos origen siempre vale, de modo que cuando tenéis hacer un dibujo.
A veces es bastante útil si yo aquí tengo la bola que representa al enemigo.
Por tanto, la voy a poner de color rojo
y tengo la bola que representa al player.
Voy a poner de color blanco, blanco o mejor verde, pero si no, si yo quiero que el enemigo se dirija
al player.
Lo que tiene que ocurrir es que el vector de fuerzas tiene que empezar en el enemigo y acabar en el
playa.
De modo que cuando aquí lo voy a poner negro para que lo veáis un poquito más grande, vale.
Este tiene que ser la dirección en la que nos movemos.
Si en un momento dado mi player se mueve, mi enemigo tendrá que cambiar su dirección porque siempre
quiero que vaya hacia el player.
Entonces, para sacar un vector siempre es punto de destino de los puntos de origen.
Siempre, en todos los casos, vale.
Así que en este caso es muy fácil.
El destino lo especifica el posición del transform del playa.
El origen lo especifica el posición del transform del propio enemigo, del propio monte que tiene el
escritor.
En nuestro caso, lo que voy a hacer es definir aquí Vector 3 la dirección, que es la dirección del
movimiento.
Esta dirección va a ser Destino Player Punto, Transform, Punto Position.
Esa es la posición de destino a la que quiero llegar menos.
La posición de origen es la del propio enemigo, es decir, yo mismo.
Punto Transform punto positivo.
Lo que pasa que esto tiene un problema.
El problema es el siguiente si yo defino que esto es mi vector de movimiento, mi dirección, fijaros
que sería el mismo, el mismo, el mismo.
Os dejo aquí escrito, veo copiar como locos.
Vale, sería lo mismo qué esta cosa?
Sería exactamente la misma dirección esto que esto, veis que la dirección es exactamente la misma,
la misma, la misma, la misma, la misma misma, lo que pasa es que el vector es más corto.
Qué pasaría si yo ahora no modifico esta dirección?
De ningún modo?
Pues fijaros que cuanto más lejos está el enemigo del enemigo, el player, cuanto más lejos está,
más largo es el vector.
Por tanto, a nivel de fuerza, más grande sería la fuerza que aplicamos.
Entendéis porque la fuerza es proporcional a la magnitud del vector.
Entonces, el truco que se hace siempre que trabajais con vectores es normalizarlo.
Y qué quiere decir normalizarlo?
Que todos tienen que tener módulo.
1.
Módulo es la longitud.
Así que en este caso, independientemente de si estáis muy cerca o muy lejos, el truco va a ser el
siguiente.
Se define alrededor del propio enemigo, que es quien aplica la fuerza.
Aquí algo así se define así hará una circunferencia de radio 1 y el enemigo tiene que tiene que ir para
allá.
Correcto, pero la fuerza va a ser ésta.
El enemigo está por aquí, perfecto.
Pero la fuerza va a ser esta para que siempre la fuerza tenga magnitud.
Lo entendéis?
Entonces, para conseguirlo es muy sencillo.
Lo único que tenéis que hacer aquí es rodear el Transform Position menos Transform Position por un paréntesis.
Y dentro de este paréntesis añadimos justo al terminar punto normalista normalizado, normalizado os
devolverá el mismo vector, lo pone arriba rubito vector UIT-T.
Magnitud 1 es el mismo vector, por tanto la misma dirección y mismo sentido pero normalizado.
Módulo 1.
Vale, me diréis oye, y porqué cuando hemos usado el vector 3 junto a forward Tutina no has usado el
normalizado?
Porque es que resulta que los 6 vectores de Unity ya son normalizados.
Si yo hago vector 3 punto quien es el back?
El back es cero cero uno cero cero menos 1.
Si calculamos cómo de largo es largo.
1.
Porque sería la raíz cuadrada de la suma de los componentes al cuadrado.
Teorema de Pitágoras vale 0 al cuadrado, más cero al cuadrado, más 1 más o menos 1 al cuadrado.
Es 1 raíz de 1 1.
Si coges cualquier otro leff lo mismo menos uno cero uno.
Si haceis menos 1 al cuadrado es 1 +0 cuadrado 1 +0 cuadrado 1 raíz de 1 1.
Veis que todos estos ya son de módulo 1?
Ya no tengo ese problema de acuerdo.
Donde no lo he hecho no lo he hecho.
Si os acordáis en el Player Controller cuando he detectado el Focal Point Transform Forward.
Pero claro, es forward como es forward es el vector unitario en la dirección delantera del focal point.
Siempre hemos usado estos vectores.
Hemos utilizado arriba, abajo, izquierda, derecha, adelante, detrás y esos ya son unitarios.
No nos había hecho falta nunca añadir aquí un punto normal que lo podéis hacer.
No hay ningún problema.
Entonces en su lugar, fijaros que a la que necesitáis un vector que hay que calcular dinámicamente,
sostiene que disparar siempre en vuestra cabeza.
éL recuerda normalizarlo, porque si no lo organizáis os daréis cuenta de que hay un bug, que cuanto
más lejos está el enemigo del player, más corre, porque mayor es el vector.
Lo podemos dejar.
De hecho, podéis hacer la prueba normalizado o no normalizado y veréis vosotros mismos la diferencia.
Entonces, en este caso el authors recordad que siempre son tres cosas es la dirección, la fuerza y
de hecho, si hay algún modificador modificadores que hemos usado.
En el caso de cinemática era el tiempo del Tata, pero sólo en cinemática.
O sea, sólo cuando se transforma en un caso de fuerzas.
No solemos usar denotativo.
Vale, porque la fuerza es independiente del tiempo.
La fuerza se aplica en cada instante de tiempo, no depende del terreno y en el propio enemigo.
En nuestro caso tampoco habrá modificador, porque en este caso solo con una dirección y la fuerza,
el fouls, vais a conseguir el efecto.
Así que es el producto de dos cosas Bofors por dirección yhasta.
Bofors por la dirección lo guardáis, nos vamos al escrit, a la escrita, al editor e importante este
enemigo que ahora tendrá el escrit, el mulford lo tendrá cero.
Vale, no lo dejéis en cero.
Ponerle una fuerza de movimiento, no lo sé por el circo y dale al play.
Deberíais ver como el enemigo se vuelve un poco loco.
Veis que viene a por mí.
No vengas a por mí, no vayas a la luz y me tiro.
Lo veis?
Repetimos.
De hecho, puedes probar de mover escala que yo me muevo.
Va girando e intenta perseguirme.
Veis que he conseguido que cayera.
De hecho, vamos a jugar mucho con estas cosas.
Vamos a poder jugar con el rozamiento.
El enemigo ves que no tiene TRAC.
Ahora como no tiene Trak, le va a costar girar?
Vale, porque él ya va con una inercia.
Necesito que la fuerza se aplica durante bastante tiempo.
En otro sentido, para compensar la que llevaba anteriormente las fuerzas, recordad que se suman.
Entonces, fijaros como en este caso hemos generado un nuevo vector que siempre apunta desde el enemigo
hasta el player, lo hemos normalizado para que tengan norma 1 módulo 1 y hemos sido capaces de aplicar
el producto de este vector por la cantidad de fuerza.
Si no nos normalizamos lo que decía, esto podría estar bien.
Cuanto más lejos, más fuerza le chupamos.
Le quitamos el normalismo.
Vamos a probarlo.
En este caso el escenario era muy grande.
No creo que vayamos a notar mucho.
Pero bueno, en este caso por qué coño no se nota los huevos o vais a lo que voy?
O sea, cómo empieza?
Bastante lejos.
Fijaros ya para empezar.
Esto parece la batalla de 300.
Por tanto, ahí podéis entender por qué está normalizado.
Vale, también pensad una cosa ahora creo que tanto el enemigo como my player tienen más a uno.
Imaginaros si el enemigo tiene más acción sea con más 100.
Primero la fuerza va a hacer que se mueva más despacito.
Veis que ahora le cuesta prepagado?
Se va a mover más despacito, veis que le cuesta moverse.
Ves que le cuesta mucho arrancar.
Ahora pensar que es una mole de 100 kilos que viene contra un objeto de un kilo.
O sea, tenéis una bola de Coca-Cola contra un señor que le va a dar una hostia al cante.
No veis que me toca?
Ya me muevo.
De hecho, ya puedo yo luchar si queréis, pero ante una mole de 100 kilos va a ser imposible que la
frene.
Ahora bien, como tiene ese drac veus que le cuesta frenar, si le pusieran el drac más alto haría que
girara más rápidamente.
Pero es que cuanto más pesa la fuerza necesito que sea más alta para que el movimiento se incorpore.
Recordad que por defecto, por defecto, todas las Portsmouth son de tipo fours y por tanto tienen en
cuenta tanto la masa como la fuerza.
Vale recordar que cuando no coloco nada en estos foros es lo mismo que colocar forth mouth punto fours.
De hecho, si queréis acostumbrados a hacerlo así, vale añadirle siempre el fours.
El formato punto Forth para estar seguros de que es el que queréis ver es el valor por defecto.
No vais a notar diferencia, pero es una muy buena práctica, sobretodo cuando uno empieza a añadir
estos parámetros redundantes para saber exactamente lo que estáis, lo que estáis haciendo.
Incluso aquí esta dirección técnicamente no es necesaria.
Vale, porque todo esto que tenéis aquí, todo este cálculo, yo podría copiarlo y ponerlo como parte
de la fórmula de foros a la práctica.
Esto es una chapuza, como un piano de grande, vale.
La gente se cree que por hacer un programa mejor no hay ninguna diferencia, porque la variable se crea,
se usa y se destruye.
Dentro del Android no hay ningún problema de memoria ni de uso de variables.
Yo prefiero que utilizais variables adicionales como ésta.
De aquí que le deis nombres significativos.
Lug dirección, dirección en la que tiene que mirar.
Fijaros que ahora es una dirección super concreta y que usais es el look de dirección como parte de
la fórmula.
La ventaja es que el día de mañana viene otro programador que a lo mejor no ha trabajado en esto, pero
le habéis dado un buen nombre.
Se ve claramente que es la diferencia entre dos cosas.
Se ve claramente que está normalizada y que forma parte de la fórmula.
Este código es diez mil veces más legible y fácil de integrar entre en un ente más grande, que no una
macro fórmula como la que hemos puesto.
No todo esto copiado y pegado aquí dentro esto la gente cree que podrá hacer un programa mejor.
Lo ha hecho en una línea de código.
El día de mañana viene alguien y esto no hay quien lo entienda, por muy bueno que sea.
Se tiene que traspasar así 30 segundos para entenderlo.
Si esto lo tiene que hacer para cada línea de código, significa que nueva persona que incorpora es
a un proyecto nueva persona, que es un lastre.
Vale, y de hecho por eso muchas veces en el mundo de los videojuegos toda la gente que entra dentro
de becarios 6 meses porque necesita enfrentarse al leer el código del otro, si el otro ya es una persona
que sabe que va a tener que incorporar nueva gente al proyecto, pues nunca va a hacer esto, va a hacer
esto en su lugar.
Y de hecho, si os presentáis al examen de Unity en algún momento, muchas de las preguntas del examen
base son.
En base a esto son.
En base a cuando una persona entra en una empresa, que es lo que le tiene que facilitar el CTO o la
persona encargada o el senior developer, una de ellas es la documentación, que los métodos tengan
una documentación correcta.
Luego hablaremos también un poco de cómo se documentan estas cosas y otras que las variables tengan
sentido.
Hay gente que rige y Bobby le llama RB, que es Robocop radio del beso.
No lo sé.
Radio Balear porque estamos en Baleares, si no lo sabes.
Entonces la gente se cree que es que le he dado un nombre super corto, cómodo y demás.
Esto es un problema cuando incorporas a alguien al proyecto y de hecho lo más normal es que un videojuego
no lo haga una persona.
Lo hago en equipo y para pensar como equipo, como unidad.
Unity viene de Unity, viene de unidad, de poderlo hacer todo con un motor y que diferentes vertientes,
diferentes perfiles se puedan unir para llevar a cabo un proyecto o un videojuego.
Entonces, si queréis abogar por los principios de Unity, lo que hemos dicho propiedades con barrabas
las variables en minúscula tal que no se cuantos, las variables con nombre, con cara y ojos con sentido
de dirección era un poco etéreo.
Dirección de dirección que de mirar, de atacar, de disparar, de saltar, de pegarme un tiro.
No sé cuál es la dirección.
Ahora está claro que es la dirección de visualización de mirar hacia dónde voy a mirar.
Podría tener otra dirección si podría tener una dirección aleatoria para que en lugar de venir directo
fuera haciendo tumbos y que viniera para mí en plan más complicado el juego con la aleatoriedad.
Acostumbrados a estas cosas que siempre, siempre, siempre son las típicas que uno no las comenta cuando
da clase de Unity, pero que son súper importantes el día que queréis trabajar en el sector, en la
industria y de hecho diferencia entre una persona mediocre y una persona que tiene garantías de poder
salir adelante.
De hecho, lo que os digo es si algún día entras en un estudio de videojuegos, lo que os van a hacer
es una prueba y la prueba va a pasar por hacer un modelo 3D, un ridi o una animación, o en texturizado,
como algunos, pero también a veces pasaba por crear scripts, por llevar a cabo funcionalidades, crear
un controlador como la persona que os evalúe ahora al controlador y empiece a ver RB Direction.
Esto lo otro o líneas más largas que la historia interminable.
A decir Bale, este chaval sabe, pero no lo vamos a coger, mientras que a lo mejor otro lo estructura
bien.
No tiene unas funcionalidades tan avanzadas como el otro, que lleva cinco años programando.
Pero la estructura bien lo documenta.
Queda claro contratado, porque yo sé que en lugar de ser 6 meses de lastre para mi empresa, va a ser
2 meses de lastre y al final es un balance entre el lastre que puede ser y qué tan efectivo puede trabajar
en la empresa?
Muchas veces la gente que se rechaza es gente que es buena, que se cree demasiado buena para poder
entrar en una empresa.
Bueno, al menos desde mi experiencia, si vale, pues ya tenemos aquí el enemigo.
Ya me está dando hostias hasta el carné de identidad y nos faltará crear el spammer para que no salga
un enemigo ni salgan dos, sino que salgan 50 y que esto se convierta en un campo de batalla.