Bueno, hasta ahora ya tenemos dos ingredientes claros de nuestro juego uno es el jugador, otros en
el enemigo.
El enemigo ya puede perseguir al jugador alrededor de la isla, lo que pasa es que hay un problema.
Habéis probado de echar al enemigo?
Cuesta.
Cuesta mucho, hasta el punto que es una batalla casi perdida, es decir, tengo que pasarme el rato
esquivando y ahora hay un enemigo.
Imagina cuando el método que hemos creado antes lo llamemos 10 veces, será casi imposible.
Necesitamos alguna forma de defendernos y de hecho esto es algo que me hace mucha gracia porque es algo
que constantemente nos gustan las historias, la mitología y demás.
Los mitos griegos ya hacían los mitos griegos presentan un héroe, tienen que presentar su villano y
siempre la historia pasa porque el héroe necesita encontrar algo para matar al villano, ya sea un arma,
ya sea el vellocino de oro, ya sea vete a saber tú que, pero siempre es algo que se ha utilizado desde
las historias clásicas griegas y romanas.
Luego se recuperó en la Edad Media.
Hoy en día lo tenemos en el cine.
Siempre se presenta al bueno, el malo.
Hay una trama que desencadena todo lo demás.
El teatro lo hace así.
Los videojuegos lo hacen así.
Es el famoso, la famosa estructura en tres actos la presentación, la trama y el desenlace.
Entonces nosotros tenemos la presentación.
La trama va a ser que ocurra el gameplay de algún modo.
En nuestro caso habrá que dar armas a nuestro jugador, porque si no es un juego perdido, ya de buenas
a primeras las armas van a ser en forma de crear palabras que me den alguna fuerza temporal para poder
cargarme al enemigo.
Cómo esto llevaría a una finalización prematura del gameplay?
Evidentemente tendré que incrementar el número de enemigos.
Tendré que hacer oleadas de enemigos para así tener servidos los ingredientes del gameplay y la trama.
Enemigos que irán apareciendo, apps que miran dando la posibilidad de cargarme a los enemigos.
El balance entre estas dos cosas me dará un gameplay más o menos justo o un juego más o menos difícil.
Y la variedad, tanto en los povera como en los enemigos, me va a dar la posibilidad de tener escenarios
totalmente diferentes.
De hecho, vosotros ponéis enemigos con unas propiedades u otras, con unas propiedades u otras.
Cambiáis el timming de cada cuánto aparece, cada cuánto aparece un enemigo?
Qué tan fuertes son?
Vuestro juego será diferente al mío, a pesar de tener los mismos escenarios, los mismos personajes
y los mismos enemigos.
Así que el hará que me va a dar alguna energía adicional de forma temporal para cargarme a los enemigos.
Ya veremos de qué forma.
Además, puede ser muy diferente, puede ser más fuerza de la bola.
Puede ser rollo bomba que mi personaje haga una fuerza, que todo el mundo dentro de cierta distancia
salga disparado.
El efecto bomba típico va a dar lugar a resultados diferentes.
Qué diferencia hay entre escanear un enemigo y escanear un power up ningúna?
Un enemigo y un power up es lo mismo songhai, mob, gex que son escaneados.
La diferencia está en el comportamiento, por eso el enemigo tiene un script de enemy scrip y el pavura
obtendrá un escritor pafuera pago prescripto.
Vale, cada uno de ellos se va a comportar diferente de forma diferente.
Evidentemente necesitaremos indicar de algún modo que es un povera, estilizar con alguno de los assets
que hay en el juego.
Como aquí sólo hay texturas, pues tendremos que jugar otra vez con cuadrados, esferas y demás.
Pero aquí no va a permitir añadir un concepto nuevo que todavía no he utilizado y que, de hecho, no
sé por qué no lo he usado todavía, porque yo soy bastante fan cuando programo de utilizar esta técnica,
el pavor que va a ocurrir se va a escanear en una posición aleatoria del mapa.
Esto ya lo tenemos hecho.
Cuando el jugador colisione con el favorable aplicaremos la transformación que haya que aplicar efecto
bomba, más fuerza, hacer que el jugador desaparezca un segundo y luego vuelva a aparecer.
Tiene que durar un par de segundos.
Está claro.
Y después de ese par de segundos el efecto debe desaparecer y el jugador tiene que volver a estar en
una condición como al inicio.
De modo que la super habilidad, la superfuerza, desaparecer de pantalla, lo que sea que vayamos a
hacer solo durará un tiempo determinado.
Aquí en particular hay dos conceptos muy importantes.
Uno es el de activarlo y el otro es de mantenerlo durante un tiempo determinado, siempre que aparezcan
estos conceptos, algo que debe arrancar, mantener.
Esperar un tiempo y recuperarse.
Hay una palabra que sostiene que venir a la mente es la de rutina.
Una rutina es una cosa muy especial porque hasta ahora estáis limitados en una cosa.
Todo lo que os he enseñado a usar es dependiente del freight.
Como vaya el ataque, si vais a más y va más rápido, va menos.
Frayba menos rápido, puto.
Y si quiero que algo dure un cierto número de segundos o quiero que algo dure cierto número de frames,
creo que no quiero depender del Frend.
Quiero esperar a que algo ocurra o que algo lo desencadene, pues la rutina es el objeto perfecto,
porque una rutina es independiente del freie.
Puede esperar un tiempo determinado y de hecho, una rutina tiene una cosa súper especial que se puede
gobernar a si misma.
La rutina se puede decir oye, espera dos minutos y luego de dos minutos hace esto o segundos, por
ejemplo.
Con una rutina podemos escanear.
Parar cinco segundos es planear, parar cinco segundos es planear parar cinco segundos.
Y lo hace de forma automática.
Si lo tuviera que hacer manualmente, pues lo tendríais que hacer en el Android.
Y hay una operación que es peligrosa.
La spamear que entre nosotros es llamar al método instantáneo.
Es una operación muy pesada, muy, muy, muy pesada.
Instantly, le indica.
Y Unity o Unity busca este Pfaff generando una copia, asignarle todas las propiedades bodys, coloides,
materiales, texturas normales, lo que sea colocárselo en este sitio y colocárselo con esta rotación.
Esa operación es pesada, no es pesada si lo haceis una vez, pero si lo tienes que hacer constantemente,
cada vez que instancia instancias es un proceso pesado.
Y qué quiero decir con espesado?
Quiero decir que podría ser que los frames bajaran temporalmente, que vuestro juego corre a 60, 60,
60 o 60 frames por segundo.
Cuando instances hay un pequeño pico que os lo baja a 30 y se recupera.
De hecho, los que jugáis a juegos habitualmente muchas veces veis una bajada de frenos.
Esas bajadas de frames ocurren cuando se instancia muchas cosas.
De golpe el escenario es muy grande, hay muchos enemigos, hay un cambio en la calidad, en la iluminación,
algo que se tiene que generar y que requiere de recursos internos de la máquina que lo ejecuta ordenador,
consola, PC, móvil y que por tanto esos recursos son necesarios y se los estamos quitando a la gráfica,
a la renderización.
Entonces, cómo este proceso es pesado y podría ser que tomara más de un frame?
Podéis imaginar que el instante dentro de la data es una muy mala práctica, tanto que si yo ahora colocara
el aparato, no lo hagáis.
Os hago un bucle for y desde cero hasta 200 intento distanciar 200 enemigos.
Aquí vais a ver lo siguiente.
De hecho, no sé si lo vais a notar porque al principio vais a ver que tarda más.
Yo le doy al play.
Bueno, le doy.
Le ha costado, vale.
De hecho, para ver qué le cuesta.
Voy a hacer una cosa voy a hacer un invoquen a una función temporal.
Voy random data.
No lo hagáis.
Se
genera random data y la voy a invocar.
Después de cinco segundos para que veáis cómo el juego corre normal hasta que tengo constancia de esta
cosa.
Ni siquiera lo voy a hacer en el Android.
Voy a hacer aquí para que veáis.
Al inicio yo vengo aquí, dejo que se reconcilien.
Vale, te doy al play.
Yo me voy a poder mover cómodamente con un enemigo, así no pasa nada, no pasa nada, no pasa nada.
Hasta que pasa la propia instancia acción se toma su tiempo.
Es un Freinet o dos, o cinco o diez en el que la cosa se tiene que congelar hasta que es capaz de ir
para alante.
Esto pasa constantemente en el mundo de los videojuegos.
Disparar una bala, que aparezca un enemigo, un sonido, una animación, una cinemática.
Constantemente se tienen que crear cosas, crear cosas es comer recursos.
Si comes más recursos de los que tenéis disponible, sólo hay una forma de que esto ocurra.
Que se liberen recursos de otro lado, para que tengáis los vuestros disponibles como pasándolos.
Los Fram se pasan unos segundos y luego sigue adelante.
De hecho, yo todavía no he usado el profiler con vosotros.
El profiler es la herramienta que vamos a utilizar más adelante cuando veamos acerca de la optimización,
pero aquí si los tengo todos activos, tengo físicas desactivadas.
El Wishing desactivado?
Vale, ahora me cuadra más.
Fijaros si en un momento dado aquí os genera unos cuantos más para que sea más palpable.
Generó mil bolas de golpe.
Voy a limpiar el profiler y le vamos a echar un vistazo cuando ahora le demos al play y veamos el profiler
vengo aquí.
Aquí en el profiler vais a ver que todo corre suave.
Vale que más o menos todo está a la par.
Ves el pico durante un Humphreys?
Hemos bajado a 15 frames por segundo.
Si esto que acabo de hacer aquí es algo que va a ser constante, que va a haber ráfagas de enemigos,
o es una escopeta o una escopeta que dispara 400 balas, es lo más normal del mundo.
Significa que fijaros como mi manager, que lo tenéis aquí escrito.
Lo veis?
Es que hay barritas de color rojo.
Cada barrita de color rojo es un instante.
Ciclistas distintas, distante, distante, ha necesitado.
No veo 46 milisegundos para poder hacer todo esto.
46 milisegundos significa que en un segundo hemos bajado a 20.
Humphreys Hemos bajado 21.
Además aquí porque es sólo un freno.
Pero si esto hago un inbox, repiten que cada segundo tiene que ir haciendo cosas.
Se están haciendo cosas, se están haciendo cosas.
El resultado será que si corre el móvil en cinco minutos no tenéis batería y aparte que podréis pedir
freír un huevo aquí.
Encima le echáis un huevo y se fríe.
Claro, porque tu país de procesador se calienta porque grafica y que por otro lado, la experiencia
final del usuario será un desastre.
Así que para solventar todos estos problemas hay varias técnicas.
La primera de ellas es el uso de corruptibles.
Evidentemente, esto irá acompañado de otras cosas.
Está, por ejemplo, el uso de los pools de pulling, que es una técnica donde ya tenéis los objetos,
instancias, dos instancias antes de que arranque el juego y se reciclan constantemente, se van extrayendo
de una raíz, se ponen en pantalla y funcionan.
Y la forma preferida que ahora tiene Unity de hacer las cosas es el llamado Dots Data Oriented Textbook,
que es un paquete externo que, como ya os comenté una vez, me daría pajeros un curso entero de DOTS,
así que no lo vamos a ver.
Pero que sepáis que la forma en la que ahora Unity se jacta bastante de ser super eficiente es a través
de doubts que se obtiene en el paquete Entity.
Esta, en cambio, titís aún ni siquiera la han portado por aquí, lo han traído para.
Yo tampoco
entity a dicho.
Y porque no está?
Debería estar por aquí el paquete en Estambul.
Tiene que estar el otro medio que son los talibanes.
Debería estar en titís si es igual.
Es una forma diferente de programar donde no hay objetos, donde no hay clases, solo hay datos.
Se sale de lo que queremos ver en este curso.
Por tanto, en un momento u otro habrá que hablar de optimización.
Habrá que hablar de que no dependamos de los frenos y por tanto, la primera de las opciones es utilizar
las rutinas.
Vale, que son las que van a ser las protagonistas de aquí.
En particular, podremos hacer que se expanden enemigos constantemente gracias a una rutina que se expande
en los power ups.
Y luego habrá que programar el comportamiento de los programas que, por ejemplo, se active o se desactive
el coloide del personaje si queréis que se haga invisible o que pueda atravesar durante cierto tiempo
a los enemigos.
Si queréis que los enemigos salgan disparados fuerzas extremas, lo que sea vale.
Por tanto, esto es un poco lo que nos falta para la última parte del juego antes de acabar el efecto.