Jme environment

Hi all,

yesterday was all saints day, which is a holiday in germany, which is why I could eventually spend another day developing parts of my (hopefully) upcoming game.

While I was doing that, I found several areas where I immediately thought that some of you must have stood in front of the same tasks, although they need not necessarily be central parts of jme; that is why I’d like to call them “jme environment”. I give you some examples:

I want to have the keys for the actions in my game to be configurable. Therefore I need a mapping between lwjgl key codes and key names, which I can then write into a properties file and which I can evaluate at game startup, something lwjgl does not provide AFAIK. Basically this is about setting up a mapping class which holds an enumeration of the possible keys and the required information; I added translations for the key names into different languages (and possibly an abstraction of the different key layouts of different international keyboards; german keyboards look differently from french or english eg.).

Next thing: I want my hud to look nicely for different screen resolutions, so I plan to orient the different parts of my hud to screen borders or edges, like in a gridbaglayout’s “anchor” property, eg. “NORTH”, “NORTHWEST” etc. Small helper class required to place quads onto the screen, possibly an extension of Node.

Another thing: what about having an ant plugin which enhances ant scripts by adding the possibility of model conversion from 3d models to jme?

Additionally there may be lots of multipurpose controllers, actions, inputhandlers out there, which fit into the needs of some of you, but they should not all be part of jme.

So what I would like to ask is whether you think it would be a good idea to collect these somewhere in some sort of contributed source pool so that everyone may benefit? It’s just a vague idea I know, but maybe somebody has an idea for organizing this?

sounds good :slight_smile:

question is should this be in cvs and be maintained by jME folks (jme addon lib) or just kept on some sort of code-wiki site for reference where folks can download and fix up for current jME as they see fit.

This, and the GameState belong together. Although the GameState should IMO go with the my AISystem which I shall be putting up for review soon so people can vote whether to have it in CVS or not…


I think that jME is a game engine, and games have game states, thus should the game state system be in the core.

That’s just my opinion.


"winkman" wrote:
question is should this be in cvs and be maintained by jME folks (jme addon lib) or just kept on some sort of code-wiki site for reference where folks can download and fix up for current jME as they see fit.

Well I think the easier it is to use, the more people will be likely to contribute. Therefore I think the code-wiki idea would be best fit. If it turns out that something contributed there would be better of in the cvs, then mojo might as well review it and place it there himself.

Yeah, the wiki would be nice… maybe it could be squeezed into a "Developers FAQ"? Like "How do I make a control mapper?", and then there are an answer with attached code.

Personally I agree that sample code would be nice to have in a visible, searchable location such as the wiki. It’s more natural for programmers to look online for code samples and should lend itself to documentation and dialog.

If there was a wiki I would contribute to it.

There would need to be some rool about licensing. For example all code must be BSD.

I did something similar to this for my game engine that I was working on. I, actually today, thought about the possiblity of converting this from my BSD game engine code to something that could be reviewable for JME.

What I do is allow either XML or INI files (the latter obviously just being a properties file) and I set where I want the files to come from then a key processor that takes the xml and parses it through a hashmap and into a gameaction object.


<!-- mappings for either attributes or elements //-->
    <key char="A" action="playAudio(1)" display="play sound 1"/>
        <display>play sound 1</display>

I'm refactoring some naming for the xml file to be a little more clear, but essentially:
The char element/attribute is what I want it mapped to this directly correlates to the VK_ name via a hashmap, as mentioned before, in my KeyMapping class (and that's all the class does)

The action element/attribute is what action I want to perform from the mapping. e.g. call a method via reflection or whatever could even be

if (action.equals("playAudio(1)"){

As of right now, this is mapped directly into the game engine per the developer, but again another todo is rip this out and have it work a little more dynamically.

The final Element/Attribute display is what I want to display to the user. In my key configuration application the user can config their keys (a lot buggy right now), but this is what would display to the user to let them know what they are modifying... like move forward or move backward, etc.

There is no difference between the xml and ini bindings that I have written except for how they are read in. In the effort of speed for smaller jvms like using midlets, etc, I wrote a binary reader/writer. So you can write your test code in xml/ini and compile it into binary then read it /write it via the configuration screen (currently a test tabbed swing frame).

That's the basic rundown. In addition to keys, I have some xml bindings for the base window loading, sounds to load, images, level listings, etc.

These other things are additions to the engine that I made so I could define things in them and not have to code the base engine around specific elements, or go in and rewrite for every game I did.

If you'd like to work together on this or whatever, let me know. I'm going to refactor, as I said, over the next few days to get it cleaned up and stripped from the base gerbildrop engine (again in the premise that I would have submitted it to jme for review and comments, etc)

I can go ahead and do the separation and then submit it to this post for everyone to see, if that's alright. :D

I have a quick tutorial on my site that covers how I did some of the xml stuff. I don't remember what exactly is in the tutorial even though it was only a few weeks ago. -- and I went to make sure that it was still up and the base page is, but the jar was removed during an upload I did a few days ago :// so I need to find the jar and reupload it. I just read my own tutorial and it's bad, I remember the 2 am upload I did on that one ;)

lemmie know,


PS probably ought to clarify. I started the game engine a long time ago, then a lot happened and I came back to it and started rewriting the wrapper and input management was the first thing I changed, but decided that instead of doing my own engine, I'd go with JME and now would like to contribute something:)

ok found the file and uploaded it. It’s a quick and simple test with EXML it reads in an xml file and writes out a different xml file.

This is the bare basics stripped from my engine. The engine code I have for something similar actually is a lot more code.

EXML was used because it was the easiest processor I started with. I know there’s verboten on 3rd party libs (from other posts that have come up in the last year or so), so it could be rewritten with sax or dom or whatever is approved for jme.

I’m probably just about done with the ripping part from my engine and will try to post a zip with the files in it later today… it may not work correctly for some pieces, e.g. I had to reinsert the INI props reader because i never use it. But it might give a quick basis to look at and/or modify for use.

it’s all BSD with copyright at the top.

I’m still cleaning up the port of my site from mycgiserver to lunarpages, so there are a lot of links not displaying and the layout is not right, but I’ll put the zip file link under the Game Index page rather than the XML link. That way anyone looking at the tutorials won’t download the wrong one.

This zip contains the first iteration of my GameState (nothing like the one in JME) and I tried to javadoc as I could, I think I got everything.

Actually, I’ll go ahead and upload it now then as I make changes I’ll upload newer editions.

He hasn’t done anything with this in a while, and what he did, he states wasn’t even close to what I have done. You can download the sample code that I have at and and run it. what I have available is the key input to read from xml files along with some other things, and it will show you the swing options pane where you can set your key mappings and when you save it, it goes to a different xml file, but could be changed to go to the original xml file as was designed.

I’m looking for more ideas on how to improve this setup (not just the key mappings, but the rest of the game code. If there are any comments on the base game code it should probably be started in another thread. But again, anything is what I’ll look for so that I can finish it up and submit it for code review.