Como veis ya he puesto el código a pantalla completa porque se acabaron las introducciones. Es hora de empezar a programar en serio.
Como ves el código está vacío, porque lo he eliminado antes de darle a grabar, porque soy listo a veces. Borra igualmente el código de ejemplo
porque nosotros vamos a hacer uno mucho mejor, ya verás. Antes que nada, me voy a detener en ApplicationAdapter y por qué MainGame debe extender a
ApplicationAdapter. Eso es porque como viste al hacer el proyecto para Android, escritorio, lo que sea, tienes una serie de lanzadores ya creadores,
el de escritorio o el de Android, que parece que ya hacen el trabajo por nosotros. Realmente la aplicación que nosotros hacemos no es nuestra.
La aplicación es de libGDX. Nosotros lo que hacemos es escribir por encima el código, pero quien prepara el sistema de audio, el sistema de vídeo,
el sistema de entrada, es libGDX y por lo tanto es realmente libGDX quien por debajo pilota la aplicación. Nosotros lo que hacemos por conveniencia
es darle el control de la aplicación a cambio de que se le pueda pasar en el constructor de la aplicación, por ejemplo cuando creemos
la aplicación de escritorio o cuando creamos la aplicación en teléfonos móviles, nuestro MainGame. Y el MainGame lo que realmente es una clase
de tipo Application: ApplicationAdapter o ApplicationListener. La conveniencia está en que a cambio de darle a libGDX el control de la aplicación,
libGDX asegura que llamará a una serie de métodos que tenemos en el juego, en momentos oportunos. Este es el código de ApplicationAdapter,
y estos son los 6 métodos: create, resize, render, pause, resume y dispose. No me voy a detener a mostrar cómo funcionan todos los métodos
porque me parece un poco bestia. De momento te voy a explicar los dos más importantes que voy a usar a partir del siguiente vídeo para cargar imágenes,
y luego a medida que se vayan usando, por qué no, vamos a ver qué hace cada uno de ellos. El primer método que me parece importante es el método create.
El método create, que es el método que va a ejecutar libGDX por nosotros automáticamente cuando haya terminado de preparar todos esos sistemas
de los que te hablaba. Es aquí donde tendríamos que cargar imágenes, sonidos, recursos... en fin, preparar el juego para hacerlo presentable.
Y aquí alguien dirá 'jo, Dani, ya tenemos una cosa llamada constructor, no sé si lo recuerdas'. Es peligroso meter código crítico, como el de carga de imágenes
o el de carga de archivos en el constructor porque a lo mejor libGDX todavía no tiene preparados esos sistemas, como el sistema de carga de archivos,
porque al final depende de una plataforma u otra el cómo puedes cargar archivos. Piensa en un navegador web, no puede cargar archivos tan fácilmente.
O en teléfonos móviles se hace distinto según si son Android o iOS. O en escritorio puedes tener acceso a más archivos de los que puedes tener en móvil.
Ese tipo de cosas, como libGDX las tiene que estudiar por separado es más peligroso hacerlo si lo haces antes de que libGDX sepa cómo se hace.
En el constructor únicamente iniciaremos ArrayLists, HashMaps, clases básicas de Java pero nada que sea crítico debe estar en el constructor,
eso debe estar en el create. Aquí cargaremos cosas en el siguiente episodio o lo que haya que cargar más adelante. El segundo método
más importante es el render. El método render es importante porque es el que utilizamos para representar la aplicación o para actualizar el estado del juego.
libGDX lo que asegura es que va a ejecutar el método render aproximadamente 30 o 60 veces cada segundo, dependiendo de la velocidad que tenga el dispositivo.
Por medio de ese método mostraremos imágenes por pantalla, si tiene que actualizar el estado del juego, como actualizar la posición de un personaje
para que parezca que se mueve de forma lineal. Este es el método que usamos para representar ese tipo de cosas. Cuando carguemos las imágenes lo usaremos
para renderizar todo lo que hemos cargado. Pero antes, vamos a centrarnos en cómo cargar esas imágenes.
