David Stark / Zarkonnen

It's out! Airships version six, bringing new lighting, new heraldry, new guns, and weather!

A bunch of questions have cropped up repeatedly in the last few days, so it's time for an FAQ.

The new version of Airships is about to drop, and as I said before, it mostly concentrates on visual improvements. There are, however, some gameplay changes too, including some new weaponry.

The intent with Airships v6 is very much to improve its visuals without making much of a change to the gameplay. However, in some cases, the visuals go hand-in-hand with new gameplay.

Developing Airships, I've been bumping up against an old problem a lot recently. There's a lot of looping over entities and sub-entities, and a lot of context that the entities need at each level, which makes for some truly unwieldy method signatures, such as this monstrosity:

public void draw(MyDraw d,
                 double cropX, double cropY, double cropW, double cropH,
                 Image[] light, float lightStrength, float ambient, Clr soilTint)

And every time I introduce some new value like the ambient light strength, I have to go all over the code, threading that value into each function call. So I was discussing this with David, who agreed that the fix was a context object passed down the invocation chain of entities and sub-entities.

I worried about context objects becoming an unholy mess of variables in various states, or having to instantiate a specific object for each invocation. But after a bit of thought, I realized that the type system could fix this:

I've been hard at work on Airships dev 6, and have now fixed upon a release date for it, and for Airships on Steam: February 25. So unless anything goes majorly wrong in the next two weeks, that's when you get the fancy new version of the game.

Speaking of fanciness, I did a short video of the new heraldry that's now in, with a whole bunch more layout and symbol options:

When I was doing Global Game Jam last weekend, we got into some Unity-related trouble, resulting in some angry tweets.

On track to losing hours off #GGJ15 because @unity3d is silently failing to save scenes.

— David Stark (@zarkonnen_com) January 24, 2015

I got asked to list my pain points with it, so here we are. Note that I'm not exactly an expert: I've used it for two game jams. So it's possible that there's fixes, but note that experienced Unity developers may have simply got used to these problems.

Over the last weekend, I again got to participate in the Global Game Jam. It's a pretty big event here in Zurich, with about 80 participants each year, held in one big ex-factory hall.

Like last year, I worked together with Kaspar Manz, though Kristina Balanc, who did the art for Art Critic, couldn't make it. What made this year different was that we were joined by Jan Graber, a local journalist who wanted to experience the jam from the inside. He would both work on the game and report on it, and if you read German, I recommend his rather more expert coverage. This post, as a postmortem, is going to focus on the good old "what went right, what went wrong" side of things.

A few months ago, I got introduced to Caverna at a board game evening. Caverna is pretty much "Dwarf Fortress: The Board Game" in that you run a group of dwarves digging out caverns, creating a living space, mining and farming. Unsurprisingly, this got me to start playing Dwarf Fortress itself again.

Today brings both the release of Airships 5.3 and the start of the Steam closed beta for the game.

When programming game AI, a common pattern is to look at each possible action and assign them a numerical score to figure out which to take. This may be done explicitly, with each possible action actually considered, or implicitly. A lot of thought may go into calculating the best action scores, taking all available information into account and also projecting play forwards in time. Or it may be as simple as "there's an enemy in front of you, shooting it would be a great idea".

A problem can arise when the AI always picks the action with the best score. This sounds odd - after all, the best-scoring action is the best action, right? But unless you did a very good job at calculating scores, a particular type of action can end up constantly scoring best. The AI gets locked into repetitive actions that become easy to predict and outmanoeuvre, and may fail to take care of secondary or long-term goals.

(This post is partly inspired by Vi Hart and Nicky Case's Parable of the Polygons in that it has a bunch of interactive toys to hopefully illustrate its points. It's not nearly as pretty as the polygons stuff, mind you.)

Late last night, I checked Airships' Greenlight page one last time and found to my great delight that it had been greenlit. So of course, I tweeted about it, had a celebratory toast with my flatmates, then promptly went to bed to deal with all the details upon the morrow.

The next major version of Airships, EA6, will have support for multiple languages. Right now, English and German are supported, and I hope to also include French and Spanish. I have fairly limited resources, so I may not be able to afford professional translation to many languages. So if you want, you can help out by providing or verifying translations through this spreadsheet.

One of the nifty features of Airships is that you can create your own coat of arms. You can do this for your single-player empires, selecting a symbol (a charge) to give you a particular bonus. And you can design and register a coat of arms for your unique use in multiplayer. The system hasn't really changed since the initial release with the exception of a few added charges, but with dev 6 - the update of prettiness - I want to improve on what's there.

I recently received some queries about my OCR project, Longan, so I thought I'd write up the current state of it. I tried doing this before, and it quickly mutated into a book-length project, so I'll try to keep this one brief.

I started writing Longan because I needed a good OCR engine for another (now defunct) project I was working on. The only freely available OCR system that anything near worked was Tesseract / Ocropus. My experiences with Ocropus were pretty dire: it was hard to set up, hard to use, and very brittle in its output quality. So I decided I could totally write my own, better OCR system. Because of hubris.

Another game from the 90s that I am once again able to play thanks to GOG.com. In Chaos Overlords, you play as the head of a criminal organization plotting to take over the city, sector by sector. You are assisted in this by an array of deeply weird gangs that you can hire and use to expand your territory, increase your income, and fight the other crime lords. It is, in other words, a war game, but a weird and wonderful one about zany crime and casual violence.

At the start of 2014, I'd been working on Airships for a few months, and the major components were beginning to take shape: ship design, combat, heraldry, even a simple strategic map and multiplayer. I'd been blogging about the game on my site and IndieDB right from the start, and the very positive response was a major source of motivation. Still, the game lacked much of a user interface, and the computer's ships just hung in the sky and fired, with no tactical AI to drive them.

Thanks to the continuing work of GOG.com, I am once more able to play Imperialism II. I originally got the game back in 1999, when it was released for Mac OS 8, and absolutely loved it. Sadly, the Mac version did not support later Mac OS versions, and I didn't have a Windows machine until a few months ago, so I found myself unable to play it for the last 15 years.

Anyway, let me tell you why I think it's still a fantastic game that holds many interesting game design lessons.

Escape Velocity, released way back in 1996, was the first game I lost large chunks of time to, and what set me on the path to game development. It could be best described as 2D Elite: You command and steer a spaceship in a top-down 2D view, flying between planets and star systems, fighting, trading, and doing missions.

I spend a fair amount of time on Steam Greenlight. Not just because I have a game of my own on there, but also because the steady flow of games is interesting, and there's the occasional gem. After a while, I noticed some definite national preferences towards specific genres. So I did what every educated white male would do in this situation: use dubious science to explain my prejudices! Er. I mean. I ran some stats on nationality vs genre on Greenlight.

When you start upgrading the visuals of your game, some parts start sticking out like a sore thumb. In this case, I'm really unhappy with the way damaged armour looks, so I'm going to outline a way to make it look better. This is a bit involved, but there is a really cool picture at the end...

In the first post on lighting, I got as far as adding unidirectional light sources to the game. The next step was to make the light directional, so things facing a light source would be lit up more strongly. To do this, the game needed to keep track of the direction of light, and not just its intensity.