jMonkeyEngine v3.3.0-stable released

Most JME developers don’t use the SDK. It has half of a person working on (maybe less than half). Even with a whole team of folks we will never make it comparable with Unity. It’s not our goal and it’s impossible.

…so for the good of the ENGINE, we cut it loose. Maybe our mistake was not just deleting it completely. libgdx seems to get along without an SDK, I guess.

This is an impossible goal, really. Those folks are already well served by Unity. If I wasn’t a Java developer, I’d be using Unity or Unreal, too.

In the end, when you jump on a tandem bike and complain about it going too slow… the other folks riding the bike are just going to ask you to start pedaling. This is a 100% volunteer project.

So in the end, I’m sorry that I’m not spending my own free time in the way that you prefer.


I dont think it is an impossible goal, if the SDK worked. Not everyone wants to develop in c#. I personally prefer Java and that’s why I started with JME. A lot less people want to develop a game engine. Most people want to build games witha a game engine. I accept you want to keep building it rather than produce a product. It’s completely a programmers way of looking at it. I have a team who think that nothing is ever finished and needs to be tweaked more and more and if I didn’t stop them we would never get any releases on the market and go out of business.
Ultimately, you must want to produce a product that can be used to build games not just develop it forever. Unity wasnt even a thng when JME first started but JME has been ‘work in progress’ for so long that it’s been left behind. That’s the real shame of the whole thing. Too much tweaking and not enough goal oriented thinking. Anyway, I appolgise if I came on strong, and I accept everything you are saying.

Until we can hire a team the size of Unity’s, I guess we’ll just have to target other failures like libgdx.

The engine works. You can develop games with it very easily. Only takes a minute to get started… if you already are a Java developer. The engine is our “product”.

Most of us just want to write games and not work on an SDK. You know someone like that, too… you see him everyday.


Just as a matter of interest. Can you tell me why you made the decision to move away from the SDK?
It seems like a strange decision? The netbeans licensing model allows you to rebadge it. Why stop doing that?
How many people would buy a Mercedes if they suddenly decided to say “Sorry it’s flatpacked now, you have to put it together yourself. Here’s the box with all the parts and here’s a screwdriveer, knock youself out”

That seems to be from my perspective what you did?

I would very much like a fully working SDK. As a result of not paying anyone though, I have zero control over what people work on. I can demand and argue and shout from the rooftops, but people will just work on whatever it is that interests them. All I can do is be grateful for the fact that they do contribute without pay.

I also understand that sometimes money is required - and I’ve set up a patreon page, software store and a new front end website - for free - so that funding can contribute toward improvements. Currently it pays for all of our online costs - and barely that - but it’s keeping JME alive. Hopefully in the future it will be large enough that we can fund bug bounties and even feature requests.

Again though - I am only one man - and I would very much love a graphic designer and social media expert to help. But again it’s without pay.

It’s extremely difficult to keep an engine running given our situation. Lots of people talk the talk, only a very few actually contribute and create the things they feel are lacking. I accept that. I also accept that money talks. So we have two options pushing us forward here. And two options for everyone to contribute.

I understand your frustration. I feel the same in many respects. But there is only so much a handful of “doers” can do, and only so much a small funding pool can pay for.

If there’s anything you can do to improve our situation other than pointing out what we already know - please do that thing. We could really do with it.

1 Like

I can help with iOS if you like. I did put a doc together on building on iOS and that is around on here somewhere.
I also tried helping a few people by answering their questions but I gave up on that because they just didn’t read my answers properly.
What is the best way to contibute with iOS then? That seems to be an area that not many are working on.

B e c a u s e t y p i n g i n a n I D E fe el s l i k e this to m e.

And because “gradle run” takes 5 seconds where the SDK takes 30+ seconds minimum on the same project properly configured to work around the 20 year old netbeans incremental compiler bugs. ANT is super super ancient by now. State of the art 20 years ago.

Because I don’t have to micro manage every jar file I want to use and all of their dependencies. Add the dependency to my build.gradle file and it sucks down what it needs.

When I develop with my preferred tools, I have no problem working on 15 different projects at once (that is not an exaggeration). Everything is fast, etc…

It’s no contest FOR ME. Everyone will have a different perspective but the SDK provides 0 value for me, personally. I haven’t even had a version of it installed for more than 5 years.

ok fair enough. I just like the way the SDK does the desktop, iOS and Android build all in one go.

Probably the best way to contribute is to write a topic for each issue, and the solution outlined.

You will more than likely get a lot of discussion on its implementation for the general public. A personal project is different than a public release and will attract a lot of scrutiny. Just try to accept it as learning instead of being ridiculed and keep pushing forward.

It would be awesome to get some iOS love.


fair play. ill see what I can do.

As for people not listening - hah! Welcome to the daily life of any support service. It’s character building. Just remain calm and try to understand why they don’t get it.

With the proper support, a gradle build would do that, too… and could even package and upload it to your servers, generate patch files, etc… sky is the limit really.

For desktop applications, this can already be done with some configuring. More templates would be nice, though.

@GTWhite sorry i dont want read all of this wall of text, but mainly i understand your problem:

Why do you even use SDK?

you dont need to. Well im not sure about android, since it need android studio, but you can use ANY IDE you like.

SDK is good for small game development, since many tools do not allow advanced usage, so advanced usage must be done out of SDK.

You can use gradle in SDK, and Ant for assets project(since SDK see(can edit) only assets in Ant project)

if you really work 30 years, you should know there is JMEC project/etc so you can do everything without SDK if this is so much problematic. Well myself i use SDK only to 2 things trully. I agree SDK is unstable, but Engine is Stable. Had many issues with SDK, even with scene graph editing/etc. But i used to know that cant rely on SDK too much. its not Unity where you click everything and dont know backend of it, here you have control over code, so you code everything.

If you use gradle, you should also know that you can use it anywhere. Also you might know there are 2 types of SDK there (did you know?).

so generally i really dont see why you are so much about SDK.
If you are pro coder, you will know that you dont really need use it.

I agree SDK is not best, but i hope it will work properly in time. New SDK as i know gonna have gradle support by default not ANT, but it take time, need wait.

about ios support, you are correct, but there are reasons.

1 Like

He’s not wrong to like the push-button convenience.

It’s just that when any one of the 1000 things that can go wrong DO go wrong, you are left with nowhere to go.

Edit: in the end, I prefer a little less magic.

Indeed, a Gradle template for all supported platforms would be very good. Similar to what LibGdx is doing.


I know what you mean and you all make good points. I do like the “proper coder” comment though. Makes me chuckle. That’s such a programmer thing to say too! :slight_smile: I’ve rarely heard a programmer say, “His code was amazing and definitely the best way to do it”
I think my underlying point, is that you shouldnt rule out newbies because its the best way to grow the community. That’s what a fully working seemless SDK does.
For example, it’s no accident that Microsoft provide enterprise developer tools free to universitys because once the newbie is hooked on a particular tool, then it’s a while before they move to something completely different (if ever). Students get the entire Office 365 free suite to use for the same reason. If you go into any industry, which would you say is the standard spreadsheet or word processor of choice. Excel and Word of course. I’m talking in business not at home. That’s a fact. There are lots of free alternatives now but it’s not always been that way and even now, they always lack something feature wise.

The way it is now, a non-Java developer creates a project. Drags a few of the objects in. Tries to create a second class because they’ve heard they’re supposed to not put everything in one giant .java file… then they get NPEs, etc… and either give up or come here. When the SDK was more popular, 60-70% of our forum traffic was exactly these folks totally lost for even basic Java coding skills.

There is a giant gap on the learning curve for “newbies” and it cannot be filled be less than a Unity-sized paid development team. One could argue that they’ve barely succeeded at it but they are close.

To go from dragging things around in the SDK to making an actual game is essentially impossible with the SDK (unless you already know Java/coding). And really, folks who want to write games without knowing how to program should absolutely be using Unity.

I’ll say it again, if I were not a Java developer, I’d probably be using Unity, too. JME’s major selling point is being a game engine for Java developers. We don’t really need an SDK for that.


Yes you are correct, but you are missing 3 points:

  • This is Open Source Free New BSD project, not like Unity.
    So it do not have enough devs to support Great SDK support.
    If you want great support, look at JME Patreon page, where @jayfella Said(and its not much more than current amount), he will PAY DEVS TO FIX BUGS/ETC since some amount of patreon. So if you really want it, you should [pay / wait if current devs fix / or fix yourself].
    But it will still not be enough money anyway. Patreon was added recently, and it all depends on Jay how he will distribute it trully.

  • JME is not “click everything” llke i said, so SDK should anyway be only “Help tools for devs”. Myself i thought to get rid of Netbeans and JME to provide just toolset like JMEC/etc tools in single app that you run along any IDE you could use. Because really, JME is for coders, you are right, newbies are not real coders, they learn, many people come here and they learn Java(while they should already know it). This require some knowledge of Java, while in Unity, many things you can just click, you dont need code, so newbies can break only code that they write, not the one that they “click”.
    OFC it would be nice if SDK would be better, but in case of JME, its not required, because like many will say, JME is for coders. See for example Skyrim/Witcher/Bannerlord(recent game)/X4/etc games. they use own engines, they dont use Unity or others, because they want to have full control over engine. They could use even JME as base engine to extend it, but i belive problem is that here is no console support and rely on Indie Game market more than AAA market. But what i mean is that you are right “Unity allow simple game to be done faster with click”, but thereare also some issues. When you just click, you dont have full control over what its doing, if something break there, you can do like nothing, while in JME you can even compile Engine yourself and fix it yourself. Both have advantages and disadvantages.

  • Also please note in JME you have freedom to use what you need, for example i need Recast4Java, i use it, or i need own ECS, i use it, well in Unreal Engine you can also use own ECS, but by default there is build-in ECS to use, and it might conflict with yours. So as you can see its not that easy, if you would want JME SDK like other engines, it would require “LESS FREEDOM” and stick only with some libs, only 1 gui, only 1 navmesh, only 1 etc so SDK will use this strictly.
    So to make SDK seamless great tool with many things clickable, it need choose “ONE TRUE LIBS THAT EVERYONE NEED USE”. Ok, maybe im wrong, because like i said, usually you can use alternatives there too, but i just mean for example Unity SDK will not support external lib you choose, or will it?

Lets say you want use: Releases · bulletphysics/bullet3 · GitHub
for physics.

Will Unity SDK support it by “click and done”? NO, because you dont have much choice. even if you can, SDK will not support “click panels” for this libs.

So when you will now think that “JME freedom allow use any LIB”(if you know JNI you can use C libs too), so SDK click-tools for some libs is like limiting this freedom, you got what i mean? it could support more of them, but it refer to point 1 about money then.

When some people do very big projects, they care about “maintenance” that could be marked as point 4 here, since maintenance is important in projects.(i refer here to JME devs ofc)

1 Like

I hear you. Especially about the money. Call of duty for example, is not my kind of game (FPS) so to me it just looks like every new incarnations is simply new maps, new vehicles and new weapons but it still costs £200 million and take 1000 man years to make. I know what you mean.