Improving Heat Signature’s Randomly Generated Ships, Inside And Out

I started making Heat Signature mainly to figure out if the mechanics would be as fun as they seemed in my head, so I built all its systems in the cheapest, fastest, simplest possible way. That worked – it’s now got to the point where I’m laughing out loud at something ridiculous happening most times I play.

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.

More Heat Signature, Procedural Generation