Unity is losing users!

Hey folks,
I found that Unity recently changed charging plans and many Indies and Teams are so upset that they are willing to change to another engine in this between Godot turned out to be a destination, but what about us?
Just saying, you know, Maybe we can use this opportunity and let those indies and teams have a look into JME?!


The only thing harder than converting a Java developer to C++ is converting a C++ developer to Java.


So true.

I have found C# devs more stubborn than C++ ones to convert to Java

Yes, They Are Very Used To Visual Basic Style Capitalization And So Find The Switch Very Difficult.

…but I lump C# and C++ together these days since the line is blurry.

1 Like

But they are used to hardships… What they wrote today doesn’t work tomorrow. It was a wild ride being a .NET developer, in less than 6 years I experienced .NET Framework → .NET something → .NET CORE. There was always need to move on, 3 years of support was max. I guess it has stabilized now as they finally know what they want. This is for a .NET developer.

Of course if they just used C# in Unity they didn’t have to battle with these .NET stuff and probably don’t need to use the date/time libraries (DateOnly, TimeOnly…) or other inconsistent stuff in .NET. C# did however evolve much faster than Java. It was really hard to keep up with all the language changes pouring in what felt like weekly updates. This is both good and bad and maybe tells more about me than the language itself :smiley:


I think that jme does not offer the editor capabilities to even compete with engines like unity/godot. Sure there are tools available for most tasks, but they are not polished to a degree where beginners can easily use them. Nor are they collected and usable in a single editor.

As a programmer this is fine, since you can get a prototype done without most of the editorial benefits.

As a non programmer you basically cannot do much before you learn to code.

I would be pleased if somebody proofes me wrong and produces something playable in any of the editors available.

To be clear, i know that for most tasks it would be possible to do it, but it is not a staightforward user experience as in the big players.


I think it probably is true that the design philosophies are different. JME is code first, but also has UI based tools. Whereas unity is UI based tools first but you can also write code.

For me personally thats what attracted me to JMonkey. I want to write code, i dont want to drag and drop. So i wouldnt say JMonkey can’t compete, but i would agree that it’s not for exactly the same market.


Thats what i wanted to say. I too like the code first philosophy. Fast for prototyping but in the same time, i think it is way harder to polish the result.

With compete i was referring attracting prior unity users

1 Like

FWIW, I think it has been a few years now since we launched JME Open Collective, and currently, we have a 4,100.65 USD balance available on Open Collective with an estimated annual budget of 1,054.62 USD, and seems our hosting expenses are 6.87 USD per month (from the open collective logs).


Do we have any plan for how that budget could be managed to improve the engine?



I feel like this was already a separate topic. Relatively recent, even.


I think it’s time to propose to Unity’s CEO to charge per game frame instead of per install! (Just kidding)

1 Like

And if we could attract more people we can raise that 4,100.65
Since Godot recently got massive donations and it was because of Unity bad plans (if I’m right)
I don’t think that’s going to be any problem C# and Java, C++ well I have experience with all three of them but mostly Java and Cpp and never felt problem by using both java and cpp i like both they are suited in different ways something i always felt is… I can say in C++ you can be more concentrated on actual problem rather than thinking how to use OOP, Since java is a Strict oop language and your mind kinda forced to think this way.
it’s not only JME that has no top noch editor, also godot editor is not that good, there are other opensources same as, Panda3d, Wicked Engine, …
What I’m saying is good time to attract those users I think that slay the spire team also moving from Unity
check here for more,
JME has lots of good things to offer, and also thirsty for more devs, more donations, more in eyes, you know just saying maybe good time to do some show off.

1 Like

I think that jme does not offer the editor capabilities to even compete with engines like unity/godot. Sure there are tools available for most tasks, but they are not polished to a degree where beginners can easily use them. Nor are they collected and usable in a single editor.

And if we could attract more people we can raise that 4,100.65

A potential corporate sponsor would be somebody like JetBrains. Especially / only if the tooling were built in IntelliJ and encouraged Kotlin use…

There are so many community tools for JME, but for a newbie / casual tinkerer like me it can be quite off putting to figure out what they all are, rather than everything being in one SDK package. For really widespread, mainstream adoption, JME really needs a complete SDK experience like Unity and Godot have.

But the work involved in making a new, unified SDK toolset is huge. And I’ve definitely fallen into the trap of spending too much time tinkering with tooling rather than working on games / learning JME itself…

For fun and profit more fun, I started porting the work I did for the Gradle Project wizard in the SDK to an IntelliJ plugin to see if it would be a potential good base for tooling going forwards.

I’ve found working on IntelliJ didn’t really match my way of working, as the workflow there is to look through code examples of other plugins / IntelliJ itself to figure out what is going on, compared to working on Netbeans where I can just read a Javadoc of the relevant API and have an idea what I want to do before I write a line of code…

Anyways, here’s a little screenshot of what little progress I made…


The one thing that everyone is missing if “PLATFORMS” even Godot doesn’t really offer all the platforms. How you going to get it on Xbox, PS, Switch. That arena is huge. I can see the small indy that only make mobile and PC games switching but everyone that thinks of possible consoles are stuck.

I know there is a 3rd party Godot 3.5 compiler to compile to those consoles, but it is not built in. So therefore it falls behind, I don’t think it supports 4.0 or 4.1 as of right now.

JMonkey has these issues for other device support also with editors, most of the editors are 3rd party external and do not keep up with changes and not part of the engine and/or SDK and so they fall apart. It would need these options.

Like Particles, there is one in the engine but is not supported, most people use the external 3rd party to handle particles. It is not part of the engine, and the engine has one. The editor is another 3rd party for designing particles.

Some of these editors is not about “NOT CODING” is about speeding up build process. Having something to quickly look at your particles and make changes, without doing it in the code is better and faster. It is not about not writing but about being able to produce faster.

Also, many people have no clue what all 3rd party editors are out there. You can find some of them through the website but many of the youtube videos showing editors are personal editors for that developer to produce.

But the draw back to having 3 - 6 different editors, they are all different and produce code of J3M different and then you have to migrate them back into your source, with editor being part of the SDK, it would be there for someone…

Cohesiveness in JMonkey is lacking.

Don’t get me wrong, I love JMonkey and use it all the time. I have 5 games I’ve done with it.

My 2 cents…


Exactly. Let’s make a game. :wink:

1 Like

Ok, Right now is not a good time, to build new stuff, (Editor, Games, libs, …) , (Also I Made games with JME)
One sdk and editor together is good ,also if of-course we don’t rely that editor into other IDE like Idea or Netbeans since when they update more effort will be on our hands to match changes of IDE, Editor is Editor we do visual tasks in it, like checking particles or placing things inside the scene …
We can achieve it in stand alone javafx or swing app. and keep updating and maintaining it.

What we can do now is using what JME already offer right now, trying to aim some of those teams and indies or all of them, by sending email, DM, by our Contributors or Leaders and telling them why choosing JME, also we can aim for twitter or youtube.

1 Like

I saw an initiative (Migrating From Unity to Other Game Engines | AppLovin) to help migrating projects from Unity to other engines (godot or unreal).
It’s a semi-automated process that converts assets and uses ChatGPT to translate the C# code into the target engine.
I think it’s an interesting concept, doesn’t do everything but it’s probably a good start.

I have never used Unity but if someone wants to make something to attract Unity users I think something like this or some documentation explaining what are the equivalent concepts between engines would help too (godot has this in their docs).

1 Like

I am an Unity developer for work. In all my years in companies I found there are two kinds of Unity devs:

  1. The “standard” developer: These are the ones that are more editor centered. Design first → code later. For them the SDK would be the best option. However, other engines like Flax, Stride, Defold, Unreal have a better chance in this field.
  2. The “coder” developer: This is a smaller subset, but a huge number. They use the Unity Editor only to run the code or make prefabs. I believe this is the kind of developer we can attract first. To my knowledge, JME is the only fully featured 3D game engine/framework that does not require you to know cmake. There are many frameworks that are mostly 2D and while they are 3D capable (LibGDX, Monogame, FNA), it is not easy. And Stride3D has a work in progress code only framework that has a LOT of work to do because it was designed like Unity