A little while ago I mentioned that I was working on a scripting system for jMonkeyEngine. I still am! I’ve however come a bit further and can now show the whole flow. So I’ve created a video since that is probably the easiest way to explain things.
What’s the idea?
The idea is to give designers and non-programmers access to gameplay features. Macaq means to create a base to which other developers can add their own game-specific script requirements without having to program everything from scratch.
So what is the background to all this?
Well, before I became a programmer, I worked for many years as a (level) designer in the games industry. All game engines had an editor and some way of scripting things visually. Those two are pretty much required for a serious game unless you want to have programmers make everything but the art itself. jMonkeyEngine already has the SDK and SceneComposer with which you can do a lot of things, but beyond manipulating assets you still need to be a programmer to do things.
When I was developing Hostile Sector, over 5 years ago, I laid out the foundations for a script system so that I would be able to make missions more easily. I didn’t make an editor then, and manually connected things in a specific mission class (this was also before AppStates, at least before I got familiar with them). Earlier this year I refactored the script classes for some new prototypes I’m working on and some months back I thought it would be a good idea to create an editor for it all. I had no idea of the work required.
How does it work?
There are a number of components and layers.
First of all there’s the logical components. They exist mostly independent from other layers. They interact with each other and other objects through LogicConnections. These come in two variants, In and Out. by connecting them you form a script flow. These are loaded and saved using JmeExporter and JmeImporter. They are the only things being saved.
Between logical components and spatials (where required) there are Controls. These can also have in and outconnections and are meant to separate the logical layer from the “worldly”. None of these are saved but are instanced each time the script is loaded.
An AppState is responsible for loading the script during startup/runtime. It handles connecting everything and finding the spatials to add the script Controls to.
The editor is based on netbeans. It’s meant to be added as a plugin to the SDK and running alongside (but currently not connected to) the SceneComposer.
What’s the plan?
Well. The short term plan is to make it available for testing. I will probably keep the codebase pretty close for quite some time but eventually make it open source. I still need to add a few components to make it usable.
I want it to detect and make available packages of additional components. This is a requirement as anyone using it will need components adapted for their project.
Interaction between SceneComposer and MacaqEditor would be nice. At least for selecting spatials, but also for running scripts directly in the editor.
Then I have a whole bunch of things I want to add to enable more people to get into open source game development.
I will continue to update this post and thread with more info.
Critique on approach is welcome. Specifically: If anyone has an opinion on using the name of a spatial as identifier, I’d like to hear it. Should I go for j3odata instead? I personally don’t use it much, so I need some input.
Is “j3s” as an extension taken? I thought it would be suitable, but I could go for something macaq related instead.
Generally, I believe in making things open source when it adds value to do so. When you want others to contribute to make the project better, for example, or for longevity of the project. I also want the code base to reach a certain level of maturity before releasing it. Thirdly (not that it’s likely to happen), I wouldn’t want anyone to fork it and run off in their own direction when it’s so early in development. I want it to have a solid foundation before letting anyone else tear into it
To answer your second question. There is a big point in making it, regardless of whether it’s open source or not; That is to enable others to USE it. The main point of it is not to have others expand the editor, but the scripting components. They are two different things. The editor is just there because it has to be.
At this point I’m just happy with how far I’ve gotten and would like to show it.
I haven’t worked with ES’s so I can’t give a definite answer, but I don’t see a reason why you wouldn’t be able to do that. The script could very well call a control or any other object which is responsible for ES object creation/deletion.
Does it require spatials to work correctly or may I simply “wire” custom objects? I’m working on a library that connects dialogue and answer options (like on a visual novel).
Right now I mix a data JSON and custom code, but wiring together everyting visually would be cooler.
The original script system had support for showing nifty dialogues. But that was coding only, visually it does have some other requirements and the architecture has changed somewhat since. But it’s on the list! I have that requirement for my personal projects. First stage is for dialogue popups, but I would like to handle dialogue chains as well, eventually.
When this is loaded (with i18n of course), it shows the text and the portrait, then you are offered 2 options:
with “OK”, is executed a java class (DetatchDialogue.java)
with “Next”, is loaded the next dialogue (tutorial6)
It already works, so if you want to integrate it on Macaq I would be happy.
OK. Well, it’s a bit early to take on that kind of request
I think that even if I don’t get around to implementing it in core, it’s just the sort of thing that should be possible to build on top of it.
This is an awesome idea! I have a few friends who have little to no knowledge about programming that have talked about wanting to learn java and Jmonkey so they can help with some small parts of my game in their spare time, but they don’t quite have the motivation or the foundation in programming to help out in a significant way. I’m looking forward to using this editor as a way to turn my friends into useful helpers in the future
@Pesegato you may be interested in Yarn. It pretty much does exactly that. I’ve been using it for a while and it’s been really easy and reliable to use.
You gotta write a new json parser of course, or at least adapt your current one. I found that storing all text nodes in a hashmap was pretty good for moving back and forth as you can always get the next one via the key, which is contained inside the node itself.
Ah well, worth a try I suppose. What are the extra options you need btw? I usually encode all the extra data in the second line and the parser does the job of executing it.
I’ve uploaded another video with a new example of scripting possibilities, this time moving into the realm of actually usable stuff. At the same time, moving outside what will be included in the core, since this is a bit too specific per-game. Still, it will be included in the examples project and can easily be expanded for use in other projects.
The video shows how to set up a simple patrol behavior.
Otherwise I’ve mostly been in refactoring hell this week, and still have a few issues left to solve. Then it’s a bunch of boring editor stuff; Right now you can only save once. There’s no undo (probably won’t be for quite some time either).
I need to think a bit about unloading/reloading scripts and such. I also need to look into the cinematics editor that was never finished. Controlling cinematics is one of the areas where there is a direct use for Macaq.
This is a nice and interesting trick, however you basically worked around the limitations by putting a “program on a line”…
My “problem” is that my tool is rudimentary, but gets the job done faster (for example, it already assumes that you have at most 3 choices and automatically creates the link for the next dialogue on the chain).
Also this is not Java, so is not easy for me to add features.
