I’ve been using the fallowing enum for quite some time:
public static enum Scene { Menu, Options, Map, Treasure, Battle, Pause, SetupBattle, FinishBattle, Exp, Died };
The enum is used to determine what to draw and update.
As i’m adding more and more I’m finding this solution to become quite bloated and hard to navigate. I was wondering how other people have gone about changing scenes.
Also, Hello JGO 
You could have different enums for different events.
for example, enums for the battle scenes
enums for the menus
enums for the maps
etc etc
then you just need to check which enum is active.
not sure if its a great solution, but it may be achievable
That’s what I’m using right now. (I should have clarified that).
It works great when there isn’t much to change between. But adding more and more scenes it’s become way to bloated and a pain to go through. I was wondering if anyone had a different approach to this.
Bad advice, Scyth
Read on how LibGDX uses Screen classes and a central Game class:
https://code.google.com/p/libgdx-users/wiki/ScreenAndGameClasses
You have a central game class that has methods “getScreen()” and “setScreen(Screen screeen)”.
You create different screen classes which implement Screen
You have you central rendering thread get the current screen using getScreen() and it draws and updates the screen.
Please don’t target the person, vbrain :point:
Ok, Riven. I just needed to get the point across.
I found that libGDX while googling around looking for a solution. The only real issue I have with it is that I’m trying to stray away (for now) from using outside libraries. This “game” I’m making is more of a learning experience than anything else.
Or perhaps I’ll learn how to use a library and stop being intimidated of them.
Thanks for the link, I’ll definitely check it out
I wasn’t telling you to use libgdx. I said you should read their documentation and see how they use screens. Then you can easily make your own.
Instead of using an enum, did you ever consider just using an ArrayList (or List) to register your screens?
Just give each screen an ID (similar to you enum ID). It should be a lot less messy and you should be able to handle many screens at once.
Sometimes I use delegates to implement the painting. Then I just set the right painter delegate to the display panel.
Sometimes I’ve been using the CardLayout.
Sometimes I’ve been just replacing JPanels (remove old + add new ) with different content.
And I’ve been using flags like you … all of them worked well in the right situation.
No one else better known has jumped in and said it, so I will! :emo:
We program in an OOP Language (JAVA) if you don’t understand what OOP means, look it up (then do some serious thinking about your choice in hobby / career) We have these great things called Classes, and they allow up to group similar data and methods into a logical structure. The answer for hard to navigate, bloated, and confusing code is almost always going to be; “Lets make another class!” /rant
For your particular scenario, I would recommend making a abstract class / interface (depends on mood this time :)) which is a state. I am assuming you have an update method and a render method somewhere in your big, giant, monolithic, dresser drawer of a main class. So instead of all your logic and all your rendering for the whole entire game being stuffed into these two (I hope they are separate) methods, simply have these call the current states update and render methods. When you transition from Battle to FinishBattle, simply swap out the current state.
I could take another five minuets adding code examples, but honestly I believe in your intelligence, and would hate to insult you by giving you what you can already figure out. If this is not the case simply ask 
BTW: Laugh with my words, and don’t take offense. I am trying to help in the cheekiest way I know how.
That’s what I was getting at with my post.
An approach that I like (I think Cas mentioned it at some point) is to use a Stack of Scenes. The idea is to add a Scene to the stack if it needs to be activated, and remove it once it needs to be deactivated. Then you should only update and render the topmost scene in the stack.
For this you may need to define your own Scene base class or interface, and create specific classes for scenes using inheritance (for classes) or by implementing the interface. A Scene interface could be something like:
public interface IScene {
// Initialize things needed for this scene, e.g. load assets. Called when the scene is added to the Stack.
public void initialize();
// Update the scene. Only called on the topmost scene in the Stack.
public void update(float delta);
// Render the scene. Only called on the topmost scene in the Stack.
public void render();
// Dispose of assets etc. that need to be disposed. Called when the scene is removed from the Stack.
public void dispose();
}
Then implement a MenuScene, an OptionsScene, a MapScene, a BattleScene, etc…
Wow, thank you everyone for your comments. You guys are amazing :o
I’m going to try out a few of this suggestions (specifically zngga and grunnt), and thanks again for all the help :x