Getting started in JMonkeyEngine

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. :slight_smile:

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 :slightly_smiling_face:
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.

Perhaps you’re thinking of BasicGame-on-Gradle, the JME project template I created.

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)

I believe we do. @RiccardoBlb manages our servers. He would know for sure.

2 Likes

That’s actually a great idea. I think something like that would be extremely useful for everyone, not just beginners, and we could extend it to support community libraries (eg. guis, physics etc.),

You are right jmonkeyengine.org is just a client side website (that uses hugo for templating), hosted on github pages, we chose that to have a front page that could stay on even if we had problems on our backend, however we have a server to support everything else, so server side support is not an issue, we can provide that.

I would still prefer this to be a client side app, if possible, since it is easier to maintain and more secure.
Or it could be a serverside app with rest interface and a js frontend that we can integrate in our site.
However if you have other plans, do as you wish, we run docker containers on the server so there is no constraint on the language etc… once the app is ready i can help with containers and integration so don’t worry about that.

If you need to contact me on DMs or discord, feel free to do that.

4 Likes

Awesome. I’ll have a play and see what I can come up with.

That’s actually a great idea. I think something like that would be extremely useful for everyone, not just beginners, and we could extend it to support community libraries (eg. guis, physics etc.),

That was what I had in mind, “What gui library would you like to use” and list Lemur (probably selected by default), Nifty gui etc

I would still prefer this to be a client side app, if possible, since it is easier to maintain and more secure.
Or it could be a serverside app with rest interface and a js frontend that we can integrate in our site.

Yes, I’m thinking either full client side, or client + rest calls to a spring boot application. One thing that pushes me in the direction of the client + rest calls is it might be nice for the application to query maven central for the most recent minor version within preset major versions, so it will always start users on modern versions of stuff and we won’t be constantly tinkering with the versions it outputs (I haven’t found an API that would give me that information yet though). (Also creating dynamic zips client side in javascript doesn’t fill me with glee even though I accept that it is possible)

1 Like

Myself i use Gradle in any IDE i like.

SDK i use only for assets managing.

Well for new people it could be easier to use SDK, but i belive they were often discouraged because of some sdk bugs (at least i tell for myself since beginning, idk if many of them still exist)

Gradle is not scary, i were learning it too. But it need to be provided first as working example (like it is in current webpage geting-started)

3 Likes

Right, those are valid use cases.
If it can help, i think we shouldn’t even try to support old browsers, using modern javascript apis will make this much easier for sure.

1 Like

I still use the SDK (although many people know that there are many problems with the SDK), one of the reasons I insist on using the SDK is to facilitate development, because the SDK can package the desktop version and the android version with one click, so that I can debug the desktop during the development phase Version, and then directly ported to the android version. In addition, the SDK provides visualization tools to help me build the game scene. I know that blender can also be used to build the scene, but I need to add some flags to the scene, and I will frequently modify the scene, use blender to frequently modify and export and then load it into jme not convenient…

2 Likes

Thank you SDK developers for continuing to maintain the SDK :+1:

4 Likes

Too true :rofl:, many potential bugs of the SDK discourage many novices.

1 Like

Actually I got you covered, I wasn’t aware that someone is having problems there.
It may be outdated (even still using travis), but: GitHub - MeFisto94/nbproject
Looking at it now, it doesn’t seem correct because it has the files in two folders, that was probably before I knew what I was doing (you’d be a fool if you’d believe me I know now :wink: ).

There’s actually https://github.com/MeFisto94/jme3-artificial-intelligence/blob/master/build.gradle
and GitHub - MeFisto94/av-capture

That’s basically correct, to build the module, it needs to be in-tree (part of the suite), at least that’s what I used to do. Now you “just” need to extract the plugin into it’s own repo and pull the SDK and build against it.

Note that the above plugins only compile against the engine and netbeans itself, not against the SDK, for which you’d need to build the SDK as well. I’ll try to get this more smooth with more recent versions, though, as we don’t need to compile the engine our own anymore.

2 Likes

I created a prototype of the JMonkey initalizer. To avoid derailing this thread I’ve added a separate topic on it at JMonkey Initializer

6 Likes

I started fiddling with jmonkeyengine about an month ago.
The sdk seems fine(completed almost all the tutorials without a problem).
The tutorials that were giving me a headache were the ones that import the assets. The wiki doesn’t explain how to import jmonkey assets using gradle, so I made a pr to the docs.
I’m a hobbyist, so I’m probably not using any advanced features, but I have made simple android apps in android studio(intelliJ), and I don’t think there’s any features that the jmonkey sdk is missing, compared to that IDE…

5 Likes