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 2: How I learned to stop worrying and love the FEM

The past week or so I have been working on getting to grips with GameMakers 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.

Background

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.

A Better (Finite Element) Method

I'd become quite familiar with the methods used for calculating atmospheric buoyancy 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 explanation has gone on pretty long now, so I think I'll save the explanation of the rules followed by the gas 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.

If you got this far good job, and thanks for reading!

Aloft Dev Log 1, Why Airships?

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.

Aloft Dev Log 0, Introduction

Probably best to start with a little intro to what this is all about.

I've been working in the games industry the last few years (my day job is at Goldhawk Interactive, our first game being Xenonauts) and 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 at an engineering company.

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. You can follow them here via RSS or sign-up for our mailing list; my hope is to be able to use the mailing list 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 via the link at the top of the page or by clicking here. I am also available to follow on Twitter, where I may post additional bits of info or semi-frequent nonsense.

Hello World

Just finished setting up this site and the associated newsletter system. In future this blog will contain any bits of information about the development of my game "Aloft - Airship Pioneers" which I think might be interesting. These updates will also be pushed out over email in our news letter, which can subscribe to here.