Working around the sdk for custom tooling?

First and foremost I would like to say thank you to the JME team. I have been learning the engine and really love all the thought behind it. This engine is so easy to pick up on compared to other options I looked into. So intuitive I am already loving it even if it is just tutorial stuff.

Now for the game I am designing I need ultimate customisation. Think modding in a way. I want my users to be able to easily learn a system to build their own scenario modules for the game, share them with others, and play them.

From what I have seen so far tutorial wise this should be very possible but for most users not accessable. I do not want the users to have to learn JME or the SDK so I will need to create more accessible custom tooling. I already have the concept of customized story/dialogue almost figured out as well as scripting for the nitty gritty interactions.

My man concern are art assets. I remember reading on the forums that j3o uses absolute paths. Does this mean I can’t create a custom tool for j3o conversion/asset pack generation for the users who want custom art?

Note: just for clerification. I am not saying I do not want to use the sdk I am saying it is probably not feasible to expect the users who want to create modules to use it. Personally I think the sdk is coming out nicely from what I have used so far.

1 Like

The way I did this is that the game associates materials to j3o’s and allows configuring materials instead of relying on j3o’s to already have their material set. Meaning materials configuration and associating them to j3o’s is data contained in my tracks. And my tracks are buildable/savable via my editor.

Modding kinda starts with adding a locator for files to the assetManager (I use a mods folder).

Now, if you want to be able to distribute levels and such, there is one big question: how much risks to the end-user are you ready to accept. From there, multiple possibilities:

  • I accepted none and went with files containing data (none pointing to classes or such) that are read and the levels are built from there. I use json files.
  • levels can be java code… but then you open yourself to maleficient code being potentially distributed
  • you can use sandboxing so the java code is constrained or the scripting code is constrained, but unless you are very sure of yourself (for good reasons), I would sleep badly

Concerning the UI: lemur, tonegodgui and nifty support ways of configuring the UIs via either css or xml.

Ok the decoupling of materials and textures from the j3o sounds like a great idea did not know that was possible.

As for scripting I was planning a data approach. The general idea was to build a visual system to allow the content creator do define conditional data so they can for instance define a new ruleset. Think of ruleset as in Dungeons & Dragons or whatever. The game can then use these rules in the scenario. Also it would allow them to bind animations to actions. In the case of custom art. In no way will they create executable code. In the back essentially the tool would build a Json like data structure. Maybe not JSON itself have not decided if I want that or something more customized to the purpose.