A proxy link on the subject with many enticing screenshots:
I'm sure that a review of their tech/system might provide a few interesting ideas for those working with and improving jME ; - )
That's pretty cool. I installed it already and tried it and although its good I couldn't figure out how to use it in 5 minutes. Will have to spend some time…
Is it expected developpers use only the UnrealScript language only or is it better to mix it with C++ ?
Now, if it was Eclipse based, and Java, I would love it. But no way I'm going to write code in some homecooked script, in some dated Notepad like IDE. I'd say, the ability to write code fast and efficient, and with the amount of available Java libraries, totally outweights all the game editors in the world.
I'd say, in open source technology like JMonkey, Java, Blender etc you can totally do the same…just you have to know what you're doing. The coding aspect of game creation is what I like, and even coding in something like Visual Studio gives me the creeps when I'm used to Eclipse, so I dare not thinking about what this would give me.
Besides, as I see it, they only release this because they are working on Unreal Engine 4…and THAT one is going to cost serious $.
Only free for non-commercial and educational purposes, so it's really only only free as in 'free publicity'…
Well,
that's sounds very familiar to Java-Annotations 
So, it would make even more sense to code this up in Java…
Since Multithreading counts more and more on, it will make even more sense to move to a real Programming language and not Scripting anymore…
JackNeil said:
You should have a look at the UDK, to see what the tools, engine, and script-language can do. It never hurts to extend the own horizon.
Truer words never spoken. Even if you will never use anything but jME (which is an awesome commitment), you should still give this a shot. jME isn't perfect and it's nice to see the way other engines do things. By the same token, Unreal isn't perfect and we can do things better than them :D
Scripting runs in a VM, and usually does simple tasks like event handling. Multithreading should happen outside of scripting. I like the keywords in the UnrealScript, it combines data-driven with traditional OOP programming, you can probably get really good results with it. I agree with tim8dev that it can be implemented with annotations.
tim8dev said:
Since Multithreading counts more and more on, it will make even more sense to move to a real Programming language and not Scripting anymore...
Answer:
Quote:
In traditional programming terms, UnrealScript acts as if each actor in a level has its own "thread" of execution. Internally, Unreal does not use Windows threads, because that would be very inefficient (Windows 95 and Windows NT do not handle thousands of simultaneous threads efficiently). Instead, UnrealScript simulates threads. This fact is transparent to UnrealScript code, but becomes very apparent when you write C++ code which interacts with UnrealScript.
All UnrealScripts execute in parallel. If there are 100 monsters walking around in a level, all 100 of those monsters' scripts are executing simultaneously and independently.
All UnrealScripts execute in parallel. If there are 100 monsters walking around in a level, all 100 of those monsters' scripts are executing simultaneously and independently.
JackNeil said:
tim8dev said:
Since Multithreading counts more and more on, it will make even more sense to move to a real Programming language and not Scripting anymore...
Answer:Quote:In traditional programming terms, UnrealScript acts as if each actor in a level has its own "thread" of execution. Internally, Unreal does not use Windows threads, because that would be very inefficient (Windows 95 and Windows NT do not handle thousands of simultaneous threads efficiently). Instead, UnrealScript simulates threads. This fact is transparent to UnrealScript code, but becomes very apparent when you write C++ code which interacts with UnrealScript.
All UnrealScripts execute in parallel. If there are 100 monsters walking around in a level, all 100 of those monsters' scripts are executing simultaneously and independently.
As far as I know, the UnrealEngine handles multi-threading better then perhaps any other game engine. (Well, perhaps ID Tech 5 does this job even better. )
Well, so you can't share a Entity (say monster) to two others? This would cause race conditions?
Or does UnrealEngine nearly synchronize every access? So then you don't have real Multi-Threading performance gains?
Maybe i'm missunderstanding something,
and yes, i agree to Momoko_fan, that Multi-threading should be done outside, but i don't think you could implement it in such a generic and performant way.
That seems a fantastic move, what an opportunity for people looking to get into game development - work with professional tools.
I think along with Unity's free release it presents a big challenge to jME and other open source engines to raise the bar, especially on tools support.
Baune said:
Now, if it was Eclipse based, and Java, I would love it. But no way I'm going to write code in some homecooked script, in some dated Notepad like IDE. I'd say, the ability to write code fast and efficient, and with the amount of available Java libraries, totally outweights all the game editors in the world.
Unreal script is mighty, explicitly designed for game developers, and has many awesome features. The language has a very strong connection to the engine.
Some examples:
Class keywords:
placeable
Identifies this class as being available for placement in UnrealEd. Classes with this designation can be placed into the world (level).
transient
Says "objects belonging to this class should never be saved on disk". Only useful in conjunction with certain kinds of native classes which are non-persistent by nature, such as players or windows.
Variable specifiers:
config
This variable will be made configurable. The current value can be saved to the ini file and will be loaded when created.
input
Advanced. Makes the variable accessible to Unreal's input system, so that input (such as button presses and joystick movements) can be directly mapped onto it. Only relevent with variables of type "byte" and "float".
localized
The value of this variable will have a localized value defined. Mostly used for strings.
Advanced function specifiers:
Server
Declares that a function should be sent to the server for execution instead of running on the local client.
Client
Declares that a function should be sent to the owning client for execution instead of running on the server. This flag also implicitly sets the simulated flag for the function.
Baune said:
I'd say, in open source technology like JMonkey, Java, Blender etc you can totally do the same..just you have to know what you're doing. The coding aspect of game creation is what I like, and even coding in something like Visual Studio gives me the creeps when I'm used to Eclipse, so I dare not thinking about what this would give me.
You should have a look at the UDK, to see what the tools, engine, and script-language can do. It never hurts to extend the own horizon.
Wow, SpeedTree bundled in the package !
Jack, I dont really see anything you said makes this so awesome. Of course U Script cannot be as advanced as something Sun spent the last decade developing.
And why would one want to write engine independent gamelogic code in a language that only executes in ONE engine ? Unless you want to be totally dependent on that engine.
I'm sure the engine is good, of course it is…and I will try it. I just can't imagine the IDE being as good as eclipse, or Unreal Script being better than Java.
Today, you don't make huge monolitic applications like this anymore, you make SERVICES, that ensure that people can use whatever they want to use from your system, while keeping as much as they want from their existing invirontment. Like JME…it doesnt forces you to use much.
Don't oversee the downsides of non monolithic systems.
Jme can be combines with nearly everything and is quite flexible, but there are quite some costs. For example
->Jme has several physic implementations, but none really stable while the UT engine has only one, but it is working without any problems as far as i know.
->Also just think about there Texture system, I guess it's certainly possible in JME too, however there is non system like this.
Still without sourcecode access it is no alternative to JME for me, since I'm not able to implement my own stuff. (This starts with the network system, and map based levels)
This is probably the downside of it, even if you have the sourcecode, it may need weeks to understand what you are doing because there is far to much stuff connected to it
Empire Phoenix said:
Still without sourcecode access it is no alternative to JME for me, since I'm not able to implement my own stuff. (This starts with the network system, and map based levels)
This is probably the downside of it, even if you have the sourcecode, it may need weeks to understand what you are doing because there is far to much stuff connected to it
well, you can have the source code... but its gonna cost you ;)
Yes, costs that are understandable, but I simply cannot pay for my fun projects 
(Also the more stuff I use that is not made myself, the less the whole project will represent me!)
Wow, SpeedTree bundled in the package !
Yes that's very very nice. Unity has decent foliage but not that quality. I guess Ogre has SpeedTree but also has the hefty pricetage. And none at all in jME :(