Confused about StandardGame

Hello everybody.  This is my first post on jME forums, but I have been playing around with the engine for about 2 years and I love what I’ve seen so far.



After reading the wiki articles about StandardGame, I decided I wanted to convert to it from my SimpleGame.  I pretty much copied the structure of the example on the wiki page.



However, I noticed that instead of extending your main class, you use separate classes (StandardGame and <whatever>GameState), which blocks all my StandardGames and GameStates from using my main class variables (like the mouse, the game logic objects, etc).



So my questions are:



Is it possible (and efficient) to write my main class as an extension of StandardGame?



and if so, why does the example on the wiki not extend StandardGame?



Thanks for the answers.  I’m just a little confused as to where everything should go (updates, inputs, etc) without creating a child of the game type.

frog will get really mad if u extend standardGame haha  :smiley:



u should put all the things u need inside a game class that doesnt have to extend standardGame. some sort of manager class.

There are many ways to handle this and StandardGame was converted to be "final" so that people wouldn't mistakenly try to extend it.  As neakor says, it was not intended to be extended, but instantiated and used. Anything that would otherwise be stored in your Game should be put in a GameState or elsewhere.

Thanks for the help so far.



I'm still a little confused as to where my code should go.  Right now my main class looks somewhat like the wiki example:



/**
Global variables here, including most of the UI components and the game logic classes.
*/
public static void main(String[] args) throws Exception
   {
   game=new StandardGame("GameName");
   GameSettingsPanel.prompt(game.getSettings());
   game.start();
   DebugGameState state = new DebugGameState();
      //do stuff with global variables
   display=game.getDisplay();
   Node scene=buildSceneGraph();
      state.getRootNode().attachChild(scene);
   GameStateManager.getInstance().attachChild(state);
   state.setActive(true);}

public Node buildSceneGraph()
{
//builds the scene graph
}



and right now my update code is lingering in a comment box because I'm not quite sure where it should go.  I'm pretty sure it goes into the gamestate, but I have no idea how to let the gamestate reference my global variables (unless I made them all public).  Should I make a separate GameState class to use to keep all my stuff in (MyGameState extends DebugGameState?) and call it up from the main class?  so it would look like


MyGameState mainState=new MyGameState();
StandardGame game;

public static void main(String[] args)
{
   game=new StandardGame("GameName");
   GameSettingsPanel.prompt(game.getSettings());
   game.start();
   display=game.getDisplay();
   
   //These three lines would change, I just don't know the hierarchies that well yet.
   Node scene=mainState.buildSceneGraph();
   mainState.getRootNode().attachChild(scene);
   GameStateManager.getInstance().attachChild(state);
   state.setActive(true);
}

For a start you can put everything into your own GameState which extends BasicGamestate.



In the GameStates Constructor you create the Scene (create Light, ZBuffer, Load Textures, create Scene Elements etc.)

In the GameStates update() method you put all your games logic.



So in the main() method you only create a StandardGame instance and one or many GameStates which you attach to StandardGames GameStateManager.

one of the reasons y i done like using standard game is that u have to create some sort of game manager class that actually contains ur standard game object. its like a game contains another game that actually manages the main loop. this just seems make little sense to me.



so what u would wanna do is create a such class that creates the standard game, initializes ur game states. then seperate all ur game logic into different game states. and in there, override the updat(float) method if u need to do some custom updating.

neakor said:

one of the reasons y i done like using standard game is that u have to create some sort of game manager class that actually contains ur standard game object. its like a game contains another game that actually manages the main loop. this just seems make little sense to me.


It seems less silly to jam all of your game's logic code in the same place as your underlying base game system?  Modularity is the key point of StandardGame and ultimately why I chose to make the class final.
neakor said:

one of the reasons y i done like using standard game is that u have to create some sort of game manager class that actually contains ur standard game object. its like a game contains another game that actually manages the main loop. this just seems make little sense to me.

so what u would wanna do is create a such class that creates the standard game, initializes ur game states. then seperate all ur game logic into different game states. and in there, override the updat(float) method if u need to do some custom updating.


It adds another abstract layer, making your game more manageable and modulair which is kind of helpfull when you're designing a rather big game.
Coming from SimpleGame, or BasicGame, GameStates are really an improvement IMO.

Thanks a bunch everyone.  Yeah making my own gamestate is what I was assuming I'd have to do.  Again thanks a lot, you guys were really helpful.

Darklord said:

neakor said:

one of the reasons y i done like using standard game is that u have to create some sort of game manager class that actually contains ur standard game object. its like a game contains another game that actually manages the main loop. this just seems make little sense to me.

so what u would wanna do is create a such class that creates the standard game, initializes ur game states. then seperate all ur game logic into different game states. and in there, override the updat(float) method if u need to do some custom updating.


It adds another abstract layer, making your game more manageable and modulair which is kind of helpfull when you're designing a rather big game.
Coming from SimpleGame, or BasicGame, GameStates are really an improvement IMO.


i guess im just buying the whole underlying game thing. i like to handle all the game system, especially i need to modify some of them to suit my own purpose. i think momoko_fan is doing something similar.

i agree that when u design a big game system, u need a even better mudularity which is exactly y i wanna manage my system but not using standardgame. and my logic is all delegated down to entity controllers or some of the manager objects. i have no logic in my own game class at all.

Then you're essentially just trying to recreate the design of StandardGame on your own.  There's nothing wrong with that if StandardGame doesn't suit your purposes, but is there anything specific StandardGame doesn't provide that pushed you down that route?

Actually I think you guys should make a list. Darkfrog list all what StandardGame offers in addition to BaseGame. And then Neakor ticks those features off one-by-one saying that it is sufficient and suitable functionality or 'this needs to be different in my game'



You would solve your problems and I would learn a ton from reading about your game design… everyone is happy :slight_smile:

hehe

haha that would be very nice. but unfortunately, i just dont have the time to go back and analys my system right now. ill try to make a list once im done with this term in may.



but one thing though, using StandardGame + JGN for a headless server is definitely nice  :smiley:



thx frog~

So the game I'm prototyping right now is using BaseGame. I'm just playing around with jME and Java right now…but eventually this prototype of mine will grow into something bigger. It is not modular right now…actually, I think it's a mess structure wise if all of the Design Pattern literature I'm reading is correct.



Question…should I start converting to a StandardGame approach now or will I be able to scale my protoype as it gets more complicated with BaseGame?



D

it dosen’t matter much if you use your own BaseGame implementation or StandardGame.

But you should take a look at the GameStates concept, it helps you to separate different elements of your game.

You can use GameStates with any kind of Game implementation.



If you switch to StandardGame you might will run into some threading issues, which will make your life a bit harder if you are new to jME.

Thanks Core-dump.



What would the general structure for that be? Right now, I've got something very similar to FlagRush lesson 7 (with some other added classes as well).



Would the gamestates just replace all of those buildXXX() in initGame() and then have them rolled into their own GameState classes? i.e. inputGameState(), playerGameState(), chaseCamGameState().



I would like to get the program as modular as possible and it sounds like GameState may help with that from a design perspective…so what would it look like?

Not sure about this but I think the BaseGame and similar classes also switched to a threaded approach using GameTaskQueue. You might not be able to notice it since they make sure the key code runs in the render thread (which might not be preferable).

darrenl said:

What would the general structure for that be? Right now, I've got something very similar to FlagRush lesson 7 (with some other added classes as well).
Would the gamestates just replace all of those buildXXX() in initGame() and then have them rolled into their own GameState classes? i.e. inputGameState(), playerGameState(), chaseCamGameState().

I'm not sure actually, it makes sense to split the GUI and in Game logic into different GameStates, everything else is always very Game specific i think.

Momoko_Fan said:

Not sure about this but I think the BaseGame and similar classes also switched to a threaded approach using GameTaskQueue.

hmm no i don't think so, it would be a bad idea, because having a separate opengl thread gives so much headache :)