Vale para destruir los enemigos.
Lo más fácil es que si tenéis una variable llamada top bown también tengáis una variable llamada Lower
Bound, vais a tener Tobatí igual a 30 y Float Lower Bound igual a menos 20.
Creo que es más que suficiente.
Menos 10, menos 20 menos lo que sea.
Lo que menos de sobra menos 10.
Como no es simétrico.
Vosotros mismos podéis decidir dónde lo queréis y fijaros que ahora lo único que habría que hacer es
colocar debajo de éste otro posible.
Y en este caso sería y disputo Transform punto opposition punto Z es menor que lo Huerva y haríais exactamente
lo mismo en Destroy Disputo.
Sin embargo, fijaros que aquí lo que es el proceso de destrucción es el código del Interior del método
de Delight es el mismo.
Por tanto, esta condición, si ocurre esto, destruye.
Si ocurre esto, destruye.
Lo puedo juntar de un modo muy simple.
Si ocurre esto o ocurre, lo otro destruye.
Vale, entonces hay los dos operadores que sirven para la lógica Pulianas son el anti logro.
ADN se escribe como un doble A&G y cuando escribís X ante Y esto es equivalente a decir que se debe
cumplir x e y a la vez las dos condiciones booleanas.
Cuando haceis humor se escribe como x dos barras verticales que son las que hay con la tecla pulsada
y el número 1, x o y.
Básicamente se debe cumplir x o y uno u otro, y esto no es mutuamente exclusivo, es el uno del otro
o los dos, vale.
El caso más típico es solo puedes entrar.
Si x llevas mascarilla y pagas 10 euros, necesitas llevar la mascarilla y pagar los 10 euros para que
se cumplan las dos condiciones si es o si llevas mascarilla o si pagas 10 euros.
Si llevas mascarilla, pasas.
Si llevas 10 euros pasas.
Si llevas mascarillas y llevas 10 euros, pasas también.
Y si no llevas ninguna de las dos cosas, es la única en la que esto es falso.
Correcto.
Por tanto, fijaros que el código para destruir es que Transform Position Z sea mayor que Bounds.
Luego os lo voy a poner entre paréntesis para que quede más énfasis de la condición o la otra condición,
que es que transform posición menor que lo huerfanos.
Por tanto, veis que he juntado las dos condiciones que antes estaban separadas en dos IPS, ahora están
en uno solo.
Lo veis así?
Es más sencillo porque aunque la condición se ha complicado aglutinar los diferentes casos, los diferentes
escenarios para que la lógica de ejecutar sea la misma.
A ver, aquí os lo he hecho todo.
Dentro de Univ.
Podéis crear dos variables auxiliares, es decir, como he hecho aquí X Y, que serían las dos condiciones.
En este caso podríais definir la primera condición booleana condición 1 que fuera esto que tengo aquí.
Segunda condición booleana que fuera la que tengo abajo
y que en el interior de lo que chequear afuera condición 1 o condición 2 lo veis que es exactamente
lo mismo que tengo que tenía antes?
Exactamente lo mismo, porque aquí cada objeto tiene una coordenada z si la Z es mayor que bounds.
Esto es verdadero.
Correcto si es verdadero esta condición.
Condición 1 se cumple aquí.
Lo segundo es que la posición Z sea más pequeña que la frontera inferior.
Si la coordenada Z es más pequeña, esta condición será verdadera.
Correcto.
Al entrar aquí, como están unidas por un HOR, se tiene que cumplir que o la Z sea mayor que la frontera
superior condición 1 o que la Z sea menor que la frontera inferior condición 2.
Entonces este IFF lo que me hace es decirme si te pasas por arriba o te pasas por abajo, destruye punto.
Vale lo que sea más cómodo.
Hay gente que le gusta crear variables por un tubo y que cada una tenga un significado.
La condición 1 es pasarme por arriba.
La condición 2 es pasarme por abajo y luego chequeados aquí.
Yo prefiero como lo tenía antes, es decir, sin variables intermedias.
Y que sea como leer un libro así.
Pero bueno, para gustos, colores.
Vale, vamos a probarlo ahora.
En principio, si yo le doy al play, las balas seguirán desapareciendo.
Cuando disparemos y nos pasemos por arriba para ver los animales desaparecer, pues vamos a fijarnos
en primero en el perro, que es el que primero debería desaparecer.
Y por qué no desaparece?
Porque no lo he puesto en la escritura.
Vale, si no le ponéis el script, pues no desaparece.
Recordad que se lo habéis programado a esta cosa al distro y autos bounds, que antes sí que lo hemos
arrastrado a la comida.
Pero ahora para los FAB es muy fácil seleccionar los cuatro de golpe, añadir componente distro y autoevacuados.
Y ahora si le damos al play, porque si cambiáis el app automáticamente los hijos cambiarán acorde a
ello.
Entonces ahora volvéis a tener a los 4 animales y veis que van desapareciendo cuando llegan al final
fijaros que la lógica es exactamente la misma, la misma, la misma, la misma.
Es lo mismo destruir una bala que destruir un animal.
La diferencia está 1.
La condición chequeada por arriba, el otro lo chequea por abajo, incluso a verlo.
Podríamos haber juntado con un valor absoluto o con alguna función para escribir dos líneas de código,
pero yo creo que así está fantástico, porque al final lo que tenemos son estas variables que son las
que me van a poder determinar cuando un animal ya no es necesario o cuando una bala ya no es necesaria.
Y no sólo esto, si luego permitiera que el personaje, en lugar de disparar para arriba, disparara
para abajo o los animales, en lugar de ir de arriba abajo, fueran de abajo arriba.
Igualmente funcionaría porque lo único que hago es chequear cuando se ha salido del cuadrado de juego.
Vale preguntarse esto.
Bueno, pues ahora ya somos capaces de escribir gameplays diferentes.
Habíamos visto antes que podíamos utilizar taxis, sobre todo para movimiento, cantidad de movimiento
en un eje u otro.
Ahora, además, os he sumado la forma de capturar eventos basados en teclas, la tecla del espacio.
Por ejemplo, hemos sido capaces de instancias, objetos, cosa que hasta ahora no sabíamos.
Ya sabemos como se instancia en objetos en tiempo real y nos hemos fijado en que podemos detectar utilizando
un script cualquiera cuando un objeto se ha salido de ciertos márgenes.
De hecho, aquí haberlo hecho por CETA mayor que Z, porque si vais a hacer que el juego sea un poco
más difícil y que los enemigos no sólo vengan de arriba hacia abajo, sino también que vayan de izquierda
a derecha, habría que adaptar este código del distro y bounds para chequear si nos salimos por izquierdas
o derechas.
En ese caso, qué variable X y Z usaríamos para comprobar si nos hemos salido a izquierdas o derechas
de la pantalla?
X vale la X y chequee haríamos si la X es mayor que la X es menor que os voy dando ideas, porque si
ahora cogéis la vaca, ésta o el burro o lo que sea y lo Rotax que mire, vaya, lo más normal es que
el burro si se va a salir o se queda el alce que se va al lado.
A lo mejor, como ya se ha salido de la pantalla, ya lo queréis borrar.
Este burro aquí ya no me sirve de.
Veis ahí no hace absolutamente nada.
Podéis adaptar el mismo escrit para que tenga en cuenta que la destrucción también puede ocurrir si
os salís de los bordes laterales.
Si me acuerdo, perfecto.
Yo no voy a dejar mirando pa abajo de momento, pero cuando quiero subir la dificultad igual es algo
que implemento que se pueda rotar un poco y que no todos vayan de arriba abajo, sino que el movimiento
sea diferente para que sea más difícil.
Te vale?