@Pesegato I mix it too, but i found it is not really comfortably. Ofc using tools like blender, font editor is the game making too, but if i must write code, test code and build application in different IDE’s i feel like i’m doing somthing wrong
I have started developing with jMonkey in February of 2016. After month after playing with JavaFX 3D (and it was bad experience). And during this time I wrote more than 1 MB of code. And JME still works for me. It makes you not only a game designer but also a game engineer because you have to solve different challenges. From my point of view, engines like Unity is Rome: you have everything on your street, you can buy everything (if you have money, of course). And JME is SPARTA: it makes you tough. Seriously, when you solve another challenge and your coding muscles grows you get tons of satisfaction.
And I believe next years will become golden age for JME, at least for PC: perfomance difference between AAA engines become less and less everyday because computers became more powerful and you can easily take ideas of AAA engines features.
1 Like
It clearly says that this is a problem caused by:
Origin 1: D:\Medvedev\JavaProjects\AndroidTest\mobile\libs\lemur-proto-1.7.1.jar
Origin 2: D:\Medvedev\JavaProjects\AndroidTest\mobile\libs\lemur-1.8.2.jar
So you can do two things:
a) as a test remove lemur-proto, it’s only an extension with more advanced “widgets”, IIRC
b) Edit both jars with an zip file to merge the duplicate file into one.
Maybe there is a flag for the Dexer to ignore duplicates but I guess this would only hide the real issue here.
Without precisely saying what is wrong we’re unable to improve the SDK.
Yes it looks a bit old-school but 3.1 is a big improvement on everything.
The only problem is that you are unable to run it. But since it’s a Engine Problem and I have no clue about that I could only suggest you giving it a try inside a virtual machine or something.
Nonsense. I know at least one professional web developer that switches between webstorm (Jetbrains) and sublime text because the former has more features, while the latter is faster.
And, if you are making games with one single tool that provides you with everything… maybe you are experimenting too little 
It is stange to hack jar files just to let them being deployed, isn’t?
Yes SDK 3.1 is unable to work on some machines, while 3.0 is able. Maybe it is only engine bug or video card bug, looks like it is mistery for most of us. Don’t wan’t to explain every issue i had, cause i prefer solve them by myself and have about 50% success, but about SDK i will explain. 3.0 is not supported by Lemur, and while i am using it i must use 3.1, so 3.1 is bugged looks like i’m some kind of stuck. And another bug i found yesterday in 3.0: after clean/build my android apk file stay unchanged while source code and assets being changed.
So, after i found a few SDK’s tools bugs forces me to learn unofficial ways to deploy what should i say, “the beuty tool”? 
Maybe i wrong but i beleive if SDK says “u can build desktop and android” it should let u do it, just after install and set up needed options, not after sitting a week and searching black cat in dark room. Whatever…
3.0 is not supported by Lemur, and while i am using it i must use 3.1,
so 3.1 is bugged looks like i’m some kind of stuck. And another bug i
found yesterday in 3.0: after clean/build my android apk file stay
unchanged while source code and assets being changed.
With open source you are most times unfortunately required to pitch in if you want things to work. At least report the bugs if you are not able to fix, but this goes also for commercial engines. Following Rust (https://playrust.com/) and one can see that the grass is not always greener on the other side 
It is equally yellow. Hard work
2 Likes
@Pesegato It is not nonsence. U have to look at onother tools and ask another ppl who using it. Ofc when u developing game it is always about using many different tools, but all of them should do their own task, like if u write code use 1 IDE, make model use Blender or Maya. Why not both? U really asking about it? Is ur day limit 24 hour or 100 hour? I mean when u want to hammer a nail do u use 10 tools for it?
I beleive u know professional dude, who switching in different IDE while doing same task, but it is not ok to me, i prefer 1 tool for 1 task, dont wanna learn Netbeans, Eclipse and Idea at same time(i used Eclipse like 2 years long time ago). So with engine is the same. Even more clen concept, cause JME SDK gives me power to edit assets and write code in one tool, but unfortunately bugs, bugs and bugs. Thread is starting to fall into complains and i dont’t want it.
Totally agree with i need more experimenting with different tools and find what is fits to me (doing what it should do )
@Antonystar Fun metaphor about Rome and Sparta 
and it looks like it is true.
But for me the game creation is a challenge by itself, no need to make it more complicated.
If u want build ur IT muscles it is just another task. U have to make 3D game without engine, just with JavaSE or JavaFX and ur gonna look like game developer Hulk 
Heh, I am not saying about becoming IT Hulk as the main goal. I tried to say that you get experienced quite fast and that becomes a benefit.
Imho it all depends on what kind of features you have in your game.
As soon as you use non standard core features you cant use the sdk anyways.
It is nice to quickly place a few objects in your scene but there are tight limits.
So the benefits are, shader node editor and the material editor which are super nice and hard to integrate in your own toolset.
Convertig assets and stuff like that are 10liners. Even possible to do it during the build process from gradle.
I personally go the route of creating my own editor, mainly because i use custom solutions all over the place.
For my real game I am using blender as my scene editor. And wrote a post-loader utility class to auto load my scene in JME and did all my conventions there (ex: model loader based on place holders from blender, LOD loader , Navigation Mesh loader for path finding , Cinematic Motion Path loader , Bone Attachment loader and so on). I create my scene in blender and links models to scene (using blender proxy) and when i export scene i just export Place Holder of models in scene (PlaceHolder is just an empty node with the name of model and it’s location and rotation) so my whole scene size after export is lest than KB. And in JME i load scene and read all Place Holders then add corresponding model based on it’s place holder using my conventional post-loader .
Using this way i could simulate SDK’s scene composer model linking.
And for exporting from blender to JME i am using Xbuf exporter.
This is a demo of all i explained above
1 Like
@Ali_RS Looks like u made some kind of subsystem of SDK system. Greate job i have to say and now we r all know how jme can be used in dat unstandart way.
EDIT: Can u answer are SDK features like terrain generator, apply controls and AppStates to preview scene dynamically isn’t needed for u? U just happy with ur subsystem?
No , I create it in code
see this example
I am doing these also in code. Managing Appstates and Controls in code is easier and faster in my opinion. (and now by switching my game design to Entity Component System Design (using great Zay-ES framework) i do not need to use controls in my game and every thing is done in AppStates)
It is really not that kind to call it a sub system 
and still is a WIP that i extend it as new need comes.
And yes i am happy with this. JME puts your hands open to do as you wish.
Actually before i want to start working on my real game, i put lots of time to study all wiki tutorials and JME beginner guide book and cook book and most of jme example codes. And before all of these it takes me about 3 monthes to learn blender and yet i find new things about it every day. And now i really really love it and use it as my scene creator.
I also created some video tutorials for using blender with jme you may like to watch them.
In my opinion JME is a decent game engine. Its flexibility and fact that its opensource makes it worth to use despite the several weakness. In general, it is quite hard to start a good looking project, JME requires at least a fair knowledge of Java at the begining and the ability to understand shaders. What you can be done with JME? Look at @MoffKalast’s Lightspeed Frontier and my Skullstone.
Personally I don’t like SDK, I use Eclipse for coding so SDK is only a tool for importing models.
Nifty is an nightmare for me, I use it only in one place, made an entryfield using it, I was too lazy to do it from scratch in my own GUI engine.
After few months of making Skullstone (and learning JME at the same time) I was able to do my own rendering pipeline based on deferred shading, with live shadows, many light sources etc. It was not a hard thing to do, thanks to JME’s flexibility.
With JME you write a CODE. Not a script, not any blueprint, there are no ‘creators’ or ‘wizards’. Treat JME as a huge library, use what you want, ignore what you don’t want to use.
Incomplete documentation is not a problem imo - you have source code, you can read it.
1 Like
Thanks for the compliment, but he should really rather look at Spoxel or some recent creations of @thetoucher which are way better looking in terms of graphics. I’m still on basic forward phong rendering.
You’re not the only one. High five? 
That’s where you’re wrong, there are wizards.
The ones sitting in front of their pc writing code.
1 Like
What’s wrong with Phong? I’m using it too, it’s just the formula for lighting the objects.
Well PBR seems to be all the rage these days.
1 Like
The truth is that we would never achieve the visual quality of AAA games, its just a matter of workhours. And imagine a player who say ‘your game don’t have PBR so I will not play it’.
Ingame graphic should be NICE. That’s all. Indie games are not something strange for players these days, their requirements are reduced.
Even the larger companies often fall back to “comic look” in order to let players on older or cheaper computers play 3D games. For many indie games it’s a great step to use 3D at all - as the creation of proper assets may take way longer than pixel graphics or flat colored polygons.