Planet Interactive Fiction

As I was poking around the forums the other day, I realized how much information is buried in the forums.  Things I might not even think to search on or are difficult to find even when looking.  And when you do find something, it’s often difficult to piece the useful information together from a long thread.

With that in mind, I’m going to start a series of posts, starting with this one, on things I’ve found in the forums or elsewhere that I find interesting or useful and try to put them in nice digestible bites.  I hope to educate myself through this process and hopefully they’ll be of use to others as well.

Are we transcripting?

My first gem was suggested to me by Andrew Schultz.  Back in 2012 he had started a thread entitled I7 – Check if transcripting is on when noting?  The basic premise behind the post was checking if transcripting is turned on.  As I talked about in my previous post on easy transcription notes, Andrew was doing something similar, but as an added bonus, wanted to check if the transcription was turned on and if so, at a minimum warn the user that it wasn’t turned on.  Very useful for beta-testing and I myself often forget to turn on transcription.

With some help from zarf and others, what we end up with is pretty useful.

Include (-
[ CheckTranscriptStatus;
#ifdef TARGET_ZCODE;
return ((0-->8) & 1);
#ifnot;
return (gg_scriptstr ~= 0);
#endif;
];
-).

To decide whether currently transcripting: (- CheckTranscriptStatus() -)

ignore-transcript-nag is a truth state that varies.

After reading a command:
	if the player's command matches the regular expression "^<\*\p>":
		if currently transcripting:
			say "Noted.";
		otherwise:
			if ignore-transcript-nag is false:
				say "You've made a comment-style command, but Transcript is off. Type TRANSCRIPT to turn it on, if you wish to make notes.[paragraph break]The long version of this nag will only appear once. You may press any key to continue.";
				wait for any key;
				now ignore-transcript-nag is true;
			else:
				say "(Comment not sent to transcript.)";
		reject the player's command.

What we have is some I6 code that is checking a flag (different depending on zcode vs glulx) that when the user enters a note command, it checks to see if transcription is on and warns the user if it is not.

We can even take it one step further and add this line of code if it is not on:

try switching the story transcript on;

This will prompt the user to turn on transcription and should work in either zcode or glulx.

I seeing more and more that I really need to dive into I6 more to see the possibilities that I may be missing.

Filed under: I7 Code, I7 Gems, Inform 7

Title: Fiasco Author: Jason Morningstar Year: 2009 Price: 12$ pdf, 25$ book+pdf, link Size: 130 pages Genre: black comedy; slapstick; crime Themes: great ambitions and poor impulse control; big dreams and flawed execution; lives that get fucked up by gigantic stupidity Number of players: 3-5 Player roles: no differentiation; everyone plays one character Preparation: none Length of game: 2-3

A new transcript has been posted for The Horrible Pyramid by Ryan Veeder

Gosh, but it’s been a long time since I wrote anything here. The reason for that is I’ve been tied up with inkle: the last post was September ’12, which was about when we started on our Sorcery! series, and that hasn’t really let up. Sorcery!, if you don’t know, is a series of choice-based text-games for touch screens, that’s done pretty well so far. I’ve been working on the design, and also done the adaptation from the original gamebooks to our inklewriter-based format.

But that’s not really what I wanted to write about. What I wanted to write about the type of games we’re now making. They’re not parser games – they use choices – but in terms of design, they’ve ended up being closer to parser games than anything else. In fact, I’ve got a provocative statement to make, which is this.

“Parser games are prototypes of choice-based games.”

This is not quite true, but it’s quite close to something true. I’m now going to try and argue it.

A Matter of Structure

First up, I don’t want to start inventing terms, but I want to talk about the underlying models behind the game, and not just the interface into that model. Our games have explicit choices – but so does everything from Versu to Choice of Games to a traditional book CYOA. But in terms of how these stories are created, these examples form a spectrum from simulation through to state-machine. We’re on that spectrum ourselves, somewhere left of centre.

We don’t use a simulation-ready engine. By which I mean, none of our games have an update loop. There isn’t a single code-path that gets called on every “turn” of the game, so there’s nowhere sensible to update timers or process background events (note: I mean, nowhere in the script. The apps themselves have update loops, obviously).

Instead, we our scripting language is built around a state-machine: a tree of text, with options that branch to other bits of text, and joins that link the story-flow back up again. It’s got a memory: as the player works through, the engine remembers what you chose and alters counters and flags appropriately, and this information is used to alter the text and choices that appear later.

Modelling the World

But the devil is in the data. We use it to model explicit things, that’s straightforward enough – how much health or money do you have, have you learnt a fact about the backstory yet. But we also do a lot more implicit modelling, say friend/foe counters for what characters think of you, and what the game thinks of you, that alter the game appropriately. These are interesting because they are altered not by one decision but by many. Use enough of these hidden switches, and the outcome of any given play-through might become difficult to predict even for its author, though of course, all the outcomes themselves are pre-scripted.

But it doesn’t end there: we also have support for named constants and routines, and those can either be calculations or  - with a bit more infrastructure in the script – sub-sections of story, that are dropped into, played through, and then returned from. That means with a little more work we can start to model the game world. For instance, we can keep track of the time of day, and create a day/night cycle when the hour shifts past dawn or dusk. Characters can move around the map, based on rules and goals which shift, using variables to track where they were last, and what they think they want.

We can then insert new text, options and even little chunks of interactivity into the flow depending on variable-state: adding in options to talk to characters if they happen to be where you are; or different options for manipulating items if they’re in the required state. We can insert the same interactive chunk into multiple places on multiple occasions (using cycles and sequences in the text to prevent the repetition from becoming obvious). At this point, what we’re doing is more like adding responses to standard commands in Inform than anything you could do in a gamebook.

The Design Process

During the construction of Sorcery! 2, and as we move into Sorcery! 3, which is going to be even more open-world-ish – these possibility are starting to mess with my head. The more I write like this, the more I’m turning off the multiple-choice part of my brain, and turning back on the parser-IF design side. The design process of locations, puzzles and interactions is starting to feel more the process behind The Mulldoon Legacy or Make It Good than the process behind games like The Intercept.

Instead of simply writing, laying down choices that endlessly move the story forward, we’re now constructing locations, adding details, altering the description of those details based on state, providing options to manipulate those states, and providing outcomes based on reaching certain states. That is to say: create rooms, with objects, and puzzles.

So that’s to say, our choice-based games are reaching up out of the gutter to approach the fidelity of a parser game. But parser games are still richer, right? They have hidden affordances, moments of inspiration, that sense of infinite freedom…

The Myth of Freedom

Well, don’t they? I started to think that, no, maybe they don’t. I mean, it’s obvious a parser game doesn’t allow you to type anything. But more importantly, the player at the keyboard of a parser game doesn’t act like the game can understand anything either.

A player – at least, one who is capable of playing – approaches the game with a list of relevant verbs, with an eye for useable nouns, and with an ear for the normal interactions of movement, stacking objects, and pushing, pulling and touching things. They learn new verbs if new verbs are introduced, and mostly complain if new verbs are expected but are not introduced. When we play a parser game in that fluid way we enjoy, we are not playing a game of infinite scope or freedom. We’re playing a game of finite choices, we’re just assembling and filtering that list in our heads, instead of the computer doing it for us.

I’ve argued in the past that for parser games to be penetrable to newcomers, we need to improve the input loop and ensure, at the very least that (a) the player cannot type anything the game simply won’t understand, due to incorrect verbs, or typos, or whatever; and (b) any error, clarification or other null-content messages the player invokes should not hang around a moment longer than they are useful. The player’s scroll-back should be a stream of content, positively-reinforcing perfect playthrough.

But while these two things are now both possible – Interactive Parsing does one, Vorple the other – I no longer think they’re enough. Having the game not let me type a command that it won’t understand is a good way to teach me to interact with parsers, but it’s still the game saying “no” to wrong input. Instead, why shouldn’t the game do that filtering of the context for me?

If it did – if it filtered all the possible input down to what’s sensible and interesting, and then presented them as a choice – surely then the game is reinforcing my presence and position in that world, and not detracting from it. In this new game, every action I take is interacting directly with something which has been determined to be interesting, rewarding and worth my attention. I am in a loop of meaningful activity.

 

Building A Choice-Based Parallel

The choice-based games we’re now making at inkle are stabs in this direction: they have simple world-models, but clever contextual recognition: we’ll turn options on when they’re relevant and hide them when they’re not.

If you want the joy of the puzzle where you think to do X with the Y, you can still have it, but as an author you simply need to put X and Y in different places and have your player think of bringing them together: that act is, in itself, enough. You want more detail? Make Y a subelement that the player needs to choose to act on, before being given options of how to act — that’s exactly what your text game player is doing in his head as he constructs his X with Y plan, after all.

You want to replicate that moment in Spider And Web? You can; although, the solution will most likely be brute-forceable now. But how many players brute-forced that moment anyway…?

You want to replicate that moment in Photopia? Harder, perhaps, but you can still have a long choice of verbs… and if the solution isn’t the first the player tries, they’ll still have a moment of  delight when it works…

A Shift Of Default

So, at the very least, a choice-game can start to approximate a parser game, to a less or greater extent. We can maybe agree that.

But what about all the things a choice-game does better? Like forward-momentum, story, and dialogue? Simple cause-and-effect? A variation of scale – interacting over moments one minute, years the next? Make It Good contains 5 characters and took 10 years to write; Sorcery! 2 has about forty and took 6 months. None are quite as complex as the ones in Make It Good, true, but several are really quite complex, and can be goaded, fooled, tricked, bribed, discouraged, and misled, over the course of short-to-medium length interactions.

In a choice-based framework, it is easy to make time pass; it is the natural state of play. And this is where I get my “prototype” statement from. There are things I can do in a parser game which I can basically do in a choice-based game, but there are things I can do in a choice-based game which are virtually impossible in a parser game. So, bar a few edge cases, and specific, unusual effects, the choice-based game with a strong underlying world-model provides for a wider super-class of experiences and narratives.

In general: if we’re comparing a system which has an update loop (parser IF) and a system with a spine (standard choice-based authoring), I think what I’m finding is that it’s far easier to call out to an update loop from the story spine than it is to create a story spine from inside an update loop where the passing of time can only ever be inferred.

Context-Free Actions

In fact, I’d argue there’s only one area that parser games hold high over choice-based structures, and that’s “context-free actions”: actions which are always available, but have little impact on the game-state; such as examining, checking your inventory, or moving around the map. They’re not totally context-free, of course, but in a choice-based game, it’s hard to insert them into the right point in the flow because they can be executed at more or less any moment, and indeed, might need to be.

These verbs open the scope of parser games a little – they let the player break out of the forward flow of the game to gather information from around the world, and across their possessions and what they can see. I think it’s here that the “freedom” of the parser game really lies – not in the commands at all, but in the breadth of objects that can be passively examined at any time.

Still, though; having the main game feed fill up with examinations of items – and often repeated examinations – does seem a little less than perfect. Solutions to that have been tried with multiple windows, showing maps and inventory screens – but these somehow never quite gel, and I suspect it’s because suddenly listing out these options in parallel with the main game starts to make the experience  feel overwhelming. (Something the parser does well is to provide a large possibility space that looks like a small one. In fact, I’d argue the parser does a better job of seeming constrained than it does of feeling open..!)

Leaning on the Interface

So for our games, we’ve cheated. We’ve created an interface layer on top of the game. We have a visual map, because having something to look at helps, and so the player can understand they are moving around. We’ve created inventory screens, and placed Examine buttons on those screens, as well as adding Examine choices into the normal flow at places where it made sense. It’s the multiple window solution – but we’ve made them stack in a rather attractive way, and I think we got away with it.

The resulting balance is, I think, quite effective: and as we set about constructing Sorcery! 3, we’re finding that starting to play out. The new game is being built with a framework of locations, objects and map connections; these fire off calls to update-loop-style routines which do turn-by-turn work, before calling set-piece-like sequences of choice-based flow that carry the meat of each scene. At the end of the scene, we pass flow back to the map layer. The result is a choice-based game which allows free exploration of an environment, object-based puzzles, but which on meeting a character can drop instantly into dialogue-based conversation without a change in interface or tone.

Testing will, no doubt, be a nightmare, just as for a parser game.

And a voice in the back of my head is nagging me to try porting Make It Good. I think it could be done. I fear it would be better.

 

 

 

The next Electronic Literature Organization conference, to take place in Milwaukee on June 19-21, has just extended its deadline for submission to December 15. Media Art Show proposals and abstracts for academic talks are both welcome.

I can’t hardly believe it’s December already.  November was a busy month for me.  Work was really keeping me busy and I don’t see that slowing down a whole lot.   Not as much time on personal project that I would have liked to have spent, but I did manage to make some progress.

At the beginning of the month, having just submitted my work (Jack) to EctoComp, I was anxiously awaiting feedback.   I had some say it was actually a decent work considering the time limit.  Despite perhaps some grammatical issues, it was fairly well implemented for a first release.  Others were turned off by the overt violence that begins to happen half-way through the game and by the lack of an ending.  So I received a mixed bag of feedback, but it was all good advice that I was able to internalize and use to make a future release better and to consider in future works.

It also gave me an incentive to start on expanding and making the work better.  I’ve gone into some of this in my postmortem that I did on the game, but I’ve spent part of the month working on finishing it up and fleshing out the back-story more.  It actually evolved beyond what my initial ideas were so it’s going to take a bit longer to finish it up for a post-comp release.  Also some of you that didn’t like the violence, well….I’m trying to make alternatives paths through the game that are less violent, but the back-story has taken a turn and become a bit dark.  It seems to work in my head, but we shall see how others like it.  Maybe by the end of the year, I’ll put out a release.

Another thing that has begun to take my attention away from Jack, is the New Years comp that was just announced.  I’ve got a few ideas for that, that we’ll see if I can expand into something doable by it’s deadline.

And of course, there’s also the Spring Thing, which I really wanted to to enter, but I’ve not got much done, so I’m not sure I’ll meet that deadline.  I’ve got one work that is about 50% done, but just not sure if I’ll find the time (or want to make the time) to finish that up.

I must say that over the last few months that I’ve gotten back into the IF scene, I’ve met some great people that have helped me along quite a bit.  I know that community support is great and everyone for the most part, whether they criticize or praise your work, they do so in the effort to make it better.

I’m hoping to be able to give back to the community in some way through this blog (as well as hopefully releasing some new games).    I’ve got a few ideas for some series of articles here, that I think might benefit the programming community (at least in regards to Inform 7  and game design) at large as well as myself.  I might kick the idea around with a few individuals first to see if it’s something that would be helpful or not before going into any great detail here.

Well, that was my November and hoping for a productive December.  So go north my friends!

Filed under: Update

It seems as though it’s important, given the changes, to lay out how XYZZY Award eligibility works as clearly as possible. So here are the principles we’re operating under: what exactly are the requirements for a game to be eligible for a XYZZY nomination?

Listed on IFDB.

In 2013, as an experiment, games eligible for the XYZZY Awards will be limited to those with listings on IFDB, the Interactive Fiction Database. Anybody can add listings to IFDB, including authors of a work; this requires a free account.

Exists.

If a game is listed on IFDB, but that listing contains no links to a place where it can be played, downloaded or purchased, it’s not eligible. We don’t require that games be uploaded to the Interactive Fiction Archive, but we strongly recommend it. IFDB already has a problem with games that were only ever available from a single location, and which have since become defunct.

This applies equally to games which were released and have since vanished without trace, games which were never actually published, and games which have incomplete IFDB entries with no links whatsoever.

Released as complete in the appropriate calendar year.

Released’ means that the work is available to the public, whether commercially or otherwise.

‘As complete’ means that it’s not a draft, an open beta, a demo, a 0.X version, an Introcomp release, full of Under Construction signs, or otherwise presented by the author as an unfinished work. (This doesn’t include installments in an ongoing, yet-to-be-finished series; we’re not here to judge narrative completeness. An otherwise complete game that ends with ‘To Be Continued’ is eligible.)

Again, there’s only so far we can go to check this: we can’t play every single game to completion in order to check if it’s really finished. We’ll do this with some games, particularly if there are other signs that may not be a finished version – but we can’t be omniscient, and if you want to be sure that your half-finished game isn’t included in error, it helps to be clear about it.

(If a game is posted to IFDB as incomplete one year, then gets updated to a complete version in a subsequent year, it may be easy for us to miss it. We recommend posting a news item to the game’s IFDB page – or not making IFDB entries for unfinished games.)

Interactive fiction.

This is a troublesome term; what it means is the subject of an ongoing conversation among IF enthusiasts. The organisers of the Awards feel that the XYZZYs should reflect that conversation, rather than attempting to define and police our own answer. However, it’s important not to mistake interactive fiction for a purely descriptive term: in this context, IF is not the set of things that are both fictional and interactive. (That definition would include almost all computer games, and a great deal besides.)

Historically, we used interactive fiction to mean parser-based, primarily-text, single-player games in the Infocom tradition. That term has been extended at various times to its neighbours, particularly text games with link-based interaction (choice games, hypertext novels, CYOA) and graphic adventure. That’s our baseline. We acknowledge that genres aren’t tidy and new forms emerge all the time (and a bloody good thing too), so works that have strong commonalities with those core styles are also likely to be appropriate, particularly if they aren’t part of an established style of game.

From recent usage, there’s a growing sense that ‘interactive fiction’ maps pretty closely to ‘text games’, shifting away from the graphic-adventure sense. (That also needs a bit of clarification, but nowhere near as much.) We’re not quite ready to adopt that sense this year, but that may very well be where we’re going; it would certainly be simpler.

We reserve the right to exclude games from consideration for the XYZZYs if we think they fall far, far outside the community understanding of what ‘interactive fiction’ means. Based on how IFDB is currently used, we don’t expect to use this often, if at all. If we do, we promise to consider it seriously, discuss among organisers, and be transparent about the decision.

A single-loading VIC-20 demo (3583 bytes) presented on November 30, 2013 at Récursion in Montréal. By Nick Montfort, Michael C. Martin, and Patsy Baudoin (nom de nom, mcmartin, baud 1). This video is of the demo running in the Trope Tank at MIT on December 3, 2013.

Tagged on YouTube as Commodore VIC-20, Samuel Beckett, Electronic Literature, Computer (Musical Instrument), and Demoscene. See also the fuller story about Nanowatt with links to executable code.

A new transcript has been posted for Ollie Ollie Oxen Free by Carolyn VanEseltine

There are some things I absolutely must mention at this point, to highlight certain of the many interesting outcomes from NaNoGenMo (National Novel Generation Month):

Alice’s Adventures in the Whale, one of two novels created by Leonard Richardson by computationally replacing all the dialog in one novel with the dialog in another:

Alice was beginning to get very tired of sitting by her sister on the bank, and of having nothing to do: once or twice she had peeped into the book her sister was reading, but it had no pictures or conversations in it, “Can’t sell his head?–What sort of a bamboozingly story is this you are telling me?” thought Alice “Do you pretend to say, landlord, that this harpooneer is actually engaged this blessed Saturday night, or rather Sunday morning, in peddling his head around this town?”

…

Presently she began again. “Ka-la! Koo-loo!” (she was rather glad there WAS no one listening, this time, as it didn’t sound at all the right word) “Stand up, Tashtego!–give it to him!” (and she tried to curtsey as she spoke–fancy CURTSEYING as you’re falling through the air! Do you think you could manage it?) “Stern all!”

…

“My God! Mr. Chace, what is the matter?” said poor Alice, and her eyes filled with tears again as she went on, “we have been stove by a whale.” cried Alice, with a sudden burst of tears, “NARRATIVE OF THE SHIPWRECK OF THE WHALE SHIP ESSEX OF NANTUCKET, WHICH WAS ATTACKED AND FINALLY DESTROYED BY A LARGE SPERM WHALE IN THE PACIFIC OCEAN.”

…

CHAPTER V. Advice from a Caterpillar

The Caterpillar and Alice looked at each other for some time in silence: at last the Caterpillar took the hookah out of its mouth, and addressed her in a languid, sleepy voice.

“I say, pull like god-dam,” said the Caterpillar.

This was not an encouraging opening for a conversation. Alice replied, rather shyly, “There she slides, now! Hurrah for the white-ash breeze! Down with the Yarman! Sail over him!”

Leonard’s other submitted novel used Pride and Prejudice (and Through the Looking Glass). Along similar lines, you may be interested in seeing what Pride and Prejudice looks like without any dialog.

Early in the month, Zarf (Andrew Plotkin) submitted a generated novel that is entirely dialog: Redwreath and Goldstar Have Traveled to Deathsgate.

Ian Renton generated Doctor Who fan fiction using the technique of Bayseian poisoning, which is popular in spam generation. It’s only the only fanficlicious novel; see the generated Austenesque novels of jiko.

I was implicated in inspiring Nif, a palindromic 50,000-word+ novel, the second generated novel submitted (early in the month) by catseye. A remixed and extended version was done by Michael Paulukonis.

Don’t miss Aaron Reed’s Agressive Passive, which details conversation between six housemates about maintaining the cleanliness of their domicile.

And finally, my entry is World Clock, which briefly describes something happening, at some location around the world, at each minute of a day.

The overall “site” for NaNoGenMo, which was the fervent brainchild of Darius Kazemi, is, by the way, this humble GitHub repository.

The Boston IF meetup for December will be Tuesday, December 17, 6:30 pm, MIT room 14N-233.

Well, Ectocomp 2013 is officially over.  Congratulations to Ryan Veeder who took first place with his Horrible Pyramid offering.  Yours truly tied for 9th place with my buddy, Mikey Phipps.

  As others have done, i decided to do a "post-mortem" of my game and here it is.  I'm not really into Voodoo, but I'm into music and I know of the character of Papa Legba through the song and its various incarnations.   Looking into the character, I found he was wrapped up in the "crossroads legend", that is, the legend of one selling one's soul to the wrong buyer.  The crossroads are a proverbial location, not a place one can google-map, and it's there one can meet, some say, The Devil, and others call this being Papa Legba.  This crossroads legend is most associated with the King of the Delta Blues, himself, Robert Johnson.

  Without Robert Johnson, we would have no Jimi Hendrix.  Hell, we wouldn't have modern rock or blues, as we know them, without Robert Johnson.  I would attest to this in a court of law.  Jimi delved into the crossroads myth with a few songs of his, notably Voodoo Child, Voodoo Chile (Slight Return), Here My Train a-Comin', and the one that inspired my Ectocomp 2013 entry the most, Red House.

  In my version, the player is a soldier who seemingly has returned from a tour of duty, only to learn that his lover, Mae, has left him.  The back-story, apparently, is that the player was looking for Papa Legba to try to make things right.  Sure enough, the player summons the otherworldly gentleman, and is offered by him a way to make Mae feel the pain she inflicted upon him.  Here, I've been told more motivation was needed for the player to feel this part better; a critique I cannot take away from anyone, really.

  The player is given tools to accomplish this, as well as direction to leave the crossroads and find Mae's red house.  The tools are a large pin and a Voodoo doll with an opening in it.  Upon taking any direction from the crossroads, the player reaches Mae's abandoned house, finds an item he believes will empower the doll with Mae, but instead, learns an important lesson about revenge, heart-ache, and even death.  I say death because, in my interpretation of the game, the player's character is already dead, having been killed in the war.

  Other complaints I heard included too many guess-the-verbs.  I thought, as we all do, that I had it covered, despite the three-hour time-limit.  But I guess it wasn't as intuitive as I had thought.  If anyone has any transcripts, please let me know!

  Ectocomp 2013 was a lot of fun and I'm excited to hear that another mini-comp, one for the New Year, has begun.  I am planning to submit something for that, so long as it gels together well.  It's an idea I'm taking off the back burner and dusting-off just to have something small to work on.  Currently, I am taking a short hiatus from coding my Spring Thing 2014 entry.  It was getting on my tits.

Thanks for listening!

The Ludorama is a new feature at the Gaming Philosopher where I present a tabletop roleplaying game. The first instalment is about Mars Colony by Tim C. Koppang, a game that I recently had the pleasure of playing online with Remko van der Pluijm. I'll start by giving you the "vital statistics" of the game, and then go on to give a fuller description of the game. Since this is the first

I am happy to report that all the items are placed. Every line in my recipe chart has a "found in" notation! ...I'm telling this out of order.

The first half of the month, I caught up on the implementation that I planned last month. That is, I created the ten new rooms (plus some cabinets) that all of October's placements required. And the navigation between them. And the locks on their doors, where appropriate. And the goal-tracking to open the locks.

In the second half of November, I decided all the placements for the latter half of the game. (Two "chapters", but as I said, the chapter numbers do not reflect either game pacing or numbers of objects.) The map grew another couple of rooms, and several more locked cabinets, but I have not yet implemented these.

You might think that the first half of the month was difficult coding work, and the second half was lazily scribbling in locations on a chart. Ha. No. Code is easy. Decisions are difficult.

Every decision is wading into a hazy cloud of "this will probably be okay" and throwing away 99% of it. Most of the possibilities that I discard are fine. Some look fine, but will trip me up later. I have to make sure that the one I keep doesn't trip me up. And then I have to make sure that I like the pacing -- where it shows up in the player's run-through. Or rather, the range in which it might show up. Too soon? Too much confusion early on? Might the player run into the hard-but-correct solution to a puzzle before the easy-red-herring solution? That would be embarrassing.

And then I do it again, and again. I've been doing it all day. My brain hurts.

(Yeah, I'm writing this on the evening of Dec 1st. Procrastination struck after Thanksgiving. I caught up.)

So, okay. I have (nearly) hit a serious milestone, and I am declaring a (sort of) vacation month. My brain needs to stop hurting for a while.

In December I will implement those last rooms and cabinets, so that I can say I've actually placed everything in the game. But I'm not going to work on HL otherwise. I will do holiday things. I will bake a lot of cookies. I may play the latest Bioshock.

I have a sneaky idea for another iOS text game, which I might try to crank out by the end of the year...

In my real life job as a software developer and manager, I like to do postmortem’s on my projects so I know what I did well (so I can do more of that next time) and what I didn’t do so well (so we can make adjustments for the next project).  I thought this would be handy for my IF works as well.

My first released work was for the EctoComp 2013 competition titled Jack.  I came in 16^th out of 24 with an average score of 5.14 (out of 10).  While perhaps not as high as I had hoped going into it, having played the games above me, I feel it was about where my game should have been.  So I’m happy.

Being a speed IF competition, the rules allowed for 3 hours of work (actual coding / writing) and no more.  It also, while not a strict requirement, had a specific theme to follow…something Halloween.

What I did poorly.

1. I didn’t spend enough time prepping.  One caveat too the 3 hour rule is that we could spend as much time prepping the story beforehand.  As long as no work was done on the computer, no coding nor any writing of dialog in a text editor or anything.  I spent too little time here.  I came up with the idea the night before the deadline and spent an hour or so, laying out a brief story line and a smallish map.  When I started coding the next day, I found myself spending too much time rewriting text and changing implementations of puzzles and actions as I just hadn’t thought it through enough.

   There are many different ideas on planning, Emily Short has a nice article on  her thoughts, but I feel I work better if I have a concrete plan in place first, not that I’m stuck with that plan, but it’s a good guide to work with.  Without that, I can usually work pretty well for a portion of my story, but there comes a time when I run into road blocks.  I have plenty of unfinished / unreleased works that fell in this trap and I find it harder to go back after the fact and fix story or implementation issues.

   Takeaway:  Spend more time in the planning phase. Make sure the story makes sense, make sure there is a clear path from start to finish, put the puzzles (if any) in place in the design phase and know how they work, and have in front of me a blueprint and plan of what I need to work on.  This might sound methodical and not very creative, but the creativeness goes in the planning stage and now we are working on writing code.

2. I was too ambitious.  Not that ambition is a bad thing, but for a speed IF that only gave me three hours to code, I planned too much for my game.  The little planning that I did do for this game, created a map of about 6 rooms.  Not overly large, but because of the time restraint, each room was necessarily sparse.  Also the atmospheric text suffered some.  While I think I did a reasonable job of providing a decent setting, the rooms were not done to my normal level of completeness.  Room descriptions were limited, a few items mentioned were not implemented and the game became very linear.  One other problem I ran into and probably the biggest problem with my game, was the ending.  I was not happy with it at all.  When I was nearing the end, so was the clock.  With little more than about 15 minutes left to go, I still had two rooms to implement to get to the ending that I was trying to setup.  I quickly wrapped those up with nothing more than some quick descriptions and an end-game that just required you to get to the end location.  The ending text also hinted at the story that I was trying to create, but left the reader hanging horribly.
   
   Takeaway:  Know the limitations you are working under, whether a time constraint, game play constraint or perhaps theme restrictions.  Plan accordingly.  I would have rather restricted my map to just a room or two, yet made them much more descriptive and interactive.
3. Not enough testing.  This again, was a problem with the time constraints, but still I could have done better here.  As I started to get feedback, I was dismayed with the amount of spelling errors, grammatical issues and unimplemented (unintentionally) verbs, actions and items.  While I don’t believe there were any major bugs that made the game unwinnable as it exists for the competition, they definitely took away from the immersion into the story.

   In this competition, any time beta testing was included in the 3 hour limit, so there was little I could do.  I did have my son run through it once before I submitted, but he’s not an IF player and found little.  My wife ran through after I had submitted and found a few issues, but those will wait until a second release after the competition is over.  Not sure how much I could have changed with that…but if I take into account my first two points here, then I would have more time for testing.  It did point out the strong need for testing however….when I submitted it, I truly felt it was pretty good with very few problems…and while it was generally OK, and I got some decent remarks, I was still surprised with some of the basic things I missed.

   Takeaway:  If time permits, make sure there is plenty of beta-testing by multiple people if possible.  No matter how good I think it may be, I have to remember I’ve not caught everything.

What I did well.

1. Made sure there was a path from start to finish.  I wanted to be sure that the game couldn’t get into an unwinnable state.  I made every effort to ensure that even if it stayed very linear, there would be no way you could get stuck.  Sure you could die in this game, but you always quickly did so and could recover from it or make an obvious change in direction next time.  Dying in the game, was actually critical to the story as my intention was to have it help to explain the story a bit each time you died.  I may not have achieved that entirely in this initial version, but the groundwork has been laid.
2. Make sure the implementation is solid.  While there are some implementation issues, most are relatively harmless in the sense that it didn’t affect the gameplay.  There is some color text lacking and some scenery items lacking decent descriptions.  There are also some verbs that were not implemented, but they did tend for the most part to be secondary ones that yes add flavor, but not necessary.

   I think I was fairly successful in keeping from causing and “guess the verb” issues.  I did that by keeping my vocabulary simple and make sure that anything that was a bit out of the ordinary, was well hinted at.  Based on a few transcripts and comments I received, I think I did fairly well with that also.

3. Began work on an update right away.  As soon as I submitted the game to the organizer, I began making updates for the post-comp release.  I knew of some things that needed implemented that I hadn’t because I ran out of time.  I went ahead and fixed those.  As I began to received feedback and reviews with suggestions, I began to implement those as well.  I am also planning for an expansion on the story with multiple solutions to puzzles and paths through the game, based on feedback and criticism received.

   I think it was important to start right away while my enthusiasm was high and everything was still fresh in my mind.  I hope to release a version soon after the competition is over that fixes most of the major concerns, with perhaps a third release later that expands on the game in a number of ways.   I hope to find beta-testers for these later releases so I can catch more problems before their released.

Overall, I was happy with the release and the results.  It got me over the hump of actually releasing my work which I hope makes releasing future games easier.  I’m looking forward to seeing some of the comments from the scoring sheets as I’m sure I’ll be able to glean a lot of good information for future games.

 

Filed under: EctoComp 2013, Postmortem

What's it like for someone to discover Eamon for the first time? Jalen Wanderer over at http://comparativecreation.blogspot.com/ has come across Eamon and is considering writing a new adventure for the system. It's an interesting read for those of you who have known Eamon for years and years!

At Récursion (the Montréal demoparty), we (Nick Montfort, Michael C. Martin, and Patsy Baudoin) released Nanowatt, a single-loading VIC-20 demo.

You can download it and run it using a VIC-20 emulator (or, of course, an actual VIC-20). I run it in VICE on my Ubuntu system by typing “xvic nw” from the directory that contains the “nw” file. If it’s more convenient, you can also download a d64 disk image with Nanowatt on it and load “nw” from there.

It produces 8 KB of English text quoted exactly from Samuel Beckett’s second novel, Watt.

And it produces 8 KB of French text quoted exactly from the French translation of Samuel Beckett’s second novel, Watt.

And the entire demo (including two songs, sound system, code for decompression and display of text, and explanations and greetings at the end) is 3.5 KB: 3583 bytes.

When possible, I will upload a video of the demo running.

This rather esoteric demo was awarded 2nd place (out of 3 entries).

I also got 4th place (out of 5) for my one-line BASIC program that was done as a fast demo, based on today’s theme: “weaving.”

Demoscene.

UPDATE: You can run Nanowatt without leaving the comfort of your browser. First, copy this URL into your copy-and-paste buffer: << http://nickm.com/poems/nw >>. Then, go to the page for JS VIC-20. Select the “Storage” menu from the top and choose the option at the bottom of the list, “Carts/Programs,” and choose the top option, “Load Cart from URL.” Finally, paste in the URL that you copied and watch the demo run.

‘NOTHER UPDATE: Video of the demo running on a VIC-20 has been posted.

This is my contribution to NaNoGenMo (National Novel Generation Month), written in about four hours on November 27. (Messing with the typesetting took a bit more time.)

Source code in Python. Requires pytz.

World Clock, the generated novel presented as a 246-page PDF.

As a developer, there is nothing worse than losing all your hard work because of a power failure or a hardware issue or some other catastrophic event.  Your source code is your most valuable asset in any project, it should be treated with such respect.  Source control will save the day and it isn’t as hard as it first may seem.

Even if your just a part-time IF author, source control can be your friend.  You don’t want to lose all your hard work that comes out of your creative mind.

What is source control?

If you already know, skip to the next section.  I’ll be brief here anyways.  A source control system is essentially a repository for your source code.  Why do we want that?  Here’s a few reasons:

1. Protect from hardware / software failures.  If you keep a copy of your source code in a separate folder on your computer, that is a form of source control.  At a minimum this can be valuable if you can do nothing else.  A source control system can add so much more as we’ll see.
2. Keep a history of code edits.  If you use a system instead of just making copies of your code, all good systems now will keep a history of all changes made.  Why is this important?  It gives you a view back in time so that if you decided to go back to a previous version or if you decide you wish you wouldn’t have moved a bit of code, you can easily go back to prior version.
3. Allow for easier collaboration.  A source control system where the repository is in the cloud or on a shared server, allows for multiple developers to work on the same system at the same time.  In the easiest case, each developer may be working on different sections (files) at the same time so when you “check-in” to the repository there is no conflicts between the two developers.  Other times, you can be working on different “branches” of the same code, meaning that the developers will have to merge their code changes together.  Most of the time this is easier than it sounds and is handled somewhat automatically by the system you’re using.

What systems are out there?

There are quite a few systems available, but I’ll just talk about a few that I use most often, GitHub and BitBucket. These both are fairly popular and work very similarly (in fact I believe BitBucket is actually based on the GitHub code base).  The both work with the popular Git source control system and BitBucket supports the Mercurial system.

Both have free options that work perfectly for independent developers.  While GitHub is more widely known and used, BitBucket offers some nice features that make it appealing as an alternative.  For example, BitBucket offers free private repositories where GitHub only offers public ones for free.  If you are working on a new game that you plan to release in a comp and want to keep secret, BitBucket allows you to create a free private repository that isn’t visible in any searches.

Another benefit to both systems are their inclusion of issue tracking system.  This allows you, testers or general public (if allowed) to enter in issues, feature requests, bugs, … that you can track and determine if you want to include the changes in your game.

Collaboration becomes easier with a system.  Other developers that have access to your code repository can create their own branch of your code, make changes and fixes, and push them back where you as the main developer will be able to evaluate and if you approve of them, you can pull those changes into your main code branch.  All this is optional of course, but does make for some nice collaboration opportunities.

So what tools do you need to work with these systems?  Well other than signing up for a free account with whichever service you use (I actually use both), the only real tool that I recommend is TortoiseGit.  This tool simply integrates easily with your windows shell and allows you to work with your chosen service.

There are plenty of tutorials out there on installing TortoiseGit and connecting with Github or Bitbucket, that I won’t bother repeating those here.  But if you run into trouble hooking these up, there is plenty of help available.

Note:  I’m a windows guy, so for the Mac or Linux users out there I know there are tools, but have no recommendations.  If you have something to recommend, please feel free to comment.

Summary

Don’t risk your source code and all your hard work.  I know that writing IF is like any other programming task, it’s a labor of love that combines creativity and technical skills and what comes out is something unique and enjoyable.  Keep that safe.

Extras

Another fun thing to use these services for….do searches on Inform 7 and you’ll find not only other games that you can peruse the code for and learn, but utilities and source for some interesting projects that you may not have otherwise known about.

Filed under: Coding

The first non-beta release of adv3Lite (version 1.0) is now available for download from https://dl.dropboxusercontent.com/u/58348218/adv3Lite/adv3Lite10.zip. There are only a few minor changes from the last beta version (version 0.92), mainly some bug fixes and corrections to the documentation. The change log may be viewed at https://dl.dropboxusercontent.com/u/58348218/adv3Lite/docs/manual/changelog.htm.

Adv3Lite is an alternative (and in some ways easier to use) library for use with TADS 3. For further information see http://users.ox.ac.uk/~manc0049/TADSGuide/adv3Lite.htm.

If you've been considering using TADS 3 but have been put off by the reputed complexity of its library, or you're already using TADS 3 and would like to try out an alternative library, do consider giving adv3Lite a go.

Note that this is likely to be the last release for some time, although adv3Lite will continue to be maintained and bug-fix releases will appear as necessary. At this stage I am not planning any further changes to the feature set, although I am always open to suggestions, particular those that might improve ease of use. While I shall probably resist adding any complicating features to the main library, I may well consider implementing them in the form of additional extensions, should either the level of demand or the nature of the requested features appear to justify it.

Enjoy!

As I’ve recently been struggling a bit with some puzzle design issues (basically my mind is coming up empty on ideas lately), I thought I’d put together some resources that I’ve found that I’ve read (or queued up to read).  I’m sure I’ll add to this over time and I invite you all to offer up suggestions in the comments.

Note this list is more for me to have handy when I need inspiration.

Designing the Puzzle – older article, but the information seems to be very relevant.

Emily Short Puzzles – Emily puts together a nice list of types of puzzles with gaming examples.

Making of Counterfeit Monkey – Emily discusses the making of her game and contains a lot of puzzle design comments.

Coding puzzles – Another article by Emily detailing some concepts of puzzle coding in Inform 7.

Emergent puzzle solutions – OK…one more by Emily sharing some thoughts on a simulationist puzzle design.

Making Better Puzzles – Stephen Granade gives us a simple article on designing better puzzles.

Designing the puzzles of escapade – Great article on how Juhana designed the puzzles in this game.  Great usage of mind-maps.

Puzzles, what are they good for?

This is a nice start to a list.  Please add comments to what you may think is useful.

Filed under: Design, Links

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:

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

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:

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

QDK was still looking rather plain:

The Room and Object editors were now grouped into tabs:

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:

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.

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).

The script editor was very basic:

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.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!

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:

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.

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:

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.

A new transcript has been posted for Robin & Orchid by Ryan Veeder and Emily Boegheim

Thomas Ferguson wrote a 8 Stars ifreview of the game 'Dawn of the Warlock' (W. Clarke; Unknown; Eamon; English; 8 IFReviews.org Stars).

You too can add your own ifreviews, simply register yourself at www.ifreviews.org and share your opinion, with the rest of the IF Community, on this or any other of the 7339 IF games listed.

Thanks for reading the IFReviews.org RSS feed,
RootShell

Thomas Ferguson wrote a 9 Stars ifreview of the game 'The Prism of Shadows' (W. Clarke; Unknown; Eamon; English; 9 IFReviews.org Stars).

You too can add your own ifreviews, simply register yourself at www.ifreviews.org and share your opinion, with the rest of the IF Community, on this or any other of the 7339 IF games listed.

Thanks for reading the IFReviews.org RSS feed,
RootShell

Just thought I’d drop another progress note out about Textfyre’s third soon-to-be-published Interactive Fiction game…

Brady has sifted through and rewritten about 20% of the code and should have the first round-trip with Paul and Chris in a few weeks. He thinks a full code review/rewrite will be completed by the end of the year. I can’t say for sure, but I think this should mean testing will follow in earnest. I’m no fool to be suggesting a release date, but this sort of progress is welcome news.

The Windows 8 Store version of Shadow is still being shrink-wrapped, so to speak. When that’s done, the new Zifmia will follow suit.

(This article includes some spoilers. I’ve hidden them in the text, but this will probably only work if you’re reading on the actual site. If you’re somewhere else, such as Planet-IF or an RSS Reader, you may want to click through to the site and read there — assuming you care about spoilers, of course.)

And finally there was Suspect. Dribbled out into Hitchhiker’s huge wake just as 1984 expired, David Lebling’s first exercise in ludic mystery and Infocom’s fifth title of 1984 still carries with it a certain inevitable air of the anticlimactic. But we always try to give every Infocom game its due around here, and Suspect will be no exception.

If you’ve played Deadline or The Witness, or even just read about them, you have a pretty good idea of what to expect from Suspect. Once again this is a game that you must not so much explore as dissect; must not work your way through linearly from introduction to climax but rather assault from every angle. You can expect to finish it successfully only after dozens of restarts, each of them a little fact-finding mission all its own. Then, when you’ve seen all the pieces, you can fit them together and plan your final mission, at the end of which you will hopefully walk away with a guilty verdict (on someone other than yourself, that is). That’s the ideal, anyway; more likely the first few times you try you’ll find you still don’t quite have enough evidence, and thus it’s back to restarting and looking for more.

Suspect completes a neat trilogy of mystery roles. In Deadline you played the detective investigating a murder; in The Witness a witness to a murder; and in Suspect, yes, the prime suspect in a murder. You play a newspaper reporter who’s invited by Veronica Ashcroft, a Maryland blue blood and old friend from university, to her annual Halloween bash. Soon after your arrival Veronica is found murdered in her office — offices are dangerous places in Infocom mysteries; that’s where the crime in all three of them takes place — with the lariat that goes with your cowboy costume wrapped around her neck. You have to find the real murderer before the detective that comes to investigate and his associate, your old friend Sergeant Duffy, arrest you for the crime.

While Suspect, like The Witness, hews very firmly to the sturdy template laid out by Deadline, it does reflect Infocom’s ever-growing sophistication. There are far more characters to interact with than in the earlier games, and far more to see and do. Indeed, the world of Suspect is in many ways the most complex Infocom had yet created. Every character in the game is constantly moving about the rather expansive grounds of Veronica’s estate, and they mostly react believably to events around them, whether said events are set off by you or someone else. Granted, it is kind of odd that no one seems to care all that much when they learn that Veronica’s just been murdered, to the extent that they just continue enjoying Veronica’s own party despite her unfortunate absence. Then again, exactly this sort of behavior is par for the course in many an Agatha Christie novel, so I suppose we can take it as in the spirit of the genre.

Dave Lebling is generally a deft, elegant writer. He doesn’t entirely let us down here, but he is somewhat hampered by the need to describe so many comings and goings. It can all begin to have something of a mechanistic feel, as if all these characters were models moving about the house on tracks.

>s
Long Hall South
This is almost the southern end of the long north-south hall. A large doorway opens into the southern end of the ballroom. Another door on the west is to a small closet.
Ostmann is off to the east.
Alicia heads off to the east.
Smythe heads off to the north.


>s
Long Hall Begins
Here the front hall and a long north-south hall fronting the ballroom intersect. Another hall starts south of here and goes east.
The Werewolf is to the west, heading toward the east.
Linda is to the west, heading toward the east.
Smythe is to the north, heading toward the south.


In his defense, Suspect is hardly alone among Infocom’s mysteries in having this wind-up-toy feel about it. The very depth of the simulation tends to cut against their literary sensibilities.

Still, Suspect also has room for whimsy. Lebling gifts us with more Easter eggs and in-jokes than any game this side of Sorcerer. Shout-outs for hardcore fans are everywhere. One of the party-goers is dressed as a “short, cuddly-looking robot”; another is a grue; moving a rug aside gets you “Under the rug you see a wooden trap door… No, sorry! That’s another story.” Indeed, the more superficial elements are some of the most entertaining. The game is a little time capsule of yuppie life in the early 1980s, from the BMW 320i in the garage to “Karma Chameleon” playing in the ballroom.

The charm extends to the feelies, the main exhibit of which is a little Miss Manners-style guidebook called Murder and Modern Manners. The humor therein bites a bit more sharply than was the norm for Infocom, with at least one paragraph that qualifies as genuine satire, on the subject of “Prison Projects”:

Poetry can be a wonderfully sensitive medium for expressing your remorse and anguish. The study of law will help you improve your oratory skills, a clear benefit when you make vehement pleas to the prison parole board. Writing books can also be quite rewarding: the first eight editions of this book were all highly successful and sold particularly well among guilt-ridden liberals. But perhaps the wisest choice is painting. Prisoners are perceived as having great depths of repressed artistic genius. There are literally thousands of deep-pocketed dilettantes who are willing to pay a fortune for prison art. Especially if the work is being done by prisoners with a background of violent crime.

Infocom and G/R Copy were able to enlist a name artist with a long history in high and commercial art, Alan E. Cober, to illustrate the box and the booklet in his distinctively spare, modern style. The economic woes that would beset the company very soon after Suspect would make such prestigious collaborators a thing of the past.

The actual mystery at the heart of it all is intriguing, if also damnably difficult to crack. Suspect is in fact the second very tough Infocom game in a row, following seven very solvable titles between Suspended and Hitchhiker’s. (Hitchhiker’s and Suspect together are almost enough to make me revise my premise that Infocom games trended generally easier as the company grew older.) When you put together the clues which are laced very subtly through the text and the storyworld to divine who’s responsible and how he, she, or they committed the crime, it’s a wonderful moment. Unfortunately, that’s just the first step. Actually proving what you know to the detective’s satisfaction is something else, a task made even more difficult by a lack of feedback; you never really know how close you actually are or which bits and pieces you’ve presented to the detective are actually important. It’s particularly difficult to figure out that you need to monitor one absolutely vital thing, the changes in the weather (highlight the preceding to reveal), and hard to know how to ply the detective with that information afterword. In spite of it all, I almost managed to solve the murder in my recent playthrough, aided no doubt by vague memories from years ago. I just neglected to do one key thing and therefore was short one key clue. I “EXAMINE”d Veronica’s party mask, but never “SEARCH”ed it. If this strikes you as rather a cheap move on the game’s part, I can’t say I disagree.

The final solution to the case doesn’t hang together quite as tightly as I’d like it to, a problem Suspect oddly shares with both of the mysteries that preceded it. I kept trying to find a good reason for Alicia to help Michael murder his wife; as the game itself says if you attempt to arrest her alone, she didn’t have any motive. I naturally suspected an affair between Michael and Alicia, but could find no evidence of this beyond seeing them dancing together briefly in the ballroom. Just as happened with both Deadline and The Witness, I was rather shocked when I secured a conviction. I thought there must still be more to discover.

Suspect would turn out to mark the end of the line for Infocom’s original, hardcore take on the interactive mystery novel. While they would continue to dabble in mystery, the later games would play more like conventional adventure games. It’s hard to say why a form that caused such excitement back when Deadline first appeared should peter out so relatively quietly. Certainly it’s clear that a significant number of Infocom fans, both then and now, dislike the form of play of the early mysteries intensely, even if enough enjoyed the format — or just let brand loyalty overcome their misgivings — to generate for Suspect fairly typical sales numbers for its period, just shy of 50,000 copies. But there was also perhaps something else: a feeling that, having invented the format with Deadline, Infocom didn’t quite know how to advance it. For all its additional polish, there’s nothing really new that Suspect brings to the table. It would be unfair to say it feels stale precisely, but it shares enough with its predecessors that it can feel a bit anonymous in their company. Suspect is certainly the least loved and least remembered of the three today. Of course, Infocom might have tried to shake up the approach with a hypothetical next game instead of abandoning it; just having the victim not be a blue blood and not die in her office would make a good start. But being as they never did, we’re left with a trilogy of games almost unique in adventuring history, and one which even comes with an overarching thematic progression. The only other role left for the player to enact was that of victim — and I’m not sure how Infocom could have managed that. Maybe by putting the whole format out of its misery, as they did.

An inevitable footnote to any discussion of Suspect must be the gala that Infocom held to promote it at the January 1985 CES. It was by far the largest party the company ever gave, yet another marker of the high-water point this period represents. They invited some 5000 people to the Hartland Mansion in Las Vegas, formerly one of Elvis Presley’s homes, for what must be the largest game of How to Host a Murder ever played. Customized letter openers, previously mailed to invitees, served for tickets as well as party favors; these are today one of the most cherished of all pieces of Infocom memorabilia. One of these also became the murder weapon, in a crime staged by an acting troupe in front of the crowds gathered in the mansion’s ballroom around a huge indoor pool. The next day’s Las Vegas Sun bore the headline “Murder Rocks CES!,” with the important detail that it was all just pretend hidden below the fold. It seemed like great publicity — until it prompted authorities to investigate, whereupon they determined that the house had not been zoned for hosting a public event of such a magnitude. Infocom was forced to return to Las Vegas to testify in court, but thankfully the owners of the house bore the brunt of the pain. Not as sexy as murder, perhaps, but such is life in the real world.

(As usual at this time of year, The Digital Antiquarian will be taking a little hiatus while my wife and I travel back to the good old U.S.A. for Thanksgiving with my friends and family. Will be back at it in two to three weeks, at which time we’ll shift back over to Britain to look at 1984 there. I’ll see you guys then.)