Heya,
I wanted to suggest a few “nice to have but definitely not required” changes to GameStateNode. The first was to add GameStateNode recursion to the activateAllChildren and deactivateAllChildren methods. Here’s the code:
/
* Will call setActive(true) on all GameStates maintained.
*/
public void activateAllChildren() {
setChildrenActive(true);
}
/
* Deactivates all maintained children contained by this GameStateNode.
*/
public void deactivateAllChildren() {
setChildrenActive(false);
}
/
* Sets whether or not you want this GameState’s children to be updated and rendered.
*
* @param active
* Whether updating and rendering should be enabled
*/
public void setChildrenActive(boolean active) {
for (int i = 0; i < children.size(); i++) {
GameState state = children.get(i);
state.setActive(active);
if (state instanceof GameStateNode) {
((GameStateNode) state).setChildrenActive(active);
}
}
}
The next suggestion was for attachChild, just to add the ability to chain calls a little (:
/
* Attaches a child to this node. This node will become the child’s parent.
*
* @param state The child to attach.
* @return the child state that was attached
*/
public <T extends GameState> T attachChild(T state) {
state.setParent(this);
children.add(state);
return state;
}
So state creation for jjmontes’ post could look like this:
MainState mainState = new MainState();
ServerState serverState = mainState.attachChild(new ServerState());
ClientState clientState = mainState.attachChild(new ClientState());
InputState inputState = clientState.attachChild(new InputState());
RenderState renderState = clientState.attachChild(new RenderState());
LevelRenderState levelState = renderState.attachChild(new LevelRenderState());
MenuState menuState = renderState.attachChild(new MenuState());
ConsoleState consoleState = renderState.attachChild(new ConsoleState());
mainState.activateAllChildren();
Or a chunk of code from TestLoadingGameState would change from:
// Enable DebugGameState
DebugGameState debug = new DebugGameState();
GameStateManager.getInstance().attachChild(debug);
debug.setActive(true);
to:
// Enable DebugGameState
GameStateManager.getInstance().attachChild(new DebugGameState()).setActive(true);
ok, well maybe I don’t like the look of that last line much, but I’ll leave the suggest in the post.
Actually setChildrenActive should probably have two parameters, one with the active flag, and another that signals whether or not to recurse through child GameStateNodes.
First off, what's the difference between:
public <T extends GameState> T attachChild(T state) {
and:
public GameState attachChild(GameState state) {
Other than the added complication of the former?
Second, I have been saying for quite some time that GameStates need re-working, but I'm not sure if we should add these to GameState or create an ExtendedGameState that offers these capabilities to keep from overcomplicating the GameState class?
darkfrog said:
what's the difference
You don't need to cast if you want to use the concrete type of the state from the returned value. But it could even be void, couldn't it? Chaining such calls does not make much sense, does it?
I think that you will be rarely enabling or desabling all the tree. Also there is no need to disable a whole branch (just disabling a parent avoids children render and update). Also I don’t think that anyone will be constructing all gamestates in the same point, or at least not in the same method.
I think I have to play with all this part of jME a bit more before I can get an better opinion on it. Improvements should respect the actual interface, though.
IMHO is a question of tastes. The actual design is good enough and does the job .
Other approaches XD :
http://gamedevgeek.com/tutorials/managing-game-states-in-c/
http://www.ogre3d.org/wiki/index.php/Managing_Game_States_with_OGRE
Okay, I guess I see the benefit to it…I'm not a big fan of chaining either though. I think it encourages you to write sloppy code on one line.
We're not Perl programmers after all! 
jjmontes said:
I think that you will be rarely enabling or desabling all the tree. Also there is no need to disable a whole branch (just disabling a parent avoids children render and update). Also I don't think that anyone will be constructing all gamestates in the same point, or at least not in the same method.
I think I have to play with all this part of jME a bit more before I can get an better opinion on it. Improvements should respect the actual interface, though.
IMHO is a question of tastes. The actual design is good enough and does the job .
I jumped the gun with these suggestions :// My code is done and working atm, just ideas I had while I was writing it. I still do have my game states created in a single place so I can add "filter" game state nodes like render/update timers but who knows what it'll change to as I get further into the process.
jjmontes said:
Other approaches XD :
http://gamedevgeek.com/tutorials/managing-game-states-in-c/
http://www.ogre3d.org/wiki/index.php/Managing_Game_States_with_OGRE
Sweet thanks for the links, off I go to read.
darkfrog said:
Okay, I guess I see the benefit to it....I'm not a big fan of chaining either though. I think it encourages you to write sloppy code on one line.
We're not Perl programmers after all! :P
Yeah I only use chaining when the line of code won't wrap, and from what I've seen it's used just to reduce line count. I also like it when a single function will be called on an object many times. Like this:
ResultSet rs = createQuery().selectAll().from("mytable").execute();
Not a big deal when there's one query, but if there are 20-30 queries in a class with lots of conditions the reduced line count can add up quickly. I haven't had readability issues as long as a single line of code isn't longer than 80 chars or whatever the wrap is set to. Probably just a personal preference, I don't like to have to scroll a lot when trying to read code. Or maybe I'm just too lazy :wink:
Eep! No, I hope this doesn't mean I'm a perl programmer :( That's one of the few languages I try to stay away from.
lazlohf said:
I jumped the gun with these suggestions ://
I didn't want to mean that ://.
Discussion is always positive. And given a graphic/game engine, structuring game code is for me one of the big issues.
Please remember that I'm not a native english speaker :'( anyway. I don't always mean what I say.
Regards,
J
jjmontes said:
I didn't want to mean that ://.
Discussion is always positive. And given a graphic/game engine, structuring game code is for me one of the big issues.
Please remember that I'm not a native english speaker :'( anyway. I don't always mean what I say.
Regards,
J
Oh no worries, even without everyone's help as I continued to code I realized those suggestions (especially the example with activating all children of mainState) really weren't that great or applicable. By the way, the fact that I got all of these responses in less than a day that discussed the changes proves the JME community is a good one to be a part of ;)