After spending hours performing search on the best Java game engines, i discovered Java in Action, which talks about Greenfoot and Alice. I haven’t tried Greenfoot, but Alice was cool, because it has a drag and drop support scene builder interface just like Unity, except that it wasn’t considered to be a full blown game engine like Jmonkey. So i just wanna know if Jmonkey plans to fuse with Alice 
Jme has its own base core code, so nope, the community only maintains the core jme libraries and the additional plugins, but you can consider it a trivial project for you…
Look what i just created using Alice 3 scene builder with my dummy experience which i haven’t done in my entire life ever since when i started using JME 
But i really love Jmonkey and wish this engine could be as easy as that…
1 Like
Try to follow the jme wiki from start and you will do more using jme, i promise 
.
1 Like
Sure thing but JME requires brainwork and the JavaDocs has too many packages and classes to read and understand so that’s what got me scared though.
But if you really stop and think about it, are you really any closer to having a game?
This is even the problem with Unity in a way. A million people can put a scene together but a very very small percentage can then make it do something particularly useful beyond the demo code.
If a game takes 2+ years to make then being able to drag and drop a simple scene in a few minutes versus the alternatives (I could have probably coded that scene in 20 minutes) is not that much of an impact. And eventually you pay some price for it.
You can start by splashing around in the shallow end of the pool but eventually you also have to learn to swim… and once you swim well it doesn’t much matter which body of water you are dropped into.
Edit: and to be clear, I’m not saying a scene editor, etc. aren’t useful. Even experienced developers would like to use these for prototyping if they are good.
11 Likes
It is very overwhelming at first. The other main 3 engines, gives an appearance that it is easy to start writing games. Creating a scene might be easier, but all the code under the hood is 90% of the work.
To me there are 3 types of Engines. A Visual based Engine, High Level code Engine and a low level code engine.
Visual = Unity, unreal, godot
High Level code Engine = Jmonkey
Low level code Engine = libgdx
Of not all engine, but a simple list.
Visual has a ton of visual options beyond scene building, make many things quick.
High level = you build everything in code. So to build a character, you add a Node for the character, attach your camera to that node, and then possible add other node for things like Torches, weapons and etc… Then create a Control (same thing as creating a script for a visual object in Visual engines) that handles like gun sway, camera sway and etc…
Low level = do around the same as high level, but you don’t have the control object that the engine controls and run automatically. You have to create your own control object and keep list of them and loop through them every update.
This is super simple explanation
9 Likes
Also note that the jMonkeyEngine SDK has a lot of “visual” features, more than most think. I’ve used it for years, and only found out about some of the hot-keys and features that made scene editing much simpler when looking at the code.
The SDK is just not as refined as the other “visual” editors.
A visual asset viewer is on my personal wish-list. We just need to see what is possible within the Netbeans framework.
2 Likes
ofc, why not?
you can do every game in JME, but about graphics, it could look best as Fallout 4 game, not better, unless you write custom shaders/filters and implement RTX functionality that for now do not exist here.
1 Like
What most people do not realize in the beginning (me included) that the final visual quality depends mostly on the assets used.
Unless you are, or have, a talented modelling and texture guy/team the assets will be your limiting factor.
7 Likes
I think that is why there is such a heavy pixel / low poly style, because it is easy to do and gives it a look that people will not complain about, because it is suppose to not be top notch. Creating top notch, will take to much for most independent developers. Specially those 1 or 2 team members. You will spend more time creating models and textures than writing code.
@rickard , which features are you using… I’ve tried and was not successful at most of them. I use it to import blender models and that is all I find works for it. I can’t even get the controls to work. SDK always says it can’t find the control.
But for me most of the game is rendered from data files and not static visual scenes. But the only reason for this is because I can’t get the control to work for me, to add door controls and etc… so that I can just load the scene and be done. But I can’t figure it out.
I would use visual scene, if I could (my limitation on what can be done) make the entire scene in Blender, import it and than add controls to certain objects. So the scene is complete, but I’ve never been able to come close to even getting this done through SDK.
But probably my knowledge limitation of SDK.
Are you using 3.4, or which version?
I’m mainly using the SceneComposer and Material Editor.
Not finding the controls sounds like an odd problem. I added RigidBodyControls yesterday and it worked fine.
Open up a separate discussion thread if you have questions, and I’ll try to help.
I hope to create a few videos on using the SDK, once 3.5 is out.
1 Like
The SDK isn’t perfect or complete for sure. To add to rickard’s reply, if it seems to be an actual missing feature or a bug. Please report it to the SDK Github. There has been now quite busy development with SDK. It would be even likely for some of the improvement ideas to be done.
3.5 release is quite imminent and maybe somewhat in a feature freeze. But we won’t stop on that release 
5 Likes
Can you check if you still have this problem with 3.5, because I can’t reproduce it. But I believe I could when I tried at the time.