There’s no longer a need to pass a Node to the GameStateManager - each game state should have its own scene tree.
StandardGameState has been changed to be more in line with the jME game classes; it now holds final update and render methods, which in turn calls empty (and protected) stateUpdate and stateRender methods. Just like in SimpleGame.
Other small stuff that has been discussed earlier, e.g. a switchFrom method in StandardGameState, and a getCurrentState in GameStateManager.
Wonder if you could add the feature that would allow multiple game states to run at the same time (for GUIs) like (I think) guurk asked. Also, I haven’t yet reached the point where I’m going to use GameStateManager yet, but when I do it’d be nice to have the stuff in jmetest updated to work with the latest version of GameStateManager. Just a thought…
it'd be nice to have the stuff in jmetest updated to work with the latest version of GameStateManager. Just a thought...
The gamestate test uses Per's new stuff for me...
Oh ok, I ASSuMEd that part, just making sure (again, like I said, I haven't actually used this part of jME yet, just planning on it in the future). ://
Currently, the FirstPersonHandler takes an AbstractGame, Camera and a String to initialise. To make it work for the game state system it needs to take instead of the AbstractGame, a GameState…
That AbstractGame is used for the KeyExitInputAction to call cleanup on it before exiting. So the KeyExitInputAction should work with the GameState too and call its cleanup method before exiting…
Ah yeah. Might be tricky though since they don’t share a common interface or anything. Maybe having two different KeyExitAction’s is the way to go? Or having them both implement Closeable or something
Oh, right, had completely forgot about that. I remember thinking about it some time ago, without coming to any smart solution. Ideas, anyone?
Not sure how your GameStateManager works (again, as I said, I haven't yet used it), but couldn't you just have a rootNode and attach two subnodes to it? As in, the actual game action node and a node that holds the GUI?
That would have worked with the old design. I’m probably just gonna go with putting them (the GameStates that are desired to update and render, that is) in an ArrayList.
Okey, I’ve done some more thinking on this, and it’s going to require a revamp of the current system (which shows how inflexible it is atm); I’m gonna go with a tree design, with a GameState and a GameStateNode (like com.jme.scene.Spatial and com.jme.scene.Node).
I’m not sure how much of the old interface that can be left intact, but at least a GameState can’t be forced to contain a camera, and the whole switchTo/switchFrom thing won’t work.
I think it’ll be way more flexible this way, at the cost of breaking some code. Just giving you guys a little headsup
Okey, this new stuff is in, and I must say I’m pretty happy with it - I think it’s as flexible as it gets…
To summarize the changes, I can say that the gamestate system now is - as stated above - node based. If you take a look at the interface of GameState and GameStateNode (new class), you can see that this works pretty much like jME’s own scenegraph, where GameState would be Spatial, and GameStateNode would be Node. This means that each GameState now contains a parent GameStateNode, and a flag that indicates whether or not the state is active (just like Spatial’s forceCull).
All maintained active GameStates of a GameStateNode will be updated and rendered.
StandardGameState has also gone through some changes:
It no longer maintains an InputHandler. This is to make derived classes govern whether or not to update it, e.g. one would not like to update the ingame states InputHandler while the ingame-menu state is active.
It’s no longer abstract (the InputHandler was the only thing that derived classes had to implement).
The switchTo/switchFrom methods has been renamed to onActivate/onDeactivate (note that this is now a StandardGameState specific thing).
Also a new class, BasicGameState, has been added. As the name implies, it provides very basic functionality; it maintains a rootNode which it updates and render. No camera or such.
Umm… that’s about it I think. The tests has been updated, and I’ve made a little menu (with submenus and such) for Marble Fun just to test the concept a little. I’m probably going to make a test showing the same thing.
