jMonkeyEngine.org

So it is a framework more than just a game? I see pics from 2 different games here… unless its a crazy 'transformer volleyball playing tanks' game.

What features are you trying to put in the framework… what will it be aimed for?

I am glad you ask about it … I was actually creating this for my IndoorBattles project but I divided to separate everything that I will be reusing.

GGF is a services and configuration framework, and also aims to impose some structure on how to design your game.  I'd say it aims to:

1) Provide a common structure and simplify game development. This is the main purpose and in theory (and so far this is working pretty well), you only need to extend View States, Logic States and Loaders.

2) Serve as a very quick start for new developments and help to make garage games more complete. Also provide ready to use game development aids (debugger view, screenshot view, Nymon's scene monitor integration, system reporting tools…).

3) Main configuration is done in a configuration file. Here you can see your complete ViewStateand LogicState hierarchy, your loaders and loader chains, your settings and defaults…  You can easily switch between components for a quick test, or add some introduction screens (or disable them during development )…

4) Be non-intrusive. Allow the developers a complete control over the final look and feel. You still have to code your complete game (JME is not hidden by GGF), but you get extra features for free from the beginning.

The components that I am implementing are: settings, settings storage, console, debugging and dev. tools, entity management, configuration, packaging, introduction/graphic screens, menu system, entity and model pools, entity and mode modular loading, command line processing, headless mode console…  All this is configurable and can be dropped, so putting everything together for a new project is a cut&paste matter  .

Development-wise, it is showings some really cool things  , and also has several flaws  , all of which I'm finding along the way. Anyway it is difficult to describe it completely here . It is now 190 classes long.

By the way, I could use some help, but if one person is willing to learn and use this thing, I will be glad to answer questions here or by IM and help back us much as I can with your project, by providing fixes and explanations quickly.

And, yeah!, that tanks game is (very) based on Wii Tanks! game. It's a great game. This one is also meant to be cooperative like the original. But again, I'll be happy if it only works  .

The components that I am implementing are: settings, settings storage, console, debugging and dev. tools, entity management, configuration, packaging, introduction/graphic screens, menu system, entity and model pools, entity and mode modular loading, command line processing, headless mode console…  All this is configurable and can be dropped, so putting everything together for a new project is a cut&paste matte

Entity management – so it has some built in entity management – I was sort of impressed by the ideas put forward in the data driven game engine threads where it was proposed to compose entities out of smaller components. Any quick description of how you have done it?

menu system – does this mean that you are linked to some GUI library? FengGUI or GBUI? Or have you made your own or is it just interfaces and more general code?

Do you make any assumptions on the type of games that can be developed using this engine? Real time/Turn based, how is the client server separation done if at all?

It sounds very interesting for me and I would really like to take a look. How much useful feedback I can actually offer is probably a different thing, depending on a number of things starting from how clearly are things packaged to how much I actually understand the reasoning behind the different bits of code.. I have a feeling you know quite a bit more than me about game design Perhaps you could send a PM if you do not want to post some SVN link here…?

Edit: If I can figure it out, I would probably also be interested in using GGF with my own project (should you choose to share it) as anything that would speed up the otherwise slow progress is welcome.

I added a ViewState to show a grid, copying code from owaye, and I added with the following configuration:

            <view id="view/root/level/axis" class="net.ggf.jme.view.AxisGridRenderView" context="debug">
               <autoLoad>true</autoLoad>
               <autoActivate>true</autoActivate>
               <camera ref="scene/camera/test" />
               <drawBehind>false</drawBehind>
               <gridCenter>0.0 0.5 0.0</gridCenter>
            </view>

And the result:

Thank you! It really cheers me up especially coming from someone like you.

Yes, pretty much everything is defined from the main config file. For instance the Stats view, or the loading system, or the entity manager and groups. But sometimes you will want to create and add some components from code (mostly entities). The idea is that some components can even serve as a placeholder which you can replace afterwards, without modifying anything else.

Have a look at the tanks.xml configuration file .

JmePhysics is a dependency because a couple of plugins for GGF are the PhysicsScene and the PhysicsEntity, which simply contain a DynamicNode or a StaticNode. But I will add a few other components like the physics debugger view and some other physics related stuff. Its easier when you see an example! .

Also, I don't know if this kind of things (frameworks) are good for beginners, but ideally it would be something that beginners can jump onto soon.

I have made some additions. Some of them may help explaining what JGF is about:

1) In a game framework, we want a quick way of putting stuff on screen. I have added a DisplayItemsView that allows the user to put some images (I'll add text) on screen:

Artistic abilities aside , this could be useful for introduction screens, loaders, and simple HUDs or in-game messages, and avoids coding for simple stuff like that.

In JGF, we add this ViewState and configure it like this:

<view id="view/root/intro/logo" class="net.jgf.jme.view.display.DisplayItemsView"
  autoLoad="true" autoActivate="true">
               
  <item id="view/root/intro/tech/1" class="net.jgf.jme.view.display.ImageItem">
    <center>-0.66 0.5 0.0</center>
    <textureUrl>tanks/texture/logo/tech-jme.png</textureUrl>
  </item>
  <item id="view/root/intro/tech/2" class="net.jgf.jme.view.display.ImageItem">
    <center>0.0 0.5 0.0</center>
    <textureUrl>tanks/texture/logo/tech-jme.png</textureUrl>
    <size>0.8</size>
  </item>
  <item id="view/root/intro/tech/3" class="net.jgf.jme.view.display.ImageItem">
    <center>0.66 0.5 0.0</center>
    <textureUrl>tanks/texture/logo/tech-jme.png</textureUrl>
  </item>                  
</view>

2) We want those states to fade in and out, so let's wrap them with the new FaderViewNode:

<view id="view/root/intro/fader2" class="net.jgf.jme.view.FaderViewNode"
  autoLoad="true" autoActivate="false" >
            
  <fadeInTime>1.5</fadeInTime>
  <fadeOutTime>0.8</fadeOutTime>
  <autoFadeOutTime>4.0</autoFadeOutTime>
  <allowKeyToSkip>true</allowKeyToSkip>
  <color>0.0 0.0 0.0</color>
               
  <view>
    ...
  </view>
</view>

And we have a nice fade in on each of the introduction states.

3) We can wrap all that in a SequencerState, so the introduction screens are activated and deactivated (and unloaded) sequentially. As configuration has a context, we can turn all of those introduction states off during development, just switching a parameter in configuration.

4) The pipelined loading system is proving quite efficient (for models, entities and scenes). It is easy to add on-demand model conversion, or entity pooling.