Building Moquette - Simulating the London Underground and Doing Pretty Things With Text

26 November 2013

Following on from the previous blog post (Moquette Post-Mortem and Review Roundup), here’s a look at how some of it was implemented.

Moquette was entered into the IFComp not under the Quest category, but as a web-based game only. Why? Because I used my latest development version - Quest 5.5, which is currently available only as an unsupported pre-beta “nightly” build. A downloadable .quest file was submitted to the IFComp for archive purposes, and will be made available from the Moquette page on when a beta version of Quest 5.5 is ready - which should be in the next month or two.

Some reviewers supposed that the text effects in Moquette might be a preview of new features in v5.5, but actually they’re not - you can do them in Quest 5.4 using the same JavaScript, which I’ll go into later in this blog post.

The changes in v5.5 as far as they apply to Moquette are cosmetic - I needed the ability to completely hide the location bar and game border, and to set a custom screen width. I also needed the ability to disable a command link after it’s clicked, and I implemented some changes to how scrolling works so there is a nice smooth transition when new game text is added.

Simulating the Tube

Moquette is full of contradictions. It’s a game, but it’s not a game. It has many choices, yet no choices. And on a technical level, it has many locations (a full tube map) and yet it really only has two locations - the train and the platform.

Everything else is just labelling of scenery. Get off one train, change to another line, get on a different train - as far is Quest is concerned, you’re just right back where you started.

The train has attributes to represent the line it’s travelling on and the station it’s at (or, if it’s in a tunnel, the station it was most recently at). It also counts turns - there is an overall turn counter, used to trigger plot events, and there is a rolling counter - every three turns, it triggers the next station on the line.

The platform has attributes to represent the lines that stop there, the direction trains go in for each line, and its location (station). At many stations, there is one platform in each direction for each line - but that’s not true for e.g. the Circle and District lines which share platforms.

There are objects for each tube line, and objects for each tube station. Tube station objects may contain hand-crafted data for platforms (if any platforms are for multiple lines), but otherwise the platform data is generated simply using data about which lines stop at that station. The format is simple - one attribute for each line which stops at that station. For example, Bank station is stored like this:

Bank XML

I started in the top-left of the tube map, at Paddington, giving the station an index of 100 for each line that stops there. Then I went along each line counting up or down. So, Bank ends up at index 110 on the Central line, 105 on the Bank branch of the Northern line, and 101 on the Waterloo & City line.

(I should really have added some code for the special case of Bank being linked to Monument, but I didn’t get round to it - few people noticed. Almost as if that was completely irrelevant to the plot…)

So, the code for moving around the tube network is pretty straightforward. But it wouldn’t be a journey on the London Underground with people. Lots and lots of people. Too many people.

Well, there are only 36 passengers in total in Moquette. Even if they were all on one tube carriage, you would still just about find a seat.

They are randomly assigned to each train when you get on. If you interact with them, that is recorded so that they won’t appear again. Every time the train enters a station, some of the passengers might get off and some new ones may get on - if you didn’t interact with them the first time, they may reappear later. This is why they tend to have fairly generic names such as “a man” or “a middle-aged woman”. I wanted you to get the impression that there were many more passengers than you were given the chance to properly look at.

In addition to the train and platform, there are locations for each of the plot events - the introductory part of the game is implemented as a sequence of rooms, as are the “visions” (the two smoking visions and the clay), the interaction with Heather and the interaction with Private Rod.

Text Effects

Quest has supported embedding JavaScript for a while now, and I wanted to show how this could be used for some effects to add a little bit of polish but without being too overblown.

A JavaScript effect is, in fact, the very first thing you see in the game. Quest’s function to initialise the user interface calls the following ASL:

JS.introScreen (GetFileURL("intro.jpg"))

This calls this JavaScript function:

function introScreen(url) {
     $("<div/>", {
         id: "introScreen"
         position: "fixed",
         top: 0,
         left: 0,
         width: "100%",
         height: "100%",
         overflow: "hidden",
         "text-align": "center",
         display: "none",
     .html("<img id=\"introScreenImg\" style=\"max-width:100%;max-height:100%;\" src=\"" + url + "\"/>");
     $("#introScreenImg").load(function() {
         setTimeout(function() {
         }, 7500);

function finishIntroScreen() {
     $("#introScreen").fadeOut(7000, function() {

The introScreen function hides Quest’s game output (which is entirely in the gameBorder div), then adds a new hidden div called introScreen containing the intro image. Once this has loaded, the function inside the call to jQuery’s .load() method is run - this ensures the image has always fully loaded before we show it. This fades the introScreen div into view over 4 seconds, and 7.5 seconds later calls finishIntroScreen to fade it out again.

finishIntroScreen first re-shows the gameBorder div containing the Quest output (which by now will contain the introductory game text), and then it fades out introScreen - to reveal the game text underneath.

Moquette Intro

The next effects occur in the first few turns - after Zoran gets on the first train, the text is nicely scrolled up and out of the screen, leaving it blank. The next effect occurs after the player makes the choice for Zoran to do something different than take his usual train today (or if Zoran makes that choice himself) - it’s the same effect again really, but this time the screen text is whisked off to the left.

Both of these make use of jQuery UI effects. These can be applied to any element, and the “drop” effect is the one used here. Quest calls:

JS.act0Clear ()

which simply calls this JavaScript:

function act0Clear() {
     $("#divOutput").effect("drop", {direction: "up"}, 1000);
     setTimeout(function() {
         EndOutputSection ("intro")
         HideOutputSection ("intro")
         HideOutputSection ("title")
         ASLEvent("FinishAct0Clear", "");
     }, 1500);

This calls the “drop” effect on divOutput, which contains the game output text (we could have used its parent, gameBorder, again I suppose as we’re not displaying an actual border around it). After this has run, the screen is empty, which means we can empty divOutput by hiding all the output sections on it (looking at this now with fresh eyes, that might be some old code as we clear the screen in a moment anyway).

We then call the FinishAct0Clear ASL function, which looks like this:

JS.reshowOutput ()
JS.StartOutputSection ("act01")
MoveObject (player, Act 0 Balham to Clapham South)

The reshowOutput JavaScript function is simply:


which gets us our Quest output back so we can start writing to it again. We start a new output section and move the player to the next location.

This is a pattern I use in most of the text effects - the ASL code triggers some JavaScript, the JavaScript does something pretty, then the JavaScript can call another ASL function when it’s done to continue the game.

The next effect is meeting Heather, which looks like this:

Meeting Heather

The JavaScript for this is:

var _heatherTextCount = 0;

function heatherText() {
    $("<div/>", {
        id: "heatherText"
        position: "fixed",
        top: 0,
        left: 0,
        width: "100%",
        height: "100%",
        overflow: "hidden"

function doHeatherText() {
    if (_heatherTextCount < 150) {
        setTimeout(function() {
        }, 20);
    else {
        $("#heatherText").fadeOut(2000, function() {
        setTimeout(function() {
            ASLEvent("JSFinish_HeatherText", "");
        }, 500);
    var minLeft = -100;
    var minTop = -100;
    var maxLeft = $(window).width();
    var maxTop = $(window).height();
    for (var i = 0; i < 3; i++) {
        $("<div/>", {
            text: "Heather"
            position: "absolute",
            left: getRandomInt(minLeft, maxLeft),
            top: getRandomInt(minTop, maxTop),
            "font-size": getRandomInt(8, 100) + "px",
            "font-family": "Georgia, serif",
            color: getRandomGrey(),
            opacity: Math.random(),

function getRandomInt(min, max) {
    return Math.floor(Math.random() * (max - min + 1)) + min;

function getRandomGrey() {
    var hex = Math.floor(Math.random() * 256).toString(16);
    return "#" + hex + hex + hex;

This places a new div over the game output, then calls a function at regular intervals to write the word “Heather” at a random location, size, greyness and opacity. After doing that a certain number of times, it triggers the ASL function JSFinish_HeatherText, which moves the player to the next location to start the conversation. Then it fades out the “Heather” div and removes it.

After meeting Heather, the “speckly” blackout works similarly - there are really two effects happening at once here. The blackout itself is simply a full-screen black div that fades in, fades out, then triggers the next part of the game. The speckles effect runs at the same time, and is similar to the previous “Heather” effect except with random letters - and they increase in size as the animation runs.

The final two animations are designed to evoke the feeling of sitting on a tube train while it enters and leaves a station. On the Underground, station names often appear on platforms above people’s heads, spaced quite close together. When you’re sat on a train looking out of the window as it pulls into a station, this gives something similar to the classic HTML “marquee” effect, but with the text scrolling past too rapidly to read at first, then slowing down and eventually coming to a stop.

For our final meeting with Heather, before she leads us to Private Rod, the text “HEATHER” appears in this way, using this JavaScript:

function heatherTube() {
     setTimeout(function () {
         $("body").css("overflow-x", "hidden");
         $("<div/>", {
             id: "heathertube",
             text: "HEATHER"
             position: "relative",
             left: "1200px",
             top: "0px",
             "font-size": "36pt",
             "font-family": "Georgia, serif"
     }, 2000);

 function animateHeatherTube(duration) {
     if (duration >= 2000) {
             left: "0px"
         }, duration, "swing", function () {
             $("body").css("overflow-x", "inherit");
             $("#heathertube").fadeOut(3000, function() {
                 ASLEvent("JSFinish_HeatherTube", "");
     else {
             left: "-1200px"
         }, duration, "linear", function () {
             $("#heathertube").css("left", "1200px");
             duration = duration * 1.5;

This temporarily sets overflow-x to “hidden”, which means we can have HTML elements off to either side of the screen without showing a horizontal scrollbar. Now all we need to do is animate a div containing the text “HEATHER” from off-screen on the right, to off-screen on the left. We do this with a duration that starts at 200ms and exponentially increases, to give the feeling of deceleration.

The final animation does the same thing, but with the whole of divOutput - so the entire game text. We do it the other way around, starting from a long duration and decreasing it each time (by dividing it by 1.3). Once duration reaches a value less than 500ms, we keep it constant and slowly fade out divOutput.

Hopefully I’ve shown you that these effects are reasonably simple to achieve, if you’re happy playing around with JavaScript and jQuery. Contrary to what some reviewers thought, these are not pointers to new Quest features at all - it just uses the same JavaScript integration features that have been there for a couple of years now, although not many people have exploited the full potential of these yet, which is why I wanted to play around with them in Moquette.

I’m not sure it would make too much sense for these kinds of effects to be more “built-in” to Quest - they would quickly become annoying through overuse. But if you need any advice on how to achieve a particular effect, post a message on the forums and I’ll be happy to advise - I can also do this kind of thing for you as part of the customisation service.

15 years of Quest, part 2: 1999-2000

26 November 2013

This is part 2 of a look back at 15 years of Quest - part 1 is here.

Immediately after releasing Quest 1.0, in November 1998, I got started working on Quest 2.0 - the first alpha version was released only a month later, in December 1998. This version incorporated the early feedback I’d received from v1.0 - making room descriptions more customisable, adding functions, numeric variables and “for” loops, improving the in-game debugging information, and fixing various bugs.

It seems surprising to me now that I didn’t ever do a bug-fix release of v1.0 - I guess that so few people were actively using it, and there were so many rough edges anyway, it must have made more sense just to plough on and pour everything into v2.0. And this was before I’d ever heard of source control anyway - in fact, I doubt I’d have even had any kind of backup copy of the Quest code at the time. (It was a time when I was constantly running out of hard disk space, when floppy disks were too small, before I had a CD writer, and before any significant amount of online storage space was easily available).

Over the following months I added more features - more text formatting options, allowing objects to moved and hidden, and libraries to allow Quest functions to be re-used between games.

It was all a nice break from working on my A-levels and filling in my UCAS form.

Quest 2.0 was released in August 1999, and for the first time included a beta version of a new visual Quest game editor called “QDK” - meaning finally you no longer had to code games using a text editor. (I would have called the editor “QED” but there was already a Quake editor of that name).

QDK 1.0

Editing a room in QDK 1.0

Editing an object in QDK 1.0

The script editor was very basic:

Editing a script in QDK 1.0

The main player interface for Quest 2.0 still looked pretty much exactly the same as v1.0 - which is to say, hideous. This was finally rectified in November 1999 with the release of Quest 2.1, which has a layout which is awfully similar even to the current version of Quest:

Quest 2.1

Quest 2.0 is the first version for which at least one actual game was made - and it’s still on, and it still works today, whether you download it or use the web-based player - The Adventures of Koww the Magician.

There are a total of 28 games on which were written for Quest 2.x - see if you can find them… (the column to the right of the game listing will tell you the version of Quest used to build the game).

The “libraries” feature got some early use, with Alan Bampton creating a “Standard” library to add some features, including containers - which Quest was still years away from supporting natively. This library was included with Quest itself as of v2.11. (10 years later, when redesigning Quest for v5.0, libraries became the way to add all functionality to Quest - without its Core library, Quest 5 does very little at all).

By early 2000 my thoughts were turning to Quest 3.0, which would be a huge update - I was getting lots of suggestions from users, and there were various aspects of Quest I wanted to tidy up - things which didn’t make sense to me at all any more, such as: why was “an object in a room” a separate concept to “an item you can carry”? It was time for the first of many overhauls of Quest. In the mean-time I carried on releasing bug-fixed versions of v2.1 up until Quest 2.19, which was released in January 2001.

Next time I’ll carry on with a look back at version 3.0 and beyond. If you want to peruse some archive material, the forums from 1998-2000 are still online.

Moquette in the IFComp - Post-Mortem and Review Roundup

19 November 2013

My first work of interactive fiction “Moquette” came 15th out of 35 entries in this year’s IFComp. Now that the competition is over, the vow of silence has been lifted (authors are not allowed to talk about their games publicly during the judging period), which means I can now write some blog posts talking about the ideas behind the game and how it was built.

15th place is a bit lower than I was hoping for, of course, but given the reviews it was roughly what I was expecting. There were various elements of the game that people were impressed with - but very few people really loved it.

The IFComp results page has a good breakdown of the voting statistics, including the standard deviation, which is a measure of how wide the range of votes for each game was. Moquette has the 6th highest standard deviation, so was one of the more divisive games in this year’s competition.

It received 62 votes in total, on a scale of 1 to 10:

  • 4 votes for 1
  • 2 votes for 2
  • 7 votes for 3
  • 8 votes for 4
  • 11 votes for 5
  • 11 votes for 6
  • 8 votes for 7
  • 6 votes for 8
  • 4 votes for 9
  • 1 vote for 10

That’s quite a range, with votes across the whole spectrum but mostly falling within the region of “not terrible, but not great”.

I deliberately set out to do something different with Moquette, so perhaps a wide range of reactions is not surprising. From the reviews, it seems people were mostly impressed by the text effects and the simulation of the London Underground. The writing itself got more mixed reviews - some people liked the style, others thought the plot was too slow or didn’t make sense (or didn’t really exist), and a lot of people didn’t warm to the main character.

I suppose this is simply a reflection of my own limitations. The text effects and tube simulation were the easy parts. I’ll go into those in detail in another blog post, but the tube simulation was the first bit I had working and it wasn’t difficult for me to implement. I saved the text effects until last, and there’s not an awful lot to them - a little jQuery goes a long way.

The plot was what gave me trouble. I was tearing my hair out for ages trying to work out just what should happen in the game, and how it should end. I just can’t fathom what the secret ingredient is for generating a plot. I don’t have much experience writing static fiction, but from what I gather, at least if you’re just writing words on a page, you can kind of “go with the flow” and see what plops out as you let your fingers walk across the keyboard. How can you do that with interactive fiction, which can’t be created in such a freeform manner? I need to know what I’m building so I can break it down into its constituent parts and implement it - I don’t see how it’s possible to build something interactive the other way around, at least not if it is going to have any kind of strong author-created plot. Or, perhaps it is possible, but only by discarding a lot of work along the way - and it’s difficult to do that if you’re working to a deadline.

It turns out that characterisation is also a challenge for me. I thought I’d got around this by basically making Zoran a version of myself - albeit a “me” from about 10 years ago when I was in my early twenties. But reviewers really didn’t like Zoran all that much. I felt conflicting emotions whenever my writing was praised for its portrayal of someone who, as it turns out, is intensely dislikable. In the author’s forum, somebody wrote “The awkward conversation with the failed flame was just executed perfectly to paint a picture of a hateful, disgusting human being wasting his life and self-absorbedly assuming that everyone else is doing the same”. Thanks, but… owch!


So, how did Moquette come about, and what was I trying to do with it?

Well, I’ve been talking about my vision for the future of text adventures for a long time now - in previous blog posts such as Text adventure games are still new, Thoughts on interactive storytelling and The Hobbit, Experimenting with stories and text, and in my talk at AdventureX. I realised that my thoughts would have a lot more weight if I backed them up by actually trying to create something, instead of just talking in the abstract about the kinds of experimentation that are still to be done with text-based games.

So what I tried to create wasn’t simply a technology demo, but to play around with various ideas and theories about how interactive story experiences might be constructed.

I will split the experimentation up into five aspects, which I’ll explore in more detail below.

  1. A different way of using links
  2. The nature of choice
  3. It's not a game
  4. First-person
  5. Special effects

Experiment 1 - A different way of using links

Quest started out as a parser-based system, although it has supported a hybrid hyperlink interface for a while now. It also now supports a simpler multiple-choice style of game - gamebook mode, which lets you create Twine-style works.

In Moquette, I’m exploring a style of game which is somewhere between the two. It doesn’t have the simple branching structure of a gamebook, but it doesn’t leave things completely open-ended like a parser game would. It is designed to be interacted with like a gamebook though, but underneath it is actually using the parser mode of Quest - I’ve just turned off the command input box and there are no objects with verbs to interact with.

I’ve used the power of Quest’s ASL programming language to model the tube network, and handle the passengers which are randomly thrown at you as the game progresses. The result is a game world that can be explored in a similar way to a parser game, but with a simpler interaction model. It’s the kind of game that couldn’t be written with Twine, or printed as a Choose Your Own Adventure book, because the game doesn’t use a branching model (if it did, the branch map would be huge as you can explore the tube network freely - it would have to be a ridiculously large book to handle all the possible combinations of choices).

I wanted to show that even with a minimalistic UI, you could create an explorable world, and you could do it more subtly than continually asking binary choice questions like “do you want to speak to the woman, or change to the Northern line?”. In Moquette, choosing one option often doesn’t rule out exploring other options too, and it’s easy to keep track of what you’ve done - the screen doesn’t clear between choices, but irrelevant links are deactivated so you always know exactly what options are available to explore.


Experiment 2 - The nature of choice

Despite all the options that are available throughout the game, there is only one real choice - and it’s right at the beginning. Do you let Zoran follow his usual routine and go to work, or do you intervene and try to stop him? Even here it doesn’t really make much difference - the choice you make comes back to you at the end of the game, but there is no real right or wrong answer (in my mind the “winning” move here is actually not to intervene, because that results in Zoran reaching his own conclusion and making his own choice. But, on the other hand, it’s also a winning move to show him the way).

Many people worked out that the choice of which tube train to get on was ultimately inconsequential. Some people didn’t like that. They expect to have a choice and to affect the outcome of the story. “You are the hero!” - but you’re not the hero in Moquette. You’re not the protagonist.

This is contrary to the assumptions of most interactive fiction, but in writing Moquette, I haven’t really been following the examples of text games I have seen before. I have been much more inspired by interactive theatre - the explorable worlds created by the likes of Punchdrunk and Secret Cinema, and wondering how to adapt those ideas to text-based fiction.

I believe that it is possible to create immersive, interesting story experiences where you have no effect on the outcome at all. You don’t win or lose when you experience Punchdrunk’s The Drowned Man, and you can enjoy the experience safe in the knowledge that you can’t get anything “wrong”, and that you will always make it to the ending. Surely text adventures can do this too?

One of the things that appeals to me about Punchdrunk is that everybody has a unique experience - there is always far more of the world to explore than you could possibly get around in one performance. I wanted some of that feeling in Moquette too, but without the flaw that often plagues Punchdrunk performances where the plot can be difficult to work out. As a single-player text game, I can adapt and move the world around according to the player’s choices - so you always get the complete plot, but different players will experience it in different locations. I wanted players to think that the encounter with Heather really is random - and that you felt that maybe if you’d gone a different way, something else would have happened instead. I wanted the game to feel bigger than it is, that when passengers got off the train before you’d had a chance to interact with them, that there were unexplored possibilities.

Of course, the illusion is shattered as soon as you play the game for a second time, and I expect many players are wise enough to work out the mechanics even when playing once. But hopefully it shows the kind of “magic tricks” that a text game might easily be able to perform.

Experiment 3 - It’s not a game

There are no puzzles in Moquette, and you will always finish if you just play it for long enough. But this gave some people a problem - there is no objective. Some people even emailed me plaintively - “what am I supposed to do?”. It’s interesting how that seems to matter, and I’d like to challenge the assumption that there should be an objective in interactive fiction. You don’t expect an objective when reading a book or going to the cinema - or if there is one, it’s simply “experience and understand the story”. Can’t that work for interactive fiction too?

Experiment 4 - First-person

I’ve never really liked the second-person style of most interactive fiction. “You are standing in an open field west of a white house” - no, I’m really not. I think writing in the first-person neatly sidesteps a lot of issues - I’m no longer wondering what my role is, how I got here, what my previous memories might be, or what I’m supposed to be feeling. Instead I can simply enjoy seeing the world through somebody else’s eyes. In Moquette we teleport inside Zoran’s brain, and we get to play with some of the controls. But the suggestions we make to Zoran are just that - suggestions, which he doesn’t have to obey.

Maybe this aspect of the game isn’t really that experimental - certainly none of the reviewers picked up on it. But given that nobody complained about it, I think the choice of first-person works well and is probably something that should be considered more as a sensible default voice for interactive fiction.

Experiment 5 - Special effects

Text Effect

There are various screen transitions throughout the game - I liked the idea of it having something of a graphical feel, even though it was only using text.

I’ll talk about the implementation details of the effects in a separate blog post - they’re nothing more than relatively simple JavaScript. It would be easy to go overboard and include too much of this kind of thing, but most of the reviews have been positive about these. I think it shows that HTML offers some interesting visual capabilities which most IF hasn’t got round to exploring yet.


Here are all of the publicly available reviews and mentions I came across (let me know if I’ve missed any and I’ll update the list).

  • Indie Statik: "Moquette is a droll game that encapsulates the act of travelling nowhere in particular and the thoughts you amuse yourself with remarkably well"
  • Francesco Cordella: "Moquette is too slow to thrill"
  • Robert DeFord: "I'm not sure I liked it, but I can see where some people would"
  • Michael Martin: "I kept trying to have goals and the game was very ambiguous about whether or not I should... I can't make up my mind whether to be annoyed or impressed"
  • Puppystuff: "It’s about some asshole with a hangover who sits on the London subway and silently judges everyone after deciding to skip work"
  • PaulS: "in the end it doesn't work, because it forces the player to make endless unimportant choices, but gives no opportunity to make important ones"
  • Doug Egan: "I expect it will only finish near the fiftieth percentile as a competition entry" (good call!)
  • Emily Short: "I had a hard time feeling deeply about someone whose chief personal characteristic is a tendency to editorialize about other people’s hat-wear faux pas"
  • Sam Kabo Ashwell: "Game designers, take note: if you ever come up with a premise that boils down to 'okay, so the player can't really do anything significant and is just hanging out getting bored, right, but every now and then some plot happens', then you should throw it out."
  • Bainespal: "its plot is both too eclectic and too unambitious to be interesting ... Moquette is probably more of a technology piece than a literary piece, but it still manages to evoke the modern social condition"
  • The Xenographer: "I've always thought that intentionally boring your audience is a tough thing to do well and in most cases should probably be avoided"
  • Wade Clarke: "Overall, a mix of good elements and others which didn't work so well"
  • Pissy Little Sausages: "Yeah, that was pretty great.  Docking it three points for not letting me get my cock out, though."
  • Deirdra Kiai: "Impressive tech demo. Not really a fan of the protagonist dude's narrative voice; he came across to me as a judgemental prat."
  • Ricordius: "Eventually, Story Happens. In the meantime, until Story Happens, I'm just blindly hopping on and off these trains. I suppose Story Continues eventually, but I no longer cared. ... But this is Quest. It means that Quest is capable of some seriously eye-opening shenanigans that I had not thought that system capable of before. And that, in spite of the very flawed central core, means I am still impressed."
  • Eric Olson: "I still have hardly an inkling of what this was supposed to make me feel outside of frustrated at the amount of my time it wasted."
  • (German - a quote from Chrome's translation: "The language ripples then, sometimes sparkles forth with unexpected impressions and insignificant observations here and there, rocking on to thoughts that suggest the image of a man who wants to break out of the eternal recurrence of the same in his gray life.")
  • Other reviews and ratings on Moquette's IFDB page

I also tried a little to get the word out beyond the normal IF circles. With the game set on the London Underground, it made sense to reach out to London blogs - it got small mentions on Londonist and Diamond Geezer. The competition rule requiring authors not to discuss games publicly hurt a bit here - if we can’t promote our own games (and the competition in general), who will? Who will take responsibility for plugging the IFComp outside of the circles of people who already know about it?


See how many times you can spot me in this highly appropriate video. (If you don’t know what I look like, check out my Twitter profile)

Quest is 15

7 November 2013

Quest is 15 years old today! I posted the announcement of Quest 1.0 on the newsgroup on Saturday 7th November 1998. (And the original link in that post still gets you to the right place today, eventually)

Quest 1.0

So Quest is itself now almost as old as I was when I started writing it. But what got me started on it in the first place?

You’re probably expecting me to say something like this… I’d been interested in text adventure games since their heyday in the 1980s. On my family’s home computer, I got hooked by classic games like Zork, Hitchhiker’s Guide To The Galaxy and Planetfall. Such wonderful worlds of the imagination! Such crafty puzzles! I would spend hours drawing maps on squared paper and looking out for grues and giving myself eye strain and…

Well, no. That’s not how it happened. I never played any of those. In fact, I was never really into text adventures at all.

But then, they were before my time. I was just a bit too young. I first dabbled with a computer in, oh, about 1990 or so. We had an Acorn Electron in our house. We did have a couple of text adventures for that - we had a copy of Acornsoft’s Sphinx Adventure (never really played it, couldn’t get anywhere, found it boring) and my dad had typed in the listing of a game called Necromancer from Electron User magazine. Which never quite worked properly, as something had been mis-typed somewhere along the line.


So I was just never that interested in text adventures. I was more into playing whatever shareware games had found their way onto my PC - Commander Keen, Wolfenstein, Doom and so on. But what I was much more interested in was creating my own. I probably spent more time in front of QBasic than any game. And that is where it all begins, really.

Schoolboy Humour

In 1994, at the age of 12 I started secondary school. The IT lab there was open at lunchtime for anybody to use. So instead of running around getting exercise, or loitering somewhere else, me and my friends played around with the computers. They were probably 486s, running MS-DOS 6 and Windows 3.1. They were connected to some kind of network but there was no internet access - we’d barely heard of this internet thing anyway back then. There wasn’t a whole lot to do other than write silly little programs using QBasic (or Visual Basic 3.0, which was also installed) so that’s what we did.

After my schoolfriend Martyn moved house and went to a different school, we kept in touch by writing letters to each other - this being a time before either of us had an email address. We would enclose 3.5” floppy disks to share our latest programming efforts. It was in fact in Martyn’s first letter, around January 1995, that he sent me a game he’d written called “Sid Snibble and the Curse of the Curry Stain”.

I still have a copy, in a heavily nested folder full of archives of archives, and I can still run it today using QB64. It looks like this:

Sid Snibble and the Curse of the Curry Stain

It was a text adventure, but even this had a graphical element to it - you didn’t walk around the game by typing NORTH, SOUTH etc., you moved an ASCII face around with the arrow keys. When you entered a location, you could look at things, speak to characters, pick up items and so on - all in an attempt to solve the mystery of what happened the night before, and why you woke up in the middle of the road in a strange town with a large curry stain down your shirt.


This looked fun. I could write something like this. It would be hilarious! And so I set to work, doing what I’d always done - copying Martyn’s ideas, but doing them a lot worse.

So, in April 1995 I wrote my first text adventure game.

It was called… well, there’s no easy way to put this. I don’t want to rewrite history or tell a lie. I was young and the game was only for me and my friends. It was called ”Where’s My Nob?!

How I wish that weren’t true. How I wish I could sit here and tell you the story of how I poured my soul into a creative work of genius, a work of art, a literary masterpiece. With a title like that, maybe I could claim that it was an earnest work exploring gender issues. But it wasn’t. I was 12. The game was an excuse for a load of the kind of sophisticated humour that 12 year olds are known for. Featuring locations such as Dracula’s castle, a teacher’s house, a corner shop, a dairy, a Skoda dealer and Potato World.

So, a throwaway game that should be played by nobody. But for me, a 12 year old boy who didn’t do any kind of creative writing, it was a fun thing to do that got some kind of creative juices flowing.

[Aside: Although it’s not a work that I would ever want anybody to see - indeed, I would be absolutely horrified - I think what it represents is something that still persists as I develop Quest today. Specifically, although I want Quest to be a useful tool for building very high quality works of interactive fiction, there is still a need for something that allows people to create their own Sid Snibbles (and, er, to find their own Nob? I think deep down my sense of humour remains the same). To give people a way to express themselves, to allow them to develop their artistic sense, to allow them to get started, and then to improve their craft. It’s easy to be snobbish about this kind of thing, and to moan about low-quality games, but if we didn’t have bad text adventures, it’s unlikely we would have very many good ones either.]

Anyway, back to my, er, game. I sent it to Martyn on a floppy disk together with a second one called “Make Mrs Booth Friendly!”, a game about my French teacher. Also on that disk, I included a terrible chatbot, “Dr Mad!” who would diagnose your illness, and a fortune teller called “Sadistic Smeg”.

Over the following months I wrote some more text adventure games, always full of in-jokes about school, only ever written for my friends, and never to be seen by anybody else ever, certainly not now. “It’s Mad!”, “Fantasy Land!”, “Park Parade Adventure!” and “The Town of Terror”. It seems the running theme was titles with exclamation marks.

Making Text Adventures for Windows 95

Fast forward a few years to 1998, when I’d started dabbling with Visual Basic 5.0 - which meant I was no longer stuck writing programs for DOS, I could create programs for Windows instead, featuring buttons and menus and message boxes and pictures and everything. I was rather stuck for ideas though. I’d spent some time working on a virtual pet, which were all the rage back then, but wanted to try something a bit meatier. I’d just finished my GCSE exams and was looking for something to keep me occupied over the summer break before I started sixth form. I thought back to the text adventures I’d written, and wondered - what would a text adventure game for Windows look like?

I decided to write myself a little engine before writing a game, so I wouldn’t have to hard-code everything like I’d done in QBasic. I started coding something that would take in a simple text file which would define all aspects of the game, and handle things such as allowing players to save their progress.

It turned out that I was actually far more interested in creating the engine than I was in writing a game anyway, and I was interested to see what other people might come up with if they used my system. At the time, I was fairly ignorant of any pre-existing systems which would do a similar thing to mine, until somebody suggested I take a look at the newsgroup. I started checking out the competition, and reading about Inform and TADS. It was clear to me that they were difficult for newcomers to use (this was before Inform had a natural language syntax - the syntax of Inform 6 still looks bizarre to me), so it looked like I should be able to get people interested in what I was doing.

I released Quest 1.0, and it looked like this:

Quest 1.0 Start Screen

(Those two globes were animated and bounced back and forth between the edges of the screen. For some reason.)

Quest 1.0 loaded text files which were in a simple format I’d devised, called ASL - Adventure Scripting Language. The syntax was simple, designed to be coded by hand using Notepad or similar - there was no visual editor yet (“QDK” appeared the following year).

Here’s the Quest 1.0 Readme file and ASL Reference if you’re interested in some historical detail. You would create games by using Notepad to edit the included template.asl file, which looked like this:

' Quest ASL Template
' All sections must exist in the game, though the text sections may be empty
' if desired.
define game <Enter name of game here...>
    asl-version <100>
    game version <1.0>
    game author <You>
    game copyright <© 1998...>
    game info <Enter game info here...>
    start <Enter name of place here...>
    possitems <Enter items separated by commas here...>
    startitems <Enter start items here...>
end define

define room <Enter name of place here...>
    look <Enter description here...>
end define

define text <intro>
Enter intro text here...
end define

define text <win>
Enter win text here...
end define

define text <lose>
Enter lose text here...
end define

This file format lasted a long time. It was used right up until Quest 4.x, the last version of which was released in 2011 - albeit heavily extended and changed in various ways over the years.

The empty template looks like this when loaded in Quest 1.0:

Quest 1.0 running a game

The user interface is still very similar to what Quest offers now - in fact, after it was rearranged in Quest 2.1 it has effectively remained an identical layout. There is the game text of course, a command box, a space to show what items you’re carrying, and a list of things you can see in the current location (which would show “Look at” and “Take” buttons if something was selected). There are also the compass buttons for easier navigation.

Quest 1.0 supported rooms, characters, objects, things you could pick up (“items”), quantities of things (“collectables”), string variables and some basic script commands. It could play WAV files, show images and display pop-up menus. It supported text formatting, and let you set up your own custom commands using a syntax like “eat #object#” - the same format that is still used in Quest 5 today.

There was a small sample game distributed with Quest 1.0, “A day in the life of a salesman”. It is of a very similar standard to my QBasic efforts - which is to say stupid, crude and borderline offensive in places. So no, you can’t have a copy, but yes, it does still run in Quest 5.4!

What happened next? We’ll pick up the story in the next blog post, where I’ll talk about how Quest grew, changed and even shrunk over the years to become what it is today.

ActiveLit Launched - interactive fiction for schools and groups

9 October 2013

After several months of beta, we have now launched our new service ActiveLit. Many thanks to all of you who have signed up and given us your feedback so far.

ActiveLit provides you with a safe, private, curated area in which to play and create text adventure games and interactive fiction with a group or class. After setting up each of your students or group members with their own login, they can access your ActiveLit area from anywhere - on your own premises or at home. They can play and create their own games and stories directly in their browser, whether that’s on a desktop, laptop, phone or tablet - there is no need to download any software.

To get started, sign up and request an account. ActiveLit is free for groups of up to 10, and we have various packages available for larger groups - with an introductory half-price offer until 31st December 2013. You can switch to a larger package at any time, so you can try ActiveLit with a free account and then upgrade later.

When we process your request, you’ll receive an email with instructions for logging in to your admin area.

ActiveLit Admin

The admin area lets you add members to your site. It also shows you the web address where they can log in - it will be something like It’s quick to add users, and passwords can be generated automatically, but if you have a large number of users to set up, email us and we’ll import them for you.

Playing Games

Choose the games you want to display to your group. You can choose any game from It is easy to search, and you can also browse by category.

Choosing games for ActiveLit

Clicking the game name shows you the description of that game, where you can play it and also jump to the listing at to see the reviews and comments.

Viewing game information

Once you have chosen the games you want to display, you can customise how they are shown.

Customising the games list

You can choose which order they appear in, and you can also give them your own description - for example, to set a particular game as homework.

Customising a game description

When group members log in to the area, they will see the list of games you have selected.

An ActiveLit area

They can click on the game to view your description, and play the game in their browser.

Customised game description

After playing a game online, as the group administrator you’ll be able to see session transcripts in the Reports area.

ActiveLit Reports list

An ActiveLit report

Creating Games

Group members can build their own interactive stories online using Quest. When they’ve finished creating their interactive story, they can publish their game to the area to share it with other group members.

More coming soon

Sign up and give us your feedback! Stay tuned for more updates - we’ll be continuing to add functionality over the coming months, so do get in touch and let us know what will help you with using interactive fiction in your group.

All Posts