Después de esa explicación que os he hecho de Scene2D vamos a ver cómo crear el Stage. Antes, ya que vamos a crear el juego en directo, más o menos,
enseñando como lo hago para que aprendáis, vamos a introducir un cambio que va a ser beneficioso para todos. Os hablé antes del ApplicationAdapter
y os conté que había unos métodos que se ejecutan en algún momento, pero a lo mejor alguien nota que falta algo, y es que cuando tienes un ApplicationAdapter,
en el momento que abres el juego empieza a desplegarse el método render y se dibuja una cosa. Pero si miramos los principales juegos que existen o
juegos de móviles normalmente tú no abres el juego y te lanza la pantalla del juego. Hay pantallas especiales, de bienvenida, o con botones que dicen “Jugar”.
Eso es porque esos juegos usan múltiples pantallas, y nosotros como vamos a querer meter en nuestro juego al menos una pantalla de bienvenida para que
no se asuste cuando abra el juego vamos a hacer algo parecido, y para ello libGDX integra una clase parecida a ApplicationAdapter porque al fin y al cabo
extiende pero que nos va a ayudar a hacer juegos de múltiples pantallas, y es Game. Afortunadamente Game es una clase que como digo extiende
de ApplicationAdapter, así que no debo introducir ningún cambio, aunque Game introduce un método interesante llamado setScreen. Con este método podemos dibujar
en pantalla una Pantalla, Screen. Nosotros lo que vamos a hacer es utilizar un Game, y luego introducir cada una de las pantallas en objetos de
tipo Screen que vamos a crear. De vez en cuando le pediremos al método setScreen de la clase Game que ponga en pantalla una Screen u otra.
La única particularidad es, que cada una de las pantallas, como la de opciones o la principal, debe ir en un Screen. Y luego de alguna conexión
nosotros simplemente le decimos que ponga una pantalla u otra. Vamos a ver como crear nuestra pantalla, y voy a crear una pantalla llamada MiPantalla,
que va a implementar a Screen. En el momento que hago que implemente Screen me va a obligar a escribir una serie de métodos que no hace falta que os enseñe
mucho porque son los que habéis visto cuando hablé de ApplicationAdapter: resize, render, resume, hide, dispose… lo único que hace Game es…
de hecho os lo voy a enseñar, es un ApplicationListener en el que las llamadas a dispose, pause se delegan a la pantalla que en ese momento se esté representando,
lo cual está bastante bien porque es muy natural y así lo tenemos conocido. La única diferencia es, que render sí que acepta un parámetro llamado delta mientras
que en el ApplicationAdapter no lo aceptaba, y este parámetro lo utilizamos porque cuando estamos haciendo juegos nos interesa que las cosas se animen
o las cosas se muevan, y a veces es necesario conocer cuánto tiempo pasó desde la última vez que se llamó a render. Por ejemplo, han pasado 25 milisegundos
desde la última vez que se redibujó la pantalla. Para que el personaje se mueva a velocidad constante tendré que hacer un cálculo para que avance 20-30 píxeles
y parezca que se está moviendo bien. Normlamente usamos esto para hacer intervalos de tiempo, y veremos que los pinchos cuando los introducimos van a depender
mucho del delta. La otra diferencia, sin duda, es la existencia de un método llamado show y un método llamado hide. Cada vez que se cambie de pantalla,
en la pantalla que se muestra, se llama al método show para que pueda cargar lo suyo, y la pantalla que se deja de mostrar se le llama a hide para que se de
cuenta que ya no es visible y pueda detener el sonido o pueda liberar algo de recursos o cualquier otra cosa. Así que, a partir de ahora utilizaremos esta pantalla,
pero como veis, no existe ningún tipo de conexión entre la pantalla y el juego. Un patrón que suele hacerse cuando hacemos juegos, al menos en libGDX,
es de alguna forma conectar cada una de las pantallas con el juego principal, porque a veces tenemos recursos comunes que necesitan estar bajo control
en todo momento, como algún sistema de audio o el sistema de anuncios si vamos a mostrar anuncios en nuestro juego. Como son cosas complejas de instanciar
porque consumen recursos, normalmente los instanciamos una única vez en el juego principal, porque para eso es el juego principal y la clase principal.
Pero necesitamos alguna forma de que las pantallas conozcan estos campos, así que el patrón más común que se suele utilizar cuando hacemos juegos multipantalla
es conectar la clase Principal con la pantalla Base, por ejemplo mediante un constructor que acepte un MainGame como parámetro y que se guarde como un campo,
porque de este modo ahora puedo hacer un montón de cosas: game.setScreen para cambiar de pantalla, y si tuviese algún campo como un gestor de texturas
podría acceder a ese gestor, así que nos viene bien tenerlo así. De hecho otro patrón bastante común es que esta clase, siempre sea la clase raíz, es decir,
que como esto es muy aburrido tener que implementar tantos métodos que a veces no vamos a usar, lo que se suele hacer es declarar esta clase abstracta y
hacer que a partir de ahora cada pantalla que queramos hacer de verdad, como la de bienvenida, lo que haga es extender a esta pantalla base que la podría
renombrar por BaseScreen, para indicar que es la pantalla raíz de la que todo sale, de modo que cada una de las pantallas ya tenga acceso al MainGame,
si lo cambio por un protected, sin necesidad de reescribir este código una u otra vez, cosa que nos va a venir muy bien.
