Due to the lack of documentation and proprietary-ness of UDK and the Unreal Engine, I am trying out the jMonkeyEngine. I am also looking at Unity at the same time. Since I like the fact that the source code is available, what do you think are the benefits besides being cross-platform and BSD-licensed? What are the advantages and drawbacks?
Thanks!
I don't really have time to write an in-depth analysis right now, and nor do I want to sound like I'm promoting Unity on the jME forum 
But in the interests of balance and based on a good deal of experience of both Unity and jME, I either disagree with most of the negative points about Unity or consider them personal preference issues.
What I do agree with is that some features of Unity cost money, and that if you are a pure coder then you will probably find jME a more familiar environment.
A comprehensive and unbiased (- as it gets) comparison of two engine's technical merit is very hard, especially when we don't know more exactly what you're trying to achieve. With some more information about key features for your project I'm sure the developers could enlighten you a little bit.
It's no secret that Unity is currently the more user friendly engine though. If you're not an experienced programmer, Unity is an excellent place to begin 3D game development. We are working hard to lower jME's entry barrier, and getting there. Now if you know Java, and fairly good with it too, jME will probably impose fewer limits on you as a designer and let you shape exactly what you have in mind with a little bit of extra work thrown in.
If you go with a different engine for this project, I strongly recommend you check back in with jME for your next, as we're seeing pretty big leaps in development every month now
1 Like
Basically, I am interested in creating a flying vehicle in 3D space (all imported from 3ds Max). I have lots of Java programming language and do not like designing levels by hand (more like I like to do thing programmatically). However, I am not sure if jME has the capability to show different views (3D person, 1st person from camera, etc.) on the same screen and I am trying to integrate this so the controls on the quadcopter can either be navigated via gamepad controller or AI. Is it possible to slow down the engine to wait for the AI to react? There are many questions I have and due to the open-source nature of jME, I thought this might be a great framework to work with.
Based on 3 months I spent making a sandbox third person multiplayer shooter with JME and JGN, I say that everything you wrote here that you want to do, you can do with JME.
JME can show different views and it's simple to implement.
But I don't know about the gamepad though.
I think in JME there are many ways to wait for something to react. I don't quite understand what you mean by slowing down the engine.
Finally, yes JME is great, so far it has been for me the simplest and most effective 3d framework to get started with. When I started off with JME, it only took me like couple of hours to get my custom project running in my favorite IDE. Whereas I never got Crystal Space compiled and Ogre was also a lot of hassle eaven with a help of my friend who is making game with Ogre. And Java3D a lot more difficult for me understand. Eaven the people from Sun's project "Wonderland" switched from Java3D to JME. +JME3 will have Android support and I think lots more cool features, like multhreaded core if I'm correct.
One of the drawback I think might be that JME is made in Java. I might be wrong, since don't exactly how Java virtual machine works and I have not made any measurements, but I think with Java more memory is used and all the code that will be executed has to pass some extra layer that will take more time.
Wella ctually the only pu problem you might get is physic calculation due to java being a bit slower than c++, but that is nto as har as in the beginnign realistic is a factor of 1.2-2.
Else it's mostly the graficcard limiting.
Slowdown for ai, yes, jsut slow down the updates, or the timescale of them.
Ok, seems like some old java myths raise their ugly head again here…
Java is not much slower than native code, see this article or this one. Its true that you need some memory for the base jvm, but thats just about 4MB, so basically nothing compared to textures etc. Also, the OpenGL part runs natively anyway, so no reason why jme should be slower than any other OpenGL app. Even when transferring data from java to native for loading etc. ByteBuffers are used that allow direct sharing of memory between java and native. So there is no “layer” that the data has to go through because you are using java…
Cheers,
Normen
1 Like
Well java is still not memory efficient, in a game that won't matter, cause the real big thing is textures+sounds
But the base can be more than 4 mb, just use one swing component and it raises to around 20 mb. However again with modern pcs and modern grafic the other stuff is far larger than the code.
Empire Phoenix said:
Well java is still not memory efficient, in a game that won't matter, cause the real big thing is textures+sounds
But the base can be more than 4 mb, just use one swing component and it raises to around 20 mb. However again with modern pcs and modern grafic the other stuff is far larger than the code.
Java is as memory efficient as the code you write with it and I did not say that Swing is memory efficient :P
@Normen
I agree with you. Java (in the present day) can in fact be even faster than C++ in certain instances, due to the impressive platform-specific optimisations which the JVM now utilises. As for memory, I don't know and don't really care – because the things that really count in terms of memory, in any game, are the enoromous visual and audio assets; or any exceptionally stupid memory-management mistakes that the developer makes (such as using huge, sparse arrays). I consider memory optimisations to be absolutely one of the last things of any importance during the life-cycle of a project.
@advacecoder
Re Unity vs. jME. As of yesterday afternoon, I am migrating my prototype project from Unity to jME, after working with Unity for the last couple of months. Here's why I'm shifting:
- In Unity, instantiation of new geometry/entities(GameObjects) has to be done in a "MonoBehaviour" script. These are scripts which have to be tied to an instantiated GameObject. Crazy, eh? What this means is:
1.1. There is no "root location" such as void main() if you're a C/Java dev, or the "document class", if you're a Flash dev, where you can start building up your game's architecture. Your root code has to start in (some) MonoBehaviour script(s). This is really sucky as it means your code architecture takes a big hit in terms of elegance and readability. It means things are broken up and there isn't a lot of logical code flow – I am always reminded of the way amateur Flash devs write mini-scripts attached to individual sprites/MovieClips. It is VERY bad form. You can minimize this with Unity, but only to a certain degree beyond which you just have to live with it.
1.2. Basically, you can write helper classes, but the instantiation of game objects and so on requires you to use a MonoBehaviour script attached to an existing GameObject. So, in my case, I'm trying to generate a level by using a graph data structure. Instead of just reading that data structure and then instantiating rooms and passages in a utility class directly, I now have to use the utility class to build an intermediate list, which will then (hackily) be passed to an instance of a MonoBehaviour script in order to do the actual GameObject (geometry) instantiation.
- Unity licensing fee. Yes, you can you use Unity Indie free. It’s pretty cool, you’ll be up and running quickly (for the beginner, even more quickly than with jME), and it comes with the funky IDE. No, you don’t get source control support until you pay $500. As a professional developer, I can only go so long without source control. Particularly once things get more complex and you need to collaborate with other devs. It is impossible to do without source control. And Unity Indie basically locks you out of using source control, the technical reason being that there are hidden metadata files in Unity that SVN doesn’t catch (apparently), somehow. Personally I’m not willing to pay $500 just to use Unity Indie with source control, when ONLY paying that will still not get you the Unity Pro features which you would get from jME anyway. So to me it’s all or nothing – $1700 or jME :wink:
- You cannot protect your source with Unity until you pay the Pro licensing fee, and then either write (or pay someone else to write) a DLL that decrypts your C# source at runtime. The Unity team offers NO practical solutions for source code protection. With Java applications, you can use something like Excelsior JET (which, granted, also has a hefty price tag but can be gotten for free), Launch4J or GCJ to protect your source by compiling Java code into a native executable for whatever platforms you want to release on.
- When you want to edit your Unity code, you use UniSCiTE. Or alternatively you can use something like Notepad++ or TextMate. Whatever text editor you like, in fact. But guess what? None of them is a full-featured IDE. That means no code hinting/completion, no nice javadocs, no awesome class views or IDE-internal SVN integration… the list goes on. On the plus side Unity has it’s compiler all built-in and ready to go in the IDE. It’s just a pity that IDE is more of an asset development tool (think Flash CS3) than a real, full-featured code-creation environment like Eclipse, VisualStudio, NetBeans, Code::Blocks, etc. etc.
***
So…
For a generative approach to building game levels, my preference is jME. Unity assumes a bit too much, and that tends to get in the way. With that said, it is still quite an adaptable tool and if I had not had the option of jME I would quite probably have stayed with Unity.
The bottom line is that Unity is a tool that is very good for walking the line between coding and asset design. For elegant and logical codeflow, it is not the best. I will point out that, like Flash, it is a superb RAD tool for prototyping simple concepts. But once your complexity grows beyond a certain size, it becomes potentially difficult to manage, at least from my viewpoint.
So if you’re a pure coder, and particularly one who already has knowledge of Java, I would recommend jME. It seems to me by comparing the API docs to these forums, that there is a hell of a lot of stuff that people don’t even use half the time. But the codebase clearly has a lot of resource available.
In terms of documentation, neither Unity nor jME are great, but neither are they terrible either. And when docs fail, we head to the forums: my experience with the forums for both engines has been about the same, they are both great, helpful, active communities – responses to my posts number better than 3 in 4, on average.
In terms of language support, one thing that Unity’s Mono doesn’t have is namespaces, and that can easily be annoying. On the other hand Java doesn’t have generic aliases, as I mentioned in another of my posts today. Meh. To me, much as I dislike M$'s business practices, both C# and Java are very worthwhile languages each with their own pros and cons.
From a standpoint of converting code from C# to Java or vice versa, it is really quite trivial. The languages are honestly that similar. Most of the changes are very minor ones (and I do mean very minor) in how you access Vector3(f), and how you use collections to access your data. So if you decide to go with one engine and then change your mind, don’t let it worry you much, as long as your code is well organised into classes you’ll be fine.
EDIT #5630: One last thing I wanted to point out which weighs in Unity’s favour is the awesomeness of importing animated/textured 3D assets directly into the Unity IDE. Granted you have to make sure the assets are built the right way, but that’s no surprise. Once you get the hang of that (depends on your 3D content creation tool), it is literally as easy as drag-and-drop.
EDIT #5631: Since you mention AI, I also want to point out that it is possible to use multi-threading in jME, for things like AI and networking, whereas Unity offers you no access to threads. Almost everything in Unity happens in a single thread and that which doesn’t, is not within your control anyway (it is handled by the underlying engine which is written in C++). <- Actually, whereas jME can’t do anything that would affect rendering in an outside thread, apparently Unity really can’t do a whole lot with any of it’s core classes in an outside thread – unless they’re only data or utility classes which don’t interface with the rest of the underlying engine.
1 Like
Interesting comparison. Thanks for writing it out 
I sometimes go through an engine's documentation to get some ideas on how to structure my own, so I went over some of Unity's docs and I found out what you did. It's really just a super-game-editor, like GameMaker.
Glad I could offer some value, Momoko_fan. One does feel like a lot of time was wasted learning a thing one isn't going to use, so it's good if one can pass this on to somone else, no matter how minimally helpful.
Oh, it's worth noting to potential Unity users that it's current implementation (2.6.1) uses Mono Framework 2.1, which means many of the newer .NET 3.5 features are not supported (such as LINQ, for one, which is a bit like E4X and is leaps and bounds beyond what 2.1 supports in terms of XML processing). I think this will probably change though in the upcoming Unity 3.0, as Wikipedia article on Mono states:
Support for C# 4.0 is feature complete (as of December 2009) but not yet released in a stable version.
...But for now you'll be missing out on quite a bit of what state-of-the-art C# has to offer.
But in the interests of balance and based on a good deal of experience of both Unity and jME, I either disagree with most of the negative points about Unity or consider them personal preference issues.
I don't really have time to credit the opinions of those who don't back up those opinions with facts. Just so you know, what annoys me is not your difference of opinion, but the fact that this part of your statement lends little to the discussion. Be clear about what you mean, or it just leaves a question mark hanging in the air, so to speak.
I welcome any clarifications on what I've said above, as we all make mistakes, and we all see different tools in different ways that both affect, and are affected by, the way we use them.
EDIT: I don't think there is anything wrong with saying positive things about Unity on these forums (you have, as have I) -- especially if momoko_fan and other jME contributors are taking something valuable away from the discussion which might ultimately contribute to this engine. We're engineers. We're comparing technology. If I'm going to hide saying good things about other engines, I may as well not even bring up other engines at all.
Easy Tiger.
I have a different opinion of the tools to you, and my opinion like yours is based on experience.
I think that some people might consider that relevant.
Should you or they decide to ignore my opinion because I don't go into detail then that is your right.
I do not state that your opinions are invalid or even wrong, merely that I disagree with some of them.
But you're not stating which you disagree with – which to me is a little strange.
If you have something to say, say it man!
challenge to a dick waving contest !!!
:Edit:
(Sorry i couldn't resist to post that, still hopefully everyone realizes that this is not the level of flame we want to do here?!)
Hehehe, touch
Things I don't like include discussing whether someone has the right to discuss at all. But I'll get over it with time and the support of my dog. I don't have a dog mind. But I digress.
Writing detailed posts about entire engines, knowing that if they aren't worded right the phrasing will be pounced on rather than the message, takes me a while. Meantime I thought people might like to know that the point of view expressed so far isn't the only one.
However, it's the evening now and I like making people happy so here, I wrote you a short book:
Unity is an complete game engine, with features integrated. At this stage, jME is a scene graph API. It is not fully integrated with an editor and most none-graphical parts of a game are not part of the core. Because of this, Unity handles a lot of things in it's own way which you would code yourself in jME or writing games from scratch. This is normal for a full game engine and does not mean Unity is just a game maker tool.
Unity is integrated and quite visual. It is an unfamiliar environment for coders. Again Unity is a game engine not just a programming API - it is supposed to be useable by other members of a game development team than just the coders.
Objects are created visually which can be uncomfortable to coders, when they aren't physical. Just like creating objects that are physical with code is uncomfortable to artists. The thing is, it doesn't affect what you can do, only how you go about it.
Unity is a commercial product. For free there is a powerful tool that can make full games with plenty of features. One of the main things you pay money for, is features for advanced professional development. Source control, in terms of pure code, is one that you get easily with jME but not with free Unity. There are some that you get with free Unity but not with jME (yet), such as straightforward shader support, management of none-code assets, straightforward build and distribution process.
By default, Unity opens scripts with the Unitron editor. This is fine for editing basic beaviours but not a patch on a decent IDE. However, you can set up MS Visual Studio to work with Unity and get all the main IDE features you need for your coding pleasure. I believe a ton of work has been done on MonoDevelop integration for 3.0 IDE goodness.
Unity does not give access to the source code, unless you pay a fortune. This means you will not be doing core engine coding. You write the code of your game only. I like having source access in jME. I generally don't like needing it. In Unity, many more core features exist and they are more likely to work.
In documentation and learning material, in my opinion Unity is light years ahead of JME. It's not perfect, what is? And it's only to be expected as the product has a lot of money behind it. But there you go.
As far as complex project go, in my opinion Unity handles pretty much every aspect of a project, other than code, better by far out of the box. And code better if you pay the money. I'd say a comparison of the projects achieved in each supports this. Again, not a fair comparison given the user base, accessibility and commercial backing but there it is.
Both jME and Unity have outstanding communities. Unity is backed by a company that pushes it forward all the time. jME has in recent months gained a new level of momentum with hard working people moving it forward. The feature set of each is set to leap forward with respective version 3's.
They are different beasts and jME certainly keeps programmers in their comfort zone. Ultimately, it's well worth taking a close look at each because other people's experience is very subjective.
Thanks for replying. It's clearer now what you were getting at. A few points:
Unity is an complete game engine
No, it's more than that, it is (in its complete form) a traditional IDE, asset creation tool and most crucially, a deployment platform. I take the term "game engine" to mean more of a full-featured API such as something like SDL or Torque, for example, that doesn't necessarily include a deployment platform. Unity, like Flash, is first and foremost a platform, and secondarily is the tools used to develop and deploy for that platform. Your core point is true and valid, however.
jME is a scene graph API. It is not fully integrated with an editor and most none-graphical parts of a game are not part of the core. Because of this, Unity handles a lot of things in it's own way which you would code yourself in jME or writing games from scratch. This is normal for a full game engine and does not mean Unity is just a game maker tool.
No, it isn't just a game maker tool. I didn't call Momoko_fan out on that point, as it's a matter of opinion what a "game maker tool" is defined as, but yes, I would tend to agree with you, as it provides a full featured API (with source under the Source Code License).
Objects are created visually which can be uncomfortable to coders, when they aren't physical. Just like creating objects that are physical with code is uncomfortable to artists. The thing is, it doesn't affect what you can do, only how you go about it.
I think it has more to do with the level of control/access than whether or not the results are visual in nature. Without maximal access to the logic that you expect and require, you are going to feel as if your hands are tied as a coder. If the dev environment obscures that, it's going to bias you against that environment. I'm not sure this is a solvable problem, really. A tool like Flex Builder vs Flash CS4 is a typical example. Different tools, different foci, same language/deployment platform.
There are some that you get with free Unity but not with jME (yet), such as straightforward shader support
I hacked together a shader for Unity, but didn't know such sugar was not available in jME. Pity.
In documentation and learning material, in my opinion Unity is light years ahead of JME. It's not perfect, what is? And it's only to be expected as the product has a lot of money behind it. But there you go.
That IS a matter of opinion. If you delve into more in-depth aspects of Unity such as mesh exporters and constructing dynamic geometries, I'm sorry to say it's about as poorly documented as jME is. The basic docs for Unity are incredibly sparse, but at least every single class, property and method has something written down, even if it's just five words. But then that is what forums are for, in both cases. It's my approach to always assume that no documentation is ever going to be perfect and thus the activity levels of forums are far better way to judge how you are going to fare when learning a new engine. And again, I feel these two engines are on a par in that sense, although Unity has about 13k members to jME's 5-6k. The fact the response level is so good here even at this smaller figure is a testament to the involvement of the jME users and contributors.
As far as complex project go, in my opinion Unity handles pretty much every aspect of a project, other than code, better by far out of the box. And code better if you pay the money. I'd say a comparison of the projects achieved in each supports this. Again, not a fair comparison given the user base, accessibility and commercial backing but there it is.
Part of the problem with that comparison (perhaps this is what you meant re accessibility) is that Java is traditionally not a language used for game development, whereas C# definitely is (XNA). So you have a whole culture of game development built around languages like C/C++, C#, and Flash, whereas Java has received very little attention in this sense probably because "there was always something better" at least in terms of library support and so on. With that said, I think we all agree that jME is an amazingly competitive piece of work and certainly one of the best advances that Java game dev has yet seen.
They are different beasts and jME certainly keeps programmers in their comfort zone. Ultimately, it's well worth taking a close look at each because other people's experience is very subjective.
I couldn't agree more. And it's thanks to threads like this that hopefully people will be able to come and read up about the pros and cons as recorded for posterity by people who already know -- so thanks for sharing.
Whats more straigtforward than using a shader material? (JME3)
Or a ShaderRenderstate JME2?
Well I personlaly hate not having source acces, cause I suually do stuff outside the orginal intended engine limits. (The reason why i changed from Source-Engine lua bindings to JME the first place)