Hey guys,

Some people asked us why we chose jMonkeyEngine 3 (we call it jMonkey) for our Project Aleron. Especially because we collected experience with Unity in the last months. Today we will compare jMonkey with Unity from our point of view and tell you why we chose jMonkey over Unity for this project.
We will not compare the languages C# and Java because, seriously, it makes no difference.

Choosing our Engine

As we started this project, we hadn’t heard of Unity yet and we found two engines which fulfilled our needs: jMonkeyEngine and libGDX, whereby libGDX only had “basic 3D support” back then. So there actually weren’t many alternatives.

While searching for engines we had the following requirements:

• 3D Graphics – We wanted to make a 3D game. 2D was not an option.
• Linux Support – We use Linux as our working environment.
• Garbage Collection – We have experience with Javas Memory Management.
• No or Very Low Costs – Students are poor 😛 .
• Source Code – If you don’t have the full code, you are not in control. Frustrating.

Unity VS jMonkeyEngine

Today we have experience with Unity and we also had the thought “What if we had used Unity?”. So here is our personal oppinion of what Unity does best and what jMonkey does best. We will not compare networking, because we did not have an in-depth look at Unitys networking capabilities.

Things Unity does better than jMonkey:

• Target Platforms – Unity can even target consoles!
• Asset Management – Great management of 3D Models etc.
• Graphical Abstraction – Unity abstracts away many things, such as graphics programming. Good for people who have no experience with it, such as us.
• Rapid Prototyping – Rapid Prototyping is a dream with Unity. Start the game, build some things and try it out. This is handy for UI programming.

Things jMonkey does better than Unity:

• Price Model – No royalties, no price tag. <3
• Open Source – If jMonkey’s built in code does not function as we expect it, we can read the code in our IDE and get quick answers.
• Development in Linux – We can use our preferred development environment. We use Git and The windows shell for git is… “special”.
• Collaboration is possible – Unitys Editor with its Scenes and prefabs is not meant for teams. You cannot merge these files and always block team members.
• IDE Choice – You can use any Java IDE with jMonkey. Eclipse, Netbeans, IntelliJ, etc. With Unity you are limited to MonoDevelop or Visual Studio (we don’t have Resharper). The latter has, among other things… peculiar hotkey combinations.
• Structure – In Unity you are jumping between the Editor and your IDE. Unity also has strongly defined structures with Prefabs, Scenes, etc. In jMonkey, you are very free. We replaced the networking entirely with Kryonet and we use our own Entity System.
• Flexibility – With jMonkey you can decide not to use AppStates or other components and use your own concepts.
  Unity enforces its scenes, prefabs and other components on developers without alternatives.
• Same Code-Base for Client & Server – We are using the same code base for the client and the server. We send the same classes back and forth and use the same libraries.

Conclusion

Unity, in our experience, is not an engine to be used for an MMORPG. It is too specific and limited for this use case, especially in the free version.
jMonkeyEngine offers us enough freedom. We have total control over our code and can share code between client and server. They even use the same Entity System and directly synchronize parts of it!
If we were to do this in Unity, we would have to translate between a lightweight C# entity system and Unitys integrated entity system.

For this project, Unity was the wrong tool. However we might use it someday for a different project. Unity has great potential for smaller games or graphical intense single player games.
Unitys lack of a Linux Editor and its incompatability with Git are two crucial problems though.

Authors: Sergej Tihonov, Eike Wulff and Benjamin Justice