Who's Using StandardGame?

StandardGame has been around for quite a while now and I posted a poll a couple years ago to see what kind of usage it was getting. I’ve seen so many people referring to it in their questions recently it makes me wonder what percentage of the community is actually using it in their projects.



For reference, here is the old poll (please don’t vote in it if you haven’t already as it will skew the numbers):

http://www.jmonkeyengine.com/jmeforum/index.php?topic=4140.0



Feel free to post reasons for why you chose to use it or chose against using it in your project.

Well for me the main reason was the argument presented in the WiKi and on the forums that it is the way to go if you are serious about your project. Initially I did not understand enough to look into the actual reasons for this point, so I just followed the crowd.



Currently as I am slowly adding features to my game, I am just happy with it as I keep discovering aspects in StandardGame that ease my development. I still do not understand everything it does fully, but it does not seem to be required for successful implementation :slight_smile:



Another thing that makes me happy with StandardGame is the fact that the forums always seem to offer you advice if you run into problems.



Yet another thing is that I am not sure of any good alternatives to it. SimpleGame just does not suit my needs. Starting to implement many of the functionality already in StandardGame in my own BaseGame also seems pointless. Yay for StandardGame

I use a bastardized standard game that I took and divorced functionality such as input and physics to a higher level.



But, yes at the core it is still just StandardGame, so I am going to vote yes :slight_smile:

basixs said:

I use a bastardized standard game that I took and divorced functionality such as input and physics to a higher level.

But, yes at the core it is still just StandardGame, so I am going to vote yes :)


That's disconcerting. Why could you not do this with StandardGame as it is?

Just to match my program design better, I like nicely separated components.  For example, by moving the physics into it's own class I can place all my call backs there, rather than scattered with all the nodes.  Also with the input in it's own class I can use it to manipulate fengGUI and jME with ease



I wouldn't find it disconcerting at all darkfrog, you should be proud that you created a product that can be so easily ripped apart (if one is so inclined) and remain fully functional not to mention how easy you made it to do. :slight_smile:

I'm pretty much in the same boat as basixs.  When I began adding physics I wrote my own class that handles just that.  I did it more because it was my first attempt with physics and I could understand the scope of the classes better that way.  :slight_smile:

I selected “I tried it, but didn’t like it”

I use my JmeContext system. In my opinion, it is superior to both StandardGame and the other jME ***Game classes.



Here’s why:


  • It directly interfaces with the underlying OpenGL implementation (no DisplaySystem usage), which not only gives cleaner and efficient code, but also provides the user more control over the display (floating point framebuffer, hardware stereoscopy, etc).

  • The clean API provides the user a display/context object from which they can get information or interact with the display. This object oriented approach is what allows the system to support multiple canvases/displays which are required by some applications.

  • It of course supports multithreading, in a similar way to StandardGame, through Callable and GameTask classes.

  • It has multipass 'buckets', you can organize what passes are called first, input, render, etc. without having to worry what passes the user added before. Passes can also have special initialization code which gets called in the render thread to allocate OpenGL resources. GameStates were lacking this, causing a crash in my application.

  • The provided source also contains several utility classes, such as a anaglyph stereo render pass, input, render, update template passes, PassManager method to add SimpleGame-like functionality, and a configuration dialog to select display properties before the application starts.

  • No modification to the original jME source is needed, the system works right out of the box



After reading this thread i converted to StandardGame :slight_smile:

Starting using StandardGame because it makes everything from a design perspective more clear. StandardGame helps me divide my game components in a nice way and its very easy to add or remove them on the fly.

I use standardgame exclusively now.

i chose i used it but i didnt like it.



i guess most ppl who use standard game coz of the native game state support.  :smiley:

i use basegame. i randomly chose one of the *game classes and built my game on it, so i can't really tell if i'd like standardgame more or less.

Momoko_Fan said:

I selected "I tried it, but didn't like it"
I use my JmeContext system. In my opinion, it is superior to both StandardGame and the other jME ***Game classes.

Here's why:

  • It directly interfaces with the underlying OpenGL implementation (no DisplaySystem usage), which not only gives cleaner and efficient code, but also provides the user more control over the display (floating point framebuffer, hardware stereoscopy, etc).

  • The clean API provides the user a display/context object from which they can get information or interact with the display. This object oriented approach is what allows the system to support multiple canvases/displays which are required by some applications.

  • It of course supports multithreading, in a similar way to StandardGame, through Callable and GameTask classes.

  • It has multipass 'buckets', you can organize what passes are called first, input, render, etc. without having to worry what passes the user added before. Passes can also have special initialization code which gets called in the render thread to allocate OpenGL resources. GameStates were lacking this, causing a crash in my application.

  • The provided source also contains several utility classes, such as a anaglyph stereo render pass, input, render, update template passes, PassManager method to add SimpleGame-like functionality, and a configuration dialog to select display properties before the application starts.

  • No modification to the original jME source is needed, the system works right out of the box




Interesting...when I have more time I'll get a look at what you've written more closely.
HamsterofDeath said:

i use basegame. i randomly chose one of the *game classes and built my game on it, so i can't really tell if i'd like standardgame more or less.


hehe, I guess that's a valid reason. :o  hhexen might run a lot faster and efficiently on StandardGame though. ;)

I'm using it, but I'm still at the very beginning stages of development.  I'm using it because it seems to do a lot of things for me that I was thinking about how best to do.  I figure the I'm not going to reinvent the wheel and I'll trust that the people who have been using jME for a while know better than I do.



So far I'm pleased with it.

I used to use a bastardization of Simple/Base/AbstractGame classes, but then I wrote my own bastardization of StandardGame stuff and they both did quite well for a few years… then, DF made improvements to StandardGame and I no longer needed the Frankenstein creations I had, now it's the only thing I do use.



If DF improves it more, well, I'll be using that version too.



timo

Whats the purpose of this poll? I dont see other devs posting polls with questions like "who uses waterRenderPass" or whatever. I just dont see the relevance and I voted "tried it didnt like it"  }:-@ bwahahaha

I dont see other devs posting polls with questions like "who uses waterRenderPass" or whatever. I just dont see the relevance and I voted "tried it didnt like it"  evil bwahahaha

That's because other implementations exist which could compete with StandardGame (BaseGame and friends). If there was another realistic water rendering implementation then MrCoder could put up a poll just like DF..
That's because other implementations exist which could compete with StandardGame (BaseGame and friends). If there was another realistic water rendering implementation then MrCoder could put up a poll just like DF
good point.

Actually, it was more a consideration of whether it were worth my time to create a new system in the ideology of StandardGame. I didn't want to waste my time making it public if there wasn't a large enough audience that would be interested in using it.