I’m right now a C#/Java developer, and I’ve been having a great time on XNA with C#.NET.
But I want to try developing 3d on Java, as it’s portable and I haven’t yet tried OpenGL out yet.
I ran into a problem where there were many possibilities here:
- jMonkeyEngine
- Avatrix3D
- Ardor3D
- Java3D – I haven’t actually looked into heavily, it seems interesting, but i would prefer seeing what people actually say first. If this is actually what I’ve been looking for that would be awesome. The downside is that I believe the support level is very low.
I mainly looked into JME, which turned out to be more of an engine then a framework (which occurred to me through the name, though I’ve been told it wasn’t).
Basically what I would want from a specifically framerwork:
- Pretty automatic rendering (see XNA, maybe a bit more then they do but around that)
- Included vector math, what they did in JME with nodes is fine
- Preferably easy to port with the application (unlike XNA, where end user has to install .NET AND XNA)
- No unnecessary implementations of what won’t necessarily be generic: this probably requires an explanation, what I mean is that, what I hate in JME is that they already have a bunch of heavy physics implementations, such as their bullet class and simplePhysicsUpdate. They don’t always necessarily do what you want them to, and it’s not very easy to implement your own. In XNA, they leave all of that subject entirely open.
- True OOP approach. Really. In XNA I consider it to be a true OOP approach since you have ONE controller class, that contains all of the GameComponents. This is also what makes it so easy to build your own library for personal input management and such. Physics also become much simpler to handle.
Please note that I haven’t been looking at JME for a long time, so I MAY be mistaken about it. If I am, please say so, and maybe provide examples of how it can implement the things I ask for on top.
Otherwise please give me ideas unto what might be like so, that is to say a framework and not an engine.
Also, it is worth noting I’ve asked a similar question already here. This is how I wound up looking into JME. I also have looking into Java3D on my todo list.
This question is different as I ask specifically for a framework rather then an engine. (for me the difference is that an engine will try to have everything game-ready, while a framework simply makes it easier to make the actual engine that suits your needs).
Edit: after reading the 2 answers, I’m going to look into Java3D even though it seems to have very little support, since I don’t want the heaviness of JME if I’m not going to use it, and consider hacking off chunks of a product to be somewhat wrong (I mean it’s OK to do it if needed, but I would prefer looking into other solutions first). If that doesn’t work either, I’ll look into jogamp and LWJGL, possibly building my own framework from them (seems like an interesting project to do). If I don’t build it, I’ll just stick to XNA (though I will lose the possibility of installing any of my creations to the linux machine downstairs 🙁 )
A couple of thoughts, but skipping to the chase: there is no such framework for Java, you can stop looking – or be very disappointed.
XNA is a major investment from Microsoft, its scope and tooling are amazing. And no wonder: XNA is a part Microsoft’s XBox strategy AND their mobile strategy at the same time. It has plenty of resources behind it. No one on the Java side has ever made similar investment, because no major player had interest in pushing Java as a gaming platform (this might change with Android and JavaFX, but I wouldn’t hold my breath).
What we have here in Javaland – is lots of smaller libraries, communities and projects. More excitement and ideas, less maturity. Less tooling, more cross pollination. My current favorite is PlayN, which is a really cool, cross platform library that lets you build a game for Android and desktop, and then compile it to Javascript and play on any modern browser without any plugins.
As for the technical side, two notes:
I object to calling “one controller to rule them all” a true OO approach (and probably against calling anything “the true OO approach”); it certainly is a design choice that has good sides, but it has its trade-offs. There are other methods of supplying dependencies apart from sticking them into some central object.
JME is not – AFAIR – hard wired to any specific physics engine, it is built with assumption that everything should be swappable. It might be done in a different way than XNA does it, but it is good.