Interactive Fiction – Weaponized Fluff

Obduction Seduction

Obduction is a relatively recent graphical adventure game by the creators of Myst. I played it recently and have some thoughts.

Hey, have you heard of Obduction? A graphical adventure game by the guys who made Myst, but released within the last decade?

In most ways, it really is just another Myst, though the story and setting are unrelated. Did you love Myst? Then you’ll love Obduction.

Never played Myst? How do lush graphics, fantastical world building, and atmospheric music sound to you?

“Adventure games” are also known as “interactive fiction”, because there’s a story behind all the locked doors, all the unexplained mysteries, all the obstacles you have to overcome.

The best IF shines where the time it takes you to solve the puzzles adds to the suspense of the narrative.

If that’s true, then boy did my experience have a lot of suspense.

There were two points where I got really stuck. Just couldn’t think of how to move forward. Got more and more frustrated.

In the past, I’ve often given in and looked at hints or walkthroughs. The trouble with that, for me at least, is that once I’ve looked at one hint, it’s almost impossible not to look at the next, and the next. The game becomes a plodding exercise in following instructions, and I almost always give up.

With Obduction, given that, nowadays, I personally have many hours inside with few distractions, I decided to tough it out. And indeed, even if it took days and days, after looking around over and over, I would eventually have a stray thought come in to my head, a new thing to try. The puzzle never turned out to be particularly fiendish or unexpected, it was always something simple I missed.

The game works fine on modern hardware, with one exception: the documents (and there are many) are blurred and almost unreadable on Retina displays. The only way I was able to read them was to connect my laptop up to an older, non-Retina display, and switch the game to full-screen mode.

I suspect that the graphical optimizations from as little as 7 years ago don’t play well with Retina.

I took copious notes and, based on my experiences and the under-annotated drawings provided in the game itself, constructed detailed maps. I suppose in the end that’s why I’m writing this post: to show off my maps. While everything else in this post is light on spoilers, the maps have a lot of spoilers in them, so only look if you don’t plan on playing the game.

Enjoy!

A TADS TADS TADS TADS World

The TADS interpreter scene on Mac OS X is a bit like the browser scene. There are more of them than you’d expect for a minority platform, and they embody different philosophical approaches.

The saying goes: “Cheap, fast, or good: pick two.” I tried “perfect” with my MacTADS project and wound up never finishing it at all, so it’s no surprise that the authors of the following interpreters made a different set of compromises in order to get their applications out the door.

(The observations below are more about the UI than a detailed review of gameplay.)

QTads
First, Nikos Chantziaras wrote FrobTADS, a command-line port of TADS that replaces the old, crufty port mentioned in this post and used in Uli Kusterer’s TADS Workbench for Macintosh.

Second, he built a GUI TADS interpreter on top of that, called QTads. As ANSI C and POSIX are to FrobTADS, Trolltech‘s Qt library is to QTads: if you support those APIs, FrobTADS and QTads respectively can be built for your platform.

This approach led to a full-featured interpreter for the Mac platform without needing someone to commit full-time to it. QTads even has some niceties not in other Mac interpreters, such as a font/color “preview” panel and theme sets.

The downside is that QTads is a Mac application the same way Eclipse is a Mac application. Colorful, but not exactly native-looking:

Huh, an Exit menu item? Never fear, there’s still a regular Quit menu item under the Application menu, but this goes to show we’re not in Cocoa anymore.

As another example, have a look at these two lower right-hand corners of windows:


QTads	NetNewsWire

QTads has an ugly black outline around its main scroll view, and its window grow box is half the size of a native Macintosh window grow box. NetNewsWire’s version is provided for comparison.

Finally, if you resize the window, you’ll notice some flickering. QTads eschews OS X’s double-buffering, and instead erases and redraws the edges of its window right before your eyes.

Some of this might be fixable with more work on Qt, but some of it is a deliberate, un-Mac-like style that comes with the territory.

Cugel
Cugel’s author made a different set of compromises. Native? Check. Full-featured user interface? Well, not really. For example, there’s no status bar area at the bottom for a “more” prompt. Such a bar doesn’t come native with the Cocoa scroll view, which is why my in-progress Neutrino main window doesn’t have one yet, either.

But what you get instead is a “Unified Interactive Fiction Player.” It can play not only TADS games, but also Hugo games, Alan games, Glulxe-based games (supported by Inform), and others.

It’s actually pretty cool to look in the Cugel package and see the individual interpreter utilities for all these languages.

Ben Hines MaxTADS OS X port
Ben Hines made a third set of compromises. My impression is that in 2002, he saw that there was already a perfectly good OS 9 TADS interpreter, Andrew Plotkin’s MaxTADS. He also saw that Apple provided a quick way to port such Toolbox-based code to OS X, the Carbon APIs.

So he “ported” MaxTADS to Carbon, and by “ported” I mean that he made the fewest changes possible to the codebase and resources so it would build and run as a Carbon application on 9 and X. The UI remained entirely unchanged, and it looks more and more anomalous on subsequent versions of OS X. For example:

MaxTADS Carbon Port UI

Yes, that’s a System 7-style textbox you see!

Here’s another issue. Two quit menus:

The Cmd-Q keystroke shortcut does nothing, by the way. You have to select the menu item by mouse.

The upside of all the hurried work? This was the very first native OS X TADS GUI-based interpreter. The other two interpreters mentioned above were released two years or more after this MaxTADS port.

..Than a Speeding Neutrino

I’ve talked about my travails using Subversion and getting unit testing set up. I was mysteriously vague about what it was all for…

…Until now. (Cue ominous music!)

It’s for an application called Neutrino, which will allow you to do something on a new Mac 1-2 years from now that you otherwise wouldn’t be able to do.

Word by Word
Neutrino is a TADS multimedia interpreter written in Cocoa using Xcode. Let’s break that down:

TADS: “Text Adventure Development System,” a special-purpose programming language, library, and virtual machine for both writing and playing interactive fiction a.k.a. text adventure games. Wikipedia has some history on it.

multimedia: When TADS was first introduced, it was strictly T, for textual. Its author, Michael Roberts, eventually decided to add some multimedia capabilities to it. He called it HTML-TADS, because the way to add these elements was via a simplified and customized form of HTML markup. There are only two interpreters that can fully display such content, the TADS interpreter for Windows that Michael Roberts himself wrote, and HyperTADS for the Mac, by Iain Merrick.

interpreter: TADS source code is not compiled to native CPU instructions, nor does it use specific operating system APIs. Instead, it’s compiled to be played in its own virtual machine maintained by a platform-specific interpreter, like Java source is compiled to run on a Java virtual machine.

Cocoa/Xcode: Because Neutrino is written using these technologies, I will be able to release a “universal binary” version of Neutrino, that will work on both PowerPC Macintoshes, and the Intel Macintoshes that will be released over the next several years. (Carbon/Xcode would be another possibility.)

History
For TADS’ early history, the sole Macintosh interpreter was also maintained by Michael Roberts. It used the early Toolbox TextEdit APIs, though, so it was limited to 32K of text scrollback. Plus, it didn’t display any styled text at all.

Once TADS went open source, Andrew Plotkin wrote a new interpreter for it, called MaxTADS. It had all the bells and whistles and matched in both style and name his interpreter for Z-code games, MaxZip.

When HTML-TADS arrived, HyperTADS was written to handle it, since MaxTADS remained text-only.

This all happened before OS X was released.

Current Interpreters
Today, there are three native TADS interpreters that I know of for OS X. Ben Hines did a quick-and-dirty Carbonization of MaxTADS in 2002. Recently, the more substantial ports QTads and Cugel have been released, and are under active development. I do a more thorough review of these interpreters (or at least of their UI) in this post.

So the native interpreters won’t display multimedia game content, and the one Mac multimedia interpreter is non-native and won’t run on Intel Macs.

Answer to the Riddle
If you buy a new Mac 1-2 years from now, and you want to play HTML-TADS games like Six Stories or Arrival or Exhibition to their fullest, you will be out of luck, unless I get my ass in gear and finish Neutrino.

Oh, yeah, one last note: it’s not finished yet. In fact, it’s probably about 10-25% done. But here’s a screenshot:

Neutrino Screenshot

I Think I Myst Again

What have I been doing with all this free time I accumulate by not writing weblog entries for weeks and weeks?

Playing Myst IV, of course!

I won’t be the first person to talk about its interface flaws, but talk I will:

1. No access to regular application menu. This means going through their clunky custom interface to open and save games and bring up preferences. This has gotten worse since previous Mysts.

2. Purty, but clunky “camera” interface. No Undo/Redo for deleting pictures. Ouch! And who needs full-motion transitions just to look at a damn picture! Why do I have to move the mouse, with difficulty, in a circle to switch pictures? Forward and back arrows, hello?!? I love being able to take pictures, but the interface is horrible.

3. Degraded zip mode. Before, you could hover your arrow on a distant location, and if you could “zip” there, it became a lightning bolt. Now, instead, you have to pick a new location from a tiny tiny strip of limited, obscure location pictures. You have to memorize what miniscule image goes with what location, and click the tiny tiny scroll arrows if the list of such images is over 4 or so. In theory, this could be better than the lightning bolt, because it lets you go anywhere. In practice….

4. No automapping. Why doesn’t any game map for me as I go? I spend hours tracing everything out to make a coherent map, guessing whether a gentle turn means 90 degrees or maybe just 45 degrees, hoping the damn paths all link up in the right places when I’m done. I can’t use my own graphics program to help, because Myst takes up the whole damn screen! Is the exact layout of all the locations a state secret? No? Then why act like it! And annotate the map, too. I don’t want obscure florid icons where I have to make a second map just to describe what the in-game map really means.

Those rants may lead you to believe I hate Myst IV, but in fact I’m enjoying playing it. The continued greater and greater use of motion in each successive Myst is a lot of fun. Not particularly realistic, but fun. And the art and music are always great. The acting somehow never seems to improve, but it’s no worse than your average Sci Fi Channel show.

I’m not done, so no spoilers in the comments!

Beta-Testing

I recently downloaded the Half-Life 2 Gameplay Video via GameSpy.com. The extended combat sequences with guns and various vehicles, and the way both your friends and your enemies act in them, impressed the hell out of me; I felt like I was watching a movie. But the narrator for the video makes the point that this realism comes at a price: vastly complicated beta-testing.

This ties in with my own experience writing the FPS’s lowly, humble cousin, the text adventure a.k.a. “interactive fiction” game. Even in an IF game, where the player can’t shoot at whatever square meter he wants to, but instead is relegated to a relatively small selection of verbs and nouns, there are far too many possible combinations of actions to try them all yourself. Even for a small game, you need beta-testers – as many as you can find.

This need exists with any development, but for some projects, it can be ameliorated by Test-Driven Development practices. You think up the relatively small number of outcomes you want, and you make sure that you always get them.

With games, the challenge isn’t consistently trying out the small number of desired outcomes, but testing – and even thinking of – the vast number of cases that derive from those outcomes, and making sure they all work, too. And “work” is tricky, for IF games. You can’t just test for the right numerical output. You’re trying to make sure the text not only make sense, but is well-written, consistent, and is pitched just right for the times it’s going to appear.

This is why you need not one group of beta-testers, but two and even three groups. The first group tests out your initial game, the stuff you came up with with no outside help. Those really cool ideas that drove you to start writing it in the first place. These beta-testers will give you the first dose of sanity, and point you in fruitful new directions.

But at some point, these testers will have become too familiar with your ideas. They won’t be able to react like your real players will: confused at the confusing places, intrigued at the mysterious places, surprised at the surprising places. You need a second group to get fresh impressions of how well your ideas are working. You can’t mechanize that.

And ideally, once they’re done making sure your game is going well, you need one last group to judge the final result and catch any remaining erroneous details. Many games have that one last prominent bug because nobody saw the final changes with fresh eyes.

How about a fourth, a fifth, a sixth, a hundredth group? Nah. Beta-tester after beta-tester, your game will still have bugs. Beta-testing is the antidote to perfectionism.

A Colossal Tease

You’ve heard of text adventure games, also known as IF for “interactive fiction,” right? On my IF page, I mention the (award-winning, natch) games I’ve written, Small World and Rematch. I also mention Colossus, a larger game that was supposed to be the successor, though otherwise unrelated, to Small World.

Most game writers dream of the Big Game, their Magnum Opus: years to write, months to play, a work that advances the form in some significant fashion. An in-depth experience akin to reading a novel, full of fiendish puzzles, compelling character development, and satisfying plot twists. Colossus was going to be that game for me.

I had several ideas about it. It was going to be the IF equivalent of a sci fi blockbuster. I even wrote a “teaser” for it, a mini-game at the start of Dan Shiovitz’s (also sci fi-themed) Bad Machine, released (gulp) going on 6 years ago now. As MacTADS took longer and longer, I thought I would write it in MacTADS once it was finished, using the newer version 3 of the TADS language.

I’m no longer sure that Colossus is what I want to spend the next year or two of my free time on, but hey, who knows?

In the meantime, the teaser’s pretty fun. I may polish it a bit and release it as a tiny standalone game, but the joker is that I’d need to use my old, Classic-only, unfinished MacTADS tools to do it, since TADS Workbench for Macintosh only supports TADS 3 currently. Such is life!

And, please, don’t laugh at the “Fall 1999” release date, OK?