I know it’s unusual (I think?) to combine a postmortem, but these two games have been incredibly intertwined for me this year. I started one, then made the other, then finished the first, so what I’ve learnt this year has really fed back and forth between the two games.
Three years of making text adventures/IF games, mostly in Adventuron, has been a constantly evolving learning process. I’ve come to understand that compared to most other IF systems, an Adventuron game is a bit of a blank slate in many ways – but that’s part of why I like Adventuron, because it’s so customisable.
I’m always trying to improve the way the parser reacts in my games; these two games were really focused on this and I’ll go into the details of that later.
(I did originally tag a lot of people in this post to thank them for various testing and other things, but apparently you’re only allowed a maximum of 10 tags! Usernames listed without tags as a result.)
Part 1: The Perils of Registering Your Spring Thing Intent in the Autumn
I put in my Spring Thing intent in the autumn (a mistake I won’t make again!) based on the game I thought I would make over the winter. I then started a software dev course in October and so, barring a couple of short games for PunyJam #2 and the Petite Mort category in EctoComp, had zero time for game-making while the course was ongoing. The course was really interesting but I missed writing games a lot!
As such, I emerged from studying at the beginning of March excited about doing some ‘fun coding’. Having learnt a bit of Python on the course, I enjoyed dabbling with a small and basic Python text adventure, but as documented in the Python thread it’s not really ideal for complex IF! Wanting to make a proper game, I looked at my Spring Thing intent again, planning to make the game I’d originally intended to enter…
Whoa. That plan from five months ago is way out of date! I’m now not planning to make that game until 2024 or somesuch! But you can’t edit a Spring Thing intent, and I really want to make a game, so let’s make a short experimental thing that still fits in with the description from my intent…
‘She was the last person you expected to disappear.’
Part 2: Plot is Hard and Also I’ve Forgotten How to Make Short Games
I don’t know if this is a common thing, but I game-make in intensive, obsessive bursts where my life basically is the game for several weeks/months straight (my husband loves this, as you can imagine). Having sketched out a story about a teenager’s hunt for her missing aunt, I jumped into this mode and did not emerge for three weeks. I had planned on getting it done in a fortnight but scope creep is a real weakness of mine and something I’m still working on. As such, Things that Happened in Houghtonbridge did not end up being a ‘short experimental thing’ as intended.
(Those two short games I mentioned making last autumn? One was made in PunyInform (I’m enjoying learning Inform 6 via this system but I’m still nowhere near as familiar with it as I am with Adventuron and therefore I’m not as ambitious with it) and the other had a four-hour time limit for game-making due to being in EctoComp’s Petite Mort category – so those are two solid ways I’ve found of keeping a game short and simple, but usually I’m at a loss!)
The first version of Houghtonbridge – a version that, as late as four days before the deadline, I was still planning to submit to Spring Thing – was very different to the eventual released version. It was timed (minute per turn) from Saturday morning to Sunday evening, with places like the hospital closing according to the clock rather than in response to game events, Olivia’s dad texting her to come home for dinner etc. at certain points (you could choose to ignore this if you wanted) and the ability for Olivia to pretend to be staying at Brianna’s overnight so that she could keep working on the mystery instead of going home to sleep. The aim of the game was to open Beverly’s desk and find the evidence linking Emily to her homebrew drug racket (and then get out of Beverly’s house) by the point on Sunday evening when the police arrived at the house; the player could then choose whether to destroy the evidence, hide it or give it back to Emily, leading to different endings and outcomes. Even in that early version, however, Beverly could not really be described as ‘the last person you expected to disappear’, as in the intent; during the writing process, she quickly became a rackety and unreliable character of whom nothing could be considered ‘unexpected’, at least in the view of the outside world.
I sent the game to testers about a week before the Spring Thing deadline; I had always found a week to be plenty of time for testing in the past, but Houghtonbridge was by far the most complex game I had yet made in terms of plot. Over the course of that weekend, as the testing feedback rolled in, it soon became apparent that not only were there some serious holes and flaws in the plot (some of which I had been aware of but had been burying my head in the sand to an extent) but also the timed mechanic did not seem to be working for players, as they felt they were sometimes missing things and sometimes kicking their heels waiting for things to happen. I realised that I would have to make some major structural changes to the game, and as such there was no way it would be ready in time for Spring Thing. I reluctantly withdrew and decided to target ParserComp instead. My thanks to JoeyAcrimonious, adventuron, Edo, Warrigal and CaptainEdgecase for testing this early version and helping me to identify what needed to be changed.
Part 3: Barry Basic and the Colourful Quest for Parser Nirvana
I had a good opportunity to take some time away (and thus get some needed distance) from Houghtonbridge for a month or so, as it was TALP Jam time. This was the seventh Adventuron-hosted jam; I’ve put entries into all seven and always look forward to them, especially now that they’re open to non-Adventuron games (resulting in a more interesting range) and focus on tutorial learning for new IF players (I’ve found recently that making games focused on tutorials helps me to think about tutorial structure in non-TALP games).
I decided to make Barry Basic and the Speed Daemon – this is the latest in a fairly lighthearted series of games I’ve been making about Barry, a game-programmer-slash-adventurer, at various stages of his life. I’ve visited him in the 1980s and 1960s before but this time I settled on the present day; it enabled me to present Barry, now in his 60s, as the wise and experienced member among a small group of adventurers, which fit well with the tutorial mechanic. (It also meant I could make reference to adventures I’ve not written yet… but would like to write one day!)
The three pathways through the game for the three characters meant that I could keep the tutorial path very straightforward, while adding a couple of slightly more head-scratching puzzles into the subsequent paths. You can get to the end of the game just by playing the first path, but the two extra paths provide additional gameplay, story and achievements, and I think pretty much everyone whom I’ve seen comment on the game has played all three – which is great, I’m really glad people enjoyed it enough to keep going!
The Speed Daemon himself is a fairly hammy and one-note villain; I might flesh him out a bit in future appearances (if they arise) but I don’t envisage doing a deep delve into his backstory or anything like that, partly because the series is meant to be a bit cartoonish and partly because he in turn was originally an adversary created by Barry for a videogame and therefore not really a rounded character. There are other characters I would really like to revisit, though, as I feel I have quite a lot of stories still to tell in this world.
Again, I planned to get the game made in a fortnight; again, it took an extra week. This was partly because of the work I was doing to ensure that the parser was coming out with sensible and helpful responses to unexpected commands. The Adventuron default (customisable, but usually left uncustomised) to unexpected commands is ‘You can’t do that.’ I am aware that players who are used to other systems sometimes find this vague and unhelpful, so in recent games I’ve been programming a lot of catchalls in order to give the player more of a hint that they’re barking up the wrong tree. The aim was to eliminate ‘You can’t do that’ from the game, and on the whole I succeeded. During testing, some strange responses were flagged up as a result – but I think I managed to sort out all of those, and it gave me a good template that I was later able to drop into Houghtonbridge and customise accordingly (and I’ll be able to do the same for future games).
The main thing that came out from testing, however, was frustration on the part of players that they couldn’t VERB ADJECTIVE. This frustration was largely borne out of the fact that there were multiple puzzles featuring multiple coloured buttons, coloured sweets, coloured wires… I generally feel that VERB ADJECTIVE shouldn’t work as it doesn’t really make sense in most cases. However, I’m aware that a lot of players do expect it to work (as it’s allowed by Inform and possibly other systems), and this game did feature a lot of objects requiring disambiguation, so in order to save players the work of typing PRESS PURPLE BUTTON, EAT YELLOW SWEET, PULL RED WIRE etc., I spent a few late nights coding lots of VERB ADJECTIVE commands into the game. I also decided I wouldn’t ever design a game again that featured multiple identically-nouned objects that could exist in the same location. (Houghtonbridge has a few, but they were designed before I ran into this issue with Barry Basic!)
Another thing expected by Inform-conditioned players and thus flagged up by my testers was implicit get – which, again, I don’t prefer myself, but I did want to minimise player frustration, so I coded this in as well. In Adventuron the easiest way to do this is adding in an is_beside check (and accompanying response/get) before the is_carried check:
: match "light torch; burn torch; ignite torch" {
: if (is_beside "lighter") {
: print "You pick the lighter up first.";
: get "lighter" quiet = "true" ;
}
: if (is_carried "lighter") {
: if (!torch_lit) {
: if (easy_words_mode) {
: print "You light the torch on the wall with the lighter. It lights up the tunnel to the east.";
}
: else {
: print "You light the torch on the wall with the lighter. It illuminates the tunnel beyond.";
}
: success ;
: set_true "torch_lit" ;
: done ;
}
: else {
: print "The torch is already lit.";
: done ;
}
}
: else {
: print "You don't have anything to light the torch with.";
: done ;
}
}
…which was a lot faster to implement than coding all the VERB ADJECTIVE options!
There was a great little group swapping testing of TALP games while the jam was on – many thanks to nilsf, Warrigal, rayleandro, aschultz and AmandaB for testing this game, as well as my ever-reliable husband Geth (who almost always does the first playtest and finds most of my major gamebreaking bugs before I inflict the game on other people!). Thanks also to adventuron for great hosting of the TALP Jam as ever.
Part 4: Return to Houghtonbridge
As briefly mentioned in the last part, the main thing that I was able to take forward from Barry to Houghtonbridge was my template for unexpected response catchalls. I was also able to improve this as the process of refining the game went on, and will continue to do so as I move it into future games.
The process of making all the changes I wanted to make to Houghtonbridge after the first round of testing took about three weeks – as long as the first version of the game itself. I got rid of the clock, changed all the events so that they were triggered by game actions rather than time (which made the game a lot more linear), got rid of a lot of the options for free exploration (as they no longer made sense) and made a few puzzles a bit more logical. I also revamped and simplified a lot of the plot elements to improve that aspect, as suggested by some of my testers. Olivia needed to have more motivation for going out and exploring rather than studying in her room, so I moved some of the revelations and discoveries to earlier in the game, meaning that she had more sensible reasons to do what she was doing. I also put a bit more thought into Beverly’s actions around covering for Emily while also trying to fight the Purple King, as a lot of what she was doing didn’t really make sense in the first version.
I then sent this version for a first playtest by my husband – and that playthrough flagged up so many things I wanted to improve further that it was another week and a half before it finally went out to my other testers. Over the course of June I had a lot of feedback on the plot, puzzles, achievements, dialogue system, presentation – all incredibly helpful but it meant there was still a lot of work to do! I ended up scrapping quite a lot of extra fluff that was only in the game for the sake of achievements, simplifying things that some testers found difficult (such as the field, which originally used my favourite maze style of looping round on itself for extra confusion), adding a few extra scenes with Emily (as a few testers felt that subplot faded out too much on the second day) and cutting down Beverly’s big infodump at the end (probably the most plaguing feature of the game for me and something that I’m still not entirely happy with post-release).
Across the two versions I had a total of 14 testers. This provided an incredible range of feedback from lots of different types of players, which I felt was necessary for what had turned into a complex game project. However, it also had a slight ‘too many cooks’ effect – different testers found different puzzles, mechanics and other aspects to be too difficult or frustrating, and by simplifying all of them, I feel I ended up making the gameplay slightly too easy and linear. I still think having a high number of testers is beneficial, but the resulting feedback is something I need to learn to balance better in future games. Many thanks to Jade, Grueslayer, dobster, Warrigal, mathbrush, ChristopherMerriner, DeusIrae, aschultz and AmandaB for their valued testing of the second version of the game, to fos1 and ChristopherMerriner for all their work organising ParserComp and to Adam_S for getting it going.
Despite the extra three months (give or take the TALP Jam) I gave myself by moving the comp target from Spring Thing to ParserComp, I did not manage to avoid the frantic final week, and as ever it was a real rush to get everything finished on time – and there were certainly a few things on the list that were moved into a new ‘post-comp release’ list!
Part 5: What’s Next for Barry, Olivia and Me
Since the ParserComp deadline, that ‘post-comp release’ list has grown quite a bit. There have been many wonderful reviewers on this forum and elsewhere providing feedback on all the ParserComp games, and I’ve been able to collect a ton of useful tips about things to improve.
However, the post-comp release of Houghtonbridge won’t be for some time – at the moment, it’s looking like a winter project. I’ve spent a lot of time in that strange little town this year and I need a bit more distance before I revisit it.
I would like to do another game with Olivia in the future – her university adventures are on my (very long) list of future games to make. Barry, as mentioned, also has a lot more stories to tell (some of them already in various half-finished states) – hopefully he’ll be back next year!
I took July off from game-making. Between my two short games last autumn, my software dev course over the winter and the two longer games covered here, I’d been solidly coding for nine months and I was a bit burnt out. I’m ready to try making a short game again now I’ve had a break… and hopefully it won’t spiral out of control this time!
Fun fact about Barry Basic and the Speed Daemon: the trophies in Barry’s office at the end of his path are an homage to all the weird and wonderful prizes you can win in Adventuron-hosted game jams.
Fun fact about Things that Happened in Houghtonbridge: the name ‘Houghtonbridge’ is taken from ‘Houghton’ and ‘Bridge’, two surnames from my recent family history.
I’m a proofreader by profession so I’m usually fairly good at spotting my own typos. The occasional exception tends to be something like missing quotation marks, which are sometimes hard to spot in a print statement!