TRVE KVLT

Small PSA

As the development of the isometric RPG is progressing, it needs have its own proper identity.
Therefore all development on the game itself will be done under the name of the game studio I'm setting up:

TRVE KVLT GAMES

That also means this blog will only post info about the Zaria Game Framework and general Game Development and Tech stuff.

For more info on the game and the studio:

• Webpage: http:/trvekvlt.eu
• Blog: https://trvekvltgames.blogspot.com/
• Twitter: https://twitter.com/TrveKvltGames
• Instagram: https://www.instagram.com/trve_kvlt_games/

Split View

The work on the isometric RPG is progressing quite well. Even though the scope of the game is fairly limited the amount of assets that needs to be created is staggering. Given the limited resources I have, the only way to progress is to automate as much as possible and optimise every step of the creation process. To that end I have created a large amount of template assets as well as scripts which are used to process them. 

And although I will write more about the process and automation I have employed. This post is about editing scripts. 

So far I have been using mostly three text editors:

• NetBeans (for Java code)
• Atom (for Python, GLSL and bash)
• Zone Editor (for game and editor scripting)

Out of those three the last one is the least mature and when I continue developing the game a find more and more features I feel like adding which are already present in the other two. Recently I found myself editing older scripts and needing a lot of others for reference, which resulted with a lot of tab switching. I wished I had more than one script on screen. Therefore the latest addition to the Zone Editor is the split view.

You are now able to edit two scripts or asset files at the same.

It's also possible to have one file in graph view while another is in text view.

Of course you move tabs around and all of the menus are sensitive to the state and type of file that is currently in focus.

There are many other modifications I need to do. However given how the editor is structured it is fairly easy it extend and improve.

Printing!

I always found it useful to have something tangible in my hand when trying to solve issues or debugging. I've been known to print out code or game data just to have a condensed overview of what it is I'm working with.

At some point I figured it might actually be useful to be able to print out game data directly from the game editor. It might be even better if the data was formatted in an easy to read way.

So... After a couple of evenings looking through how printing in Java works, and trying out different approaches, finally the Zone Editor has a proper printing feature :)

It prints out the data in a hierarchical way, where definitions which are linked to are shown next to the field they are being linked from. The result looks a bit like YAML, but is only meant for human readability. The actual data is still stored in the form of (customized) JSON.

Automating Asset Creation

I really hate repeating tasks.

That's one of the reasons why creating art assets can be such a drag for me: because a lot of actions need to be repeated over and over (plus the requirement for manual precision, but that's a different story).

Thankfully most of the tools out there can be automated to some extent. Allowing for certain tasks to be scripted out, rather than clicked/typed out again and again.

Good case study would character animation in the isometric RPG I'm working on right now:

• Each character has 29 animations.
• Each animation requires 8 sides to be rendered.
• All individual sprites need to be added to a texture atlas.
• Sprites in the texture atlas need to have empty margins removed, in order not to store useless information. 
• The texture atlas itself needs to be compressed.
• Texture atlas requires information for the game engine where all sprites are. 
• Animations need to be mapped to actions in game.
• Animations need to be mapped to specific directions in the isometric world.
• Certain animations need to be marked as looping.
• Certain animations need to be mapped to tags, which are used to start animations in-game "by type".

That is a lot of work. Manually that would be days. Even worse if mistakes were made.

And believe me, initially I did all of this by hand. But with every character I would automate more and more. And at this point adding a new character in game takes about 45 minutes, instead of days, out of which most is waiting for scripts to finish.

What I would like to show here is specific to my use case (2D isometric RPG using my Zaria Framework). However the logic and principles can be adapted to pretty much everything. Plus I'll add some useful Blender Python scripts.

1. Prequisites

First of all some preparation.

What we will be doing here, is importing a humanoid character and applying to it already prepared, rigged skeletal animations.

Therefore we will need a character model. In this case, a royalty free model in FBX format, in the (kind of) T-pose.

We will also need all of the animations used, set up for a base character. With the camera positioned at the proper angle and distance as well.

Essentially what we will be doing, is substituting the character in the base animations for the new imported character, using the existing rig and rendering for all 8 directions.

2. Mixamo

For the second step we will be using Mixamo. Its auto-rigger is just the help we need. The additional fact of having A LOT of good looking animations ready to use, makes it even more appealing of a tool.

If you have a different way of preparing rigged characters in a consistent manner, you can skip this step.

To get the model correctly into Mixamo it needs to be exported as FBX, with only the mesh and texture inside.

Thankfully Blender can do just that. Just click export to FBX and use the settings below:

One of the most important elements being setting Path Mode to Copy and making sure that textures are packed inside the output file (icon next to Path Mode).


When uploading to Mixamo you will be asked to locate a set of main bones, for the auto-rigger to kick in.

Once that is done, download the rigged T-pose as FBX.

 3. Blender

Now that our model is rigged exactly as our prepared animations, we can run some magic Blender Python scripts.

This one imports the input FBX file into the input blend scene and substitutes already existing model for the imported one. The way it does that, is relying on names, therefore naming of (at least) the model root needs to be consistent in all animations.

Source: https://wtools.io/paste-code/y3A

This script renders all frames of an animation into png files. It also takes into consideration all of the directions. What is also important here, is that the naming is consistent. Each animation, for each direction, has the same name for each character. This will be useful later.

Source: https://wtools.io/paste-code/y3B

Finally we will run the scripts.

I ran them from a bash script which would run the first (to create the animation blend file) and the the other (to create the animation frame sprites) for all blend files in the input directory.

I also ran two of them at the same time to max out all of my processor cores.

Source of the bash script: https://wtools.io/paste-code/z1q

Here are both scripts hard at work.

The processor usage is quite significant. I found that running two of them at the same time is most optimal. And in my case generating all sprites took about 20 minutes.

The result ended up being over 7000 frames of animation.

4. Zone Editor: Texture Atlas

Now that we have all animation frames, we need to put them in a single texture. As this is a 2D game, graphics memory will be used heavily. Therefore we need to optimize our textures as much as possible.

For that we will be using the Texture Atlas Builder in the Zone Editor.

It has a number of ways to optimize the texture:

• It removes all duplicate frames.
• It cuts out all of the empty margins from all of the images.
• It can compress the texture using DXT.

Additionally it creates data structures, that are read by the game, which map specific parts of the image to specific animation frames.

The process (especially looking for duplicates part) can be quite CPU heavy, and take a good while. However it is definitely worth it.

The result is a 8192x4096 pixels texture.

Some closeup on the result:

5. Zone Editor: Game Assets

The final piece of the puzzle is putting all of this together.

At some point during development I realized that I'm doing a lot of very mundane things in the Zone Editor. Hooking up components to objects, setting animation transitions etc. I realised that all of that can be automated. So I decided to reuse the script engine (based on Java Script) I put in the game, in the editor to be able to automate it's functions.

With the API I created, in practice anything that can be done through the UI can be scripted out. This turned out to be very powerful and very useful.

In this case we will be running script that sets up all of animation related data for a character. It will set up which frames correspond to which logical animations, set up animation events and transition animations.

Sources for the editor scripts:

• https://wtools.io/paste-code/z1J
• https://wtools.io/paste-code/z1K
• https://wtools.io/paste-code/z1L
• https://wtools.io/paste-code/z1M

The result was creation of all required data structures that define animations for new characters:

With the characters being available in game soon after:

6. Conclusion

In short: Anything that can be automated should be automated.

Employing this process saves me days of work for initial setup as well as for any further tweaks.

It is not perfect however. Some models might need some tweaking for some animations, due to mesh deforming imperfectly. Even that being the case, the minority of animations for which this happens, can be tweaked and with the used scripts re-rendered quite quickly.

4C Prague

In October I had a opportunity to speak at the 4C again, this time in Prague.
I talked about a topic I find fascinating, which is Narrative System Design.

DevGAMM Kyiv 2018

At the beginning of February I travelled to Kyiv to speak again at DevGAMM.
As usual it was an amazing, fun and friendly event. I'm really, really grateful I was invited there again. This time I talked about the early days - the prototyping phase of development of Horizon Zero Dawn.

4C St. Petersburg

Between 22th and 23rd of September I had the privilege of speaking at 4C conference in St. Petersurg.
Apart from seeing this beautiful city I met wonderful Russian devs and people from Wargaming.net who organized the conference. I talked about the Evolution of the Decima Engine from Killzone to Horizon Zero Dawn.

VirtuaX

Earlier this year I started a synthwave/trance/digital hardcore musical project called VirtuaX. First track from the EP I'm working on, is released and available for listening on YouTube.

DevGAMM Moscow 2017

Between 18th and 19th of May I had the privilege of speaking at DevGAMM conference in Moscow.

It was quite an experience to open the whole conference and meet a lot of wonderful Russian, Ukrainian and Belarus developers. Including the wonderful and very talented people at Ice-Pick Lodge, who are hard at work on Pathologic.

Again I talked about quests and the Quest System in Horizon Zero Dawn, but this time I had the opportunity to get a bit more technical.


The conference was unlike I have ever seen before, relaxed, not very formal and very, very friendly. Also a bit crazy as this picture shows:

Yes that is Chris Taylor (damn that dude is ripped) and Jon Carnage on stage :D

GDC 2017 Talk on YouTube

My GDC talk about Non-linear narratives in Horizon Zero Dawn is now available on YouTube :)

GDC 2017

A couple of days ago I returned from sunny San Francisco where I was attending GDC 2017. I'm at a loss for words to describe how amazing the whole event was. It is absolutely mind blowing to meet so many people from the industry, to share ideas and just to nerd out. Talks were super interesting but as everyone knows, the evenings are the heart of the whole event.

During the first day, on the Narrative Summit I also delivered a talk about Quests and Non-linear Narratives in Horizon: Zero Dawn (full talk is freely available in the GDC Vault, presentation slides are already available at the Guerrilla Games website). Where I talked about the Quest System I built and designed for Horizon: Zero Dawn, our process in creating it and our approach to non-linear narratives. It's sort of a Engineer's Approach to Game Narrative :P

I never talked at such a important event before so I was pretty scared and breathless. However it would seem it all went quite well, the I reception I got was amazing. The fact that the game was critically well received undoubtedly helped as well (currently 89 on Metacritic!). Afterwards I was answering questions for an hour, so I missed the following talk (sorry Amy!).

One of the coolest things that happened to me during the conference was meeting Jeff Howard. Who had his own talk: Force and Fire: Making Your Game More Metal (also available on the GDC Vault, but account is needed for access). He wrote an amazing book about quests in video games (Quests: Design, Theory, and History in Games and Narratives), which I used to create my talk and even quoted at the very beginning. The meeting was unexpected to say the least :D

Apparently some of the game press also found the talk worthwhile, which blows my mind even more:

• http://www.dualshockers.com/2017/02/28/horizon-zero-dawn-non-linear-quests-guerrilla-games/
• http://www.usgamer.net/articles/horizon-zero-dawns-quest-design-was-inspired-by-everything-from-vampire-the-masquerade-to-skyrim
• http://www.4gamer.net/games/305/G030590/20170228142/
• http://news.nicovideo.jp/watch/nw2665517
• http://game.watch.impress.co.jp/docs/news/1046865.html
• http://www.gamersglobal.de/news/126917/gdc2017-nicht-lineare-erzaehlungen-in-horizon-zero-dawn
• http://revistayumecr.com/horizon-zero-dawn-recogio-inspiracion-varios-juegos/
• http://www.meristation.com.mx/noticias/los-juegos-que-influenciaron-la-historia-de-horizon-zero-dawn/2179336
• http://www.vandal.net/noticia/1350687911/guerrilla-analizo-la-historia-de-los-juegos-de-rol-para-horizon/
• http://www.outcast.it/home/2017/2/28/costruire-la-narrativa-non-regolare-di-horizon-zero-dawn-coi-post-it

 My friends at Guerrilla Games also gave talks on other topics:

• Dan Sumaili & Sander van der Steen - Creating a Tools Pipeline for Horizon Zero Dawn
• Paul van Grinsven & Thijs Kruithof - Player Traversal Mechanics in the Vast World of Horizon Zero Dawn
• ​Jaap van Muijden - GPU-Based Procedural Placement in Horizon Zero Dawn

libGDX and Editor update

Over the past year I've made some significant changes to the Zaria framework and the Zone Editor. Polish, improvements but also I slimmed down it a bit.

Zaria has been working for a very long time on top of jMonkey Engine 3.0. As amazing as that engine is it proved a bit troublesome at times. Quite a bit of my game projects hit significant delays, because functions that would be expected to just work, would not. All 3d projects hit problems with physics, stable rendering of shadows or general performance. All of these can be worked out of course, but my ambition was never to write a game engine, it was to create a framework for quick development of cRPGs (along with such games).

Given all that I decided to take a step back and more conservatively look at what can be done. It would seem that for the time being scaling down and developing a 2d game was a good way to go.

jME3 is great 3d engine, but is not particularly good for 2d projects. I decided to look at the other big Java game engine/framework - libGDX which had very good 2d support (as well as some other really cool features like HTML5 support).

Switching the backend is never simple. So it took a while to decouple Zaria from jME3. The benefit of that is that Zaria and the Zone Editor is now agnostic in regards to backends. It can be used for any Java game engine and all specific code is now put in separate libraries. It also made development for Android simpler as I abstracted all desktop specific code as well.

There are many things still to do. Fixing jME3 support to work with the new abstracted logic (I've been working exclusively with libGDX for now), adding a plugin architecture to the editor, so custom, engine specific editors could be added easily, while still making the core editor engine agnostic, adding netbeans/eclipse plugins for common Zaria actions and types, improving documentation and howtos. However this drastic change was good for the whole project. Made me think what it is actually supposed to be doing and how to implement it in a clean way.

Along the way I managed add two new features to the editor that I really like. One is suggestion support to the script editor, to make scripting even easier:

Now when scripting Ctrl+Space will show a dropdown with all possible functions that can be used at the given moment (pretty much like any IDE).

Another thing is I added support for Value and Function types. These can be used by different definitions provide a value (like how far the fireball can go in regards to character magic stat). However because thet are definitions by themselves, they are easy to tweak from the editor. Plus the CurveFunction got its own custom editor (strongly inspired by the libGDX Particle Editor):

You can add points which will define the function, zoom in and zoom out. Currently three types of functions are supported: Linear Interpolated, Spline Interpolated and Polynomial.

And yes I did (finally!) change the color scheme to dark.

I'm continuing to work on the project. New cool things are coming.

Escaping the vacuum

Unless you're an astro-engineer it doesn't make sense to build stuff in a vacuum. Tools, whatever they may be, have to be tested and proved in action. And the best way to test a game editor and framework... is to make a game :D

So I started working on small hex based project, using Zaria.


The game itself is progressing slowly but steadily. I'm able to iterate relatively quickly and it's very easy to make systems data driven. Overall, not bad, although a lot can be still improved. The effect on the framework and the editor has already been very, very positive. I found a million bugs, identified a million more of annoyances, and one by one I'm getting rid of them.

The biggest problem I have right now is the way objects are identified. Currently the user needs to input a unique string for every object definition. It makes sense for objects that are being used explicitly later on, but the majority are not. What I want to do is to switch to a system, where only some objects have an user generated ID, but all will have an automatically generated UUID (using http://docs.oracle.com/javase/7/docs/api/java/util/UUID.html), which will be used internally by all systems to identify definitions.

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