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.