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

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.

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.

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.

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.

Problems will arise when You will want to use more than one state. For example having game running in background while user being in main menu might require 2 states - one GAME and second MENU.

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.

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.

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.

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

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.

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!

Personally I like to use a Stack of Screens (a game screen is much like a game state). The top-most screen on the stack is updated and rendered. So the contents of the Stack when the game has been started from the main menu, while the options screen is open would then be:

MainMenuScreen -> GameScreen -> OptionsScreen

With OptionsScreen being rendered and updated, and GameScreen and MainMenuScreen being inactive (they will become active when the screen on top of them gets popped off the stack).

What I do is similar but a bit more elaborated (no offence guys), one state is active at a time, I don't directly go from the main menu state (mm) to the game state (g) because I need a dedicated state to show something to the player while loading the level (ld). I use a switch node and each state has a node which is a child node of this switch node. That way, when the current state is active, it is the only one that gets updated and rendered but a state can be used to prepare another one. I use a task manager too.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org