[java] switching gamestates - ugly?

No. You might have something like this.

public class State {
  public static GameState currentState;
}

public class SomeThreadClass ... {
  public void run ( long curTime ){ 
    if ( Keys[KeyEvent.VK_ESCAPE] ) { //back to the mainmenu...   

      State.currentState = new MenuGameState ();
     return; 
    }
  }
}

---

First make it work,
then make it fast.
--Brian Kernighan

"I’m happy to share what I can, because I’m in it for the love of programming. The Ferraris are just gravy, honest!" --John Carmack: Forward to Graphics Programming Black Book

I''d suggest trying to get the GameStates to do their job and their job only. Things like esc and such can be handled at the top level, then the active state can handle the input that it''s interested in. It doesn''t make sense that the states are aware of when switches need to be made, they''re not controlling the game the overall master class above them is. Something like

class MyApplet
{
...
	private GameState activeState;

	public void play()
	{
		for(;;)
		{
			if(keys[KeyEvent.VK_ESCAPE])
			{
				activeState = new MenuGameState();
			}
			// other outer level "meta" input handling

			
			activeState.run(ticks);
		}
	}
}

Then the GameStates can just do their job and not worry about the rest of the game. The master class will have to know how the game flows and switch states accordingly.

In some cases a state is aware of state changes, maybe a level has ended and the active state knows a summary screen needs to pop up. Then you could have run return a value to indicate that.

My one suggestion would be to create a final static instance of each state instead of using new all the time.

public static final GameState MENU_STATE = new MenuGameState();

Then you could just say ActiveState = MENU_STATE and not be creating any garbage.

Also, I think that the states should handle state transitions. I think that''s what the state pattern is for. And I don''t think he needs to screw around with threads. run(long curTime) looks like it''s called once per game loop. Maybe he should call it update(long) to differentiate it from run() in Runnable.

this is a good suggestion, i will make them final i guess.

yup, no threads here, run(long curTime) is called once per main loop.


how would one handle state transitions properly? i always did some simple hacks for screen-fading in/out to another gamestate. i''d be interested in such a system.

I think you just have to keep track of when the state changes

if(activeState != previousState) {
   doTransition();
   previousState = activeState;
}
 

Why not have the run method of the state return another GameState? That makes state transitions one of the responsibilities of the state itself.

--
AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.
[Project site] [Blog] [RSS] [Browse the source] [IRC channel]