Monday 21 April 2014

Introducing the Zone Editor

During Ludum Dare 26 (my entry) and 24 I lost a great amount of time because of ineffective tools. I used to use Tiled Map Editor and jEdit. However they proved to be insufficient (at least for creating what I have in mind). I realized that in order to decrease my iteration time I need a real 3d game editor. jMonkeyEngine doesn't come with one and the Scene Composer is far too simple.

I try to use as many already existing solutions as possible, so I started looking for stand alone, 3rd party, 3d level editor. Unfortunately I couldn't find a 3d counterpart of Tiled, everything I encountered was closely tied to the engine it was built for. The best solution I could find was GtkRadiant, which although powerful and flexible can hardly be used outside id Tech. In the end it meant that none could be made to work with the jMonkeyEngine without heavy modifications.

I decided to build something on my own.

Zaria Framework is built to be as data driven as possible. Almost all game objects are created from object definitions that are stored in ZONE format (Zaria Object Notation), which is a slight modification of JSON. The editor would use this format directly, so I called it the Zone Editor.

The first thing I wanted the editor to do is to be able to edit game files for any executable built with the Zaria Framework without recompilation. To achieve that the editor can read in any .jar file at runtime and parse all object definitions stored there. Using the Reflections library I was able to easily get all object definitions also from the classpath.

The next step was to create a text editor that would work with ZONE format, with proper syntax highlighting, validation and a palette of all object definitions that can be used by the framework.

The text editing part is built around the RSyntaxTextArea which had a lot of stuff already built in that is needed for heavy text editing. All I had to is create a ZONE syntax definition (for syntax highlighting), a parser (for validation) and a transfer handler (for drag'n'drop from the palette).

After that I had to create a visual editor, that could speed up the process of editing and creating ZONE files. Because a ZONE file is a list of object definitions, with some of them having relations between each other, an object diagram editor seemed appropriate.

I managed to find a great graph rendering and manipulation library called JGraphX, which allowed me to have a first prototype up and running in a week.

Apart from that a property editor was needed. The only ready solution I could find was part of the Common Components, which has not been supported since 2007. I had make so many modification to get it up and running, that I ended up ripping out only the property editing logic and integrating it directly into the editor source (thankfully everything I use is FLOSS).

Finally a 3d map editor could be created. Right now it can be used to place and edit map geometry, entities, markers, triggers, collision volumes and bake lightmaps.

The rendering is done by the jMonkeyEngine. The engine provides a rendering context with a Swing Canvas, which makes it easy to embed in the app window. The way the map is rendered and managed is different from how it is done in game. There is no streaming, no lighting, which makes all of this easier to manage and manipulate. To make it work all objects that can be placed on the map, provide a Spatial that is used for rendering and manipulation in the editor.

One of my favorite features of the editor is integration of the Sunflow Global Illumination Rendering System, which enables baking of high quality lightmaps.

Because the view in the map editor is simplified for performance reasons, a built in map viewer had to be created so that the map could be viewed as if in game, directly from the editor (with all geometries in their final form, entities functioning as defined, LOD mechanism running and all post processing effects in place) .

Writing the editor in Java proved to be a good idea. A lot of work I'm doing in the framework benefits the editor and vice versa (validation, serialization and other mechanisms are common between the two). Swing also was good choice, even with it's quirks. It is very mature, so almost all problems I encountered were already solved and there is a lot of 3rd party libraries available, which saved me a lot, a lot of time.

There is still a great deal of work to be done. However already the editor can significantly speed up the process of making games using jME 3.0 and the Zaria Framework.