A Double Postmortem: Barry Basic and the Speed Daemon / Things that Happened in Houghtonbridge

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.

19 Likes

Thanks for writing this! I always enjoy others’ postmortems, and I also think there’s never a bad time for them. I think it’s quite appropriate to put the two together if they overlapped in your personal life. I’ve had that, too.

I also appreciate the trivia at the end of the postmortem about the trophies and Houghtonbridge, the second of which just sounded like a really good name to my American ear. They’d be cool to know on their own, and I definitely think they’re the sort of thing the author shouldn’t spoil until after the comp, as enough people will be curious! It’s weird, it’s not the meat of the postmortem, but it’s the sort of odd facts we were sort of itching to know.

Wish I could’ve done more testing for you. I had my own procrastination issues with my entry. But that would be in my own thread. FWIW, I definitely have bursts of creative activity combined with hitting a wall, and I find I’m at my best when I have a chunk of coding time, then a chunk of creative time, and back and forth. I also like to let certain things sit until I’m ready. If a submission date is months away, I sometimes deliberately leave small features for later if I’m on a roll, because even rudimentary testing and programming can break up creative stuff, but on the other hand they are a great way to get back in the groove if I had to put my work aside.

I’d be curious to know what other people have found with their own habits, etc.!

And I fully agree that sometimes the author needs time away from a big work such as Houghtonbridge. I think you should be more than confident enough you can tackle what you want/need once you’re ready and other things cool down a lot!

4 Likes

Glad you found it interesting! I’ve not done a postmortem before this one but it really helped put some things to bed before moving onto the next project.

That’s a really good idea about leaving some creative parts for later - the latter part of the process can be a slog sometimes.

2 Likes

Thanks for posting this, Dee. It’s always interesting to read about the background to a game and this was a good read.

One thing that I’ve noticed in your games is that the writing is really solid. By that, I mean spelling, grammar, capitalisation and punctuation.

The other thing that I’ve noticed, particularly in the more recent games, is that you always seem to cater for all the weird things that a player might try. Some of the other entrants in competitions should take note of this.

These two games were technically very proficient. Having published a few Adventuron games myself, I know how difficult it can be to work around the scope, disambiguation and multi-word input issues. What people may not realise is that Adventuron doesn’t have a built-in library like Adrift, Inform, TADS et al. You have to do everything yourself. I have taken the same approach as you and, in effect, built my own library. This works really well and it shows in these games.

The only thing that I didn’t like about Houghtonbridge was that it started off as a mystery, then sort of evolved into a fantasy from the field onwards, then became somewhat linear - like narrative fiction. Nevertheless, I still enjoyed it and rated it highly in the comp.

Games don’t have to be big to be enjoyable. Believe it or not, my favourite (or most memorable) Dee Cooke game is probably ‘The Cave of Hoarding’. I don’t know why. Maybe it’s the retro feel or the nice, straight forward puzzles.

I can’t wait to see what you come up with next.

3 Likes

Yes. By the time I tested these games, they were already rock solid and I had very few complaints. This level of attention to detail makes for a really rich, immersive experience, which is where parser games can really shine.

I really loved how weird it got. It was a total surprise, and I love that-- when a game completely defies my expectations with genre switches.

I do that, too. It cooks in my brain until it’s ready to be born, and then there’s no stopping that baby from coming out and I have to attend to it all the time for a chunk of my life. And yes, I do love to mix metaphors.

4 Likes

Thanks :slight_smile: 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!

Thanks so much both! Doing that work probably took me longer than writing the games themselves, but I was really pleased with the result and it’s something I can now transfer between games and keep improving.

I think the tone was the hardest thing to get right. It’s something I will definitely give more advance thought to if/when I make a really plot-heavy game again!

I have a soft spot for The Cave of Hoarding too - partly to do with nostalgia for the first Adventuron jam! And thanks, I’m looking forward to getting stuck into making another game :slight_smile:

Thanks so much! I think I could have maybe hinted more at the upcoming supernatural elements during the first part as it seems they came out of left field for most players, but I’m really glad you enjoyed it as a surprise :slight_smile:

Glad it’s not just me!

3 Likes

Definitely the same here, too. I’m trying to turn my “sprint → collapse” cycle into a “jog → walk” cycle. Though this is easier said than done, huh?

Not bad considering Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law”. I was taught to double my estimation then add half of the original estimate. So, 3 weeks is better than 5 weeks, I’d say!

Anticipating an audience is definitely the most tricky part of the authoring process. But I also think it’s the best part! It’s the part where I feel closest to my audience, like I’m speaking directly to them.

I tell myself the same thing, too. “Just one little itty bitty short game. I can do that, right? Right?” Yeah, sure! I don’t know why I always buy it, but I do. Haha!

(Honesty, CoL was the first time I’ve overcome this, and it’s my proudest moment of the competition.)


Anyways, it’s always great to read through another author’s approach, so thank you again, Dee. I love retrospectives like this!

1 Like

Using a timer has been the best habit I’ve formed, @aschultz. I programmed my own timers and use them as a “designer’s metronome” that keeps my momentum going through the “boring” parts of a process. I can still explore, but I don’t wander too far. And when I feel stuck on something — DING!! — I can skip it and come back later.

2 Likes

I have something like that, too… every evening at the same time, Windows Task Scheduler uses an AutoIt script to open up a copy of my latest project in the Windows IDE and compiles it. The trick is to remind myself “yes, I want to do something, even though it might not be much” or if I’m just goofing around, this snaps me back.

This would be something I’d love to discuss in more detail but I don’t want to take attention away from Dee’s postmortem.

But I do want to add, I’ve used this to get further through judging and rating IFComp and ParserComp games as well–simply shifting my focus to the next game e.g. with a weblink or running the glulx file or whatever.

2 Likes

I think time estimates get better with practice but I’m not quite there yet!

And yes, I never know how players will react but it’s always a fun experience when they do.

2 Likes

Thanks for this write-up!

Aha! A group of us (all with UK English) were playing over voice chat, and eventually we had to agree an arbitrary pronunciation for ‘Houghtonbridge’ (of the many possibilities that English offers), to stop tripping over it. But it sounds like there is a canonical pronunciation! Would you be willing to share it, to satisfy our curiosity?

(Also – and at the risk of derailing this thread to tech support, so perhaps this should be taken elsewhere – I could never get this game to run in my browser; whatever I tried, clicking “Run game” from the itch page, I just ended up on a black screen. Nothing obvious in the web console. Other Adventuron games like Off-Season at the Dream Factory did and do work fine for me. Firefox on Linux, with some slightly unusual browser configuration, but none of my usual workarounds helped. I didn’t see any complaints, and it worked for the others in my group so they were able to drive, so I didn’t say anything at the time. Dunno if it’s something to do with Itch hosting, somehow.)

2 Likes

Interesting. I never thought of that. In my head, I always pronounced it as “Hortonbridge”, but I can see that other pronunciations are possible. Don’t you just love the ambiguities of the English language?

Regarding the black screen, I didn’t have any problem, but it’s worth raising this in the Adventuron channel or on the Adventuron Discord server.

1 Like

I couldn’t decide between “uff” as in “huffing and puffing” or “aught” as in “nought” or “daughter”.

@dee_cooke Help us out, would you, or this will haunt me forever.

1 Like

Hmm, not had a report of a black screen before! I have heard about issues with certain browser configurations, but if you can play Dream Factory it sounds like it’s more likely an Itch issue. I’ll keep an eye out for similar reports.

I wondered if this would come up! It is indeed ‘aught’ as in ‘daughter’ :slightly_smiling_face:

4 Likes

I wondered too. I guess I saw it as “HOWton” because I have memories of an announcer saying “Ray Houghton … goal!” for, well, Ray Houghton’s wonder-goal against Italy in the '94 World Cup: Ray Houghton Goal–Republic of Ireland v Italy–World Cup 1994–USA–18th June Group E-Giants Stadium. - YouTube

2 Likes