• The Drunk Snake is probably the best algorithm so far, for generating the amount of branching and length of critical path we want while looking fairly pleasing.
• But! There’s a lot of room for improvement.
• But! Improvement is getting harder: we don’t have a huge amount of control with these types of algorithms, so we can’t fine-tune things precisely without a big rewrite.
• And! We don’t know enough about our requirements to get really fussy yet – maybe some things that seem bad now will be good when we have certain security devices or guard patrols in.

In other words, it’s not worth getting tunnel vision and tinkering with layout algorithms until we start fleshing out the systems and elements they’re meant to support.

The most basic one of these is locked doors and keys. The keys and even the doors are partly placeholders: some will literally be keycards and locked doors, but instead of some keycards we might put a terminal that can override things of that security level, and instead of some doors we might put a security camera that needs to be turned off.

I’ve had some version of that system in there since the first post, but it was literally dumping they keys in front of the doors. I wanted them placed in dead ends off the beaten track, so I can put security measures on them.

This turns out to be harder than it sounds. I want an early sector to branch off in three directions – two are dead ends with keycards behind various obstacles, and the third is the locked door either could open. I don’t want exactly that every time, obviously, but that kind of thing.

But because we generate as we go, at the time we place the next sector along, we don’t know whether there’ll be other branches coming from the last one, or if this is the only path. It could be like this sector, whose phallic shape allows for two keycards to be placed in easy reach:

Or this one, which did not branch at all before the door that leads to the rest of the ship.

The Drunk Snake places all the sectors that form the longest path first, and only afterwards does it look for room to make branching paths. The Branching Algorithm is not much better: it’ll let the first sector branch first, but after that it’s effectively random.

Long story short, it gets very tricky if you want to place keys and locks at the same time you place the sectors. It was pretty clear that ‘Security’ needed to be added in a second pass, after the basic geometry of the ship has been generated.

In case I haven’t made it clear yet, keys and doors work on Security Levels: a Security 3 Key can open Security 3 doors as well as Security 2 and 1. And they’re reusable. If you had one Security 9 key, you could open every door on the ship with it.

I’ll spare you my false start at this and skip to the algorithm that worked. What we’re doing kind of involves pathfinding – to ensure there’s a route to Key 2 that doesn’t go through any Lock 2 doors. But it would be complicated to integrate it with Game Maker’s pathfinding systems or to write my own, so I basically do it by making lots of lists.

We place the first sector as normal. But when we join a second sector onto it, we tell that sector to remember that ‘Sector 1’ is one of the ones you have to go through to get here. When we join something onto Sector 2, it copies Sector 2’s list of sectors-you-have-to-go-through, and adds Sector 2 to it. So every sector has a list of every other sector you need to go through to get to it.

Once the whole ship is generated, we go through the sectors and make a list of all the ones that are dead ends.

Then, until we run out of dead ends, we:

• Find the nearest two dead ends – the ones with the fewest ‘sectors you have to go through’.
• Remove them from the list.
• Put a keycard of security level S in each.
• Tell every sector that leads to either of those dead ends: your security level is fixed now.
• For all sectors whose security level is not fixed yet, upgrade them to security level S.
• Increase S.
• Do it all again.

Lastly, we go through every door in the ship and tell it: your security level is equal to the highest of the two sectors you’re between. So if you join a Sec 1 to a Sec 2, you are a Sec 2 door.

This works! Look!

Next I should either try adding hazards – like security cameras or specially placed guards – or I should put all the functional modules back in and check it still works: thrusters, cockpit, etc.

But as I said at the end of the post, there might be a problem with this layout. Here’s the route you’d have to take to get from the airlock to the front of the ship:

The Snaking Algorithm

That long, snakey, back-and-forth route is common to a lot of ships this code generates, and it comes from the order in which it places the sectors. It starts with one at the airlock, then tries to surround it with new sectors. But! I also wanted each of those sectors to be surrounded too, so as soon as it creates the first one, it tries to surround that. And as soon as it places the first surrounding sector, it tries to surround that one too.

If you keep trying to surround the last sector you placed, what you’re really doing is placing sectors one after the other in a line. And since we connect each sector we place to the last one we put down, we end up making one long route that weaves back and forth across the ship.

There are a few possible problems with this:

• It’s obviously inefficient for the crew of the ship, though that’s not necessarily a major problem.
• A bigger concern is that the player might feel they’re being messed around, that the layout is contrived to take up their time.
• And the biggest one is that this long, linear path doesn’t lead to much branching – a few little twiglets sprout off here and there, but usually only one at a time. That doesn’t give me a lot of places to put keycards: ideally, before every locked door, I want to place two different key-type things that let the player open it, and put different types of hazards or obstacles in front of them. That way, the player has a choice of challenges.

I call this the Snaking Algorithm, because it tends to create one long and winding snakey path. Since my biggest concern was the lack of branching, I tried to come up with a new one that would focus on that.

The Branching Algorithm

The snaking, as I say, comes from trying to surround each sector as soon as it’s created. So I took that part out, and just let the algorithm finish surrounding that first sector.

That gives you lots of branching, but obviously doesn’t fill the whole ship. At some point, it’s got to decide which of the remaining sectors to try to surround next. So I defaulted to what I always default to: random.

It goes through all sectors that haven’t been surrounded yet, picks one at random, and surrounds it. Since we make doorways between sectors at the time we join them on, this gives the early sectors it picks lots of branches. But then as the ship fills up, it has less and less room to place new sectors around the one it’s picked, and so those later sectors have fewer branches. But where those are on the ship is pretty random.

Once every sector has had its turn being surrounded, we’re done.

Nice!

Cool!

Well! You can see pretty clearly here that the sector the player’s ship is docked with, in the bottom right, was surrounded by other sectors – and joined to all of them – before anything else.

And now I’m starting to see the problem.

The Problem

On anything but a tiny ship, branching a lot early on ends up leading to multiple long paths.

This clashes a bit with our policy of “place multiple keys protected by varied hazards before placing a locked door”. What kind of keys and doors do we place along these multiple parallel paths? Either:

1. We have multiple parallel tracks of level 1 key > level 1 door > level 2 key > etc.
2. Or we have only one track like that, and all the others start with higher sec doors – level 6 or so – ones you don’t get the key for until you reach the end of the first path.

Neither option appeals much. The first feels redundant, messy, and an inefficient use of space – we’d need very big ships to ensure one path is long enough to be interesting, and big ships are daunting and expensive performance-wise. The second involves a lot of backtracking, and makes the critical path – Where You Have To Go – almost impossible to read without meticulous examination. I tried to design a set of keys and doors for a big Branching ship by hand, and it was laborious even to draw:

The more ways the Branching Algorithm clashed with my plans for keys and locks, the more I thought “Boy, that Snaking Algorithm really wasn’t far off.”

Tweaking The Snake

So the Snake’s problems were a) an almost dickish determination to take you on the longest possible route to your objective, and b) not enough branching to place multiple keys before a locked door. But maybe these are fixable. Like everything at this early stage, I wrote every step of this code in whatever way was easy, simple and short, so there are loads of biases and cheats in it.

I looked for the easiest one to mess with, and it’s this: when surrounding a sector, it always tries placing them above and below, then switches to looking down both sides. To be more ‘true random’, it should find all the adjacent modules and then pick a random one to start a sector from. But even that seemed too much like hard work to me, so first I wanted to test if this ordering stuff even made much of a difference. There is one super easy way to do that: switch those two bits of code round. Try placing sectors along the sides, then try above and below. I give you The Sidewinder:

It’s snakey, but it’s trying to snake lengthwise.

And right away this answers lots of questions. Firstly: yep, this makes a huge difference. This ship is nuts. And secondly: look! Branching! Enough? Too much? Dunno! But it’s worth taking the next step.

I’m still too lazy to do true random selection of adjacent modules, so I came up with another super easy trick: instead of always doing vertical first, or always doing horizontal first, it flips a coin. And because this one piece of code is run again for every module, the coin flip will mean some snake horizontally and others vertically. I give you: The Drunk Snake Algorithm.

That’s lovely, but small ships almost always are with sector systems, I’m finding.

This huge one is a bit ugly, but just because it picked a lot of 3×1 rooms all next to each other – I may bias it against that. But pathwise, it’s surprisingly good – the critical path is not dickishly circuitous, and there’s a good amount of branching along the way. There’s a huge amount of path after the objective, but I don’t know yet if that’s bad.

My next step involved giving every sector a ‘distance’ value: how many sectors do you have to go through to get to this one? So the airlock sector is 0, any attached to it are 1, and so on. They usually go up to about 8, on a medium ship. Then I boarded one and saw the number 23. I thought it was a bug at first, but then I traced the route, and no, the Drunk Snake is just a dick sometimes:

I actually love that layout. And it gave me an idea: these distance values could also be used to spot good places for a shortcut. So if this sector is at distance 14, but it’s right next to one that has distance 3, maybe we just make a door. Maybe it’s locked. Maybe it has a hazard on it. Dunno! That’s what I’m gonna play with next.

So that’s why I was replaying the Deus Ex games recently. My conclusions from that combined with two other ideas I’d been having about how to improve ship generation, namely:

1. Getting from the airlock to your objective should involve a series of Gates and Keys. For each locked Gate you encounter, there’s a corresponding Key somewhere in the area you can access, and fighting/hacking/sneaking your way to that is how you progress.

2. Whenever I sketch out what a cool ship interior might look like, I draw it as a series of little bubbles of space, about 3-6 modules each. One might be a long room, another might be a row of rooms, another might just be corridors that connect the rest. I call them Sectors. It feels like these lead to natural/pleasing/readable ship layouts – can I teach the game to build them this way?

And the relevant conclusions from my Deus Ex replay are:

3. The player needs multiple routes to their objective.

4. Those routes must be blocked by different obstacles, which require different methods to get past.

There’s some other stuff, but that’s what’s relevant to ship layout.

The first two are more instinct than rigorous logic: I feel like 1 will make the ships feel more like ‘levels’, and I think that’s more positive than it sounds: right now they feel like random, empty mazes – to use an even less liked term, they don’t feel like ‘content’. And they need to – if each ship isn’t a fun little challenge, the game has nothing at its core.

And 2 is my best guess at how to combat the corresponding visual ‘blah’ factor: they look like random mazes, and I want them to look more designed.

Teaching the computer to think in Sectors

Checking all these boxes is a massively complicated challenge both technically and creatively, so I tried to start as simple as possible. Let’s just have one type of Sector for now: a 3×1 room. Can you build a ship out of these?

The two neat features of my current ship generation algorithm are:

a) The interior layout always fills the whole ship
b) You can always get from every module to every other module

a) would be tricky with only 3×1 sectors, but should be doable with sectors in general – we just let one of the Sector types be a 1×1 module and then any gaps are fillable.

b) sounds tricky, but actually I’m already fulfilling it in the sketches I draw, and the way I draw them is the key to teaching the computer to do it. I start by drawing one Sector, then draw another adjacent to it, then new ones adjacent to those, and so on. If I created a doorway from the existing sector to the new one I’m drawing each time, every sector would have a route back to the start, and therefore every sector has a route to every other.

So after tinkering for a bit, I got the algorithm to do this:

And then this:

Great! They’re not connected yet, and they all tend to point in the same direction, but this is promising. The little 1×1 rooms are spaces where it couldn’t fit a 3×1 sector, in the order that they were laid. It’s definitely possible to do a better job of it than that, but that’s irrelevant – those little pockets look nice, I want them. If they were all clustered in one corner it’d look bad, but randomly dotted around like that is great.

So next, remove that direction bias. It’s happening because the code tries to place the sector lengthwise, and then if it doesn’t fit, goes through each possible rotation in turn. Since it always tries them in the same order, you end up with a lot of lengthwise ones. I tweaked it to try the rotations in a random order, producing this:

Lovely!

Now we need to connect them. As I say, it seems like you could just do this each time you place one: connect it to the old one. It’s a little trickier than it sounds to find the co-ords of the two modules in question (we need to know which modules to link, not just which sectors), but I got something logical working:

I actually don’t know why this works so well. My connect-as-you-go concept assumes that every module is part of some sector, but at this stage those 1×1 bits aren’t part of any sector – they’re just leftovers. I don’t quite have a good enough handle on my own code to tell you how it knows to link those up too, but it does.

So now I need to do some messy replumbing: right now we’re working with a single fixed sector size, but obviously I want a variety of sectors. After some deliberating, I decided to make each Sector type an object – a sort of invisible template the ship can refer to when creating itself. The template for each sector could store what its dimensions are, and what kinds of modules it contains.

Making those is easy, but having the algorithm read them in, rotate them to try 8 different orientations, then actually place them is all rather fiddly. For now I’ve settled on a slightly rigid system, where a Sector can either be a ‘Big Room’ or ‘Corridors’ or ‘Small Rooms’, but it can’t specify an arrangement of multiple elements – like one small room surrounded by corridors, for example. Supporting that would add a lot of complexity, so I decided to leave it until I’m really sure I need it.

So, with the new Sector templates in – just 3×1 and 1×1 for now – how does it look?

Oh, it’s broken. Parts of this layout are OK, but it fails both our conditions: doesn’t fill the ship, and the bits it does fill aren’t all connected to each other. Doesn’t make sense as a ship.

This, and a similar glitch, took me about a day to solve. I kept thinking there was some flaw in the way I’d implemented ‘connect as you go’ that could lead to a Sector being created but not connected to the previous one. As it turned out, the reason I couldn’t find a flaw in this code is that it was exactly right. I just had two very stupid, unrelated mistakes that both caused very similar symptoms, and kept looking like one thing.

a) I’d created a 3×1 ‘Corridor’ sector, but forgot to tell each module of it to link to the next – it wasn’t internally connected. The connections to other sectors were fine.

b) I’d set the dimension values of the 1×1 Sector to 1×3. This is incorrect. Maths tells us that 1 = 1 and not 3, so that 3 should be 1, so that it reads ‘1×1’, because one is not three, in fact it is less. Stop me if I’m going too fast.

Fixed these, and blam:

Blam is the sound of a ship being generated with a connected and spanning interior graph:

This is looking great to me, especially on smaller ships. So, on to Gates and Keys!

On, indeed, to Gates and Keys

Again I wanted to start as simple as possible. Some ships will play host to a particular mission with a specific objective, but for any that don’t, we should default to treating the ship’s cockpit as the ‘objective’ – it’s the thing they’d most want to protect.

Because we generate as we go, we don’t actually know how far along your path to the objective we are when we place a Sector. But we can fudge it: if the next sector is physically closer to the objective’s location, then we increase the security level of the door we’re placing between them. And to ensure you can open it, we put a keycard of the same level somewhere in the previous sector. Again, for now, I went ultra-basic: it dumps it right in front of the door.

This works! You can’t see them well, but those black square outlines in some modules are where keycards are placed, and some are placed less gracefully in corridors and stuff. The level it generates is always completable, though obviously not challenging yet.

So we need to move those keycards to more secluded locations, so that we can put obstacles between the player and them: enemies, security, etc. But before I put a lot of work into ensuring that can happen, I wanted to look into a possible worry with the kind of layout this is generating. And since this has taken a while to write up already, I’ll save that for the next post!

But the slapdash way I built it has the following problems:

• All collision checks, including guards checking whether they can see the player, are being done on a per-pixel basis. That means the game slows down a lot if there are many guards.
• Pathfinding is done ahead of time, meaning each ship calculates all possible routes within it every time its floorplan changes. For very large ships, that causes slowdown when a missile takes a chunk out of it.
• When things on a ship move or are created, they don’t have a good way of making sure they end up fixed in the right position on the ship, leading to lots of very tricky to diagnose bugs where airlocks appear in the wrong place and won’t let you inside.

The Rewrite

All of these systems need a total rewrite, and I know how to make each one massively faster and more reliable now that I’ve had some experience with how they’ll be used. I’ve been working with the bad code for so long that I’m actually really excited to rip this awful shit out and make it all clean, fast and efficient.

But I’m also aware that this means it will look like exactly the same game until I finish all three rewrites, which might be a while. So while I’m at it, I’m making some of the more superficial tweaks I’ve been planning, just to make the game feel fresh on the outside too. And the first of these are tweaks to the way ships randomly generate their interior floorplans.

The Old Floor Plan Generator

I talked about how I built that system at the time, and it’s really simple:

1. All modules in a row have doors leading to each other
2. If there’s a row behind this one, one module in this row has a door leading to it
3. If a module has exactly two doors and they’re in a straight line, it’s a corridor. Otherwise, it’s a room.

That generates interiors that look like this:

I was pretty pleased with this! From only three rules, it makes sure every module is used, every corridor leads to a room, and there’s a path from every module to every other, but it’s usually not trivial. Despite being simple, the pattern didn’t seem to be obvious – to me or others. I posted a shot on Twitter and asked people to figure out the rules – no-one got them right.

Its main shortcomings were:

• There are a lot of rooms, as opposed to corridors. Rooms obfuscate connections: it’s harder to see at a glance which ones are connected and which are blocked, which can make the layout visually boring even when it’s mechanically interesting.
• It’s usually not mechanically interesting either. The fact that there’s only one logical route between any two rooms will probably be too boring and restrictive once we have more of the on-board game elements in, like sealed doors and hacking.

The New Floor Plan Generator

So I made a few tweaks, and the new system generates stuff like this:

How much you get out of this image might depend on how much you care about corridors, but I am fascinated by it. It’s so much more intricate, organic and complex than the rules I added seemed – I look at it and think “Wait, I didn’t tell you how to do that!” But evidently I did. Again, I think it has good Rule Stealth: the rules are right there on display, but I don’t think you’d guess what they were, right? If you want to try, do so before clicking this:

Click to show the new rules

The Interesting Bit

The bits that surprise me are bits like this:

How did it know to build a corridor branching off from a lengthwise passageway to lead to this out-of-the-way room?! My algorithm builds the ship one lateral row at a time, and each one has no idea what was in the last one. This makes it look like whoever built the ship planned ahead to make sure there was a corridor leading to this otherwise isolated room.

The Explanation

I get it, of course: three modules in a row all decided to make a door to the previous row, which meant all of them could block themselves off from each other laterally. And in the row it made afterwards, the middle module failed the chance to create a door leading back, so the room behind it was left with only one connection. And being a dead end, it became a room rather than a corridor.

The fact that it’s reachable is not luck, it’s a result of some logic I intentionally put into rule 3: we’re only allowed to block ourselves off from the rest of the row if we know the rest of the row also has a back-door. That way we can still get to them by going back one row.

But what if there’s a lateral block there too? Well, they’ll only create one if they, too, have doors on either side of the block leading backwards. What about the row behind that? Same rule, all the way to the very back row of the ship, which will never create a lateral block because it’ll never have two back-doors – it won’t have any.

Imaginary Intentions

But it’s so interesting how much intentionality I can read in to the result of these rules. It looks so much like they isolated this room for a reason, and built that corner corridor to lead to it. And that adds meaning and character to whatever we put there.

Once the room types are in, that might end up being a cargo hold with a locked door and valuable loot in it. Clearly, it’s isolated by these thick sturdy walls for security reasons.

But random is random, so it could just as easily end up being living quarters. Now the isolation looks like privacy: maybe they don’t want to be kept up by ship noises. Or it could be a bathroom, and they don’t want sound to travel for other reasons.

That’s why this new system fascinates me. It seems to create intentionality out of algorithms, and the more stuff I put into the game for it to combine with, the more unexpected combinations will come out.

Its process for the ship’s shapes is probably obvious from the video:

• Pick a random ‘length’ in ship modules
• That many times:

• Pick a random ‘width’ for this row
• Generate that many modules
• Center them along the ship’s middle

So they’re all symmetrical, and contain no gaps, holes or curves – conventional. You still get some interesting oddities – like the rare very wide ship that’s only one module long – but the pattern is pretty obvious.

For the layout of the internal rooms and corridors, I tried the same approach: just the simplest thing I could think of that would always work. But I think it’s harder to see the pattern in the results. Even knowing the rules, I still find layouts that surprise me.

Curious about this, I asked from the game’s Twitter account if anyone could guess what the rules were from the video. I got lots of good suggestions, and one or two got an individual rule right, but none that I saw got the whole process. Here’s what it does:

• When building a row, always add a doorway to the next module in the row.
• Pick a random module position in this row that’s not empty in the next row, and make a doorway between the two.
• If a module connects exactly two modules in a straight line, it’s a corridor. Otherwise, it’s a room.

This ensures every room is connected to every other room, so it’s never impossible to get somewhere, but also makes it unlikely that the route will be direct. It makes a lot of wildly unrealistic corridor layouts, but I was surprised at how varied they felt.

I didn’t plan it this way, but it’s also quite similar to a Spelunky level laid down flat: a Spelunky level is a series of floors made up of chunks, and a randomly selected chunk will lead down to the next floor. It doesn’t guarantee every chunk is connected to every other, though, only the ‘leading down’ chunks.

I’ll change this a fair bit as I go – once guards are harder to get past, and there’s more incentive for stealth, I’ll open up multiple routes between rooms to give you more options.

I’ll also make the ship generation itself more varied, possibly by faction. At the very least I want ‘junk’ type ships that are cobbled together from old wrecks and not at all symmetrical. It’d also be interesting to have a type that are rotationally symmetric, or have a width-wise axis of symmetry instead. And I can vary module width and length independently, which’ll change the whole shape, look and feel both inside and out.

But it’s not worth tinkering with that stuff yet – after IndieCade, my next job will be to put ship systems in, so that rooms relate to ship capabilities and you can sabotage them. Once ship functions are tied to their layouts, there may be implications for ship generation I haven’t seen coming. More importantly, it’ll be a lot more fun to mess around with.