What killed it? Well, I usually blame a lack of art, but I'm not sure that's it. I think it's the point where I can start adding art, but I realize that to get anything actually useful, I have to add more art than I'm able to make myself. And I'm not independently wealthy, so I can't pay others to do my bidding for me. And I don't think my project is sexy enough to find an artist willing to work with me.
Meanwhile, I've been brushing up my l33t Java skilz. Last i did it, it was version 1.1, back in 1996 or so. I was lead for the team building one of the first true-threaded Java VMs back then (for BeOS). However, the Java environment has come a good way since then. It even has nice IDEs, like NetBeans or Eclipse. I've done some simple J2ME stuff for my cell phone in NetBeans before, but I prefer Eclipse after having used it for a while now.
I started using the jMonkeyEngine, as a way to jump in and get something done. However, I've reached the classic impasse that I get to with most of the free or cheap game/graphics engines I look at: the art path isn't very robust. In fact, the only way to get skinned animated characters out of 3ds Max and into jME is to use a Collada converter, that only understands a dialect of Collada that is exported by a MaxScript that is written and available only to NCSoft people.
I did my part: I wrote a new ASE file importer, that supports multiple meshes/nodes, and multiple materials, and animation -- neither of those options were supported by the ASE importer that comes with jME. You can find it on code.google.com if you want. I also looked at a number of other packages, including jmephysics2/odejava, and ran into various roadblocks. However, I'd like to stay for a little moment longer on jMonkeyEngine.
I found some code in the jME that I, honestly, feel was so bad it should go on www.thedailywtf.org. It was a matrix transpose routine, that didn't do a transpose at all; it created an identity matrix with a few (but not many) of the original matrix elements moved over. Finding this bug took me two full evenings of debugging, where I thought my ASE exporter was doing something wrong (it wasn't). However, apparently the community didn't agree that the code was so bad that it deserved to be laughed at by others, and in the end I had to realize I'd overstepped what's acceptable for the community, and apologize.
However, that brings me to another pet peeve of mine. The first is "art paths in low-cost game engines." The second, which I'll refer to here, is "amateurs and programming." There are people who may have spent three or four years doing programming, and maybe even graduated college, who believe that they are worthy programmers. In fact, that kind of people, I find, are most of the people contributing to open source projects. The problem with that, is that it takes at least 10 years of programming to make a grown-up professional programmer. Most of the code you find in open source projects ranges from "atrocious" to "cutsey." A great article about this phenomenon is Pounding a Nail: Old Shoe or Glass Bottle? by Alex Papadimoulis. I realize I'll probably sound elitist to some people, but then, so does anyone rejecting sub-par candidates at a job interview.
There are, of course, some great counter-examples, like the Linux kernel, or the Apache web server, or the GCC compiler. Those projects have managed to attract people with real experience, real talent, and managed to keep the code up to standards. I think a large part of it is that those projects have had strong supervision, where patches to the code have not been accepted until vetted by someone who actually has both experience, and a vision for the project. Most open source projects (and I mean 99% here) lack at least one of those four things (leader, with experience, and vision, and contributors submitting patches).
So, jME is one of the best supported Java open source 3D game engines. I'll agree with that. The other contenders might be Xith.org, and java3d, and the folks over at Multiverse (who are wrapping the C++ Ogre3D engine). However, it has a number of design defects that, in my opinion, would make it very hard to work with. In no particular order:
- No working animated skinned character art path from 3ds Max
- No support for interleaved vertex arrays
- No support for multiple batches/materials out of the same vertex array
- Special "shared mesh" delegating object needed to avoid duplicating vertex array data
- Physics mesh objects duplicate the mesh data per object instance
- Colors are stored as 4 floats per vertex
- Inherits material state through the spatial transformation graph
- No Matrix4f getters and setters for transforms
- Un-thread-safe "StandardGame" base class, with no clear termination mechanism
These are the most annoying design problems I've found. There were (and are) also numerous bugs, some of which I've found, fixed, and submitted patches for. However, taken together, I don't think this is a great game engine, Java or no, free or no. C4, for example, would be a better engine. Ogre3D as well, except it's only/mostly rendering.
Can you deliver a game on top of jME? I believe you can. Especially if you don't worry too much about corner cases, or performance. The people doing Bang! Howdy seems to have delivered on jME. However, the fact that they succeeded may have more to do with those people, than with jME itself.
Alright, end griping. There exist people who think jME is a fine engine, and there exist people who think that beggars can't be choosers. Time for me to shut up for now.
