Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (526)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (593)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  What's the best way to go about game states?  (Read 2123 times)
0 Members and 1 Guest are viewing this topic.
Offline kpars

JGO Kernel


Medals: 107
Projects: 4
Exp: 4 years


Extreme Typist.


« Posted 2013-10-06 08:09:54 »

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?

Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #1 - Posted 2013-10-06 08:23:25 »

Pack states together in a enum?
Offline SHC
« Reply #2 - Posted 2013-10-06 08:29:48 »

It's best to use enums.

1  
2  
3  
4  
public enum GameState
{
    MENU, INTRO, PLAY, END
}

This defines the enum
GameState
which defines different states of the game. Then there should be a static variable of it in the main game class.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
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,

1  
2  
3  
4  
5  
6  
7  
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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeremy
« Reply #3 - Posted 2013-10-06 08:49:59 »

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.

http://www.javacodegeeks.com/2013/08/state-design-pattern-in-java-example-tutorial.html

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline nellykvist

Senior Newbie





« Reply #4 - Posted 2013-10-06 09:39:34 »

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
Offline Jeremy
« Reply #5 - Posted 2013-10-06 09:53:20 »

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.

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)

http://www.youtube.com/watch?v=rWA8bajpVXg
Offline nellykvist

Senior Newbie





« Reply #6 - Posted 2013-10-06 10:11:44 »

That's what I thought about...
Offline Troncoso

JGO Coder


Medals: 20



« Reply #7 - Posted 2013-10-06 12:44:58 »

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.
Offline Roquen
« Reply #8 - Posted 2013-10-06 13:10:57 »

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.
Offline Troncoso

JGO Coder


Medals: 20



« Reply #9 - Posted 2013-10-06 14:03:33 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gouessej
« Reply #10 - Posted 2013-10-06 14:20:06 »

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.

Offline kpars

JGO Kernel


Medals: 107
Projects: 4
Exp: 4 years


Extreme Typist.


« Reply #11 - Posted 2013-10-06 18:43:48 »

Thank you all for your responses.  Grin

I'll probably go with SHC's method, I really do need to use enums more often.

- Jev.

Offline Troncoso

JGO Coder


Medals: 20



« Reply #12 - Posted 2013-10-06 19:11:53 »

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.
Offline Roquen
« Reply #13 - Posted 2013-10-06 20:35:37 »

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.
Offline SHC
« Reply #14 - Posted 2013-10-07 03:03:56 »

the enums are no more useful that some constant integers, so, you aren't really practicing anything useful that way.

What do you mean my no more useful? I don't understand that.

Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 139
Projects: 4
Exp: 3 years



« Reply #15 - Posted 2013-10-07 03:16:58 »

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.
Offline Troncoso

JGO Coder


Medals: 20



« Reply #16 - Posted 2013-10-07 04:15:16 »

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.
Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 139
Projects: 4
Exp: 3 years



« Reply #17 - Posted 2013-10-07 04:19:10 »

Who's method? persecutioncomplex
Offline Troncoso

JGO Coder


Medals: 20



« Reply #18 - Posted 2013-10-07 04:32:31 »

It's like 5 posts up.....I'd quote it, but it won't let me.
Offline zngga
« Reply #19 - Posted 2013-10-08 19:11:18 »

I use different 'Scenes' managed by a 'Theater' like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
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();
}


1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
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;
    {
}


1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
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!  Cool

My code never has bugs... it just develops unexpected features!
Offline gouessej
« Reply #20 - Posted 2013-10-23 20:32:08 »

@gouessej
Thats actually interesting idea.
That's what I meant:


That's explained here.

Offline opiop65

JGO Kernel


Medals: 159
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #21 - Posted 2013-10-23 21:01:27 »

@Znnga thats a really nice set of classes you have there, I hope you don't mind if I steal your ideas Wink

Offline zngga
« Reply #22 - Posted 2013-10-24 00:35:28 »

@Znnga thats a really nice set of classes you have there, I hope you don't mind if I steal your ideas Wink

Absolutely! Glad to be useful.

My code never has bugs... it just develops unexpected features!
Offline Grunnt

JGO Kernel


Medals: 94
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #23 - Posted 2013-10-24 11:40:34 »

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).

Offline gouessej
« Reply #24 - Posted 2013-10-24 21:55:30 »

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.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

toopeicgaming1999 (73 views)
2014-11-26 15:22:04

toopeicgaming1999 (63 views)
2014-11-26 15:20:36

toopeicgaming1999 (15 views)
2014-11-26 15:20:08

SHC (29 views)
2014-11-25 12:00:59

SHC (27 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (27 views)
2014-11-24 19:59:16

trollwarrior1 (40 views)
2014-11-22 12:13:56

xFryIx (78 views)
2014-11-13 12:34:49

digdugdiggy (57 views)
2014-11-12 21:11:50
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!