Working on a game about airships...

[Laughing Mechanicus]

I've been working in the games industry the last few years (my day job is at Goldhawk Interactive, our first game being Xenonauts) mainly on the art/design side of things. I decided I also wanted to develop at least some rudimentary programming skills, so I've been playing with GameMaker on and off for the last year to do just that. Up to now I've mainly been messing about with little throw away projects to get to grips with GM's built-in language (I made a little functional real-time multiplayer system, for example) but now I've started working on a game I eventually would like to release.



The game, which I am thinking about calling "Aloft - Airship Pioneers", will be set in the early 20th century and have the player building and flying airships. I decided to go with airships because they have always been fascinating to me, but there are almost no games that deal with them in any depth - and when they do show up, it is only as a bit of steampunk window dressing. When people play my game I want them to gain a little bit of understanding of how airships worked and flew, and the best way to do that (as demonstrated by games like Bridge Builder and Kerbal Space Program) is to let them try it themselves. For the airship aficionados amongst you I plan to have both rigid and non-rigid types in the game, though starting with small non-rigids like the Submarine Scout class.

For the sake of simplicity the airship building/flight will be presented in a side-on 2D view, but will contain a robust physical simulation of airship flight physics and dynamics; going 2D combined with a physics simulation might sound like an odd approach, but I've prototyped it and found it to work well. The coolest feature of the physics will be a gas simulation system I designed myself - this means the body of the airship will be simulated as an actual dynamic structure whose buoyancy and shape is dictated by the gas inside it, using the ideal gas law; the system is based on a fluid dynamics finite element analysis approach, which I am familiar with from a previous job I had working on some engineering software.

I will break down how that system works at a later date as I think it is quite interesting, but for now here is a gif of me manipulating a gas filled bag that is being simulated using this approach in one of my test applications. Each yellow square is one element in the gas simulation grid, with the intensity of the yellow indicating the density/pressure of the gas within; the red links around the edges are the balloon's skin, each node of which is dynamically linked to the gas sim system; the pink ball is the indomitable force of progress.



Hopefully people will find the posts about this interesting, and I'll do more as progress continues if there's interest. Any feedback and thoughts people have would be great, and in particular I'd like to hear what sort of wider structure people think would be cool for the final game. I am still very undecided on this part, it could be anything from a simple set of linear missions all the way up to a full management sim where you have to run your airship business to support the building and flying of new designs.

I have a website, Slow Blade Systems, where I will be cross posting these development updates. I also have a mailing list which I hope is to be able to use as a resource to recruit people from to help with testing, when it gets to that stage, so if you are interested in that please sign-up by clicking here. I am also available to follow on Twitter, where I may post additional bits of info or semi-frequent nonsense.

[madd0ct0r]

colour me interested.

[Elheru Aran]

IIRC, Starglider here had/has a game which does have airships in it. There's a link in his sig. 'Spirit of Windhaven' or something like that. You could check that out. Don't know if it would be any help, but that's my two cents

[Laughing Mechanicus]

Yeah, I've followed the development of Stargliders game on and off - the bird flight aspect looked neat. This is just a little update I wrote on my blog, I thought I might cross post it because why not:

I had planned to write about some more technical things, but I'm a little strapped for time this week so I thought I might talk about what inspired me to make a game about airships.

Airships are COOL

Any of my friends will tell you, with a weary expression, that I think airships are very cool. I also think it's pretty obvious that lots of other people thinks airships are cool - for a type of aircraft that went almost completely extinct over half a century ago, airships are all over the place in video games: The Order 1886 had an entire level set on a fantastically detailed airship; Batman Arkham Knight features airships over Gotham linked to side quests; in Bioshock Infinite the entire city of Columbia not only features loads of airships but is inspired by a (broken) version of the futurism/utopianism that existed around flight, and airships in particular, in that time period (see H.G. Wells "The War in the Air" and "The World Set Free"). Now it could reasonably be argued these games feature airships because it is suitable for their setting, but what about the multitude of other games that feature them for really no apparent reason - Final Fantasy has fantasical airship throughout, Just Cause has a big airship casino, GTA V has a fully working not-Goodyear blimp you can fly around the city in, one of the more popular mods for Skyrim adds an airship house, Fallout has had airships in the past and looks like it will again in 4; they even appear as background dressing in Viva Pinata, which has about as little to do with airships as it is possible to get.

I've belaboured the point here but I think it's pretty obvious people are desperate to include airships in their creations, regardless of setting or suitability, simply because they are almost intrinsically cool. And if I am going to make a game about something, it might as well be something COOL.

Airships are INTERESTING

So people like airships, but conversely people don't really know much about them - at all. This is hardly unexpected for a form of transportation that was only every produced in the low hundreds, operated for the most part decades ago and by crews who have now sadly mostly passed away. Fortunately there are still good sources of information about airship flight and operations, mostly in out of print books and a few online resources such as The Airship Heritige Trust. A bit of digging turns up lots of interesting information, both on the technical sides of airship flight and on the human side too - how about this chap who stowed away on one of the first transatlantic airship crossings and was almost chucked out over Ireland? Or that the first British rigid airship snapped in half before ever flying in a farcical episode dubbed "The work of an idiot" by an Admiral viewing the aftermath? Or that the foundation of the company that would build the famous Zeppelins rested on what was essentially a crowd funding campaign to get started?

Aside from factoids about airship history, the mechanical (in game terms) details of airship flight are much more involved than most people realise. Once an airship is off the ground, it isn't just a case of flying in a straight line towards their destination. Being a giant bag of gas means airships are very sensitive to weather, and must navigate weather systems in much the same way that ships do at sea - for example, airships can take advantage of the prevailing winds that circles a low pressure weather system in order to boost themselves to their target; or they can use cloud cover to hide themselves from the direct heat of the sun, that might otherwise overheat their lifting gas.

I'm convinced there is more than enough detail to make airship flight itself a really compelling adventure and, importantly, that it can be presented in a way that is accessible but very deep - where people can compare notes about the best way to build their airship or the best way to navigate a storm and while doing so learn INTERESTING things simply by engaging with the mechanics of the game.

I'll try and have something a bit more graphical next week.

[Elheru Aran]

While it's pretty cliche, airships would fit a steampunk environment quite well since they tick a lot of points for that particular aesthetic. Valves, dials, tubes, flying goggles, gloves, etcetera. Dieselpunk is also another application that might work (think Crimson Skies).

There's a game somewhere... damned if I can remember what it's called, I saw it on 4chan yonks ago, but it has aerial battleships and such. That looked cool. It was a tabletop though, I think.

Are you thinking like... a flight sim, or something like a air-battleship game, or more adventure?

[salm]

The simulation looks like you could derieve very interesting game play mechanics from. Do you have anything specific in mind yet?

[Laughing Mechanicus]

@Elheru: I think for the thematic setting I will be going with a slightly caricatured version of historical reality - I want to weave some elements of real airship history in e.g. achievements of performing some airship feat earlier in the game than it was accomplished in reality. I think the game you might be thinking of is Leviathans? Tactical pre-WW1 naval boardgame with awesome flying pre-Dreadnoughts.

@Salm: So the physics of the gas simulation should allow me to turn almost every aspect of airship flight into a mechanic - for example as airships increase their altitude the gas inside them expands, eventually dangerously so (pop!). In reality this problem is solved by installing pressure release valves in the airship envelope set to automatically release pressure and secondly by installing so called "ballonets" inside the airship envelope to regulate pressure (explanation here). These are things that players of the game will design into their airships themselves, and then need to learn how to use during flight. My hope is that, in the airship flight portion of the game, most mechanics will arise from simulated systems, rather than hard and fast "gamey" rules (though they have their place too).

[Laughing Mechanicus]

So the past week or so I have been working on getting to grips with GameMaker's built in physics system, which I intend to use for simulating the internal wood/metal structures of the larger rigid airships, and parts like the cabin/gondola on smaller non-rigids. Nothing particularly interesting to show for that yet though, so I thought I'd talk a bit about the gas simulation system I've implemented, which I showed off in the first update.

Firstly a bit of background on how I came to settle on the gas simulation system I have now. I've been playing with GameMaker on and off for a couple of years in my spare time, coming up with various game ideas and trying them out; no finished projects came out of this, but each one taught me a great deal about working in GM.

At some point I came across the LiquidFun particle system (http://google.github.io/liquidfun/), a subset of which is implemented in GM, and noticed while watching the videos that there was a demonstration showing working particle based bouyancy. This immediately got me thinking about airships and if I could re-purpose that system, with "air" particles instead of water, to simulate the way they fly.

I made a prototype using this system where the lifting gas inside the airship envelope was simulated as physics particles, and while the results were initially encouraging after some more in-depth testing I realised the system was going to be unsuitable; the chief problem was that GM did not provide a way to make a physics enabled collide-able skin to contain the lifting gas - the only solution I could find was to constantly create/destroy a rigid polygonal envelope every game iteration, with it's shape being modified by some physics "probes" reacting to the gas. This caused instability in the physics system, with gas frequently escaping, and would cause performance problems when scaled up to a larger system. Here's a little gif of that first prototype, working as well as it ever did:



However in the time I'd spent working on it, I'd been thinking about the wider concept of making the obvious game that could use this system - one where the player builds airships. I was pretty convinced this would make for an interesting and unique game, so I decided to look for an alternate solution to the gas simulation problem.

I'd become quite familiar with the methods used for calculating atmospheric bouyancy when validating the performance of the particle based system versus reality, and the maths involved were really not very complicated. This led me to try a new approach based on the finite element method or FEM; FEM is used extensively in all kinds of engineering to model how real world physical systems behave, and I'd worked with them previously. The basic idea is you take an area of space you want to model, like water flowing through a pipe, and then chop it up into little chunks ("elements"). You then use standard scientific principles to calculate the behaviour of each little chunk, based on the initial conditions and states of those around it; you eventually build up a picture of the entire thing you wish to model. Wikipedia probably has a better explanation if you want to know more (https://en.wikipedia.org/wiki/Finite_element_method).

The finite element method usually takes a lot of computing power to run, running simulations that can take multiple days on supercomputers; this means it is mostly ignored in real-time applications such as games. However FEM is only that processor intensive because it is usually run on a 3D grid of elements which are individually extremely small and therefore numerous. I on the other hand only need to simulate my airship lifting gas on a 2D grid (meaning each element would only have to consider 7 neighbouring elements instead of the 25 required in a 3D space) and I could get away with much larger elements because solution accuracy was a secondary concern (each gas element in my current prototype is 4m per side).



The first thing I knew when I adapted the FEM approach to real-time was that I still wanted to use GameMakers physics system for the more mundane bits of physics - the simulation of rigid structures, forces (e.g. turbulence) being applied to the hull of the airship etc. To do that my FEM gas simulation system had to have a point at which the maths behind it connected into the physics simulation in a continuous, non-disruptive way. I did the obvious, which was the construct the "skin" of the airships gas envelope out of physics enabled nodes, tied together by elastic connections (neatly simulating the elastic nature of a balloon's skin). This is part 1 in the diagram below.

Next I needed to use that shape described by those nodes to define which parts of the "gas grid" were inside or outside of the envelope, so that I could correctly allow gas to spread. To do this I used a really cool math trick called a "winding number" (https://en.wikipedia.org/wiki/Winding_number); essentially this allows you to really quickly determine if some point lines within a shape defined by a set of other points by counting how many times an imaginary observer standing at the testing point would turn a full 360 degrees if they looked at each container point in turn; it's quick, intuitive and completely effective. In part 2 of the diagram below you can see each element in the gas grid within the envelope has been marked with a 1.

Finally once the gas simulation within the grid had been finalised I needed that information to feed back out into the rest of the physics system via the skin "nodes". There were two problems here - firstly I needed to know which elements in the gas grid were the "border" elements, as they were the ones whose physical properties would affect the skin nodes, and secondly I need a way to assign which skin nodes received the pressure forces from which border gas elements, which was important to make sure the simulation was physically accurate. After a bit of searching both of these problems were handily solved by a useful algorithm called "Marching Squares" (https://en.wikipedia.org/wiki/Marching_squares); so called because it takes a grid of various numbers and will then "march" out the contour lines between values above/below a certain value - in my case this was easy, I just wanted the borders between 0 and 1 in my gas area masking layer. The algorithm then populates a new grid with numbers, each of which indicates what, if any, kind of border exists between 0 and 1 in the current grid square. Once that is done it is a simple matter to iterate through each grid square marked as a border and assign them to the nearest physical skin node. This is shown in part 3 of the diagram below, with the grid showing the numbers output by the marching squares algorithm and the coloured groups of dots around the envelope border each being physically linked to an envelope skin "node".



This has gone on pretty long now, so I think I'll save the explanation of the rules followed by the gas itself for another time. For now, here's a little gif I made of me testing out a cigar shaped gas envelope in my simulation - it's a bit jumpy because I haven't really tuned it, but you can see the method of cross connection that will be used to make the gas bags conform to more complicated shapes.

[madd0ct0r]

That's an extremely realistic ripple you've got there. Can the engine cope with tie ropes and rigid spars?

[Laughing Mechanicus]

So ropes are pretty easy - just a chain of connected points like the "skin" in the gifs above.

Rigid spars and similar structures is actually what I've been working on most recently - in the last week I've been putting together a rigid structures simulation prototype; after reading a lot on the dynamics of how the structural girders that support a rigid airship behave I've decided to try and simulate them as capable of the full range of elastic (i.e. non-permanent) and plastic (permanent) deformation, along with final structural failure. This is probably a bit ambitious in terms of simulation complexity, but I'd really like to try as it will give airship stress/damage much more depth than most games with structural physics. I've requested a copy of a paper from the journal of the Royal Aeronautical Society on the strength of rigid airships structures, and I'm hopeful it might have some neat shorthand approaches to these kind of calculations. Here's a little gif of a simulated 5m girder undergoing some permanent deformation when a weight is dropped on it.



I hope to have a proper dev log up on Friday.

[Laughing Mechanicus]

So still just been working on possible methods to simulate the structural parts of rigid airships. Annoyingly most of the approaches I've come up with don't actually look any better than the gif of the denting girder I posted previously - however they do work just as well AND seem able to produce something somewhat close to the real data I have access to; my next task is to tweak the most promising method for maintaining girder rigidity so that it follows the data.

Here's a quick picture of the method I'm thinking of using:



To explain, this shows a girder supported by two immovable points (green triangles) with a small round weight resting on it; I chose this setup as it mimics the testing setup used to obtain the real world data I have.

The girder is 5 meters long and as you can see is composed 5 sub-pieces, each of which are connected by very simple free spinning "revolute" joints (I've highlighted two of these with red dots). Now if this system were left to it's own devices it would of course simply collapse as there is no force keeping the girder rigid.

To create that force I have added a second kind of connection between the neighbouring sub-parts of the girder, which is a simulated "spring" connecting the mid point of each part to that of its neighbour; I've illustrated this for one of the pairs of girder parts with the green dots and connecting line. This solution works well as no matter which way the joint in the girder bends the spring will produce a proportional force attempting to straighten it out.

It's probably worth me saying again that I am aware that running what is essentially a physical finite element simulation of every major girder in an airship (50 longitudinal girders alone for a larger ship) is probably a bit ambitious, but I'm willing to give it a try before falling back to something more simplistic if needed.

Anyway this has been a bit of a boring and short update, so in compensation here are some gifs of some of the less successful attempts I made at getting the girder simulation working.

[Laughing Mechanicus]

So far I've mainly talked about the physics aspects of the game, but have been vague on what the game itself will look like - time to change that.

Part of the reason I decided to make Aloft a 2D game, aside from keeping the physics manageable, is that I've always really want to try my hand at a parallax scrolling background. For those not familiar with it, parallax scrolling in games is a technique where multiple 2D background layers are rendered and then scroll at different speeds in response to player movement, simulating a shifting 3D perspective. As a child I played lots of games that used this technique, and I still find it really effective at conveying forward motion and progress while remaining elegantly simple.

In most games however the parallax background would be relatively restricted - it would react to sideways movement, and a bit of vertical movement, but the changes would be slight. For Aloft the background will need to adapt to the altitude of your airship from ground level up to several kilometres high, it would have to change dynamically to show different kinds of terrain as you explore the world and it would need to display a full day night cycle.

To start with I used the 3D modelling program Blender to create an animation of a side on view of an airship flying vertically and horizontally against a background which was simple 3D representation of the world built to scale with the airship in Blender. This proved very valuable, as it immediately highlighted to me what the key variables for such a background would be - the simulated field of view of the game "camera", and the distance at which the 2D background "tiles" were placed from the airship.



After that, I got to work making a prototype. The first thing I needed to do with the prototype is come up with a dynamic system to position the background tiles on the screen - I wanted this to be as accurate as possible, so I set it up so that it works out the positions required for background tiles from first principles based on the radius of the Earth, airship altitude and desired virtual camera FOV. Here is a shot of my debug tool showing the output of that system (this is shown head-on to the airship, rather than the games side-on view); the white line is the surface of the Earth, the blue dot is the airship, the yellow lines represent the limits of camera field of view (yellow dots where it intersects the Earth) and the green dots are where the game has calculated it must place background layers of a given height in order to fully cover the "ground" in the 2D view from the base of the screen to the horizon:



This took some effort, but once this system was working it was a comparatively simple job to have the game properly fill the screen with some background tiles I created and have them respond to player movements. Here is a gif of the result (note the terrain sprites are just for testing - the game itself will have better assets):



If you are interested each layer here is spaced a simulated 50km apart, with the horizon being about 250km away. The airship is going much faster than it would in reality, to emphasise the scrolling effect.

After that I started thinking about day/night cycles. This was easy to do with some simple colour blending on the terrain - blend black onto the terrain at night, and darken the sky - but I wanted to push it a little further. Because I had made a 3D model of the terrain, I was able to extract some depth information of it from Blender very easily using a normal map. I took this information and created new rendered layers for the terrain showing which contained only the shadows at dawn/dusk, and then re-rendered the original terrain without shadows. By blending these elements together based on time of day, I was then able to simulate moving lighting on the 2D terrain.



Now before anyone points it out - yes, I know the Sun does not both rise and set in the same place and that the lighting in the "morning" is therefore wrong; I just have it setup like that at the moment so I can test both sunrise and sunset easily.

I think you can see, based on the above, how I can now easily go on to implement things like clouds layers at different heights, fog and other weather effects with relative ease. The major challenge left is transition from one tile set (say the desert) to another (like the sea) but I have quite a few ideas on how to do it.

Thanks for reading all that, hopefully it was interesting.

[Purple]

What are you using to actually program this?

[Laughing Mechanicus]

It's all in GameMaker Studio, using its built in language GML.

[Laughing Mechanicus]

So I'm afraid I don't have a huge amount to report this week - I made a little progress the week before on the finite element simulation/destruction method I am using for rigid bodies (such are the girders that support larger airships) and I am getting pretty close to this being done, but I had the flu last week and as a result made no more progress. Here's a little gif preview of the me mistreating a girder, demonstrating elastic and mechanical failure - ignore for the moment that it is a bit "floppy", I still need to tune the material strength:



So for this week I'll finish the run down I started previously of the Finite Element Method gas simulation system. Last time I described the broader systems that support it - the data grids which contain information about each gas "element" in the simulation, and which are used to calculate essential things like the shape of the total gas area and enable a force feedback between the conventionally simulated "skin" nodes and the FEM gas sim.

The real core of the simulation happens in one of these grids, which I call the atmosphere grid. It is very simple, with each 2D grid space representing a 2x2 meter area of the game world (you'll notice I previously said 4 meters, but it is actually fully configurable). Each cell in this grid simply contains a value for the number of moles (a scientific unit for the amount) of simulated gas, in this case Hydrogen, which are currently in that grid square.



The above image shows a deliberately coarse atmospheric grid, each grid square displaying its mole value. This may seem extremely simple, but is is actually almost everything we need to simulate the behaviour of that gas under expected conditions using the Ideal Gas Law.

To do that simulation, we iterate through each populated node in that gas grid once every game frame (about 1/30 of a second). When processing an individual cell, the first thing we do is make a list of every cell that neighbours it, in both straight and diagonal directions; that gives us 9 in total. We then discard any neighbours that are invalid e.g. those outside of the gas bag skin.

According to Ideal Gas Law, a gas will always try to diffuse from areas of high pressure to areas of low pressure. We already know exactly what pressure our gas is at, as we know how much of it is in the cell (in moles) and we know what the volume of a cell is. We then also calculate the pressure in the same way for the neighbouring cells, giving us the difference in pressure between our own cell and each neighbour. We then calculate, for each neighbour, the amount of gas this pressure difference represents and that gives us how much gas (in moles) moves between the current cell and the neighbour being considered - this is done using the following form of the Ideal Gas Law:

m = PV\RT

Where:
m is the number of moles of gas
P is the pressure of the gas
V is the volume of the gas
R is the ideal gas constant
T is the temperature of the gas

If the value resulting from this is positive then the gas generally moves from our currently considered cell into our neighbour, if its is negative then gas flows the other direction. The basics are really quite that simple.

There are some caveats though, which I'll cover here. It is super important to randomise the order in which the cells and the neighbouring cells are considered for this diffusion; if you do not you introduce a static "grain" to your gas grid along which the gas prefers to flow. To combat this I have a list that stores the ID of every gas cell in random order; I use this list to go through each cell, and re-randomise the order of the list each frame - thus averaging out any directional effects.

You may also notice above the Ideal Gas Law requires a temperature, which I haven't mentioned. This temperature is currently set to sensible static value, which is fine, but it misses some important effects in airship flight to do with thermal heating of the gas in the airship (it expands, be careful!) - fortunately the calculations for this are even easier than the gas diffusion, so it's no problem to add later. Similarly I also need to add some simulation of gas momentum, but this is less pressing and also fairly straight forward.



There is one final piece of the puzzle, which is how the gas cells interact with the physically based skin. I covered this a bit in the previous post, but what happens is each gas cell at the border of the envelope gets assigned to the closest skin node (red dots on the skin in the pictures) - the pressure we calculated for that gas cell is then applied to that skin node as a force, and if it is large enough it will push the node away; if that happens with enough force then the skin will move far enough to include a new, empty, gas grid square in the envelope - when this happens the gas from the previous edge nodes rushes into the empty node, thus reducing the average pressure. At the same time, an opposite force is exerted back on the skin nodes by a simulated "atmospheric pressure" from outside the gas envelope. These competing pressures eventually lead the system to stabilise at 1 bar of atmospheric pressure, which is precisely correct (the first time that happened was a real Eureka moment).

Phew, and that was a lot of words again! I hope that was interesting to some of the more technically minded among you, and hopefully the next update I should have some of the concept art that is currently being worked on ready to show.

[madd0ct0r]

deeply interesting - you could probably get away with randomising the cell order once and just running it backwards and forwards. might save you a few flops.

[Laughing Mechanicus]

Had a bit of a slow month in progress on Aloft, as I've lost some of the time I'd normally spend on it to other projects and some DIY. What progress I have made has been in fairly unsexy parts of the project, so I haven't felt particularly compelled to write about it - I'll have a quick talk about it now though.

So I got to the point a few weeks ago with my various prototypes that I feel I can now be confident that GameMaker can support the kind of physics systems I'll need to build the game I have in my head. Now I've started the planning process of how I will go about implementing that game, and also getting a very rough outline of what the different parts of the game will be like.

Rather than me explain to you in excruciating detail what that will mean, I will simply quote an existing document I have already written in which I explain in excruciating detail what that will mean! This specific document mostly covers the "Design Office", which is where the player will go to design their airships. This is only an outline, so is relatively light on technical details (I have another document for that), and has been used to firm up my ideas of what the airship design process would include and need to support it.

This is still a work in progress and I'm posting it without any attempt at filtering; I write these in Notepad (just because) so it will be full of spelling/grammatical errors - please excuse them:

This document outlines the mechanics that players will use to build airships in Aloft. It excludes anything to do with airship flight, and the airship development/management level. It is mainly a working document for design, but includes some technical caveats.

Airship Design Goals
———————————
———————————

- Provide the player with many distinct options for how to assemble their airship with a given set of components
- Facilitate discovery of the advantages and disadvantages of the current design without time/resource costly setbacks
- A high level of detail in simulation to facilitate depth in designs


Design/Hangar Screens
———————————-
———————————-

Airships are initially designed in the Design Office screen. This is represented as a drawing room style side-on view of the airship being put together on paper. It has a “daydream” function that lets you test the airship design instantly, without the cost of any components and with no risk from disaster but without the ability to use it to complete any missions or navigate the world map. This additionally allows you to try out technologies that have been conceptualised but not yet researched, such as new types of engine. A technical listing is also available showing some information about the current design, e.g. gas capacity and lifting weight, while it is being assembled. Airships can be designed at any size, but the player will be warned if they exceed the size of the largest available hangar.

Once an airship has been designed it can, so long as it is technically feasible and a hangar space is available, be ordered into production. The details of these requirements are covered in a different document. During construction, and once complete, the airship can be viewed in the Hangar screen, represented in the games standard 2D side-on graphics with its visual appearance reflecting its construction progress. The player can, at any time, switch from this view to the Design Office screen and make revisions to the design which, if saved, will then be made to the airship itself - though costing extra time and resources. Additionally once the airship is complete the Hangar screen is where the player can apply visual customisation to the airship, and assign crew and make tweaks to the loadout in preparation for a mission.


Design Procedure
————————
————————

When creating an airship design in the Design Office screen the player will typically first define the envelope that their airship will use; this functions as the “main” part of the airship to which all other parts are attached in game logic terns. Available envelopes are listed in the side bar, as described in the components section of this document.

Layers
———

The components of the airship are arranged in three distinct layers. The layers are considered to be separate from each other in terms of game collisions, and objects within a layer cannot overlap each other. The “external” layer is considered to be everything outside of the envelope of the airship - such as engines. The “interior” layer is everything inside the airship envelope, which means components placed it this layer must remain wholly within the envelope - typical objects in this layer might be ballonets for non-rigids, or gas bags and internal crew areas for rigids. The final layer is the “systems” layer, in which objects can be placed anywhere (though they must be physically connected to an anchor point) - this layer is only for objects related to node and connection based simulated systems such as gas pipes, control cables, telegraph wires etc... they are mainly kept in a separate layer to simplify the design process.

Anchor Points
——————-

The envelope of the airship will by default create a number of physical “anchor points” along it’s length. These are locations to which other components can be attached. Components themselves will also have pre-determined anchor points so that they can be attached to the envelope and/or other components. This attachment can either be done directly or indirectly where components are mounted using girders/flexible wires which the player creates manually. Anchor points are shared between all layers and there is no limit (aside from physical strength) to the number of objects attached to an individual anchor point.

Envelope
————

Envelopes are parametric containers used to define the main body of an airship. To create one the player drags the desired type/style of envelope from the sidebar onto the design page - it will appear there at a default size, and can be manipulated to the desired size/configuration using grab points positioned around it (more details of this procedure are covered in the Parametric Components section below).

Once the envelope is in place, the player can begin adding components to it. Components can either be mounted inside or outside of the airship by switching layers (toggled by clicking an icon) though some are limited to being mounted only externally or internally. Internally mounted items must be within the bounds of the envelope, whereas externally mounted items can be mounted anywhere.

Crew
——

The first components the player will want to add is one with a position for at least one crewman to act as the pilot. Any object that requires a crewman comes with a slot to accommodate them; a pilot slot is available on all control cars, and some more complicated parts may come with slots for multiple crewmen (e.g. pilot, radioman, engineer). The control car object can either be directly attached to the structure of the airship via anchor points (this might be impractical due to shape on smaller ships) or the player will position it below the airship and then attach it to the main envelope using a series of wires or girders. Most control cars can only be mounted externally, though some later ones for very large ships might be internal.

Propulsion
—————

For propulsion the player will want to add both engines and fuel tanks. Engines are typically mounted externally in symmetrical pairs, though when mounting engines at the very top or bottom of a design the option is available to mount them as a single centreline engine - a tooltip will inform of the player of which configuration they are placing. Engines are typically mounted externally, though later on the player may develop the option to mount them internally which a mechanical linkage to separate external propellers. Fuels tanks can be mounted both externally and internally; once placed they must be connected to the engines which they are to feed by a fuel line.


Lifting Gas
—————-

At this stage the player may want to organise the lifting gas arrangements for the ship, which will be set up in one of two different ways depending the type.

For non- and semi-rigid airships, the player will need to drag and drop the appropriate lifting gas they want to use into the desired “container” object. The player will also probably want to add some internal ballonet containers in the fore/aft of a non-rigid - these are added as nested containers of the main envelope by simply dragging and dropping them into the design then connecting them to the envelope via wire or rope; this time the player will drag and drop “Air” from the gas menu into these so they are by default filled with air. In order to work correctly the ballonets will need to be connected to inflow/outflow valve by airflow pipes.

For rigid airships the player will instead need to populate the ship with internal gas bags to hold the lifting gas. Before doing this however, they will mostly likely want to use girders to create transverse connections vertically in the airship hull to provide strength, lest it collapse in flight. This must be done first because large transverse girders block the placement of anything “crossing” them, such as gas bags. Once the girders are placed placing the gas bags between them is straightforward, and they are filled with lifting gas in the same manner as described above.

Flight Control
———————

To add flight control to the ship the player will want to add some control surfaces. These are divided into two categories - rudders, and elevators. Rudders are vertical surfaces that allow the player to make changes to the airship’s heading, whereas elevators are horizontal surfaces that allow the player to make changes to the airship’s pitch. These can be placed anywhere, either be attached directly to the airship hull or supported via girders. They come in multiple sizes, and some can be resized using grab points. Note that control surfaces attached to a non-rigid envelope should lose effectiveness (indicated by their “sagging”) if the envelope loses pressure!

An additional form of flight control is the provision of ballast. Ballast can come in a few forms - sand or water. Sand is stored in bags that are physically dropped from the ship to release them, whereas water is stored in bags that can be partially drained for better control.

Systems
———-

In order for many of the parts of the airship to operate, they must be connected to each other in a variety of ways; this is referred to as the “systems” aspect of the design. Systems components are kept in their own layer for the sake of clraity and so as to not interfere with the placement of larger structural objects. Below is brief description of some of the systems players will use to improve their design.

Flight controls surfaces (rudders and elevators) must be wired up to the pilots station using special “Control Cables” in order to function. Cable splitters can be used to operate multiple surfaces simultaneously. Larger/more surfaces and/or longer cable lengths will require greater force to operate, and actuate slower in general, and so hydraulic boosting devices can be added to the control cables to aid in this. Control Cables can also be attached to a variety of other airship systems to control them remotely e.g. operating valves or releasing ballast.

Electrical power is needed to operate certain systems, such as radios and pumps. These need to be wired up to power with “Power Cables” in order to operate. Airships can use batteries to supply the power, or derive the power from a dynamo attached to their engines.

Air and gas needs to be directed around the ship in various ways - this can involve inflating internal ballonets or venting over-pressurised lifting gas. This is done using “Gas Pipes” which can be connected to a variety of manually or automatically operated valves.

Engines must be connected to sources of fuel using “Fuel Lines”, in a fairly straightforward manner. Multiple fuel tanks can also be chained together using fuel lines.

Ballast may also require a system of water pipes to allow draining/refilling of the bags.

Control Panel
——————-

In order to control the above systems, players may have the ability to build their own custom “Control Panel” to operate their airship more efficiently. The design of this remains tentative for now, until the depth of functionality in the systems aspect of the simulation is more fully explored.

Completion/Iteration
——————————

After adding the above described elements the airship design should be complete and somewhat flyable, though more tweaks will probably be necessary to make it work well. The player can test the design for free in “daydream” mode, which is essentially a limited sandbox the design can be flown around in, or they can save it to be ordered into actual production in the campaign/management layer, a process which consumes time and resources.


Airship Components
—————————
—————————

Airships are built out of component parts, some of which are singular “snap-on” parts (e.g. engines) and some of which the player defines themselves in a more free-form manner (e.g. envelope). An airship can use whatever components the player wants, within the following limits:

1) The main body of the airship is composed of a single “container” - a flexible skin for non-rigid (blimps), or a covered framework structure for rigids (zeppelins).
2) This main body can contain multiple sub-containers, ballonets in the case of blimps or gas bags in the case of zeppelins.

The components available to add to a design are presented to the player via a side panel, with a tab for each of the following categories:

Envelope - Shows parametric envelopes for blimps and rigid structures for zeppelins, also includes internal gas bags/ballonets and fabric coverings for rigid structures
Structure - Shows other structural parts such as girders, ropes and wires to link various parts together; also control surfaces/empennage
Gas - Shows available lifting gases and other lift management systems, such as air conduits and gas valves
Propulsion - Shows any parts related to propulsion, such as engines, fuel tanks and fuel feed lines
Cabin - Shows singular and snap-together parts used to make the crew inhabited part of the airship
Payload - Shows any parts that can be carried by the airship that do not aid in flight, e.g. cargo space, passenger rooms etc... also ballast
Systems - Shows a variety of misc devices and connections the player can use to control various aspects of the airship e.g. control cables, electrical wire
Instruments - Shows special devices the player can add to their control panel to help flying the airship (needs fleshing out)

Components in this list are displayed as icons, with an instant tooltip showing their name and a delayed tooltip showing more detailed technical/cost information on mouse over. Any components that rely on a currently unresearched technology are marked to distinguish them, and can be hidden as desired. To add a component the players drags and drops it from the side panel onto the design “page”.

Many components will be singular objects with a few designated “anchor points” that allow them to be connected to other parts. If there is more than one anchor point, then the player chooses which to connect by clicking nearest to the point they want to use when clicking to drag the part. Other objects are parametric, such as gas bags, and in their case the attachment points for them will be the physics nodes that comprise their shape.

Components dropped onto the design “page” do not become an actual part of the design until they are connected to the airship via a anchor point; the “airship” for this purpose is considered to be the main envelope of the craft, created at the start of the design. Disconnected parts can be moved around the page and connected at will, but will not be saved if they remain disconnected.

Parametric Components
——————————-

Parametric components, such as girders and envelopes, come in two main types: lengths and containers.

A “length” is the simplest, and is defined by the player clicking a start point and an end point; the game then dynamically creates the correct number of pieces (i.e. physics objects) needed to fill that length, and will connect the start/end node to the anchor points the player designates, if they do so. Lengths can be solid objects like girders or flexible objects like ropes.

A “container” component is used to define confined area of space - such as the envelope of of a blimp or the gas bags of a rigid airship. Containers in game logic consist of a series of physics nodes (which act as anchor points) connected by physics simulated joints in a loop. It also creates a “container mask” for use by the internal physics system. The player defines a container by dragging the type they want to create (e.g. a ballonet for a blimp) to an initial point, where it will appear at a default size and shape, and then clicking a dragging various grab points around it to make it the required size.

Rigid envelopes are a special case of container, where the “skin” is actually composed of rigidly linked girders but which creates no container mask unless enclosed by a skin (skins are a separate component dragged onto a rigid container after creation).

Containers, unlike lengths, are always aligned to the horizontal and cannot be rotated in the design phase - though they can be resized using the methods mentioned above.

The boundaries of two or more containers may never overlap, but it is possible to create nested containers - the smaller container must be completely within the bounds of the larger one.

Paired Components
——————————-

Not a distinct class of components, but a mounting type. Some components (mainly engines) Are placed in pairs when being mounted on the airship. Because the simulation is 2D, this has no effect other than to double the weight/output of the component being mounted in pairs. Components capable of being mounted in pairs are also capable of being mounted as singles - thought if they are being placed externally they must not overlap with the envelope to do so; internally they follow the normal rules for placement.

You can see that I am leaning towards a "systems" heavy design here, with bits of special machinery the player must set up in order to make the airship function optimally; I also played around with some designs which more heavily centered on the crew, but that ended up requiring a lot of abstraction that was at odds with the otherwise very simulationist nature of Aloft.

So that this post isn't just entirely composed of an enormous wall of text, here is a quick preview of some of the rough sketches one of the concept artists I've been working with did for some early non-rigid airship designs.

[Laughing Mechanicus]

The Christmas break not unexpectedly slowed progress on Aloft, but I have still been quietly badgering away and have been back working on it properly in the last couple of weeks. At this point I have finished writing up the design and technical documents covering the airship building/functionality which I showed in the last post, and I am currently working on one last prototype - the intent of which is to prove out at least one practical method for rendering the flexible canvas skins of the airships. More on that in future.

Anyway, I mentioned a few months ago that I was getting starting to work towards defining an art style for the game. To begin with, I started to collect examples of art that I thought fit into one of several broad categories that might be suitable for Aloft. I collected these on a separate Pinterest board for each style, which allowed me to comment on each example and easily share them with artists.

The first style, and the one I actually thought I was most likely to use, is a heavily dithered pixel art look - which I fondly remembered from games such as UN Squadron for the SNES.
(You may need a Pinterest account to properly view the following links, I'm afraid.)
https://uk.pinterest.com/aaronash84/alo ... art-style/

The second style I considered was a more painterly and slightly abstract style. Aside from looking nice my hope here was also that art in that style would be relatively quick to make, and thus ease the burden of producing the large volume of terrain tile art I will eventually need.
https://uk.pinterest.com/aaronash84/alo ... art-style/

The final potential style is what I call the "vintage aviation" style. This is based on lots of old oil on canvas paintings of heroic WW2 fighter planes etc... as well as the kind of finely detailed illustrations you would find in older reference books about aircraft.
https://uk.pinterest.com/aaronash84/alo ... ion-style/

So, I sent these around to a few dozen artists I found via conceptart.org, and asked them which style they felt most comfortable with. As it turns out, only a handful had any experience with pixel art, which isn't too surprising, and of those none of them jumped out as being able to execute quite what I was after. There were plenty of candidates for the other two styles however, so I had to whittle it down to one each for the painterly and the vintage style, based on their various portfolios, quotes and interest/familiarity with airships.

Anyway - here are the finished concept pieces they produced! Both of these were created following guidelines that meant they matched most of the restrictions placed on the final rendered game e.g. the backgrounds are composed of layers to permit parallax scrolling effects.


Larger: https://dl.dropboxusercontent.com/u/683 ... _style.png
Early non-rigid airship, racing type, in the painterly style. This one is by a chap called Thomas Bagshaw. Portfolio http://www.thomasbagshaw.co.uk/.


Larger: https://dl.dropboxusercontent.com/u/683 ... _style.png
Mid period rigid airship, navigating a stormy coastline, in the vintage style. This one is by one Alec Beals. Portfolio http://alecbeals.com/.

I'm very pleased with how both turned out, and although I'm not fully decided on the details yet, I think it is quite likely I will cherry pick parts of each style and try to integrate them together for the final style - the strong lines of the vintage style airship are probably most suitable for clearly communicating an airship's design to players, but the hand painted clouds in the painterly style perfectly sell the romance of sailing through the skies.

Would love to hear comments and thoughts!

[Enigma]

I certainly like the vintage style.

[Laughing Mechanicus]

So today development on Aloft has quietly ticked (or tocked, not sure) over and I have brought to an end what I have been grandly calling the "pre-production" phase, which I loosely defined as doing research, teaching myself GameMaker and producing various prototypes of systems that will be needed in Aloft. In the W.S.C. school of international project management this is not the "beginning of the end", but might be the "end of the beginning".

I am now in the equally amorphous phase of "Pre-Alpha", which by my definition means I have a big list of everything I will need to program, all art that will need to be created and even all the sound effects and music that will be required in order to produce a pre-alpha version of Aloft that I can release publicly. This will still be a very bare-bones version of the game, but it should prove that the most basic mechanic - that of designing and flying about in big bags of gas - is something that is entertaining and can be built on.

This also means I don't have anything particularly exciting to show off at the moment (unless you are really excited by time estimates!); however I do have some of the preliminary sketches produced for the previous batch of concepts which have some neat airship designs, so I will post them for everyone to take a look at:





Hopefully by the time I next have something interesting to post it will be that I have started work in earnest on the code that will become the final game!

[Laughing Mechanicus]

Been a while since I've done an update on this - I'm still working away, but mostly on fairly mundane low-level things that underpin the rest of the game (getting menus working etc...); this will probably continue for a little while to be honest as I have quite a lot to implement, but I'll be sure to post updates on anything interesting along the way (I have a couple more pieces of artwork under way at the moment).

[Laughing Mechanicus]

I'm still soldiering on with the implementation the foundational parts of the Aloft application; this is somewhat boring work but will make it easier for me the manage the code as it grows. Progress will probably be at about this pace from now on, but I'll try and post something interesting at least once a month.

On the art front we are working on a logo for the game. I felt it was about time to get one done to make the project look a bit more professional.

The basic style I decided on was one of those metal "inspection plates" that were typically attached to Victorian machines by their doting manufacturers in order to say who made, what patents applied to it or merely to highlight how ludicrously over-engineered this machine is compared to the competition. Typically they use a flowerly treatment of the company name, with some more practical down-to-earth text for the rest of the information. Almost always etched out of brass, which is heavy and therefore best.



The above were sketched by the talented Alec Beals, after we spent quite a while getting the font for "Aloft" just right; I like all of them, but am probably going to go with something based on the bottom right design. Eventually this will be fleshed out into a fully rendered colour logo, along with simpler black and white versions.

[salm]

Hey, nice to see some progress. And nice logos. Personaly I find the top right one the best as it incorporates the whole airship idea in the most bold and simple way.