In my past games I handled game states by having a million booleans everywhere, and I eventually got tired of the logic issues with doing this.
What’s the best way to handle game states?
Pack states together in a enum?
It’s best to use enums.
public enum GameState
{
MENU, INTRO, PLAY, END
}
This defines the enum [icode]GameState[/icode] which defines different states of the game. Then there should be a static variable of it in the main game class.
private static GameState gameState = GameState.MENU;
public static GameState getState()
{
return gameState;
}
public static void setState(GameState state)
{
gameState = state;
}
This ensures that you have only one variable and everywhere you need to check the state,
switch (Game.getState())
{
case MENU:
// In menu screen
break;
...
}
This way, you can use enums effectively. I’ve used the switch statement in example but you can use if statements as well.
State Design Pattern
I hate to be “that guy” but it actually works out pretty well. I know a lot of games use it throughout their UI and game. It’s better than a huge branch of switch\if-elseif-elseif that needs to be changed whenever you have a new state.
I did not understand you, why do you hate to be “that guy”, what do you mean ? What’s so bad about “State Design Pattern” ?
If you don’t like text tutorials, you can watch as well design pattern video tutorials on Derek Banas youtube channel. Here’s the tutorial link to “State Design Pattern” http://www.youtube.com/watch?v=MGEx35FjBuo
Every single time I bring up design pattern here someone starts an argument with me. It seems to be controversial to suggest design patterns here for some reason.
That’s what I thought about…
I like states. I do everything with states. I use a combination of enums and the state pattern. Rather than have a bunch of actual classes (one for each state), I just make them all enums. Enums can also implement an interface, so they are just as viable, and it really cuts down on the number of of separate classes you need.
Something I’m trying out now is having state managers. These are like my main states, and within each have a bunch of substates, which are the actual ones the game sees. So for my game, I’ll have the menu state, the in game state, and the inventory state. Within the menu state I have new game state, continue state, options state, etc. The main purpose of this for me is to easily switch input schemes between the different states I have. Like, the controls aren’t the same while playing the game as when you are navigating menus. And it also logically separates my states, so I don’t have like 50 defined states in one class.
Hehe. OK…I’ll bite. Comparison and contrast: Why focus on the single solution of “State pattern” instead of “Design by composition” which is a superset thereof? If you can do the latter then the former is obvious but not in the opposite direction. No need to respond…this is a thought exercise.
He’s asking about game states, not object states. A game is only ever in one state. Even if you have the game in the background with a menu overlay. That’s not 2 states. That’s its own state.
Honestly, an object is also only ever in one state of a given state machine. That’s how states work. You can, however, have multiple state machines to dictate a single object. Though, they shouldn’t really have any interaction with each other.
It’s not really a problem. I use a state machine and you can put different operations into your transitions so that you don’t do the same thing when going from the game to the in-game menu and when going from the game to the main menu. I use a state machine with the Fettle API and Ardor3D, I’m very satisfied by the result, I never need to “be” in several states at the same time, I release some resources when I really leave the current game, not when I make a pause. I use about 10 states.
Thank you all for your responses. ;D
I’ll probably go with SHC’s method, I really do need to use enums more often.
- Jev.
No programming technique should be used just because “it needs to be used more often”. They all have their place. That’s why design patterns are so controversial.
Anyway. Enums can be used with the state pattern. If you really want to use enums, you should still look into the pattern. No offense to SHC, but a switch statement is just another way to write a bunch of if cases. The state pattern is a lot more organized. Besides, with his method, the enums are no more useful that some constant integers, so, you aren’t really practicing anything useful that way.
Let’s not go overboard. If the number of things is small (which the definition of small is context dependent) then using a switch statement is the least work, easiest for other to understand and easiest to maintain solution.
What do you mean my no more useful? I don’t understand that.
Constant integers don’t nearly provide as much functionality as enums. First of all, with enums you can store much more information in one entry - just add more parameters. Second, it improves readability - it may not be immediately clear what a class with a bunch of statics is for. With an enum it’s immediately clear that some sort of state- or type- based system is in effect.
[quote]Besides, with his method, the enums are no more useful that some constant integers
[/quote]
That first part was very important. In his example, he’s doing nothing but defining enums. He’s using no functionality of them that you couldn’t do with constants.
Who’s method? :persecutioncomplex:
It’s like 5 posts up…I’d quote it, but it won’t let me.
I use different ‘Scenes’ managed by a ‘Theater’ like this:
public interface Scene
{
public String getName();
public void init();
public void enter();
public void input();
public void update();
public void render();
public void leave();
public void dispose();
}
public class Theater
{
private HashMap<String, Scene> map = new HashMap<String, Scene>();
private Scene current = null;
public void addScene(Scene s)
{
map.put(s.getName(), s);
s.init();
if(current == null)
{
s.enter();
current = s;
}
}
public void enterScene(String name)
{
Scene s = map.get(name);
if(s == null)
return;
current.leave();
s.enter();
current = s;
}
public Scene getCurrentScene()
{
return current;
{
}
public class Game
{
private Theater t = new Theater();
public Game()
{
t.addScene(new MenuScene());
t.addScene(new GameScene());
t.addScene(new CreditScene());
}
public void input()
{
t.getCurrentScene().input();
{
public void update()
{
t.getCurrentScene().update();
{
public void render()
{
t.getCurrentScene().render();
{
}
Not saying it is the best way, but I like keeping everything pertaining to one aspect of the game, like a Main Menu, separate from other parts of the game. Then I just have a new implementation of the Scene interface for different parts, like a menu, game, win/loose screen, and credits. I don’t like how messy the Switch case, or nested if-if else statements look, and that method tends to make one giant hard to read, harder to troubleshoot class. This way, if I want to add something to my menu I know just where to find it. Not saying its the best way, just the Znnga way! 8)