Reasons to recommend jME3

Hey, a bunch of folks at Slant are putting together a comparison of 3D game engines to serve as a comprehensive overview for people looking where to start with game developoment. Here’s the work-in-progress comparison:

There’s some initial info on jME3, but not a lot. Mind helping out?

Reasons my team uses jMonkey (versus Unity with C#):

  • Linux support for Developing.
  • Most Engines are missing this
  • No Costs, No Royalties, No Risks
  • Full Source
  • After working at Unity, we noticed that this is a must-have.
  • Freedom of Choice for Architecture.
  • We have our own modified Entity-Component-System synced between Client & Server. This would not be possible with Unity
  • Java is an amazing development platform:
  • Best IDEs for refactoring (and they are free!)
  • Full JDK Source
  • Great Exception Handling and Checks an Compile-Time Exceptions
  • Easy Debugging (Unity crashes often when we expect to get a StackTrace)

Cons (if you are still looking for some :P):

  • No Console Support (Xbox, PlayStation, etc)
  • No 2D Support (We used libGDX or Slick2D for 2D sprite-based projects)

I don’t agree with “Java is not as performant as possible”. Maybe the shaders are (I don’t know), but Java is not slow. The amount of calculations my team does per frame is silly but Java does not have a problem with it on slower PCs like my own :smile:


Java is not as performant as possible
Knowledge of glsl (difficult) is required to modify shaders and optimize performance for your own requirements. Included shaders can be slow


Java is not as performant as possible

This sounds like it’s writen by someone that just known java in year 2000. As usual, there are misconceptions about java being slow, but I’m tired to argue on this.
Especially funny to hear when all the top rated engines use an interpreted scripting language for the game logic…

Knowledge of glsl (difficult) is required to modify shaders and optimize performance for your own requirements

Yes you need to know glsl to modify shaders… because they are written in glsl… It’s not as difficult as one may think, it’s actually a fairly straight forward language.
That sentence alone implies that you can’t modify shaders in the other engines which sounds completely dumb. If we have that con, every engine has it… IMO it’s a pro though

Included shaders can be slow

Well at least it implies they can be fast. We’ll never know under what circonstances I guess.

If you want real cons :
The lack of manpower to have a fast and decent release cycle.
Not on par, feature wise, with commercial engines.


This sort of comparison is deeply flawed… You can split a single pro into multiple pros to increase your numbers. Also some have more value than others, but the site will treat all pros / cons equally and just sort by their count.

What DevMaster does (or at least used to do) was a lot more useful. It would have standard names for features like “Rigid Body Dynamics” or whatever, and then you can say your engine either had it or didn’t. That way you could easily compare a bunch of engines to determine if a feature you wanted was available or not.


The attack on Java no longer applies, but at some point in the past I do admit that it had many issues.

The only cons I could find is the scene composer, although useful, it still lacks some useful things that save a lot of time in coding and testing like ragdolls.

But besides that, I find JME way better than Unity as a programmer, I do more game code and less workarounds.

Thanks everyone for taking the time and answering. I’m going through everything now.

Pro/con count does not change ranking. The order is determined by recommendations. So is the content. It’s user-generated, policed and iteratively improved. Think Wikipedia.

Is there a source I can use to dispute this?

Is there maybe a benchmark that could show the real situation?

I’d really appreciate if you would make an exception in this case.

What does it imply?

Maybe the contributor meant that there are easier (maybe more high-level ways?) of editing shaders elsewhere? Also, why would you describe it as a pro?

Is there a benchmark that could be used to settle this?

Mind elaborating why? What enables you to do that?

I see DevMaster has:

  • Lighting
  • Shadows
  • Texturing
  • Shaders
  • Meshes
  • Scene Management
  • Animation
  • Terrain
  • Physics
  • Networking
  • Artificial Intelligence
  • Sound
  • Video
  • Tools & Editors
  • UI
  • Scripting
  • Input
  • Special Effects

There’s an option of doing something like that in the spec sheet, but only with objective information. DevMaster includes subjective there as well. Subjective info should be discussed in pros/cons. That would mean features only. Thoughts?

try this Common Misconceptions About Java - DZone

Well, an interpreted scripting language is by definition interpreted on the fly. usually by an interpreter that is capable of transforming the scripts instructions into machine instructions. But it suffers to some extend of what java 1.0 suffered with JIT : interpreted code is slower than compiled code. Even from code compiled to byte code like java.

So I’m not saying the other engines are slow because their game logic is done with scripting languages. What I’m saying is that most of the time, the game logic is not your performance bottleneck in a game, so it doesn’t matter if your game logic is “not as performant as it should”, because your CPU will end up waiting for your GPU.

Bottleneck in a game is most often the rendering process. The rendering process happens on the GPU, with shaders, and every single engine I know use this.
So this con “java is slow” is twice irrelevant, because first it’s wrong, java can be as fast, faster or slower, depending on the case, than C++. And second because the slight difference in performance doesn’t matter at all, because the hard work is not done by Java, nor by C++ in the other engines.

Yes there are, and we have a way too, called shader nodes. I agree it’s not yet as easy to use than ue4 or unity’s node system, but I’m working on it. This would have been a valid con if it was phrased like “Lack of proper material editor or shader compositing tool”.

What I would describe as a pro is the ability to make your own shader without the engine getting in the way or having to hack around to do so.

Nope, we have no benchmark, and I’m not saying this con is wrong, I’m just saying that it’s based on wind. And unless someone has made a proper benchmark, I was pointing that we could have a pro based on the same wind saying “provided shaders can be fast”.


I know one of the things that really interested me when I started using JME again like 4 years ago was how easy it was to jump into GLSL. It took me like 10 minutes to have a simple app up and running where I could test my own shaders and only like 10 minutes more to understand the small “JME” specific parts.

I was hacking my own shaders in about 30 minutes… which is a lot better than old 2006 JME and much better than the C++ engine I’d used before that. (I never did figure out how to set that one up myself and always cut-pasted another project first.)

So to me it’s a huge “pro” that if you know a little about GLSL already (a standard) you can go from shader books to playing around really quickly with JME3. JME mostly stays out of the way here.

1 Like

I can’t find the source that listed problems of java in the past that I totally agree on, but many of teh attacks now lie on many fallacies and this article explains about some of them.

Unity uses a behavioral “script” architecture for your game code. This means that you have a base class that you extend and you have access to an incredible set of features of the engine or your objects in scene. This makes it incredibly useful when you want to prototype games or make simple ones because you simply place objects on scene, create scripts and attach them to the objects and you’re set. Unity encourages this.

However, as you begin to add complexity to your game code, Unity will eventually start fighting back. Unity uses a simplified version of Mono that does not have the latest features of a more recent version of Mono (sometimes incompatible) or what you could expect from regular .NET. If you reach this you have to start writing your own version of the feature either with c# or most likely by making a native plugin (c++, Obj-c or Java) to compensate for the missing feature.

An Unity programmer is “forced” to trust Unity in the execution of the engine components, even though they may go against your code and you have to rewrite it to avoid that clash. Another fact is that besides threading you have co-routines to make asynchronous code execution while remaining on the main thread but unfortunately there is no exception catching by default so when it fails you don’t know why nor where. You either debug in Mono Develop or Visual Studio or write a co-routine handler that will do that for you or print in console for you to read and start playing detective.

Other issue that I found is that by default Unity uses MonoDevelop to write the code. This enables you to debug your code but the debugging features is incredibly behind something like Visual C# that only runs on windows and the fact that you may experience crashes without any known reason (specially when you have a bunch of scripts). So you resort to write in code text editors (Notepad++, Komodo Edit. etc) to write the code and then go to unity to wait for the building of the scripts before testing in engine and to debug and go to the good old reliable console logging in the process.


Alright, thanks for all the info. I’ll see about improving the comparison. Thanks.