Is using Game in libGDX for more than just switching screens a bad practice?

Question

I'm the process of refactoring the prototype of my game to use multiple screens using the Game - Screens model. I found some information (I think in more than one place) that the Game class should be used only to switch screens. I've checked some libGDX demos and they indeed follow that pattern.

Initially I wanted to do it the same way, but then I found more and more problems with this approach. AssetManager is the best example I think. Since there is only one instance of it and I would like to use it in more than on screen why not use the Game object to store it? Same thing with Viewport for example or Camera, if I'm happy with just one. What about single instances of my own classes, that I need throughout the whole game, why not to use Game for that?

I know that there are different ways to achieve what I wrote above. I can use static methods like here or create my own class to store all the needed objects and pass its instance between screens, but since I'm already passing instance of Game, what's the point?

To summarize: is using Game to anything else than to switch screens a bad practice? If so, why?

Answer 1

Idea behind screens, is to separate logic between different context. However, those screens can still share data and have references to some classes that were originally initialized at original game class. If you don't use screens, you will have to dump all the code to main game class. Even if you try to hide logic behind different classes, you still end up having pile of mess.

Example: You could separate levels of your game to own screens. When starting new level, you could pass gameManager or whatever class to it. Then, when the level is done, you can just remove the screen and let the garbage collector handle the rest.

Example2: You could have GUI screen, that handles drawing GUI. That screen does indeed need THE reference to games engine or logic unit, so it can draw game related stuff.

So, it's perfectly fine to share data between screens and pass data to new screens.

EDIT: i just Re-read you question. If you use game class like that, i don't see it really violating anything. Just try to separate contextually different stuff. Game class is just a class, treat it like that and don't clutter it with everything. Design nice screen loader and just put all the levels in collection, like list or stack. Make screen set it's state to "IsFinished = true" and check for that and remove it from collection and from game and let the next screen start and get the update, input and draw.

Answer 2

You can use Game for everything you like. Game is just class that implements ApplicationListener and supports screen switching, nothing more. So design you code as you wish. Just be sure that your Game class doesn't become dump.