2004 Java[tm] Technology Game Development Contest

I’m sure most of you are familiar with java.net community but I decided to announce this here also. Sun is setting up a game content, more information can be acquired from here:



See:

http://community.java.net/games/

and

http://games-contest.dev.java.net/



Now, I’d like to ask from jME developers about the current state of jME library.



Does anyone have any reasons why jME couldn’t be used for creating a simple game today? I haven’t checked jME’s status for some months so excuse if my questions seem bit akward.



Let’s put it simple:


  1. what is the state of loaders

    -can I load big environment (e.g. terrain), consisting of >10k vertices to scenegraph without problems? We’re using 3d studio max.


  2. hundreds of static enviromental objects

    -can I load hundreds of 3ds/ase objects (e.g. house, trees) to scenegraph without problems? We’re using 3d studio max.


  3. couple hundred dynamic objects (constantly moving)

    -can I constantly transform couple hundred objects on the scenegraphs without problems?


  4. simple UI (text + buttons) work without problems?


  5. particle engine

    -can I use even simplest particle effects currently?


  6. sound

    -I can use LWJGL’s sound

    -any extra using jME’s sound API’s, how finished are they?


  7. jME works “as good” as LWJGL

    -I assume if I use only “basic” features of jME, if it crashes it’s mainly easy to fix or the reason is on LWJGL?


  8. Platform support

    -I assume jME is still pure Java, no extra native bindings, so it works as many platforms as LWJGL does


  9. Issues & blockers

    -does all the basic features work with jME, like texturing, scenegraph, lighting etc.

    -does any blockers exists?





    E.g. with Xith3d I can do all these, but there are some caveats, currently the memory management is somewhat unfinished and this gives big hiccups for the GC from time to time (or one is bound to use incgc).



    Also jME is based on LWJGL which is more game oriented and somewhat better tested and widely used on games than e.g. JOGL, do you share similar feelings?





    Best Regards, Jani
1. what is the state of loaders
-can I load big environment (e.g. terrain), consisting of >10k vertices to scenegraph without problems? We're using 3d studio max.


Not currently, no. This current release is going to introduce terrain loading, but it's not implemented yet, and most likely won't be in time for the time frame you require for the contest. It will be in "soon" but I can't give any firm dates. If you need other spatial partitioning methods (BSP, Portal, etc) that won't be until the next release.

2. hundreds of static enviromental objects
-can I load hundreds of 3ds/ase objects (e.g. house, trees) to scenegraph without problems? We're using 3d studio max.


Yes, we can handle hundreds of static objects quite well. However, the 3ds/ase loading is problematic. Basically, my ASE loader is fragile, limited and unreliable. We are currently in the process of considering a new system to handle model loading, but again, it's probably not going to meet your time contraints. Milkshape and MD2 are the only two loaders I have some confidence in, but I realize the limitations of these formats. Basically, you've hit a sore spot with your first two questions. Loaders are something that jME is severly lacking and we are in the process of trying to remedy that. Hopefully, with a solid custom format that we can guarantee will work. Then a collection of converters and exporters to convert an existing model into our format. Again, this is not going to meet your time needs.

3. couple hundred dynamic objects (constantly moving)
-can I constantly transform couple hundred objects on the scenegraphs without problems?


This needs to be tested properly, but should not be a problem.

4. simple UI (text + buttons) work without problems?


Yes, current GUI capabilities support this. Perhaps, like everything else, it requires some more testing.

5. particle engine
-can I use even simplest particle effects currently?


Yes. There are enough capabilities that most simple effects (fire, smoke, fountains, rain, snow, etc) can be achieved.

6. sound
-I can use LWJGL's sound
-any extra using jME's sound API's, how finished are they?


Any sound that OpenAL can read can be used as well as WAV. MP3 support was supported, but it introduced some licensing issues with Java Layer and was removed. Sounds can be spatially located.

7. jME works "as good" as LWJGL
-I assume if I use only "basic" features of jME, if it crashes it's mainly easy to fix or the reason is on LWJGL?


Hard to say with much authority, but I'm fairly confident in most of it's aspects. We try hard to test each component and squash bugs almost as soon as they are found. I'd give this a tentative "yes", with the addition that if you bring up a bug, it will be fixed as soon as possible. My main goal is to insure the current software is stable, before adding new features. That means if a problem is found, I drop what I am doing to fix it.

8. Platform support
-I assume jME is still pure Java, no extra native bindings, so it works as many platforms as LWJGL does


jME is confirmed on Windows and Linux. It should work with Mac OS X, but do to some apparent issues with mixing LWJGL and awt (we use java's ImageIO for texture loading) textures may not appear. I have not confirmed this, or worked to resolve it.

9. Issues & blockers
-does all the basic features work with jME, like texturing, scenegraph, lighting etc.
-does any blockers exists?


Everything that is currently in the API should work and be complete. There may be a bug here and there, but overall, it should be solid. All basic features can now be said to be in. We are currently simply adding needed features, such as loaders and environments.

E.g. with Xith3d I can do all these, but there are some caveats, currently the memory management is somewhat unfinished and this gives big hiccups for the GC from time to time (or one is bound to use incgc).


We are very aware of gc issues, and have tried hard to resolve them. In fact, I can say with confidence, that core jme components do not have any serious gc issues.

Also jME is based on LWJGL which is more game oriented and somewhat better tested and widely used on games than e.g. JOGL, do you share similar feelings?


I really don't know. I would assume this is true, due to the age of LWJGL compared to JOGL. I have not used JOGL enough to compare.

I tried really hard to be as blunt and honest as possible. I would have loved to say yes to all your questions and have you use jME for your contest, but I must admit that you are most likely going to find our model loaders lacking. Mostly because I have very little experience with models and mostly wrote our current ones using tutorials off the web, which themselves were lacking in capabilities.

DarkProphet has made a simple little game using jME. It's nice because it uses all the major components of jME (scenegraph, sound, particles, etc).

Basically I’m evaluating jME against Xith for the time being. Xith’s loaders have their own caveats aswell, perhaps I should compare them more. I’m sure neither is finished yet.

"mojomonk" wrote:
1. what is the state of loaders
-can I load big environment (e.g. terrain), consisting of >10k vertices to scenegraph without problems? We're using 3d studio max.


Not currently, no. This current release is going to introduce terrain loading, but it's not implemented yet, and most likely won't be in time for the time frame you require for the contest. It will be in "soon" but I can't give any firm dates. If you need other spatial partitioning methods (BSP, Portal, etc) that won't be until the next release.

The simplest requirement is to load single big e.g. terrain.ase that has only one node consisting of bunch of vertices and normal vectors. Can this be done with current jME? Textures need to be applied to the terrain. No need for BSP, Portal.

I hope some culling however works for complex nodes (like terrain).

Is this possible?

Basically, my ASE loader is fragile, limited and unreliable. We are currently in the process of considering a new system to handle model loading, but again, it's probably not going to meet your time contraints. Milkshape and MD2 are the only two loaders I have some confidence in, but I realize the limitations of these formats. Basically, you've hit a sore spot with your first two questions.


Xith's loaders have their caveats aswell. This is a complex area and I'm content if loaders can handle simple structures (but with lot's of vertices).


We are very aware of gc issues, and have tried hard to resolve them. In fact, I can say with confidence, that core jme components do not have any serious gc issues.


I can strongly recommend Borlands OptimizeIT, although it costs big bucks. You can get 10 day evaluation version for it though.


I tried really hard to be as blunt and honest as possible.


I believe you have been as objective as you humanly can, thank you.

As an aside to this interesting, candid discussion - the prizes for the contest don’t look that great. Most of the “$50,000 in prizes” seems to be taken up by a license for the GameSpy SDK. Not as nice as cash, by any means!

still, they are offering it for free, its better than nothing.



Im going into models myself, there must be a good resource somewhere about 3ds loaders (thats easy to follow! :slight_smile: ). If not, then were did War Craft III people get their loaders from?



Im going to dig straight into jME over easter. So I can enter the competition too! :smiley:

I can strongly recommend Borlands OptimizeIT, although it costs big bucks. You can get 10 day evaluation version for it though.


That's what we've been using as well as JProbe. You'll notice very little object creation after the initial game loading (on the jME side).
"Fuseboy" wrote:
As an aside to this interesting, candid discussion - the prizes for the contest don't look that great. Most of the "$50,000 in prizes" seems to be taken up by a license for the GameSpy SDK. Not as nice as cash, by any means!

Heh, I'm sure nobody with their senses would participate this because of the cheesy prices :) I'm a bit joking here. Frankly, the prizes are what they are, I'd say most of the people are participating this just because it interest them or they would like to get more experience (or some fame) from Java gaming development.

Java gaming development is an interesting area because it's just raising it's head from the mud pool, everything is new, just like the c64, then Amiga and now PC demo scenes (10-15 years ago), individual efforts really matter. This is something that is always (again) welcome on a commercial world that we are living in :)

It's interesting to see what happens in the next few years!

Cheers, Jani!