Airship Sails Addendum

A recent comment gave me reason to read back over my post on using sails on an airship and realize I didn't include any pictures of how the vectors I was talking about were oriented.  In that post I was so much more concerned with finishing and organizing my own thoughts I didn't do a very good job of expressing what I was talking about at all.

This picture shows the two most important vectors when talking about either a triangular sail or a wing.  Blue here represents the prevailing wind, or possibly the current direction of motion for the vehicle.  Green represents the lift, or the direction that the sail causes the vehicle to move in.  Wings convert forward motion into an upward force, while sails convert wind into a forward force.
On a ship the collected forces cause a net motion as shown below:

Here the wind exerts a net pressure (in orange) on the hull which pushes the vehicle in that direction.  This force should be fairly weak, but on an airship can't be compensated for by the keel as on a waterborne sailing ship.  Between the lift and pressure forces a net force creates some velocity (in yellow) which in turn creates a drag force (in red) on the ship.  This is what I calculated in the previous post, merely to demonstrate that such a vehicle could indeed generate a meaningful velocity.

There is a concern in this image that I didn't raise in the previous post.  What happens when the breeze is coming from the fore, rather than the aft, of the ship?  So long as the sail can be angled properly and the wind is coming from at least a little behind, or even directly to the side, of the desired direction then this image is roughly accurate.  When it comes from ahead, though, that pressure force that normally would be compensated for by the keel becomes a serious problem:

Here the pressure and lift create a net velocity not ahead, but to the side.  Obviously a sufficiently well sized sail and a properly sleek ship can somewhat mitigate this issue, but never eliminate it.  By beating to windward, however, this problem is significantly reduced.  Doing so causes the pressure and drag forces to be almost in line, meaning velocity is reduced but the direction is controlled:

This is a pretty complex maneuver used in real sailing, one that I can't possibly do justice to here. In short, it involved keeping the desired momentum more or less opposite the direction of the prevailing wind.  The ship constantly moves back and forth about that vector, so the wind is always coming slightly to either side.  In this case so long as the forward component of Lift is greater than the backwards components of Drag and Pressure then the ship will continue moving forwards.  Since the sideways components of the two orientations are opposite each other they cancel out over time and the drift is minimal.  Unfortunately the effect of pressure here will make this a much less effective maneuver than it is for a ship at sea, but it ensures the ship can maintain forward velocity regardless of the direction of wind.

I haven't bothered here with the particulars of design or calculation, the majority of which was done in the first post.  While the new issues raised here would impact any real attempt to construct such a vehicle we've also seen that such issues could be overcome by a sufficiently dedicated designer.  There is a combination of hull and sail design that would make this work.  That is enough for now, unless we want to start really building one.

Dungeons and Dimensions: Generating a Dungeon as a Network

In Part One of this series I introduced the basics of network science and how it might be applied to dungeon design.  In Part Two I went over some of the basics of analyzing a network, and what those terms might mean when applied to a dungeon.  In this third entry I'll talk about what all this buildup has been for: producing a new dungeon and describing it from scratch.  Actually, I'll be producing it from a collection of functions and subroutines designed for this express purpose.  Basically the same thing, right?

Before I go too deeply into this topic, though, I'd like to answer the most obvious question here: is this Procedural Dungeon Generation?  Well, it is a procedure that generates a dungeon, so by the most obvious definition it is.  But, is it really?

No, not really.  Most procedural content generation (PCG) systems actually produce a completed map, and I've been very explicit that that is not what I'm doing.  Not yet, anyway.  The most common PCG methods for dungeons are built around removing walls from a solid grid, placing rooms, generating mazes, and then populating the completed building with encounters.  This network based method is more about determining which encounters lead to which other encounters, then drawing a dungeon around that.

You can find a great write-up on a procedural dungeon generation method here, by the way.  There's a clear contrast between this kind of procedure with those of the network based procedure I'm employing in terms of both their method and their goal.