Squiffy 1.0

Squiffy is a lightweight tool for writing interactive fiction. It is open source and runs on Windows, OS X and Linux. It generates static HTML, CSS and JavaScript files which you can upload anywhere.

I’ve already written one interactive fiction system, Quest – so why create another? It was while writing my first game Moquette last year that I realised I needed a simpler tool for the kind of interactive story that I was interested in writing. I wanted something that would let me sit down and “just write”, mostly getting out of my way.

So I’ve now created the tool that I wished I had back then. This version 1.0 release is intentionally very simple – it’s a command-line Python script that reads in a text file, and writes the output to the same folder. Here’s how to install Squiffy.

Game text is written using Markdown. Players click links to interact with the game. Unlike other systems, Squiffy’s equivalent of “nodes” or “pages” are split into two types:

  • Sections which move the story forward
  • Passages which provide a way to further explore or interact with the same scene

An example might help to explain the distinction between the two.

You enter the room. There's a [chair] and a [table] here.
You can go to the [[kitchen]].

[chair]:
Just a chair.

[table]:
An ordinary table.

[[kitchen]]:
You enter the kitchen...

Here, “kitchen” is a new section, whereas “chair” and “table” are links in the same section. You can click the chair, and the chair’s description appears, but the table and kitchen links remain enabled. If you click the kitchen link, the table link is now disabled, as you’ve moved to the next section.

If this sounds confusing, don’t worry – you can build you game entirely out of sections, and it will play as a traditional multiple choice game. But by including passages, you could create works that have a bit more of an exploratory feel. If Moquette were written now using Squiffy, I could use sections for each train, and passages for interacting with people in the same train carriage, for example.

Squiffy also makes it easy to use JavaScript. Any section or passage can embed JavaScript, simply by indenting code before the text. This would be useful for Moquette-style transitions – here’s an example of a screen blackout between sections.

A player’s progress is saved automatically to the browser’s local storage. They can close their browser tab, and the game will be restored immediately when they come back.

You can save state in attributes, replace text, and make links that replace themselves.

For publishing your game, you can upload it to any web space, or submit it to textadventures.co.uk. You could install PhoneGap or upload it to PhoneGap Build to turn it into an app.

Instead of “big bang” releases, the plan is to improve Squiffy one feature at a time. We will build up to a web-based editor over a series of what will hopefully be relatively frequent releases. For the plan, see the Development Roadmap.

For full details on using Squiffy, see the documentation.

I hope you will give it a try and give me your feedback in the forums!

Quest is now on GitHub

Ever since Quest was made open source back in 2010, we’ve been using CodePlex, which is Microsoft’s open source project hosting site.

Now in 2014, even Microsoft isn’t using CodePlex any more – all their open source ASP.NET is on GitHub, for example.

So CodePlex has been feeling a bit dead, but even worse, it’s been a bit buggy over the last few months – frequently giving me authorisation errors when pushing to the Mercurial repository.

I’d stuck with CodePlex and Mercurial for a while because Git tooling on Windows was always kind of horrible. Fortunately, that changed when GitHub launched GitHub for Windows, which finally makes it easy for just about anybody to use Git.

So I’ve now migrated Quest over, and the source code now officially lives on GitHub at https://github.com/textadventures/quest.

All issues from the CodePlex Issue Tracker have been migrated too. Please log all bug reports at GitHub from now on.

Finally, nobody had ever heard of the Ms-PL which Quest was previously licensed under. I kept having to say it was “just like the MIT licence”. So I’ve updated that too, and Quest is now officially licensed using the MIT licence. Nothing has really changed – you can still do pretty much what you want with the Quest code, including using it within closed-source projects – but hopefully it’s just a bit clearer now.

How am I doing? The Quest and textadventures.co.uk Annual Review 2013/14

I’ve done an “annual review” at around this time of year for the last few years, so it feels like a good idea to do it again, one last time. For reference:

This is the last time I’ll do an annual review because I am no longer working on Quest and textadventures.co.uk full-time. The good news is I’ve just started an absolutely awesome job at Stack Exchange, and for pretty much the first time ever I am thoroughly enjoying being employed.

Some stats

textadventures.co.uk has grown quite a lot over the last year:

  • It currently averages around 1500 unique visitors per day, up from about 800 a year ago.
  • Over the last week, there were on average 2150 game sessions per day, which is up from 480 per day. (That figure was the average over 2012/13, so is not exactly equivalent – the site grew over 2012/13 too, so the daily average by the end of 2012/13 would probably have been a bit higher).
  • There are currently 3693 games listed on the site, up from 980. Of these, 2536 are publicly available (the rest are private “unlisted” games only available to those who have been given the link).
  • Of the games on the site, 2752 are Quest games, of which 1671 are public. So, there are 941 non-Quest games – which is up from zero a year ago, as during this year support was added for all kinds of web-playable text games. 503 of these non-Quest games have been imported from IFDB (more will be added soon).
  • 24,548 games have now been created using the web version of the Quest editor since it was launched, up from 7300 last year. 1766 of these have been published, up from 331.
  • Of the 1751 Quest games added since 1st April 2013, 1334 were created with the web version of Quest – 76%. Last year it was more like 50%.

Some things that happened since the previous annual review

May 2013: Released Filbert and the Broccoli Escape – an interactive children’s book for iPad, and the beta of ActiveLit. I also spoke a bit about text adventures at GameCamp.

June 2013: Wrote up some thoughts from the Futurebook Innovation Workshop, and started accepting games built with Twine, Undum, Parchment etc.

July 2013: The first QuestComp competition finished. Open-sourced QuestJS, the Quest-to-JavaScript converter. Wrote up some initial thoughts about Quest 6, although my thinking has changed somewhat since then – carry on reading this post for my current thoughts.

August 2013: Added more games to the site by accepting external listings for web-playable text games.

September 2013: Wrote up some notes from the Publish 2013 conference. The IFComp games were released, including my very own first work of interactive fiction – a story set on the London Underground called Moquette.

October 2013: Enrolled on the 3-month Story Innovation Programme, experimenting with stories and technology with a whole bunch of interesting people.

November 2013: The IFComp results were in, and I wrote a two-part analysis of Moquette – part 1 and part 2. I also wrote a three-part series of blog posts looking back at 15 years of Quest – part 1, part 2, part 3. Meanwhile, as part of the Story Innovation Programme, I started work on an experimental interactive fiction project as part of a brief we had been given by book publisher 4th Estate, to come up with something to promote the forthcoming “Annihilation” by Jeff VanderMeer.

December 2013: After failing to get funding to continue with Quest and textadventures.co.uk full-time, it was time to start thinking about moving on. I didn’t let the knock-back stop me from released Quest 5.5 Beta though. The Story Innovation Programme came to an end, and we demonstrated our prototype to 4th Estate, who liked it enough to want to see it turned into an actual thing.

January 2014: Mostly job-hunting, really.

February 2014: After finally getting the go-ahead from 4th Estate, I spent most of the month working with Caroline Moran, Simon Mercer, Martha Henson and Sam Howey-Nunn to build our interactive experience Join The Southern Reach, which launched at the end of the month.

March: Released Quest 5.5 and started my new job.

Good, but not good enough

I think there are a lot of positive aspects to what’s happened over the last year, but ultimately none of the major projects were as successful as I’d hoped.

  • ActiveLit, the site I set up for schools using Quest in the classroom, has got off to a fairly slow start. It is getting signups, and there are other groups (presumably schools) which I can detect using the main site, but it seems like the energy has waned somehow – I used to see blog posts and tweets from teachers getting excited about the potential for text games in the classroom, but I don’t see this very often now. I haven’t been invited to an educational conference or asked to run a workshop for a while now either.
  • Moquette did OK in the IFComp – not terribly, which was a relief for my first game, but it hardly set the world alight. I still judge this a successful project though – it was my favourite thing I worked on all year and certainly the most challenging. It taught me a lot about writing interactive fiction, and I got to see Quest in a whole new light. It’s good to remember the importance of “eating your own dogfood“.
  • Join The Southern Reach is pretty good, I think, but it has attracted very few users. I had big hopes for this as it’s something I’ve wanted to do for a long time – a project with a traditional publisher. I got to focus on the coding, leaving other people to worry about the actual writing, the marketing, and so on. It got on to BoingBoing, yet it has had fewer players than Moquette. It shows that even if a project is backed by a publisher and an author with an existing fan base, that’s not enough.
  • I suppose “seeking money” was the other major project of the year. We came tantalisingly close with Emerge, but not close enough.

Where next?

What next for Quest and textadventures.co.uk, then? They are back to being spare-time projects, which is a relief in many ways as I no longer need to worry about how on earth I might make money from them – giving me a lot more freedom to just pursue the aspects I’m interested in.

textadventures.co.uk is growing, getting more visitors and receiving more submissions. Managing this is an interesting challenge. How should we highlight and encourage good games, how can we help people to post useful reviews and comments?

Quest itself seems less interesting to me. The textadventures.co.uk site is now bigger than Quest, as it now accepts submissions from all web-playable systems. And it feels to me like I don’t have much more to contribute to Quest itself – I’ve pretty much reached the end of my mental list of things I’d like to do with it. Significantly, in writing Moquette I came to the realisation that Quest isn’t actually working for me as an author. It’s too big and complicated, it tries to do too much, and the HTML/JavaScript aspects of it are not as flexible as I’d hoped. (I had to do a lot of hacking around to make Moquette, which is largely why the 5.5 release of Quest exists).

It was with this in mind that I started work on Squiffy, which is pretty much the system that would have needed to exist for me to have been able to write Moquette as simply as possible. I haven’t really announced it much yet, and there’s still some way to go before it’s really usable.

I will continue to accept any pull requests that are sent my way for Quest, but I can’t see myself doing anything too major on it in the future.

The wider world of interactive fiction continues to grow and change. Inkle seem to be doing very well, people are still making stuff in Twine, the IFComp is changing, there are new meetups like the Oxford and London Interactive Fiction Group. This is all very encouraging, but maybe over the last year I’m just not seeing the acceleration of change that I was expecting. I used to be convinced that interactive fiction could grow to become much more mainstream than it currently is, but now I’m not so sure at all.

So it feels like the right time for me to be putting interactive fiction projects back into the time-slot marked “hobbies”.

Quest 5.5 is now available

Quest 5.5 is now out of beta:

For details on what’s new in Quest 5.5, see the beta announcement blog post.

Changes since the beta:

  • Mauricio Díaz García updated the Spanish translation, and added a new editor translation – so the editor now is mostly displayed in Spanish when editing a Spanish game.
  • Pertex fixed a few bugs and did some more work on allowing the Editor to be translated.

Thanks once again to everybody who has contributed to this release: Pertex, Jay Nabonne, The Pixie, Guillaume Poulain, Katzy and Mauricio Díaz García, and also to Phillip Zolla for sponsoring the new drawing features in this release.

Quest 5.5 Beta is now available

The Windows desktop version of Quest 5.5 Beta is now available for download.

This is a relatively small update, with a focus on refining the player interface, and a few other tweaks and enhancements here and there.

Improving the player interface

This version features some enhancements to make it easier to create games that look a little more elegant. The location bar and screen border can be toggled off, and you can set a custom display width and padding. There are new display themes, so you can easily change from the Quest Standard theme:

Quest Standard Theme

to the simpler “Novella” theme:

Quest Novella Theme

And there are a few more fun bonus themes too.

In gamebook mode, the new default is to not to clear the previous page when clicking a link – instead, new text is added to the bottom. (The option to have the screen clear between pages is still available).

Drawing

Support has been added for drawing SVG graphics in the custom drawing layer. There are new functions for drawing arrows and arbitrary many-sided shapes. The automatically generated grid map now works when multiple player POV objects are used.

Tweaks

Various tweaks have been submitted by Quest users:

  • Pertex added more gamebook counter functions, as well as contributing some bug fixes.
  • Jay Nabonne has contributed a tweak to the “invoke” script command.
  • The Pixie has added a “select” command to the text processor, and updated the text processor’s “{if}” to allow not-equals.

Translations

  • Pertex has started work on allowing the Editor to be translated.
  • Guillaume Poulain has contributed an updated French translation.
  • Katzy submitted corrections for Dutch.

Other changes

  • The “return” statement now immediately exits the function.
  • The “Pause” request is no longer supported for games written for Quest 5.5 or later.
  • You can now create a blank JavaScript file straight from the editor.
  • There is a new “Features” tab for both the game and objects, making it easier to toggle Quest features on and off, so you only see the editor tabs you care about.

Thanks to everybody who contributed towards this release – please download it now and submit any bug reports to the issue tracker.

Starting a new chapter

I’ve been building Quest and working on textadventures.co.uk full-time for a couple of years now, on and off. Despite my best efforts to turn this into my living, I can no longer continue to work on this basis. As of January, I’ll be moving on to work on something else, with interactive fiction becoming a side project once again.

We applied to Emerge, a new startup accelerator focusing on education, with our aim of building up ActiveLit. I’m told about 80 companies applied, and we were one of the 20 selected for interview.

Unfortunately we are not one of the 7 or 8 that have been selected to join the programme.

We would like to thank you for taking the time to apply to and interview for Emerge Education ’14.

Places are limited and the applications were excellent. It was difficult to select participants from such a strong group. Unfortunately on this occasion, we are not in a position to offer you a place in Emerge Education ’14. We hope you will apply to our future programs.

We include below a brief summary of how we arrived at this decision and hope this is helpful to you:

  • Your product was more developed and had more traction than that of any other applicant to Emerge Education and we were impressed by the user demand it has received;
  • The selection committee’s main concern was a lack of clarity around whether your team had the strategic intent to take ActiveLit from an (already) successful product to a high-growth business;
  • In addition, applicants that did better in the selection process tended to have more business experience as part of the co-founding team.

I find it difficult to understand the logic here, and in fact this email makes less sense every time I re-read it. The highest traction product of all applicants, but a question mark over our “strategic intent”?

Whatever. You can’t expect too much from rejection emails. Any “reasons” given are always post-hoc justifications of the decision made. I expect the most typical would be “your product is not sufficiently developed”, so at least it’s novel to be turned down because our product is too developed.

It would only require one reason to say yes – “we think there’s a good chance of making money if we invest in you”. At least in this way it’s a more straightforward and honest process than awarding grants – it’s refreshingly simple compared to working out why, say, a government body won’t award funding. Any rejection from an accelerator is fundamentally because they couldn’t find this reason to say “yes”, rather than any reasons that may be given for saying “no”.

This is the feedback we’ve been waiting for, then – the simple yes/no answer to the question “Can we convince people that know about money and business and stuff that what we’ve been working on is viable?”

And the results are in, and the answer, at least from Emerge (and also Wayra), is “no”. And that’s fine.

They say that it takes grit to succeed, but what if you never give up on an idea that is fundamentally never going to work? Maybe it simply makes more sense for Quest, textadventures.co.uk and ActiveLit to be run as side projects. I’ve sunk a lot of time into these now – 2 years of full-time effort. I’d be much richer now if I hadn’t done this.

Of course, I’d be unhappy. I’m really pleased with what I’ve achieved. I used to sit at work, seething in frustration, because there were things I wanted to do with interactive fiction that I didn’t get time for. That’s changed now – I’ve built a lot of software, explored a lot of angles and spoken to a lot of people, trying to work out how an interactive fiction business might succeed.

And what I’ve discovered is, I can’t make it work. Not right now anyway. Maybe it just needs to live and grow organically for a while. Maybe something external will change, as more and more people discover interactive fiction, or as more teachers use Quest and text adventures in the classroom. I’ve got nothing left to “push” from my side, and I’ve run out of money anyway.

And even if nothing external changes, and it never grows beyond what it currently is, it will still have been worthwhile. I don’t regret anything. I’ve built what I wanted to build. I’ve scratched the itch. I’ve created software that is being used by all kinds of people for all kinds of things. Children are learning programming, being engaged with reading and writing. More and more people are playing and creating games on the site. I’ve met some great, interesting people. It’s been a lot of fun. It’s been totally worth it.

But I can’t do this for a living, so it will have to become my hobby again. There are plenty of other things I can do – there are loads of opportunities for software developers at the moment, and there are some great companies out there doing interesting things which I can contribute to. It’s an exciting time, and I’ve now got some great experience that will hopefully prove useful in whatever I move onto next.

15 years of Quest, part 3: 2000-2004 – Experimenting with Multi-Player

This is part 3 of a look back at 15 years of Quest. Here are links to the previous posts: part 1, part 2.

The first alpha build Quest 3.0 was released in March 2000, and fixed one of the weird design flaws of previous versions by unifying “items” and “objects”. Objects now had to have unique names, but they could have aliases, which would be displayed to the player instead of the code name. This version also introduced a disambiguation menu to allow the player to distinguishing between different objects which had same the alias. This is fundamentally the same approach to object handling that Quest still uses today.

That first alpha of Quest 3.0 also added timers. The second alpha in July 2000 added support for a truly experimental feature that never quite took off – online multi-player play. This allowed Quest to connect to a new bit of software I was working on, which started out with the name “QX3″ and was later renamed “QuestNet Server”.

The idea was that the game ran entirely on the server, and players would connect to it using the Quest software. This would allow multiple players to connect to the same game world, where they would each have their own inventories and be able to interact with other players.

You can get some idea of how it worked by looking at some screenshots for the basic “Arena” demo. Multiple players would appear in the same room, and they could pick up objects, give them to each other, and even hit each other. For example, here’s what Bob might see if he joins Alex in the room:

Multi-player Quest game - 1

And here’s what Alex sees while this is happening:

Multi-player Quest game - 2

I thought this was rather nifty, myself, and although it got a reasonable amount of interest from Quest users, it ultimately failed to really get anywhere. I’ve come across a forum post from 2002 by MaDbRiT which sums it up:

Questnet is a good idea that is kind of struggling to get off the ground. There are no games because there are no players and no one wants to spend aged writing a game if there are no players. What came first, the Chicken or the Egg? The technical demands of hosting a QuestNet game are out of realistic reach of most of us too – even if I wrote a QuestNet game, I couldn’t “serve” it – I just don’t have the facilities.

In the days when most of us were still using dial-up, the idea of running a server on your home internet connection just didn’t make a whole lot of sense.

QuestNet Server would hang around for a while, never getting much use or ever seeing its full potential. I still think there’s something in the idea of multi-player interactive fiction, and maybe it’s something to revisit some day. Watch this space!

The second alpha of Quest 3.0 also got rid of the separate concept of “characters” – they were now just objects too. It added support for arrays, and arbitrary object properties allowing any kind of data to be attached to an object (although these were separate to the built-in properties or “tags”, which meant that you couldn’t easily read or update data like an object’s “look” description – this flaw was resolved when Quest was rewritten for v5.0, when all object data was finally stored as properties).

A third alpha build followed in September 2000, which added object types – allowing object properties to be inherited. This also added support for creating rooms on-the-fly via script.

In October 2000, I moved to London and started university, so progress with Quest slowed down quite a bit.

In March 2001, Quest 3.0 reached its first beta release. This added support for dynamically creating objects and exits, and added script properties (“actions”). The second beta followed in April, featuring various minor tweaks to get it closer to a releasable version. Quest 3.0 was finally released in September 2001, and QDK was updated at the same time to get a cleaner interface and to support all the new Quest features. It also gained a new script editor.

The new-look start screen allowed you to load a game file, or connect to a multi-player network game:

Quest 3.0 Start Screen

The main player interface was relatively unchanged from Quest 2.1, although you could now toggle the panes off:
Quest 3.0

QDK was still looking rather plain:QDK 3.0

The Room and Object editors were now grouped into tabs:QDK 3.0 Room Editor

QDK 3.0 Object Editor

The new Script Editor presented a plain English way of editing scripts. It’s not dissimilar to Quest 5’s script editor, although it did involve opening a pop-up window every time you wanted to edit any individual command, which some people found a bit tiring:QDK 3.0 Script Editor

A few bug-fix releases followed very shortly afterwards, and then I started working on v3.1. This added support for MOD music files – something I was into creating myself, but a feature I think was never actually used by anybody. There were various other tweaks, including improvements to the parser. Libraries gained the ability to add panes to QDK (here again is an example of a feature that was added which is now a core part of how Quest works – as of v5.0, all panes in Quest’s editor are defined by libraries). Quest 3.1 was released in June 2002.

The next update was version 3.5, released in December 2003, featuring the ability to translate the player interface (although not on a per-game basis – it was a player setting), plus support for text-to-speech and opening ZIP files. Following slightly later in January 2004 was the first non-beta release of QuestNet Server – although, as it would turn out, it would never get another significant release after that, simply keeping pace with features as they were added to the single-player version Quest.

The pace of change was clearly slowing down, as I was keeping busy with my Physics degree. It got even worse after I graduated in 2004, and started working – I didn’t really touch Quest for almost two years. But when I finally came back to it, I dived into it in a big way. More on that next time!

For a trip down memory lane, all posts from the old forums from 2000-2003 are available: Quest Forum, QuestNet Forum, Games and Chat Forum. Posts from 2003 onwards are all part of the current forums.

15 years of Quest, part 2: 1999-2000

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 textadventures.co.uk, 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 textadventures.co.uk 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.

Finally if you’re enjoying this retrospective and/or want to support Quest, please buy Quest a birthday gift. Thanks to everybody who has bought us some teabags so far!

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

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 textadventures.co.uk 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) {
     $("#gameBorder").hide();
     $("<div/>", {
         id: "introScreen"
     }).css({
         position: "fixed",
         top: 0,
         left: 0,
         width: "100%",
         height: "100%",
         overflow: "hidden",
         "text-align": "center",
         display: "none",
     }).appendTo("body")
     .html("<img id=\"introScreenImg\" style=\"max-width:100%;max-height:100%;\" src=\"" + url + "\"/>");
     $("#introScreenImg").load(function() {
         $("#introScreen").fadeIn(4000);
         setTimeout(function() {
             finishIntroScreen();
         }, 7500);
     });
 }

function finishIntroScreen() {
     $("#gameBorder").show();
     $("#introScreen").fadeOut(7000, function() {
         $("#introScreen").remove();
     });
 }

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:

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

The reshowOutput JavaScript function is simply:

$("#divOutput").show()

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"
    }).css({
        position: "fixed",
        top: 0,
        left: 0,
        width: "100%",
        height: "100%",
        overflow: "hidden"
    }).appendTo("body");
    doHeatherText();
}

function doHeatherText() {
    _heatherTextCount++;
    if (_heatherTextCount < 150) {
        setTimeout(function() {
            doHeatherText();
        }, 20);
    }
    else {
        $("#heatherText").fadeOut(2000, function() {
            $(this).remove();
        });
        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"
        }).css({
            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(),
        }).appendTo("#heatherText");
    }
}

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"
         }).css({
             position: "relative",
             left: "1200px",
             top: "0px",
             "font-size": "36pt",
             "font-family": "Georgia, serif"
         }).appendTo(getCurrentDiv());
         animateHeatherTube(200);
     }, 2000);
 }

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

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.