Given the current state of the SDK, should we continue recommending it to those getting started with jMonkeyEngine?
What alternatives exist, or could be created, to meet this need?
I think we should start by asking what’s the meaning of an SDK and why jME’s has to be in NetBeans.
Possible answers:
- Because it facilitates the understanding of jME for beginners.
- Because it is makes it more convenient to import models from other formats to .j3o.
- Because other engines have their own SDK.
- Because it makes it easier to design game levels and scenes.
- Because (add your reason here).
IMHO all of those answers are valid, but I don’t see why the jME SDK needs to be built inside of NetBeans. Oh yeah, because it is already there and we don’t have enough people to work on a standalone tool. I know and I appreciate the effort of everyone involved in the SDK, thank you!
But the thing is what if instead of doing something inside NetBeans, which we know has issues, all efforts were directed towards a standalone tool and, as a bonus, making jME more independent in the process?
2 Likes
Start up a project. Find contributors.
This has been tried at least twice publicly.
With limited contributions, the tiny amounts of effort people seem willing to give would be better spent making small improvements to an existing tool than to make small changes to a non-existent tool. But if you are willing to put the effort in then I will not stand in the way of someone “getting it done”.
Writing an IDE from scratch is a huge undertaking which is why folks tend to pin it to one or another already existing IDE… which then turns off everyone who religiously will only install one IDE on their system.
3 Likes
I used to love the idea of a new IDE/SDK for JME (even though I like the existent SDK a lot), but the last attempt went so bad that I think sticking to the SDK is best.
I’d love to see something new, but the excitement for a new SDK alternative seems to ultimately end in wasted productivity, and in hindsight the last attempt felt like a “too good to be true” idea that ultimately diverted attention away from the actual SDK.
I recall the author of the new Particle Monkey System mentioning something about wasting a bunch of time making a visual particle editor for the failed IntelliJ based SDK last year, and it really sucks to think that we could instead have had that feature added to the SDK if we hadn’t gone down that path in the fist place.
So I’m in full support of sticking with the current SDK.
I can speak from my own experience that it made the process of getting started with JME waay easier. I knew nothing of gradle (and theres no chance I was gonna figure it out at that time) and I was an eclipse fanatic prior to JME. I nearly gave up because I was too dumb at the time to setup the engine in eclipse, but thankfully I let go of my meaningless attachment to an IDE and just downloaded the SDK.
I also feel as though anyone who can’t figure out a new IDE is going to ultimately run into bigger problems using the engine to try and make an actual game, so I don’t think we should take IDE preference seriously at all when it comes to choosing an IDE for an SDK. They all have their problems, but at the end of the day the IDE is not going to break or make a game.
2 Likes
To be fair, I’ve wasted a lot of time trying to build a plugin for the existing SDK but it is a little above my head on how to make that even work. I think the farthest I ever got was when I built it into the SDK itself but I had to scrap that when everyone pushed me into making it a plugin instead of replacing the existing emitter.
My biggest issue with the existing SDK has been its extensibility. It would be great if there was a way to extend its functionality without having to figure out how to make netbean plugins.
4 Likes
it’s really hard to use SDK for me, I’ve tried couple of time, watched all the tutorial videos from wiki, and I still feel it too clunky and not intuitive. So currently I’m trying to create my own scene-composer =D
3 Likes
I tried to remember my own experience.
When I startet I also somehow started coding with Java, had a bit of general experience before.
So maybe Im not an example for the typical user of JME.
Anyhow I have not realy used the SDK but installed the versions available since then. I wanted to get used to the SDK of my choice.
I went through the tutorials then and made my own network example. As I do breaks between working I still look and use the examples from them.
What I would need as a new user:
I needed a bundle of all the necessary Jar filles. When the current JME Version came out I could not locate them. At that time (JME was on Google Code?) I could not find it.
So in the end I somehow got the Jar from the SDK - as they had been there in one folder.
Documentation and examples of JME are nice and its well done. You can work with that.
I also had a look to ready examples and code from other users.
Getting startet with JME for me means:
- Have a download button for all Jars needed
- Have a “install and use JME for dummies” manual
- Have a step by step example and tutorial
- Maybe have a example game ready for download and to compare
Most of it is already available at jMonkeyEngine | Quick Start.
So not to much to tweak there.
As an example. I still ike the Neon Vector shooter, or maybe the vehicle project etc.
About the SDK: There is not enough workforce available. So use the old SDK, if it is used and needed add and improve what users already did.
For my part: I only need it to convert models.
3 Likes
I started using JME some months ago. Although I haven’t really done any game dev or 3D graphics programming before, I do have a lot of experience as a Java dev and professional software engineer, so I don’t know if I fit the typical newcomer profile. Anyway, here are my thoughts:
-
I found the SDK unpleasant enough that I considered looking for another engine/framework, until I dug around the wiki a bit more and learned that I could just set up a normal Maven/Gradle project in my preferred environment. So, I think it could be useful to write more prominent wiki documentation to explain how to set up a project outside the SDK, along with recommendations for 3rd party libraries (such as Minie, Lemur, Blocks, etc.).
-
Although I’m sure a good SDK would be easier for newcomers, I’m not convinced it’s necessary – for example, LibGDX seems to do pretty well with project generator tools, so maybe such a thing would be useful for JME (especially if components are removed from the core engine in 3.5 onwards; then a project generator could simply provide checkboxes for all of them, as well as recommended 3rd party components).
-
I do occasionally see mention of various visualization tools in the SDK, such as model viewers, terrain viewers, etc. This makes me wonder if I’m missing out on anything really important or convenient. I have no idea how these things are implemented in the SDK, but would it be at all feasible to extract them into standalone tools? Might not be great for complete newbies, but it would be good for experienced programmers who are just new to JME.
10 Likes
How about this? Dead but maybe still better than the SDK:
We could then suggest to use a gradle compatible IDE…
4 Likes
Deprecated, there are many bugs, the project is great if maintained but its now non-dependable & hard to maintain because the codebase is not obvious from the beginning, seems it was not planned to be maintainable.
3 Likes
On the “Gradle is scary for beginners” point.
Spring boot provide a utility where you give it some basic information and it produces a zip that is a starter project that you just open in any friendly IDE. Would that bridge the gap? It would of course be all code from there, no SDK utilities to help you design things, just you and a blue cube. Not sure what https://jmonkeyengine.org/ is written in, is it traditional html + js (and I’m seeing some md files) with no active server side?
I’d be up for creating something like that if people thought it was a good idea. (Although it would be easier if the site had a server side)
Although it would be interesting to know the experience of someone who was new to java and started with JME, I can’t really imagine that myself, 3d game programming is HARD. JME does a good job of making it “as easy as possible” but “as easy as possible” is still hard. I went console apps → 2D toy games → android apps → 3D games (intermingled with things people would actually pay me for), which felt like a natural progression of difficulty
6 Likes
Yeah, I think if you don’t already know Java and therefore don’t already have an in-built language preference then something like Unity is better. Then for a while at least you can pretend you could drag-and-drop code a whole game.
4 Likes
Is there anything special about the SDK that could be improved (besides the gradle template, that is underway).
This is the thing I don’t understand. Besides “religious” reasons, I don’t understand why people seem to be annoyed by whatever is running underneath as application framework. You can use your favourite IDE together with the SDK. Removing the RCP basically only makes us reinvent the wheel. Besides that you loose a lot of integration (e.g. auto complete assets / right clicking on them, basically combining code and models as well as the editors themselves). Imagine you’d need to find the correct swing application from a collection of 10, browse to the folder with the dialog each time etc. Then you want to have a look at the terrain together with other props, so you need another application etc.
On the other note: It may be an extreme POV, but from multiple communities I have the feeling that, if you don’t know Gradle/Maven and can’t take the day to learn it, you will stop developing after copy and pasting a few examples anyway, because you are overwhelmed by the concepts anyway.
And again to the SDK: What would a rewrite really bring to the table, besides looking more modern?
6 Likes
I think if it were easier to add things to the SDK then that would help. It’s quite a big pill to swallow and turns most people off… and the existing plug-ins aren’t necessarily the best examples, either.
Need an “SDK plugins for dummies” or something.
One feature most rewrites have (all so far) is never getting finished enough for widespread adoption. 
8 Likes
This is my biggest problem with the SDK. Gradle support WAS the other one but I think that is fixed now. Most game ideas that I’ve toyed around with would benefit from some sort of custom tooling integration.
2 Likes
Just to be clear, I wasn’t suggesting that the SDK be rewritten; as for chopping it up, you make some good points as to why it should remain integrated. However, I get the impression that it’s difficult to maintain and contribute to, hence my wondering about breaking it up. (I do realize that I can just use the SDK for the viewer plugins, and IntelliJ for everything else, but I haven’t gotten that far yet with my projects.)
Alas, I have to admit that my initial reaction to the SDK was largely knee-jerk and religious. I’ve grown accustomed to the code analysis and project organization tools in IntelliJ, and Netbeans seemed less capable by comparison. Also, the font rendering was pretty bad – trivial, I know, but it all comes together to make a certain impression, and since I already have a favorite IDE…
As for concrete suggestions and observations that might actually help … well, I remember having trouble setting up the asset paths and test-data jars in the SDK; the wiki docs seemed to be out of date, or maybe out of sync with what the SDK was actually doing (I know that’s vague, but it was several months ago and I haven’t looked back after setting up my JME projects in IntelliJ). I imagine this is the sort of thing that a new Gradle template would fix?
Cool, thank you 
Nehon had previously developed Bootmonkey with Swing. It had no option for third-party libraries I guess. It will be nice to make an official web-based project creator with a checkbox for third parties (like Minie, Lemur, Zay-ES,…)
I think the JME store has a server-side. @sgold may know more.
2 Likes
As I recall, Bootmonkey used NodeJS or whatever… which sent me down a rabbit hole that I never did get working.
But it’s the right idea.
No, I am asking if JME has a server so we can use it to host the web-based project initializer tool? (similar to https://start.spring.io)