There’s a shiny new version out, mostly focusing on stability and UI things, but also adding some huge new modules like a targeting computer and a repair bay. The next version’s going to focus on adding some new mechanics like boarding. 
I’ve been sketching some concepts:
A turret with a > 180 degree field of fire. Flexible, but very big and expensive.
A landship, totally inspired by these from Girl Genius.
A wurm, a juvenile dragon…
Reminds me of the land ships from the book Leviathan.
You can check out all of the land machines from the book here: http://leviathanscottwesterfeld.wikia.com/wiki/Walker
Probably really great if you’re looking for other inspiration.
Also, on the topic of airships: http://theedgechronicles.wikia.com/wiki/Sky_Ships_of_the_Edge
The ships in the edge chronicles are really cool. They fly using floating rocks!
These are just what I was immediately reminded of by your last post. Concept art looks real good, hope to see some more diversification like that in the future.
Oh cool - both of these look like a goldmine of inspiration, visual and otherwise. Thanks!
http://zarkonnen.com/static/bumble/media/uploads/as_gl.png
So the game’s on Steam Greenlight now, which is a “fun” experience of watching a number intently, willing it to go up. I would be extremely grateful for upvotes, as I still need several thousand to have a chance of being picked by the great steam bird when it next visits, plucking the ripest game-berries from the greenlight tree. Uh.
Ramming is already an important part of airship battles, which tend to be quite physical. In early access version 5, one of the major goals is adding external modules - such as proper ramming equipment.
I started out with some historical research: what did ships’ rams actually look like? There isn’t that much visual material available, but it turns out that a common pattern for ancient Greek and Roman vessels was a bronze ram with three projections, as seen above.
One of the cool things I discovered during my trawl is that there is a full-size, fully functional reconstruction of an ancient Athenian trireme, called the Olympias. The ram on it is really quite prominent, and you can see how it could be used to good effect to hole enemy ships.
Another interesting detail is that some ancient warships had two rams - a main one to hole the ship, and a smaller, spiky one, to break the enemies’ oars.
More modern naval rams look more boring, as they are basically projections of the metal hull of the ship. So in the interest of fun, I decided to pattern the ones in the game on the more ancient type. This is what I came up with for the basic ram:
And then this is what you get as an option if you pick the Ram as your heraldic animal:
Which lets you do this:
I am quite pleased with this outcome.
Next up, I’ll be writing about some other new external modules, such as sails and tanks of suspendium dust. If you want to try the game out, have a look at the early access version, or upvote it on Greenlight…
I’m now getting started on airship-to-airship boarding, which is the major new feature in the next development release. With boarding, you can send air marines to enemy ships to disrupt them and even take them over.
The actual sending over part is a bit tricky, because crew members move inside the grid of their airship. This means there is currently no way to represent someone not inside a ship. To allow air marines to jump or glide or grappling-hook across the gap between two ships, I will have to introduce a second system of tracking people’s position. The second system will be in the same coordinate system as the ships itself, and will have to deal with physics, collision detection, etc.
So for now, I’m just going to ignore all that and make the crew teleport over! I even added a completely pointless particle effect for it.
Why? Because I want to get to the more fundamental part first: what happens during boarding?
Air marines boarding an enemy ship should try to disrupt its operation, and if there are enough of them, even take it over. These two goals are somewhat at odds, since the fastest way of disrupting an airship would be to make its suspendium chambers stop working, making it fall out of the sky. But I doubt that the air marines would be inclined to make the ship they’re in crash. Instead, I decided that the marines will target weapons systems, propulsion, and command centers, rendering the ship harmless but still afloat. So once an air marine has boarded a ship, he will path to the nearest “interesting” module - a gun or propeller or bridge, and start shooting the crew in there.
The other question is how taking over a ship happens. Airships are complex entities, so what does it mean for one to be taken over? The rule I decided on: if there are no crew members of the current owner in any of its command centers (bridges or cockpits) and at least one crew member (air marine) of the opposing side in a command center, the ship’s owner flips. The invading marines get added to the crew list while any surviving defending marines are now considered the new invaders. The normal air sailors are set to be “under occupation”, which means they will only perform a subset of duties needed to keep themselves alive: they will put out fires and run suspendium chambers, but nothing more. The occupying air marines will have to do any fighting duties.
Having figured things out, it was time to start building!
Air marines will have to perform normal crew duties in occupied ships (and they can also help out in your own), so they should be a type of crew. So first off, I introduced a concept of “crew type” to distinguish between marines and sailors. These have different sprites and different competencies: sailors are more efficient at working in airships, but much weaker in combat.
Next, I added a new module type, the barracks, which was pretty straightforward.
The game also has to keep track of whether someone is on board a ship as an invader or as a crew member, so I added a separate list of boarders, and got to work on rewiring the crewmember and airship classes to make this difference clear. A lot of questions like “how many crew are in this ship” had to be made more precise.
Next, I implemented a “board” command for airships, borrowing liberally from the existing “target” command and fiddling in GIMP until I got a decent-looking grappling hook for an icon.
So I got to the first tests: the marines would teleport over to random locations on the other ship - and then just stand there, going “Oh, that is a nice cannon you have here. And it is indeed shooting at my ship. oh well, carry on!”.
I needed them to actually go and do some mayhem, so next up was pathing: identify the modules of strategic interest and move there. Pathfinding was already available from the code for air sailors, so this was pretty quick. And of course, once they got to their targets, it was time for them to shoot things!
The game already has a concept of shots from ship-to-ship fights, so I reused and extended this. It’s cleaner than introducing another mechanic, plus it potentially allows for things like boarders shooting ships, ships shooting boarders, etc. This meant extending the shot class so it can come from a crew member as well as a weapon, and differentiating whether it comes from inside the ship or not. (Shots from inside the ship don’t get held up by armour.)
Now I just had to tell boarders to shoot crew and vice versa, and a fight for the ship finally happened! And, as it turns out, a rather silly bug: I forgot to tell marines that they can’t move when badly injured or dead, so now I had casualties and corpses sliding around on the floor and impossibly climbing ladders while prone, slowly moving to the next place to conquer.
Having fixed that, combat now proceeds reasonably: the boarders go and shoot up the bridge and cannons of the enemy ship, weakening it. Next up will be the takeover phase: boarders converging on the bridge, and the ship’s allegiance switching over.
No doubt boarding will need a lot of balancing work. Right now, it feels way too powerful, but this may be because it’s very easy thanks to the temporary teleporting. In the end, boarding should be one tactical option in your arsenal that works in certain circumstances, much like ramming, sniping with rifles from high up, grounding your ship, forcing down an enemy, and so on.
Join me next time when I put in the ship takeover mechanic and start figuring out how to make the marines move between ships!
I have an idea for your boarding , you could either A: Have a marine cannon that shoots them into the enemy ship or B: have a little bay that sits at the bottom of the airship where the marines jump out and get little parachutes , they then float toward the enemy . Of course for B to work you would need to ensure that you were high enough up.
Air-to-air paratroopers sounds awesome. Also adds to the mechanic that you have to get above the enemy to be able to board them, unless you get jet pack upgrades or something.
Yes, definitely! I’m thinking the grappling hooks could be an upgrade which lets you do more horizontal boarding.
And then there might be Air Dragoons…
I’m continuing work on boarding combat, which will be the major addition in the next release of Airships, according to the development plan.
Last time, I got to the point where air marines could teleport over to an enemy ship and fight the crew there. This disrupts the enemy ship’s operations, with marines killing crew who would otherwise be busy firing at your ships. But marines should also be able to take over ships with enough effort. This was the next thing to implement.
Because airships are complex entities with a lot of internal structure, a takeover can be ambiguous: Imagine you’re an air sailor operating a propeller somewhere in the ship. You can hear that there is fighting elsewhere, and after a while you get an order barked down the speaking tube by an unfamiliar voice: you are to turn the ship around. Do you obey? Seconds later, there is another, more familiar voice rescinding this order, the sound of gunfire in the background…
So crew will be at least somewhat aware of what’s going on on their ship, and are unlikely to cooperate fully with any occupiers. Still, for practical purposes, there has to be a point at which the ship moves from one side to the other. So a ship will switch sides if its bridge(s) contain no (living) crew and at least one (living) invading marine. The original crew of a captured ship will only perform duties from self-preservation: they will operate suspendium chambers to keep the ship from crashing, and they will put out fires. Everything else will have to be handled by the invaders.
To effect this takeover, air marines will converge on the ship bridge(s) once they’ve run out of important strategic points to disable. The combat code continually checks the requirements for a side switch and executes it when possible. You can also recapture your own ship, and the crew will stop being in “occupied” mode and resume their normal range of activities.
Once I got that all working, it was time to tackle the other half of boarding: the process of actually moving from one ship to another, replacing the stand-in “teleporter” I’d been using so far.
Boarding an enemy ship happens in the following phases:
- Upon receiving the command to board, marines inside a ship move to a place where they can exit - a hatch or a hull breach.
- Arriving there, they leave the ship, which means they are now treated as a separate entity by the game.
- Next, they move along the outside of the ship to a place where they can safely cross over - jump - to the target ship.
- A mad leap across the open air follows!
- Having arrived on the other ship, they move along the outside of the target ship to the nearest entrance - again a hatch or hull breach.
- Finally, they enter the target ship as boarders, and the boarding combat code I’ve already written kicks in.
To get there, crewmen (marines) need to be able to exist outside an airship. As previously mentioned, crew normally exist on their ship’s coordinate grid, which of course stops working when they leave.
To start, I introduced a new list of outside crew members. I decided to treat them differently from normal physics objects like ships and floating rocks, as they are able to move along the side of them, overlapping. Their simplified physics mean that they can move and fall down, but if they collide with a ship or rock, they hold on instead of bouncing off.
The exception to this is the ground, which they should not overlap with. Since there is only ever one ground object, I was able to solve this fairly simply: when an overlap with the ground is detected, the game moves the crew member back along his trajectory to neatly leave him outside of the ground. This would be harder to do if crew needed to be moved back out of multiple things. For example, if crew were also shifted out of airships, an airship squashing a crew member against the ground would pose a problem: he could not be moved out of the way of both of the ship and the ground at the same time.
Once I got this basic physics to work, I added a visual layer for displaying the external crew members and got started on the functionality for entering and exiting ships. To start, I ignored the planned restrictions that crew could only move through hatches or hull breaches and just… sort of let them phase through walls. One step up from teleportation, anyway. The actual code for making the switch was mostly a lot of bookkeeping - unregistering the crew member in one place and adding them in the other, translating in-ship coordinates to global ones.
The first time I tried out the code by giving the boarding order it turned out that I had forgotten one small thing: only marines should exit the ship for boarding purposes. Instead I got everyone shifted to the outside - in the wrong place too - with rather unfortunate consequences for the ship that suddenly found itself without a crew to operate it!
Having fixed this up, I had part of the boarding cycle working, but there was still a lot to do, especially the actual jumping across, which will be the focus of the next article.
Also, in exciting non-boarding news, Airships got nominated for the Swiss Game Award 2014 of the Swiss Game Developers’ Association. Pretty pleased with that.
I am pleased to announce that Airships early access version 5 is out. This release introduces boarding combat, ramming prows, and new ship modules such as sails - and music!
Boarding and ramming makes airship combat yet more physical: A well-placed ramming manoeuvre can instantly take out whole enemy ships.
Air marines can leap across the gap between two ships and invade through hatches and hull breaches. Once inside the enemy ship, they will attack weapons and command systems, seeking to disrupt and even capture. If the marines manage to take control of the bridge, control of the ship switches to the invaders. The remaining enemy sailors will do minimum duties keeping the ship flying, but the marines are going to have to do the rest of the fighting themselves, so send over lots if you want to make good use of your prize.
Apart from air marines, there are also air grenadiers, elite troops with grappling hooks that make it a lot easier to get from ship to ship, and guards for buildings. Because troops need a way to get in and out, ship and building designs now require the addition of hatches or cargo doors, so if you have existing designs, they will require some updating.
Airships’ music is created by Curtis Schweitzer, who previously did the soundtrack for Starbound.
The next major version of the game is going to concentrate on improving graphics and polishing the user interface, all according to the development plan.
Just checked my youtube subscriptions and look what I’ve found
vqegru9otQg
My airship combat game is getting pretty close to being greenlit - three quarters of the way through - but I really really need a last big push to get it there. Players really love it, and the greenlight page is full of enthusiasm. I’ve been trying to do this without resorting to vote-stuffing deals like Groupees that tend to get used to propel games over the finish line - so I’d like to ask you to give the game your greenlight vote.
The turtledove, like many other creatures in Suspendium-rich regions, has learned the trick of bio-accumulating Suspendium to become flighted. In the turtledove’s case, the accumulation is confined to the shell, which as a rigid mass of bone acts as an excellent and safe matrix for the Suspendium. As a result, these animals are able to grow to large sizes while remaining afloat, using their elongated flippers to propel themselves.
I’ve been pretty busy over the last two week with some non-Airships work, but I did get around to doing the above concept sketch. Blame getting “Twelve Days of Christmas” stuck in my head.
Meanwhile, Stuff+ has been doing an excellent series on ship construction and strategic conquest, which is well worth watching if you want to see some serious gameplay.
Development is going to gear up again now, so what’s next? There’s some audio and video bugs I’m currently tracking down, which means there may be a bugfix version 5.3.
Beyond that, the main focus of version 6 is going to be prettiness, which means both the aforementioned new lighting system (the second devblog for that is coming soon), and a new user interface as well:
(Concept, subject to change.)
Finally, you should totally vote for Airships in the 2014 IndieDB awards.
This looks great,
I really like the UI. May I ask. What libraries etc did you use to make this?
So that UI is just a mockup made in GIMP, put together at the pixel art level. The UI in the game doesn’t really have a library, it just has convenience functions for things like “draw a button here with this callback”. I may formalize that a bit when I update the UI though.
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…
Currently, each type of armour has a series of five appearances, from “unblemished” to “destroyed”. When undamaged, the armour tiles nicely and looks quite nice, especially with the lighting effects now applied. The problem comes when there’s heavy damage: since there’s only one picture for a destroyed armour tile, this gets tiled and looks very bad: a regular series of holes with the exact same shape.
The obvious way to fix this is to add more pictures for damaged armour tiles, but this doesn’t fix one problem: a damaged tile may be right next to an unharmed one, which means that the hole can’t quite extend to the edge without a sudden and obvious transition from one tile to the next. So I’d still up with a grid of holes, just of different shapes.
I could add pictures for all the configurations of tile adjacency, but this produces a combinatorial explosion: including diagonal adjacency, each tile has eight neighbours that could be damaged or fine, which means that I’d need to draw two to the power of eight different tiles. I am not drawing 256 armour tiles for each type of armour if I can help it!
So instead I’ve hit upon a different idea to make the armour drawing look really good. Unsurprisingly, this involves a clever shader. (I get this feeling that more and more of the game is moving to shaders, until eventually the entire thing will just run on your graphics card.)
Note that I haven’t actually implemented what I’m about to describe, so it’s perfectly possible that I’ll have to abandon it because it’s too hard, or too slow, or just looks bad. Normally, when I write dev blogs I do retrospectives where I can describe what I ended up doing, leaving out all the false starts and dead ends, which makes me look more clever than I really am.
On to the idea: per-airship damage maps. Each airship gets an associated grayscale image of where its armour has been damaged: white means undamaged, black means the armour’s been punched through. Impacting shots draw splashes of damage onto this image, bigger and darker for stronger projectiles.
This damage map is then used in the shader to put together the look of each tile. In places where the map is nearly white, it draws the normal look of the armour. In places where it’s grey, it draws an alternate, damaged look, which comes from a second armour picture that looks all roughed up. Finally, in places where the damage map is black, it doesn’t draw the armour at all, leaving a hole.
The result is that each airship gets its unique patterning of armour damage and holes, going across tile boundaries with no visible transition.
What’s more, the shader can also calculate the lighting for that tile using a few bits of extra information. First, it needs a height map for the undamaged armour. This is different from the bump map described in the lighting post. A height map shows where the armour sticks out. A bump map is the derivative of a height map: it shows where the height map changes.
The shader combines the height map of the undamaged armour with the damage map for the tile, which results in a new height map that shows what remains of the armour after the damage has been done. Then it derives the bump map and uses it for the lighting calculations.
The result should be pretty awesome: armour that can be blasted off pixel-by-pixel and dynamically lit at the same time, so flashes of light will play across the jagged edge of the holes, making splinters of still-unblemished metal light up.
Can I pull it off? As you can tell, I’ve got the logic of the shader pretty much worked out. The bigger question is whether it’s feasible to attach a damage map to each ship, update it, and feed it to the shader in the correct way with all the offsets set up properly.For now I will leave you with this amazing piece of Airships fan art created by Jenny Thorne:
(Oh, and please vote for Airships on IndieDB! Only a few hours left.)
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.
I wanted to get an early version of the game into people’s hands quickly to start getting more feedback, so on March 23, I released the first early access version. To sell the game, I chose itch.io, a relatively new game store which is wonderfully straightforward for both players and developers. There’s no application process, and no super-complex backend - you just upload the game, write a description, set the price, and you’re ready.
As these things go, having activated the store, published the blog posts, and sent out the press releases, I then spent the rest of the afternoon hitting refresh in various places, anxious to see if people noticed or cared. And they did - the game sold maybe 30 copies in the first day, which isn’t a lot, but a clear indicator of interest. Compared to my previous, much smaller game, Patent Blaster, which only ever sold about seven copies, things were definitely looking good.
A second and third version followed pretty quickly, adding smaller modules, an Internet game server, and a lot of balancing and bug fixes. By that time, I realized that Airships really needed a soundtrack. I advertised for a composer on Reddit and was fairly flooded with responses. I ended up making a spreadsheet of nearly forty candidates, whittled those down to seven, and finally chose Curtis Schweitzer, who impressed me with his orchestral scores, high quality of work, and previous experience making the soundtrack for Starbound. Frankly, I was a bit amazed that he was willing to join up with some tiny unfinished game, but clearly he could see its potential.
By the end of July, version 4 was ready, adding floating rocks, espionage, flamethrowers and Suspendium cannon. Most of the major changes were under the hood, as I’d reorganized the main game view into a more flexible componentized system that’s since held up very nicely. Shortly afterwards, I took the plunge and added the game to Steam Greenlight. Sure, itch.io is great, but Steam still utterly dominates the PC games market, so Airships has to get onto the Steam store sooner or later.
This did mean that promoting the game got a bit more complicated: in general, you want to suggest one concrete action for people to take. Previously, this was obviously “buy the game”, but now “upvote the game on Greenlight” competed with this. In practice, I’ve found the conversion rate to be about the same, which is kind of weird. People are as likely to fork over $5 for the game as they are to click “upvote” on Greenlight!
Early access 5 added major new features in the form of ramming and boarding, opening up new combat strategies. Subsequent updates finally brought a degree of balance to the strategic mode as well.
Shortly after the release of EA5, Youtuber Stuff+ started his very popular Construct+ series on Airships, introducing many new players to the game. I think that by now, about half of Airships players found it through Stuff+.
And indeed, by the end of November, the tally of games sold reached and exceeded 1000 copies, a pretty major milestone. In and of itself, a thousand copies don’t make the game commercially successful: It’s had about 7 man-months invested in it by now. But it’s a very heartening sign that even half-done, unpolished, and with limited media attention, the game already sells.
So what’s the plan for 2015? Obviously, I want to finish the game in that year. I’m aiming for early Q3, making it a solid two years of development time.
The next step, what I’m working on now, is to make the game a lot prettier: the new dynamic lighting system is now in place and looking really good, and still to come is a prettier and more consistent user interface. Early access v6 is where the game starts growing up a bit, hopefully moving beyond niche appeal to something that looks cool and plays well.
With version 6, I also hope to get the game greenlit. There’s a mere 300 votes still needed to reach the top 100. Valve no longer do whole batches of greenlighting but rather pick individual games, usually from the top 100. I’d like to think that Airships is a pretty good contender. It’s distinctive and already has a track record of success.
Beyond v6, it’s a question of spending some time adding cool features. This will be a balance act between putting in all the things I can think of, and having enough time to really debug and polish it within my timeframe. If it turns out that I have to cut major features I wanted to put in, and the game sells reasonably well, there’s always the option of creating an update or expansion to add in the extra stuff.
Finally, by early summer 2015, I want to switch full-time to polishing and debugging, ensuring the game’s quality and compatibility. The words “early access” have lately acquired a bad reputation for games that are abandoned partway, and this is not what I want for Airships. I buy and play games too, after all, and it’s so heartbreaking to end up with something that would have been really cool if only it had been fixed, polished and balanced. And after all, I want you to buy my next game too, and the one after that!
So what are the cool additional features I still want to add? A lot of this is in the plan file, but that’s actually somewhat out of date, so here’s my current list, in no particular order. Not everything may make it into the final game, for reasons of time, balance, or implementation difficulty.
- Land-ships that walk on legs or drive on tracks. Cheaper but less flexible than airships.
- Infantry: Cheap but squishable.
- Bodies of water in combat mode.
- Dragons, Sky-Krakens and other monsters.
- Ship captains with special abilities.
- Magical spells for combat.
- Turreted weapons and droppable bombs.
- Diesel engines as a more powerful alternative to coal.
- A more fleshed-out single-player campaign.
- A multiplayer ladder system.
I’m certainly having a lot of fun making this game, and I’m very happy that people are playing and enjoying it. 2015 should be a good one.
Nice to see you’ve continued working on this project. The art style is great, and I think the gameplay has a lot of potential. Gave you an upvote on greenlight 