Nuestros animales se mueven de arriba abajo cuando llegan al borde de la pantalla desaparecen y si quiero
otro animal, pues no me queda más remedio que arrastrarlo por aquí en algún lado para que aparezca,
porque no hay forma de que se expanden todavía.
Aquí lo que queremos hacer es permitir que el animal pawnee se cree se instance en un lugar aleatorio
de la pantalla en lugar de la zona superior para que aparezca arriba y que nada más instancias se le
ocurra, como le ocurrió a la bala que en este caso vaya para abajo.
Entonces aquí entra el primer concepto que ya me había preguntado acerca de la aleatoriedad cómo poder
establecer una posición aleatoria en la parte superior de la pantalla y en base a esa posición aleatoria
que se expande en nuevos objetos.
En este caso, el Spanic va a ocurrir cuando pulsas otra tecla, os dejo elegir la que queráis.
Puede ser la S de Spanic, puede ser cualquier historieta y lo voy a hacer para que podáis probar.
Luego, lo más normal es que durante el gameplay se expanden a cierto intervalo de tiempo y que lo hagan
de forma automática con una rutina o con alguna función especial.
De momento vamos a ser nosotros quien proactivamente pulsando una tecla se espania, eran enemigos y
de hecho lo voy a hacer mejorar de una vez a otra.
Lo vais a ir viendo.
De modo que en este caso lo que necesitaremos será un script que sea capaz de elegir una posición aleatoria
arriba del todo de la pantalla y que en esa posición, cuando se pulse la tecla de Spawn o similar,
se cree un objeto.
Para empezar, se creará uno o uno de los animales que queráis.
Luego lo vamos a extender a un animal aleatorio de entre todos los disponibles y luego, si queréis
más dificultad, podríamos incluso rotar aleatoriamente o cambiarle la velocidad aleatoriamente para
que algunos fueran más rápidos, otros fueran más cortos.
De todas formas, todo pasa por crear lo que llamamos un manager en el mundo de la programación de videojuegos,
que es un manager.
Un manager es un fichero más importante que el resto.
Si trabajara en un estudio de videojuegos, un manager sería vuestro jefe, hoy manager de todos los
tipos de bajo nivel, que sería el que con el que maneja a los becarios de medio nivel, que sería el
que coordina todos los miembros de un departamento.
Serían AltoNivel Nivel los que coordinan diferentes personas de diferentes departamentos.
A veces los managers reciben otros nombres dependiendo de si están en la parte técnica.
Podría ser un CTO.
Si fuera el jefe jefazo sería el CEO.
Si se encarga del manejo del producto, sería el manager de producto o el product manager.
Habría diferentes roles y, por extensión, un fichero que se encarga de gobernar cosas que ocurren
en el juego.
Hace de manager igual que una persona que hace de manager en la vida real.
Un script es un manager cuando en lugar de tener un comportamiento dirige el comportamiento de otros.
Cuando hace de jefe, en este caso nosotros vamos a necesitar un manager que sea capaz de manejar cosas.
éL es Pauling en sí.
No es algo que le ocurra al objeto de forma inherente.
Un objeto no se pavonea por arte de magia.
Es otro quien le dice que se tiene que escanear ya usado el player controller para escanear las balas.
O sea, que el control es realmente ha hecho de manager en aquel caso, lo que pasa que el controller
es un manager tan especial que tiene nombre.
Controlé es el manager que se encarga del movimiento, es el controlador, es un manager que tiene nombre
y apellidos player controles.
Por lo demás, cada vez que necesitais un manager de un fragmento específico de vuestro videojuego,
la recomendación es que uno vaya en la carpeta de scripts y 2 lleve el apellido manager.
Por ejemplo, si es el manager que se encarga de todo, la lógica del videojuego se llamaría Game Manager.
Si se encarga de pintar en pantalla botones, de pintar la puntuación máxima en los pavura apps y demás.
Pues a lo mejor sería Highway Manager.
Un manager manager de interfaz de usuario como el nuestro es un manager cuya función va a ser es planear
rondas de enemigos, pues tiene sentido que a la hora de crearlo lo llame, lo llame Respawn Manager.
Incluso a ver, podrían haber varios managers de Spawn o Spawn Enemy Manager Spawn Resources Manager.
Podría haber diferentes tipos de managers.
En este caso no me basta con el manager.
Y aunque aquí no lo voy a usar, cuando queréis hacer el mánager de los managers, el director supremo,
el dios de los managers de un script, le vais a llamar game manager.
En este caso no lo vamos a usar, pero el manager es el Dios Todopoderoso y es tan poderoso que hasta
el gráfico cambia
solo por haberle llamado gai manager.
Sabe una rueda dentada y esto es el dios supremo.
Cualquier cosa que pasa en el videojuego se canaliza a través de un manager y un manager dice que no
es que no vale fuera.
No vamos a usar goin manager.
En este caso vamos a abrir, eso sí, el respawn manager, porque el proceso de instancia ación es muy
divertido.
Este es palmauna ayer es un comportamiento, es un genio.
Lo que pasa es que y qué forma tiene un manager?
Es un cubo, es una esfera, es una vaca de estas.
Es una pizza, que es el que es Pacman ayer.
Pues no es nada, al menos nada que sea visible.
Entonces la recomendación es este es un manager, va a ser un comportamiento, va a ser un mono y yo
se lo tengo que arrastrar a alguien a quien se lo arrastro.
Mi recomendación es que siempre tengáis la manía de venir aquí y crear botón derecho vacío y que el
manager que necesitéis sea un objeto vacío, por ejemplo, spawn manager.
De hecho, si le quereis colocar un espacio en blanco, ya sabéis que aquí en el nombre de estos objetos
le podéis colocar todos los espacios que queráis.
También ya os dije el primer día que los objetos que son invisibles.
Dónde viven?
Pues a ver, viven en ningún lado porque son invisibles.
No vais a ver nada.
Sin embargo, este podéis ver que me lo ha colocado en 1,6 en X, menos 12 ni 34 en Z.
Esto no sé muy bien donde está.
Yo lo que prefiero para los objetos vacíos es botón reset y que me lo coloque en el cero cero cero.
Como mucho, si necesito la coordenada x o y o Z, ya lo moveré acorde a ello y este se presta mucho.
Se presta mucho, porque si este va a ser el panel de los enemigos, dónde lo colocaría?
Pues por ejemplo, yo lo colocaría por aquí arriba a la altura a la que queréis que se unen los enemigos.
Evidentemente que no sea más de 30, porque recordad que si se espania algo más de 30 tengo un escrit
que se carga todo lo que está más de 30.
Entonces es una buena solución, sería?
Pues mira, te voy a colocar a 29 y medio por aquí arriba y la propia altura será la que me dictaminará
la zona en la que se pueden escanear.
Este es el típico caso en el que, a pesar de ser un objeto vacío, me puede ser útil.
Igual porque la propia posición en la que yo lo coloco me sirve para decir vale, pues esta va a ser
la coordenada de las zetas en las que van a aparecer los enemigos.
O no vale.
Es una posible solución?
Vale, pero para que veáis que a pesar de ser invisible, el propio objeto por tener posición me puede
dar la pista de donde escanear enemigos.
Ahora que lo tenemos.
Vámonos al escrit del espacio ayer este,
porque me falta decidir cuál es el objeto o los objetos que vamos a poder.
Instancias en este caso tengo 4 enemigos.
Si tengo 4 enemigos y quiero poder spamear uno u otro.
Alguno tendría la tentación de decir ah, si para escanear la pizza has necesitado un Game Moggi para
escanear los cuatro enemigos vas a necesitar un monje enemigo 1, enemigo 2, enemigo 3 y enemigo 4.
Correcto, esto está medio bien.
Funcionaría?
Habría que escribir mucho código, pero el día que viene el diseñador gráfico superfeliz con un quinto
enemigo, me ha jodido entero porque volver a programarlo.
Entonces, siempre que las variables no vayan de una en una, sino que sean colecciones de cosas.
Esto es una colección de enemigos 4, 5 o 29, pues nunca utilizaremos una estructura que sea variable.
Variable.
Variable variable.
Utilizaremos variable corchetes y esto querrá decir colecciónde array.
De entonces ya no tendremos 4 variables, una para cada enemigo.
Tendrá una variable que será enemigos y enemigos.
El artista, el diseñador, quien sea, va a poder añadir 1, 2, 27 o ninguno, los que quieran.
Pero básicamente esto es.
Era más básica que existe, que es el rey.
Si os habéis hecho el cursillo de César, recordad recordad que había reyes, había listas, viajás
mapas, diccionarios.
Lo más importante a recordar es que el rey, una vez creado, es de ese tamaño y no puede ni crecer
ni decrecer.
Es de tamaño fijo.
Esto quiere decir que si ya tenéis pensado que en una partida va a haber 20 enemigos, esta estructura
es perfecta porque ni el número de enemigos diferentes va a crecer ni va a decrecer.
Sin embargo, si pudiera cambiar dinámicamente, si se pudiera añadir un nuevo enemigo de.
Porque sí, porque me da la gana, en lugar de utilizar una raíz como estoy haciendo aquí, utilizaríamos
una lista la sintaxis de la lista.
Luego ya aparecerá la palabra y entre en castellano se llaman diamantes.
En inglés se llaman whiskers bigotes.
Entre los dos símbolos indicar el tipo de dato.
Esto para las listas, que de momento no las vamos a usar para Harrys, que es el caso que me ocupa,
sería públic.
El tipo de dato que vais a guardar en este caso son Guillemot, Gex, colecciones de Game Objects dentro
de eninglés.
Si lo haceis así guardáis cuando vais al editor de Unity.
Vais a ver que este es Pacman ayer que está por aquí.
Si le arrastro ni escribe, le aparece aquí un campo que pone enemigos seis cero.
Lo veis aquí?
Lo primero que tenéis que tener en cuenta es que como el tamaño viene fijado a priori en una Ray, le
tenéis que decir cuántos queréis.
Aquí estaréis tentados ahora a hacer esto.
Quiero cuatro.
Aparecerían estas cuatro cajitas, pero veis que si ahora quiero una quinta es tan fácil como venir
aquí, poner cinco y si quiero 20 es tan fácil como poner 20.
Ya no tengo que crear tantas variables a mano como hubiera ocurrido con el enfoque anterior.
Aquí lo chulo, de todas formas, no es esto, sino que siempre estáis con una raíz de cero como éste
que tengo aquí.
Yo qué quiero hacer?
Al final quiero arrastrar mis enemigos.
Pues sería tan fácil como venirme a los prepas donde están mis enemigos, mis animales, y fijaros en
esto sin crear ninguno.
Selecciona uno y lo arrastro aquí, donde pone enemigos.
Automáticamente se me añade uno más.
Añado el siguiente, añado el siguiente y añado el siguiente, incluso más allá.
Queréis que uno de estos sea más probable que los otros arrastrarlo dos veces?
Creéis que aleatoriamente salgan más perros, que más vacas arrastran más perros?
Ves que estoy repitiendo el perro tres veces.
Eso significa que el perro tendrá tres opciones o tres veces más de posibilidad de aparecer en pantalla
que los otros animales.
Vale, me cargaba algo.
La beta me ha petado.
Han desaparecido los textos.
Esto normal es una beta.
Vale.
Pues fijaros.
Qué fácil es crear una colección de objetos en general, siempre que necesitéis no un objeto, sino
dos, tres, cuatro indefinido, listas o arrays o diccionarios, incluso Rojas-Marcos.
Hay otros tipos de colecciones y están las pilas, están las colas, los árboles, los árboles binarios.
Hay un montón de estructuras de datos que se pueden utilizar y que son más o menos útiles dependiendo
de la tarea que vayas a resolver, pero la gran mayoría de ellas se acaban reduciendo a estas tres listas
diccionarios y arrays.
A ver, se sigue haciendo un include para utilizar listas y arrays.
Lo que pasa es que todos los scripts la traen de serie.
Existen colecciones y existen collection generic.
Entonces, si yo ahora Attic utilizar a un listilla entre diamantes, utilizar Object, fíjate que se
me acaba de iluminar de color lila systems.
Colección Generic.
Hoy en día todos los escrit la traen incluida de serie.
Vale.
Ahora que quite el Liseth y lo deje con Arráiz vuelve a estar en gris.
No me hace falta, pero es que era tan, tan, tan, tan, tan común que ahora, ya por defecto, cualquier
escrit que se crea automáticamente trae el Collection.
Si el Collection Generic, que sirve tanto para listas como para cualquier tipo de programación genérica
basada en colecciones, se vale, pues tenemos este rey de enemigos y de hecho casi, casi después vosotros
podréis adaptar algo así para el disparo.
El disparo ahora dispara una pieza de pizza o de lo que hayáis arrastrado.
Imaginaros que cada vez quisiera tirar una cosa diferente.
El enfoque sería el mismo una colección en lugar de.
Está el Player Controller, en lugar de tener un solo proyectil lo.
Podríamos tener una colección de proyectiles, tener 7, 8 o 10 apps diferentes y que cada vez al lanzar
lanzaremos uno u otro aleatoriamente o porque habéis recogido cinco pizzas y tres manzanas, lo que
fuera, pero veis que la idea es exactamente la misma que en una colección, en una ray o en una lista
se pueden añadir todas las cosas que queráis.
Simplemente arrastrar aquí uno tras otro.
Lo veis?
Vais arrastrando, vais arrastrando y aquí aparecerían todos y cada uno de ellos.
Yo, en mi caso, lo voy a dejar en 4.
Uno de cada tipo.
Pero ya os digo, si queréis que sea más frecuente ver uno u otro y no os queréis complicar con una
estructura demasiado complicada, añadir el bicho que queréis que salga más veces.
Un par de veces y así es más probable elegir una posición donde salga este enemigo que una donde sale
una menos veces.
Esto también ayuda a lo que es el manejo de la dificultad del videojuego.
Si, por ejemplo, la vaca es más lenta, luego viene al alza.
Luego viene el ciervo, luego viene el perro.
Si cada uno de ellos es más rápido que el anterior, pues a lo mejor os interesa tener muchas vacas
que son lentas, menos alces, menos ciervos y uno o dos perros, porque sabéis que a la que salga un
perro irak. carísimo.
Entonces, si vosotros jugáis con el campo de la velocidad, recordad que lo tenéis porque hemos puesto
aquí el forward.
Si ya sabéis que unos van a ser más rápidos que otros en términos de.
Aquí podéis balancear qué tan probable es que aparezca un animal u otro arrastrándolos más o menos veces
y siendo conscientes de cuál es más rápido, que os voy dando ideas para que veáis que al final el incremento
de la dificultad no es programar más, no es tener más líneas de código, es tener ideas.
Vale para que veáis que al final todo lo que cae dentro del campo del 26 en general no tiene porqué
saber programar, no tiene por qué saber de mecánicas de videojuegos y ser capaz de establecer este
tipo de comportamientos.