O.o … your mind must be more dirty than mine Xd I did not see that XD
This thread took a turn for the worse… nice one everybody! haha
1 Like
I have something to add to this discussion though, the UDK vs. JME that is… not the pants… cough
Would I be correct in assuming that a single dev might have more success in something like the UDK as opposed to JME if they have little to no programming experience? I would assume that more pointed scripting like in the UDK would be quicker to pick up than a full programming language. And if I’m not mistaken, this probably has been discussed at length here on these forums… but a decent knowledge of Java is probably a rather big necessity to really take advantage of the JME, correct?
1 Like
Yes to all your questions 
More or quicker success? thats the real question. As long as you are motivated and are able to invest time, the success with jme might be more ( at least I feel very proud for understanding the c++ binding with jni, low level opengl and lighting, shaders , network , leraning to use java (and algorithms in general) in a clean and efficient way and countless other stuff (and I hope to add quaternions to this someday))
If you define success in the part of the game the casual gamer sees, then UDK will be way faster.
Or in other words, if you are intreseted in how a car works the own ford might be a better choice since you can do everything with it, if you just want to drive fast, rent the ferrari.
JME is a huge advantage over UDK becuase java can be moved to any system that runs java and thus it can save alot of time, effort and money.
JME is a huge advantage over UDK becuase java can be moved to any system that runs java and thus it can save alot of time, effort and money.
It's not as clear. UDK will have a Console Port. That porting will be really easy to perform because you don't write system dependent code. Of course you have to write in a manner that's appropriate for consoles.
But... all this accounts only for really big games because the console publisher control those games published for their hardware and so you as an indie will probably not publish onto consoles.
In the end its the same, both systems use a VM that runs on multiple machines. jME can be compiled on a PS3 just as well, in the end we are not dependent on Oracles JVM distribution, most probably we’ll also add the option to bundle a JVM for situations like Apples AppStore and similar things and/or even allow to cross-compile to native for selected platforms using avian.
@enum said:
It's not as clear. UDK will have a Console Port. That porting will be really easy to perform because you don't write system dependent code. Of course you have to write in a manner that's appropriate for consoles.
But... all this accounts only for really big games because the console publisher control those games published for their hardware and so you as an indie will probably not publish onto consoles.
Good point but still with things like UDK you need(correct me if im wrong) permission from the makers of UDK to release the game on a console, where as Jme its opensource so it kind of removes that barrier of inconvience, time wasted on writing contracts or getting lisence deals worked out.
Yes that’s true. I just wanted to show that it is not as clear as written above^^
@enum said:
Yes that's true. I just wanted to show that it is not as clear as written above^^
Oh gotcha
Maybe it’s just me, but I find it obvious that JME, still being solidly in beta, 100% open source, and non-profit, is not really meant to be a real competitor to fully featured commercial packages like Unity or Unreal. At least not yet.
Currently I see it as an educational platform. I have learned quite a lot from JME and when I have more time after school I hope to actively develop for/with JME. But if I had to make a commercially viable game today by myself, given my inexperience and JME’s incomplete state I would also have to go with something like Unity. I just don’t know enough about the low level parts of making a game to do it on my own. But without communities like JME I would know very much less.
So it’s important to keep the support for this project going even if you use another package for “real” game making, because if projects like JME aren’t supported they die, and if they die then we don’t get to make this choice anymore.
And who knows, maybe one day we will have a fully featured open-source package that rivals even Unreal in ability and ease of use and it will be completely free to use and community maintained. But that can only happen with support.
1 Like
@HeroHero said:
But if I had to make a commercially viable game today by myself, given my inexperience and JME's incomplete state I would also have to go with something like Unity
I think that's delusional. That's not you in particular, but a lot of people think that.
You can't make a complete commercial games even with Unity without a proper and solid knowledge about 3D development. This implies knowing a language (scripting also implies a language), an API, and knowing how things are done in the background.
If you think you can achieve this without all that knowledge with Unity, I suggest you try.
Though I admit we lack some features. But now a lot of things can be added without touching to the core. So in the end it's up to the community.
Unity is just so tacky anyways its another plugin the user has to download and we all know how relucant users are of downloading new plugins with all these viruses running around.
I don’t know how anyone could release anything super serious with unity3d I even made a first person shooter with unity3d from the ground up and it just didn’t feel quite like the FPS gaming experience…
@nehon said:
You can't make a complete commercial games even with Unity without a proper and solid knowledge about 3D development.
Maybe you're right. As I said, I lack experience. I just view Unity as an on-rails type of platform. I don't disagree that both require knowledge of 3D development, but when it comes to other details such as testing and deployment, the major packages seem to be far more full-featured.
@HeroHero said:
but when it comes to other details such as testing and deployment, the major packages seem to be far more full-featured.
Testing is your responsibility. Deployment... Well, considering jME3 is instantly deployable on PC, Mac, Linux and some obscure others OSes, I think jME3 is faring pretty darn well.
1 Like
@madjack said:
Testing is your responsibility. Deployment... Well, considering jME3 is instantly deployable on PC, Mac, Linux and some obscure others OSes, I think jME3 is faring pretty darn well.
I don't disagree at all. By full-featured, I mean more tools for doing such testing.
And I doubt java will ever run on console.
Actually, what are your thoughts on this? I suppose anything is possible....eventually.
I think I remember reading somewhere, sorry I don’t have a quote, saying that Java was already running on some consoles? I might be wrong though.
1 Like