LIBGDX para Android – Tutorial 14 – Multiples Pantallas – How to make games Android

September 26, 2019

After that explanation that I have made Scene2D we will see how to create the Stage. Before, as we create the game live, more or less, teaching as I do for you to learn, we will introduce a change that will be beneficial for everyone. I spoke before ApplicationAdapter and I told him that there were some methods that run at some point, but maybe someone notices something is missing, and that is that when you have a ApplicationAdapter, when you open the game begins to unfold the render method and one thing is drawn. But if we look at the main games that exist or mobile games normally you do not open the game and throws you the game screen. There are special screens, welcome, or buttons that say “Play”. That’s because these games use multiple screens, and we as we want to get into our game at least a welcome screen for do not panic when you open the game we will do something similar, and it integrates libgdx a similar class ApplicationAdapter because after all extends but we will help make multi-screen games, and Game. Fortunately Game is a class that extends as I say of ApplicationAdapter, so I have no change, although Game introduces an interesting method called setScreen. With this method we can draw display a screen, Screen. What we will do is use a Game, and then enter each of the screens in objects Screen type that we create. Occasionally we will ask the setScreen method of the Game class to put on the screen one Screen or another. The only peculiarity is that each of the screens, such as options or the principal, should go on a Screen. And after some connection we just tell him to put a screen or another. Let’s see how to create our screen, and I’ll create a screen called MyScreen, that you are deploying to Screen. At the time I do that implements Screen will force me to write a series of methods that do not need to teach you much because they have seen that when I spoke of ApplicationAdapter: resize, render, resume, hide, dispose … all it does is … Game in fact you I will teach, it is a ApplicationListener in which calls to dispose, pause delegated to the screen at that moment is representing, which is pretty good because it is so natural and so we met. The only difference is, itself render that accepts a parameter called delta while in the ApplicationAdapter not accept it, and this parameter is used because when games are doing things we want to encourage them or things moving, and sometimes you need to know how much time passed since the last time it was called to render. For example, they have spent 25 milliseconds since the last time the screen is redrawn. To make the character move at constant speed I have to do a calculation to advance 20 to 30 pixels and it appears that is moving well. Normlamente use this to make time intervals, and see that the spikes when we introduce will depend much of the delta. The other difference, of course, is the existence of a method called a method called show and hide. Each time you change screens, on the screen shown, you call the show method so you can load its own, and the screen stops showing is called to hide to be of that is no longer visible and can stop the sound or you can free up some resources or anything else. So, from now on we will use this screen, but as you see, there is no connection between the screen and the game. A pattern that is usually done when we play, at least in libgdx, is somehow connect each of the screens with the main game, because sometimes we have common resources they need to be under control at all times, as any audio system or ad system if we are to display ads on our game. As things are complex to instantiate because they consume resources, normally we instantiate only once in the main game, because that is the main game and the main class. But we need some form of screens aware of these fields, so the most common pattern that is often used when we multiscreen games Main class is to connect with the Base screen, for example using a constructor that accepts a MainGame as a parameter and is saved as a field, because this way I can now do a lot of things: game.setScreen to change the screen, and if I have a field as a texture manager You could access the manager, so we have it so good comes. In fact another common pattern is that this class is always the root class, ie, that as this is very tedious to have to implement many methods that sometimes we will not use, which is usually done it is to declare this abstract class and make from now on each screen that really want to do, such as welcome, whatever it is to extend to this base screen that could rename by BaseScreen to indicate that is the root screen everything out, so that each of the screens already have access to MainGame, if I change for protected without the need to rewrite this code one time or another, which we will come in handy.

Leave a Reply

Your email address will not be published. Required fields are marked *