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.)
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 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’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:
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.
…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.)
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.
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:
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!
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.
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?