There's been a lot of talk about alternate currencies recently, with Bitcoin, Dogecoin, Stellar and so on all jostling to be The Future. I would like to suggest an... alternate approach. It may strike you as odd at first, but hear me out: it has some truly fascinating dynamics.
I've previously written about the problem of rising complexity in strategy games. You manage a number of units (team members, cities, spaceships, etc.) that have some degree of complexity. As the game goes on, you need to acquire more units to succeed. But since the complexity of managing each of them stays the same, the game eventually slows down to a crawl. At the start, each detailed decision on each unit makes a meaningful difference, but by the endgame, only the aggregate of your decisions matters. So you have to either play suboptimally or spend a lot of time on boring micromanagement.
If you're a game developer, you've likely encountered these: emails from people claiming to be a Let's Player or representing a game news site, asking you for a review copy of your game. A lot of these are fake, but of course there are real ones too, which you really need to get the word out about your game.
Having separated out landships as a new kind of construction, it was time to start figuring out how to draw their wheels and legs.
I just got quoted in this article by 20 Minuten that argues Swiss game developers lack a certain grand vision to make it big. I'd like to expand on my quotes here, because I don't think the issue is exactly a lack of vision.
Having covered the kind of stompy war machines I want to make in the last blog post, let's get into how to implement them.
Landships? But the game, it's called, um...
I think we've pretty much established that feature development in this game runs on the basis of what I think is cool. Giant stompy war machines are cool, and a staple of Steampunk fiction.
Airships 6.2 is out, bringing you the following:
This is likely the final feature release for version 6, so there may be a 6.2.1 for bug fixes, but the next big one will be version 7 in a number of weeks. More on that in a future post.
The up-to-date development plan for Airships: Conquer the Skies.
Modern graphics cards are complicated beasts. Treat them right and they're extremely powerful, but use them badly and you produce a lot of heat to no great effect. They like to do things in big batches: give them thousands of polygons in one go, and they're fast, but send them information piecemeal and they'll spend most of their time on overhead.
So why do computers that can run Skyrim on high settings struggle with big fights in Airships, a mere 2D game? The problem is that there's so many small things to draw: each module, each tile, each individually rotated limb of a crew member. Until recently, the game did this in an utterly inefficient way.
Airships 6.1 is out! Improvements:
Next up will be work on performance improvements before starting on major new feature work for version 7.
It's time for another episode of explaining stupid bugs! I am given to understand that the more normal thing to do with game bugs is to quickly fix them and never speak of them again, but I just find them too entertaining. This time around: every once in a while in combat, the whole ground would suddenly fall away, buildings and all. Awkward. But why?
Now that turreted weapons and bombs are in Airships, the next step is to make something specialized for shooting upwards: Flak Cannon! I've wanted to put these in for a while now, and several people have independently asked for them, so it is time.
JavaProphet's Bread & Games Mod for v4
Modding came to Airships: Conquer the Skies kind of organically. People started reverse-engineering the game and adding stuff on their own, a development I was quite happy with. So I did some things to make modders' lives easier: released the source code to people who asked for it, added a system for loading in alternate classes and overriding the defaults, writing some tutorials.
And it was good. But now, things are a bit more complicated.
As somewhat predicted, Airships version 6 is swiftly followed by version 6.0.1 which brings a bunch of bug fixes and balance adjustments. Download it from the store you bought it at.
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:
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.