Ahora estad atentos que esto la gente se suele liar la primera vez.
Hasta ahora hemos hecho una comunicación en nuestros escritos que ha relacionado vuestro objeto con
sus otras componentes, con mi Heider, con mi Rizzi Body y los he ido toqueteando.
Este punto en el que estáis ahora requiere una comunicación entre objetos.
Hasta ahora habéis hecho intra objetos con objetos y si ellos mismos y sus otros componentes ahora necesitáis
hacer ínter objetos, necesitáis que otro escrit consulte el estado de la variable que mover que tiene
el pavo el controlador.
Entonces?
Esto es muy importante porque esto va a querer decir que el fondo necesita saber dónde está el pledge.
De hecho, el player controller para poder acceder a sus variables o el escáner que va generando cosas
ahí a saco a piñón, va a necesitar saber dónde está el player para poder leer el valor de la variable
y mover entonces a la hora de parar el movimiento a izquierdas.
Lo que hay que hacer es lo siguiente tenemos un bule auno game over que es conocido y dominado por el
player control.
Funciona porque hemos visto que aparecen CHEC.
Necesitamos que otros lo lean, de modo que enseguida que ocurra esta colisión que haya aquí no sólo
el valor de mover pase a ser verdadero, sino cualquier otra cosa que se estuviera moviendo a izquierdas,
automáticamente se pare de mover.
Por tanto, el script Muflones, que ha vivido muy feliz con una sola línea de código hasta el momento,
trasladando un poco más.
Ahora va a necesitar conocer de la existencia de nuestro Player Controller.
Por eso os dije que muchas veces se utiliza el gains manager, porque tiene sentido conceptualmente
que sea el manager quien coordina el resto de cosas.
El player, el escenario, los enemigos, los lo que sea que no hablen entre hermanos.
Ahora van a hablar entre hermanos.
El que mueve a izquierdas va a hablar con el controlador, que es su hermano.
Por qué no tiene un manager por encima?
Vale, se puede hacer, pero ahora que los proyectos son muy grandes vais a ver que suelo crear un manager,
porque tiene más sentido que sea el director quien te diga lo que tienes que hacer, que se lo preguntas
a tu hermano, que lo tienes al lado.
Pero bueno, que se puede hacer entonces una vez que tenemos esa variable y que es pública, al haberla
hecho pública cualquier otro va a poder consultarla.
Lo que pasa es que, claro, el left no tiene acceso a esa variable.
El mofle, que es nuestro background, pues tiene el Mugler del RIP Bagram de un colíder, un de RENDERED
y un Transform, no tiene un controlé.
Cómo puede consultar el controller?
Pues no lo puedo hacer, al menos no por el solito.
Quién es que quienes tienen el control leer y por tanto la variable que mover?
El Player Player tiene un player controles y controles.
Tiene la variable que mover, pues hay que hacer todo el recorrido, hay que pedirla.
Y Unity es donde está el player del player.
Hay que decirle dame tu player controller y del play control hay que pedirle dame tu variable que mover.
Ves que vuelve a ser lo mismo que antes de ir encadenando uno de otro, uno de otro, uno de otro,
uno de otro.
Lo que pasa es que en lugar de ser mis propias componentes Get component entre diamantes tipo ahora,
lo primero es localizar algún otro tipo de objeto basado en alguna condición.
Cuales son las formas más típicas de localizar los otros objetos?
Hay dos por nombre o por etiqueta.
Si solo hay uno por etiqueta, sí hay varios que pueden tener el mismo tipo de etiqueta.
Y queréis uno en concreto?
Os tocará por nombre.
Si no todos tiene la misma etiqueta, no vais a distinguir uno u otro.
Así que aquí, en este caso, lo que vamos a hacer es localizarlo.
O bien por un modo o bien por otro.
En este caso tenéis una ventaja.
El objeto se llama player y la etiqueta se llama Player, donde me he ido.
Aquí el objeto se llama Player.
La etiqueta se llama Penella.
Tanto uno como otro.
Entonces, en el escrito de muflones, que es lo que necesitáis exactamente, necesitáis saber el valor
de la variable y mover el valor de la variable que mover quien lo tiene.
El player controle el script de player, controle.
Por tanto, vamos a crear una variable.
De qué tipo?
No será float, no será entera, no será un monje, será player controller, es decir, aquí hay leyes
contra el tipo de datos.
Vuestro propio script lo veis?
No estáis usando una componente creada por Unity, no estáis usando un tipo de dato básico como enteros
flows o julianos.
No estáis usando una raíz ni estáis usando un AdMob.
Estáis usando una instancia de vuestro escrit player.
Controle y le vamos a llamar Player Controles a la que lo escribo y esto me sirve Fantãstico para introducir
el nombre que me sugiere.
Rayder lleva una barra baja.
A ver, está claro que es una variable.
Si es una variable no la vais a llamar nunca en mayúsculas, pero es que a la que la pongo en minúsculas
le meto una barra baja adelante.
Qué es esto?
Resulta que las variables se nombran con minúsculas y a partir de ahí, si son dos, tres palabras capitalizadas
con el cambio cais a cada una de las palabras vale bien.
Lo que ocurre es que las propiedades que normalmente se tienen por componentes externas un colíder,
un rishis body, un player controller las queremos marcar con un énfasis diferente.
O sea, ya no son números.
Ahora son propiedades al completo que pueden hacer muchas cosas, como saber el estado del gas, mover.
Entonces vais a ver que muchas veces aquí, por ejemplo, en el controller el rishi body os acordais
que le llame player rever el body?
Probablemente cuando vea autocompletado también me lo ha sugerido y yo he pasado de él a ver borrar
esto.
Ah, bueno, porque no lleva la palabra leída, pero si escribo Rizzi Body que ya me lo sugieren.
No lo vas a llamar en mayúscula, porque el de mayúscula es la clase.
Si lo llamas en minúscula.
Además, hay otro problema y es que Junichi ya tiene una variable Rising Moovit, obvio.
Por tanto, ya la Belial porque estés machacando una variable que no es vuestro.
A la que le queráis llamar como la propia clase, como no es un tipo de dato básico, ni es una RAI
o sugiere la barra baja.
En general, utilizar esta nomenclatura para properties para todo lo que sean propiedades de objetos
que vayan con barrabas, salvo que sean variables de tipo de datos básicos floods, enteros, booleanos
y demás.
Aquí lo voy a dejar con la que estaba.
No voy a meter mano a lo que he hecho antes.
Lo dejo como playeras, pero acostumbraré que cualquier propiedad de este estilo se suele nombrar con
barra baja.
De acuerdo.
También es algo que es muy típico de C.
No es que se haga en Java.
Java no lo utilizamos Nabarra abajo para nombrar variables, al menos no de forma natural.
Vale, pues tenemos el player controller.
Evidentemente este player controller no lo tiene.
El fondo que se mueve a izquierdas es otro objeto donde preguntarías por la existencia de este objeto
con esta componente de Takada.
Yo creo que ya os ha quedado claro que si no queréis salir escaldados por tanto en él en el estar,
lo podríamos hacer en el weak.
No rotundamente, porque si se despierta el elefante es que el player, a la vez que yo quiero buscar
el player, no el painter exception os da un error.
Vale, por tanto debe ir por narices en el estar dentro del estarte.
Es muy simple la variable barra baja player controller que acabáis de crear se le asignará y ahora hay
dos formas, una de ellas por nombre y la otra por etiqueta.
En cualquier caso, las dos pasan por preguntar a la clase iMovie.
Por tanto, si es clase con la G mayúscula, recordad que mollete en minúscula ya el utilizado para
consultar el Transform o el Destroy Game Object en minúsculo en minúscula hace referencia a la variable
a mi mismo como objeto en mayúscula hace referencia a la clase como cuando usado la clase físicas vale
lo mismo.
Gameshop en mayúscula no la leais en mayúscula es la clase, no el objeto.
Punto.
Y si escribis la palabra finta hay varios find filled stack feingold object optics y luego están las
mismas en plural finja objects, hostigue with TACC, etc. Entonces a saber find para buscar por nombre
find y entre paréntesis nombre del objeto.
El nombre que pongo aquí es este.
Tal cual.
Que tiene espacios, acentos, celdillas ñ.
Tienen que estar.
No recomiendo que hagáis uso de esas cosas, pero si aquí la habéis llamado por un espacio en blanco,
que es la cosa más tonta del mundo, aquí el nombre tiene que ir con el espacio en blanco.
Este es el nombre.
El nombre de la jerarquía es el primero de los métodos.
El segundo es Find Wiz TACC encontrar un objeto que tiene una etiqueta.
Este cuidado que tiene un problema si buscáis un objeto con etiqueta en singular.
Cuántos objetos con esa etiqueta puede haber en pantalla?
Uno y solo uno, porque si hay dos os podría devolver cualquiera de los dos.
Es más, cada vez podría devolver uno diferente.
Entonces, tened en cuenta que todo lo que sea estocástico, todo lo que sea aleatorio, se lleva muy
mal con estos métodos que en principio son deterministas.
Entonces, filled with TACC solo deberíais usarlos si el gameshop.
Si con esa etiqueta.
Si no, pues unas veces recibiréis.
Otras veces recibiréis otro.
Y por eso, de hecho, si os fijáis, hay los mismos en plural que acaban en que os devuelven a raíz
de que Bob Gex lo veis aquí, porque en el caso de que haya más de uno que queráis, todos los enemigos,
todas las balas, todos los objetos, todos los algo se llama al método que acaba en este fin Objects
Optics, Fangal, Objects with TACC, etc. y el OPTICS os da la posibilidad de recuperar el objeto que
tiene una determinada componente.
Por ejemplo, podríamos utilizar el fin objectos óptico y pedirle el único objeto de toda la jerarquía
que tiene un player controller.
En este caso usaríamos Find Objects Optics tipo y el tipo de componente type of play el.
Lo que pasa que esto de nuevo estáis obligados a que sólo haya 1 recomendación.
Este de aquí el de óptico es más costoso porque tiene que buscar todos los objetos y de todos los objetos,
buscar que al menos una componente sea de este estilo.
Este es el más costoso.
Vale, por tanto, este no lo recomiendo mucho, salvo que no haya otra forma de identificar los objetos.
Si no tenéis nombre o no tenéis etiquetas, os va a tocar hacer esto.
Si tenéis nombre o tenéis etiqueta, que es mejor nombre o etiqueta.
Hay mucha diferencia.
Al final son strings, son marcas que le ponéis y por tanto, si sabéis el nombre ponéis el nombre.
Si sabéis la etiqueta, ponéis la etiqueta.
Lo único, eso sí, que no haya dos objetos llamados player's o no haya dos objetos con la etiqueta
aleya.
Pues si no será un cachondeo, vale.
Por ejemplo, si esto fuera un juego de dos personas, está claro que colocar aquí el nombre no sería
una opción, porque uno será Player 1 o 2 player 2.
Colocar etiqueta Find Tack Player.
Sería una opción para un juego de dos personas.
Lo sería si pongo esto, finja y cuesta, vale.
Así que si que sería una opción, porque así recuperaría una raíz Monges Boys.
En nuestro caso es un single player.
Sólo hay un player.
Sólo hay una etiqueta player.
El que os dé la gana, o sea, Fayette, es el más corto.
Esto de aquí Game Object Player os devolverá.
Ojo esto, eh?
El armazón, el cascarón, el prefacio, lo que haya allí.
Vamos, ahora que tenéis el padre.
Vosotros que quería ir, guardar aquí queríais todo el padre.
No queríais el player controller?
Esto de aquí, de hecho, que devuelve, devuelve un objeto de la clase Cambodge.
Es decir, si esto lo queréis guardar como Game Object Fantãstico, ya está, se acabó.
Pero si queréis una componente, cuando tenéis un game movie, cómo se accede a una componente de un
mismo objeto?
Component Y entre diamantes, tipo de componente que en mi caso es un player controles.
Esta vez, que es lo mismo que antes, os hago el intro para que lo leáis mejor.
Gameshop Jeffry Employer que de hecho como me encanta Rayder fijaros ya os dice que hizo un gay molletes
que es pa idiotas tío.
Programa hasta el verdulero de la esquina que nos ha tocado un ordenador en su vida y del gay monje
recuperás el player controles.
Lo veis?
Player Controller ahora tiene exactamente una instancia del ESCRIT Player Controller y como tal yo ahora
puedo consultar de Player Controller cualquier variable en particular.
Estaba esta variable que hemos dicho que mover esto significa que me puedo venir aquí a las bait.
Y este código de recordar qué hace desplaza el objeto a la izquierda ad infinitum y si o no solo debe
ejecutarse esta línea de código.
Si goy mover folks entendemos sigue es pols si no hemos llegado al fin de la partida.
Así que en este caso lo rodeamos con IP del Player Controller.
La variable de mover.
Supongo que querrías hacer algo así.
Igual igual a Fool's.
Si el game over que dice el Player Controller es falso.
Se debe ejecutar la translación si todavía no ha llegado el gas, mover deja que aquello siga palante,
lo entendemos.
Del mismo modo que os he dicho antes que comparar contra igual igual a Trump, es una idiotez.
No hace falta poner igual igual a Trump, porque una variable booleana ya es verdadera, por tanto es
resultado de la condición que evalúa el igual igual a Fool's es equivalente a decir que lo contrario
de esto es verdadero sí o no?
Es decir, una condición equivalente a este a esta sería que esto que su contrario es verdad.
El contrario, la negación en informática se suele hacer con el signo exclamación delante.
Esto quiere decir no?
Si el player controller dictamina que no hay que mover.
Si esta condición es verdad, entramos aquí dentro y por ende, como de igual a igual a otro, es totalmente
inútil borrarse de igual a igual a otro.
Y ahora sí que es como leer un libro.
Fijaros si no hemos llegado al mover el primer, si es condicionales, si no hemos llegado al goy mover,
muévete para la izquierda.
Conceptualmente es lo que estabas pensando.
Si no hemos llegado al fin de la partida, sigue moviéndote y hasta si no hemos llegado al fin de la
partida sigue moviéndose.
Esto quiere decir que si lo guardáis cualquier cosa que tuviera el escrit mofle.
Ahora, cuando el valor sea game over, es decir, cuando chocamos contra un obstáculo, finalizarã
la partida.
Por tanto, venimos aquí, vamos al play.
El juego arranca, me voy moviendo, voy saltando, voy a esquivar uno para que veas que todo se mueve
bien, a la que choco, que.
Además se para todo, se para al fondo y separar el mamarracho.
La cosa esta puedo seguir saltando porque aún no lo he parado, pero fijaros que por todo lo demás bastante
sencillo, no?
Si además fijaros un pequeño detalle, de hecho no os habéis dado cuenta.
Ahora mismo hay un buque en pantalla.
De hecho, debe haber una pila aquí, ahora ya.
Estupendo.
Hemos creado Diogenes en pantalla putamadre que se siguen creando y caen por aquí.
Esto es como el repartidor de Amazon que te va tirando los paquetes a la valla.
Vale, si he parado el fondo hay otra cosa que tengo que parar que el escáner, el escáner que están.
PALMAUn ayer.
Recordad que yo he hecho aquí un inbox.
Repiten y van repitiendo y repitiendo y repitiendo y repitiendo que parece la salsa al kebap.
Lo ves?
No, para esto sigue.
Sigue acabado el fin de la partida.
Igual sigue, sigue, sigue.
Qué tengo que hacer para que se pare?
Lo mismo que antes necesito el Player Controller, necesito acceder a la variable game, mover del Player
Controller y solo hacer el instante wait si no hemos llegado a mover por tanto Playboys Player Controller
y por lo que os he dicho antes, barra baja player controller en el estar, barra baja Player Controller
igual a Going Movie, Puntofijismo Leger y Player Get Components entre diamantes.
Player Controller Pues lo pongo con un intro y solo ejecutar es un obstáculo.
Si no, el Player Controller ha llegado, ha estado ahí.
Game over.
El código es el mismo, es tal cual.
O sea, yo lo he escrito porque me cuesta diez segundos, pero lo copia, espera del otro y debería
funcionar porque fijaros que ahora el spawn obstacles solo va a escanear, sólo va a hacer un instante.
Y si el player controller no ha llegado a mover, lo entendemos.
El resultado?
Dejadme probarlo y ahora os lo dejo en pantalla para que acabáis de copiar.
El resultado es que cuando ahora yo muero se debería parar el fondo.
Evidentemente.
Pero para el fondo.
Si no me equivocado, aquí ya no deberían aparecer más basuras, vale.
Y fijaros que de hecho os acordais que os he dicho que aún podía saltar si yo ahora me cojo el player
ahí donde está el pledge?
Por Dios, si me cojo el player y me lo muevo, opacaba y le quito el valor de mover, que todo se sigue
moviendo y se generan más objetos hasta que vuelvo a chocar.
Veis que se siguen generando, sea todo ahora depende de esta variable y de hecho lo que os estoy enseñando
ahora son Jack.
Por qué?
Porque si yo ha salido un barril del otro lado, estupendo.
Pura física.
Entonces, una cosa con la que hay que ir con mucho cuidado es que estas variables tan peligrosas como
el game over ahora las estáis dejando expuestas.
Qué quiere decir esto?
Que yo aquí sí la he dejado expuesta.
Podría tener un trozo de código que hiciera a Player Controller punto y mover igual a fouls.
Es más, lo pongo en el Android.
El juego nunca acabaría y habría jaqueado juego, porque aunque yo muera, da igual, me lo vuelvo a
poner a falso, yo puedo seguir jugando, así que ultima cosilla.
Qué opináis de que la variable que mover sea pública?
Malo no está mal, pero claro, la parte privada se la hago privada, se queja leff se queja de un manager,
se queja todo el mundo porque no puede acceder a una variable que es privada en otra clase.
Habrá que ver como lo hacemos.
Habrá que ver cómo lo hacemos, porque privada parece que no es una opción muy viable por ahora.
Vale.
Ahora veréis cuál es el truco.
Borro esto.
Por cierto, no me dejéis aquí si el otro adeu.
Lo he borrado nada.
Vale, pues vamos a ver cómo se puede hacer este último cambio.