Introducing Hoolock Code Generator


I’ve been working on some tools to simplify development with jme, especially targeted at new users. The goal with Hoolock is to avoid having to write tedious and error prone boiler plate code. It uses the Netbeans Generator API, so the same that lets you generate constructors and getters/setters, etc. I’ve put together a video that explains one of the two features it currently has; generating pattern and methods for an ActionListener class.

The other code it can generate is a Savable pattern with read and write methods for all fields in the class.

I haven’t uploaded it to any plugin repo as of yet; it’s only available from the github repo (but an unsigned nbm exists): GitHub - neph1/HoolockCodeGenerator: A code generator plugin for jMonkeyEngine3 SDK

If you have any ideas for other usable things it could generate, I’d love to hear about them.


Maybe the projects at → it will be way easier to just use it from the ide than to download and unzip(Still, the initializer is REALLY useful)
also, code generator for appStates will be really helpful.
Really awesome Project so far! I no longer have to write input manager code for every game :slight_smile:

Can this be included in the SDK plugins download manager ?

The initializer is designed to be APIs first (with the web ui calling that api). So if someone wanted to use it’s APIs to provide functionality in an IDE plugin that should work fine.

The API is documented at Swagger UI


A project creator is somewhat out of scope for this project. However, there is a brand new gradle project creator coming in the next version of the SDK. Perhaps that could be expanded upon.

It’s interesting that you mention AppStates, since I have some vague plans to do things with AppStates in the SDK. But when you say you want to generate them, what do you have in mind, then? They’re so generic that it’s difficult to assume anything about them (that BaseAppState doesn’t already do).

Glad that you see the benefit of it!

Certainly. Some kind of integration with the SDK would be great. I’m not sure what the status of auxiliary plugins are, though. Regardless, I will do some kind of official wrapping around it. Whether I put it in a suite of plugins and create an update center for them, or something else.


I haven’t run the SDK in 5-6 years or more so maybe this stuff is still there.

…when I first started using JME and downloaded the SDK for the first time, on the right there was a palette of code snippets for creating the blue cube, adding lights, etc… Between those and the tutorials, I was up and running with JME in about an hour and had my first block-world prototype working 2 days later.

Stuff like that is super helpful if it isn’t there anymore.

As for an app state generator, in my text editor I can setup templates for different file patterns. Whenever I create a new * class it fills in the class, sets up a logger, and adds the initialize/cleanup/onEnable/onDisable methods for me. Being able to create an bare bones BaseAppState extension ready to be filled out is super handy.

Another common app state “type” I create so often that I’ve considered adding a separate template for it are app states that manage their own root node that they attach/detach on enable/disable. Sometimes to the rootNode but most often to the GUI node. For pop-up UIs, menus, etc… All. The. Time.

The code palette is still there. I wonder though if there are any tutorials about it. Otherwise it might be easy to miss.
The generator is different from the palette, though. Whereas the palette produces static code snippets, the Generator api accesses the class structure and can add dynamic code depending on what’s there, or in the case of the example here, using a dialogue interface.

AppStates managing their own root node? That’s a really cool idea, and would be really easy to add to the palette.

1 Like