StandardGame, GameStates, and Multithreading Wiki Entry

Check out my new wiki tutorial:



StandardGame, GameStates, and Multithreading (A New Way of Thinking)

A Paradigm Shift by darkfrog



http://www.jmonkeyengine.com/wiki/doku.php?id=standardgame_gamestates_and_multithreading_a_new_way_of_thinking

Well, dang, only 4th. I would have at least given it 3rd.



http://www.cnet.com/4520-11136_1-6275610-1.html



Try to get Mindshare in there somewhere.





In all seriousness… I think I vomitted a little in my mouth when I saw you use that phrase.

That has just cleared up a lot of things! I didnt understand what the heck a gamestate was before. Is making a normal game (extends AbstractGame) into a GameState hard? And could a game state be used in an applet? That wiki is very helpfull.

I'm not sure I get where this is a new way of thinking?  SimpleGame and the like is only an initial building block for new comers getting their feet wet (although, as with most hobby projects, many only dabble in the first step and that fulfills their curiosity.)  Game states are nothing new as you mention…  Even my old Dirt game in jME was doing game states and the game state classes written by Per have been around in jME for a long time.  Multithreading in games is also not really new… ask any of the guys at my office about multithreading and they'll say that's already standard practice with networking, audio, AI, physics and the like.  Definitely useful don't get me wrong, but hardly new… and reads a bit like an ad for your personal StandardGame class.  :wink:

mojomonk said:

In all seriousness... I think I vomitted a little in my mouth when I saw you use that phrase.


Then I've done my job better than I could have hoped. :) Come on, if I have to write a tutorial at least I can have some fun.

The Gibi said:

That has just cleared up a lot of things! I didnt understand what the heck a gamestate was before. Is making a normal game (extends AbstractGame) into a GameState hard? And could a game state be used in an applet? That wiki is very helpfull.


Nah, it shouldn't be too difficult to make the switch, primarily just ripping out a lot of the functionality that's no longer necessary really. Sure, it can be used in an Applet.

renanse said:

Definitely useful don't get me wrong, but hardly new... and reads a bit like an ad for your personal StandardGame class.


That's really what it is...I truly believe that eventually StandardGame could be used as the standard for any game written in jME and that's what I'm trying to get across.

Honestly, even though I was having some fun, it is still something of a paradigm shift in abstracting all of the game concepts away from the developer and that's the primary focus of StandardGame. I really was going for something catchy and perhaps I've been writing too many documents at work that look surprisingly similar, but it did its job and has gotten a bit of attention so I'm happy. ;)

Nice ad 8)

And nice starting point for people about to use StandardGame, but…



Threading still is a bit more complicated that it seems in that article. E.g. updating the scenegraph while it is currently rendered can lead to strange flickering/jittering effects. Maybe you should point out that StandardGame is not for newbies. And for the advanced people you should mention that they still have to sync their code with the render thread. (?)

Definitely threading is more complicated and that's why I suggest further reading on it. jME in general is not for Java noobs.



Updating the scenegraph while it is being rendered could perhaps cause some strange effects perhaps, but I have yet to have any problems with it.  You don't have to synchronize the majority of your code with the render thread.  In most cases you'll probably be building GameStates that are not visible yet anyway, so this would be an issue.  However, there shouldn't be any need to synchronize with the OpenGL thread for the majority of cases, it's working wonderfully well for me thus far.  Further, if there are problems with this they should be addressed because remaining synchronized with the OpenGL thread loses nearly all benefits of multithreading.

I didn't mean "Java noob" but jME newbies - when you start to figure out how jME stuff works it's really a bad idea to use StandardGame right away, I think.

I disagree, as long as you have a good understanding of threading already then I don't see any problem in using StandardGame and in fact, I think it can make life significantly easier. Granted, it does hide a lot of the functionality of jME that is beneficial to know, but still I don't see any problem using StandardGame from the get-go.

On everything jME method you invoke you need to decide wether it might call OpenGL and if yes put it in a callable. That's nothing I would like for getting started. And the worst thing is that you get the strangest effects when you forget to do so.

That's definitely valid and a caveat that must be understood by someone wishing to utilize StandardGame.  However, the number of calls in jME that need to be explicitly executed in the OpenGL thread should reduce significantly over time as better multithreading support is added to jME.  Currently this is definitely something that must be understood in order to use StandardGame.

Does that mean you will add the "not for jME newbies" disclaimer? :slight_smile:

No, because they simply have to accept that fact with any multithreading in jME and though it adds a bit of complication there it removes significant complication in other areas, so I'd say it's a trade-off.  jME newbies just have to make their own decisions and I still believe StandardGame is going to be easier to figure out and use than the alternatives for newbs.

I'm a JME newbie and I went directly to StandardGame for its multithreading support - my Java apps are all multithreaded, and this just adds another thread. :slight_smile:

Qworg, I will take your statement as a compliment. :wink:

thx darkfrog,



i tried to realize just such a thing as StandardGame and ended up nowhere. now that i stumbled upon SG it took me 2 hours to make it work  :smiley:



thxal

That's what it's there for.  XD