I have been using LibGDX for while now and stages are pretty interesting (at least on my mind).
But I haven't seen any real guide how to use stages like pro.
Now my current project has MainMenuScreen, MainMenuStage,GameScreen, GameStage classes and many more coming.
I have already encountered problems with setting input because of my multi-stage-screen-system. So it would be nice to know if there is any better way to implement screens+stages.
There are multiple topics about using many stages at the same time on screen but I haven't seen any thing for other side.
So is it necessary to use Screen and Stage class for every screen in game ? Or is there even better way than screen + stage class to display menus and general stuff?
TD;DR: Should I use multiple screen and stage classes in game?
P.S. Thanks in advance and sorry if there is spelling mistakes.
I have not used LibGDX but I have had to deal with the same scenario and delt with it different ways. I found that what works well for me is putting common fields and methods in parent Stages or Screens and then make child Screens and Stages to put fields and methods that are unique to those classes.
For example in a particular application I have a class called AppScreen. All my screens inherit from it. I also have another class called PagableScreen which also inherits AppScreen, and I have a few classes that inherit from PagableScreen. This allows me to put all fields and methods that pertain to PagableScreen sit in one place and do not need to be re-implemented across other classes that require pagable capabilities.
An oppossing design is to use the Decorator pattern, which actually works quite well but can get messy if the problem space is not big enough to warrant it. With Decorator you create specific features and attributes as add-on classes to particular Screen/Stage, e.g. Decoration classes. So taking the PagableScreen as an example, I would instead have PagableDecoration, which any screens that require pagable capabilities would decorate themselves with. This is actual works well in situations where there might be some other decorations you might want to add on. For example lets say you also have a MenuDecoration which gives a Screen some capabilities for doing a menu screen and now require both Pagable and Menu capabilities. With the Decorator pattern you can get both in one class, where as with pure inheritence you can only be either PagableScreen or MenuScreen.
But ultimately I do agree that there will be a GameScreen and GameStage and MenuScreen and MenuStage and so forth and so on. The goal is to make them elegent and possibly small if much of their implementation can be put into a parent class or a decoration.