ISSUE #52 -- July 29, 2008

SPAG
The Society for the Promotion of Adventure Games

ISSUE #52

Edited by Jimmy Maher
July 29, 2008

SPAG #52 is copyright (c) 2008 by Jimmy Maher.
Authors of reviews and articles retain the rights to their contributions.

All email addresses are spamblocked -- replace the name of our magazine with the traditional 'at' sign.

IN THIS ISSUE

Editorial
IF News

A Blind Man's Take on Interactive Fiction by Ari Damoulakis
Works of Wisdom: A Comparison of Nate Cull's "Planner" and Aaron Reed's "Intelligent Hinting" by Ron Newcomb

An Interview with Mike Rubin

Reviews
    An Act of Murder
    Child's Play
    Deadline Enchanter
    A Fine Day for Reaping
    Ghost Town
    Gun Mute
    Hors Catégorie
    Lost Pig
    Suveh Nux
    Treasures of a Slaver's Kingdom
    Varkana

SPAG Specifics
    Metamorphoses

EDITORIAL

I recently attended the Electronic Literature Organization's convention in beautiful Vancouver, Washington. For those of you not familiar with the ELO, its stated goal is to "facilitate the writing, publishing, and reading of literature in electronic media." Definitions like this, however, seldom bring much sense of an organization's real orientation. The ELO has historically tended to focus its attention on less narrative-oriented forms of electronic writing: e-poetry, collaborative writing projects, hypertext "fiction," etc. (I put the "fiction" in hypertext fiction in quotes because I find that most works in this genre are not really about assembling a coherent narrative at all.) Of late, however, IF has taken a place under the ELO's umbrella, thanks largely to the tireless efforts of Nick Montfort to academically legitamize the still vaguely disrespectable form we've chosen to work in. Granted, it still often feels in the ELO like there are the IF people and then there is everybody else, but at least we are represented.

Plenty of insightful papers and interesting artworks were presented, on IF and other topics, but there was one thing about the conference, and about the ELO mode of discourse in general, that bothers me: an obsession with form rather than content. It's a problem that's not unique to the admittedly hyper-academic atmosphere of the ELO. We do the same thing within our own (culturally very different) community, and it also disturbs me here at times. I sometimes think we are getting ourselves so caught up in technical and mechanistic minutiae that we are losing sight of why we might want to be writing IF in the first place. Let me try to illustrate with a couple of examples.

First, let me pick on one of the IF works that was presented at the conference: Hors Catégorie by Chris Calabro and David Benin. I'm not going to discuss its merits and problems as a work of IF; Victor Gijsbers does a very good job of that elsewhere in this issue. Rather, I want to look briefly at how the authors describes their own work in their game's byline.

The subject of Hors Catégorie is the use of blood-doping and other artificial enhancements that have caused such controversy in the sporting world in recent years. The game casts its player as a cyclist competing in the Tour de France and facing a decision -- you can probably guess what sort of decision. It's a strong subject for a work of literature: complex, resistent to black or white thinking, and of real interest and importance for our times. How then do the game's authors describe their game in their own byline? "An experiment in affective, embodied interactive fiction." Now, this is of course problematic on more than one level. It is first of all simply bad writing with an unfortunate air of disingenuousness to it, for as a phrase it is essentially meaningless, the sort of argument from obscurity that infects so many in academia. Moving past that, though, I wonder why the authors chose, after having chosen a really quite compelling subject for their work, to essentially ignore that subject and describe their game (or, I suppose, not describe their game) in terms of vague formal abstractions. Even had they been meaningful abstractions, the problems would remain. This was its most important aspect in their eyes?

Let's consider one of the played, respected, and oft-written about works of modern IF: Emily Short's Galatea. In all of the reviews and and other discussions of the game you can find on the Internet and in printed academic literature, you will be hard pressed to find much commentary on the content of the piece. Writers rather talk about the piece's technical complexity, about how well (or how poorly) the conversation flows in response to the player's inputs, etc. Cool intellectual responses dominate the discussion, with the exception of the occasional off-the-wall commentary such as the IFDB reviewer who considers Galatea to reflect "modern man-hating female disparagement." Galatea excites admiration, interest, even a certain amount of awe, and all of it richly deserved. However, it seems to excite very little love. Nor does it seem to inspire its player to grapple with anything more universal than the design of good IF conversation systems.

Is this a problem? Not really, I think, when taken in isolation. I think that Emily Short, whom I have immense respect for as a writer, creator, and tireless agent for positive change in IF, intended her work as an experiment and even possibly a bit of a provocation, an illustration of what might be possible. But where is the game that takes Galatea's formal and technical innovations and uses them in the service of crackerjack story with a fascinating setting and compelling, believable characters? Eric Eve's recent works come close, but how many others do? Galatea sits out there in splendid isolation. People play it, they tell themselves and each other how interesting it was, what potential for IF it demonstrates, and then they move on. It's not up to Emily to build on Galatea's foundation; if she retires from IF tomorrow, she's done more for the form than I or 99% of you will ever manage. It's up to us. Where are we?

Some of us who are very, very good are writing games like the generally acknowledged best game of 2007: Lost Pig. On the one hand, Lost Pig is nothing to disparage. It's hilarious; it's great fun; it's honed and polished to the most beautiful shine. Admiral Jota deserves tons of praise and respect for his creation. And yet, on the other hand, it disturbs me just a bit that, after twelve months and dozens if not hundreds of game releases, a game about a cartoon-style orc with pidgin English skills trying to recover a pig was the pinnancle of our achievements. Best comedy (if such a category existed)? Sure. Best game? That concerns me a bit. It's not that the XYZZY voters were wrong. Lost Pig probably was the best game of 2007. But why was it the best game? Where are the IF games that, to paraphrase a famous old Electronic Arts ad, make us cry?

We can work to make our parsers more newbie-friendly. We can make IF more accessible through web-based interpreters like Parchment. We can put a more attractive face on the genre through projects like the cover art drive. We can do outreach to casual game portals like Jay is Games. All of these things are great, and hugely helpful. I applaud everyone who has worked on these projects and others. But most of all we need games that will make us cry, or that will just keep us up late at night playing because we can't wait to find out what's going to happen next. And to get those kind of games we need authors who are willing to cut themselves loose from both the ironic, deconstructed, postmodern aesthetic that is the hallmark of academic art and from the elevation of craft and accessibility above all us that is the hallmark of gems like Lost Pig and put it all out there -- to tell the best damn story they have in them, or that they can find and adapt; and to do it in the most compelling, immersive way possible.

Photopia made at least some of us cry. And while the academics talk about Galatea, the general public, that vanishingly small percentage of them who have ever played IF, talk about Photopia because it's about something other than itself. It made them feel something, and in doing so gave us a glimpse of the potential of this new immersive form of reading, even as it was hobbled by its linear structure and rather over-sentimentalized plot. What if we could marry the technical and formal innovations of Galatea with the storytelling force of Photopia? What if we could create a work of technically sophisticated IF that was about something beyond its own technical sophistication? What would we have then? I think we might just have, at long last, literature.

Back to Table of Contents

IF NEWS

Planet IF
Now this is the sort of cool little idea that comes along every once in a while and leaves the rest of us wondering why no one thought of it before. Christopher Armstrong's Planet IF is an RSS feed aggregator that brings together many blogs and news sites that discuss IF. With IF discussion increasingly moving from the newsgroups to blogs and other scattered locales around the Internet, this is a great way to bind us all together. Check it out, and if you run a blog or website that deals with IF please think about setting up an RSS feed (if you don't have one already) and contacting Christopher to add you to his collection. SPAG will be on there soon, I promise.

Art Show 2008
Marnie Parker has had to postpone this year's IF Art Show due to other personal obligations. She does plan / hope to run it toward the end of the year, however.

Spring Thing 2008
Greg Boettcher's Spring Thing competition for longer works of IF is complete. All three games were quite well-received and finished very close together, but the winner was Pascal's Wager by Doug Egan.

Macrocosm
Macrocosm, a quite ambitious-looking piece of multimedia IF written in TADS, was recently released by its author after four years in development.

Parchment
Atul Varma has developed a Z-Machine interpreter that allows you to play games directly through your browser. He has also provided a website that gives access through Parchment to every Z-Code file in the IF Archive. The interpreter is a little slower than I'd like, particulary with Inform 7 games, but otherwise works a treat. Now we just need something like this for Glulx... oh, yes, Andrew Plotkin is working on that, or at least on a browser-based GLK implementation, which is the first step.

Web Adventures
Web-based IF seems to be all the rage these days. Andrew Whaley has also put together a site for playing some popular recent and classic IF titles directly through your browser. You don't even need Javascript enabled. Unfortunately, the presentation still seems a little wonky on at least some browsers -- I somehow ended up with three separate status lines on my screen -- but hopefully Andrew will get things smoothed out over time.

War Mage
Giancarlo Niccolai has released an English translation of his Italian IF/RPG War Mage, which he discussed at some length in SPAG's last issue.

IF Competition 2008
The big daddy of all the comps will of course be taking place again this fall, ably administered as always by Stephen Granade. You must submit your intent to enter by September 1, and submit your completed entry by September 30. The six-week judging period will begin immediately thereafter.

FyreVM
Textfyre, David Cornelson's commercial IF startup, has released its C# implementation of the Glulx virtual machine as shared source. FyreVM allows programmers to easily design a customized user interface for IF in a way I don't entirely understand. Nor do I understand all this business about channels. If you are smarter or at least more persistent than me, however, you can even enter a contest to design a customized interpreter using the FyreVM. Entries must be submitted to David by the end of the year, and the top three will each win $200.

IntroComp 2008
Jacqueline A. Lott will be running another edition of her competition for introductions to proposed longer games. The intent to enter deadline was July 20, but everyone can play the intros, score them, and offer feedback to their authors beginning on August 20.

Club Floyd
Jacqueline has also been hosting a weekly cooperative playthrough of a work of IF on the IF MUD. Contact Jacqueline at jacqueline.a.lott SP@G gmail.com, or just drop by the IF MUD, for information about times, schedules of future games, etc.

Page 6 Reviews
Back in the day, Garry Francis wrote a series of reviews of adventure games for the Australian Atari magazine Page 6. These reviews, along with the rest of the magazine's contents, have now been placed online. Garry's reviews are surprisingly well-written and thoughtful in comparison with the general standards of the era, and well worth perusing for a little dose of nostalgia.

Back to Table of Contents

A Blind Man's Take on Interactive Fiction
by Ari Damoulakis

You are standing in a crowded bar. There are many tables in front of you. On one is a can of beer and a half-eaten packet of crisps. Against the wall there is a pinball table. The bar counter is to your right, and there are men and women sitting at the counter on high chairs talking.

This description seems just like another description of an interactive fiction game. This description also seems like an everyday scene that any person can see when they walk into a bar… but that is what makes interactive fiction so special to me: I am a blind person.

My name is Ari, and I am a student from South Africa. I am writing this piece in praise of interactive fiction and text descriptions. As a blind person, there is just so much detail that I miss out on as I go through life if it is not described to me, or if I don’t know that something is there. I have been totally blind since birth, yet I have an artistic streak in me that really loves things, scenes, rooms and people being described to me. I am also curious and interested in people -- their everyday lives, problems, challenges, what they do and why -- and I reckon that if I were able to see, I would have been one of those photographers who sees an ordinary scene or room, but are still so fascinated by it that they take a picture.

Most gaming opens worlds for people. Interacting with characters and role-playing a career or life that they do not have in the real world allows people to imagine themselves in certain situations, or challenges the person to make certain decisions. It is that aspect of gaming, along with the writing, descriptions of scenes and the possibility of interacting with characters that make interactive fiction so special. As a blind person, most mainstream role-playing games are unplayable. Interactive fiction is then the bridge that allows me as a blind person, who also would like to participate in the joys of relaxing with a role-playing computer game, to step into an imaginary world.

Even leaving aside the descriptive writing or the imaginary world, I enjoy the challenge of sitting in front of my laptop, on a cold and rainy evening, trying to solve the wonderful puzzles! I love one-room games, or games set in a house, which pose the challenge of getting out of a room, or of examining a few rooms, trying to get out of, or solving the mystery of that place. Examples would be Coming Out of the Closet, Humbug, Puzzle In Box, King Arthur’s Night Out and Bugged. I also enjoy games which are set in the real world, and which are based on situations which are likely to occur in the real world, such as Stranded, Tube Trouble, Gourmet or Gumshoe. Because I’m unfortunately too much of a realist, I am not a fan of games which contain fantasy or concepts which do not occur in our world, such as magic, magical creatures, or fantasy worlds, however, many blind people do enjoy those type of games.

How does a blind person play interactive fiction, and what is the state of accessibility for interactive fiction? We as blind people use screen reading programs, which read the text of a computer screen back to us. Ideal for interactive fiction! As long as the interpreter is written well, there is no barrier that stops us from accessing games in the Windows environment. It is unfortunately quite disheartening, however, to see that many authors are incorporating and including graphics that are crucial to solving the plots of their games. An example of this would be the Quest game, The Last Resort. The description of this game seemed very delightful, coupled with the fact that there were even sounds, but unfortunately the author had incorporated graphical clues which needed to be understood in order to solve some puzzles, which was quite a blow for me.

I am trying to learn how to write in either Alan or Adrift, so that, in the future, I will also be able to release some games as well. I think IF is a wonderful resource for artistically-minded blind people to sketch situations and paint wonderful ideas. A blind person who learns to write IF will have a wonderful paint brush or camera!

To the authors of Interactive Fiction, I would like to say this: thanks for not letting the newer, flashier style of gaming put you off from keeping the wonderful pastime of text-based IF alive, even though a single descriptive photo or picture does say more than 1000 words, and it is easier and quicker to deduce details. Thanks for the wonderful puzzles which carry on trying to twist and smash my brain, and, above all, thanks for the brilliant descriptive writing which you use that opens up so many worlds, scenarios, locations and events. Interactive fiction has taught me not to just concentrate on the “larger” description of things, but has also trained me to take an interest in and ask people about finer details when someone describes places or objects to me, even in real life. (Unfortunately that is probably irritating to the person doing the describing -- "Why on earth does Ari also want to know if there are pictures on the walls, what they are of, and even the expressions of the people in the pictures! I’m getting sick of him asking me all these questions!") One of my friends who does English literature, did once remark to me that she really enjoys describing things to me, as this gives her chances to use words which she hardly ever uses in real life, and it also helps her in writing, since she has learnt to write in greater descriptive detail for her readers.

Please keep the passion for IF!

(Feel free to email Ari at aridamoulakis SP@G gmail.com with your comments.)

Back to Table of Contents

Works of Wisdom: A Comparison of Nate Cull's "Planner" and Aaron Reed's "Intelligent Hinting"
by Ron Newcomb

A comparison between a hinting system to a NPC goal-planner may seem as fruitful as comparing the proverbial apples to oranges. But these two extensions cover the identical ground of artificial intelligence, the capacity of a computer to perform operations analogous to human decision making. Both extensions are complex, but that complexity lies in the AI itself, not in how our games use the information. What is done with the result of that decision making is a trivial difference: Hinting says the resultant action; Planner does it. In this article we shall score these extensions against one another on several features. But first, let's introduce our contestants.

Nate Cull's Reactive Agent Planner is a cross-platform AI found on various versions of Inform and TADS. Not all ports of it were necessarily done by Cull alone -- the original was heavily based on academic papers from the Oz project, and the TADS3 port was done entirely by Steve Breslin. Software with such a multi-author and multi-platform history usually possess benefits of maturity, polish, and reliability since the code base has been worked and re-worked many times over. The Inform 7 port alone is two years old, nearly as old as Inform 7 itself.

The new kid on the block, Aaron Reed's Intelligent Hinting, was recently released in May of this year. Created to encourage beginner-friendly works by promoting itself as author-friendly to use, it underwent a brief online peer review before its release. Its youth is not necessarily a disadvantage, however. Inform 7 is still in beta, and since Planner's release Inform has added many new features which Hinting uses to good effect.

Which is easier to use? Which is more powerful? How nimble is each in fulfilling the other's role? And how do we decide between the two, if we want both functionalities for the price of one? Let's find out.

--- Surface Issues ---

Terminology

As each extension was conceived for a specific purpose, their respective terminologies differ accordingly. But the concepts map onto each other nearly one-to-one, and so their terms do as well. Planner uses the apparently plain language of the Oz project with the point of view being the character's: goals are achieved by one or more plans. Hinting uses the language of game puzzles, so the point of view is the author's -- puzzles are solved by one or more tasks.

Though either work, our deciding factor is in the details of the code. Planner has a slew of hyphenated names for essential rulebooks and objects, all of which begin with "planning-". While many realms of computerdom demand naming conventions, they are out of place in a naturalesque language where a name can be more than one word.

And so, our first point goes to Hinting.

Documentation and Examples

Reed went to some lengths to document Hinting, including a handful of examples, and specifically shows how two known works would be adorned with hints. He further separates all of the Hinting-specific code from the game's code to emphasize exactly what must be done to enhance an existing work. Again, if understanding leads to more understanding, expanding upon two already-known works with a strict division between the new and old code is a valuable aid.

Planner has a much longer history than Hinting, and has more written about it over the course of that history. However, you wouldn't know it by its Inform 7 documentation, which reads like a list of caveats followed by a history lesson. This is a cardinal sin with esoteric pieces of code such as AI, and doubly so as much documentation exists for RAP on other platforms, including an amusing and very well written Wonderland-themed introduction with earlier ports.

By all rights, Planner had the advantage here. It did not exploit it. Point: Hinting.

Narrative hooks

Good authors will customize the output of any extension with their own prose. How is this done with each, and how flexible is it?

Hinting uses a simple table of default responses which can be amended via the kind-of-value in the first column. Planner uses a slew of initially empty rulebooks which allows different characters to describe a variety of situations. Planner's rulebook approach is far more flexible than Hinting's table approach, but it has no default responses. This can baffle authors new to Planner. Ultimately, each extension uses the appropriate method for its own narrow task, and even Hinting's method can be slightly expanded by calling rulebooks through a say phrase.

The tie-breaker comes in the form of the character -- PC or NPC -- who thinks out loud. Such noisy characters tend to exist in half-completed works still undergoing testing. Though both extensions have some debugging support, it is primarily intended for debugging the extension itself, not the enclosing game, and we don't wish to confuse the two. And while both extensions also use To phrases extensively, Planner uses a pair of rulebooks -- "planning" and "planning-testing" -- to recursively solve problems. Since To phrases cannot be modified and rulebooks can, our babbling oracle can only be implemented in Planner.

Point: A tough call, as Planner lacks default replies while Hinting lacks that last obscure ability. But Planner's issue is essentially being a little too ready to accept customized prose, while Hinting's issue is impossible to overcome. This point goes to Planner.

--- Encoding Desire ---

Representing a Desire

An AI must know what is wanted before it can reason out the steps to get there. How does each extension represent this?

Planner requires a Goal to be stated as an object-relation-object triad, such as the cat, the bag, and the containment relation. But Planner immediately hits a limitation here: relations cannot be put into tables, nor passed to To phrases, nor even put into global variables. Planner circumvents this by creating a stand-in object for every existing relation, called a planning-relation, and uses these exclusively. This has two drawbacks. First, it burdens authors with creating stand-ins for each of their new relations. And second, for all Planner talks of them, it doesn't actually use relations itself. This is misleading, and is one of the larger barriers to learning Planner.

Hinting too uses objects connected by a relation, but the relation is always the same, the Requires relation. Instead, it is the objects that have stand-ins. These objects, called Puzzles, must also be created by the author. Like planning-relations, Puzzle objects are little more than a name that can be attached to things. In this case, to Task objects and other puzzle objects.

Point: Neither. Although Hinting won the terminology award here, a surfeit of vacuous objects is always an annoyance. Hinting needs to shave down the number of concepts, while Planner needs to rethink its implementation or at least how it is described.

Striving Toward a Desire

The core aspect of an AI is how to specify, step by step, how to get to where it wants to be. How does each extension represent how to do what needs be done? Both Planner and Hinting use a rulebook -- "planning" and "requirements", respectively -- that enumerate the necessary actions to accomplish the given desire:

	Planning when the desired relation is being-in and the desired param1
is broth and the desired param2 is the pot:
	plan 1;
	suggest being-in with the onion and the pot;
	suggest being-in with the celery and the pot;

	Requirements for Slaying-The-Gorgon: 
	do the action of the person asked closing eyes; 
	do the action of the person asked showing the mirror to Medusa.

Both seem straightforward: given a simple desire, list the steps to finish it. However, there's something else going on here with Hinting. The requirements rulebook never takes a Puzzle as its input; it takes an intermediate kind of object, the Task. Tasks are the real workhorse of Hinting. They remember the individual steps to accomplish something, they can be marked as complete or incomplete using the Definition syntax exactly as Puzzles are. Indeed, they can do nearly anything Puzzles can, which leads one to ask -- why the extra object kind?

Additionally, the requirements rulebook is only ran when play begins. If some actions are conditional on time (such as a Scene) or state (such as Darkness), the if statement can't be placed on the do phrase like it can on Planner's suggest phrase. Hinting states it must go into yet another place, the Red Flag rulebook. This introduces another extraneous concept to Hinting which Planner does not have, and AI is complicated enough.

Point: Planner.

Evaluating a Desire

How does a work know when the desire is attained? Are we there yet? Are we there yet? This is a question that a work must ask itself from time to time, and many different Inform features can be used to implement it. At its simplest, any condition that fits between if and then will do the job, but Inform doesn't support conditions as stand-alone entities. So, Planner uses a rule in the planning-testing rulebook, predicated on the two objects and the relation stand-in, and the body of the rule has the if-then statement. Hinting precedes that same if-then statement with an adjective definition, "Definition: the (specific Puzzle object) is complete if...".

Point: Hinting, hands down. Less is more here: Hinting's definition method requires less author typing, less computer memory, and less of the player's time to execute, and furthermore does so with no loss in flexibility.

--- Flexibility ---

Eating the other's lunch

Once a particular action is found to be necessary by an AI, how easily does it pass to the enclosing game the option of what to do with that action? In other words, how easy is it to make Planner hint and Hinting plan?

Planner was created before Inform supported Stored Actions, so, much like relations, actions have stand-in objects, of kind "planning-action". When Planner has finally found the best next action, it gives that stand-in to the "planning-acting" rulebook, which contains the actual Try statements. Given this setup, it's relatively easy to create a First Planning-action Rule that speaks rather than does.

Hinting uses Stored Actions, so merely prints or invokes one as necessary. Unfortunately, a stored action cannot be edited; we cannot change the actor part of a stored action to someone else, and Hinting internally describes actions with "the action of" instead of "the action of the person asked", so there's rigidity here that cannot be easily overcome.

Point: Planner. Planner's generalized method works though it is unnecesarily complicated -- many other things would work better as an action stand-in than more oddly-named objects, and some of them are easier to update as we create new actions. Hinting's method is rigid to the point of disallowing games with multiple PCs, or utilizing new actions in its reasoning at all.

Accidental ignorance

There comes a time in every AI's problem domain when it just can't find an answer. A new author isn't experienced enough with coding to tie up all the loose ends; a PC or NPC has been put into an unwinnable state either purposefully or accidentally; and not even a hint system knows everything while a work is still being written and tested. How well does each extension handle failure, either during testing or during an actual game?

Planner makes an art of it, dividing failure into two kinds: one when the only conceivable actions are blocked by Check rules (planning-acting-failure), and one in which no actions can even be conceived by the AI (planning-failure), possibly indicating a hole in implementation.

By contrast, Hinting's position on unintended stuckness can be summed up in a word: Inconceivable! Consequently, when presented with such a situation during a game, it falls over dead. While we can change Hinting's last words, there's very little in the way of leftover variables or other information for a postmortem to diagnose what happened. Attempting to construct the hints and a game simutaneously will quickly send the author to the routines used for debugging the extension itself.

Point: Planner.

Intentional ignorance

Dealing with mis-information, NPC ignorance, and unreliable narrators is not a trivial matter, and neither extension attempts it. Arguably, Hinting may make the claim that, being a voice from outside the world, should not deal with this problem. However, in a game with multiple PCs, they may differ in their knowledge and abilities, so Hinting would need to tailor hints to each PC's abilities. Related to this, an author may decide that hints come instead from a semi-reliable sidekick who only knows so much. Hinting has no provision for either.

Similarly, Planner has no provision for an NPC's imperfect knowledge. This is more grevious in Planner than Hinting, though Planner's rulebook-based approach makes this easier to add such features.

While both extensions may be modified to add this ability, it is not obvious where to do so, and neither documents how to begin such an undertaking.

Point: Neither.

--- And Finally ---

Ease of use

Let's assume we're already familiar with a given extension from our recent heartbreaking work of staggering genius. How quickly can we throw something new together? That depends largely on what we're trying to do of course, but we already addressed flexibility. And terminology and documentation won't be a problem (or benefit) because we're already accustomed to our chosen extension. Rather, this point goes to whichever extension does its own job with the least amount of fuss.

Planner has no default messages, and even its basic functionality is extracted to another file, Basic Plans. Furthermore, it requires a great deal more typing for most everything. Conversely, Hinting already knows one goal our character has -- winning the game. A few names, a few relations connecting them to Winning, and we are good to go.

Point: Hinting.

--- Conclusions ---

First, let's tally our scores.

To Hinting, four points: Terminology, Docs & Examples, Evaluating a Desire, and Ease of Use.

To Planner, four points: Narrative Hooks, Striving Toward a Desire, Eating the Other's Lunch, and Accidental Ignorance.

And two unawarded points: Representing a Desire and Intentional Ignorance.

The overall results probably won't surprise anyone who has tried to use each. Intelligent Hinting is more polished and ready-to-use, albeit only for those specific kinds of works that fit its mold. Planner is far more flexible and powerful, but has a serious image problem. Planner can easily implement Hinting if it chooses to, but Hinting can't quite say the same.

If the heart of AI is to represent, attain, and evaluate fulfillment of a particular desire, it's an interesting observation that neither extension came away a winner here. This is not a knock against their respective authors. Software that can introspect asks a lot from the programming language in which it is written, and much like a wire cheese slicer will expand the faint line it leaves in a block of cheddar, into a chasm long after it has passed, a language's small exclusion grows into colonies of stand-in objects, work-arounds, and other hyphenated words. The rewards are promising, if distant and hard to see: hint systems that track and assist hapless players, easier creation of new implicit actions, auto-created lists of a game's required commands, and NPCs whose believability improves through the player's agency, not in spite of it.

All it requires is a little work, and a little wisdom.

Each extension has at least one example that comes with its documentation. Below, each of those examples has a little code added so that the given extension can work both as a hinting mechanism and as an NPC goal-planner. These were constructed with build 5T18 of Inform 7, and use the May 2008 version of both extensions. Hinting was slightly modified per the comments in its example.
We may copy and paste from below into a new Inform project to immediately compile and run.

"Alchemy" by Nate Cull

Chapter 1 - The Game

The Laboratory is a room. "A chaos of glassware, dark sigils, spellcasting apparatus sprawled in disgusting confusion -- in other words, a perfectly normal research lab, with a cupboard full of food. A stone archway leads east and another south." The Library is east of the Laboratory. "The stony walls are racked with square miles of parchment volumes." The Alcove is south of the Laboratory. "A tiny niche carved out of the stone, which opens out to the north."

A rosewood bench is a supporter in the laboratory. "A rosewood bench, scarred and burned by years of incantations, fills half of the room." An iron crucible is an open container on the rosewood bench. "Bob's crucible bubbles merrily on the bench." A curiously carved table is a supporter in the Library. A cupboard is a closed openable scenery container in the laboratory. A plastic bag is a closed transparent portable openable container on the carved table. A Chinese puzzle box is a locked lockable closed openable portable container in the plastic bag. A pinch of ginger is a portable edible thing in the puzzle box. A wicker basket is an open container in the cupboard. An onion, a tomato, a stick of celery, a lemon, and a banana are edible things in the wicker basket. Broth is an edible thing. A brass hook is a supporter in the Alcove. "Screwed into the stonework with grim determination is a shiny brass hook." The brass hook has carrying capacity 1. A silver key is on the brass hook. The matching key of the Chinese puzzle box is the silver key.

Every turn when the onion, celery, banana, and ginger are in the crucible: repeat with item running through things in the crucible begin; remove item from play; end repeat; now broth is in the crucible.

Every turn when broth is in the crucible: if the crucible is visible, say "The soup simmers, melding into a rich pungent vegetable broth."; end the game saying "Soup's ready!".

Bob is a person in the laboratory. "The mighty wizard Bob potters around his domain." The description of Bob is "Bob is carrying [a list of things carried by bob]."

Report Bob opening the cupboard for the first time: say "'Aslan sesameslan!' says Bob, flinging the cupboard doors wide open to reveal [a list of things in the cupboard]."; stop the action.

Chapter 2 - add PC stuff

Persuasion rule: persuasion succeeds. The block giving rule is not listed in any rulebook.

Definition: a person is other if it is not the person asked.

After an actor going: let follower be a random other person; say "[The follower] follow[s] [the actor]."; move the follower to the location of the actor; continue the action.

Chapter 3 - Supplemental Intelligence

Test me with "hint/solve/solve /solve/solve/solve/solve
solve/solve/solve/solve /solve/solve/solve/solve/ solve/
solve/solve".

Test him with "bob, think/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve/bob, solve".

Include Planner by Nate Cull, Basic Plans by Nate Cull.

Section 1 - Make Planner plan

Procedural rule when the desired relation is being-in and the desired param1 is broth and the desired param2 is the crucible: ignore the basic putting things in containers rule.

Planning when the desired relation is being-in and the desired param1 is broth and the desired param2 is the crucible: plan 1; suggest being-in with the onion and the crucible; suggest being-in with the celery and the crucible; suggest being-in with the banana and the crucible; suggest being-in with the ginger and the crucible.

Procedural rule when the desired relation is being-in and the desired param1 is a person: ignore the basic dropping objects in rooms rule.

Planning-failure: say "Bob scratches his beard and looks perplexed.".

Planning-success: end the game saying "All done!".

Section 1b - Make Planner plan using a new action

Doing-asking-for is a planning-action.

Planning-acting when the planned action is doing-asking-for: try the planning actor trying asking the planned param1 for the planned param2.

Planning rule when the desired relation is being-touchable-by and the desired param2 is the planning actor and a person (called the owner) encloses the desired param1: plan 1; suggest being-touchable-by with the owner and the planning actor; suggest doing-asking-for with the owner and the desired param1.

Instead of Bob asking the player for something: say "'I say, old chap,' says Bob. 'Do be a sport and hand me that [second noun].'"; change the action success flag to 1.

Section 2 - Make Planner hint

The new successful-action rule is listed instead of the successful-action rule in the specific action-processing rules. This is the new successful-action rule: change the action success flag to 1.

First planning-acting when an actor suggesting: change the action success flag to 1 instead.

Understand "solve" as solving. Solving is an action applying to nothing. Carry out an actor solving: have the actor plan an action for being-in with broth and the crucible.

Understand the command "think" as something new.

Understand "suggest" or "hint" or "think" as suggesting. Suggesting is an action applying to nothing. Carry out an actor suggesting: have the actor plan an action for being-in with broth and the crucible; say "[The planning actor] should try [the planned action][unless planned param1 is no-object] [the planned param1][end if][unless planned param2 is no-object] with [the planned param2][end if].".

Section 3 - Print the planned actions nicely (optional)

A planning-action has some text called the printed name. The printed name of doing-opening is "opening". The printed name of doing-taking is "taking". The printed name of doing-putting-in is "putting". The printed name of doing-going is "going". The printed name of doing-unlocking-with is "unlocking". The printed name of doing-asking-for is "asking".

"Cloak Of Darkness" by Aaron Reed

Chapter 1 - The Game

Foyer of the Opera House is a room. "You are standing in a spacious hall, splendidly decorated in red and gold, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways south and west." Instead of an actor going north in the Foyer, say "You've only just arrived, and besides, the weather outside seems to be getting worse."

The Cloakroom is west of the Foyer. "The walls of this small room were clearly once lined with hooks, though now only one remains. The exit is a door to the east." In the Cloakroom is a supporter called the small brass hook. The hook is scenery. Understand "peg" as the hook. The description of the hook is "It's just a small brass hook, [if something is on the hook]with [a list of things on the hook]hanging on it[otherwise]screwed to the wall[end if]." Understand "hang [something preferably held] on [something]" as putting it on.

The Bar is south of the Foyer. The printed name of the bar is "Foyer Bar". The Bar is dark. "The bar, much rougher than you'd have guessed after the opulence of the foyer to the north, is completely empty. There seems to be some sort of message scrawled in the sawdust on the floor."

The scrawled message is scenery in the Bar. Understand "floor" or "sawdust" as the message. Neatness is a kind of value. The neatnesses are neat, scuffed, and trampled. The message has a neatness. The message is neat.

Instead of an actor examining the message: say "The message, neatly marked in the sawdust, reads..."; end the game in victory. Instead of an actor examining the trampled message: say "The message has been carelessly trampled, making it difficult to read. You can just distinguish the words..."; end the game saying "You have lost".

Instead of an actor doing something other than looking, going or solving in the bar when in darkness: if the message is not trampled, change the neatness of the message to the neatness after the neatness of the message; say "In the dark? You could easily disturb something."

Instead of an actor going nowhere from the bar when in darkness: now the message is trampled; say "Blundering around in the dark isn't a good idea!"

The player wears a black velvet cloak. The cloak can be hung or unhung. The description of the cloak is "A handsome cloak, of velvet trimmed with satin, and slightly splattered with raindrops. Its blackness is so deep that it almost seems to suck light from the room." Instead of an actor dropping or putting the cloak on when the player is not in the cloakroom: say "This isn't the best place to leave a smart cloak lying around."

Carry out an actor taking the cloak: now the bar is dark. Carry out an actor putting the unhung cloak on something in the cloakroom: now the cloak is hung. Carry out an actor putting the cloak on something in the cloakroom: now the bar is lit. Carry out an actor dropping the cloak in the cloakroom: now the bar is lit.

When play begins: say "[paragraph break]Hurrying through the rainswept November night, you're glad to see the bright lights of the Opera House. It's surprising that there aren't more people about but, hey, what do you expect in a cheap demo game...?"

Chapter 2 - add an NPC

Bob is a man in the Foyer. Persuasion rule: persuasion succeeds.

After someone going: say "You follow him."; move the player to the location of Bob.

After deciding the scope of the player when in darkness: place Bob in scope [because he can still hear you].

Chapter 3 - Supplemental Intelligence

Test me with " solve / solve / solve / solve / solve / solve / solve ".

Test him with " bob, think / bob, solve / bob, solve / bob, solve / bob, solve / bob, solve / bob, solve / bob, solve ".

Include Intelligent Hinting by Aaron Reed.

Section 1 - Make Hinting hint

Winning-The-Game requires Noticing-The-Dark-Room, Hanging-The-Cloak, and Reading-The-Message.

Noticing-The-Dark-Room is a task with venue The Bar. Definition: Noticing-The-Dark-Room is complete: if location is The Bar or The Bar is visited, yes.

Hanging-The-Cloak is a reversible task. The venue is Cloakroom. Requirements for Hanging-The-Cloak: do the action of putting the cloak on the hook. Definition: Hanging-The-Cloak is complete: if cloak is hung, yes; no.

Reading-The-Message is a task with venue The Bar. Requirements for Reading-The-Message: do the action of examining the scrawled message.

Section 2 - Make Hinting plan

[ Because Inform doesn't understand "change the actor part of the relevant action to Bob", we have modified the extension, a simple search-and-replace of all instances of "the action of" with "the action of the person asked" ]

Carry out someone solving: now relevant action is the suggested action; unless relevant action is the action of the person asked fake-actioning, process appropriate action, actually performing;

Instead of someone thinking: say "Bob considers [the suggested action]."; rule succeeds.

Back to Table of Contents

An Interview with Mike Rubin (conducted by Urbatain)

Mike Rubin, better known online as Rubes, is currently at work adapting Jason Devlin's 2005 Comp-winning effort Vespers into a real-time 3D environment using the Torque Engine from Garage Games. As an attempt to wed the storytelling sophistication of textual IF with the immersive immediacy of graphical 3D worlds, it's both an interesting experiment and a noble attempt to use FPS technology in the service of a non-simplistic story. Urbatain of the Spanish IF community and SPAG's sister publication SPAC conducted the following in-depth interview with Rubes about Vespers 3D and the difficulties and potentials for an adaptation of this nature.

Urbatain has a somewhat, shall we say, idiosyncratic style of English, and I've had to heavily edit his questions to make them read more naturally. My apologies to him if I've overstepped my editorial license anywhere.

Urbatain: For a start, I would like to know a little more about you. As I've told you in private, I'm really excited about your project, and something that struck me positively is that it is not just theoretical vaporware. You have already made considerable progress: there are marvelous screenshots on the net, there are videos, and you have laid out in detail your design concept and your plans for modeling Vesper's world. Many of your labours are already done. So tell us a little bit of yourself and your history with interactive fiction, and tell us whether you have worked on any IF projects before.

Rubes: Well, I wouldn't go so far as to say my labours are done; we probably have only about 20% of the game done so far, but I understand what you mean and it's nice of you to say that. I've played IF for a long time, although I haven't played a huge number of games. I remember playing the original Colossal Cave on my dad's computer, sometime back in the 1970s, although I couldn't tell you which specific version it was. I was probably only about 8 or 9 years old at the time. I remember we had it on a 5.25" floppy, and I would get excited whenever I typed a command that caused the disk drive to start spinning -- it meant I had found something new and something good was about to happen. From there I moved on to mostly Scott Adams games, like Adventureland and Pirate Adventure. I loved those games.

Like many others, I moved on to Infocom games and had a great time with those. I remember Deadline and Planetfall the best, but there were so many good ones. I didn't really play many graphical adventure games after that. I tried a few, but none really hooked me. I don't remember playing very many adventure games at all in the '90s, but a few years ago I discovered rec.arts.int-fiction and realized the IF community was alive and well. I've been following along since.

I've never written any IF myself, though. I think I can write well, but I don't consider myself a very good creative writer. I've thought about it, though. If I wasn't working on Vespers, I think I might have tried it by now.

Urbatain: Tell us about your career as an indie developer.

Rubes: Well, I didn't start from zero, but not far from that. I have created only one other indie game, a shareware game for the Mac back in the mid-1990's called Missions of the Reliant. As a kid, I had learned programming and wanted to make a game so badly, but like most kids I had no idea what I was doing and never accomplished anything. But in the early '90s, with some extra time on my hands, I decided to get serious about it. Well, not too serious, considering I was a lazy graduate student at the time. And I still had no idea what I was doing, but at least I got somewhere with it. Missions was a 2D sprite-based game, inspired by the old ASCII Star Trek game where you warped from sector to sector on a grid wiping out Klingons with photon torpedoes and phasers. I made it basically alone, and I think it did fairly well for a shareware game back then. It was nominated for MacUser magazine's "Best Mac shareware game" of 1994, I believe, and came in second place (damn you, Andrew Welch!).

It was a fun experience, but as I moved on in life I found I had little time or enthusiasm for more game development. Then, a couple of years ago, I got the itch again, so I started looking into it. But that's really all there is to my history of being an indie developer -- one little space game some twelve or thirteen years ago.

Urbatain: It's almost impossible to make a quality graphical game without a whole team of people. Vespers is no exception. So tell us something about your indie company. How it it organized? Do you have an office or do the members just stay in contact through the net?

Rubes: You're right, there's really no way to make a 3D game like this without a lot of help. We're still a pretty small group, though. The company's name is Orange River Studio, which is something of a tribute to the slot canyons of Utah (where I live) and the room from the original Colossal Cave adventure. Right now, the group consists of me, Jason Devlin (Vespers author), one 3D modeller (N.R. Bharathae), two character animators (James Allan and Marc Schwegler), and a composer (Daniel Godsil), although some of those people work independently from the company. This project really started as a hobby more than anything, so we're still in the process of evolving from a hobby project to something more organized. We're scattered all over North America (and Switzerland), so there's no single office. We're all working out of our homes, as far as I know, and I think most of us have day jobs and do this work at night and on weekends.

Urbatain: When did you first decide to develop a "graphical IF" game?

Rubes: Well, as I mentioned a couple of years ago I got the itch again to make a game. I really didn't anticipate being able to make a 3D game, though, since I had no interest in the complexity of those engines and the steep art requirements, but I somehow stumbled across the Torque Game Engine from GarageGames and suddenly it seemed like a 3D game was a possibility. There were still huge hurdles to overcome with respect to content generation, but after some consideration I thought I would give it a shot.

The easy part was deciding to make a game; the hard part was deciding what game to make. I don't remember exactly how it came to me, but sometime early in the process I decided to try and merge IF with a 3D engine. I thought it would be something that nobody had really tried before, and it might be a way to combine the best parts of both worlds, to make an adventure game that was more interactive and immersive. It seemed silly at first to try and merge text with advanced 3D graphics, and some days it still seems pretty silly. But I know that text offers something that AAA FPS games don't have, and vice-versa. So I thought I would give it a try with a small "experiment" -- a game that is shorter and more contained. That's why I initially looked to the IF Comps for possible games to implement.

Urbatain: I'm quite interested in the idea of implementing the same kind of deep model world interactivity that we see in Inform or TADS in a graphical game, no matter the interface: point and click, icons, FPS, I don't mind. I only know that I want to do it, someday... and then I find you, developing the same idea and using as your source a game that is hardly the first candidate one would think of for such an adaptation. So... why Vespers? It just seems like such a difficult title to adapt into a 3D environment.

Rubes: I didn't want to start completely from scratch with this experiment, so as mentioned I first looked to the IF Comps for a good game to base this upon. By starting with a completed IF game, much of the difficult and important ground work would be done, and I could start with a game that already had good writing, strong characters, and a developed plot -- something a lot of big-time games don't have. And it's not all that different from a movie producer looking to base his next project on a successful book, I suppose.

After playing through a number of IF Comp games from different years, I found that I enjoyed Vespers a great deal and realized that it would make a really interesting graphical game. Some of the things I liked about Vespers were that it was a short game, it was relatively well contained with not many rooms or objects, and it had some decent puzzles, so it wouldn't be a stretch to implement the whole thing. I also loved the setting and the atmosphere of the game, as well as the characters, dialog, and story. I thought it worked really well in text, but I also thought it presented a great opportunity for translating into a graphical game. I just got the sense that I would enjoy exploring that world in 3D, and that it would work in that type of medium.

It definitely has its challenges, though. The game is heavy on dialog, so that means the characters have to be modeled, animated, and voice-acted really well or it will come across as too artificial. There are also a few scenes in the game that will be difficult to put together, like the avalanche scene, the scene in the cellar, and the final ending scene. But I think we'll be able to come up with some satisfying solutions for those. I hope we will.

Urbatain: I would have expected you to choose a very different sort of IF game. Many classic IF games are of course just detailed environments where time is more or less static. But a modern game like Vespers is a much more ambitious exercise in storytelling. It seems exceptionally difficult to adapt into a graphical game. Did you consider starting with an older, simpler game, with no real character interaction, no branches in the story, no real need for the player to direct the plot, or even much of a plot at all? In other words, a typical old-school cave crawl.

Rubes: Now you tell me! ;)

Actually, this is probably true, and if I had thought about it more at the beginning, I might have started with an abbreviated implementation of Colossal Cave or something similar. Then again, realistic caves can be a bit difficult to convincingly model in 3D, so maybe not. When I started out, my main concern was trying to find an IF game that was brief (to keep the scope of the project down) and feasible (to limit the implementation challenges). Vespers does present some feasibility problems -- how to implement the long ride to the stream, the avalanche, the scene with the wolves, and so on -- but we'll have some solutions for those issues. What I find most interesting about those challenges is that they get to the very heart of the differences between turn-based IF and real-time 3D, and I'm hoping it will generate a lot of discussion about the alternative ways of approaching these problems.

Urbatain: I have two games in mind that I think might be good choices to convert into graphical games. There is a Spanish game, El Anillo (The Ring), in which the player is a ring that only can do a few things: examine, look, shine, increase or decrease its size, and talk with the person wearing it. This might be quite easy to implement -- at least in the first part; in the second part, the ring controls a mentally retarded hunchback, so it's more like a typical IF game -- in a graphical game. I would implement it like the flash game Sprout (Google it and play it! It's worth the time). Another one might be Spider and Web. In fact, I mentioned this possibility to Zarf, but he was pessimistic about how well it would work well as an "arcade" game. So this get me to Vespers 3D. How did you finally decide on the the interface and model world as it is now? And have you considered other approaches toward implementing a decent IF model world in 3D?

Rubes: That's a good question. One of the main challenges to implementing an IF game in real-time 3D is that IF is traditionally turn-based; activity only takes place between command prompts, and players have as much time as they want to ponder the next action. Of course, in a real-time game there is generally more pressure on players to think and type fast, but that's not the game I want to create. So I've tried to design the system and the interface to be this hybrid of real-time and turn-based play.

A turn-based game is really just a game that waits for player input before advancing the action a certain amount, and this game is not really any different -- even though it gives the appearance of taking place in real time. Things are happening around the player all the time, but really these are just idle activities, and most just play continuously or randomly until the player performs some type of meaningful action to interrupt them. It's really not much different than a turn-based game, at least the way I'm implementing it.

What I'm doing is really a direct translation of a turn-based text game, making (animated) graphical representations of objects and characters that are defined much as they are in the original Inform code. Because of that, our world model is very close to what it is in IF, just with models, animations, and more salient spatial relationships. But since that's the approach I've taken, I'm also not exactly pushing the boundaries of the medium, so to speak. There is a lot more that could be done, but I'm really just using this experiment to see what this model is capable of, before testing its limits with a future project.

The real challenges will come in scenes that contain continuous activity, like the avalanche and cellar scenes from Vespers. It's a challenge to create those in a turn-based text game, of course, but there is never any deviation from strict, discrete turn-based play. Once you get into the realm of animated 3D, even if it's pseudo-real-time, you run into problems waiting for the player to take action. There are certain things we can do, but it takes a lot of creative thinking to work out those scenes.

Urbatain: This is an interesting approach. However, there are examples of real-time textual IF, such as some MUDs or Skotos's Castle Marach; and a friend of mine is making a system for MUDs and IF at the same time (multiplayer IF is at hand at last! ;) how many times have we heard this?) where actions take time to be done, so a player could see another player start to pick a lock, then see him picking the lock, and finally see him finish picking the lock. How do you control the passage of time in actions like this in your game?

Rubes: I haven't reached any of those situations in the game yet, but I will soon. There are a few of those in Vespers, like the ones mentioned above -- the avalanche scene, the scene with the wolves, the scene in the cellar -- where actions take place over a number of turns. I'm not exactly sure how the final system will work, but I imagine it's going to be some sort of hybrid between turn-based play and real-time play. For instance, the player will probably be given a lot of time to think, but it won't be like a pure turn-based game where time only advances once actions are taken.

Urbatain: Another game I have thought of porting to a graphical formal is one of mine called El Extraño Caso de Randolph Dwight. It is an experiment into alternatives to compass direction navigation. Although there are rooms, the player must navigate with the verb GO: "Go near the wardrobe and open it", "go through the door," etc. This game also has a system whereby the player character automatically goes near the object the player is attempting to interact with. (Shade by Zarf also uses this approach quite successful.) Here's an example:

>open wardrobe You walk to the wardrobe and open it, revealing your clothes.
I implemented this system because my testers protested about the "You are too far away to do that..." message, and for certain actions this could be a little odd and tiresome. But I've seen in your screenshots that in Vespers 3D that sort of thing would be common. Why did you decide on that approach -- or maybe you are still flexible about it?

Rubes: I've tried to be flexible with this, although I have to draw the line somewhere. I am very opposed to taking control of the player's avatar and moving it around without consent -- it can be disturbing for players, and it introduces a number of problems to deal with, such as path finding. But because of that, for most player actions, I have to perform a series of checks to see if the action is allowable. One of those checks is for distance, and one way that I've tried to be flexible is by allowing different maximum distances for different actions. So for some general actions, like taking or opening, you can be up to a fair distance away; for others, such as reading, you need to be closer. It can lead to some frustration on the part of the player, I'm sure, but I also don't want players to feel like it's okay to close doors 30 feet away on the other side of the room.

Some of the other checks are for things like line of sight and field of vision, just to make sure the player isn't trying to perform an action on an object that is behind him, for instance. But the goal of these checks isn't to make the game hyper-realistic; there needs to be some flexibility so players don't get overly frustrated. We'll see how it goes once we have people test it out.

Urbatain: You have to be careful with things like this. For instance, in my Dwight game, some actions were too dangerous to allow the player to walk around automatically: a simple EXAMINE would launch them to a certain death. I think there's no a perfect solution for this, but there are things that can be done. For instance, an intelligent EXAMINE that gives different information when near as opposed to far away from the object. Think of the wolves scene in Vespers:

>Examine the tree Ok, you walk there and pass near the circle of wolves, who happily make you their next meal.
Rubes: Yes, I think for some actions like "examine" you can implement different responses based on the player's distance from the target, although that introduces more content requirement. But most verbs, unfortunately, don't conform to that structure.

Urbatain: To speak of what an IF game offers that graphical games lose completely, at least graphical adventures: I think it is the eureka factor. You know, the pleasure of solving a puzzle or advancing the plot, or even better, of changing the outcome of the story through our choices. I think this factor is only possible because of the natural language interface. In graphical games your possible actions are all listed for you, so the pleasure of solving a puzzle is not as complete as in an IF game. So I think your game will show the world the real potential of a parser to increase the player's sense of possibility.

Rubes: I actually disagree with that, but I think you're close. There is very much a "eureka" factor in graphical adventure games when you solve certain
puzzles, although the quality of that experience might be different than in an IF game. I think the "eureka" factor is one of the main appeals of the adventure genre overall, graphical or text, since puzzle solving is so integral to game design and play.

Text input is, of course, one of the more unique features of this project. So I think the real question, then, is why? Why use a text parser? What does it add to the experience?

As you suggest, in graphical games the actions are often simplified -- e.g., grouped together into larger categories, like "use" or "interact" -- and typically fewer in number. Some might argue that objects in adventure games often can only have one or a few actions applied to them anyway, and that adventure games in general need only a handful of verbs -- so why bother with a large set of verbs that frequently don't work and only give standard, library responses?

I actually looked at this to some degree on my blog in a cursory and highly unscientific manner, and it appears that there are actually a large number of verbs used in three relatively well-known IF games, as specified in their walkthroughs. Of course, some IF games use more verbs than others, and some may use only a handful -- of course it's highly game- and designer-dependent. But, I find it interesting that it's not uncommon to see adventure games that use 50, 60, or more different verbs or actions. That's a lot of options, and I'm not really sure how you would create an efficient interface for all of those in a graphical game.

Then there is also the difference between a concealed system, as with a text parser, and a fully disclosed system, such as you see in most graphical adventure games. That is, in a fully disclosed system, the player knows ahead of time the entire set of possible actions in the game, since the options (verbs) are presented in some sort of visual menu. I believe what you are getting at with your comment above is that, with a system like this, you sometimes don't get that same sense of discovery you might experience in the absence of a complete list of all options. With a concealed system -- like a text parser, which doesn't (typically) disclose a list of all possible verbs -- you can get a deeper and more engaged participation in the game world, and you can utilize certain special actions to great advantage. There are some wonderful experiences in IF that simply would not work if all possible actions were given up front, and the parser is better suited for
creative situations like these.

This has benefits and detriments, of course -- the most obvious detriment being that players can get frustrated trying to find or express the precise action that the game requires for a particular situation. But in many cases determining (and expressing) how to use an item or perform an action can be a puzzle in itself. For this to work well, though, authors need to do a thorough job of (1) designing fair, clever puzzles, (2) giving the player an intuitive feel for what is possible and what is not, and (3) testing the game to make sure it accounts for alternative ways of expressing the same action. Without that, the game can come across as needlessly complicated or difficult, with many players blaming the parser itself.

Urbatain: Yes, I agree. Actually, I think we pretty much agree on all of this, but English is not my first language, and so I did not perhaps express myself properly. But yes, of course you can have a eureka factor in a graphical adventure, but I think that solving a puzzle is more satisfying in textual IF because of that concealment of the interface you talked about. Puzzle solving in an IF game just feels more natural to the human mind, because your mind thinks about a solution, and your mind express that solution in the manner to which it is naturally atuned: natural language. You type down the posible solution and the game answer properly (or not).

Rubes: I think you'll probably find a lot of people who do not necessarily agree with that, and my sense is that it's probably just a matter of preference. Some people find a simplified, point-and-click interface to be easier and more natural, particularly given the typical computer interface. I think one of the attractions of a text parser is that it allows players to more naturally express the desired action -- typing TAKE, DROP, PUSH, or OPEN is more explicit and expressive than moving or clicking a mouse, so for some people (myself included) it is a more comfortable way of doing things. But I would say the popularity of point-and-click adventure games would argue, at least to some degree, that that type of interface is preferred by many people.

Urbatain: I would say, however, that many complaints that people raise about IF are implementation rather than systemic problems. The guess the verb syndrome in particular arises from authors not fully considering ways that their players might choose to phrase a command, and of course from inadequete testing. I have read your analysis of verbs in IF that you just mentioned, and because you are duplicating the model world of Inform, when it comes to mouse shortcuts for lazy players... what kind of apporach will you take with that? Will it be possible to complete the game using only the mouse? When the player right-clicks on an object, will he see the whole set of available verbs, or only the most common?

Rubes: I was hoping to create a game that could be played entirely from the keyboard, but not necessarily the mouse. One of the features of the text parser that I like is that there is a sense of incomplete disclosure; that is, the player does not know all of the commands allowed in the game, and part of the puzzle is figuring that out. With mouse-based point-and-click games, you need to have full disclosure, and to me that eliminates one of the challenges of the adventure game genre. This is particularly true for "special" verbs and things like magic words, where the designer may not want the player to know certain words or verbs exist until they are discovered. So there are certain things that I don't want the mouse to be able to do.

Right now you can do almost everything with the keyboard. The only things you can't do are to rotate left or right (only strafing is currently supported), or look up or down. You can't select objects, either, but you don't have to -- you can just refer to objects by their name. The game can certainly be played and finished with only the keyboard, but it probably wouldn't be an ideal experience. Adding the ability to turn and look up and down with the keyboard is not difficult, but I'm not sure how many people are really comfortable doing it that way. That's something that we'll probably look at once we get to testing.

The mouse is more restrictive. The cursor is used to select objects by clicking the left mouse button, which highlights the object. The right mouse button is used to perform an action based on whatever verb the button is currently set to. Right now the set of possible verbs is restricted to four common actions (TAKE, LOOK, EXAMINE, and INVENTORY), and you pick the one you want by rotating the mouse wheel (if your mouse has one). You can also pick the verb for the right button by typing the command SET RIGHT BUTTON TO <VERB>. For the verbs that require an object (TAKE and EXAMINE), the game will automatically assume any selected object is the target of the action. So for instance, let's say the right mouse button is currently set to EXAMINE, and the player clicks on a table to select it. Clicking the right button will generate the command EXAMINE TABLE and send that to the parser, where it will be interpreted and executed.

Also, if either mouse button is clicked and dragged, it will pan the camera for looking around. Holding both buttons down simultaneously will make the player move forward. So there is some functionality to the mouse, but you'll still need the keyboard to play. For the most part, keeping one hand on the mouse and one on the keyboard should work well, without much interruption.

Of course, most of this is not set in stone, and we can (and likely will) make changes to it as needed once we get to testing.

Urbatain: Speaking of interfaces, the premise I've talked about just one question before, I once thought (as did a lot of adventure-game visionaries) that the natural evolution of IF was going to be toward 3D and virtual reality games, toward graphical model worlds with deep interactivity and simulation. However, as the videogame market evolved it rather chased anther kind of vision, one of beautiful high definition environments with poor world modeling and less interactivity. Vespers 3D, I think, could take us back to the original visions of 3D gaming.

And to speak again about the eureka factor: you are right, I think in 3D games with controls that simulate a model world and have an element of simulation, albeit simplistic simulation, such as Quake for instance, you could have that Eureka! factor. You see the enemy, your mind calculates movement, trajectory and timing, you launch the missile and its flight is simulated by computational simulation, and... Eureka! Frag! Another example: in Clive Barker'sUndying there was a puzzle where an unlit fireplace was waiting for you to cast the Fire spell upon it. You didn't just click on the fireplace and select "burn", as you might in a graphical adventure, but rather had to experiment by casting different spells until you found the right one.

I can imagine that the best evolution for 3D-IF would be a parser controlled by natural speech, with a microphone.

Rubes: Well, I agree it would be fascinating to see a game controlled by natural language entered with a microphone, but I think it will still be some time before we see it. As for the evolution of world models in general, I think we are moving towards more advanced systems that allow for creative experimentation and puzzle-solving, and it will be interesting to see where developers take it. Vespers, however, is really not very advanced in this respect -- it's world model is really just a straight graphical representation of the IF world model that Jason created in Inform 6. There are, perhaps, more options for interaction than you might find in a typical first-person 3D game, but it is designed to work very much like the world model in IF, to the extent that it can.

That's actually one of the ultimate goals of this project: to create a 3D world model that implements the IF world model as closely as possible, so that players and designers can see how IF might directly translate into 3D. But to me, that essentially represents just the first step; from there, I'm hoping people will look at this and begin to think about how we could begin to explore the medium, to take greater advantage of the things 3D offers, to make a game that is more than just a direct representation of an IF world model.

Urbatain: But as I recall the Vespers model world was built with Platypus, so its level of simulation is quite a bit deeper than that of a game built with the standard library!

Did you observe the complex world-modelling in commercial games when planning Vespers 3D? For example I have in mind the Thief series, especially some of the fan-made missions. Some have managed to tell quite sophisticated stories within an FPS environment.

Rubes: I have played a number of commercial games, although as a Mac user I haven't had as much access to popular PC games as I would have liked. One of the games I enjoyed the most is Deus Ex, which I thought did a nice job of following a simple but entertaining storyline and providing nice visuals, atmosphere, and environment. Still, it was more shooter than adventure, which is not what I'm looking to create. Not long ago I purchased a Mac Intel laptop and installed Windows XP using Boot Camp, so one of the things I've been doing lately is going back to try some of the popular adventure games I missed, mostly to experience them and study their world models and interfaces. For instance, I've been playing Dreamfall recently and, although I'm enjoying it, I'm finding the interface to be a real irritation.

Urbatain: You should take a look at some commercial action games. Let me mention some with particularly complex 3D world-modeling: Deus Ex of course, the Thief series (if you get a copy of Thief 2 you can get years and years of out of it with its tons of fan-made missions), Thief: Deadly Shadows of course, System Shock 2, Half Life 2, Portal, Bioshock. It's curious: all of my favorites are products of the same group of people, disciples of the same philosophy about games inherited from Looking Glass Studios. I can't think of any indie game that takes this kind of approach. As for graphical adventure games, they are mostly stuck in the past; well, maybe Real Myst would be worth looking at, as it allows the player to move about freely in a 3D environment; and maybe Zork Grand Inquisitor, with its magical system adapted from the Enchanter trilogy, albeit not with quite the full complexity of Infocom's original.

Rubes: I think some graphical adventures are stuck in the past, but there are some really interesting games that have come out or are expected to come out which to me seem very forward-thinking. The Penumbra games come to mind. Those focus a great deal on storytelling and immersion, and use advanced 3D graphics and physics. They also have you interacting with objects in the game world through "natural" movements like pulling levers or opening drawers with the cursor, although I'm not sure that type of interaction is necessarily better. Nevertheless, I admire their thinking and approach.

Urbatain: Another quite important thing to consider for IF vs commercial games is that text allow us to represent perfect model worlds (although I could imagine problems and puzzles which a 3D engine would be better suited for modeling). For example, in IF we have containers and supporters. The concept is so simple -- one thing can be inside of another -- but in graphical adventure games they must use lists of sub-objects or a pop-up window. One could expect that 3D worlds would fix this; however, they continue using sub-lists of objects, because they are easy to implement. A perfect 3D world would allow us to really look inside a container. This is not an easy thing to implement, however; for an example of real 3D containers that don't work very well, see Thief: Deadly Shadows. And I'm curious about supporters. Since their "contents" are visible, they should be easier to implement than truly openable 3D containers.

Rubes: Well, I would say that text does not necessarily allow us to represent perfect model worlds, particularly with respect to containers and supporters; depending on the implementation, for instance, you could have containers holding far more objects than they should be able to (since weight and space are either overlooked or difficult to implement). But yes, those types of things are far easier to implement in text than in 3D. Supporters, like tables, are a little bit easier in 3D these days, particularly if you have a good physics engine at your disposal. But in general, these are difficult concepts to model in a practical sense.

Vespers does have the advantage of containing only a handful of objects the player can possess, but even then it can still get complicated. I can only think of a couple of containers in Vespers off the top of my head -- the alms box in the entrance hall, and the cupboard in the kitchen, although I'm probably forgetting others. Rather than try to model these containers in a highly realistic manner, however, I chose to model them more practically. In the text version of Vespers, for instance, the only object allowed inside the alms box is the coin -- the code will not allow the player to place any other object inside. So, I just did the same thing. The coin is hidden nicely inside the box when the lid is closed, but no other object can be placed in there.

The cupboard is a little more complicated, though. In the text game, the cupboard is described as having only a single door, and the inside is not described in any detail. We decided to model our cupboard in 3D based on some designs we found, but the design included 4 doors. So now we have four different places that the player can (and should) be able to place objects. I was able to implement this, but the simplest way to do it was to create a "holder" for an object behind each of the four cupboard doors. The problem is that you can only place one object in each holder. From a game standpoint, this really isn't a problem: the player rarely has more than a couple of objects at any one time, and there really isn't any need to place objects there anyway. But from a mimesis perspective, it can be jarring if you put a small coin in the cupboard and then are told that there is no more room for other objects in that space.

There are likely more elegant solutions to this issue, but the work required for that is really not worth it for Vespers.

Since the Torque Game Engine does not have a very good physics engine built in, I decided to implement supporters a similar way: I just created a series of points on top of each supporter for objects to be located when placed. So for instance, the bed in the Abbot's room has 5 different locations for placing objects, and if the player wants to put an object on the bed (for whatever reason), it just finds an empty location and puts it there. Once all 5 locations are occupied, there is no more room for objects on the supporter. Again, it's good enough for our purposes since, in Vespers the player will never have more than 5 objects that he can drop (if I remember correctly). If there were more objects, we might run into some problems with mimesis, but as with containers a more elegant solution is not really worth the effort.

Urbatain: But in text, imagination creates far more perfect worlds than any 3D game could ever presnt. In IF it is so simple to model having something inside another (a match inside a match-box). Today you can easily add complex control of volume and weight in IF games... actually even back in the 80's and 90's, the PAW system allowed you to have volume and weight. But Vespers 3D will represent things inside containers, as viewable object? in a real 3D view? not using pop-up windows with sub-lists of sub-objects?

Rubes: Well, there aren't many instances of this in Vespers, mostly because there aren't many inventory items and containers in the game. But for those that we do have, yes, objects will be visually represented inside of other objects. The coin, for instance, appears inside the alms box when you open it, and when the box is closed, you can't see it. Same for the food in the cupboard.

Of course, the text will also reflect this, as it would in IF. So if the player types LOOK INSIDE ALMS BOX, the answer will be "In the alms box is a coin."

Urbatain: Good! Good! Ok, so only the inventory reverts to sub-lists, for obvious reasons.

We'll take a break from the tough questions for a moment for something more straightforward. Will Vespers 3D be a commercial product, or will it be free?

Rubes: That's actually a tough question to answer. Originally I had planned on making it free, but I also originally planned on spending a lot less to make the game. It really is difficult to make a 3D game with characters and animations on a tiny budget. The plan was to use this game as a springboard to a subsequent, full-length 3D-if game, but to do that I'd probably have to recoup at least some of the cost of this game. The problem with charging money for a game like this is that it is very short compared to most commercial games, so it's not like I can charge very much. So if I do end up charging for it, it will probably be a small amount -- probably along the lines of a movie ticket.

Urbatain: Have you thought of entering it into something like the Independent Games Festival?

Rubes: I'd certainly like that, that's the goal -- IGF, IndieCade, and the like. But there's still a long way to go before we can get to that point.

Urbatain: Well, to be honest, I always prefer free indie games, and it's a shame to see a lot of the IGF winners going commercial, whether through X-Box Live, or (less annoyingly) as shareware with demos. And meanwhile you can get all these top-notch free indie games, like Knytt Stories, the 6 days a sacrifice series, IF games, and the many online Flash games. It seems hard to justify paying for games when all of this is out there for free... but soon TextFyre should be coming out with high quality IF games that I'm sure I will be glad to pay for... so I'm left feeling divided! Well, maybe you could go an intermediate way like Radiohead, that soldIn Rainbows online, and buyers could choose what money to pay for it, between 0 pounds (for free) to 99... ;)

Rubes: We'll certainly look at different options, but I can also understand why some of these designers want to charge for their games. It's rare for an indie game designer to break even on a project, much less make any significant profit. And it's tough to keep making games for little or no price -- especially 3D games, which can get very expensive very fast. I've already spent a considerable amount on Vespers, and it's unlikely I'd be able to make another one of these games without either earning back some of what I spent, or getting an outside party interested in supporting it. But if you do the latter, then you have no choice but to charge for the game. So it's a tough spot to be in.

Urbatain: Okay, back to the tough questions! Will you censor yourself at all? Vespers -- not to spoil the plot for those who haven't played it yet -- has a good deal of violence and sex. In a text game, sex can be written about without going into nasty details. But I simply cannot conceive how you might manage to adapt these scenes into 3D. Have you decided to just cut them? Thank God indie developers don't have to deal with moral codes, official censure and laws (I hope... I think...). Correct me if I'm wrong.

Rubes: It's also especially challenging with a 3D game that has a first-person perspective. Anything that requires the direct, coordinated physical interaction of the player and an NPC, such as sex or violence (or even simple conversation, for that matter), is going to be difficult in a 3D FPS game and will require some creative solutions. We haven't decided to cut any of those parts from the game, but we also haven't worked out final solutions for them yet, either. We do have some options, and we'll try them out to see how they work. It's not going to be easy, though. As far as the sexual material goes, however, suffice it to say that it won't be graphically depicted (pun intended) in any way.

Urbatian: But to get beyond the sex and violence issues... you told me before that some scenes are quite difficult to implement. Let's talk about the technical issues of an adaptation... The original game has a lot of "close" contact scenes (maybe this has something to do with that sex... or not). How do you manage these cinematic or "close contact" scenes? I have in mind, for instance, the ending scene, and yes, that cellar scene, that is similar to the well scene in Anchorhead. I simply couldn't imagine how to do that in 3D. Well in the ending scene I suppose you could always show a pretty end picture or a video; but the cellar scene in Vespers and the well scene in Anchorhead are interactive; implementing them seems very difficult.

Rubes: Right, absolutely. It gets back to my point above, that direct, coordinated physical interaction between the player and another character is very hard
to resolve in a 3D first-person game. There are some tricks you can do to restrict where the player might be, or how much the player is allowed to move or act, but sometimes even those methods don't always work. The biggest problem is that you can't always predict where the player is physically located when he tries to perform a particular task, or when a certain action in the game needs to take place, which is information that the NPCs need to have in order for their animations to appear appropriate. One solution is to design the system so that the player can be manipulated into moving to one or more predictable locations, at which point the triggered animations will then make more sense. It's hard to talk about specific examples from Vespers without giving too much away about the game, but hopefully that gives you an idea what we're thinking.

Urbatain: Not really! :) But I think that I will have to wait for the final release to have these questions answered... :)

However, this brings to mind an important issue: that is, 3D narration. Commercial game developers don't know where they are going with the medium; sometimes they copy the cinema approach, a bad idea because they are, and we are, interactive. To be more direct: I'm thinking of the difference between a first- person and third-person camera. In the Quake games, when you die, the camera jumps outside of your body; in the Half-Life series, the camera is ALWAYS inside Gordon Freeman. Could you tell us something about this? Maybe for those difficult scenes you could change the camera to third person?

Rubes: I've never been a big fan of changing camera perspective in the middle of a game, at least for games where you're playing a particular role (in Quake-style FPS games, I think it's less of an issue). I prefer first-person view to third-person view, since I find that allows me as a player to become more immersed in the character that I'm playing, and I prefer to keep the camera perspective that way throughout.

There are some situations in Vespers where control of the camera will be taken away from the player for a few brief cut-scenes, but we're not planning on showing the player character (the Abbot) in those instances. We've talked about that as a group a few times, but I think my philosophy is to give players a role and to let them imagine themselves in that role, rather than explicitly showing them the character.

Urbatain: We talked before about the control interface and the difficulty of allowing the avatar to move around automatically because of the need for complex path-finding algorithms. However, I think I would like to see the interface be fully parser controlled. For example, in Facade the player must use the arrows to move the PC but he must type to speak to NPCs. I think games that force the player to jump from mouse to arrows-keys, from arrow-keys to the rest of the keyboard, can be confusing to play. I would like to be able to control the game only with text: GO TO THE DOOR, GO NEAR THE TABLE, LOOK NORTH, LOOK AT THE BLOOD, LOOK AROUND, LOOK TO THE LEFT, TURN AROUND, TURN 45 DEGREES, etc. Yes, this could be a little bit complicated with the need for pathfinding algorithms and such... but I think it deserves the effort. Could you comment a little bit about this? About control design... what elements should you abandon for sake of simplicity, and what is the final design for the interface?

Rubes: Well, as I mentioned players can use the keyboard almost exclusively as is. You can't type GO TO <LOCATION>, but you can move easily enough with the WASD-type controls. The real problem with allowing GO TO commands is that you can never predict where the player is when the command is entered, so at any time there might be an object, a wall, a door, or an NPC directly in the player's path. So you're left with two options: just zap the player to the new location (which I feel is too jarring, and what if an object is already at the destination spot?), or develop a sophisticated set of path-finding code, which can be complicated and time-consuming. I certainly agree that constant switching between keyboard and mouse can be distracting and annoying, but it would also seem equally (if not more) tiresome to have to type such specific commands as TURN LEFT 45 DEGREES when the same could be accomplished by either pressing a single key or slightly moving the mouse.

As for the interface design, I discussed most of the interface elements above, but there are a few things I haven't mentioned. One is to make common commands as simple as possible by using single keypresses, so INVENTORY can be accomplished by pressing I, LOOK by pressing L, EXAMINE by pressing X, OPEN by pressing O, and AGAIN by pressing G. I've tried to make the majority of commands fairly simple; for instance, examining objects becomes a process of just clicking on an object and pressing X, opening becomes just clicking an object and pressing O, and so on.

I've also tried to incorporate some customization by, for example, utilizing the TAB key: just like the right mouse button, it can be set to a desired verb, which executes when the TAB key is pressed. The default is INVENTORY, but it can also be set to LOOK, EXAMINE, or TAKE, and you set it by entering the SET TAB KEY TO <VERB> command.

The ability to customize (like with the TAB key or the right mouse button) got me thinking that we could allow even greater customization if we want. Why restrict the verb possibilities to four common actions? Couldn't we allow players to enter SET TAB KEY TO <VERB> and allow any valid verb to be used? And could we also allow players to attach specific verbs to single key presses as well? Like what if someone wants the T key to execute TAKE, while another wants it to execute TALK TO? Why not let them specify this?

For that matter, couldn't we also allow players to attach whole phrases to specific keys? The way the game interface is set up, any time a command is issued -- whether from the command line, a single key press, or the right mouse button -- it works by generating the appropriate command in text form, and sending it through the parser. So if the TAB key is set to INVENTORY, pressing the TAB key actually generates a text string containing "INVENTORY" and sends it to the parser. So theoretically, it is perfectly feasible to assign a whole phrase to a specific key. We could, for instance, let players type SET F1 KEY TO SET TAB KEY TO TAKE, and the result would be that, when the F1 key is pressed, the phrase "SET TAB KEY TO TAKE" would be sent to the parser, and the TAB key would be set to TAKE. All sorts of possibilities become available.

But the real question is, do players want that level of customization? I sense that the interface is already complicated enough as it is, and I sense that adding more and more possibilities might overwhelm too many people. Simplicity is something that I believe should be sought, so I'm not sure how I feel about all of this yet.

Urbatain: One thing that I think is really important in interactive pieces in 3D worlds is the handling of "close contact" between the avatar and the object being interacted with (and not just NPCs). For example, in most FPS's we never see our own body, but in some we do see just an arm floating in midair. Some of these arms add to the realism, allowing us to see ourselves pushing buttons, pulling levers, breaking heads, etc. As a negative example, though, I have one game in mind: Thief Deadly Shadows, where we are aware of our whole body, but when we decide to pick up an object, it just disappears from the ground and is magically transported to inventory. It's jarring. We have that perfect modelled thief but he has telekinesis for moving around objects. In other games like Blade: Severance (a commercial Spanish release, also with body-awareness) the the arm of the avatar moves somewhat correctly to pick up a piece of bread, move it to the mouth and eat it; or in Dark Messiah where we see the arm fighting enemies, impaling them, cutting ropes for improvised traps, etc; this effect is really satisfying. So, the question is, will there be animations of the arm, or even the whole avatar's body, for every one of Inform's actions?

Rubes: We've thought about doing some of that, but probably not for this game. I think if I had another two or three programmers and artists working with me, we could probably do it, but it's a lot of fairly complicated work to get it to be convincing. So for now, we'll still have players who work telekinetically. ;) It's really a question of resources and manpower vs. the additional benefit this provides.

Urbatain: How will the game handle negative feedback? Will there be animations for "You can't do that..."?

Rubes: In general, the answer is no. At this stage of development, though, we're focusing more on the translation over from IF, so most of the responses like that will still probably be in text form. If it makes sense to do it graphically and it adds to the game to have some sort of negative visual feedback, then we might do that for some things.

Urbatain: Will the game have an audio element? Will there be a voice telling us we "can't do that" when we attempt something impossible?

Rubes: Right now, we do have some voice recording for the Abbot. It goes a little bit against my approach of not revealing aspects of the player character to the player (such as appearance and sound, which I think can sometimes break immersion), but I think it's necessary in some places. For instance, there are some conversations between the player and other brothers which are dependent on a back-and-forth exchange, so we really needed a voice for the Abbot to contribute. I think, in general, it works out well.

Right now we don't have specific audio recordings for failed actions, only a text response. I'm experimenting with different kinds of audio feedback, which I think is important, but I want to use something that breaks immersion as little as possible.

Urbatain: I don't see a problem here. We are playing a role in the game, so it's ok to that we hear the voice of the Abbot!

To what degree of depth have you implemented Inform's model world? For example, have you modeled the system of actions -- after, before, react_after, react_before, etc. -- or have you simplified this? If so, do you plan to extend this feature in the future?

Rubes: The Torque Game Engine has its own scripting language, and I've just adapted it to my purposes here, including some structure that is (vaguely) similar to the way Inform 6 works. So for instance, when I define objects in the game (like the alms box or the coin) I give them attributes and properties similar to the way Inform does. So the alms box has a name field which includes "almsbox" and "box", and an adjective field which includes "alms", and the parser uses these to determine whether or not the player is referring to this object. It also has fields for pronoun ("it"), plural (false), container (true), open (false, initially), and openable (true), as well as fields for parent, child, and sibling objects.

As for actions and reactions, I've handled that a bit differently, mostly because the game is played in real-time, and it's difficult to implement things like before, after, and so on in anything other than a pure turn-based game. For instance, there are a few "react_before" cases in Vespers (the text version) that respond to a movement command, but that would be difficult to do in 3D since movement is usually by holding down a key. So many of these instances are hard-coded in different ways, but that's okay since my goal was not necessarily to design the system to be completely independent of the game in the way that Inform is.

Urbatain: Finally, have you defined a complete language or script similar to TADS3 or Inform to for developing the game? If so, could you show us what it looks like?

Rubes: As I said, I just adpated the scripting language for the Torque Game Engine to do what I needed. Some of what I designed is similar to Inform, and some is different. For example, each verb has its own code for execution. First, it performs a series of checks to make sure the action can be performed (for instance, the player is close enough to the object, is facing the object, and so on). Then, it checks the object itself for any code specific to that verb, and then it executes the verb action. An example of this would be the INSERT action. If the player types INSERT COIN IN ALMS BOX, the engine would go to the code for INSERT and first run through checks to make sure the the coin is in the player's possession, the alms box is a valid container, the player is close enough to the alms box, and so on. Then it calls the code specific to the alms box to see if there are any special issues; in this case, the INSERT command is only allowed with the coin, and no other objects. So if the player tried to put another object in the alms box, here is where the command would return an error message and cancel the action. But since in this example the coin is the object, it is allowed to proceed. Back in the INSERT action code, it then performs the action of visually putting the target object into the container object, setting the appropriate parent/child/sibling values, and delivering the appropriate successful library message.

Urbatain: What role is Jason Devlin playing in the development? Is he directly involved in the programming and scripting, or is he in more of an advisory role? Will he stay with Orange River for more projects? I'm curious how many good authors TextFyre and Orange River is going to steal from the IF scene... :)

Rubes: For this project, Jason is mostly in an advisory and testing role. There are so many issues, as you can imagine, when moving from text to 3D -- not just in the translation of Vespers, but in the way the 3D/IF world model functions, and Jason has played a large role in figuring all of this out. Occasionally we run into parts of the 3D world that were either not included or not described in the text game, and Jason helps us figure out what to put in or how to describe it. I would like for him to design another game for us to make after we're finished with Vespers, and it would be interesting to see what he could design for a 3D/IF world specifically, not just an IF world. But due to our long development times, I wouldn't worry about us stealing many authors. ;)

Urbatain: When do you plan to release Vespers 3D? :)

Rubes: I'd love to answer, but I honestly have no idea. Not anytime soon, although perhaps we'll have a demo version (part of Day One of the game) sometime this year, if I'm lucky.

Urbatain: Do you have something in mind for Orange River after Vespers 3D is finished? Maybe, a more ambitious project? Perhaps an original work? Or another port from a textual IF? Or maybe is too soon to talk about that?

Rubes: Right now we have no specific plans, but we would be interested in doing both -- porting a successful IF game (assuming any authors are interested) and creating a new game that perhaps can take better advantage of a 3D/IF world model and push its boundaries, as you say. Movies are a very different medium from books, and each has their own set of techniques and styles that work only in that medium; similarly, 3D/IF is very different from IF, and to really succeed in this new medium we need to discover the techniques that work, rather than relying too heavily on pure IF itself.

We still have a long way to go before we start looking at new projects, but I'd certainly be interested in pursuing both pathways, and to hear from anyone interested in seeing their IF game created in 3D/IF.

Urbatain: That's all Rubes, thanks a lot for your time and for this project.

Rubes: Thanks, I appreciate the opportunity to talk about it, and I'm glad you are interested enough to learn more. I hope it turns out to be a game people enjoy experiencing.

Some links:
The Monk's Brew: Mike Rubin's blog
Vespers 3D on The Great Games Experiment
An Interview with Mike Rubin on The Rampant Coyote
Vespers 3D on GarageGames.com

Back to Table of Contents

Game Reviews

Title:	An Act of Murder
Author:	Christopher Huang
Author Email:	odd1out SP@G openface.ca
Release Date:	October 1, 2007
System:	Z-Code (Inform 7)
Version:	Release 1
Reviewer:	Bill Powell
Reviewer Email:	bill SP@G billpowellisalive.com

"Frederic Sheppard." Chief Inspector Duffy pulls at his moustache mournfully and stares up at the house through the windshield. "Theatrical sort, usually has a finger in some play or other. He bought up Gull Point about ten years ago. Never any complaints from the neighbors, never any scandals." He pulls at his moustache again. "He was found dead in the cove at the foot of the cliff behind the house about half an hour ago. Caller said it looked as though he fell from the study window."
So begins your investigation of a lethal drop from high society. If you enjoy a good Golden Age detective story, you'll want to play An Act of Murder. The game placed 2nd in the 2007 IF Comp, both among the judges and the authors, and I'd say it deserved it.

The beginning had both strengths and weaknesses. I appreciated the quick instructions about how to use "ask" and "tell"; these are the kinds of quick parser instructions that can save hours of a player's life. On the other hand, I did get anxious at the rather forced introduction to the main suspects. Fortunately, you're soon left to your own devices.

The world is consistent, crisply described, and just spacious enough for the story. The characters are clearly delineated, and easy to imagine. Implementing five separate suspects whom you can ask about anything may seem ambitious, (in the Credits, the author admits originally planning over 20) but in general, the interaction goes well. As hours passed, and Chief Inspector Duffy's arrival became imminent, I did get frustrated at a few "obvious" questions that soared over their heads, but p

ISSUE #52 - July 29, 2008