next »

[Zarkonnen]

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...

[Zarkonnen]

The Plan

Let me get down to laying out my future plans for Airships. Right now, the game is still in the middle of development, and is not going to hit alpha for many months. Along the way, I'm going to add a whole lot of features, and the game's price is going to rise to $10 for the alpha, and then to $15 when we approach the final version.

My rough plan, subject to change:

dev4

This is the next release, due in July. I have 12 to-do items left in my plan, then I need to do some testing, and then the release will happen.

The biggest change in dev4 is under the hood: it unifies the ship editor, combat setup, defence layout and combat screens, allowing for seamless transitions. For example, you can look at your city's defences and seamlessly switch to refitting a ship. This also means that zoom and pan will work, and work the same, across the board.

The major new feature is deformable ground for ships to plow into and floating rocks to act as obstacles. This will matter especially once boarding combat and landships are in.



Beyond this, this version will introduce a simple espionage mechanic to allow you to see enemy fleets in the campaign mode, and more weapons: A short-range flamethrower and a long-range Suspendium cannon. Credit to the forums where these were proposed by Chosenlama.

dev5

Boarding combat, finally! You can add barracks modules containing air marines that you can send to disrupt or take over enemy ships. This was originally planned for dev4, but got sufficiently delayed that I'm splitting it out into its own update.

Apart from the boarding mechanic, this version will introduce externally attached modules: ramming prows, Suspendium dust chambers, as well as turreted weapons that have a wider field of fire and bombs for taking out buildings.



dev6

Next up, the major focus will be a new graphics engine: Right now, there's a lot of ugly display artefacts like gaps between tiles. The new graphics system will fix this and hopefully also add dynamic lighting and improved performance. More on that in a future detailed dev blog entry, of course.

Along with the new graphics, I will also polish up the UI components. Mechanics-wise, dev6 will introduce weather effects. Rain that reduces fire, wind that needs your ships to hold position, lightning, sunrises and sunsets that make it harder to aim in one direction.

Around this point, the game's price will rise to $10.

dev7

Dev7 will finally introduce landships with wheels, tracks and legs. Landships are cheaper but less flexible than airships, and have to follow along specific routes in strategic mode.



This release will also add diesel engines as a more powerful if expensive alternative to coal. Diesel fuel can be moved around by pipes instead of needing crew with buckets. But it also burns really, really well...

dev8

The focus for dev8 will be a major upgrade to the campaign mode. You will start with a single ship where you can learn the basics of the game, upgrading it as you go along, and eventually conquering your first city, before ending up in the late-game conquest that currently comprises the strategic mode.

dev9

Dragons! Wild dragons as hazards, tame dragons as allies.



Also potentially planned are ship commanders who give bonuses to individual ships, and a global multiplayer ranking ladder.

At this point, all the major features will be in, and the price will rise to $15.

dev10 and beyond

Finishing the game is a matter of fixing bugs and polishing the experience. Any number of releases might happen between dev9 and release 1.0, depending on how long it takes for the game to be truly done.

release 1.0

In a sense, this is going to be anticlimactic: version 1.0 is simply the version that's good enough to be called "done". There will be a party, though.

version 1.1 and beyond

There will be ongoing bug and balance fixes for a while.So that's the plan! As you can see, I have lots of things still planned, and it's going to take me a while to get there. This is also very much subject to change: I may think up additional features, decide to prioritise something, or even end up having to drop something that just doesn't work properly. If there's something you'd very much like to see in the game that's not mentioned here, I urge you to go to the forums and post your suggestion!

[Zarkonnen]

Suspendium crystals are what keep the airships aloft. How do they work? I mean, obviously they're fictional, but it's nice to have consistent rules in your fiction. As you'll see, thinking about the rules of Suspendium leads to a whole bunch of worldbuilding as a consequence.

Suspendium is a crystal that, when charged, repels other Suspendium crystals. A single crystal, as long as it's flawless, does not repel itself. This is because the repulsive force is a function of the alignment of the crystal structure: two crystals that are perfectly aligned also experience no repulsive force.



In the world of Airships, Suspendium is absolutely everywhere: there's big deposits in the rocks, it's in the soil, in plants and animals and people. It's even in the air as fine Suspendium dust.

This is why a big crystal with an alternate current running through it can hold up an airship. It's not an anti-gravity device. It's repelled by Suspendium in the ground. This repulsive force weakens with distance, which is why airships have quite low service ceilings: at best, you can rise a few hundred metres above the ground.

Big crystals are rare. Most Suspendium is in small, useless crystals, sand, or dust. Dust in particular is just annoying: it floats above the ground in response to the smallest charge in the air. In some areas, you can tell approaching thunderstorms by the dust that comes up.



When ingested, Suspendium is not toxic, but it does tend to bio-accumulate, staying in the body. And since all those little bits of Suspendium repel each other, they exert mechanical stress on the cells they're in, leading to illness and frequent cancers. Some people are unlucky and have an especial affinity for accumulating Suspendium. They tend to die pretty young, though a careful diet can ameliorate this.

Some plants and animals are adapted to accumulating Suspendium, incorporating it into special tissues that align the crystals and produce lift.

Dragons are of course the most famous of those creatures. The default form of a dragon, called a wurm, is a nasty lizard the size of a Komodo Dragon with small nonfunctional wings. Many dragons never progress beyond this stage, but if enough Suspendium accumulates in the thyroid, metamorphosis begins.



The wurm begins to grow larger and starts seeking out Suspendium-heavy food, even eating plants when needed. Its wings lengthen and several large Suspendium nodules form in its abdomen. In time, the wurm becomes dragon, a multi-ton hyper-apex predator capable of flight. Dragons don't quite float, but they are a lot lighter than they should be, and they make up the difference with their wings.



Dragons are just the most obvious use of Suspendium in nature. Plenty of plants make use of it. There are Suspendium trees with narrow fleshy trunks and gigantic canopies. Other plants are entirely rootless, floating, capturing moisture and nutrients from the air. Of course, these plants are not very safe to eat, but they're considered useful for capturing Suspendium that would otherwise end up in crops.



Suspendium is a mixed blessing. It makes travel much easier: airships, cheap Suspendium barges floating just above the road. On the other hand, it contaminates much of the world, making vast areas unsuitable for agriculture, shortening lifespans and being a general nuisance. And it enables and encourages war for those parts of the world that are fertile and productive.

But that's all right, because you're going to bring peace to the skies with your giant fleet of airships!

[Zarkonnen]

After a lot of development, version 4 of Airships Early Access is finally out!
It brings the following improvements:

• Unified interface for editing ships, combat, combat layout, etc.
• Random, destructible terrain with floating rocks.
• A simple espionage mechanic that lets you see enemy cities and sabotage them.
• Two new weapons: a short-range flamethrower that's very effective against lightly armoured targets, and a long-range Suspendium cannon.
• Bug fixes and performance improvements.

HMS Golem making good use of its flamethrower.




Closeup of a heavy cannon salvo.




HMS Undead, armed with a Suspendium cannon, a floating rock below her.




Weaken enemy defences through spy actions.




Being horrible with grenades.

[Zarkonnen]

I was very unsure about when to start the game's Greenlight run: there's a lot of work still to be done, and the version after next in particular is going to make the game look a lot prettier and potentially appealing. On the other hand, there's a question of momentum: after the post-dev3 slump, there are lots of new players now, the forums are active, mods are being developed. So ultimately I decided to enter it into Greenlight now.

As I understand it, the way Greenlight works is that new entrants get added to everyone's review queues, which means that at the start of the process, votes accumulate with deceptive speed. This means that for the first few days, the game's been rocketing upwards, but is now stalling rather badly, which means I very much rely on your upvotes. Please check it out and vote on it, even if you already have a copy. When it's gone through, I will see that I can give Steam keys to existing purchases.

Development will of course continue no matter how the greenlighting goes, but I'm understandably very keen to have as wide a set of distribution channels as possible, and making the game available on Steam is a big part of that.

[Zarkonnen]

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.



Credit

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.



Credit

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.



Credit

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...

[Zarkonnen]

I've been working on rams for the ships and the AI to use them properly, and made a short

showing how the AI calculates positioning.

[Zarkonnen]

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!

[Zarkonnen]

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.

[Zarkonnen]

In the last two installments on boarding, I covered all the phases of boarding except for how to get your crew across from your ship to the enemy's. The marines are able to leave your ship and hang on to the outside, and once on the other ship, they can enter and start fighting. What remains is the leap across.



This means the marines need to figure out where to jump from, and in what direction, to end up landing on the enemy ship rather than plummeting to the ground. This is a projectile trajectory calculation - which is pretty much what computers were made for originally. One short trip to Wikipedia and I had the correct formula to calculate the angle of launch for a particular target position.

To find a suitable jumping spot, marines examine likely locations on their current ship. At each such potential jumping spot, they attempt to do the trajectory calculation for a bunch of locations on the enemy ship. Assuming they find a place where it's safe to jump across, they move towards it. I pretty heavily constrained both the jumping-off and landing spots each marine considers, since otherwise the number of possible trajectories to consider would be huge: tens of thousands, potentially.

Once a marine arrives at a suitable jumping spot, he makes the trajectory calculation and then jumps in the resulting direction. There's no guarantee that the jump will succeed, of course - if the enemy ship moves at just the wrong moment, he might fall to his death.

At this point, the boarding sort of worked, with marines moving between ships and making nice jumps, except that they were still magically phasing through solid walls. It was time to introduce a minor new game concept: hatches. Until this point, airships simply didn't have doors. The question of how crew and supplies actually got into the ship wasn't really relevant. But now, with boarding, I wanted ships to have specific points where they were vulnerable to enemy marines coming in.



Hatches are pretty simple: certain modules, such as crew quarters and ammo storage, now have a supply cost that has to be met by hatches or large cargo doors somewhere on the ship. This means that the larger the ship, the more points of entry it must have. But you are free to put the hatches where you want - specifically, you can put them well away from the parts of the ship vulnerable to boarding, and perhaps right next to a barracks!

Having added hatches, I then limited the ability of crew to move between the inside and outside of ships to places where there was a hatch or a hull breach. Finally, I added pathing code so that the crew would find such a spot when needed. Now the cycle was complete! When given the order to board, marines would move inside their ship to the nearest hatch, pop out to the outside, move along the outside to a jumping-off spot, jump across to the enemy ship, move along the outside of the enemy ship to the nearest hatch or hull breach, enter the ship, and start fighting.



This concludes part three of the series on boarding. There will be one final installment, dealing with cool extra stuff I needed to add: guard posts and grappling hooks.

[Low_Chance]

I really love the concept of this game.

Thanks for sharing your progress in this devlog; it's really interesting to watch your development process.

It's always interesting to see how a relatively simple, intuitive idea like "marines that can board the enemy ship" actually entails a large amount of reworking of the game. Having now solved it, however, you'll be all set for when you add dragons that land on the ship, smash open a hatch, and start eating the crew within!

Just brainstorming here, but I like the possibility of ship-to-ground combat between airships and fortresses that you have already included, and I'd like to see what that might make possible for multiplayer. I think an interesting possibility for multiplayer might be a "base battle" deathmatch, where each side can design a fortress on land as well as airships (perhaps dividing resources between ships and fortress, so that a player might have a very imposing fortress but a light airship, or vice-versa). The fortresses start a fair distance apart and can equip long-range but inaccurate artillery, allowing them to slowly zero in on the enemy fortress or target the opponent's airship. Airships then battle in the middle of the map - or perhaps, outmaneuver the enemy airship and focus fire on the fortress! Gives some significance to gaining/losing ground during the battle so that positioning can be more relevant to the outcome.

[Zarkonnen]

I really love the concept of this game.

Thanks for sharing your progress in this devlog; it's really interesting to watch your development process.

It's always interesting to see how a relatively simple, intuitive idea like "marines that can board the enemy ship" actually entails a large amount of reworking of the game. Having now solved it, however, you'll be all set for when you add dragons that land on the ship, smash open a hatch, and start eating the crew within!

Just brainstorming here, but I like the possibility of ship-to-ground combat between airships and fortresses that you have already included, and I'd like to see what that might make possible for multiplayer. I think an interesting possibility for multiplayer might be a "base battle" deathmatch, where each side can design a fortress on land as well as airships (perhaps dividing resources between ships and fortress, so that a player might have a very imposing fortress but a light airship, or vice-versa). The fortresses start a fair distance apart and can equip long-range but inaccurate artillery, allowing them to slowly zero in on the enemy fortress or target the opponent's airship. Airships then battle in the middle of the map - or perhaps, outmaneuver the enemy airship and focus fire on the fortress! Gives some significance to gaining/losing ground during the battle so that positioning can be more relevant to the outcome.

As it happens, fortresses are indeed in the game and can be used in multiplayer matches. One big balancing thing is definitely going to be getting buildings vs ships right. I also hope to add land walkers and infantry (for stomping on). :D

There's definitely been a lot of reworking involved in adding marines. The core horror in terms of game complexity is that there's multiple coordinate systems: each ship and piece of landscape has its own, a grid of about 4x4 metres, but then the combat as a whole has a floating-point system. So there's a lot of work switching seamlessly between these contexts.

Also, I hadn't even considered dragons eating crew. Should definitely be a thing, maybe they regain some HP that way too. I'm also thinking about adding a whole bunch of other monsters for variety's sake: Sky octopuses! Giant mechanical ducks! Giant undead sugar gliders! Something like that, anyway...

[Zarkonnen]

The release of Airships early access 5 is scheduled for Tuesday, October 21. All that reminds is some final testing and baking the releases, and you'll get to play with the new features like ramming, boarding, and sails. To bridge the gap, here's  an overview of the new kinds of crew you can get, as well as two stories of ridiculous bugs I discovered in the last few days.

Crew Types

Airsailors

• Work Speed: 10
• Combat Strength: 2

Operate airships and defensive buildings, fetching supplies, firing weapons, repairing, fighting fires. By far the fastest workers, and somewhat capable of defending themselves against boarders.

Air Marines

• Work Speed: 5
• Combat Strength: 4

Shipboard troops that man guard posts and protect vital ship modules. In times of need, they can also perform most of the duties of an air sailor, but much more slowly. They can be commanded to board enemy ships and buildings, leaping across the gap. Once an enemy structure has been boarded, they move to disrupt weapons fire and try to take control of the bridge. If they succeed, the structure comes under the control of the boarders. The remaining crew stop fighting, but will only do basic maintenance and repair work, so the task of operating weapons falls to the occupying marines.

Air Grenadiers

• Work Speed: 7
• Combat Strength: 6

Elite boarding troops with grappling hooks. More expensive than marines, and less interested in guard duties, they stand at the ready for the command to attack. Their grappling hooks are a far more reliable and longer-ranged way to board enemy ships and buildings - and they're better at fighting too.

Guards

• Work Speed: 5
• Combat Strength: 4

While airships have marines and grenadiers, buildings have guards, who are a lot cheaper to support thanks to the convenient city next door. This makes it possible to have most buildings guarded against minor boarding attempts to which they'd otherwise be very vulnerable.

Bugs

Boarders fighting their friends

While testing the new boarding system on buildings, I noticed that sometimes, after a building had been captured, fighting would suddenly break out again. Was this some kind of revolt or rearguard action? No, it was the friends of the original boarders, who had not gotten the memo that the fight had already been won. All the boarders knew while crossing from one place to another was what they were supposed to board. So if some of the boarders were delayed, and the fighting was won very quickly, by the time they arrived at their target, it was already under new management. Undeterred by this, they would insert themselves as boarders and start fighting their comrades.

Secret police encourages enemy sabotage

This is a really embarrassing one if you've been playing Airships already. A while ago, I introduced a new espionage mechanic in singleplayer that lets people see enemy defences and sabotage them. When I first introduced it, feedback rapidly made it clear that it was way overpowered, so I added a Secret Police mechanism that let you passively defend against sabotage. Still, even after the introduction of that mechanic, sabotage kept on being too powerful. So I increased the amount of espionage protection given by the different levels of secret police and released.

Now it turns out that I was not very... awake when I wrote that code, because going back over it, I finally discovered the problem: I had meant to subtract the secret police value from the success chance of spy actions, but I was instead subtracting it from the failure chance. So in practice, the more money you spent on secret police, the easier enemy spy actions became. Imagine a massive secret police organization putting up posters of convenient sabotage targets everywhere and supplying free fire bombs to all visitors...

Needless to say, both of these things are fixed now, and we're on track for the release!

[Zarkonnen]

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.

[Zarkonnen]

This week, I started working on dynamic lighting, which is one of the major planned features in the next release. The idea is that explosions, fires, etc. light up their surroundings. I also want to take into account light direction, so surfaces that are angled towards the light source are lit up more strongly. Like in real life!



Ignoring directional light for now, the easiest way to do this is to draw light flashes on top of everything else:



But that exposes an additional point: things that are further back should be lit less. The back walls of ships, and especially the sky and clouds, should receive less light. Though Airships is 2D there's an implicit third dimension. Since the light sources are right at the front, things further back are at a greater distance to the light source and need to be lit less.

To make this work, the game has to be selective about the degree to which it applies the lighting. To make this work, I used a separate light map. This is a separate image from what you see on the screen. It's initially black and then has all the lights drawn onto it.



The code for drawing various parts of the screen can then refer to this light map to superimpose it onto what's being drawn to a greater or lesser degree. In practice, this means creating a shader for ship modules that indexes into the light map. The result is that the modules are lit up strongly and the back walls somewhat less so. Finally, I also draw the whole light map on top of the screen once. This is technically incorrect, but it gives things an amount of "shine". And that's where I am right now:





Particles and modules produce coloured light, which is drawn onto the light map every frame, making the lighting fully dynamic, which is pretty neat! I haven't yet measured the performance hit from this, and I'll probably include the option to turn off lighting for speed purposes.

Next up is going to be directional light, which will involve a bit more cleverness, multiple light maps, and bump maps for the textures...

[Zarkonnen]

[Zarkonnen]

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

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.

[Zarkonnen]

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.

Now, doing this properly would involve tracking the position and intensity of each light source, but this would be very slow, as the number of lights can be in the dozens or hundreds, and each pixel drawn would have to do distance and angle calculations for each of them.

Instead, I stuck to the light map concept, but with four light maps, one for each cardinal direction. A single point light now draws a cone of light onto each of these maps:



This tells us where the light is coming from at each position on the screen. We also need to know the direction the objects on screen are facing. So we introduce a bump or normal map: a secondary sprite sheet that indicates the angle of surfaces. Each color channel in the sheet stores part of the information - in the case of Airships, the red channel stores up/down angle, green stores left/right angle, and blue stores the intensity - the "shinyness" of the item.

Here's an example of the three color channels on a targeting computer, and the sprite overlaid with the channels:



As you can see, it basically looks as if it's being lit by a green light from the left and red one from the top.

To calculate the total light intensity at a location, the shader now first looks up the surface angle. Then, for each directional light map, it looks up the light intensity. Combining the information about where the light is coming from and where the surface is facing gives us the end result:





In the previous post, I mentioned that this new lighting system was going to have a performance cost: this more complex system definitely costs performance, though I was able to reduce the cost by downsampling the light map 8x with no visible difference. One of the things left to do is adding a setting to disable the clever lighting stuff for better performance.

So what else is left? Lots of mop-up: fiddling with the colour values, adding more particles to places, overriding the normal bump values at the edge of armour so ships are lit from the side:



Finally, doing lighting on crew body parts and gun barrels, which can rotate arbitrarily and need a slightly cleverer shader that takes this into account. That will conclude one of the major parts of the next version of Airships, with the new user interface still to come.

Oh, and you should vote for Airships as the IndieDB Game of the Year 2014.

[8-Bit Ape]

This looks pretty cool! Are you considering a 4-pack bundle for people who want to play with their friends? Looks like the kind of game that is fun with friends.

[Zarkonnen]

This looks pretty cool! Are you considering a 4-pack bundle for people who want to play with their friends? Looks like the kind of game that is fun with friends.

You know, that is a very good point that had not occurred to me. I'll have to check how to best do that, but yes, totally.

Also, I now have an animated GIF of the lighting system after some further improvements: