Click through for details on each:

• Character Traits
• 7 New Hazards
• Glory Missions & Clients
• Upgraded AI & Reworked Alarms
• Player Story Trading Cards
• Contractors: 4 Unique Enemy Types
• The Daily Challenge
• 10 Quality of Life Features

This update is a one-off, we don’t plan to do updates like this on a regular basis. You should only buy the game if you want it in its current state – we don’t make promises about future content.

This update was made by
Tom Francis: design/code
John Winder: code
John Roberts: art

Dedicated to John Francis
We started this update in April this year, and my dad passed away in May. He was an electrical engineer, a software engineer and an inventor. He got me into computers at an early age, inspired me to be ambitious with his infinite faith in me, and protected me from the fear of failure by making me feel I could never disappoint him. I hope everyone reading this knows they deserve that kind of boost in life, whether you’ve been lucky enough to receive it or not.

Dad was extremely excited when my games took off, making his own graphs and projections from the sales figures I sent him. All of you who bought Heat Signature or Gunpoint made him so happy and proud. I hope this update can say thank you for that.

Once I calmed down and read them, though, I was delighted: they were not only very positive, but they told entertaining stories and made intelligent points. And almost every critique I read I thought was a fair point. Hence this:

The Fair Points Update

5 new features and 3 new items, in direct response to review critiques, designed to round the game out and make it more fun for more people.

We also added a gun that fires acid money to melt the flesh from your enemies and leave only chemically bleached bone. No-one asked us for that, we just kind of did it, and now here we are.

This post goes into all the design logic, critiques and features – if you’re only interested in what’s been added, the Steam Announcement covers only that.

Fair Point 1: if you can’t manage Hard missions, progression is too slow.

That’s true, and intentional! I made two assumptions here, both wrong:

1. If you do enough Easy and Medium missions, you have good enough kit that Hard ones become doable for players of any skill level.
2. Easy and Medium missions are boring, and you should eventually be forced to do harder ones.

As it turns out, some players struggle to ever do Hard missions even after acquiring a lot of gear, and are dying often enough on the Medium ones that they’re usually playing with a new, under-equipped character.

Separately, I was surprised to hear that these players really like Easy and Medium missions. They’re having fun!

But the fix isn’t as simple as increasing the rate of liberation progress for easy missions. Most players do have a better time when pushed to take harder missions, so harder missions need to reward you more. And the rate of progress should not be faster across the board, or the game becomes too short for those players. What we really want to do is check: are you making progress too slowly? And if so, can we help you out with that in an interesting way?

Feature 1: Liberators

If you haven’t liberated a station in a while, one of your choices on character select will be a Liberator: a randomly generated character with high-level gear, and a personal mission to liberate a particular station. They already have the intel and the kit to go out there and do this, so you can just pick them and head straight out.

If you don’t usually last long enough to find high-level gear, this’ll be a nice chance to try some out – and to keep it after you’re done. Because these characters only appear after you’ve gone a while without liberating a station, they don’t make the game any easier or faster for players who aren’t struggling. They should just ensure that progress is never too slow, whatever your skill level, and that you’re unlocking new things and having new experiences along the way regardless.

Fair Point 2: Stronghold liberations are too hard for some players

Heat Signature’s philosophy is to always give you a huge range of difficulty options for every mission, to cater to all skill levels, all character levels, and player tastes. We didn’t really do that for Strongholds, the 4 climactic missions you have to do to complete the game – they’re just outright hard. Perfect for some players, nigh impossible for others. It wouldn’t quite work to let you choose the difficulty of these – there’d be an incentive to play it safe and make them easier than your real ability level. So instead:

Feature 2: Stronghold Liberators

If and only if you fail a Stronghold mission, you’ll find a Stronghold Liberator in the bar. These are like the other liberators but even better equipped, so they should make Stronghold missions easier. Still not easy, but you can also afford to take more risks and lose them, since it’s not hours and hours of progress on the line. And each time you’re offered one, their kit will be different – so may be better or worse-suited to the job.

Fair Point 3: Permadeath encourages you to choose missions below your skill level, because so much is at stake

Huh! This one completely surprised me because it makes perfect sense and yet I’ve never experienced it. I play Heat Sig with a cavalier attitude, taking on missions I’m not at all sure I can do, assuming I’ll figure it out or at least be able to abort in spectacular style if things go south. But if you’re more risk-averse about your characters and kit, it’s true, the threat of permanently losing them is a factor pushing you to take easier missions, not harder. And for the reasons above, that’s the opposite of what we want to do!

Feature 3: Glitchback Guarantee

Sometimes, one of the harder missions on offer will come with a Glitchback Guarantee. This means your client will teleport you out the moment you get hit, avoiding any permanent damage. So there’s absolutely no risk in taking these missions, you can’t lose anything no matter how badly it goes. It doesn’t make the mission easier, though – if you have to be glitched out, the mission is canceled. So this also serves as a modifier to make some missions trickier: you only get one shot.

Even though we added this feature to cater to players who think the opposite way to me, I’ve ended up really enjoying it myself. I’ll just dive into an Audacious mission with a brand new character and no real hope, and just see how the chaos plays out.

Fair Point 4: I just don’t do missions with shielded or armoured guards

Aha. These two types of kit are special, in that they are nearly impossible to deal with without specialised tools. That’s intentional, for two reasons:

1. It makes those tools especially desirable, creating a progression path and meaningful differences between what different loadouts are good for.
2. Sometimes, having to deal with an enemy you cannot take out gets really interesting, and brings out possibilities you don’t otherwise discover.

Where we screwed up, a little, is that you don’t know how many of these you’ll encounter. So even if you have a 5-use Crashbeam, you might not take a mission with shielded guards because there could be 15 of them. So you play it safe and don’t take it.

Feature 4A: Guard counts

You’re now told how many of each type of guard you’ll encounter on a mission, so you can plan accordingly. You’ll be able to tell: yes, I have enough tools to deal with this many shielded guards. But I’m also hoping you’ll sometimes think “I nearly have enough tools to deal with that many, I bet I can avoid the rest….” A 5-use Crashbeam vs 8 shielded guards is a much more interesting proposition than an unknown number.

We’ve also made the number of bosses on a mission something that can vary separately, to increase variety: so you’ll now see missions that take place on a large ship but with only a handful of armoured bosses, and others where there’s more than one boss per cluster. There are more missions with 3-6 bosses, which is very doable if you have just one tool that deals with their protection type.

Feature 4B: Acid and Crash Traps

We’re also adding two new item types to help you better deal with armour and shields. Acid Traps can be placed to strip the armour of any guard who walks on them, and Crash Traps will crash all of their electronic kit, shields included. You’ll have to use some guile to set them up and lure the target into them, but they both come with a powerful advantage: they’re always self-charging. That means even the common ones are endlessly re-usable, so there’s no upper limit on how many armoured or shielded guards you can deal with – if you can lure them in.

Fair Point 5: I sometimes have trouble making things out

We did a lot of work on clarity before launch, and saw great improvements in feedback – I think we got it to a point where it’s clear enough for the vast majority of people and also looks really nice. So I was gonna say “screw it, we did our best”. But then my friend Zack said two interesting things on the subject:
1. He has the same kind of colour blindness as at least one other person who had this trouble.
2. He wishes there was a mode he could turn on that made everything ultra-clear, regardless of the visual quality cost.

We haven’t heard about a specific colour-based distinction that’s causing trouble (we avoided knowingly relying on colour alone for this reason), but that angle helped me realise this is an accessibility issue. It doesn’t really matter whether the cause is an eye thing or a brain thing, if a percentage of people can’t see what’s going on, we should fix that.

His second point made it easier to see how we could: clarity is only hard if you’re trying to also optimise for visual richness and variety. We successfully did that for most people. For those we left behind, clarity is waaaay more important than prettiness. So if we have a way of making it clearer but less fancy, let’s make that an option!

Feature 5A: Simple Art mode

Under Accessibility Options, there’s now a Simple Art Mode you can enable. It makes all ships use a simpler version of the Foundry ship look, which is already our clearest and plainest. We’ve clarified and plainified it a bit further in this mode: the traversible space is almost entirely blank, and the solid stuff is tweaked to all look identical. Hope this helps!

Feature 5B: Explosive guard annotations

We now annotate explosive guards when they first appear on screen, since some people had trouble spotting those. You can turn this off in the options if you don’t like it.

Fair Point 6: I just hate permadeath

OK, no reviewer said this. But one or two players did, and my mental response was “Well, this game is not for you.” I’m not gonna completely remove permadeath, it would be a totally different game, and one that generates less interesting stories overall.

But maybe that’s not the right question. It’s not: would the game be better without permadeath? It’s: can we help the players who hate it? Is there something we can do for them? And that’s actually an easy answer: sure! We could let them turn it off.

This is a bit mad, so I’m interested to see how it works out. I’m very intentionally moving away from ‘auteur protecting his precious artistic vision’ and towards ‘let’s welcome everyone we can’ – as long as we can do it without affecting players who are alrady having fun.

Feature 6: A Cheat Option to turn off permadeath

We’ve added this under Cheat Options to be clear that it’s not how the game is meant to be played – I don’t want other players to feel like they’re being asked to design how the game should work. This is a cheat. Play without it unless you need it. We warn you about the ways it can make the game less interesting. It’s only there for people who cannot enjoy the game as it stands.

When permadeath is off, anything that would normally permanently kill your character instead resets you to when you were last at a station.

Fair Point 7: As it stands, there’s no way to strip the flesh from my enemies with a corrosive form of currency?

Yes, sorry, that was an oversight.

Feature 7: The Fleshstripper

The Fleshstripper is a new unique weapon that fires the same acid used as currency in the Drift – extracted from those colourful nebulae you’ve been flying through. It belts out a heavy rain of the stuff in an arc, melting through armour and flesh alike, leaving only skeletons behind. Its ammo is your savings: it costs 1 acid to fire.

From the 22nd of Space November to the 6th of Space December, there’s a shipment passing through the drift carrying the Fleshstripper – that’s your sure-fire way to obtain it. Regardless of whether you steal the shipment, it’s also available to all players as a very rare random drop.

A note on Updates

Us: Here’s a significant free update!
You: Great! I can’t believe we get these regularly for free forever!
Us: Oh, geez. This is awkward.

This update is a one-off, we don’t plan to do updates like this on a regular basis. We might add items from time to time, but only buy the game if you want the game as it stands – we don’t make promises about future content.

Nominate us in the Steam Awards!

Heat Signature is all about player choice, so we would never try to influence how or when you choose to vote for us in the Steam Awards, in the ‘Choices Matter’ category for player choice, before the 28th of November, by clicking here. That would have to be your choice.

Either way, if you’ve played enough Heat Signature to know if you recommend it, we’d love for you to leave a quick review! As you can tell from this update, we like reviews.

Removed: Death

Due to science, you cannot die during Space Halloween. Bleeding out, suffocating, or being incinerated in an exploding pod will permanently turn you into a living skeleton. Once Halloween is over, you’ll remain a skeleton but any lethal damage will finish you off. On the plus side, skeletons are undetectable by guard’s heat sensors, and can spacewalk indefinitely since they no longer need to breathe.

Actual Ghost Missions

When taking a mission with the Ghost Clause, you are now an actual ghost. As with real-life ghosts, you can still be seen but all attacks pass through you. You’ll return to normal once the mission is over.

Actual Skeleton Crew

Ships running a Skeleton Crew are now literally running a crew of skeletons. The skeletons are functionally the same as normal guards except that they can no longer feel hope.

Does That Mean I Could Potentially Become A Skeleton Ghost?

That’s a ridiculous question. Of course you can become a skeleton ghost.

A few other patch notes here. If you don’t have Heat Signature, well, getting it would be step one.

Update On The Everything Gun

It’s been great to see how much people are loving this very silly weapon, and how excited people are to send us shots of them finding it. One thing I didn’t forsee was that for a small number of people, it could cause anxiety: the fear of missing out, or even when they have it, the fear of somehow losing it. So we’re going to simplify it:

If you play any time between now and Oct 5th, you’ll unlock the Everything Gun as a random drop.

Within six months, we’ll unlock it as a random drop for everyone.

I hope that allows it to still be a special thing for everyone who was part of our launch, without causing anyone worry. A few more details if you need them:

• If you’ve already stolen it from the shipment (even if you died right after), you’ve already unlocked it even if you don’t play again before Oct 5.
• You can still steal it from the shipment if you haven’t already, that’s just a reliable way of obtaining it the first time.
• Its unlocked status is stored both in your saves and backed up on Steam Cloud (unless you’re playing off Steam or have disabled Steam Cloud).
• It’s a file called Progress.dat if you want to back it up manually.
• Once it’s unlocked for everyone it’ll just be in the game, no save file involved, so there isn’t and never will be any way to permanently lose it.

Three things to know about finding it as a random drop:

• It’s a Unique Item, the rarest tier, so it doesn’t come up frequently.
• It’s a Unique Item, so there’s only one per galaxy. If one of your active characters has it, you won’t be finding it in crates in this galaxy, because look, there it is, that person’s got it.
• Any time it’s not owned by one of your active characters, you can find it. Doesn’t matter how/why/when it was lost. Doesn’t matter if a character retired with it and didn’t pass it on. Doesn’t matter if you blew it up or flung it into space. Honestly it sounds like you’re trying to lose it, but tough, you can’t.

How The Launch Went

Heat Signature has been out for six days, and my God. It has been a storm. The good kind. It took three and a half years and I spent about £200,000 on it, making it probably the biggest risk of my life. And by the time it was done, the chance for any given indie game to succeed had dropped enough that the term for this trend ends in ‘pocalypse’.

I knew I wouldn’t have another Gunpoint-size success – that came out in the sweet spot for indie, when demand was high and supply was low. So my best-case-scenario was to do half as well as Gunpoint did in the same timeframe.

It’s done better than Gunpoint. Not by much, and it’s too soon to know if it’ll have the same long-tail Gunpoint did, but so far it really is a Gunpoint-size success. We hit #1 on Steam on launch day, and stayed in the top 10 for most of the week. Thank you so much to everyone who bought it and spread the word, and to everyone who’s left such lovely reviews. This was a huge gamble and I’m so relieved and grateful and frankly surprised it paid off.

If you haven’t got it yet but plan to, the 10% discount ends tomorrow.

Reception

The other shock is how people are reacting to it. I knew I’d designed a weird thing – it’s like a roguelike but in a persistent world, it’s like Hotline Miami but it’s not about skill, it has a goal but it’s not the point. Whatever you think it is before you play, it’s probably not quite that, and I’ve seen that not-as-expected thing lead to a bad reception for games I love.

That does not seem to have stopped it. Overwhelmingly people get it, and I can use that word now because at time of writing our user reviews are ‘Overwhelmingly Positive (95%)’ on Steam. But more than that, so many people are having the perfect response to it: they’re telling stories. For me a Story Generator is one of the highest goals in game design, it’s the common thread between my love for Deus Ex, Spelunky and Invisible Inc. So it’s wonderful to see Heat Sig is not just generating ones that players enjoy, but ones they’re excited to share. This didn’t happen with Gunpoint – people liked it, but at best they’d share jokes I wrote, not unique experiences they’d had.

If you browse a Twitter search for @HeatSig you’ll see them still pouring out. This one by my friend roBurky is a favourite. Today someone sent us fan art they’d done of their own characters, their own story. That feels like a sign we got something important right.

Which brings us to:

Our First Player Legend Trading Card

We want real player stories to be the legends of Heat Signature’s world, so we’ve been asking you to send us clips of your hijinks and turning the best ones into our Steam Trading Cards. We’re still accepting these on Twitter and haven’t nearly finished selection, but one came in that was such an easy Yes that we made the card right away. I’m posting it now to give you an idea of the glory that awaits you, and what a good entry looks like. To be clear, you just send us the clip (below – put @HeatSig at the end not the start) and say roughly what happened – John does your glamour shot, I give you a nickname and write your story. (I’m a recovering games journalist, let me have this.)

Ferris ‘Swapshot’ Harris

As a ship’s security guard, especially as an armoured elite, you have to be ready for anything. This one saw Ferris Harris coming. He saw an Offworld Angel coming at his ship’s broken window full burn, and even though he knew it couldn’t dock, he was ready for whatever other nonsense they were about to try.

At the moment of impact, Harris hit eject. He threw himself from his pod, through the pressure-retention field, and skidded to a halt directly in front of the guard. The guard didn’t flinch. He fired. And Harris swapped with him.

The guard was not ready for this. He suddenly found himself staring at the blue glow of the forcefield Harris just came through. He couldn’t process the situation fast enough to realise what would happen next: his own bullet hit him in the back of the head. His heavy armour saved him from the lethal impact, but the force was just enough to nudge him one step forwards – into the pressure field.

What we don’t know is if, in the 15 seconds between being flung into the icy void and asphyxiating, he had time to figure out what the hell just happened.

Now

Now I’m in a state of simultaneously needing a) a break, b) to catch up on a backlog of urgent things I let slide during development, and c) to tweak the game in response to feedback. But I’m happy to be doing all that in the aftermath of a success, rather than eg. the shadow of a massive financial disaster. So thank you for that!

Or you can buy it from the Humble Store.

Supporter’s Edition

There’s also a Supporter’s Edition, which comes with a bunch of fun extras:

• Play through Heat Signature’s development with 8 early prototypes from its 3.5 year development.
• Watch 9 developer commentary videos showing and explaining its evolution: from drilling through hulls to liberating empires. (Total: 70 minutes)
• Own the full soundtrack in 320kbps MP3 format. (19 tracks, 83 minutes)

And on the Humble Store.

Technical Issues

If you’re having any technical issues, we’re posting any known solutions here, and you can report bugs to us here.

Thaaaaaaaanks!

We don’t do pre-order bonuses because I don’t want to pressure you to buy before reviews are out. But I am super grateful to those who buy at launch, because our whole future depends on how we do that first week. So we’re doing a few special things to celebrate it and thank those of you who are joining us:

Unique Shipment: The Everything Gun

For the first two weeks, there’s a ship carrying a unique weapon passing through the galaxy. It’s called the Everything Gun, and if you steal it, you’ll also unlock it as a random drop in this and all your future games. More info below.

–

Be One Of Our Trading Cards

Heat Signature is all about the stories that emerge from what you get up to in game, not our pre-written lore. So for Steam Trading Cards, we want them to be about your stories. We want to see GIFs or short videos of crazy situations you’ve got into or clever tricks you’ve discovered, and we’ll turn the best into trading cards with your name on! You’ll have the strange sensation of being traded, sold, and perhaps broken down to make a badge. More info below.

–

Unique Shipment FAQ

How do I find the shipment?
You’ll come across it randomly (about every 30 secs) as you fly around, quite frequently, and you’ll know it by a big golden light flashing on it, like in the video.

Does this mean I have to be online to play?
Haha, God no. It’s a single player game and we’re not assholes. This is just a bit of fun.

What happens if I board the ship but fail?
That’s fine! The ship will still be flying around until the date it’s due to leave, so you’ve got as many chances as you like, with whatever characters you like.

What if I buy the game after the date the shipment leaves?
Same, you won’t get the Everything Gun, and it won’t drop randomly for you.

If miss out, will it ever return?
Yes, though we haven’t planned when exactly.

Is the ship hard?
Nope! See the video.

–

Be On A Trading Card FAQ

What kind of clips are you looking for?

– Clever or ridiculous: my favourite are ‘I was in this impossible situation and here’s the mad thing I tried to solve it’
– Less than 1 minute in length, preferably less than 30 secs.
– GIF, GFY or very short YouTube clip. You can also link to a particular timestamp in a longer YouTube or Twitch vid if you like
– Cut, or link, straight to the good bit, or at most a few seconds before. No lead-in – if it needs that it’s probably not what we’re after.
– Tell us in the Tweet what is happening, as best you can in the character limit.

How do I submit one?

On Twitter! But!

– Do it as a normal tweet, not a reply to us – we’d like people who don’t already follow us to see it. That means don’t start your tweet with @HeatSig.
– Instead, mention @HeatSig at the end! You can say something like “I just did X in @HeatSig [link]” – that way we’ll see it.
– Upload or link your clip, obviously. GIFs uploaded direct to Twitter are the coolest, but I know they’re more hassle to make and if they’re more than a few seconds they won’t fit in Twitter’s 7Mb, so links are fine.

Example:
I just used a Glitchtrap to teleport a body into space and then Swapped with it to escape the ship in @HeatSig https://youtu.be/zGRddCgdKPQ

What’s the deadline?
We’ll start looking at entries September 28th, but we’ll keep accepting them until we have enough that we love!

How will I know if I’m picked?
We’ll reply to you on Twitter.

How will I be credited on the Trading Card?

We’d like to make the title of the card your name, but!
– If you prefer an alias we can do that (caveat below).
– If you’d rather we used the name of the character you were playing at the time we’re very happy do that (we can still credit your real name in the description or not, your choice).
– If we’re using your name or an alias it’ll be subject to our approval: we don’t want anything that is or sounds like a joke name or something that’ll clash with the fiction.
– We can discuss this if you’re picked.

The description on the card will probably be our summary of your cool moment.

How do I capture videos or GIFs?

If your PC has an nVidia card I like nVidia ShadowPlay. It’s included in the GeForce Experience (unfortunately you have to make an nVidia account) and you can set it up to always be recording, then hit a key to have it save the last 5 minutes. Amazingly it seems to have almost no performance impact. That’s what I do.

Otherwise, OBS is your best bet. You’ll want to go to Settings > Broadcast Settings > Mode > File Output Only to make it save to disk instead of streaming live. I think it can do a similar always-recording thing but I haven’t used it for that myself.

For editing, I like Avidemux.

For sharing, I suggest YouTube. In theory it’s possible to upload videos straight to Twitter but it’s never worked for gameplay videos for me.

To make GIFs, first make a video as above, then I recommend GIFCam for capturing the bit you want.

You just watch your video back and put GIFcam on top of it and hit Record. I’d say 16 fps is good enough for this, and you’ll need the file size to be under 7MB to upload it on Twitter, which is the best way.

Failing that, you can upload small videos to GFYCat and it’ll both GIF them and GFY them – GFYs are better quality equivalent of GIFs, but they don’t embed natively in Twitter.

• I made a new video showing off John Roberts’ excellent new art for the game’s four factions! (Not that surprising)
• I’m looking for a programmer in the Seattle area to help me finish the game! (Seattle part seems surprising)
• … because I’m moving to Bellevue to work on the game at Valve’s offices! (Extremely surprising but now the Seattle thing is less surprising)

Here’s the new video, which also shows what teleporters and the What Now? screen add to the game:

If you haven’t already, put it on your Steam Wishlist so you hear about it when it comes out. Also, if you were in on a Steam beta, it was probably taken off your wishlist because Steam briefly thought you owned it, so check. And if you want to be in on future tests, make sure you’re on the mailing list (top right).

The Valve thing

They want my input on something, and I’d obviously welcome theirs on Heat Sig, so I’ve accepted their offer to come and work on it at their offices instead of my bedroom. I’ll still be independent, self-employed and pretty much full time on Heat Sig, but I’m very excited to be around people again – especially these people. I’ll be there for 3 months at most, at which point the siren song of visa waiver laws will call me home.

The job (updated)

Found someone, thanks!

As well as the update above, I’ve been putting up some day-by-day logs of what I’m working on in Heat Signature. I’m only doing them for my own benefit, so they’re not mega interesting and I don’t do one every day I work – only when I think it’ll help.

If you’re in the alpha:

• Yes, it’s fine to stream, screenshot, write about, and publish videos of, monetised or otherwise!
• As requested in the invite mail, please don’t send me bug reports on Twitter or DM or e-mail, I’m getting bombarded with these from all sides and I can’t sort through them this way. Using the form means I have it all in one place.

If you’re press or anyone with an audience:
I’d like to fix the first batch of crashes and bugs before I really recommend you play it. Once I’ve done that, I’ll get in touch. If I haven’t already told you I’ll send you a key, DM @HeatSig (DMs are open) to let me know you’re interested.

If you’re just a regular joe, real salt-of-the-earth type, good people, never hurt nobody, keeps emselves to emselves:
Did you see we have a store page now? And a new short video? And that you can Wishlist the game, so you’ll be told when it’s out? See those things!

A brief history of zooming and backgrounds:

1. We worry about how to make the game look good at all the zooms between ‘local’ and ‘galaxy map’.
2. You ask if anything actually happens at those zooms. It doesn’t! I rejig the zoom system to skip them.
3. I find very close zooms are disorienting because there’s no background for a sense of speed.
4. You make tiling vapour layers and stars/dust.
5. I tell them to display at certain zoom levels, and fade in between. It looks good but is awkward code-wise, everything’s hard-coded to a certain zoom level and I have to create a new special case instance for each zoom level.
6. For unrelated reasons, I start to let the camera auto-zoom to keep two things on screen: eg. the player and their ship, if they’ve ejected.
7. The slow zoom-out gives an awesome sense of scale, except now the star layer tiles very obviously and soon the vapour layers stop showing and it’s all a big blur, which is kinda pretty but you lose the feel of ‘zooming’.
8. I think: “What we really need is for the layer itself to spot when it’s being asked to tile an unacceptable number of times, like 4, and if so create a new layer of double scale that we can fade up, and then when the old one is fully invisible, it destroys itself, and trusts the new one to spawn bigger or smaller layers as required and fade between them smoothly and destroy itself when it’s no longer needed. And vice versa for zooming in.”
9. Aeons pass.
10. I do it!

Update: better video!

• You can’t fly this fast, I’m using fast-forward.
• I fade the layers out entirely once the shapes of the galactic blobs are visible, so it doesn’t texture parts where there’s no vapour.
• The slight pulsing of vapour opacity on zoom is not intentional, though not sure if it’s worth fixing. It’s probably to do with the fact that two 0.5 opacity layers do not equal one 1.0 opacity layer.

It works! I love it. Feels like a real victory of code and art: we had this big scary problem, a gap in what we could do to a good standard, and we dodged around it for a while, and then your perfectly tiling dust layer and my new autozoom system came together in a way that suggested a smarter approach, and it just solves it completely. We fade through hundreds of orders of magnitude of scale, and the background layers just transition seamlessly as you go. And the sense of scale is so much better – it’s actually got easier to catch yourself in your pod now, because you can tell between ‘it got further away’ and ‘the camera zoomed in a bit’ – previously both looked the same.

This new system will mean I can tweak the zoom controls to not skip that big gulf between local and map, and use autozoom more liberally, for things like being chased or approaching an objective or an autopilot destination. Turns out once those zoom levels look good, there are a few gameplay uses for them!

• 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!

I’d like to use the term in game design to mean specifically that: numbers you can see. Things that are represented so simply and wholly and countably that you don’t need to display an actual numeric figure to tell the player how much they’re seeing. They can just see.

Here’s an FTL screenshot, showing how it presents your ship’s various weapons and systems:

FTL is a game with masses of systems and numbers and configurations, which are part of what makes it great: there’s a huge range of possible ship loadouts to put together, and a huge number of sophisticated ways for them to go wrong. But I never would have played it, and I suspect it wouldn’t have got popular, if it felt complex. It doesn’t – you learn it pretty quickly, and pretty much anyone can play.

For me, that was down to how ‘natural’ the numbers involved were, especially those power pips shown above. Do I have enough power to bring my drone systems online? You can see the three green pips of spare power on the left, and the two empty pips next to the drone system on the right, and you know immediately: yes. Interestingly, I don’t think this even involves any counting or comparing of numbers, in the mathsy sense – for small values like this, we have some kind of low-level spatial recognition routines that just come back with an instant “yes”.

It’s further simplified by how these natural numbers reuse their same values in all contexts: the hitpoints of each system is equal to the power it’s consuming and that’s also the total power of subsystems it can support. These are concepts you have to learn, but learning them is easy because there’s no maths to do, everything is one-to-one.

Here’s a screenshot of Heat Signature:

The player, in the small ship, is approaching a big ship. These are randomly generated and have lots of properties that vary from ship to ship, all of which are important. But there’s no stats panel for them, here or anywhere else, showing that info as bars or figures. Partly inspired by FTL, I show everything I can in ‘natural’ numbers.

What’s this ship’s attack rating? Well, it’s got one gun. That, to me, goes one better than answering the question. If an info panel said “Attack rating: 1”, you still don’t know what that means in real terms. I’ve spent hundreds of hours in RPGs without ever finding out what their ‘attack’ stat actually means – sometimes it’s like accuracy, sometimes damage, sometimes attack speed. But if you’ve ever seen a gun fire in Heat Signature, you know everything there is to know about this ship’s offensive capabilities right off the bat.

What’s its manoeuvrability rating? If you’ve ever seen a thruster fire in Heat Signature, you know that it has 4 of them and you have a sense for how it’ll feel to fly.

How many hits can it take? Well, one hit destroys one module, so just look at how many modules it has. Also inspired by FTL, things have a one-to-one-to-one relationship wherever possible. One gun fires one missile. One missile destroys one room. One gun takes up one room. So if you’ve ever seen one ship shoot another, you’ve already permanently memorised every conversion factor for every relationship between attack and defence, because ‘one’ is as natural as numbers get. So you can see at a glance how many hits this ship can take.

You probably can’t count how many, at a glance. But what I like about natural numbers, if you use them throughout, is that you don’t need to. There’s no reason you need to know whether there’s 13 modules here or 15, because nothing else is expressed in terms of figures. You can see that there’s that many.

That visual, spatial, intuitive sense data is more immediate, more memorable, and easier to compare than a dry number. If you see a ship with more guns than this has modules, no number comparison is necessary to see what happens next – in fact, you can’t help but picture it.

And your sense of by how much that ship is outmatched is more powerful than if you’d learnt it from figures: if you were on the smaller ship, the urgency to get off it would be that much more intense.

If you don’t, though, I don’t recommend buying it just to get in on this! This is very unfinished, very unoptimised, and time-limited: I will close it down in two weeks and then you won’t have it anymore. It exists purely to help me find problems with the game and get people’s thoughts, not necessarily to give them the best experience or one I’d charge for individually.

In case it’s not yet abundantly clear: this is not like early access, getting in on this alpha does not get you the game. As with Gunpoint, I’ll also be doing free closed alphas too, and I’ll let everyone on the mailing list know when they can sign up for that. This first one is just a perk of the Exclusive Edition, part of what I promised to say thanks to those who supported Gunpoint so generously. I did the same thing with Floating Point – Exclusive Edition folks got the first alpha, then later ones went to people who signed up.

All that said, if you are in on this test, I hope you like it! Please do follow the link in-game and fill out the feedback form at some point in the next two weeks – I’ll be keeping a list of all the people who actually give me feedback, so I can include you in some future tests if I want to make sure I get responses.

Not sure what to do with it from here. I like everything about it except the end, it has what I call ‘fat tail’ problem: no matter how gently I tell the alpha to fade out, the final, big chunk of vapour always looks like it ends rather suddenly, like your ship just has this big fat tail following it.

I like the idea that breacher ships of different factions would have different contrail colours, though. And I think engine upgrades will probably affect this too.

Here are a million shots:

I needed the airlocks to clear 4 squares on the ship’s collision grid, to give you room to stand. But I hit a weird bug: some of them, maybe a third, did not clear. I checked the ‘clear grid’ function was executing on each of them, but still some of them ended up blocked.

I could see nothing wrong with the code no matter how hard I looked, so the only way to solve it was to look at a lot of test cases and see if I could spot what the bad ones had in common. As I said in my tutorial episode on debugging, it’s often impossible to see the problem until you get a clue about where to look. So I spawned lots of ships, checked each airlock, and screenshotted each one. And it was only looking back at the screenshots that I spotted what all the bad ones had in common – or rather, what all the good ones did.

I thought it might be fun to just put up all the shots I looked at and see if you can spot it yourself. Not the actual explanation of the bug, of course, that’s tricky without seeing all my source code, but I was just looking for any commonality at all. And in case you think I’m Tom Sawyering you into solving it for me, I have no compunction about just asking for help when I really am stuck. This one was kind of fun to figure out, for a certain definition of fun.

Here are all the bad ones. The grid thing is showing what bits of the ship are solid, and these are ‘bad’ because the part I’m standing in is all red – I’m stuck. None of the debug text is relevant.

And here are all the good ones – the area I’m standing in is green, I’m free to move.

So there’s something all the bad ones have in common and something all the good ones have in common, and it’s evident in these shots. Comment if you spot it!

Update! People have got it! Both here and on Twitter, in fact I think most people who took a stab either got it or got something close enough. Kudos to Pompolic for the first correct solution I saw. I’ll detail what was going on below, but hide it until you click to reveal the solution, for anyone who still wants to try it for themselves.

This is both a slightly better looking build than the last trailer, and a longer vid – shows the whole disrupt/isolate/capture cycle.

I used to be press! Now I’m a developer. So I’m showing them my game, and trying to figure out if what I’m showing is exciting. Here’s what that’s like. I would like it known that I really am saying ‘Alec’ when I refer to Alec but it sounds a bit like Alex because of a mouth thing. A similar mouth thing to when I appear to say ‘intereted’ right after.

As always, follow it on Twitter or sign up to be told when it’s out, or ready for testing, here.

I also made a short montage of all the ways I fucked this video up in previous takes:

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

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

Many of you have been asking how the story of Heat Signature follows on from Gunpoint. We can now explain.

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

I have a maths problem in Heat Signature that I can’t quite get my head around, so if you’re into trigonometry, read on and see if you can help me! I think I know all the rules I need to solve this, but I can never quite reframe the problem into something I recognise.

In Game Maker, everything the player can see on the screen at one time is called ‘the view’. The whole game world is called ‘the room’. In my game, the view moves around the room and also rotates, to follow the action. In the diagram, the whole image is the room, and the rotated black rectangle is the view: what the player sees.

What I’m trying to do is find rx and ry: an object’s x and y co-ordinates relative to the screen, at its current position and rotation. I have every other piece of information:

• x and y, the co-ordinates of the object, relative to the upper left corner of the room.
• vx and vy, the co-ordinates of the top left corner of the view
• theta, the rotation of the view, measured in degrees from horizontal, going anti-clockwise.

So, how do I combine those things to find rx and ry?

My usual method is to bash my head against these problems for a day or two, drawing endless diagrams and running tests and simulations in code. But lately I’ve realised how quickly some problems can be solved by just checking in with someone who already knows or finds it easy, so I’m trying that! Any help much appreciated.

Update: Thanks for all the suggestions so far! It’s possible that my diagram implies some assumptions I didn’t intend. To be clear:

• y and vy are not the same, it’s just coincidence that they’re close here. No values mentioned are the same, related, or constrained by each other.
• theta can range from 0 to 360, meaning the whole view could be upside down relative to the room.
• vx and vy are the ‘top left’ of the view when it’s at theta 0. It rotates around that point as theta increases, meaning it could end up not being the top left. I am mistaken about this! See below.
• The object can be completely outside the view, we still want to know rx and ry even if they’re negative or larger than the view size.

To illustrate the full shittiness of the problem, here’s another diagram this also has to solve:

Update 2: The plot thickens! The reason nothing has worked for me so far is that I have misunderstood how the view rotates. vx and vy do stay the same as it rotates, BUT the rectangle itself rotates around its center! So for most angles, vx,vy is well outside the screen area! Bizarre! We still need rx,ry relative to what the player will see as the top left of the screen.

Of your many clever and much appreciated suggestions, the two I’ve had most success understanding and implementing are, roughly:

The Andrew/Andrey ‘cos-sin’ version

xDifference = x – view_xview[0]
yDifference = y – view_yview[0]
Angle = view_angle[0] * -1

GUIx = (xDifference * dcos(Angle)) – (yDifference * dsin(Angle))
GUIy = (xDifference * dsin(Angle)) + (yDifference * dcos(Angle))

The Puzey/Varanas ‘arctan’ version

xDifference = x – view_xview[0]
yDifference = y – view_yview[0]
Distance = point_distance(0,0,xDifference,yDifference)
Angle = darctan(yDifference/xDifference) – view_angle[0]

GUIx = Distance * dcos(Angle)
GUIy = Distance * dsin(Angle)

These both work at view_angle[0] = 0, but drift in a circular way when the view is rotated, because it’s not rotating around the point I thought it was. The point it’s rotating around must be something like:
view_xview[0] + (view_wview[0]/2)
view_yview[0] + (view_hview[0]/2)
But we still need co-ord relative to ‘the top left of the screen’, which is something I no longer even have a variable name for.

Now that I know this I might have a way of figuring it out, will update if I do so.

Update 3: Got it! For anyone who needs it, here’s a rotation-proof function to find an object’s position in screen co-ordinates, for us in the Game Maker Studio’s DrawGUI function so you can draw HUD elements over it and annotate it and stuff. Now accounts for zoom too!

Thanks so much to everyone who helped!

var ViewCenterX = view_xview[0] + (view_wview[0]/2);
var ViewCenterY = view_yview[0] + (view_hview[0]/2);
var Zoom = view_wport[0] / view_wview[0];

var MyDistanceFromCenter = point_distance(ViewCenterX,ViewCenterY,x,y) * Zoom;
var MyDirectionFromCenter = point_direction(ViewCenterX,ViewCenterY,x,y) + view_angle[0];

GUIx = (view_wport[0]/2) + lengthdir_x(MyDistanceFromCenter,MyDirectionFromCenter)
GUIy = (view_hport[0]/2) + lengthdir_y(MyDistanceFromCenter,MyDirectionFromCenter)

Update 4: One year later, I needed to do the reverse – find world co-ordinates from GUI co-ords. So here’s that, slightly more verbose to explain what’s happening:

var ScreenViewCenterX = view_wport / 2;
var ScreenViewCenterY = view_hport / 2;
var Zoom = view_wport[0] / view_wview[0];
var MyDistanceFromScreenViewCenter = point_distance(ScreenViewCenterX,ScreenViewCenterY,GUIx,GUIy);
var MyDirectionFromScreenViewCenter = point_direction(ScreenViewCenterX,ScreenViewCenterY,GUIx,GUIy);
var MyDistanceFromWorldViewCenter = MyDistanceFromScreenViewCenter / Zoom;
var MyDirectionFromWorldViewCenter = MyDirectionFromScreenViewCenter – view_angle;
var WorldViewCenterX = view_xview + (view_wview / 2);
var WorldViewCenterY = view_yview + (view_hview / 2);
x = WorldViewCenterX + lengthdir_x(MyDistanceFromWorldViewCenter,MyDirectionFromWorldViewCenter)
y = WorldViewCenterY + lengthdir_y(MyDistanceFromWorldViewCenter,MyDirectionFromWorldViewCenter)

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.