Slow Blade Systems

Slow Blade Systems is a one-man indie game development studio. Its debut project is a physics-based building and simulation game called "Aloft - Airship Pioneers" which is focused on the era of airship travel.

Aloft Dev Log 12: Strong Headwinds

I've been neglecting updates here for far too long, but progress on Aloft has been particularly slow the last few months due to my working on a few other side projects.

Anyway, I'm still working on relatively boring parts of the game so I'm afraid there isn't anything particularly exciting to show. A long overdue feature which I finally got working in the last week or so is taking the previously static gas simulation grid I was using, and converting it into a freely scrolling grid system, without destroying the integrity of the physics sim in the process. This means the "world" in Aloft is finally liberated from the tiny box it used to live in, and I can now start to get much more interesting information out of it like the altitude your airship has reached or the horizontal distance travelled and all the interesting simulation opportunities these offer.

Here's a short gif showing the debug view in the game, in which you can see the gas simulation grid scrolling along in response to the motion of the test balloon (which is heavier than air here, hence the sinking):

The next things on my list to implement are pressure based gas bag rupturing; some UI to keep track of vital airship stats, like speed, altitude, rate of climb, pressure etc; a method for saving/loading airship designs from a file format, which a big and rather boring job I've been prevaricating about for a while; and adding some momentum calculations to the gas simulation, which would enable both exterior wind forces and interior "gas turbulence" that should help iron out some physics foibles. Eventually I'm also going to have to tackle, you know, actually adding some graphics for the airships, but that does need to wait until the design save/load system is in.

Aloft Dev Log 11: Hangar Queen

It's time for the pseudo monthly update!

Been a relatively slow month in progress on Aloft, as a few other projects (and maybe a little Total War Warhammer) consumed some of the time I'd usually spend on it. I initially intended to have some balloons floating in the game now, but I got side tracked into improving some of the basic infrastructure I'd been implementing (specifically handling custom resolutions/windowed mode and allowing custom key bindings for everything).

The other major thing I've been working on is making the game world ready for proper airship flight. Up to now the gas simulation grid for the airship was a rigid structure, and as such though the airships/balloons behaved realistically they could never leave the bounds of this "box". As part of that I have also switched the game view from a basic fixed camera to one which can be zoomed in and out, and scrolled around with the mouse/keys. Finishing that off will probably take at least another few weeks.

Another important change is the gas simulation system now supports multiple gas "containers" in the same space - so multiple balloons can exist together and should experience (crude, to begin with) collisions with each other.

Anyway, there's still really not much of interest to show, but here's a quick gif of loading into the game via the very basic menus, and then having a zoom/scroll around in "flight" mode with a debug object (unfortunately the compression went a bit wrong on it, but you get the idea):

Aloft Dev Log 10: Float before Flight

Been a bit of a delay in news here, partly as I've just been doing relatively boring integration of already demonstrated prototype features and also had a couple of weeks vacation. Back now, and with some cool stuff to show to boot!

Firstly a development update: I have mostly finished setting up the basic framework of the game i.e. finite state based game control objects, basic menus, transitioning cleanly between game modes, customisable controls, loading settings from files etc.. and am at the point where today I should at last be able to get my gas simulation system up and running so I can simulate some balloons in engine; a simple step but a nice milestone in progress.

The exciting stuff is on the art front however, as two ongoing pieces have come to fruition in the last month. The first is final the logo for Aloft, which I showed sketches for previously; here it is in it's final brassy glory:

This was produced by Alec Beals, and he's done a fantastic job of capturing the engineering heavy (and perhaps slightly pompous) nature of airships that the game will focus on.

The second piece of art completed this week is something for a key menu in the game - the Aerodrome screen. Right now this screen will mainly serve as a place to launch into either "flight mode" or "design mode", but later it will be expanded to be the central hub for the planned management aspect of the game, with the player managing funds, resources and workers to complete their airship projects.

This was produced by Thomas Bagshaw, and he put a pretty spectacular amount of work and detail into this piece - click the the image to see a version of a truly titanic resolution. Though it is static for the moment, any dynamic parts of the image are layered to allow me to go in and add a bit of simple animation later.

The inspiration for the image above came from an interesting old picture I found of Shortstown in the UK, a "company town" which was heavily involved in the design and manufacture of airships. Recently it actually once again become a centre for airship development, as the company Hybrid Air Vehicles has moved into one of the gigantic old hangars to develop their Airlander lighter than air vehicles - their website is worth a look. They recently floated their airship in the hangar for the first time, and plan to begin flights soon!

Aloft Dev Log 9: Think of the Oxen

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.

I will leave you with an interesting airship fact: For a long time the internal membranes of the gas bags inside airships were made of "Goldbeater's skin", the hammered thin intestinal lining of an ox. It could take over 200,000 oxen to provide the material for one large rigid airship; during the First World War demand was so great in Germany that the manufacture of sausages was banned(!) to ensure an adequate supply.

 

Aloft Dev Log 8: Post Pre-Production

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!

Aloft Dev Log 7: Dapper Dirigibles

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 dev log, 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 will need a Pinterest account to properly view the following links, I'm afraid.)

Pixel Art Pinterest

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.

Painterly Art Pinterest

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.

Vintage Aviation Pinterest

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 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. Click for larger versions:

Early non-rigid airship, racing type, in the painterly style. This one is by a chap called Thomas Bagshaw.  Portfolio here.

 

Mid period rigid airship, navigating a stormy coastline, in the vintage style. This one is by one Alec Beals. Portfolio here.

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!

Aloft Dev Log 6: Design Office Design

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

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.

Aloft Dev Log 5: Revenge of the Finite Element Method

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.

 

Aloft Dev Log 4: A bit of background

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.

Here is that animation:

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.

Aloft Dev Log 3: Riveting Stuff

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.