Game Development APIs in Java - important, please feel concerned

General Discussions
#1

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

Introduction
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.

I. Needs

  1. Maths
  • (MAT) Vector and Matrix Math library
  • (COL) Collision Detection library
  • (PHY) Physical simulation library
  1. Graphics
  • (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)
  1. Input
  • (INP) Game devices handling library
  1. Network
  • (NET) Networking library
  1. Development
  • (IDE) Integrated Development environment
  • (DAT) Data loading/saving library
  • (TST) Test suite
  • (SCR) Script language
  • (PRO) Profiler
  • (DBG) Debugger

II. Existing APIs

  1. Maths
  1. Graphics
  1. Input
  1. Network
  1. Development

III. Less known/used libraries

IV. TODO

  • 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

Conclusion
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…

#2

You missed JGN http://javagamenetworking.dev.java.net and FlyingGuns (don’t recall the url) for networking. :-p

-Matt Hicks

#3

20/02/2006 :

  • JGN and FlyingGuns added (thanks sunsett)
  • URL of all projects added
#4

You link to JMF is pointing to FengGUI.

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

Kev

#5

technically you can add lwjgl under sound and input

#6

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

And you’ve forgotten SDLJava under GFX, and both SWT and LWJGL under WIN. Although LWJGL is only a partial solution under window handling.

Cas :slight_smile:

#7

Maybe you can add :
Jirr : binding for irlicht
Ogre4j : 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.

#8

don’t we have a wiki for this? 8)

#9

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 :wink:

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.

Nevertheless I am sorry for this attitude :wink:

#10

(SCR) BeanShell (best), Groovy (not bad), Jython (supports Python)

Whats so good about bsh for making it the “best”? Its pretty much the slowest option.

Other scripting languages are: Pnuts, Jelly, TCL, JRuby, JudoScript (js), Rhino (js), ObjectScript, Yoix, Hecl and others.

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

#11

21/02/2006 :

  • JMF website URL fixed (thanks kevglass)
  • Added LWJGL under (WIN)
  • Added LWJGL under (MED) and (INP)
  • Removed commentaries about script languages.
  • Changed a bit the Intro
#12

[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:26282"]

#13

Fixed. Thanks.

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…” ;D ;D ;D 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 :-[ )

Done. Thanks.

  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.

I left SDLJava out, because I don’t think it’s sooo used. (Say, I can’t see any board on java-gaming.org about it). If I’m wrong, I’ll add it.

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 ?
Because it’s already made, Doc !

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 8) ?) We have plenty of excellent open-source wiki engines out there, let’s use them.

Anyway, making my proposition of a “website” a wiki is a good idea.

That’s right, exactly what I wanted to say.

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.

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.

I do so.

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.
About BeanShell : it was because it’s Java-syntax compatible.

#14

http://wiki.java.net/bin/view/Games ?
[/quote]
Answered. In the previous post.

#15

[quote="<MagicSpark.org [ BlueSky ]>,post:13,topic:26282"]
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.
About BeanShell : it was because it’s Java-syntax compatible.
[/quote]
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.]

#16

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 / Aviatrix3D
About (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.

#17

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.

#18

A very nice scripting language for Java games.

http://www.alice.unibo.it:8080/tuProlog/

Yes it’s prolog and it fits like a glove when working out on a system to do NPC dialog.

I think this thread should ALSO be made into a wiki article.

About Jirr, jOgre SDLjava perhaps you could link them in a section for less used/known java apis. There aren’t so much java gaming apis like that.

#19

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.

Hmm… we really have to do a poll to know the best scripting language :stuck_out_tongue:

Hmm, yeah, I’m thinking about reorganizing a bit the wiki, but I don’t know what the administrators would think of it.

#20

[quote] Don’t you agree there would be ONE best approach ?
[/quote]
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…