This is a postmortem for Terminator Chaser, my ParserComp 2015 entry. As you might expect, it contains severe spoilers for the game.

This postmortem is based on my own impressions of replaying the game after its release, but it’s also based on watching the reaction to the game itself. I want to single out reviews from Sam Kabo Ashwell and Emily Short, as well as the players who submitted feedback through ParserComp’s judging form.

You can play or download the post-comp release of Terminator Chaser, with various improvements, here.

The Goals

Terminator Chaser was scoped very specifically to be something that I could complete within the window I gave myself, which contained most of January as well as the ParserComp “polish” window in February. I have a lot of unfinished Inform 7 projects under my belt, so I knew that was the system I would be using to implement it. I also had a pretty reasonable idea of how hard things are to implement; I knew, for example, that if I wanted a fully implemented NPC in my game it would take up a lot of complexity space. As such, from the very beginning of my initial brainstorm, I had a set of constraints: Either a small space (10 rooms or so) with medium implementation complexity; or a single high-complexity implementation thing (NPC, puzzle, what have you) in a smaller space with less objects.

Obviously, I chose the former. This was less a conscious choice about the type of work I wanted to implement and more a natural consequence of the story I ended up deciding to tell. I took the competition’s theme (sunrise) as a starting point and brainstormed by myself; what I came up with was a very basic setup:

The player character is on the surface of Mercury, and must escape daylight.

Everything else stemmed from that starting point. As a result, I knew the player character would be alone in the game’s space, saving me from implementing full-featured NPCs. High-detail NPCs are a notorious Hard Problem in parser IF, to the point that the primary advice Carolyn VanEseltine had to give about implementing them was to avoid doing so. Terminator Chaser, then, had a basic design goal: Build a polished, fully-implemented but parsimonious parser game, in the traditional mode of exploration and puzzle- solving.

Influences

People familiar with postcyberpunk RPG Eclipse Phase will be familiar with the idea of Mercury miners moving around the planet to avoid sunlight. The idea is compelling because it suggests a hard life in a harsh environment. It also injects a type of realism that rarely comes up in science fiction: Instead of having some kind of “green rock” to protect them from the effects of solar radiation and Mercury’s extreme daytime temperatures, the terminator chasers have adapted their life and work patterns to their environment. Their life, like our own, takes place at the meeting point between what they can control with technology, and what they can’t.

Alien (by which I really do mean the original film, and not so much the rest of the franchise) is a huge influence here as well. Much like the film, I’m operating within a conception of space travel that’s about working people. Science fiction is populated with universes in which space travel is simultaneously commonplace and seemingly the exclusively province of scientists and soldiers. Much like the space truckers of Alien, the space miners in Terminator Chaser might be a little coarse, but I wanted them to be fundamentally competent, empathetic, and not at all stupid. In the end, characterisation ended up being fairly spare, but I hope I got that across.

The last piece of the ripping off other people’s work puzzle is less obvious: Gillo Pontecorvo’s The Battle of Algiers, a classic film about the struggle for Algerian independence. I don’t want to pretend I can approach Pontecorvo’s deftness in engendering sympathy towards the unsympathetic; I did, however, want to play around with this idea of trying to get the player to do something that they might not normally find justifiable, or at least of giving them the option. Hence, the various endings which allow you to sabotage the hab. From this idea came that story subtitle, “An Interactive Sabotage.” It refers both to Rayland’s act of betrayal1 and to the potential “saboteur” endings.

Process

The map was the first thing sketched out for the game. The basic idea of a roughly triangular hab, with the central hub surrounded by airlocks and other rooms, was there from the start. In fact, the map layout changed very little over the course of development. In most ways, rather than building a map layout to fit the story and puzzles, I chose to build a map layout that represented a “realistic” idea of what that space would look like. Living space is separate from work space; the manager’s work space and living space is separate from the workers’; control rooms are spatially near what they control even though they have neither windows nor doors connecting them to those things.

I knew the basic puzzle of the game would be built around the problem of leaving, which led me to the thought of fixing a sabotaged rover. The idea of a miner being left behind to shut down everything after the team had left, and of that being used as an opportunity to whack them, came more or less fully- formed. The plot outline came in very early in the design: Ainsley was a fairly active union rep. Wysham-Yamano tries to have them killed, because they want compliance from their workforce in their scheme to settle them permanently on Mercury and drive labour costs way down. Rayland does this by breaking the communications system and sabotaging the transport rover, so Ainsley is stuck in the hab, where they’re presumed to die.

The airlock puzzle was the first puzzle in the game, and more or less everything else was built around it. I really wanted to incorporate the setting into the puzzle, which is why it revolves around the issue of pressure vessels and airlocks. I’m still not sure how contrived the idea that your space suit is too clumsy to use a screwdriver is.

Originally, the player was able to leave through either airlock from the start of the game. It was possible, in fact, to totally bypass the main story, never visiting the communications array at all. One tester managed to complete the game after missing the story wholly: They dutifully performed all of the shutdown tasks (Which in this stage of the game weren’t even necessary to progress), fixed the rover, and drove off without ever encountering the actual plot.

Eventually, I realised I had to give some shape to the player’s exploration. The solution was to start the western airlock depressurised, so the player couldn’t walk out that way at first. Instead I added a map connection between Mass Driver Loading Dock and Communications Array, which wasn’t there originally. Note how I opted not to change the fiction of the game world’s geography at all. To justify that the player is able to clamber out of the crater, I added in the first test load puzzle. This had the added bonus of making the most important puzzle object in the game relevant to more than one puzzle. The breach was added late in development, as a way of breaking up the repetitive sequence of repeating the same puzzle solution once for each rover.

Perhaps the most significant shift in the game during the testing period was in how the story was told. Originally, east of Office Space was a server room; it contained a mail server that the player had to turn on, and all of the story would be told by emails.

This entire system proved to be a complete nightmare. To dole out the story in manageable chunks, emails would arrive gradually when certain actions were completed; unfortunately, there were not enough mandatory story beats in the game for this to fully work, so a lot of the triggers for new emails were obscure. To get the player to read the emails, I made them necessary to progress. First, by having access to the work suit gated by a combination lock, the combination to which was placed in an email. And eventually, by having a similar gate on getting the sealant to fix the breach. This proved highly obscure. One of the testers actually came under the impression that the emails were arriving on a timer, such that the solution to the puzzle was to wait until it arrived. Furthermore, it was possible for the player to trigger several emails before even reaching the mail server, and of course the entire thing rested on a very flimsy contrivance.

In the end, I opted to cut that whole system in favour of a much more streamlined Bronze-like triggering of memories when certain rooms are visited. At that stage, the game already had think about as a Robyn & Orchid-like device to dole out backstory, so it was a natural fit. This proved a much better solution, but it involved cutting a mass of content; there was a lot of backstory that is simply gone from the final version of the game.

The Good

I was really happy, ultimately, with how the prose in the game turned out. I was very much trying trying for spare, assertive writing which should be reminiscent of the better end of 20th century science fiction writing. I think I managed to get there, without falling into the trap of asserting too much literary objectivity. I was especially happy with the handling of the one death ending in the game, which can happen if the player chooses to deliberately depressurise an airlock without wearing a space suit:

As your ears pop, you realise you’ve forgotten something terribly important.

I didn’t want to write some gruesome description of what exactly death by explosive decompression entails; it wouldn’t fit the tone. And yet I thought it would be better to let the player do it in the first place, since it was well enough amenable to UNDO.

I also think, overall, the quality of implementation was high. Not a lot in the game was implemented using special cases; the airlocks, while not exactly massively entertaining, will work as you might expect no matter where the test load has been placed. Air pressure in rooms was handled programmatically so that it was possible to play around with it – I consistently opted to make it so actions that might lock the player out were reversible, instead of preventing them from happening in the first place. A lot of testing and special case handling had to be put into the system to ensure the player couldn’t get stuck by messing around with the airlocks.

I think Terminator Chaser strikes a reasonable balance between not overwhelming the player with information and still presenting a reasonably deep environment.

The Bad

Probably the worst thing that could have happened did, which is that Terminator Chaser shipped with a game-breaking bug that shut off one of the game’s endings. I only found out about it several days later when Sam Kabo Ashwell reviewed the game. Yeah. I’m not as clever as I think. Here’s the relevant bit of code:

Before touching a widget button:
  if final choices is happening, rule fails;
  if investigating the array has happened:
    say "You have more pressing issues to deal with at the moment, like
    making sure you're able to leave. Maybe later.";
  otherwise:
    say "You have no reason to fiddle with the mass driver controls.";
    rule fails.

Can you spot the bug? rule fails should be continue the action. This bug was introduced very, very late in development; I think it may very well have been the last change I made. Originally, the mass driver console was handled with a set of buttons that would simply not be in place at the beginning of the game; the start of the final scene would move them into place. For continuity reasons, I chose to change that; instead, the buttons would be unmentioned and impossible to interact with if the player got to them too early on.

Then I implemented the above rule to do this… and only tested the two special cases where interaction with the buttons was blocked. I never saw the bug because I assumed I knew what my code did. This proved to be a horrible mistake.

Shipping a game with a game-breaking bug like this is embarrassing, and I was definitely saddened when I found out, but the nice thing about bugs is that I don’t feel dishonest about fixing them in a post-competition release. While I may have to live with the prose in Terminator Chaser forever,2 I don’t have to live with any of the bugs, so that’s a small comfort.

The Ugly

Storytelling

I’m not sure I sold the motivation behind Ainsley’s attempted murder at all. On the one hand, I felt it shouldn’t be too heavily motivated; I didn’t want Ainsley to be this heroic thorn in the company’s side. I wanted to suggest that this wasn’t a highly motivated murder; rather it was a simple cost- benefit analysis. Ainsley had an estimated adjusted cost of x in labour costs and liabilities, over the long term, given their contribution to stopping or delaying the settlement plan and their general union-rep activities. Causing an “accident” in a small, less than important hab would cost y, and x > y by some amount such that the expected value of having Ainsley whacked was positive. Regardless of my intentions, it appears that the storytelling ended up being too spare, such that events in the plot felt unmotivated.

This was partly a result of the development cycle – huge parts of the original story were thrown out halfway through the process. All of the storytelling content (the dialogue vignettes) present in the game on release was put together within two weeks before release. So I very consciously chose to write a relatively small quantity of that content, so I could ensure the writing was tight, and remain focused on implementation issues. In retrospect, it seems like adding 2-3 other vignettes might have made a big difference.

A big part of this problem however, is just that the use of THINK ABOUT was non-obvious to players. It seems like the game suggested you could only think about the specific vignettes that are prompted, which isn’t true – you can think about over a dozen topics. Another small fix, then, is adding a prompt to suggest that to the player.

Puzzle Design

One big problem with the airlock puzzle was that it was repetitive. It involved performing the same sequence of actions twice. The breach puzzle was created exactly to break up this sequence, and make the player stop and rethink what was going on.

In retrospect, the right way to deal with that repetitiveness was to abbreviate the western half of the puzzle: The transport rover’s service compartment should have started the game open and visibly empty. This would have strengthened the reveal that the rover didn’t work and that Ainsley was set up; it would have also lessened the amount of repetition involved in the puzzle. It would have resolved another problem pointed out by Emily Short: The reason to open the mining rover and cannibalise its reactor is underclued, and it creates a feel-bad moment after opening the transport rover to find its service compartment empty. This change seems small enough to be a valid change in a post-comp release, and enough of a no-brainer that version 2 of the game has it.

Another unintuitive thing to note is that pushing things from place to place appears obscure enough that it seems underclued, even though both examining and picking up the test load suggest that it’s an option. Another small puzzle design change that makes sense is to make the player push the test load around earlier, by having it start in Smelter Yard instead. That way, the test load’s mobile nature is clear to the player before its role in dealing with the airlock puzzle crops up.

Lessons Learned

Unit testing is your friend

At the very least, I should have set up a series of blessed Skein threads which ran through all of the game’s content, to make sure I wasn’t breaking anything. Instead, I had a “throughline” thread that simply finished the game as quickly as possible, leftover from the original walkthrough requirement.

This led to a game-breaking bug ending up in the release version even though everything was working fine up until the last minute. Don’t do what I did.

Keep finding new eyeballs

In retrospect, a lot of the things that should have been spotted later in testing Terminator Chaser were very obvious to a player new to the game, but much less so to a player who had become used to it after playing through it multiple times. In the last week or two of testing, I really should have found at least one more tester, ideally several, to look at the game in its release candidate state and spot bugs. The lack of direction about how to fix the transport rover, for instance, was obscured by how testers already know what was wrong with it and how to fix it, and naturally gravitated to the more straightforward solution of opening up the mining rover first. Effectively, testers become less useful as the process goes on, as they become more inured to the faults of the software.

In Conclusion

Test your work early, well, and thoroughly. Scope things correctly. Don’t be afraid to throw out work that isn’t pulling its weight. You know: The usual. I have more work coming up (Including an Undum project I’m hoping to get finished in time for Spring Thing), and I look forward to seeing the reception to that.

  1. It’s arguable whether it constitutes a betrayal, of course. Part of the intent is exactly that Rayland’s real loyalty is not to the people he works with but to the faceless institution he represents. ↩

  2. Naming the villain “Rayland Wilt” is an Ayn Rand-like move that will haunt me to the end of my days. ↩