Gilbert interview

Just wanted to point out a new interview posted over at Eurogamer with Ron Gilbert, he of Monkey Island fame. Gilbert was recently hired as creative director at Hothead Games to assist with their upcoming games, "Penny Arcade Adventures: On The Rain-Slick Precipice of Darkness" and "Deathspank". I'm not a Penny Arcade fan, so the former doesn't really appeal to me very much -- particularly the way Gilbert describes it:

"It's kind of a light adventure game; there aren't going to be these really intricate, mind-boggling puzzles you would find in Monkey Island."

The latter, however, sounds a bit more intriguing, although not much has been revealed about it except that it will be released episodically -- which apparently is the hip new thing these days. Said Gilbert:

"The adventure game aspects in Deathspank are a lot more traditional and hardcore. You are going to get a lot of really intricate puzzles...it is melded with what I would term classic Monkey Island-style puzzles."

That sounds like something I could look forward to. In the interview, Gilbert is very enthusiastic and hopeful for the future of adventure games, which is encouraging -- as long as companies like Hothead and TellTale are successful and continue to publish good quality pieces.

Towards the end of the interview, Gilbert is asked to comment about this year's GDC, when Dave Jones (from Realtime Worlds) apparently said something about leaving storytelling to books and movies, not games.

"I think that's completely unfair. The main reason games don't do stories well is we don't have good storytellers. That gets lumped in, 'Well, games don't know how to tell good stories.' Well, no, games can tell stories, but you have to tell good ones...Adventure games did a really good job of telling them, but as graphics got better, the games industry became more action-oriented."

I think he's on to something, but I find it interesting that interactive fiction still isn't really part of the discussion. IF did, and still does, a good job of telling stories without graphics. But even though his solution is to blend core adventure game elements with other genres, such as RPG, we're not really sure what those core elements are that he refers to. In many respects, IF is at the core of most adventure games, at least historically, so perhaps asking "What works about IF?" can really get at the heart of the question "What works about adventure games?"

IF Beginners Comp

I would be remiss if I did not mention the new IFBeginnersComp, organized by David Fisher and inspired by (and running parallel with) the Interactive Short Fiction Competition. The comp consists of games that are suitable for beginners to IF, which I think is a great idea for getting more people interested in IF.

There are five entries in the comp:

- Connect, by James Hudson
- Germania, by Vicente Munoz
- Limelight, by Justin Lowmaster
- Mrs. Pepper's Nasty Secret, by Jim Aikin and Eric Eve
- The Sleeping Princess, by Molly, Alex, and Mark Engelberg

All were written in either TADS3 or Z-code, so they should run on most interpreters. I recommend Spatterlight for Mac users and Gargoyle for Windows/Linux users.

The public judging period goes until March 15th, and instructions for voting can be found here.

The important question, however, is whether the games succeed at their intended purpose. Below are some of my impressions (with some possible spoilers).

I gather the idea behind the IFBeginnersComp is to capture new players, turn them on to IF, and get them hooked and wanting to play more. How to determine if a game is "suitable for beginners to IF" is open to debate, but for me such a game would be brief, and it would include clear instructions (particularly for those new to IF), a small set of straightforward puzzles, and a variety of possible actions that would span a decent array of verbs. At least one or two engaging NPCs would be useful as well. But perhaps most importantly, the game would be well designed and tested to avoid ambiguous output and confusing parser issues. Because a common perception of IF is that it still suffers from illogical puzzles and frustrating parsers, IF games made to attract new players should, I imagine, do their best to avoid these shortcomings.

At least one of the games, Limelight, does not do this well. Instead of being a game suitable for beginners to IF, Limelight comes across more as a beginner's attempt at writing IF. There's nothing wrong with that, of course, if that's the case. But my guess is that players who are new to IF would likely find the mechanics of this piece frustrating, confusing, and inconsistent at times, and it probably would not inspire new players to try other works. The most obvious criticism is that it would have benefitted from more careful testing, to correct typos, inconsistent plural forms, and more appropriate responses to what I imagine are valid but unsupported commands. Room exit lists are occasionally incomplete (at one point the player is told "You can go north" when there are clearly exits both north and west), and some solutions (such as the HIDE/UNHIDE commands) are not necessarily intuitive. The most glaring problem, however, is the final chase scene. Although it is very forgiving for new players, the implementation is strange and messy. In addition to making the player move (by running) without specifying so, the descriptions are sloppy ("You see a Nasty thug, Mean thug, yourself, and thugs"...yikes) and inconsistent ("The thugs quickly move the crate and cart out of the way", when there is only one thug, and the current location no longer has a crate or cart). The game is not difficult, and most players should be able to complete it without too much effort, but the sparse instructions and messy technical problems make it tough to envision this as an appropriate game for beginning IF players.

The Sleeping Princess is a game that I think would fare better with beginning IF players. It is very short and has only a handful of fairly well-conceived puzzles which require the player to perform a small variety of actions, including speaking with an NPC. I did not come across any inconsistencies or errors except, unfortunately, for my first command of the game (EXAMINE PORTRAIT gave no response at all), and some minor contextual issues while speaking with Willy. I think some beginners might be slightly frustrated by having to completely drop every item before descending through the trap door -- is it really necessary to drop a key, for instance? -- but overall it's a minor issue. The instructions (which I believe are the default for TADS3) are incredibly lengthy and I can't imagine beginners not being intimidated by them, but they do give a very good overview of IF. It also uses the nice stepwise and context-sensitive HINT system, which is good for new players. Although the game itself is not terribly engaging, it does a reasonaly good job introducing new players to IF, and may induce some to try other games.

I thought Mrs. Pepper's Nasty Secret, on the other hand, is a very good introduction to IF for new players. Although it also includes the same impressively lengthy default TADS3 instructions as The Sleeping Princess, it does contain very good game-specific instructions, a stepwise and context-sensitive HINT system, and the option to include extra hints that can help new players to understand game mechanics as they play. I found the latter to be very effective. This game is longer than the others, and makes use of a variety of classic puzzles, most of which I found intuitive and not very difficult; the in-game text did an effective job pointing the player in the right direction. The content kept my interest throughout, especially the use of magic spells and the way they were implemented. The game is very polished, well-tested, and forgiving -- I would expect as much from the authors, and they delivered. In all, I think it would be a nice game for new IF players.

I haven't yet played the others, but I think the IFBG has already succeeded in one respect: it has recognized the importance of having well-written, tested, and forgiving games with which to introduce new players to IF, and has induced authors to write them. I think prospective players are too easily turned off these days by poorly written or tested games, or games that are too large or complex. Having short, simple games that enable new players to become comfortable with IF game mechanics is one key to expanding the audience for IF, and there is at least one entry that I believe does this well.

The Sentimental Sound of Spinning

Like many nerds, I get nostalgic when I think back to my childhood in the mid-late 70s and 80s and the computer games that I played during those years. Best I can remember, it started with the original Colossal Cave adventure on my dad's enormous NorthStar Horizon computer, with its wooden case and dual 5.25" floppy disk drives. Later, it was some of Scott Adams's great text adventures like Adventureland and Pirate Adventure, and a host of other text-based games like the old Star Trek grid game and even an old game about the Battle of Midway very similar to this one. Not to mention a whole mess of games that I typed in by hand from David Ahl's incredibly awesome book from 1978.

Then it was on to the famous Apple ][ days. I spent countless hours with so many games, I couldn't possibly remember even a fraction of them. But there are certainly those that stand out in my memory: Planetfall, Deadline, Castle Wolfenstein, Lode Runner, Karateka, Mask of the Sun, Prince of Persia, The Prisoner. And of course, Wizardry.

I have seen and tried a few Apple ][ emulators in the past, and I've been able to play a few of those old games again. Some don't run properly, some don't run at all. But many of them do, and it was great fun to see those old games again. But a little while ago, I came across an emulator I hadn't heard of before: Virtual ][, a program that emulates the Apple ][, ][+, and //e. It's a great piece of software, with a lot of cool features, like being able to save a virtual machine and load it back in later to resume. But one of its best features is that it not only emulates the machine, it also emulates the peripherals, including the floppy drives.



The images of the drives at the bottom correspond to the two available floppy drives. To use them, you click on one and specify which "disk" file to load into the drive. The fascinating part of this, to me, is that the emulator does three things: (1) it emulates the Apple ][ at its native speed, so programs "load" from the drive at the same speed they did back in the day, (2) it animates the red light on the floppy drive, and it lights at the appropriate times (not just randomly), and (3) it actually emulates the real sounds the drives used to make -- the sound of the drive door opening and closing, as well as the sound of the drive spinning and reading from the floppies.

I emphasized the last part because I think it's a really important point. Hearing the old sound of the Apple ][ floppy drive, I realized how much of an impact that spinning sound had on me as a kid, and how the sound of the drive was really a significant part of computing (and gaming) back then. In some cases, I had booted, loaded, and played certain games so many times that the specific pattern of sounds made by the drive as the game ran was burned into my memory. I can still remember some, like the sounds from Wizardry and The Prisoner. Firing up Virtual ][ and loading in those games brought back memories not just from seeing and playing the games, but also from hearing the same floppy drive sound patterns that I remember from childhood.

But it also got me to thinking of some of those old text adventure games on my dad's NorthStar Horizon, like Colossal Cave. Although I don't recall any specific sound patterns from the big floppy drive the same way that I do for the Apple ][, the sound of the spinning drive still had significant meaning. Back then, when there wasn't much memory to spare, a lot of information was read from the drive as it was needed. So as I played those adventure games, I would type in a command, wait a few seconds for the computer to process the command, and listen...waiting expectantly for the drive to start up again, which meant the game needed some new information from the floppy. I had done something different. The result, I hoped, would be a new message indicating I had figured out something in the game, and had made some progress.

Occasionally, I would stay up late into the night, playing Colossal Cave or some other text adventure, in the darkened living room with only the glow of the terminal. Sometimes, I would wait so anxiously that the sound of the floppy drive starting up again would give me shivers. It was an important sound. It was inseparable from computing, an odd byproduct of the limitations of those systems. It's something that, with gigabyte hard drives and RAM modules, has disappeared from the computing experience.

I'm fine with that -- I much prefer the ultra-fast loading times we get today to the strangely melodic sounds of a slowly spinning floppy drive. Still, I'm glad to have been able to experience those sounds, both back in the day and again with Virtual ][, and to realize the importance that those sounds played in the old gaming experience. Or at least my gaming experience.

It kind of reminds me of a scene from the movie "American Beauty", when the main character (Lester) is buying some pot from the next door neighbor's kid (Ricky):

Lester: "Well, now I know how you can afford all this equipment. When I was your age, I flipped burgers all summer just to be able to buy an eight track."

Ricky: "That sucks."

Lester: "No actually, it was great."

Kind of like those slow, loud floppy drives, and the sound of the spinning.

Vespers Update 2/18

Time for another update, the first since starting this blog. There has been some progress in a few areas, although perhaps not enough to warrant one of my more extensive blogs like on GarageGames.

Characters and Animation

Happily, we've finally replaced our previous animator, who left us for more prosperous opportunities. In his place we now have two individuals helping with the character animations, James and Matt, which I hardly have to say is a real gift. Progress on the new characters has been slow so far as we get those two up to speed and comfortable with the art flow. We've also made a few adjustments to what we were doing previously; in addition to entirely new character rigs, we've also been experimenting with a system to provide some pretty nifty lip syncing to go with the voices.

The lip sync process uses a software program called Magpie Pro, which takes the rigged model from 3ds Max and an audio file, analyzes the audio, and generates a text data file that contains all of the keyframe information for setting the model to the accompanying audio. That data file can then be read into 3ds Max, which creates and sets all of the necessary keyframes. It takes a lot of up-front work to rig the model's mouth so that you can create each of the necessary phonemes, but once that's done it's a relatively easy process to generate the data files and import them into Max.

This level of lip syncing may end up being more work than it's worth, but the results so far are pretty impressive and I think it will add to the immersiveness of the game. I'm really looking forward to seeing it in action.

So right now we have Marc working on Ignatius, and James working on Drogo, which should keep me pretty busy in the coming weeks. Both characters are fully rigged, including the facial rigs, and the Ignatius data from Magpie is all ready to go. I'm hoping to see some big progress very soon.

Models

N.R. has been slaving away for us recently, with some pretty awesome results. He's been finishing up the last batch of primary objects to populate the monastery, focusing mostly on the kitchen and dormitory.

Some of his latest work has been a new version of the bed, complete with straw mattress, as well as Constantin's tools and keys. In the text game, the tools actually consisted only of a hammer and some nails, but we decided to expand them a bit to a hammer, tongs, and punch.

The punch can functionally take the place of the nails in the game. We decided to implement all three of the tools as one object to simplify things, although the player can refer to them individually, if desired.


We have a few more objects to create for the kitchen to make it more recognizable -- some pots and pans, some plates to place on the shelves, and some empty hooks for the ceiling. Once these objects are done, that would finish most of the important scenery objects in the game, which would be a nice accomplishment. We'll still need a few more environmental additions to give the place more atmosphere, but the majority of the object work will be done.


In the meantime, N.R. is focusing his attention on the monastery, and trying to portalize the interiors to help optimize performance. Portal construction, as it turns out, is one of the more cruel practical jokes the world of Torque plays on its artists. It's a very complicated and time-consuming process, not to mention fussy and hypersensitive. Breath incorrectly while you're creating portals, and either the exporter will throw up on you or the game engine will laugh in your face. I think it's definitely testing N.R.'s patience. It's unfortunate that it's such a critical part of our model, but if we can get it working I think it will really boost our framerates. I'm keeping my fingers crossed.

Code

Not a whole lot new on the code front. I've mostly been installing more verbs lately, verbs like EAT, DRINK, LOCK, and UNLOCK. New verbs are fairly easy to implement, although the code for performing the actions on specific objects can get a little complicated when they involve playing animations (like for LOCK and UNLOCK) or switching models (like for EAT).

The other significant piece of code that I implemented recently is the "implied take" process. It's commonplace in IF games to allow the player to perform actions on objects without first possessing the object -- in such cases, the engine performs an "implied take". Basically, if the player tries to perform an act that requires possession of the object, the engine will insert a "TAKE" command prior to performing the action. So for instance, if the player tries to UNLOCK HATCH WITH KEYS while the keys are sitting on the floor next to him, the typical IF engine will first perform a TAKE KEYS command before performing the UNLOCK action (if the TAKE action is successful). Most engines will respond with a line such as "(first taking the keys)" or some such message, so this is how I implemented it.

It turns out to be a fairly complicated process. In most cases like this, I would just generate a "TAKE OBJECT" command and run it through the parser, but because of issues that deal with text output (for delivering the appropriate message) and remembering the previous command entered, this would cause problems with my parser. So instead I had to create a separate "implied take" function, and shoehorn it into the existing code.

It wasn't pretty, but on the bright side it did allow me to discover and fix a few previously unknown bugs in the parser. It's working now, but I haven't tested it extensively. Hopefully I didn't end up breaking something else.

There's also the issue of other "implied" verbs, which I haven't tackled yet. I know that opening doors can also trigger an "implied unlock" command, as is done in the game "All Things Devours" (which I highly recommend), for example. I'm not sure how many other implied verbs there are, so it will probably take a bit of searching around.

That's about all for now. Hopefully soon I'll be able to give a more extensive update on our character development, and with any luck perhaps a report on our successful implementation of portals.

IGF Ramblings and XYZZY Awards

Just a couple of thoughts as I daydream about what it would be like to have a game nominated as a finalist for IGF...

I really wanted to try to go to GDC this year, finally, to get a glimpse of what it's like. Alas, it was not to be. Another work trip this week made it too complicated to try and do both, especially with a busy week ahead of me and the in-laws coming for a visit this next weekend. Ah well. Next year, I think.

Speaking of which, thanks to TRC and Scorpia for posting and linking to the finalists for this year's IGF. I'm a little disappointed that we don't have any real adventure games in the list this year -- I guess we haven't seen enough innovation with graphical or text adventure games to catch the attention of the judges.

I was also a little disappointed to see how difficult it was to find Mac versions of the finalists. They may be available and I'm just missing them, but best I can tell most are PC-only. I did get a chance to play a couple of the browser games, including Iron Dukes and Tri-achnid.

Iron Dukes is well done, and I like the style, with its fictional late 19th century theme. I enjoyed playing the brief demo, although there was not much in the graphical presentation or gameplay that came across as really innovative. I liked the simple RPG-like elements that intertwined with the treasure finding, though. During one play-through, I quickly recovered two treasure items worth $13,500 each, giving me a lot of cash to work with, and I was really impressed at the sheer number of items available for purchase -- it looks the full version of the game will be quite large. Some of them were a little questionable, though. "Authentic Squid Tits" and "Caucasian Semblance"? Hmm. I'll definitely check out the full version of this.

Tri-achnid looks to be an interesting experimental game, but I had a lot of trouble with the controls during my brief time with the game. It was enough trouble that I gave up on it relatively quickly, but when I have some time I'll go back, re-read the instructions, and give it another try. Overall it looks intriguing to me.

For the others, looks like I'll have to boot into Windows. I plan on checking out Goo! and Snapshot Adventures: Secret of Bird Island, which I suppose is the closest of the finalists to an actual adventure game. If I get the chance I'll also check out Audiosurf and Synaesthete, both of which appear to incorporate music into game play in interesting ways.

In other news, as Emily Short has pointed out, it's that time of year again, time for the first-round of voting for the XYZZY awards for the best IF games of 2007. The nomination form and full list of entrants can be found here. Thanks to Emily and others for highlighting this.

Implementing an IF interface in 3D

Most of today's graphical adventure games eschew text input and output for more streamlined, symbolic interfaces and visual feedback. The typical IF game is somewhat unique these days in that it relies entirely on text for both purposes. There are advantages and disadvantages to each interface type, but what I want to know is, could a hybrid IF-like interface work in a 3D graphical game?

Rather than going into the why, I thought I'd discuss the what, so at least you'll have an idea what I'm talking about and how it might work. Cue the screen shot.



This is a shot of the kitchen, which is still a work in progress. The cupboard is to the left, a table is straight ahead, and a locked hatch in the floor is in the back to the right. At the bottom of the screen is the text output window. Here's a close-up:



The box above the text output window is the command entry window. It pops up when you hit the SPACE bar. You can still move the camera around and click on objects while it's open, although all keypresses are sent to the entry window while it's open.

I wanted to design the interface so that people comfortable with IF could play the game almost entirely with text entry, if they so prefer, even though I don't expect that to be the case. The main exception is movement; there are no text commands directly related to movement, such as compass directions, IN/OUT, UP/DOWN, and so on. These are all performed via the typical FPS-style W-A-S-D setup, with the mouse used for camera panning. But aside from that, most other commands can be entered through the command entry window.

The parser was designed to be comparable to other common parsers, like those from Inform or TADS. It can handle things like actions on multiple objects ("Take the food and the keys"), disambiguation ("Which door did you mean, the bedroom door or the locutory door?"), and completion ("What do you want to unlock the hatch with?"), although I suspect the ability to select objects visually will eliminate much of the need for these. Common abbreviations are supported, such as X for examine, G for again, I for inventory, and so on, although these actions can also be performed by pressing the appropriate key, without having to bring up the command entry window. So "I" will bring up the inventory window, without having to hit SPACE-"I"-ENTER.

Speaking of the inventory, it is implemented graphically as well as through text. The common text presentation is preserved for those comfortable with it, but it is also presented as a separate window:



The items in the inventory are selectable with the mouse, which will then allow you to perform actions on them. So, if you click on the keys to select them (as above), and then hit the "X" key, that would be the equivalent of bringing up the command entry window and typing EXAMINE KEYS.

Despite the inclusion of (and emphasis on) a text input interface, point-and-click is provided and is very useful. Clicking on objects to select them results in the object becoming highlighted visually, as with the cupboard door below:



Once an object is selected, it can then be acted upon either through single-key commands (such as X for EXAMINE, or O for OPEN) or through the command entry window. In the case of the latter, the act of selecting an object allows the player to exclude the object from the text command -- it is automatically assumed to be the object acted upon. So in the example above, with the cupboard door selected, the player could just bring up the command window and enter OPEN, which would be interpreted as OPEN CUPBOARD DOOR.

The same applies for commands requiring two objects, such as unlocking the kitchen hatch:



By selecting the lock, the command can be abbreviated to just UNLOCK WITH KEY, and the parser will interpret the command as UNLOCK LOCK WITH KEY. Likewise, if the inventory screen was open and the key was selected, the player could type UNLOCK LOCK, and the parser would interpret that the same way.

As alluded to in the image above, there are other ways to simplify the performance of actions. The middle mouse button (usually a clickable mouse wheel) can be set to perform one of a list of common actions. Scrolling the mouse wheel flips between the different options, which right now are LOOK, TAKE, EXAMINE, and INVENTORY. Each rotation of the wheel is the equivalent of entering the command "SET MIDDLE MOUSE BUTTON TO < action >" in the entry window, so this could also be done directly via text. Then clicking the middle mouse button performs the action. I typically have it set to TAKE, so I just need to click on an object with the left mouse button to select it, followed by the middle mouse button to TAKE it.

The other customizable key is the TAB key. By default this is set to INVENTORY, but it can also be set to one of the commands above as well using the "SET TAB TO < action >" command.

Aside from the middle mouse button mentioned above, the mouse is reserved for selecting objects (left mouse button) and camera panning (right mouse button click and drag).

It's a lot to remember, no question. I think it will be perceived as a barrier by many people, particularly newcomers. But I do think the basics are fairly straightforward. Most of the shortcuts will probably take some time for players to remember and become comfortable with them, but once they do I think players will be surprised how streamlined most commands are, while still allowing for more advanced command input with the entry window -- which itself can be faster than in traditional IF.

Of course, this is still very much a work in progress, so it will undoubtedly change over time. I thought it would be useful to show how I've approached incorporating an IF-like interface into a 3D world, for future discussions as well as to solicit opinions and suggestions. Both are welcome and appreciated.

A Verb Analysis in IF

While preparing some blogs to discuss things like my decision to use a text parser for command input, the oversimplification of the adventure game interface, and a demonstration of our hybrid interface, I started thinking about all of the different verbs used when playing interactive fiction. Because when you really get down to it, the real heart of an adventure game -- aside from the salient features like writing, story, and characters -- is arguably the verbs.

My impression is that the vast majority of commands in IF are limited to a few categories, like movement or examining. But once you get beyond those common actions, you find the jucier verbs, the ones that seem to have a larger impact on advancing the game and the story. Verbs like PUSH, PUT, WEAR, TURN, or BREAK. And then the rare verbs, the ones that are used maybe once or twice in a game, but have a specific purpose and impact. Like DISLODGE, SUMMON, or ARREST.

But how often are these verbs used in a typical game, and how many of these jucier verbs are there, really?

That's actually a complicated question, for a number of reasons. The main issue is that the frequency of verb use is highly dependent on individual game design, as well as the person playing the game. The frequency of verb use is very different when you compare an experienced IF player with an inexperienced one, and playing style is important, too (I tend to overuse LOOK, EXAMINE, and INVENTORY, for instance -- who knows why, I think it just gives me a sense of "buying time," so to speak, which is silly since IF is turn-based). And it's also very different if you compare a relatively short game, such as those in the annual IF Comp, with a more full-length game.

But in an attempt to initially explore this question, I've decided to take the relatively easy and straightforward route: I downloaded the published walkthroughs for three games entered into the IF Comp in the recent past, and compiled a breakdown of the verbs required for each. Note that these walkthroughs are not necessarily fast solutions -- they include commands that are technically unnecessary for solving the game, but which provide a more complete experience of the game for players who follow them. Still, these are by no means game transcripts, so they don't really reflect the typical use of verbs that one might expect from players. As such, I expect there is a significant underrepresentation of verbs such as EXAMINE, LOOK, SEARCH, ASK, and INVENTORY, among others.

The three games I decided to look at are Floatpoint (by Emily Short), The Elysium Enigma (by Eric Eve), and Tales of the Traveling Swordsman (by Mike Snyder). Below are the breakdowns from each of these games. In order to avoid any spoilers, I chose to leave the graphs unlabeled, and to erase the labels of the least common verbs. I have also grouped together all movement verbs into one group, which includes the compass directions, plus verbs like IN, OUT, ENTER, EXIT, and UP and DOWN.





What to take from all of this?

Well, not a lot, really, given that it's a very small, very biased sample. That said, I think it's no surprise that movement commands and EXAMINE make up a huge chunk of the verbs. But it's interesting that, once you get beyond that, it can be pretty variable, which I think is largely a reflection on game design. It's pretty fascinating that if you look at the top 10 verbs beyond movement and EXAMINE, they are quite different between games.

What I find most interesting from this is the surprisingly large number of verbs included in the walkthroughs for these games. The totals ranged from 34 up to 65. Granted, not all of these are verbs (such as the responses YES and NO), but it's still a surprising range of input. And that doesn't necessarily account for synonyms.

Of course, many of these verbs act on specific objects, and many of those actions are, generally speaking, the only important actions one could perform on those objects. So in theory many of these verbs could be replaced with the generic "use" verb, or a simple context-sensitive menu, as is often done these days in graphical adventure games to simplify the interface. It's more efficient, and players don't have to think about what specific action they want to perform. Plus, it eliminates any "guess the verb" frustrations.

Still, many of these verbs don't act on objects, and provide a deeper level of interaction with the game world. And I think there is definitely something to be said about forcing the player to think about -- and explicitly state -- what he or she wants to do next. Figuring out what to do, not just how to do it, can be part of the challenge of an adventure game, and I think it's something that is missing from today's simplified interfaces.

Many people might respond with a "good riddance", and perhaps that's how most people feel since the market has shown that the simplified interface has been quite successful. But just as I believe there is a role for text output in a graphical adventure game, I also believe there is still a role for text command input, to potentially broaden and deepen the player's experience.

I should state that, with Vespers, we really will have more of a hybrid interface. Movement, of course, will be handled as with many typical FPS games, and many other common commands will be able to be entered quickly, either via the mouse or a single key. That will eliminate a lot of the typing, but it will certainly leave a considerable amount.

Will people see it as a benefit or a barrier? Who knows. That's all part of the experiment. It's one of the things I like about being an indie -- you're not just forced to design to the lowest common denominator.

Oh, and I suppose you might be wondering about the text version of Vespers. Here's the breakdown. Fewer verbs required than some other games, but still a pretty good number. Plus, the walkthrough leaves out a few verbs, and there are also three different walkthroughs, so others might be slightly different.

Al Lowe on adventure puzzles...and text?

Rock, Paper, Shotgun has posted a nice interview with Al Lowe, the creator of the famous Leisure Suit Larry series of games from Sierra. I recommend checking it out, as Al provides a nice perspective on those old Sierra games and the current adventure game market.

In it, Al makes an interesting observation that I think is important to reflect upon:

---

RPS: I’ve noticed that we seem to have lost our patience with puzzles. Developers seem to be frightened of a player getting stuck. Why do you think this happened?

AL: I have a definite thought on this. I hesitate to share it as I don’t want it to come out sounding the wrong way, but I believe that in the early 80s, you had to be ridiculously determined just to make those damned computers work. It was near impossible. Set high mem. Deal with QEMM. Customize boot up settings. Hell, I had a whole subdirectory full of autoexec.bat and config.sys files…

RPS: [Large groan as the hideous memories came flooding back]

AL: … I would save off the current pair of files into a subdirectory and copy up another pair so I reboot, all just to run a game. I probably had ten different set-ups. Just geeky shit like that drove people crazy. So puzzle solving was a requirement just to get the damned things to work. And therefore puzzle solving in games fell right into place. It’s what you were already doing. And the parser? It was just like the DOS prompt. You got a flashing cursor and that’s all. If you didn’t know what to type, you had to try things until something worked. Our games were that way. The cursor would flash and you’d think, “What am I supposed to do now?” I remember a conversation once where we speculated, “Won’t it be wonderful when 10% of American households have a computer? Think how great sales will be?” Well, now it’s well over 50% and the people that we added aren’t the people who subscribe to Games Magazine, or solve New York Times crossword puzzles, or watch PBS or BBC America. They’re the people who watch Fox! Their demands for entertainment didn’t include slapping your forehead over and over while you tried to figure out what to do next. They wanted some action… and wanted it now!

---

An interesting point, for certain, but I think you could apply this answer not just to the question, "Why might players be less tolerant of puzzles?" but also, "Why might players be less tolerant of text-based input in games?"

I think it's a great point that, back in the 80s (and even into the early 90s), the graphical user interface wasn't nearly as ubiquitous as it is now. Heck, I can attest that even the University of Utah hospital in 1997 was still using a DOS-based computer system -- no graphical interface at all. People were used to operating with text. Like Al says, you got a flashing cursor and that's all, and "if you didn't know what to type, you had to try things until something worked." Text was how we communicated, whether with games or with operating systems.

I think there are probably a few things operating here:

1. Perhaps, as the graphical interface became more widespread, people became less tolerant of having to use the keyboard. You could accomplish most things with the mouse, in a much simpler and straightforward fashion. The interface for adventure games likely followed suit, with text commands eventually being replaced with mouse-driven command options, and in many cases with just a simple point-and-click interface.

2. Back then -- and this could be pure recall bias -- it seemed that you had to know more about how to use a computer than you do now. The text interface almost demanded it. But with the rise of the graphical interface, alongside the rise in popularity of computers in general, we perhaps now find that many (if not most) computer users know little about the systems they use. It's one of the main functions of the graphical interface: replacing arcane and enigmatic text commands with simpler and more natural visual representations. Perhaps the old text interface allowed people to be more comfortable with this type of system interaction.

The continued -- and growing -- use of Linux would possibly argue against this to some degree, but I think you could even argue that Linux is rising in popularity, at least in part, because of the graphical interfaces that are now available for it.

A lot of adventure gamers out there now prefer the simpler interface, whether it's as simple as point-and-click, or mouse-driven contextual menus. Text parsers, I believe, have borne the brunt of the responsibility for this, but I think the argument above contributes a great deal as well -- there exists now an alternative which is simpler and less finicky. Text as an input method in games has been all but abandoned, except for the persistent interactive fiction crowd.

With Vespers, I have decided to use text-based input for a number of reasons, which I will likely address in future blogs. But the interface, like the game, is really a hybrid -- there is a point-and-click interface with mouse-driven commands in addition to the text parser. I think, if you could look at transcripts of a large sample of IF games, that the vast majority of commands issued by players would amount to the compass directions and movement (N,S,E,W), LOOK, EXAMINE, TAKE, and INVENTORY. I don't have any hard numbers to back me up, but I would guess that these would account for somewhere around 75%-80% of all commands in a given game. In our hybrid game, these are all commands that can be issued with either the mouse or with a single key on the keyboard (e.g., X for EXAMINE).

Still, will players tolerate any text input? In general, I think players don't like the thought of having to use the keyboard -- or to switch between the mouse and keyboard. But we'll see. I think the benefits, which I'll discuss later, still outweigh what I feel is a (relatively) small inconvenience.

Catching up with Vespers

Although The Monk's Brew is a new blog, I've been blogging for some time on my progress with Vespers over at GarageGames.com, the makers of the 3D engine I am using (Torque Game Engine). I thought the beginning of this blog would be a good place to collect those initial reports, in case anyone would ever care to go back and review my development process and progress. All new blogs from this point will be posted here on TMB. Here are the links to the blogs, in chronological order:

Chasing Windmills?
11/8/05
In which I first discuss my decision to pursue a hybrid of interactive fiction and a first-person 3D engine.

"Vespers3D"
12/30/05
In which I discuss my initial attempts at creating a text parser within the Torque Game Engine, and my enlistment of Jason Devlin and "Vespers" as the experimental game.

Vespers3D: The Adventure of Text Parsing
3/9/06
I which I discuss some of the challenges of implementing a text parser within a 3D world, partcularly how to deal with objects that don't have physical representation in the 3D environment.

Vespers3D: The Adventure Continues
5/31/06
In which I discuss the implementation of the visual inventory, visual object higlighting, and the horrors of text parsing such as disambiguation and multiple objects.

Vespers3D: Living the Adventure
10/16/06
In which I discuss our choice of company name (Orange River Studio), customizing command inputs, a new opening intro sequence, and the implementation of purely informational verbs such as LOOK, LISTEN, and EXAMINE within a 3D environment.

Vespers3D: Adventuring Along
1/22/07
In which I discuss implementing command completion within the text parser, the introduction of our first NPC (Matteo), and the auditions for our voiceovers.

Vespers3D: Adventures in Cinematics, Part I
4/26/07
In which I discuss how I implemented the cinematic animations in the game using a sequence manager and triggers.

Vespers3D: Adventures in Cinematics, Part II
6/17/07
In which I continue to discuss the implementation of the sequence manager and animation states.

Vespers3D: Adventures with NPCs, Part I
6/30/07
In which I discuss the development of our first NPC, Matteo, from text to concept to animated and voice-acted 3D model.

Vespers3D: Adventures with NPCs, Part II
7/25/07
In which I discuss the development of our second NPC, Constantin, from text to concept to animated and voice-acted 3D model.

Vespers3D: Visibility Issues in 3D
8/6/07
In which I discuss some of the real problems with referencing objects in a 3D world due to complex collisions and collision checking.

Vespers3D: Adventures with NPCs, Part III
9/3/07
In which I discuss the development of our third NPC, Lucca, from text to concept to animated and voice-acted 3D model.

Vespers3D: Adventuring Onward
12/28/07
In which I discuss ongoing issues with animation, the new opening intro sequence and music, and the implementation of the objects in the church.

Welcome

Welcome to The Monk's Brew.

This is a blog about a number of things, but if I had to summarize it, I would say that it is a blog that presents an indie game developer's perspective on computer game design, development, and play. Although not limited to one game genre, the focus will tend to be on adventure games, including a focus on interactive fiction and its contributions to indie gaming and design.

The main context of this blog is the ongoing development of Vespers, an indie game project that I started back in 2006. As with many indie games, Vespers is an experiment. This experiment attempts to answer the question, "What would happen if you took a traditional interactive fiction game and dropped it into a 3D first-person graphic engine?" It is based upon the interactive fiction game of the same name, written by Jason Devlin in 2005. I found it to be a wonderfully written game, with excellent non-player characters, great imagery, and a compelling storyline.

I thought Vespers would make a great basis for my experiment. I wanted to know what it would be like to see, explore, and interact with this world in real-time, while preserving the distinct advantages of text as a method of communication -- both input and output. Jason graciously agreed to allow it, and to assist with the long transition.

You can play the IF version of Vespers online for free at this link.

Along the way, I've come across some fascinating issues in the transition from a pure text environment to a graphics-text hybrid, and many of these issues have had a strong impact on design and development decisions. The process has also led to a greater awareness of game design and theory in general, particularly as it relates to story-driven games. It fits neatly into numerous ongoing discussions of game design and gameplay, including the issues surrounding linear vs. sandbox approaches, and real-time vs. turn-based play. This project provides the context and the opportunity to include my voice in these discussions.

In addition to Vespers, blog material will originate from several places, including:

• mainstream games -- predominantly adventure games (such as Dreamfall), but really any games that provide interesting examples of gameplay and game design;
  
• literature, including excellent reference works such as Nick Montfort's Twisty Little Passages and Pat Harrigan's and Noah Wardrip-Fruin's Second Person, as well as works by Chris Crawford;
  
• mainstream articles and blogs, such as from Gamasutra;
  
• other indie gamer blogs, such as Tales of the Rampant Coyote (a great blog that focuses on the indie game scene, particularly with respect to RPG games) and Grand Text Auto (a group blog with an academic spin on digital fiction and storytelling);
  
• other indie game projects;
  
• and much more.
  

The main goal is to generate discussion and to explore the many aspects of indie game development. I hope you find the content compelling and the opportunity to contribute your comments.