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


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.


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.


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.


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.


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.


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.