Hey! I’m new to programming and am very eager to make a game in the future.
Have therefore looked around on the internet and found some candidates when it comes to game engines and programming languages.
But I have some questions and I wonder if you might have time to answer them.
Is there a big difference between programming a game in java compared to c ++ and if so, what are the pros and cons?
And what are the pros and cons of jmonkeyengine when it comes to developing a game compared to other game engines out there?
I understand that jmonkeyengine is an open-source project and does not have the same resources compared to unity or unreal engine. But thought if there are any advantages jmonkey has over them because of the fact that jmonkey is written in java and not those general languages usally used to make game engines.
language dont matter much. its just about what language you like (well even in JME you can programm in C via JNI/etc, anyway OpenGL / physics / navmesh libs in JME are in C)
while unity is almost like “click everything”, jmonkey is almost like “code everything”.
JME is free and open source, while Unity is partially closed source and need pay taxes if you earn too much. I think this is main reason except if you like Java to use JME.
ofc JME cant have as good quality tools/premade assets like Unity(it would be many things to tell, like pipeline for example is better in Unity), but if you are skilled developer / artist(or just buy models from external sites) you can do everything you want.
I would say you got 100% coding freedom here. (but this sadly require knowledge/skill from you)
Everything have advantages and disadvantages, but i seen Unity users were angry recently when they made more code closed-source. I think this is main disadvantage of popular Unity.(except taxes and coding way ofc))
If you like the “click everything” approach of Unity but want an open-source library, you may want to check out Godot. It has a fully open-source license like JMonkey, so you can do pretty much whatever you want with it without needing to pay anyone. While its “visual scripting” is a bit obtuse, its primary GDScript language is pretty easy to pick up (especially if you already know Python), and it has support for C# and C++ as well if you really need it. I haven’t done much extensive 3D work in it, but I do very much like what I have seen so far, and would take it over Unity or Unreal any day, if at least for stability more than anything else.
Alternatively, if you want a “code everything” C++ library, The Urho3D looks pretty good. I haven’t tried it myself yet, but that is where I would look first.
That said, the general wisdom is that while you can often technically squeeze higher performance out of C++ applications compared to Java (even though the gap is pretty small these days due to the JVM’s remarkably high optimization), your code will be hampered by a lot more obscure bugs simply because C++ is pretty hard to code for and is prone to these bugs in a way that Java isn’t.
As far as rendering goes, though, most of the work is ultimately offloaded to OpenGL anyway, so it doesn’t matter too much what language you use, as long as the engine isn’t doing anything too stupid. Our recommended physics library, @sgold’s Minie, also offloads its work to the Bullet native library, so the Java/C++ point is rendered moot there as well.
In the end, I would just recommend using pretty much anything besides C++ if only for saving on headaches. C++'s manual memory management may seem handy for games at first, but it is often more trouble than its worth, and Java has a pretty decent garbage collector anyway.
I looked at Unity and Unreal before getting into JME (JMonkeyEngine). Here are some key differences:
JME is open-sourced, while Unity (and probably Unreal) are closed.
JME and Unity are free, while Unreal requires 5% royalties above an income threshold.
JME’s license is short and easy to understand, Unity and Unreal’s are the exact opposite.
JME works well on Linux, while Unity and Unreal are said to have problems.
Unreal and Unity are well known, while JME is less so (that hardly has anything to do with this though).
Although I don’t know the details for Unity and Unreal for this point, I’ll include this anyway. Learning JME was a very steep learning curve for me, even though I already had experience with Java. The “hello tutorials” and forum here was a huge help! Just take note on that.
JME is REAL coding, while (as @oxplay2 said) Unity and Unreal are more drag/drop with their Blueprint language.
I might be wrong about some points, since the last time I looked at Unity or Unreal was about a year ago.
I’m not actually sure that Unity has a visual script. It has support for scripts in C#, but I don’t see anything in the documentation about anything like Blueprints.
Also, while Unreal does rely heavily on Blueprints, you can also use C++ for scripting. You may not be able to accomplish the same level of depth that you can with jMonkey, but the more flexible language is available.
if you start programming, you should definitly start with java not c++(unless you have someone who helps you). Because c++ can be frustrating, in c++ you can run into problems before you even start programming, because just setting up a project with something like urho3D can be difficult. Java is a very easy programming language. Java is way slower than c++(but still way faster than python) but since you arent going to write an AAA Game that should not matter at all.
This is not true. There are many places where java can outperform c++, and there are many times when c++ can outperform java. But neither outperforms the other by a very large margin anymore. The largest difference is in memory usage. Especially when java is performing a task faster than c++ you will have larger memory usage. This is because java has a lot of power in how it handles dynamic code, where c++ although object oriented, is still fully compiled with no runtime dynamic factor that can be used to improve performance.
Java will always be slower to start than a c++ application, because it needs to start the jvm before it can run, but in many instances if you are willing to trade memory for performance, it can outperform c++.
Only looking at pre-canned artificial test will get you nowhere when performance testing languages.
I have done enterprise development with java, c++, and a variety of other platforms. There are uses for all languages, each languages excels at specific tasks. Java is much faster at dynamic operations than c++, which makes up almost every high performance cloud application.
Anything that is cpu bound, such as the test you link to will always be faster in c++ as it is running the cpu instruments directly instead of going though the jvm.
Unreal doesn’t typically use native memory management - it has a garbage collector, and while I’ve not seen numbers I’d bet good money it’s nowhere near as fast as Java’s best-in-class GCs. The newer Shenandoah & ZGC are able to do virtually all work outside of the stop-the-world phase, making GC pauses essentially non-existent. At a game’s complexity, it would be extraordinarily difficult to correctly use C++ manual memory management and beat (or even come close to tying) Java’s GCs.
The point is C++ and Java are in the same ballpark. And given how insanely much easier java is thats good enough for me. If they are within the same ballpark for expert-level-optimised then which is actually faster in the field probably depends more on the actual application and programmer than the language choice
I believe all of these tests start from a cold JVM - it’s an apples-oranges comparison, since the C++ program won’t have to warm up a JVM and progressively JIT optimize on the run. This tests the worst-case performance of the JVM - warming up, running bytecode, JIT compiling and re-optimization, etc. Once warmed up it will almost always be within a few percent of neck-to-neck (in some cases, this will be in Java’s favor as it can eliminate sections of code a C++ compiler can’t). Virtually all programs outside of short-running CLI tools hit the post warm-up point.
For example, I took a quick look at the Pidigits test (the first test in the list). It’s a dismal comparison for a couple of independent reasons:
As mentioned above, it’s run from a cold start. This is a disadvantage, as the JVM starts by interpreting bytecode and has to JIT on the run - if the test runs for a long time this will be less pronounced, but for a short running test this is a huge hit. I don’t know how long Pidigits runs for.
This doesn’t test Java’s numerics at all - all the computation is done by the GMP native library, which is called via JNI. JNI is slower than native-native calls do because it has overhead that they do not have, and on top of that the JIT compiler cannot optimize across Java-JNI function call boundaries, whereas the C++ compiler may be able to. (Just about any FFI will have the same or similar overheads.) Pidigits is really testing the speed of calling numeric C code from Java, not Java numerics, so it’s an apples-oranges comparison in a specialized, rarely-used area where Java is known to have unavoidable overheads compared to a native compiler.
If you want to accurately test, you need to use the OpenJDK JMH benchmarking harness as it will avoid the subtle pitfalls that tend to accompany ad-hoc Java benchmarks.
In my experience, the benchmarks games aren’t good for much beyond order-of-magnitude comparisons and even then be aware that they have some fundamental flaws, tend to compare apples to oranges, and don’t typically represent real-world usage.
When properly warmed up, the JVM tends to be virtually neck-to-neck with C++ on most computationally intensive tasks.
In most graphics applications the shaders and number of draw calls to the GPU are the limiting factors, yes. JNI overhead to call OpenGL is totally lost in the noise for jME, and the Java parts you write will usually be in areas where Java is neck-to-neck (or even a little faster than) a C++ compiler.
If you are new to programming (and in most cases even if you aren’t) the difference between programming a game in C++ and other languages is that with the other languages you get a chance to actually finish your game while you are still alive.
Java vs C++ will always open a can of worms . The answer to your question really depends on what your end goal is. If you want to begin your journey towards working in the game industry professionally , companies that use java for their game engines and/or “scripting” layer for gameplay programming are few and far between and C/C++ will remain the golden standard for years to come just by pure inertia like in any IT domain where there is so much investment already made around an existing programming language. That being said there is nothing stopping you from creating your games with java and making a living out of it. If you are afraid of performance problems the language might have, like many others have said, don’t be, it’s performant enough for most of your needs. Programming languages aren’t magically more performant than others. Writing performant code requires a understanding of more than just time and space complexity of algorithms but how certain hardware architectures work as well and java gets in the way of that but C++ has some nasty performance pitfalls if you don’t know what you are doing. If you write C++ code the same way you write Java code most of the time the resulting C++ code will be slower. I recently saw a talk where the npm(node package manager) team moved their codebase from nodejs to rust(which is seen a C++ equivalent) and their initial implementation which was a naïve write the old code into the new language resulted in a performance hit because the V8 javascript engine was doing so much optimization. Later edit: BTW, with the features that are planned to come to Java in the next years it won’t get in the way at all anymore from my point of view but just to reinforce the point it’s already fast enough even when writing code without thinking of optimizations
. The answer to your question really depends on what your end goal is. If you want to begin your journey towards working in the game industry professionally , companies that use java for their game engines and/or “scripting” layer for gameplay programming are few and far between and C/C++ will remain the golden standard for years to come just by pure inertia like in any IT domain where there is so much investment already made around an existing programming language. That being said there is nothing stopping you from creating your games with java and making a living out of it. If you are afraid of performance problems the language might have, like many others have said, don’t be, it’s performant enough for most of your needs. Programming languages aren’t magically more performant than others. Writing performant code requires a understanding of more than just time and space complexity of algorithms but how certain hardware architectures work as well and java gets in the way of that but C++ has some nasty performance pitfalls if you don’t know what you are doing. If you write C++ code the same way you write Java code most of the time the resulting C++ code will be slower. I recently saw a talk where the npm(node package manager) team moved their codebase from nodejs to rust(which is seen a C++ equivalent) and their initial implementation which was a naïve write the old code into the new language resulted in a performance hit because the V8 javascript engine was doing so much optimization. Later edit: BTW, with the features that are planned to come to Java in the next years it won’t get in the way at all anymore from my point of view