Here is a video blog about that, and how I’m changing how I think about working on it.

The green blob in some of these is your ship’s heat signature: it’s visible at any zoom so that you know where you are on the map. At some point I decided to let you turn this off for screenshots. The faint white dot is the cursor.

I tweeted about how I approached this as I went, here are those tweets:

Detpack FAQ Q: Why does placing a detpack cause you to also fire your gun? A: This interview is over.

— Heat Signature (@HeatSig) February 24, 2015

One year on, and the latest video shows how far it’s come.

But I have to keep reminding myself it hasn’t been a year of work yet. When I started it, I was still torn between this and another project, a heist game using grappling hooks. In the year since I started Heat Signature, I have also:

• Worked for about two months on that grappling hook heist game. The last two dev log videos I made for that show what I did on it in that time.
• Took the grappling hook tech from the heist game and spent five weeks to make Floating Point, a peaceful game about swinging around elegantly, released on Steam for free.
• Went to the BAFTA Games Awards: for Gunpoint, lost to some shitty car game.
• Collaborated with Natalie Hanke and Jukio Kallio to make Distance, a short visual story piece for the Space Cowboy Game Jam.
• Collaborated with Liselore Goedhart to make SimAntics: a two-player competitive anteater licking simulator, where you steer a prehensile tongue with the mouse to lick up more ants than your opponent. Filmed and released as part of the Super Game Jam documentary.
• In my ‘spare time’, knocked together a basic RTS-style framework for possible use in a civ-building game I’d like to try some day.
• Wrote and successfully pitched an hour-long talk for next year’s GDC.

And I’ve also done a bunch of Heat Signature related stuff other than the actual development:

• IndieCade East, New York: to show the heist game and Heat Sig.
• GDC, San Francisco: to show Heat Sig.
• Fantastic Arcade, Austin: to show and give a presentation of Heat Sig.
• EGX, London: to show Heat Sig.
• Made a bunch of videos about it.
• Spent more than a month finding and reviewing applicants for the artist and composer positions on the team, and eventually making a decision on both.
• With John, built a nice website for it.

I’m listing all this mostly for myself, because I’m always haunted by this feeling that I’m not being productive enough, that I should have done more. When I write it all down, though, it seems like a lot.

I intentionally let myself wander a bit after Gunpoint, since that had taken three years of sustained focus to finish. And Heat Signature itself is actually the result of that: I let myself get distracted from the heist game to try it out, and it turned into something both cooler and easier to make.

When I started working on it properly, I had a time frame in mind. But right away, it started to stress me out. The scope would change or my ETAs for individual features would be off, and I’d start to feel like I was failing even though nothing had gone wrong. So now I don’t even have an internal release date, it’s just a thing I’ll work on as efficiently as possible, at least until it feels ready, and then until I feel like moving on. I’m having a great time doing that, so I’m not going to let anything spoil it.

When I have new shots in future, I’ll add them on this page and take down any outdated ones. I’ll keep the first three as reasonably representative ones, then below them it’ll be newest-first. Everyone has permission to use these shots in any articles or videos, print or online, as long as you make it clear what game they’re from.

I whined to Mike Cook about this, and he said something to the effect of, “When you read up about Finite State Machines, it sounds like they’re this one specific agreed-upon thing, but every time you talk to an actual programmer about them you’ll get a different version of what they are.”

But! I am determined to try them in Heat Signature, and I have just reached that point where there’s enough AI an animation stuff going on that I need some kind of system to manage it. So I’m going to explain how I plan to use one, and if you’re a programmer, perhaps you can warn me of any problems I’m making for myself.

If you’re not, or if you’re learning, maybe you’ll get something out of how hopelessly I’ve failed at this so far.

How I Did It In Gunpoint

Guards did have a ‘State’ variable in Gunpoint, which I’d set to things like ‘Patrolling’ or ‘Preparing to fire’. But every time I wanted to change state, I’d have to check against all the possible states that should ignore this change. That was a pain, because every time I added a new state, lots of code in lots of different places needed to change.

Example: When a guard sees the player, he should go into the ‘Preparing to fire’ state. Oh, unless State = “Dead”. Then later, when I added a separate “Unconscious” state, I’d have to find all the places I made an exception for “Dead” and also add one for “Unconscious”.

I tried to alleviate this by having extra variables for broader concepts like “Mobility” – if the guard can’t move, I don’t care if it’s because he’s dead or unconscious or held down by the player, he shouldn’t run to investigate noises.

The problem was that I had to remember to add “Mobility = false” to all the different places that might set a guard’s state to “Dead” or “Unconscious”. And the more properties like that I added, the messier it got.

What I’m Planning For Heat Signature

Clearly, the problem boiled down to “Given our current state, can we change to new state X?” There will always be special case exceptions to that, so my attempt to boil things down into broader concepts like ‘Mobility’ would never be a full solution by itself. So I think for each state, there will have to be a list of states we can’t change to from there.

What would be helpful, though, was if there was only one such list for each state. Only one place in the code where we define those exceptions. It’ll still need maintaining and updating as the possible states and transitions change, but just the once. Then it would be much easier to maintain and the complexity wouldn’t increase when we called it from more and more different places in the code.

It could also set any useful broader variables like ‘Mobility’, and as long as it’s the only bit of code that ever changes state, we can be sure that those will always be set consistently for any given state we’re changing to. Every time we change to Dead, for example, it’ll always be this piece of code that runs it, so if it says ‘Mobility = false’, there’s no way we can ever die with our Mobility flag on, something our grandparents warned us against.

So specifically, I’m thinking of a function that says something like this:

ChangeEnemyState(NewState)

//See if we should change state

if State = “Sitting” {

    //No exceptions, always change regardless of new state
    State = NewState
    
} else if State = “Dead” {

    //No valid transitions, ignore
    
} else if State = “Unconscious” {
    
    if NewState = “Dead” {
        State = NewState
    }

}

//Set properties of new state (regardless of whether we changed)

if State = “Sitting” {
    
    Moving = false    //Not moving
    Mobility = true    //Can move if we need to
    Shootable = true
    
} else if State = “Dead” {

    Moving = false
    Mobility = false
    Shootable = false
    
} else if State = “Unconscious” {

    Moving = false
    Mobility = false
    Shootable = true
    
}

Does that make sense? Any problems I’m going to run into? Is that a Finite State Machine?

Edit: Thanks everyone! I have a much better idea of how they’re meant to work now. Lots of different implementations suggested, so I’ll pick the bits that make the most sense to me and that I already know how to do in Game Maker Language.

First night in Austin, met up with fellow Brit and Sokobond co-creator Alan Hazelden for a drink at CU29, appropriately named for the atomic number of copper (Sokobond is about atoms). This is a ‘Mexican Coffee’, which involves setting fire to orange peel. It was goddamn great.

This was the rather different setup for my rather similar presentation at Fantastic Arcade, in a bar. This trip was my first time doing something on stage with no preparation or script, in a randomised game, so it was nice to do it in a more relaxed atmosphere at Fantastic before going up in front of a larger and more captive audience at EGX. Pic by Brandon Boyer.

Typically if the screen is indistinguishably white they’re playing SimAntics, and if it’s indistinguishably black they’re playing Heat Signature.

Half of Fantastic Arcade happens in an Alamo Drafthouse theatre, where they bring food and drink to your seat. Me and a new friend who works at Blizzard drank boozy milkshakes and watched the N++ tournament, which is one of the best spectator sports.

Robin Arnott and Alexander Bruce play SimAntics, the game Liselore Goedhart and I made for the Super Game Jam. Our SGJ episode was meant to screen in the giant theatre, but unfortunately wasn’t ready in time.

Luftrauser’s composer and Life on a Mountain creator Jukio Kallio and I. Jukio and I worked with Natalie Hanke on Distance.

Jukio DJ’ing the Fantastic Arcade closing party as Kozilek, with Fernando Ramallo on visuals.

Instead of rushing back to get home for 1 day before having to go to EGX, I stayed in Austin to watch the new Ghibli film (pretty good) and The Stranger (awful), and join some friends for a trip to the Salt Lick (pictured), which had sent at least one of them into surgery previously.

Bacon and maple donut at Gourdoughs, a thing I was determined to try before leaving Austin. It was soft and crispy and a massive mistake.

EGX.

I patched Heat Signature while I watched people play, trying to address usability issues quickly enough to see whether my fixes worked on the next players. I made 12 versions in 4 days, and the game improved hugely.

I think I’ll do this at events any time I can, rather than standing around and explaining my game to onlookers as I did at PAX. It’s less sociable, but much easier on the legs and voicebox, and so satisfying and energising to get so much work done – then to see its value immediately.

Each new version took progressively less pointing at things. Thanks again to Natalie Hanke for designing the awesome poster. Pic by Ben Borthwick.

Matt Lees and Steve Hogarty tried it. I tried, and failed, not to ask journalists “What did you think?”, because I hated it when devs did that to me when I was a writer.

This fellow boarded a ship, saw a horde of guards coming his way, fired wildly, shot an explosive barrel, and blew this chunk clean off the ship: spinning through space, suddenly alone.

Gunpoint and Heat Signature artist John Roberts manned the station for a while so I could see a little of the show.

The random gas clouds keeps producing gorgeous combinations I’ve never seen before.

Quite a nice layout on a big ship. I think this is the balance of rooms to corridors I’d like to see more of, more rooms than this and it starts to look like grid paper.

Pic sneakily taken by my friend Rossi while I was being interviewed by Chris Bratt for VideoGamer.com. EGX was better for press exposure than any other event I’ve been to.

Lots of nice tweets during and after my talk. This pic by Gareth Williams.

Sneakily taken by Pip while I nervously watch Heat Signature being played in not the exact way I would play it – always scary.

Now that I’m back, there’s lots of boring business stuff to catch up on, including officially forming our team. But then there’s the wonderful job of revising my priorities and ideas for the game’s grand plan based on the truckload of new self-awareness I’ve gained from watching people play and talking to them about what works.

The response was hugely positive, but the blanks in the current prototype are not the type a new player can fill in for themselves. With Gunpoint, it was “This, but more levels.” Heat Signature’s already infinitely big, so it’ll increase in definition and systemic richness rather than in size. That’s something I could inject in any of a million places, so the current build doesn’t definitively show where it’s going. But the upside of that breadth is that I can also adapt my focus as I learn more about where the most exciting possibilities are.

As ever, join the mailing list if you want to be involved in testing when we do that, or just to be told when it’s out.

My deep, deep thanks to the amazingly talented people who applied, it meant a huge amount to me that people of your calibre were interested in my thing.

Here’s who I picked:

Alex Burnett, composer

[soundcloud url=”https://api.soundcloud.com/tracks/164108318″ params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]

I said if composers wanted to make a sample piece for Heat Signature, they could have a go at both the peaceful music that will play as you fly around space, and the tense music that will play once you’re inside an enemy ship. Alex did a fantastic job of both, but his peaceful track in particular is just divine. Testing it in-game, as some of the first art started to make space look beautiful, it just perfectly matched the feeling of awe and serenity I wanted that experience to have.

Ivan Semidolin, composer

Ivan didn’t try to match the sample tracks I posted, which I mentioned was an option. His full-length track captures a mood I didn’t know I wanted. It uses industrial sounds that evoke the workings of this large machine you’re aboard, and has this unusual rolling, clicking beat I can’t get enough of. In-game, lots of great ‘tension’ samples made me feel like I was in a dangerous place – Ivan’s made me feel like a dangerous person.

John Roberts, artist

Several artists’ samples made me say “Wow” out loud, but I think John’s was the first that made me say “Holy shit!” Did we make the game already? I appear to be looking at several screenshots of a rich, meticulously detailed, satisfyingly chunky, gorgeous and completely finished Heat Signature. How does this already exist?

Apart from the crispness and vividness of the thing, what I especially love is the sense of solidity in the interior shot: I feel like I know how heavy these walls are, what the worn floor would feel like to touch. And it’s full of clever game-savvy touches: all the interactive things are picked out in white, and boundaries between solid and empty space are stressed by hazard lines painted on the floor.

Sharp observers might recognise John’s name: he was also responsible for the best art sample I got for Gunpoint, and therefore became Gunpoint’s main artist. Heat Signature’s style is radically different, but apparently he’s just incredible at everything. Several other people I’ve worked with before also applied for these positions, and I didn’t give them any particular advantage for that. But I also didn’t exclude them: the point of the open submission process isn’t to avoid previous collaborators, it’s just to make sure that if I do work with them, it’s because they’re the absolute best fit for this particular game.

It was tough getting there, but I think that’s what we’ve got, and it’s really exciting to see it take shape. Obviously it’s early days, but if you come and play it at Fantastic Arcade in Austin this week (free), or EGX in London next week, you’ll be able to see how some of this stuff is already working in-game.

When’s it out? Dunno! But if you’re on the mailing list I’ll tell you once it is.

Can I test? At some point! Again, I’ll tell the mailing list when there’s a way to do that. I only use it for major stuff like that.

18-21 September: Fantastic Arcade at the Alamo Drafthouse in Austin, Texas, US
25-28 September: Eurogamer Expo (EGX) in Earls Court, London, UK

I’ll be at both events to talk you through it and answer any questions with “I don’t know,” “No,” or “We’ll see.” I’ll also be doing some form of presentation at each, probably involving playing the game myself and explaining my plans.

Earlier this year I also made a game with artist and designer Liselore Goedhart, in which two players steer the tongues of anteaters and battle each other like disgusting slithery light-cycles as they compete for ants. That’s SimAntics: Realistic Anteater Simulator, and it will also be playable at Fantastic Arcade!

And for EGX, I commissioned my friend and graphic designer Natalie Hanke (who I worked with on Distance) to create this spectacularly pink poster!

And b) I’m ready to start looking for an artist and a composer to work with!

Update: the deadline has passed and applications are now closed! We got a lot! More as I sort through them.

I’d like to do it the same way I did for Gunpoint, with Open Submissions. That means anyone can send in a sample of what they can do, and I’ll pick the best artist and the best composer based on that. In this post I’ll explain loads about what we’re looking for, but the highlights are:

✓ Paid!
✓ No experience required!
✓ Work from anywhere!
✓ Flexible hours!
✓ Game already works!
✓ Application deadline: [EXPIRED!]

About the game

Why open submissions?

Who can apply

Sending samples

The work: music

The work: art

Time frame

Pay

How we’ll work

Practical considerations

How to submit:
Alas, it is too late! As mentioned at the top, the deadline has now passed.

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.

Don’t apply for either of those jobs yet, though! The other thing I need to do before then is nail down enough of the game’s underlying tech to be sure of precisely what kind of art and music it needs. The way it’s coded right now is rather glitchy, so now I have to investigate whether it’s the fixable kind of glitchy, or the “Fuck this and try a different method entirely” kind of glitchy.

Time lapse

So I’m not going to show much of its current state, but I did put together a time-lapse of everything I’ve done so far: Heat Signature’s five month development in 2 minutes.

The jetpack thing you see early on there felt horrible, made your character feel more like a vehicle. The boarding drill was a technical nightmare I never got working, and would have broken most of the infiltration game design anyway. In general, stuff I cut made the game worse.

Here’s what stuck!

New things since that last video

• Ships now have individual turrets and thrusters you can hijack or destroy.
• You can hijack the cockpit to take control of the ship, fly it around, start fights with others.
• Ships fire heat-seeking missiles, accelerate to outrun them, then cut thrusters to cool down and lose them.
• Christ, did I not even have modular destruction in that video? Modular destruction! Missiles destroy any module they hit.
• If blowing up a room on a ship splits the ship, the fragments spin off independently. This caused insane complications with ship IDs and contents that I don’t want to talk about.
• Sexy hot vapour trails on your ship. Trail thickness and brightness proportional to thrust when it was made, fades smoothly over time.
• Loot! Find bits that upgrade your ships thrusters and cool rate.
• Missions! Actually that’s the main thing I want to talk about, so I’ll break out of this list.

Rethinking missions

Previously, the idea for Heat Signature would be that you would start the game with a single target to hunt down and eliminate, however you like. But, as I discussed in a dev log video, the business of actually searching for your target was inherently unfun. I replaced it with a system where you get progressively closer to finding them almost regardless of what you did, which was better, but weird.

Now I’m thinking that you’ll choose a class at the start, then be given a series of shorter missions of that type, forever. Assassins will be assigned to kill specific crewmembers on specific ships. Thieves to steal particular bits of tech from particular ships. Interceptors neutralise hostile ships. Exfiltrators capture and retrieve their targets alive. And you do as many of these missions as you can without dying.

I have the beginnings of that working: randomly generated assassinations and thefts that feel cool to pull off. But I haven’t entirely settled on whether the game will have permadeath or autosaves: I hope permadeath, but certain frustrations need to be solved design-wise before I can do that without causing bad situations.

As you can see, the “Who are you and what are you trying to do?” part of Heat Signature changes a lot, even as the game mechanics stay roughly the same. So these are just my latest thoughts, we’ll see what I settle on by the time I come to make the next proper demonstration video. It’ll be a while though, lots of basic tech stuff to redo first.

I’ve been designing and trying various ways for you to make progress towards your objective in Heat Signature, and four bad iterations have led me to a surprising conclusion.

Better still, the rate of change in jerk is called ‘jounce‘. After that, though, physicists seem to run out of juicy, evocative words:

“The fourth, fifth and sixth derivatives of position as a function of time are sometimes somewhat facetiously referred to as “Snap”, “Crackle”, and “Pop” respectively.”

I feel like we can do better than that. So here’s my proposal for the first thirteen derivatives of position over time:

Change in position: velocity
Change in velocity: acceleration
Change in acceleration: jerk
Change in jerk: jounce
Change in jounce: hyperjerk
Change in hyperjerk: meta-jounce
Change in meta-jounce: binge warp
Change in binge warp: migrational spank
Change in migrational spank: barflurch
Change in barflurch: dark jaunt
Change in dark jaunt: catastrophic snap
Change in catastrophic snap: whipfuck
Change in whipfuck: Newton’s torment

Anyone want to take it beyond thirteen?

I was testing the new code just now, and headed for a small ship to dock with it. It had rubbish heat sensors, so I came in pretty hot, and my ship was still cooling on its hull when I docked and snuck aboard. Unfortunately, at that exact moment, a much, much larger ship with much, much better heat sensors went past – and immediately spotted my still-warm ship latched onto the smaller one.

Ships have heat-seeking missile launchers now, of varying number, and when they attack they fire all of them. So as I’m dealing with the first guard in the small ship, four missiles slam into it. One destroys the module my ship was latched onto, sending it drifting into space. I run for the guard and knock him out, just as a missile destroys the room I was standing in a second earlier.

Two more rooms are blown off the smaller ship, leaving not much left. And once a space war starts, it doesn’t stop: the big ship might not have been aiming for the small one, but they’re enemies now, so they’ll shoot it out until one of them dies. And with four missiles per volley and only three rooms left on this ship, I don’t like our chances.

But it suddenly occurs to me that a ship doesn’t have to be obliterated to ‘die’. If you knock out the captain, its lights and sensors go out and other ships see it as defunct. The time between missile volleys is also randomised – somewhere between 3 and 6 seconds right now – so I had no idea if I had time, but I tried it anyway: I sprinted for the cockpit and smacked the captain unconscious. The lights went out, everything went quiet, and… nothing.

I zoomed out just in time to see the bigger ship’s sensor radius slip off screen as it cruised off.

I was still boned of course, stranded on this ruined ship without one of my own to leave in, but it felt like a fantastic moment. I’d never even thought of this as a tactic until I randomly found myself in a situation where it was the only way to survive.

Heat Signature is a game about randomised space ships that you can sneak aboard. These ships have a randomly generated interior of connected rooms and corridors, and crew that patrol those rooms.

Right now, there’s no pathfinding: the crew roam randomly. At some point, though, you’ll be able to set off alarms or cause other disturbances that the crew should run to. So the problem is: how do find a route to that room? Specifically, how do they find the shortest route to that room?

I could cheat a bit: right now each row of rooms in a ship is always internally connected, and each has just one door to the next row. But I might change that layout logic, and as I’ve been planning the features for Heat Signature, I’ve noticed something interesting: a lot of the problems I’ll need to solve utlimately boil down to: “Is this module connected to that one?” and “If so, what’s the shortest route?”

Crew pathfinding is one. Player pathfinding is another, if I keep the current controls. But also, when a ship is hit by a missile, the module that got hit is destroyed. If you blow up enough modules to cut a ship in half, it ought to break apart. How do we tell when that should happen, and which modules should belong to which half? Well, we need to know “Is this module connected to that one?”

Fourthly, and this is just a pipe dream, but if it’s not too hard I would love to have vacuum suck you out into space. So when that module gets destroyed, it takes a second for the doors that were leading to it to seal, and everything would be sucked towards it in that time. To figure out what gets sucked and in which direction, we’d need to know: “Is this module connected to that one?” and “If so, what’s the shortest route?”

In programming, you’re always hitting challenges other people have already solved. The best policy is to do your research, find out what the best solution out there is, and adapt it to you purposes. But I hate research, and I love figuring things out, so I have a different policy: try to figure it out for yourself. If you can’t, or your solution seems insanely hard to implement, then look it up.

So I haven’t looked up how you do pathfinding – I’m going to try my own way first. And since it’s a big subject and I’m blundering through it in my head, I thought I’d write out the approach I’m going to try before I actually try it, partly to make sure the logic is sound before I do the legwork of implementing it. So here’s my plan:

Pathfinding By Induction

In maths, there’s a very useful process called induction: if you want to solve a problem for all numbers, start by solving it for ‘1’, then use that result for ‘2’, and so on. Algorithmically finding the shortest route between two distant points in a selectively blocked grid seems daunting to me, so I think I’ll start with the case I can solve and work from there. If two modules are connected by a door, I can definitely tell you the shortest route between them.

It would work like this:

Every module is assigned a number, from 1 to however many modules there are on the ship.

We want to give every module two lists: one is how far it is to each other module on the ship, and the other is which way you should head if you’re going to that module.

So if the Cockpit is module 1, module 8’s lists will hopefully end up including something like:

• DistanceTo[1] = 5 modules
• NextStepTo[1] = go to Module[7]

But we don’t know that yet. So when the ship is created, all these distances are set to a big number (ModuleCount) – no module knows of a good route to any other one yet.

Then we go through the modules one by one.

For each module, we check to see if it has a door to any of its neighbours.

For each of its connected neighbours, we say:

• The distance to that neighbouring module from here is 1 (DistanceTo[n] = 1)
• To get to this module, just head straight to it (NextStepTo[n] = Module[n])

These ones are easy! But obviously we can’t stop there. So we also look at the neighbouring module’s list of distances to each other module in the ship, and ask:

• Is your best known distance to that module much (2) shorter than ours?
• If so, we can find a better route to that module by going through you!
• Our distance to that module is now your distance + 1: we take one step to get to you, then use your route (DistanceTo[d] = Module[n].DistanceTo[d] + 1)
• So our NextStepTo that module is you (NextStepTo[d] = Module[n])

So that’ll get us some routes to modules that aren’t our neighbours, but obviously it won’t get them all – not on first run. When we run this for the first module in the ship, none of the other modules have routes to anywhere, so it’ll only know about its neighbours.

But this process is sound: it’ll never replace a good route with a worse one, and each time you run it it’ll find efficient routes to more and more distant modules, until all the lists are optimal.

How many times do we have to run it for that?

Well, we can stop running it when the routes aren’t changing anymore – if none of them change on one run, they also won’t change on the next one, so the process is finished.

Why This Method?

For a single pathfinding operation, this method is probably super inefficient: it involves a lot of nested loops, so the total number of operations it’ll do is very high. I’m trying it because:

a) I’m too dumb to see how to optimise it, and
b) it doesn’t really matter if it’s a bit slow, because it doesn’t need to run at all for people to navigate. Every room has a static list that tells everyone where to go next without performing any actual calculations. So you could have thousands of crew and thousands of modules and still spend zero cycles on pathfinding. It only needs to recalculate when the ship physically changes shape, which happens much more rarely.

It’s probably still a dumb method and I’m sure many of you will point out problems or better ways of doing it – please do! But I’m interested to give it a go and see how it works. I might even put in some visualisation stuff so I can see it working, and the paths it creates.

Update

It worked! Here’s a shot where every room is showing the shortest route to the player from there (click for big):

Next step is to check it works when a ship is damaged – maybe I could also make crew run to the point of impact to give it a test run, too. Might do a video once everything’s all working together – I’ve also added heat seeking missiles and infighting between ships since the last one.

And in the showing-games part, there was Dry Ice: a top-down local multiplayer game in which all four of you control craft that go invisible – even to you – until you fire.

(I talk more about both these things in the latest Crate and Crowbar podcast)

I was there partly to show both the games I’m working on, get people to play them, and ask them which they preferred. That forced me to get both in suitable shape to be played by strangers: as soon as I committed to doing it, I realised the grappling hook game needed objectives to make the co-operative movement useful, and Heat Signature needed visibility tweaks and player guidance to make it comprehensible.

Once I had a build of each ready for IndieCade, I made videos to show their current states to the internet too. The internet spoke pretty clearly: the grappling hook game’s video has about 3,000 views, and Heat Signature’s now has 27,000 and got coverage on big gaming sites.

At IndieCade, though, the first three people to play both prototypes all said they liked the grappling hook game more. Two people said they were more excited by Heat Signature at first, but changed their vote after playing the grappling hook game. And after around ten people had played or seen both games, the votes were about 60% in favour of the grappling hook game.

That’s not a significant lead, and a tiny sample size compared to the internet, but it’s alleviated my worry that the grappling hook game might have been really far from working. The build I showed has lots of extremely awkward control problems, and I think with a few simple fixes it would have got an even better response. As with Gunpoint at the IGF in 2012, lots of these were things I knew were problems, but wasn’t 100% sure how to solve until I saw people struggle with them right in front of me.

It’s always been the plan to make both games, and it still is. I was showing the two partly to force myself to focus on what each one truly needed to be playable, partly to see if either one of them was just not going to work for people, and partly to see which one it makes sense to finish first.

It seems like they both work, but Heat Signature will be a lot quicker to finish. I’ll keep working on Grappling Hook Game in between – I’m excited about making those tweaks – but I have a clearer picture of how to prioritise them now.

Speaking of which, I talked a bit about both games, and story in Heat Signature, and the appeal of sudden death, in this here interview.

Here are some more photos of IndieCade and New York.

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.

“Well,” I tell them…

When will…

I don’t know.

I didn’t finish my question!

If it starts with ‘When will’, my answer is always ‘I don’t know’ – I learned from Gunpoint that it’s pointless, impossible and even harmful for me to guess how long developing something will take me. Don’t worry about it dragging on forever, though, I’m incredibly impatient.

When- LET ME FINISH – when it is ready for testing, can I get in on that?

Quite possibly! When I do get to that stage, I’ll let the Suspicious Developments Mailing List know how to sign up, so join that.

What are you making it in, and will it come to Mac and Linux?

Game Maker Studio, a more modern version of the same tool I used for Gunpoint. I can’t be sure about non-Windows platforms because I’ve never tried those before in Game Maker (Gunpoint’s were handled externally). If I export it and it just works, great. If it’s riddled with platform-specific problems, then I’m not gonna promise I’ll have the time and talent to fix enough of those to make it good enough to sell.

Will you do a Kickstarter?

Nope, my share of Gunpoint’s earnings fund Heat Signature’s development.

Will you do Early Access?

I don’t plan to. I definitely wouldn’t put the game up in a rough state and start charging for it – I never want to sell a thing I don’t believe is worth the money in its current state. The other possibility is to get the game into a good state and then use Early Access like a final beta. I’m not against that in principle, but my current plan is just to keep doing closed alphas you can sign up to.

Weren’t you learning Unity? Why did you switch back?

I still am. I’m using Game Maker for Heat Signature because part of the appeal of the idea, to me, was that I already knew how to make it in the tools I’ve previously used. I’m very slow and very bad at Unity by comparison, so I want to keep learning it while still getting something done.

I want to make a game, should I use Unity or Game Maker?

If you’re a complete beginner and your idea would work in 2D, I suggest Game Maker because it’s so much quicker to learn.

If you have some programming knowledge, or your idea needs to be in 3D and you’re patient, I suggest Unity: it’s more flexible, it’ll probably be easier to work with other people, and the asset store is really cool. Unity can do 2D games, but I haven’t tried it for that.

What tutorials do you recommend for Game Maker or Unity?

For Game Maker, mine! I did a video series talking you through making a game with no coding experience, with the free version, in 16 hours. For Unity, I used and liked Alec Holowka’s, but they’re for JavaScript and you’re probably better off in C# in the long run. These days I’m mostly just using the stuff on their official site.

Can I suggest something?

Yes, but! Don’t make a suggestion if you would be upset to see that suggestion in the game without credit to you. It’s very common for people to suggest things I’m already planning, and luckily so far everyone seems lovely and just happy the game is going in the direction they’d hoped, but I’m aware of the potential for someone to get the wrong idea.

I can now show you what my space stealth game is really about! As long as I don’t get spotted like three times in a row right at the start of this video. Watch that first if you care, if not, here’s the summary.

• You fly around in a little ship with no weapons, trying to avoid being detected by big, powerful, randomly generated space ships.
• If you can sneak up on them and stay cool enough to avoid their heat sensors, you can latch onto their airlock, breach it, and climb aboard.
• Once inside their ship, you’ve got to avoid any armed crew patrolling the corridors and rooms of the ship, and if you can get to the helm and subdue the captain, the ship is disabled.
• In future, ship systems like guns and thrusters will be in specific rooms of the ship, and you’ll be able to sabotage or control them if you get there. You’ll also be able to fly their ship if you get to the helm.
• My plan is that each time you start the game, you’ll be randomly assigned a profession and a target: “You are an assassin. Your target is Tom Francis.” or “You are a shipjacker. Steal the Dreadnaught Incisor.”
• You’d locate your target by boarding ships and hacking their server, which would either give you info on your target’s location, or on which types of ships are likely to have that info.

If you’re interested

If you want to be told when it comes out, or when I’m looking for testers, get on the Suspicious Developments mailing list. I only use this for very rarely for major news like the above, it’s mainly a way to ensure you don’t miss anything big.

For more regular shots and dev diary videos and stuff, you can follow it on Twitter @HeatSig.

Thought I’d take a break from programming talk to get into game design, and how I approach it. I am aware my mug is ridiculous – it’s an old GTA III promo one.

I’m bad at shutting up once I get talking about this stuff, so I’ll also summarise the basic points in this post. Not all of this stuff is in the video and not all of the video is in this – good summary Tom.

Starting

I usually have an idea for a game when I’m excited about something else. With Gunpoint, it was thinking of cool ways to infiltrate buildings in Deus Ex.

For the Grappling Hook Game, I was watching a great Chinese/Korean heist movie where they use a lot of ropes (it’s on Netflix: The Thieves), and it clicked with all the rope-related moments I’d loved in Worms and Chaos Theory co-op and Rainbow Six: Vegas.

And for Heat Signature, it was an old idea I’d had for a triple-A 3D roguelike, which I’d always assumed to be impossible. I got talking to Graham about how it might work in 2D, and the more we talked about it the more doable it seemed, and the less I felt it needed to be anything else.

With all these, what turns it from ‘something I’m excited about’ to ‘something I want to make a game about’ is a conviction that this exciting, magical thing can be compressed down to a simple set of rules. Rules that wouldn’t just be a crude shadow of what’s cool about these things, but actually condense what makes them exciting, and generate that excitement again and again.

Making Things Modular

When there are big sweeping unknowns in how I’m going to handle something in a game, they usually get cleared up when I find some way to classify what needs to fill that gap, to summarise it as a simple template that can be varied and repeated to create things that’ll be interestingly different.

In Gunpoint, the question of “What kind of things can you hack?” was answered when I figured out how to define these things: each one is an electrical device, each one can be connected to any other, and each one can trigger whatever else it’s connected to. From that template, I can fill the levels with these crosslinkable ‘modules’: light switches, electronically locked doors, security cameras, trapdoors, etc.

How that same principle applied to Heat Signature is what I talk about in the video above.

Leaving Flexible Gaps

It’s very hard to answer all the unknowns in a plan all at once, and it doesn’t really make sense to – you need to make some of it to really bring into focus what it’s missing or what it would benefit from. So it’s good to leave these gaps flexible: I try never to say things like, “And I’ll have to come up with a full text parser to make AI-driven conversations work.”

It works out better if you keep that gap flexible: “And then you’ll talk to these characters, but I’ll decide how in depth and interactive we make that when I come to build it – anything from completely pre-scripted text boxes to dialogue trees to the nutty text-parsing thing.”

Having A Plan And Not Sticking To It

I do plan, a lot, but it’s more like navigation than a strict design document. I hate to waste time, and making things work is very time consuming, whereas purely theoretical design is very easy. Purely theoretical design can’t fully predict what the finished system will feel like or what the consequences of it will be, but it can foresee some problems, and when it does, it’s usually right.

There are an infinite number of things you could make – it doesn’t make sense to spend your time exploring ones that already seem problematic after a few minutes mapping them out in a text document.

But having that document doesn’t stop you from changing course when the thing you build turns out differently than you imagined. The plan for the Grappling Hook Game says only one character should have the grappling hook, to encourage co-operation. Now that I’ve built that much, playing as the non-grappling hook characters feels a bit paralysing, so now I’m figuring out if it’s viable to give them all grappling hooks in addition to their speciality gadget.

If that feels good, the whole game could become about latching onto friends and swinging off them mid-air to do ridiculous things. If it doesn’t, maybe the solution is just to improve on-foot movement or something. I don’t know yet, but the plan is always just ‘what seems most promising on paper – try this first’.

Here’s the first video of Heat Signature, a temperature-based space stealth game I’ve been making the last two days. It’s about sneaking up on ships while keeping your ship cool enough to fool their sensors.

So you can jet around an infinite galaxy super fast, but your thrusters generate heat, and enemies can detect that from far away. The closer you want to get to them, the cooler you have to stay, and the more precise you have to be with your thrusters. And to take them out, you have to physically clamp onto their hull and shut down their systems.

GHGC is still my main project, I’m just taking a break from the brutal process of learning Unity to make something quick in Game Maker, where I already speak the language. How far I take this depends on how the next few features work out.