Long Time No See

So... I got a bit caught up with things being hectic at work and haven't had a lot of free time to do fun stuff like blogs. Hence a two-month hiatus. However, what little time I've had, has been put to good use.

Here are the things wot we have been up to.

Battledroid

The voxel engine for Battledroid, "Voxoid", is... finished! It now does all the things. It draws models, it does shadows, it does vast numbers of particles (that are lit), we've got effectively unlimited point and cone lighting, it does transparent geometry, we've got a nice configurable water layer which should do everything from lakes of lava through swamps to the open ocean... it's all good stuff and it all runs super fast.

Hopefully we'll be able to show some fancy screenshots and videos of it when we get Chaz back, but right now Chaz is dealing with life stuff and is having to take a bit of a breather. With any luck he will be firing on all four cylinders after Christmas.

Pkeod's Secret Card Game

Brian Kramer of Subsoap is working on some fun diversions for us in the meantime, the first of which is nearly ready to play - Faerie Solitaire Harvest. FSH is an ultra-casual match-2 solitaire game suitable for killing time when you don't want to have to think too hard. We'd be very grateful if some of you Patroids could test it out in a week or two - we'll release it via Steam, and you're all getting it for supporting us.

After FSH, I think Brian is planning a more hardcore card game called Faerie Solitaire Dire, which will have rather a lot more mechanics in it from other genres of card game.

The development of FSH is quite interesting as Brian is developing it using some fairly new and cutting edge technology to enable him to get it out on all platforms simultaneously - he's using Defold, a new 2D engine that emits cross-platform code, scripted in Lua which is a lovely little simple but fully-featured programming language. Also interesting because the Defold IDE is made using JavaFX and written in Clojure. Pretty radical cutting-edge stuff.

THJSON

I created a new DSL for describing game resources called THJSON, "tagged human JSON". It's very similar to HJSON upon which it is based but adds a couple of very useful features, particularly for describing data when you've got an object-oriented language under the hood.

THJSON looks a bit like this:

I've got a reasonably good syntax colouring grammar defined for Notepad++ which makes it easy on the eye. Could do with a more comprehensive colouring grammar defined for the LiClipse text editor plugin for the Eclipse IDE which I favour.

One of the key thing about THJSON is the addition of "tags" before objects - for example that (background) tag there. This lets some processing tool that's loading the file in know what kind of thing an object might be if there are potentially different choices.

One of the other key things about it is the addition of #keywords that can be interpreted in any way you like by your processor.

If you're interested in playing with THJSON I'll be glad to give it to you to play with, though I've already got it up on Github (but it's badly out of date - will fix shortly).

Resources

The reason for the THJSON work was to provide a solid foundation for my Resources project, which is a generic way of configuring a large tree of arbitrary data in THJSON files that gets loaded up into Java objects.

My old resources system used XML, which was horrible to behold and use, and was completely tied to SPGL2, my generic game class library. Every resource had to extend my AbstractResource class. This isn't much use to anyone else who doesn't want to use all the rest of my own organically developed spaghetti code. So enter the new Resources project, which works with any code you like.

Its basic function is to store a map of String names to arbitrary objects, and manage the preparation of these arbitrary objects for use. For example, you've got an "image" resource of some kind, which starts out initially just as a URL, and when it has been "created" it's got the actual image at that URL stored in it.

It automatically calculates dependencies between resources, so if you've got a GL texture resource that depends on an image resource, the image resource will get created first, and then the GL texture gets created.

I'm currently working on an actually interesting algorithmic problem, which is how to totally parallelise the task of creating all the resources in one go (such as you'd do on a loading screen). This task is much more complicated than it seems, because some dependencies can only be created in the main thread, and we also need to keep track of the total number of things that need to be created so that we can display some sort of progress bar.

SPGL3

My "old" game library, SPGL2, was developed as a completely new redesign of my original game library (let's just call that one SPGL1), upon which Titan Attacks, Droid Assault, and Ultratron are all built. SPGL2 was designed specifically for use with Battledroid, which was to be its maiden voyage.

However in the intervening years I've got a bit wiser, balder, fatter, and more cantankerous, and many things about the way SPGL2 worked displeased me. In particular the use of XML for resource definitions, and the irritating need to have all the resources inherit from AbstractResource.

SPGL3 is the rework of SPGL3 using the THJSON and Resources projects, and it's coming along nicely. The last piece of the puzzle is in fact the aforementioned resource-creation task-tree thing. Ultimately the whole point of it is to firstly clean up some of the stupid anachronisms in SPGL2 that were themselves held over from SPGL1, and secondly using the new THJSON format and Resources system should be vastly more user-friendly for Chaz when he gets to putting neat stuff into the game (it's mainly Chaz that ends up doing the resources).

So that's what we've been up to.