Here's a quick report of the situation (3-characters ID between parenthesis are used to quickly reference a need) :

[size=20pt]Introduction[/size]Java Game development is growing more every day. Even if commercial projects are made with, the majority of the coding efforts are open-sourced. This is great, but I think we should have a bit more organization.I'm doing a summary of all the projects I've seen in my rather modest career. This is why I left out some APIs I don't know, and some I don't find really useful. However, don't mind posting constructive criticism.

[size=20pt]I. Needs[/size]

[size=14pt]1. Maths[/size]

(MAT) Vector and Matrix Math library

(COL) Collision Detection library

(PHY) Physical simulation library

[size=14pt]2. Graphics[/size]

(WIN) Window handling library

(GFX) Low-level graphic library working on top of (WIN)

(SCG) High-level scenegraph based on (GFX)

(FMT) Graphic files loading library

(FRM) Frame-based animation library

(SKE) Skeletal animation library

(GUI) Game User Interface library based on (GFX)

(MED) Video and audio streaming library working on top of (WIN)

[size=14pt]3. Input[/size]

(INP) Game devices handling library

[size=14pt]4. Network[/size]

(NET) Networking library

[size=14pt]5. Development[/size]

(IDE) Integrated Development environment

(DAT) Data loading/saving library

(TST) Test suite

(SCR) Script language

(PRO) Profiler

(DBG) Debugger

[size=20pt]II. Existing APIs[/size]

[size=14pt]1. Maths[/size]

(MAT) Vecmath (missing some functionalities) / JAMA (needs to be included in Vecmath)

Set up a JavaGames website (in addition to the forum) to coordinate the efforts

Put this report on the website

Be sure each named project has a page on dev.java.net

Make these pages clean, clear, concise, and write roadmaps

Verify each project license (LGPL or BSD, in order to be able to make open-source projects / freewares / commercial projects)

Write specifications for (FMT), (FRM), (SKE), and (COL)

Separate (FMT), (FRM), (SKE) from various (SCG) (take the best out of all libs)

Separate (COL) from (PHY)

Merge Vecmath and JAMA if necessary, and implement missing functionalities in the resulting lib

Merge (SCG) if possible. If not, make a new library made by all developers of the previous projects. If there are really different needs, make two or more libraries, but anyway, try to avoid fragmentation

[size=20pt]Conclusion[/size]Please tell me what do you think of it, which needs I missed, if you find the idea of a javagaming website useful, and other thoughts about merging libraries...

I think you miss his point. The summary above is just a starting point for MargicSparks hope of a discussion for more collaboration/merger inside the java gaming community. I have followed his posts, so I can say, this is not the first attempt in this direction ;-)

Unfortunatly I think MagicSpark misses a point, too. There is just no interest in a merger of any of the above frameworks. It's more an ego thing like "my library is better than yours... at least it's _my_ library". To honest, I would/will act the same, since it's more of an hobby for me (and others on this board). The only chance I see is simply to start merge and reorganize code in a new source tree, for projects where the licences allow forks, hoping that some of the core developers jump on the bandwagon once it's rolling.

This is a major undertaking and I would be surprised to see this happen.

I think last time you posted something like this I ranted on at you so I'll just refrain from commenting this time.

Hell, I just can't say anything and people think : "Hey it's the guy who, one day, wanted to make a fusion of all existing middlewares... He will never understand.. Ahh.. Damn newbies.." Anyway, thanks not to rant on at me one more time.Please not that _i don't want anymore to make a big fusion_. This is just stupid. But I had to crash me by myself before being convinced of that. (Gamma has been stopped months ago )

Bit of a strange mish-mash there, not sure really why you're listing it all and needing to coordinate it ...?

1. To make a summary of the existing libs, even if it's useful only for me.2. And to collect advice from the guys who made wonder with Java, unlike me.In fact, I had this motivation since I looked at the JSR I can't remember the number that was talking about a "Game Development Profile" and was listing 9 development areas. This JSR have been withdrawn.. But it's still actual I think.

Maybe you can add :Jirr : binding for irlichtOgre4j : binding for Ogre3D

And a reader of one of my article on Developpez.net emailed and made me know VTK (a powerful scenograph) and its binding for Java.

Hmm.. thanks InfoRital for pointing this out, but.. I just don't know where it could fit. They are not widely used as far as I know. I think they're not going in the good direction.. Jirr and Ogre4j are feasible in Java with only JOGL and JOAL as dependencies. So why make a JNI binding of all the rest ?[size=8pt]Because it's already made, Doc ![/size]

Oh, that's right. I didn't event know there was one...I took a look at it, but here are some of my thoughts about it :

It's not sufficiently known (just make a poll)

It's a bit disorganized, and lack of content

CollabNet may be a great piece of work, it sucks for forums & wikis (IMHO. Think about it. Why javagaming forum isn't on dev.java.net ?) We have plenty of excellent open-source wiki engines out there, let's use them.

I think you miss his point. The summary above is just a starting point for MargicSparks hope of a discussion for more collaboration/merger inside the java gaming community. I have followed his posts, so I can say, this is not the first attempt in this direction ;-)

Unfortunatly I think MagicSpark misses a point, too. There is just no interest in a merger of any of the above frameworks. It's more an ego thing like "my library is better than yours... at least it's _my_ library". To honest, I would/will act the same, since it's more of an hobby for me (and others on this board).

Hmm... You mean the project leads won't start a collaborating effort ? That may be right.. And yes indeed the ego thing is something really strong in the programmer's heart. And I would/will act the same, too. (Actually I'm doing that with Xith3D and JOODE, making the war against Java3D, jME, and ODEJava..).But aside from this fact, there's several interests in merging _some_ libraries :

Fragmentation. What is it ? Basically two facts. You can't choose between existing libs, because you don't really need all they do, but none of them fulfil exactly your needs. And different programmers do several times the same work, probably falling in the same pitfalls...

Maintenance and Support : We have a much larger user-base when we have one lib for one need.

The only chance I see is simply to start merge and reorganize code in a new source tree, for projects where the licences allow forks, hoping that some of the core developers jump on the bandwagon once it's rolling.

Maybe yes, maybe no. I agree sometime starting to work on your own is the best way to go, as others can see that your idea works indeed and they go with you.. But we will probably end up with _another_ dead fork.

While its not a scripting language Janino can be used for scripting, too.

Okay I must admit I have almost no experience in scripting languages and my commentaries were based on things I've read on this forum. Now I didn't added the whole list, cause I don't think it's useful. But if best suited script languages for games aren't the three I named, please tell me, and I'll change it.[size=8pt]About BeanShell : it was because it's Java-syntax compatible.[/size]

[...]Okay I must admit I have almost no experience in scripting languages and my commentaries were based on things I've read on this forum. Now I didn't added the whole list, cause I don't think it's useful. But if best suited script languages for games aren't the three I named, please tell me, and I'll change it.[size=8pt]About BeanShell : it was because it's Java-syntax compatible.[/size]

Well, I havent tried em all. But I think pnuts is pretty nice, too. And I'm using janino alot for scripting (again). [Janino is a very fast on-the-fly compiler.]

Okay, something concrete now. Having Java3D and Xith3D side by side is a bit redundant, since

Xith3D was a fork of Java3D when it died. It was developed by David Yazel for his game, Magicosm

David has retired of development. William Denniss took the succession, but the development isn't as active as it used to be.

Java3D was bring back to live by the community

So we have 2 APIs with the same design, and pretty much the same functionalities, except that Xith3D handle Sound & Collision Detection. I think it would be better to merge the codebases and make a better work together. Say, I don't want to put jME in the game, because it's too diferent from J3D and X3D. So we would have basically three APIs for (SCG) : Java3D-Xith3D / jME / Aviatrix3DAbout (FMT), (FRM), and (SKE) I think this is a task that can implemented in a generic manner so all (SCG) can handle them. That would save us a lot of work time. But to achieve this goal we have to define open standards, then implement them.

There are some fairly big differences between Java3D and Xith as I understand it, as far as the internal architecture of the two APIs is concerned, more or less based on what they are for- Xith is designed for games writing so it loses some of the more good practice/thread safety type features in favour of performance. They are similar to write to, but I think they act quite differently in use.

There are some fairly big differences between Java3D and Xith as I understand it, as far as the internal architecture of the two APIs is concerned, more or less based on what they are for- Xith is designed for games writing so it loses some of the more good practice/thread safety type features in favour of performance. They are similar to write to, but I think they act quite differently in use.

Mmhh.. yes maybe, but actually what I worry about is the following : Imagine I want to make a game, I have a wonderful idea. Okay I write a Design Document, and find some talent people, and among them one or more programmers. I really don't care if they libraries they use are thread-safe or not ! As long as they do their job, I'm happy with that. Now I'm not a game designer (not yet). I do game programming in my spare time, just for fun. Sometime people ask me "which library/scenegraph should I use ?". And I just don't know what to answer them ! I may say :

Well, use Xith3D. It'll be fine. At least, I'm using it and I can probably give you advice

or,

Err.. you should use jME it seems simpler for beginners

or,

Hmm.. Java3D proven to be the faster scenegraph at the last benchmark in date.. you will probably be happy with it.

That's not a good situation I think.. Don't you agree there would be ONE best approach ? Or do you have to chose one lib, to what you can do with it, and throw out the others ?I think you can do one scenegraph that fulfil everybody needs (in graphic game programming), don't you think ? If you make it in a really modular lib where one can reimplement which part you want.. so you can privilegiate speed, or clearness, etc.

I know how to use J3D, to some degree and that is good but I am glad that if I did run into something unsurmountable when I was trying to develop something with it I would like to be able to switch to another API that fits my needs better. I don't agree that a single scenegraph can do everything I want it to or if one can then it could be so abstract or so huge as to be impractical.

I'm not one of these far right free market nutters that seem to be about 80% of the internet, but I think that choice is important. It is good to be able to explain the similarities or differences between APIs and let potential users decide for themselves. I realise that some people may find that offputting, but my counter to that would be that if someone is too dense to choose a 3d api they are clearly going to be unable to get to grips with 3d programming so it's no real loss...

I would challenge anyone to find any significant reason to use Java3D or Xith3D over jME. It has been my experience recently that jME has FAR surpassed that of any of its competition. I have been wrong before.....I'll wait for the oohs and awws to quiet down....but if I am wrong I'd love to get some reasoning as to why. :-p

I would challenge anyone to find any significant reason to use Java3D or Xith3D over jME. It has been my experience recently that jME has FAR surpassed that of any of its competition. I have been wrong before.....I'll wait for the oohs and awws to quiet down....but if I am wrong I'd love to get some reasoning as to why. :-p

-Matt Hicks

I deslike jME because there are a lot of tutorials but no concise user and dev manual for the engine.

I know how to use J3D, to some degree and that is good but I am glad that if I did run into something unsurmountable when I was trying to develop something with it I would like to be able to switch to another API that fits my needs better. I don't agree that a single scenegraph can do everything I want it to or if one can then it could be so abstract or so huge as to be impractical.

Hmmm... I'm not so sure.. Huge ? Not if you split parts in different jars and if they're not inter-dependant (except of the core).

I would challenge anyone to find any significant reason to use Java3D or Xith3D over jME. It has been my experience recently that jME has FAR surpassed that of any of its competition. I have been wrong before.....I'll wait for the oohs and awws to quiet down....but if I am wrong I'd love to get some reasoning as to why. :-p

-Matt Hicks

Hmm... you may be right, but anyways it's a lovely way to fall into a heavy flame war.

I would challenge anyone to find any significant reason to use Java3D or Xith3D over jME. It has been my experience recently that jME has FAR surpassed that of any of its competition. I have been wrong before.....I'll wait for the oohs and awws to quiet down....but if I am wrong I'd love to get some reasoning as to why. :-p

-Matt Hicks

I deslike jME because there are a lot of tutorials but no concise user and dev manual for the engine.

That's not very important and can be easily fixed. If sunsett says the true, and if this is the only reason why not to use jME, then jME can easily be the best scenegraph.

So you have a problem with tutorials, hundreds of tests, terminology guides, a user updatable wiki, a forum that has more activity than any other open-source project I've ever seen, etc. all freely available and you don't have read some lame guide or search a crappy mailing list to find your answers.....I see your point....maybe I should switch to Xith so I can have an under-developed, under-active project that I can run instead.

*gosh I love ranting run-on sentences*

I meant all that in the best light possible...no offense intended of course.

So you have a problem with tutorials, hundreds of tests, terminology guides, a user updatable wiki, a forum that has more activity than any other open-source project I've ever seen, etc. all freely available and you don't have read some lame guide or search a crappy mailing list to find your answers.....I see your point....maybe I should switch to Xith so I can have an under-developed, under-active project that I can run instead.

*gosh I love ranting run-on sentences*

I meant all that in the best light possible...no offense intended of course.

-Matt Hicks

Yes a good user and devs manual would save a lot of time. Browsing trough endless mailing lists, unrelated tutorials and forum posts is not a good solution to find information quickly. Don't overlook good api documnetation and good user/dev manuals.

I still remenber the hours of wasted time i spent with swing trying to figure out why my code wasn't working because a mistake in the api docs of the swing list jcomponent. In the version of swing version i used a list index value is converted internaly and silently into a short and then back into an int causing hard to find bugs.

Consider something like good dicumentation that let's you find info fast and without mistakes an advantage just like having a engine with many features and fatser than others. In other words stop thinking like a geek in your own world and think about other peoples worlds. Im not posting this in any malicious or offensive way by the way.

I would challenge anyone to find any significant reason to use Java3D or Xith3D over jME.

I know how to use Java3D already.

I have no idea how the performance compares, and I'm very open to changing over if it ever becomes a problem, but right now J3d does all I need and it doesn't come with the overhead of needing to learn a new API.

zingbat, hehe, I agree there is some benefit to a manual, but the problem with that and jME is that jME is so consistently being added to that it would have to be frequently kept up to date...I know that's not much of a problem with Xith.

I think that jME is making strides that direction by providing the wiki that allows the users to keep it up to date.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org