StandardGame Help

I’ve been reading topics on the forum about how to change over to using StandardGame.



I’ve gotten simple things working like shown here in darkfrogs simplegame to standard game effort.  But when it comes to some of the multithreading questions… i’m not sure about the best way to go about it.  I’ve looked through posts like this one asking about the multithreaded design.





What i’m basicly getting at… how would you synchronize things like:

“1. Input Handling (Create events and/or take action based on user inputs)

  1a. Network Event Handling (Network events could be handled by being placed on a queue and then received at this stage).

2. AI updates (Update AI behavior based on games internal state)

3. Game logic update (Actors/Entities in the game update using controllers, scripts, and event handlers)

4. Physics updates (update position of Actors/entities in the game. Collision detection)

5. Render Frame (Execute any additional OpenGL tasks on queue, and render frame).”




Where you would need them to be done in an atomic opertation.



Does anyone have any standardgame example source code that I can look at (on things like game logic in StandardGame)?  I seen plenty of examples with SimpleGame… just trying to get a grasp on how to work with StandardGame.  It is very interesting.  Any help or direction you can point me in is greatly apperciated.









-DK42



P.S.  The Game i’m working on is similar to “Twisted Metal” but with a Tron style and various strategy elements added in.

I would say the majority of problems with threading come from over-analyzing.  I think the same is also true with StandardGame.  The concept is actually quite simple.  It's not much different at heart than SimpleGame, it just has a different intention and focuses on all the work being done in GameStates instead.



I'll try to take your points one-by-one:


  1. Events can be handled the exact same way they are now in everything in jME…the place where events are spawned is a single-threaded process so you don't really gain anything from multithreading there.  However, there may be potentially gains from having your action processor being a separate (or multiple) thread(s) and just maintain a pool that the events get thrown to for processing.

    1a. Take a look at JGN http://forum.captiveimagination.com/index.php/board,4.0.html as it gives many examples of how to do manage networking events in games.
  2. AI can be entirely managed in an (or multiple) external thread(s) and simply connect to a GameState as necessary to deliver changes or request information on the scenegraph or bean structure (depending on how you designed your game). Depending on what you're doing this may require you do either lock StandardGame while you are working or toss an event in to be processed in the OpenGL thread (GameTaskQueue)
  3. No changes necessary for StandardGame…the only difference is your work is being done in a GameState instead of the Game itself.
  4. Could be a separate thread, but I don't believe that jME-Physics is designed with multithreading on this level in mind.
  5. GameTaskQueue, look back at my wiki tutorials for more insights.


Does anyone have any standardgame example source code that I can look at


I keep getting asked this question.  I would be happy to add to my most recent tutorial another conversion of a game to StandardGame if it would help?  Is there a test in jME that would be acceptable for this or does someone have a very simple game (don't really have the time to be converting someone's full game) they'd like me to switch to StandardGame?

Hope this is helpful.

Hmmm this is helpfull… I think I keep getting stuck on the idea of using a 'simpleUpdate()' that is called every frame to do some things.  It's used often in the examples and tutorials that I see that are based off of SimpleGame.



I'm still not fully clear on it all but it is starting to sink in some.




darkfrog said:

I keep getting asked this question.  I would be happy to add to my most recent tutorial another conversion of a game to StandardGame if it would help?  Is there a test in jME that would be acceptable for this or does someone have a very simple game (don't really have the time to be converting someone's full game) they'd like me to switch to StandardGame?

Hope this is helpful.


Yes this would help greatly. :)  I can't think of an exact test off the top of my head right now (I'd have to look back through them).  Just any one that covers a few of the topics that are commonly asked about would be nice.



-DK42


I’ll try to explain my point of view, which I hope it may throw some light on the topic:



What I’m doing with StandardGame is using it to manage all the usual game application flow, while using the GameStateManager to implement all the application logic.



I’m relying in that StandardGame is evolving to a standard-common skeleton for game apps, while leaving the concrete game details to GameStates (http://www.jmonkeyengine.com/jmeforum/index.php?topic=4360.0).



What I’d expect from StandardGame is that it managed the window and display creation, logging facilities, harward support checking, alt-tab support, maybe alt-intro support, application settings (in a extensible way, as many applications will store and load preferences in different formats)… This is quite similar to what StandardGame currently does, if we ignore the fact that it also creates a Camera and a PassManager which IMHO are superfluous.



That said, I’ll try to explain how I manage the server/client game logic with GameStates.



GameStates are arranged in a tree, which allows enabling and disabling a whole branch of GameStates with a single call. My current GameState tree is as follows:



  • MainState



    • ServerState

    • ClientState



      • InputState

      • RenderState



        • LevelRenderState

        • MenuState

        • ConsoleState









States will be executed in order, so the final game loop is as follows:

Update phase

MainState (1st step) simply calls its children.

The first one is ServerState (2nd step), which applies the client commands (i.e. setting throttle for a vehicle). That commands were received in separate threads, but you could just read the client data here.

Then it updates the game (I'm really relying on my Level object update method, which calls all entity update methods which apply forces) and then calls the physic engine update method. If you aren't using a physics engine, this step would update the scene information.

Then ClientState is called and it updates the input system (3rd step). The input system simply generates commands to send to the server (it can be done here or queue them in a separate thread).

Then the RenderState and its child are called (4th step). The LevelRender updates geometry, the ConsoleState updates the text in the console... No geometry will change from this point.

Render phase

The first render method which has code is the LevelRenderState, which (5th step) renders the scene from the adequate camera. It also renders debugging information and should render extra passes if you need it.

Then, and as always "if enabled", the MenuState (6th step) and ConsoleState (7th step) render their geometry to the framebuffer.


I can run in server-dedicated mode if I simply disable the ClientState. In the other hand, I still let the ServerState run when in client mode to process server messages and make movement prediction. My ServerState currently acts as a "server-mode server" and as a "client-mode movement predictor", but you may want to separate that logic in different ServerStates. It also works if I'm in single player mode or dual server/client mode.

Note that I'm actually making my GameStates inherit from GameStateNode, not GameState, which allows me to put logic in the update() method of middle branches of the tree, not only the leafs. I like this design because I can add logic to the game loop by simply adding some new states to the tree. It separates all the logic in an update phase and a render phase, which you may like or not. You may also want to use the GameTaskQueue, but I've found that it is the same that putting code at the beggining of the state chain (see StandardGame update() and render() code). I'm using it for some tasks anyway.

Hope it helps. Keep in mind that my design is surely poor, but maybe you can make an idea from it (sorry for the poor english too).

Regards,

J
jjmontes said:

Hope it helps. Keep in mind that my design is surely poor, but maybe you can make an idea from it (sorry for the poor english too).

Regards,

J



It did help me a lot actually.  After reading through your post I started thinking of how I could use GameStates and a lot of things started clicking finnaly.  I would still like to see a conversion of one of the test files, darkfrog.  More sample code on StandardGame in use is always nice. :)

-DK42

I'll try to get to that soon, but you guys have to figure out what you want me to convert.  :stuck_out_tongue: