-
Content count
29 -
Joined
-
Last visited
About Aaron
-
Rank
Member
Profile Information
-
Gender
Not Telling
-
Location
UK
-
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!
-
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.
-
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).
-
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!
-
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.) 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 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. 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!
-
Project SSDC; Action-Strategy Hybrid Early Alpha
Aaron replied to Gaizokubanou's topic in Game Development
I missed this thread initially but it looks nice from the video! Did you do the art yourself? Interested to hear what you have in mind for the strategy mechanics. Also keeping up the dev logs certainly is tough sometimes. -
So progress still a bit slow and 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. 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: 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 centred 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.
-
So yes, the physics and supporting systems will be central to how the player engages with the game. At the moment I'm leaning towards adding some more "engineering" elements a bit similar to something like Gunpoint i.e. where different parts of the airship (engines, cockpit, control surfaces, etc...) are connected by wires/pipes etc.. with valves and whatnot, which the player manipulates these in order to interface with the physics simulation and hence control the flight of the airship and respond to emergencies and that sort of thing. This past week I've been working on just outlining the way in which I think all the physical systems will be organised (in internal game logic) and how that impacts how they will be presented to the player - it's relatively dull stuff like "Can I allow players to draw entirely custom gas envelopes, or should they choose from resizeable templates?" or "How are external vs internal components organised and their collisions handled?" but it's important for me to build a mental model of these problems and their possible solutions it so I can tackle the implementation more smoothly. Progress has been slow recently due to some other projects and having some work done on my house (and Fallout 4 to be honest). I'll try and post an update this week, either some concept art stuff or maybe about the design problems I'm working on.
-
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.
-
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.
-
@Jutranjo: So my simulation will obviously never be as accurate as a fully 3D one, but I'm pretty confident I can get it working well enough to emulate the specific behaviours I'd expect. In terms of engineering test data, it is often "2D" anyway, as it considers forces acting on an object along a defined axis, so that isn't too much of a problem. 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.
-
@ThumbCitizen: A custom mesh would be a super cool solution but it would mean abandoning some of GameMaker's built in data structures, which would cost me quite a bit in terms of ease of development; this is the first time I've programmed a complete game, so I want to avoid giving myself any more obstacles than I already have. Still, I actually could do something a little like a custom mesh by simply running the gas calculations over larger grid areas deeper inside the balloon e.g. do the average result for a 3x3 or 4x4 grid area. @SuperBiasedMan: I will definitely be including information about the physics and engineering behind all kinds of airship technology - not just for informational purposes, but to guide players when designing more advanced airships. This week I'm still working on the rigid structures simulation prototype; after reading a lot of 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.
-
@root: I actually had not heard of that book before - but it sounds great, thanks for the recommendation! I've got it queued up on my tablet to read. @elvaq: I'm very much of the mind that A) most people who make "mainstream" games ignore the huge possibilities for interesting game design offered by simulating some vehicle/equipment etc... in a deep and accessible way; and B ) the people who make simulation games have, mostly, become trapped in a vicious cycle of fidelity at all costs and anything else be damned, gradually whittling their market down to a technical elite. 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.
-
Hey, thanks for the replies! So to answer your questions when the physics gas bags collide they will properly interact with each other, squashing into weird shapes - I haven't got this in my prototype application yet, as it probably needs a momentum stat to be added to the gas sim, which I haven't got around to yet. In terms of obstacles in the game I haven't decided on a specific design yet, though it will likely be a contract based system like Kerbal. In reality there were lots of goofy things in airship history that can serve as good inspiration for the contracts - one of the very first small British airships was funded by the Bovril company, who make fortifying drinks, on the basis that they could stick a sign on it for advertising; many of the first (doomed) attempts to cross the Atlantic in airships were also attempted in order to win a reward for doing so being offered by a newspaper at the time! 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.
-
The crafting and wider base building stuff have the potential to make the modding side of this even more popular than Skyrim - it's one thing to download a new sword, or quest; but now people are going to be downloading building blocks for weapons/armour/whole settlements which they will then take into their games and, Minecraft style, literally assemble into their own play experience. That's outstandingly well positioned for things like streamers/youtubers. Did they ever confirm if the modding side of it was coming to consoles, and if so how it would work? I am also both sad and excited to finally be putting Skyrim to bed when this arrives; I've had hundreds of hours out of Skyrim, and even now my dunmer toon is still sitting in some inn with a bulging quest log to finish. It is odd how little compunction I feel to actually "officially" finish the game though, but the side stuff is always better.