Hi all,
I've recently switched from jME to UDK because I think the latter will allow me to work much faster. Since UDK is backed by a company with actual money behind it so I think it's impossible to beat UDK at what it does best (making an UT clone). However even UDK is far from perfect and I think jMonkeyPlatform and jME3 could beat it. For this reason I'd like to post my thoughts about certain aspects of UDK that struck me as really good (and thereby a candidate for shameless copying) or annoying/bad and therefore something UDK could be beaten to.
Since I've mainly been learning the scripting language until now I'll start there.
UnrealScript itself is not actually as bad as I expected, pretty easy to grasp if you know java. It does apperently have some benefits compared to a non-game-oriented programming language but it has so much sillyness in it that Java still looks like the better language of the two (I could specify and I was planning to, but then this post would become too long).
This in itself, however, is just a small disadvantage others may very well disagree with.
The real "problem" with coding for UDK is your starting point.
UDK has some scripts ready made for you. I love ready made things, just not the way UDK does it. What you have to do is create a script extending a "GameInfo" script, there you have to declare your player controller and the object you are actually controlling then in the player controller you declare one script for the camera were you declare another script for the camera were you have to declare a third script for the camera were you can change a method so the camera is looking from the top, and oh, all these classes are extensions of classes that do all kind of stuff you never asked for. This approach really made me miss jME2's rootNode I could just attach stuff to.
So my point is, please keep the basic class one is supposed to extend clean and simple: initGame, update and no more.
Doing this will of course "remove" all the helpful pre-made classes and that's bad, so this is what I propose:
A list of pre-made classes (like a gun, or a building that can produce things) with keywords so the programmer can quickly see if what he wants has already been made.
There are other points I'd like to mention but this post is long enough and I have to go myself, so I'll post them some other time.
So we just need to keep our game entity templates simple? No problem!! 
jMonkeyPlatform already beats UDK in one respect: You can sell the games you create with it w/o having to pay horrendous fees 
I love threads like these If anything, we're not doing this often enough. Dissecting the technology of our competitors is to me an essential step in improving jME, not to mention narrow down its core concepts. What are we bringing to the table that no one else is offering?
I've spend quite some time with UDK myself in a game design course. I've made both multi-player and single-player maps with it; in doing so I've also dealt quite a bit with Kismet, but only the 'pull-string-to-box' approach. I hated it… 
Kismet that is. Other parts of the engine were great, but there's not a single thing about it I felt could not have been better, or done entirely differently with a much more intuitive approach. But then again, I'm only able to address the more editor-specific issues, and not so much what a programmer would care about, especially with source-code (but I assume you haven't got your hands on that, heh).
What you describe here seems like a rather simple thing to do, I reckon your wish is our command on this one ;D By all means though, post the rest 'some other time' and I'll be all ears.
Well, traditionally jME is SceneGraph-based so that will be the logical base for everything, thats why right now I am trying to make that as accessible as possible in jMP. The logical consequences will form the way things are done in jMP and I am already confident that this is a very good approach, keeping things understandable and at the same time extendable to almost anything. Also it should be easily possible to cut down future template files due to the same fact, speaking of features no one ever asked for :).
As far as scripting goes we have a ton of options in that aspect. There are many scripting engines available for Java and I am sure we could find something suitable for games.
Beside the scripting is there any other differences you want to mention?
UDK requires Windoze…that's reason enough for me to avoid that engine. I'm all for cross-platform compatibility, which jME is all about.
Well not to turn this into a jME vs UDK thread, but while it is true that UDK requires you to pay licensing fees and is not cross-platform compatible I don't think the "big" developpers will care about it (gamers are used to the requirement of having a windows pc so they will have on anyway). But I'd like to make this thread about how to make jME3+jMP "better" than UDK at it's core, disregarding budget, compatibility, affinity with one language or the other etc. (if at all possible, like I said I am using UDK myself at the moment and it would be hard to compete against a large commercial company)
Since you asked I'll post some more opinions.
Most of my problems with UDK are more or less about how "obscure" it is. A lot of things are handled by the engine (great!) but it's not really clear how it all works. In the process or creating something more suited for a game scripting language UnrealScript got very complicated. That's why I think clean and simple java may still be the best choice. There are however certain concepts I think are rather nice (at least if I understood their workings correctly) so if anything java + these points would be the way to go in my opinion:
There's a keyword you can put before a variable that decides if that variable will be shared with other players online, seems like a very clean and simple way to regulate much of the multiplayer aspect.
Variables can be declared to be settable from the editor.
Actors can be in different states that can have state-specific methods in them and a start and stop function (plus something else I don't quite understand or like). So in a state "afraid" the method "seenEnemy()" may involve running away while in a state "agressive" a call to that same method would involve bashing it with a rotten fish. Also if I understand correctly (and if I don't screw it, the idea is good) there's also the possibility of stacking states. So a unit could be in a state "moving" and seeing an enemy would push the state "fighting" on the stack and the death of targetted enemy would pop that state again.
The kismet editor, a lot of programmers probably hate this but it's actually really nice. Main issue I have with it is that everything is marked by the same lines. I think there should be at least a clear difference between getters and method calls (and possibly restrict everything to that).
There's some other stuff but I'm running out of time again (forming opinions is very time consuming) so I'll post them at a later date.
Huscar said:I think the Kismet editor is a great idea executed poorly. Most importantly it's a job in itself to keep it tidy, in every sense of the word. Half of what my Kismet lectures covered was basically how to not get overwhelmed... Like you were on to, many of its problems could have been handled with better visuals.
The kismet editor, a lot of programmers probably hate this but it's actually really nice. Main issue I have with it is that everything is marked by the same lines. I think there should be at least a clear difference between getters and method calls (and possibly restrict everything to that).
Another thing about the Kismet editor I think is that there are certain best practices that could easily have been enforced, or at least pushed as defaults. For a task as simple as creating an elevator, there were too many features that might very well become bugs if handled incorrectly. If the editor knew that everything inside of a particular script was supposed to be an elevator, it could dutifully prompt me if a return call was missing.