More Editors!

The Zone Editor was made so that any kind of game data could be edited in a single coherent way. However very often specific elements benefit from having custom editors. The map editor is good example of that - it is much easier to create a map using a 3d view than in text or graph format.

Some time ago I added an additional editor for Entity Instances and now the time has come to add more:


Editing particle effect emitters.

 

Editor for materials. Works for all MaterialDefinitions.

 

Viewer for geometries.

I made a small framework for this type of editors, so adding a new one is as simple as implementing a function that creates a spatial from a object definition.

Simplifying scripting

Using scripting languages in game development has been common for years. And for good reason - most of them are easy to learn, and the lack of compilation decreases iteration time. Right now pretty much every major game engine has a scripting layer. Zaria too. It uses slightly modified JavaScript running on top of Rhino.

During my previous game projects I also used a variety of scripting languages: UnrealScript, NWScript, Lua etc. While working with them I found one thing really annoying - in most cases without browsing through a wiki or looking through documentation I had no idea what the available API was. Going through various web pages, or even printed documentation made it difficult to get back into coding. It's easy to loose focus and more difficult to get it back again.

With compiled languages it's easier. Their strict structure makes it simpler to implement various code completion and suggestion tools, which in turn makes exploring the available APIs quicker.

What Aurora (and Electron) toolset had, was a searchable, drag'n'drop list of all available script functions right next to the editing area - extremely useful stuff. I really missed such a feature when working with Unreal Engine 3 on Blade Lords.

In order to not repeat past mistakes and learn from good examples I decided to implement a similar feature in the Zone Editor.

A searchable palette on the right lets the user drag any available function right into the script. Functions are grouped by category, which can be defined by whoever creates the script function. Tooltips also provide some basic information on what the function does. Also to make it even more easy, other scripts can be dragged from the file view into the editing area, which will result in a properly resolved import.

On the code side adding a new script function is really easy. Just create public static method and add the @ScriptFunction annotation. The editor will parse this data and show the function in the palette.

There are other features I can imagine that could further enhance script writing, but for now I think this already makes stuff much clearer and simpler.

Adding lights to entities

I implemented static lightmap support some time ago with nice results. However moving stuff did not yet have a lighting solution.

I wanted to have something in which the data for lighting would be common for static and dynamic objects. What I what I came up with is to save the light data (position, color, power, radius) that is used to generate lightmaps and use it also to create localized lights for entities.

By localized I mean that each entity creates its own set of lights, which affect only it. This allows for attaching quite a lot of them, as the lights will affect only a small amount of geometry and gives a lot opportunity for LOD optimizations. The only down-side is that this method will not support shadow casting. However, in the end, this is not that big of a drawback, as such an amount of dynamic shadows would kill the framerate anyway.

I created a component for that, so making an entity dynamically lit, is now trivial. The first test can be seen here:

The map from which this video was taken:

The scene had 8 lights and with 7 entities the fps was around 2700. So far not bad.

Multiple files from a single wizard in NetBeans

I've been fighting with NetBeans modules recently. I wanted to add templates for common class types used in Zaria. Half of them, in order to be useful, go in pairs: Object + ObjectDefinition.

To make the process as easy as possible, I wanted to be able to crate both files using a single dialog or wizard. Meaning: If I choose to create a new EntityComponent then both NewEntityComponent.java and NewEntityComponentDefinition.java get created with all boilerplate code in place.

I managed to do that. However, either because of bugs or weird design decisions, it is far from straightforward.

Ok. So how to do it?

First have a look at https://platform.netbeans.org/tutorials/nbm-filetemplates.html

It shows how to create a new module that will generate a new file from a template. It is a good beginning and in theory should be all you need.

The annotation @TemplateRegistration in the field content can take multiple files. Spec says that the default New File wizard should then create both files using the input templates.

However the reality is different:

• Only the first file is created. To fix this you need to create your own custom wizard.

• If you want to generate java classes from templates, you need to call the template file xxx.java.template Otherwise the module will not compile.

 

How to create your custom wizard?

Although it shows more than needed here, a good initial tutorial can be found at https://platform.netbeans.org/tutorials/nbm-wizard.html

In the New Wizard dialog choose New File instead of Custom. This will remove some of the complications and will make the wizard automatically work with New File menu in NetBeans.

Annotate your wizard as in the first tutorial:

   @TemplateRegistration(  
     folder = "Zaria",  
     iconBase="eu/cherrytree/zaria/modules/filetemplates/zaria_file.png",  
     displayName = "#EntityController_displayName",  
     content = {"EntityController.java.template" , "EntityControllerDefinition.java.template"},  
     description="EntityControllerDescription.html",  
     scriptEngine = "freemarker")  

   @NbBundle.Messages("EntityController_displayName=Entity Controller")  

And the whole trick is in the instantiate() method in your WizardIterator:

    
     private FileObject getDefinition(FileObject fileObject)  
     {  
         for(int i = 0 ; i < fileObject.getParent().getChildren().length ; i++)  
         {  
             FileObject obj = fileObject.getParent().getChildren()[i];  
               
             if(obj.getName().equals(fileObject.getName() + "Definition"))  
                 return obj;  
         }  
           
         return null;  
     }  
       
     @Override  
     public Set<?> instantiate() throws IOException  
     {  
         // Prepare the arguments for passing to the FreeMarker template.  
         String name = (String) wizard.getProperty(GameObjectVisualPanel.nameProperty);  
         Map<String, Object> args = new HashMap<String, Object>();  
         args.put("name", name);  
   
         //Get the first template.  
         FileObject firstTemplate = Templates.getTemplate(wizard);  
           
         // Find the second template.  
         FileObject secondTemplate = getDefinition(firstTemplate);  
                   
         DataObject dTemplate1 = DataObject.find(firstTemplate);  
         DataObject dTemplate2 = DataObject.find(secondTemplate);          
   
         // Force usage of the script engine.  
         secondTemplate.setAttribute("javax.script.ScriptEngine", firstTemplate.getAttribute("javax.script.ScriptEngine"));  
   
         // Get the package.  
         FileObject dir = (FileObject) wizard.getProperty(GameObjectVisualPanel.pathProperty);  
         DataFolder df = DataFolder.findFolder(dir);  
   
         // Set the names of the file:  
         String targetName1 = name;  
         String targetName2 = name + "Definition";  
   
         // Define the templates from the above, passing the package, the file name, and the map of strings to the template:  
         dTemplate1.createFromTemplate(df, targetName1, args);  
         dTemplate2.createFromTemplate(df, targetName2, args);  
   
         // End.  
         return Collections.EMPTY_SET;  
     }  

It would seem that there are two issues:

• The second file in the TemplateRegistration is quirky. It would seem that the templates are always put one after another. There no are guarantees when it comes to ordering of FileObjects in regads to templates. Therefore you will need your own trick to associate them with each other. In my case name is sufficient.
• The script engine is only assigned to the first file. Therefore you have to copy the ScriptEngine attribute from the first template to the others.

With these two tricks everything seems to be working fine :)


BTW. If you need to get the currently selected source directory, use:

         Project project = Templates.getProject(wizard);  
         Sources sources = ProjectUtils.getSources(project);  
         SourceGroup sourceGroup = sources.getSourceGroups("java")[0];  
               
         FileObject src_root = sourceGroup.getRootFolder(); 

I've been testing this in jMonkey Engine SDK 3.0 which is modified version of NetBeans 7.x. Maybe NetBeans 8.x does not have this issues. However the Internet suggests that as of June 2014 people are still having problems.

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 L2FProd.com 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.

A gaming keyboard for a game programmer.

After years of using the cheapest PC peripherals I could find, I figured I should finally get myself a decent keyboard.

I started looking with Logitech and Razer (the only two brands making high quality peripherals that I knew about). And I almost chose the Razer Deathstalker Expert.

It seemed like a nice choice. The reviews were good. I could squeeze all of its basic functionality on Linux (but no macros, probably no backlight control etc.). However I encountered this post on Phoronix and I learned about a German manufacturer called Roccat. Apperently they also build high quality peripherals but you can get proper Linux support, through open source drivers.

I didn't hesitate long and chose the Roccat Isku.

So after finally getting my device and using it for a couple of days, I'm really, really happy. Not only it is a very good, very responsive and very comfortable keyboard but I can also fully customize it using a graphical tool.

So I hooked up my NetBeans shortcuts and it works like a charm. Auto complete, refactoring with a press of a single button. Pure awesomeness.

I am yet to do any serious gaming with it. But for a programmer it is a great device. I will definitely be recommending it to anyone.

Steam on Fedora 64-bit

It's really nice that Steam is now in RPFusion repository for Fedora. However getting it to run is not fully straightforward on a 64-bit system. If you try you will most probably get the message:

OpenGL GLX context is not using direct rendering, which may cause performance problems.

To fix this some 32-bit packages need to be installed. To do that you need login as root and run:

yum install pulseaudio-libs-glib2.i686 libao.i686 esound-libs.i686 alsa-oss-libs.i686 alsa-plugins-oss.i686 alsa-plugins-pulseaudio.i686 audiofile.i686 mesa-libGLU.i686

Then depending on the graphics card vendor 

For NVIDIA: yum install xorg-x11-drv-nvidia-libs.i686
For AMD: yum install xorg-x11-drv-catalyst-libs.i686