RSS

Tag Archives: tads

The Text Adventures of 1991

Coming exactly halfway between the shuttering of Infocom and the release of Graham Nelson’s landmark epic Curses, 1991 was the most exciting year of the little-remembered interstitial between interactive fiction’s commercial era and its supposed rebirth as an endeavor of dedicated hobbyists. The games of 1991 show what a misnomer the word “rebirth” really is in this case; the text adventure never actually went away at all. The tools available to amateur authors were certainly rougher than they would be in years to come, design standards as well less thought-through, but the fact remains that not a single year has gone by since Adventure first took the computing world by storm in 1977 when at least one or two worthy text adventures haven’t been written. In fact, hobbyists did considerably better than that in 1991. Amidst its blizzard of activity, that year yielded the four games I’ll be writing about today: two classics, one enjoyable journeyman, and one heart-breaker which came that close to being one of the finest text adventures ever written. Not bad for a dead form, eh?


Cosmoserve

It seemed like such a good idea at the time.

As a self-employed computer consultant, working at home was the logical decision: no more long commutes, no expensive office to lease, no boss. Unfortunately you also have no secretary, no janitor and no weekends. Your living room has become a glorified break room and your only human contact is by Electronic Mail.

Thank God for your computer.

It is 3:30pm on Friday the 7th of September, 2001. Everyone else in your time zone is finishing up work and looking forward to a relaxing evening. But you, R.J. Wright, overtired undernourished overeager programmer that you are, have promised to deliver a finished program to a client by 8:00 tomorrow morning.

Time to get to work....

I’ve always been entranced by the personal aspect of so many vintage text adventures of the amateur stripe. In this respect, they stand apart from almost all other games of their era, which preferred to emphasize the science-fictional, the fantastical, the epic. Even when those other games aren’t demanding that we leave the world we know for some strange new one, they almost always prefer the macro to the micro: wars and battles lost and won, the rise and fall of civilizations, the grand sweep of history. But text adventures, by contrast, can give us an intimate view of a single person’s life, whether said life be that of a PhD student at Harvard or a community-theater volunteer in a small California town. To state the case in literary terms, these are the quieter novels of ordinary people that, for some of us at least, become far more interesting than the latest swords-and-sorcery doorstops as we get older.

Cosmoserve, a game written in AGT by a Celtic harpist and sociologist-to-be named Judith Pintar, has the added advantage of providing a window into a world I’ve just spent the last two months on this blog doing my level best to capture: that of the commercial online services of the 1980s and early 1990s, which pioneered so much of what has since become daily life on the Internet. The game’s title is of course playing on that of CompuServe, the most popular of these services for well over a decade, and a service to which Pintar herself was an active subscriber for many years.

Cosmoserve is ostensibly set in 2001, but we can’t award Pintar too many points for her skill at prognostication. She manages to simultaneously underrate and overrate the pace of technological change to come. In her version of 2001, the wide-open World Wide Web never came along to bury the closed ghettos of the commercial online services, Windows never entirely replaced MS-DOS, and Intel never abandoned their old “x86” nomenclature for their microprocessors. And yet, at the same time that Pintar’s fictional universe was progressing more slowly than ours in all these respects, full-on online virtual realities — the sort of thing that’s just starting to become imaginable for us in 2017 — had already become a thing there by 2001.

But then, prognostication isn’t the point of Cosmoserve. Rather than an extrapolation about computing’s future, what you’re actually getting here is a gentle satire of the computing present which Pintar knew as she was writing the game. If you were already a computer freak in 1991, you’ll find yourself chuckling at things that are barely remembered today but were a major feature of the landscape of those times. For instance, do you remember the way that Intel, thanks no doubt to some marketing genius of an MBA inside the company, used to release crippled “SX” versions of their latest chips — versions that in some cases actually performed worse than the chips of the previous generation? I barely did myself, until Pintar reminded me:

This is the newly-released Orfland 786SX. Most of the advanced features of the revolutionary 786 chip were factory-disabled for the SX model: it hasn't got enough memory to run a graphical interface and it chugs along at about 12Mhz, but hey, its still a 786!

The plot of Cosmoserve is a classic shaggy-dog story in text-adventure form, the same approach that would be used to more famous effect by Curses two years later. Playing the role of a harried free-lance computer consultant, you need to get a patch for Turbo Pascal — another blast from computing’s past; the Borland product was by far the most popular development tool in the world in 1991 — in order to complete an assignment for an important client. You should be able to get the patch on Compu… err, Cosmoserve. It’s when you fire up your computer to go online and fetch it that the game, after having started out as a slice of life set in your own house, begins to show its real cards.

Most of Cosmoserve plays as a simulation of that whizz-bang Orfland 786SX computer of yours. First you’ll have to navigate the DOS prompt to get yourself online; in the some-things-never-change department, remembering your password will pose a particular problem on that front. Then, once you do manage to get online, the simulation extends yet one level deeper, allowing you to roam the Cosmoserve service, visiting forums, chat rooms, file libraries, email — all the things I’ve spent so many recent articles describing — along with a few futuristic touches, like the virtual-reality area, presented in recognition of the fact that we’re allegedly in 2001. It eventually emerges that getting the Turbo Pascal patch and finishing your assignment will first require you to stop a computer virus that threatens to take over the world. For those who aren’t aware: yes, viruses were already a problem in 1991. I really could go on forever about this game’s palimpsest of the familiar and the obscure, how it constantly signals all the ways things have changed in computing and all the way they’ve remained the same.

As a purely technical achievement, Cosmoserve is remarkable, especially considering that Pintar wasn’t an experienced programmer. AGT was by the standards of text-adventure authoring systems to come a very primitive tool indeed, riddled with assumptions about the sorts of games it would be used to create that can be almost impossible to completely override. And yet Cosmoserve manages to push AGT farther out of its comfort zone than any other game I’ve ever seen. If its simulations of DOS, of a terminal program, of CompuServe/Cosmoserve itself — even of a text adventure within this text adventure which you can play from the DOS prompt — aren’t always perfect, they’re far better than they have any right to be.

From the standpoint of the modern player especially, Cosmoserve does have some drawbacks. It’s never an unfair game according to its own old-school lights, but it is a demanding one. If you’ve never used MS-DOS, or have forgotten everything you once knew, you’ll likely have to consult a reference manual in order to get anywhere at all. And you’ll certainly have to pay careful attention and make some notes if you hope to solve this one.

More controversially, Cosmoserve plays on a clock. Timing is tight, you have a lot to do, events happen online at specific times… meaning, yes, this is one of those try-and-try-again games which require you to make a series of losing reconnaissance runs to get the lay of the land before you put everything together for your victory dash. This design approach is absolute anathema to some people; if you’re one of those people, nothing I can say will persuade you otherwise. The good news, though, is that in this case at least I don’t really have to.

Judith Pintar revisited Cosmoserve in 1997, adding some further polish to the experience and, most importantly, greatly easing the time pressure. Which version you choose to play must be a reflection of your own preferences as a player. Personally, having been raised on the Infocom mysteries, I don’t mind the try-and-try-again approach overmuch, if it’s done within reason and if I know what I’m getting into. I thus actually prefer the earlier Cosmoserve, which feels like a purer expression of its designer’s original intent to me. But of course those of you who aren’t as old-school — masochistic? — as me should feel free to go for the later version.

Either way, I think you’ll find the experience worthwhile. Whether considered as a pure gaming challenge or as a cultural artifact of its very specific time and (virtual) place, Cosmoserve has a lot to offer; taken on either terms or both, the wit, humor, and humanity of its author shine through. It was given co-winner status in the 1991 AGT Competition, alongside a more traditional text adventure called The Multi-Dimensional Thief. The latter game, a confusing  mashup of Guild of Thieves and The Wizard of Oz that delights in insulting its player when it isn’t dead-ending her, hasn’t aged very well. Cosmoserve, on the other hand, has only become more essential as the online life it chronicles has faded into oblivion and its time-capsule qualities have come to the fore.

Although either the original or the updated version of Cosmoserve can be played most easily on modern computers using the AGT interpreter AGiliTy, you’ll lose much of the atmosphere provided by occasional sound effects, not to mention MS-DOS’s familiar old green text on a black background. I therefore recommend playing it under the original AGT interpreter, in DOS, to get the full effect. To make that as easy as possible for you, I provide versions of Cosmoserve and Cosmoserve 97 — take your pick — ready to run in the DOSBox emulator. Whether you have a Windows, MacOS, or Linux machine, just install the version of DOSBox for your platform and follow the instructions included in the zip file to get the game going.


The Dungeon of Dunjin

You are in a dark, mysterious and confusing forest. Tall fir-trees form a dark wall around you. A cold wind is blowing from the mountains, and in the far distance you can hear wolves howling. Faint trails lead east and south. To the north the forest seems to continue forever, and to the west the vegetation is so dense that it would be impossible to go in that direction.

If you’re anything like me, you may prefer the idea to the reality of the sprawling text adventures that ran on the big institutional computers of the 1970s. Still some of the largest works ever created in the medium of text and parser, games such as the original Zork and Acheton offer immense worlds of hundreds of locations and almost as many puzzles — worlds to get lost inside for weeks or months. They seem absolutely amazing at first. When you start to play them a little more, though, you come to realize that you just can’t trust these games. Standards of good and bad design simply didn’t exist at the time they were being made, meaning that they tend to be riddled with as many terrible puzzles as brilliant ones.

The Dungeon of Dunjin, written by a Swede named Magnus Olsson over the course of about five years, answers the question of what Zork might have been like if it hadn’t, as Robb Sherwin once so memorably put it, hated its player. The setup is as old-school as it gets: you, the nameless faceless adventurer, have arrived near the entrance to the titular dungeon with treasure on your mind. As you play, another plot line does begin to emerge, but it never feels all that compelling. At bottom, The Dungeon of Dunjin is best accepted as a game about looting a landscape and dropping your spoils in a repository for points — a concept that was beginning to feel a little retro already by the time Infocom left Zork behind in 1983. Olsson’s 1991 backward glance comes complete with a sprawling geography of some 180 rooms, filled with locations that in typically old-school fashion often fail to connect with one another in the expected ways; going south and then going north, in other words, isn’t guaranteed to return you to your starting position. (In light of this, you’ll wind up happy that the game engine doesn’t recognize secondary compass directions like northeast.) Needless to say, light sources, trolls, and dragons figure prominently in the puzzles and plot.

But the thing that separates The Dungeon of Dunjin from its legendary forebears is that all the really annoying old-school nonsense is blessedly missing. Olsson has clearly made a conscious, thoroughgoing effort to design a game that the motivated player can actually win, and without being bored to death by petty logistical problems in the process.

The game engine is home-grown, written in Turbo Pascal. (I did tell you it was everywhere in the early 1990s…) It’s nowhere close to the level of even the PDP-10 Zork, possessing only an extremely basic world model and a parser that’s for the most part limited to two-word verb-noun constructions. Many a designer forced to work with such an engine has wound up stretching it past the breaking point, stumbling into the territory of guess-the-verb puzzles and sheer logical incoherence in an attempt to make a more difficult game than the engine can really support. (I would argue that the entire Scott Adams catalog after the fifth or sixth game can be seen as extended proof of this thesis.) But Olsson is too smart to be caught in that trap: he knows how to work within his tools, avoiding puzzles — like those involving intricate mechanical manipulations — which his game engine just can’t handle. There’s enough that it can do, he realizes, to make a perfectly satisfying old-school adventure game.

The most unfortunate aspect of the writing actually comes right up front, in the horrid title. The Dungeon of Dunjin is no literary masterpiece — that’s hardly the point of a game like this one, is it? — but the writing acquits it surprisingly well for that of a non-native English speaker. (Olsson does poke a little fun at the thing many people still think of first when they think of Sweden by making one puzzle revolve around an Abba record.) Like Adventure and Zork before it, the game never takes itself too seriously, freely mixing contemporary culture with high fantasy, placing computer labs practically next door to slavering dragons. Sometimes a sly Zorkian wit peeks through, as when you find a human skull in the dungeon that’s made of plastic and has “Made in Taiwan” printed on the side. The dungeon itself, meanwhile, proves in the end to be a closed-down tourist attraction; shades of the bizarre postmodern endgame of Adventure.

Filled with little homages to its predecessors like these, but perfectly playable if you don’t know a rusty rod with a star on the end from a lonely white house, The Dungeon of Dunjin is one of the better old-school puzzlefests I’ve played in my time, consistently surprising and amusing, consistently challenging — not least as a result of the combinatorial explosion that stems from its considerable size — and yet never insurmountable and only very rarely actively annoying. I enjoyed playing it immensely, and fancy that any of you who are up for a big adventure that will absorb quite some hours of your time and who don’t mind making a map and checking it twice — thankfully, we have Trizbort these days! — may just do so as well. Being a native citizen of MS-DOS, it can only be played through an emulator on modern computers. I’ve therefore prepared a version for you that will make that as easy as possible. Just add DOSBox.


Save Princeton

According to the brochure that the admissions department gave you, Princeton University is one of the last bastions of intellectual pursuit, where students can engage in the quest for learning unencumbered by worldly cares. As far as you can tell, though, the place looks like any one of a thousand clones of Cambridge University that clutter the American academic landscape. Still, you figure there must be something at least vaguely interesting about it, considering the reputation that the place has managed to accumulate over the past 250 or so years.

You decide, therefore, to take an Orange Key Tour. Minutes into it, though, you realize that you have no interest in being shown buildings with cannonball scars from the Revolutionary War. So, as the guide leads you through yet another archway, you break off from the group and wander through a nearby door. You find yourself in an entryway, standing in front of a door labeled with the number 21. When you turn the handle, the door swings open, and you enter, hoping no one will catch you being a voyeur.

As you poke around, the sound of gunfire coming from outside in the courtyard startles you. You dive for cover beneath a desk and remain there, shaking, until the tumult dies down. When you come out, you can sense a tension in the atmosphere. Clearly, something strange has happened.

Written by a Princeton University student named Jacob Weinstein with some assistance from his fellow student Karine Schaefer — “she just helped plot it, and left the geeky stuff to Jacob” — Save Princeton is another entry in a weirdly overstuffed sub-genre of interactive fiction: the collegiate text adventure, a category that includes such earlier classics as The Lurking Horror and A Dudley Dilemma. This game isn’t on the same level as either of those, but it has its charms.

As soon as you start Save Princeton, you’re smacked in the face with how much some things have changed since 1991; a plot involving terrorists taking over a major university would never be treated so flippantly in these times of ours. Here, though, it’s just a mechanism for pushing you to explore the campus and lap up — or, more likely, scratch your head at — the endless in-jokes. While nothing really stands out about the game’s puzzles or construction, there’s nothing notably objectionable either; this is all pretty standard fare, albeit delivered in a pretty user-friendly way, without the inscrutable puzzles, mazes — well, there is a fake maze — or parsing issues that were still typical of most amateur text adventures of this era. Doubtless helping the game’s cause is the fact that it’s written in TADS, a much more powerful and polished system for programming text adventures than AGT, if also a much less popular one in 1991. The writing is actually more ramshackle than the technology or the puzzle design, with the tossed-off feel that was also so typical of early amateur text adventures.

But it isn’t Save Princeton‘s merits as a piece of timeless game design, much less as a piece of writing, that makes me want to cautiously recommend it. It rather comes down once again to that personal quality of so much amateur interactive fiction.

Weinstein fills his slice of life not just with the architecture of Princeton, nor just with the pop-culture detritus of 1991 — “there are posters of such charming items as Laura Palmer’s corpse” — but with himself, along with the friends he has at university. Go to the “Girls’ Common Room” and there’s Lisa, “working on the New York Times crossword puzzle”; there’s Melisande, “buried in an Orson Scott Card novel.” Go to the boys’ room and there’s Eric, “humming the violin part of The Rite of Spring“; there’s Otis, the “fairly accomplished computer programmer” who “won the Mr. Princeton bodybuilding contest his freshman year.” Eventually you’ll also meet Karine — yes, Weinstein’s alleged coauthor — sitting in the romantic glow of a lava lamp, dreaming of Anthony Hopkins of all potential heartthrobs, “making an acidic comment regarding the cultural inferiority of every city in the world except for New York.” Somehow I suspect that Jacob was crushing hard on Karine, to the point of giving her a dubious authoring credit on his game, only to be stuck permanently in the Friend Zone.

Of course, I don’t really know what was going on with any of these young people. Nor have I ever even been on the Princeton campus, meaning that every in-joke is utterly lost on me. And yet — and you can chalk this up to my going all American Graffiti in my middle age if you like — there’s something about this unassuming little game that I find almost unbearably poignant. It so happens that I’m almost the exact same age as the kids we meet in it, and I can’t help but feel a connection with all these entitled little dreamers, so full of grand plans for the future, so convinced that the meaning of life can be revealed to them by the right song, book, or film. Where have their lives taken them? If they were given this game to play today, would they be surprised to meet the people they used to be?

Call me a sentimental fool, but Save Princeton, patently envisioned by its author as just a light-hearted adventure game, kind of puts a lump in my throat. Your own mileage may of course vary, but it’s certainly not a bad little game even if it doesn’t prompt in you the same ruminations about the cycle of life. You can download it from the IF Archive and play it using any of the many freely available TADs interpreters.


T-Zero

You awake from uneasy dreams. Since you're no longer on easy street, maybe that's the way your dreams are going to be from now on. Exactly where you are becomes clear as you sort out the sounds of the river to the east, the rustlings of birds to the north and west, and the sweet scent of sleep-inducing poppies wafting down from the northwest. Apparently, after a day of determined walking about, you burrowed down next to the river and let consciousness drift.

What exactly induced this bout of walking? Well, two nights ago, Count Zero handed you your walking papers and extracted your latchkey to the museum in exchange (little does he know that you keep a spare hidden in the topiary). It's just as well that you were dismissed from the museum--your duties as combination custodian and librarian involved either re-shelving books and dusting off clocks or rewinding timepieces and dusting off books. However, you were onto something. Exactly what is unclear since the pieces of the puzzle seem to disconnect with sleep. You resolve not to sleep until you've recollected and reconnected their jagged edges. You can be just as calculating as the Count. You can even reach beyond the Zero . . .

I had one of the most magical gaming experiences of my life with T-Zero.

About fifteen years ago, I was working the graveyard shift at a computer-services firm in Dallas. From 7 PM to 7 AM, three or four nights per week, I’d sit in a nearly deserted data center babysitting the servers and mainframes, just in case anything should happen. Most of the time, it didn’t, meaning I had a lot of free time on my hands. Boredom was a big problem. There were enough curious eyes wandering about the place doing their system modifications and whatnot that playing anything that looked like a game would have been a really bad idea. Text adventures, however, were a different story. I could sit typing away into a window filled with text, looking for all the world like I was hard at work on something vital. Thus I played a lot of text adventures during this period, delving back into a lot of forgotten games — often justifiably forgotten! — from the early issues of SPAG magazine. One of the games I played was T-Zero.

I was playing it one night when a message popped up out of nowhere, apropos of nothing I was actually doing in the game at the time. “It’s a full moon tonight,” it read. “Go outside and take a look.” So, curious whether this already very old game knew what it was talking about, I did.

Well, the game did know what it was talking about. Outside a huge harvest moon hovered low over the warm night. I’d always loved the silence of the predawn hours, when the only sounds you could hear were the omnipresent Texas crickets. Now the peaceful scene, blanketed in the moon’s silvery sheen, seemed to fuse with the peculiar beauty of the game I’d just been playing. I stood there in front of my employer’s antiseptic corporate building for quite some minutes, marveling at the beauty that can visit us at the most banal times. As I turned to go back inside, I knew that I’d never forget this night. And, as this little reminiscence demonstrates, I was right.

T-Zero truly is a magical game in some ways; at its best, it almost attains the same heights as Trinity, my all-time favorite work of interactive fiction. Indeed, comparisons between the two works strike me as unavoidable. T-Zero at the time of its release had the most subtly textured writing that had been seen in a text adventure since Trinity. More than that, though, it resembles and even pays homage to Infocom’s finest hour in many respects: a sundial and a gnomon, to name an obvious if superficial example, figure prominently in T-Zero as well as in Trinity. Less superficially, both games share an abiding obsession with the mystery of time, and both have a smile-through-tears quality, a gentle whimsy laced with melancholia.

T-Zero was written by one Dennis Cunningham, a person about whom I know nothing beyond his description of himself as “a programmer with literary leanings.” He is or was obviously very talented in both fields. For someone like me who loves words, T-Zero is a source of constant delight. As an example of its love of clever wordplay, consider that you begin it by waking up in the location known as “River Bed” — or consider the “buxom bell” you’ll soon be ringing. Unlike so many self-consciously “literary” interactive works, which tend to get buried under the weight of their own aspirations, T-Zero‘s writing dazzles without ever seeming to try to do so; Cunningham’s writerly touch is light where the others are heavy. I can perhaps best convey his game’s atmosphere by borrowing a line from one of his room descriptions: “Either your vision is becoming near-sighted or this scene has all the pointillist charm of a Monet painting.” Like an Impressionist painter, Cunningham is more interested in the interplay of light and shadow than he is with concrete forms. Maybe that explains why the moonlight affected me so on that one magical night.

I hesitate to trample over the delicate poetry of T-Zero too much more with my leaden reviewer’s prose, but will note that it takes place in the slightly surreal landscape which surrounds a strange museum where you until recently worked as a low-grade custodian and librarian. You will eventually learn that the time is out of joint, and you will have to learn to travel through time to visit the same locations in other millennia, learning of the other inhabitants who dwelt and will dwell here. These inhabitants are not human; nor is it ever entirely clear whether you yourself are. Again, T-Zero isn’t concerned with the concrete. It’s a dream and a meditation, and it’s all the better for it.

T-Zero has a spirit of unabashed intellectualism to it — a complete disinterest in talking down to its player — which looks forward to Graham Nelson’s Curses. Cunningham peppers his game with allusions: to Miguel de Cervantes and his deluded knight, to Edgar Allan Poe and his bells ringing in the night, to Douglas Hofstadter and his Eternal Golden Braid, to the Beatles and their Walrus. This sort of thing can veer into rank pretension in a hurry. But, again like Nelson, Cunningham’s erudition reads as intriguing rather than off-putting, sending you scurrying off to Wikipedia to learn more about the references you don’t entirely get.

With so much going on at the literary level, it may seem almost belittling to focus on the technology that underpins the game, but I’d actually be doing its author a disservice not to mention it. Like Magnus Olsson, Dennis Cunningham chose to write his game from scratch rather than use a text-adventure authoring system like AGT or TADS. And here I have to break out the superlatives yet again: the engine he created is quite simply the best bespoke text-adventure engine I’ve seen. Ever.

Cunningham doesn’t just meet the Infocom standard that was still the aspirational ideal among amateur text-adventure makers in 1991, he actually exceeds it in a number of respects. The parser handles even the most complicated constructions with aplomb, and the game is rife with little conveniences seldom seen during its era: things like undo, like a generous command-history buffer, like a menu-based restore command that doesn’t expect you to remember the name of every save file you create. The world model is complex and coherent, and the addition of carefully chosen shades of color, rather than just looking gaudy as color so often tends to do in an all-text game, adds to the rich atmosphere.

Just look at this! T-Zero offers a menu for disambiguation as one of the conveniences it’s absolutely rife with.

But now, having praised T-Zero to the skies, I have to tell you about its one tremendous flaw: this game is just way, way too hard. A goodly chunk of the puzzles involve wordplay of the Nord and Bert variety, the sort of thing that delights some players and drives others — especially players who don’t have English as a first language — absolutely crazy. This in itself may thus be enough reason for some of you to reject a game, but we’re just getting started with the litany of barriers to solving it. T-Zero muddies the waters further than Nord and Bert did in that it doesn’t have discrete sections devoted to discrete kinds of wordplay; you never know, in other words, whether it’s looking for an idiom or an anagram or an allusion. Or, for that matter, whether it’s looking for something else entirely: there are also plenty of traditional puzzles here, grounded in real-world — or at least text-adventure — physics. And then we have to throw onto the pile the fact that this is a big game with a lot of locations to explore, and over several time periods at that. Because the descriptions of these intricate landscapes are drawn in such loving detail, it’s really, really hard to know for sure which locations contain puzzles waiting to be solved and which just exist for you to drink in on their own terms.

Not helping the situation is a tendency for the parser, so flexible in most ordinary tasks, to suddenly become needlessly persnickety in some specific situations, with failure messages that can be not just unhelpful but actively misleading. For instance, at one point you need to tear the flyleaf out of a book. You need to type it exactly like that: “tear flyleaf out of book.” If you try to “pull flyleaf out of book,” you’re told that “your pull is next to nothing when it comes to the flyleaf.” Far worse, if you just type, “tear flyleaf,” you’re told that there’s “no reason to play the vandal”; if you’re foolish enough to take the game at its word here, you’ll never solve it. There aren’t heaps of situations like this one, but there are more than enough to ruin an otherwise brilliant game for its player even absent the other questionable design choices.

That said, it must also be admitted that there is a partial solution to all these problems built right into the game. Among its other technical wonders, T-Zero includes a full-fledged adaptive hint system that keeps track of your progress and doles out context-specific hints for each location — the first such system I’m aware of in the history of interactive fiction. It breaks my heart, but I have to recommend to any of you who choose to play this game that you use it liberally, typing “hint” as a matter of course in each location you visit. Sometimes doing so gives away the full answer to the puzzle; sometimes it at least leaves a little for you to work out on your own. The former in particular is far from ideal, but what else can you do if you’d prefer not to beat your head for hours and hours against this brick wall of a game? The shame, of course, is that there are some very good puzzles here which you won’t be able to enjoy thanks to the bad ones. Ah, well… at least T-Zero‘s wonderful version of the maze-that-isn’t-really-a-standard-maze, almost as venerable a text-adventure tradition by this point as mazes of the old drop-and-plot variety, isn’t entirely spoiled by the hint system.

Having to recommend that you play T-Zero in this way really does pain me, not least in that it destroys all the critical goodwill I have toward every other aspect of the game. As you regular readers know, I’m deeply skeptical of the idea of the “great, as long as you have a walkthrough” species of adventure game. Adventure games are interactive works, and when their interactivity fails them it’s hard for me to see why one should bother with them. As I once put it, “an adventure game that cannot be solved unaided, or for that matter that can be solved only through sheer doggedness and refusal to give in to tedium, is a bad game.”

But I will say now that this particular bad game comes closer than any other to making me recommend that you go ahead and play it anyway using the hints, just to experience the prose and the beautiful environment it evokes. In the end, you’ll have to decide for yourself whether this failure that by all rights should have been numbered among the all-time greats is worth your time. Once again, you can download an almost-ready-to-play version from this site. The only other thing you need is DOSBox.

 
18 Comments

Posted by on December 29, 2017 in Digital Antiquaria, Interactive Fiction

 

Tags: , , , , , , , ,

TADS

For text-adventure fans confronting the emerging reality of a post-Infocom world, AGT was a godsend, allowing amateurs for the first time to create games that at a quick glance might appear to match those of Infocom. Still, AGT was far from the answer to every prayer, for the fact remained that it would have to be a very quick glance indeed. David Malmberg, the developer of AGT, was ingenious and motivated, but he was also a self-taught programmer with little background in the complexities of programming languages and compiler design. He had built AGT by adding to Mark Welch’s profoundly limited GAGS system for creating generic database-driven text adventures a scripting language that ignored pretty much all of the precepts of good language design. What he had ended up with was almost a sort of technological folk art, clever and creative and practical in its way, but rather horrifying to anyone with a deeper grounding in computing theory. The best argument in favor of AGT was that it worked — basically. While the system was undoubtedly more capable than anything that had been available to hobbyists before, it still didn’t take much poking at an AGT game before the rickety edifice’s seams began to show.  A number of authors would push the system to unforeseen heights, in the process creating a number of classic games, but it was obvious that AGT could never work quite well enough to create games as polished as those of Infocom. To do that, a language would be needed that was truly designed rather than improvised. Enter Michael J. Roberts with his Text Adventure Development System, or TADS.

Roberts had first started programming on his school’s DEC PDP-11 system in the 1970s at the age of 12, and thereafter had ridden the first wave of the PC revolution. In those early days, text adventures were among the most popular games there were. Like so many of his peers, Roberts studied the BASIC listings published in books and magazines carefully, and soon started trying to write adventures of his own. And like so many of those among his peers who became really serious about the business, he soon realized that each game he wrote was similar enough to each other game that it made little sense to continually reinvent the wheel by writing every one from scratch. Roberts:

It occurred to me that lots of the code could be generalized to any adventure game. So, I tried to write a little library of common functions — the functions operated on a set of data files that specified the vocabulary words, room descriptions, and so on.

This was a nice approach in some ways; the idea was that the game would be described entirely with these data files. The problem that I kept running into was that I’d have to write special-purpose functions for certain rooms, or certain commands — you couldn’t write an entire game with just the data files, because you always had to customize the library functions for each game. What I really wanted was a way to put programming commands into the data files themselves, so I didn’t have to modify the library routines.

Once you start putting procedural code into data files, you essentially have a programming language. At first, I tried to avoid the work of writing a real language interpreter by making the language very limited and easy to parse. That was better than just the data files, but it was tedious to write programs in a limited language. I eventually saw that you really needed a good language that was easy to use to be able to write decent games.

Roberts, in other words, was discovering for himself the limitations and inelegancies that were inherent to a system like AGT — the limitations and inelegancies of grafting a scripting language onto a generic database engine.

But it wasn’t until he went off to the California Institute of Technology that his experiments progressed further. Despite his official status as a physics major, CalTech offered plenty of opportunity for a motivated young hacker like him to immerse himself in the latest thinking about programming languages and compiler design. In the air all around him was computer science’s hot new buzzword of “object-oriented” design. By allowing the programmer to gather together data and the code that manipulates that data into semi-autonomous “objects,” an object-oriented programming language was an ideal fit for the problems of constructing a text adventure. (Indeed, it was such an ideal fit that Infocom had developed a heavily object-oriented language of their own in the form of their in-house adventure-programming language ZIL years before the buzzword came to prominence.) Following yet another trend, Roberts based his new adventure language’s syntax largely on that of C, the language that was quickly become the lingua franca of the world of computer programming in general.

On the theory that a worked example is worth a thousand abstractions, and following the precedent I set with my article on AGT, I’d like to show you a little bit of TADS code taken from a real game. You may want to refer back to my AGT article to contemplate the comparisons I’m about to make between the two languages. Taken together, the two articles will hopefully lead to a fuller understanding of just how TADS evolved the text-adventure-programming state of the art over AGT.

The game we’ll be looking at this time is Ditch Day Drifter, a perfectly playable standalone adventure that was also used by Mike Roberts as his example game for TADS learners. Once again following my AGT precedent, I’ll focus on that most essential piece of equipment for any old-school adventurer: a light source. Here we see Ditch Day Drifter‘s flashlight.

flashlight: container, lightsource
    sdesc = "flashlight"
    noun = 'flashlight' 'light'
    adjective = 'flash'
    location = security
    ioPutIn( actor, dobj ) =
    {
        if ( dobj <> battery )
        {
            "You can't put "; dobj.thedesc; " into the flashlight. ";
        }
        else pass ioPutIn;
    }
    Grab( obj ) =
    {
        /*
         *   Grab( obj ) is invoked whenever an object 'obj' that was
         *   previously located within me is removed.  If the battery is
         *   removed, the flashlight turns off.
         */
        if ( obj = battery ) self.islit := nil;
    }
    ldesc =
    {
        if ( battery.location = self )
        {
            if ( self.islit )
                "The flashlight (which contains a battery) is turned on
                and is providing a warm, reassuring beam of light. ";
            else
                "The flashlight (which contains a battery) is currently off. ";
        }
        else
        {
            "The flashlight is off. It seems to be missing a battery. ";
        }
    }
    verDoTurnon( actor ) =
    {
        if ( self.islit ) "It's already on! ";
    }
    doTurnon( actor ) =
    {
        if ( battery.location = self )
        {
            "The flashlight is now on. ";
            self.islit := true;
        }
        else "The flashlight won't turn on without a battery. ";
    }
    verDoTurnoff( actor ) =
    {
        if ( not self.islit ) "It's not on. ";
    }
    doTurnoff( actor ) =
    {
        "Okay, the flashlight is now turned off. ";
        self.islit := nil;
    }
; 
 

Unlike the case of our AGT example, for which we had to pull together several snippets taken from entirely separate files, we have here everything the game needs to know about the flashlight, all in one place thanks to TADS’s object-oriented design. Let’s step through it bit by bit.

The first line tells us that the flashlight is an object which inherits many details from two generic classes of objects included in the standard TADS library: it’s both a container, meaning we can put things in it and remove them, and a light source. The rest of the new object’s definition fleshes out and sometimes overrides the very basic implementations of these two things provided by the TADS library. The few lines after the first will look very familiar to veterans of my AGT article. So, the flashlight has a short description, to be used in inventory listings and so forth, of simply “flashlight.” The parser recognizes it as “flashlight” or “light” or “flash light,” and at the beginning of the game it’s in the room called “security.”

After this point, though, we begin to see the differences between TADS’s object-oriented approach and that of AGT. Remember that adding customized behaviors to AGT’s objects could be accomplished only by checking the player’s typed commands one by one against a long series of conditions. The scripts to do so were entirely divorced from the objects they manipulated, a state of affairs which could only become more and more confusing for the author as a game grew. Like those created using many other self-consciously beginner-friendly programming languages, AGT programs become more and more of a tangle as their authors’ ambitions grow, until one reaches a point where working with the allegedly easy language becomes far more difficult than working with the allegedly difficult one. Contrast this with TADS’s cleaner approach, which, like Infocom’s ZIL, places all the code and data pertaining to the flashlight together in one tidy package.

Continuing to read through the TADS snippet above, we override the generic container’s handling of the player attempting to put something into it, specifying that this particular container can only contain one particular object: the battery. Then we specify that if the player removes the battery from the flashlight when the flashlight is turned on, its status changes to not lit — i.e., it goes out.

Next we have the flashlight’s “long description,” meaning what will happen in response to the player attempting to “examine” it. TADS allows us to insert code here to describe the flashlight differently depending on whether it’s on or off, and, if it’s in the latter state, depending on whether it contains the battery.

Finally, we override the generic light source’s handling of the player turning it on or off, to tie the written description of these actions to the specific case of a flashlight and to reckon with the presence or absence of the battery. Again, note how much cleaner this is than the AGT implementation of the same concepts. In AGT, we were forced to rely on several different versions of the flashlight object, which we swapped in and out of play in response to changes in the conceptual flashlight. In TADS, concept and code can remain one, and the steps necessary to implement even a huge adventure game can continue to be tackled in relative isolation from one another.

Instructive though it is to compare the divergent approaches of the two systems, it is important to state that TADS wasn’t created in reaction to AGT. Computing communities were much more segregated in those days than they are today, and thus Roberts wasn’t even aware of AGT’s existence when he began developing TADS. Beginning as a language tailored strictly to his own needs as a would-be text-adventure author, it only gradually over the course of the latter 1980s morphed in his mind into something that might be suitable for public consumption. What it morphed into was, nevertheless, something truly remarkable: the first publicly available system that in the hands of a sufficiently motivated author really could create text adventures as sophisticated as those of Infocom. If anything, TADS had the edge on ZIL: its syntax was cleaner, its world model more thorough and consistent, and it ran in a virtual machine of its own that would prove as portable as the Z-Machine but was free of the latter’s brutal size constraints.

As TADS was rounding into this very impressive state, Roberts set up a company with a friend of his named Steve McAdams. In tribute to Roberts’s degree in physics, they called it High Energy Software, and, following in the footsteps of David Malmberg’s little AGT enterprise, planned to sell TADS as shareware through it. Version 1.0 of TADS was released in September of 1990, alongside two games to show it off. One was the afore-referenced freebie example game Ditch Day Drifter, while the other was Deep Space Drifter, a bigger game released as a shareware product in its own right. Both games tread well-worn pathways in terms of subject matter, the former being yet another “life at my university” scenario, the latter a science-fiction scenario with some of the feel of Infocom’s Starcross. Both games are a little sparse and workmanlike in their writing and construction, and some elements of them, like the 160-room maze in Deep Space Drifter, are hopelessly old school. (It’s not a maze in the conventional drop-and-map sense, and the puzzle behind it is actually very clever, but still… 160 rooms, Mike? Was that really necessary?) On the positive side, however, both games are quite unusual for their era in being scrupulously fair — as long, that is, as you don’t consider the very idea of a huge maze you have to map out for yourself to be a crime against humanity.

But undoubtedly the most ambitious and, in their way, the most impressive of the early TADS games came not from High Energy Software but rather from a pair of University of Maryland students named David Leary and David Baggett, who started a company they called Adventions to sell TADS text adventures via the shareware model. Of all the folks dabbling in shareware text adventures during the early 1990s, it was Adventions who made the most concerted and sustained effort at building a real business out of it. Their flagship series came to encompass three big unabashed Zork homages — Unnkulian Underworld: The Unknown Unventure, Unnkulian Unventure II: The Secret of Acme, and Unnkulia Zero: The Search for Amanda — alongside Unnkulia One-Half: The Salesman Triumphant, a free snack-sized sampler game.

When the first Unnkulia game was released remarkably quickly on the heels of TADS itself — Mike Roberts can’t recall for sure, but believes Leary and Baggett likely developed it with an early beta copy of the system — it stood as easily the most immediately impressive amateur text adventure ever. The text was polished in a way that few text-adventure developers outside of Infocom, whether amateur or professional, had ever bothered to do, being free of the self-conscious meta-textual asides and atrocious grammar that had always marked the genre. Adventions’s text, by contrast, looked like it had actually been proof-read, and possibly several times at that. Likewise, the game took full advantage of the sophisticated TADS world model to offer puzzles of an intricacy that just wasn’t possible with a tool like AGT. The first Unnkulia game and those which followed were almost in a league of their own for some time in all these respects.

On the other hand, though, the Unnkulia games strike me as curiously unlikable. You can get a good idea of their personality just by looking at their names. If the name Unnkulia — be sure to say it out loud — strikes you as hilarious, congratulations, you may have found your new favorite series. If it instead just strikes you as stupid, as it does me, perhaps not so much. (I admit that my attitude may be affected by having to type the damn thing over and over again; no matter how hard I try, I just can’t seem to remember how to spell it.) Much of the humor inside the games for some reason involves “cheez” — and yes, it’s spelled just like that. The humor has always been, at best, polarizing, and I have no doubt on which side I stand. In addition to just not being all that funny, there’s a certain self-satisfied smugness about the whole enterprise that rubs me the wrong way. At the risk of over-personalizing my reaction to it, I’ll say that it feels like the work of two young men who are nowhere near as witty as they think they are. In short, there’s something about these games that I find insufferable.

In terms of design, the Unnkulia games are an equally odd brew. It’s clear that they’ve been quite rigorously tested — another thing that sets them apart from most text adventures of their era — and they’re free of mazes, guess-the-verb puzzles, and the other most-loathed aspects of their genre. Yet the puzzle design still isn’t all that satisfying. There’s an obsession with hiding objects behind, under, and inside unlikely things — an obsession which is ironically enabled by the TADS world model, which was the first to really allow this sort of thing. Sometimes, including in the very first room of the very first game, you even have to look twice to find everything. Hiding surprises in plain view is okay once or twice, but Baggett and Leary lean on it so hard that it quickly starts to feel lazy. When they do get more ambitious with their puzzles, however, they have a tendency to get too ambitious, losing sight in that peculiar way so many text-adventure authors have of how things actually work in a real physical environment. Let me offer a quick example.

So, let’s set up the situation (spoilers ahoy!). You have a bronze plate, but you need a bronze coin to feed to a vending machine. During your wanderings in search of that among other things, you come upon the room below. (These passages should also convey some more of the, shall we say, unique flavor of the writing and humor.)

Inner Temple of Duhdism

This chamber is the temple of Duhdism, the religion of the ancients. It's rather a letdown, after all Kuulest told you about it. A small altar with a round hole in the center is in the center of the chamber. Carved in stone on the far wall is some writing, the legend of Duhdism. The only exit from this chamber is back to the east. You feel at peace in this room, as if you could sleep here - or maybe you're just kind of bored.

>read writing
"The Legend of Duhdha and the Shot to Heaven:

One fine summer day, Duhdha was loading a catapult with rocks. When his students asked what he was doing, the great Duhdha just smiled and said, "Something real neat." Soon, the catapult was full, and Duhdha pulled the lever as his students looked on. The stones crushed the annoying students, leaving the great man to ponder the nature of mankind. Not only did the rocks eliminate distraction from Duhdha's life, but they fell to the ground in a pattern which has since become a standard opening for the intellectual game of "Went." Since then, the altar at the Temple of Duhdha fires a small stone into the air soon after a worshipper enters, to honor Duhdha - who taught his students not to ask stupid questions and to pretty much just leave him alone."

>x altar
The altar is about two feet by one foot, and about three feet tall. There's a small round hole in the exact center of the top surface. The altar is covered with rock dust. There's nothing else on the Duhdist altar.

>z
Time passes...
A rock shoots into the air from the hole in the altar, shattering on the ceiling and spreading rock dust on the altar.  From the outer chamber, you hear the old monk cry "Praise Duhdha!."

We obviously need to do something with this rock-spewing altar, but it’s far from clear what that might be, and fiddling with it in various ways offers no other clues. Putting things on it has no effect on either the thing that’s just been put there or the rocks that keep flying out — except in the case of one thing: the bronze plate we’re carrying around with us.

>put plate on altar
Done.

>z
Time passes...
A rock shoots from the altar at high velocities, puncturing the plate in the center. The rock shatters on the ceiling, spraying rock dust. You hear a tinkling sound as a tiny bronze disc falls on the floor. From the outer chamber, you hear the monk shout "Praise Duhdha!"


*** Your score has just changed. ***

When you reach this solution either by turning to the walkthrough or through sheer dogged persistence — I maintain that no one would ever anticipate this result — you might then begin to wonder what physical laws govern the world of Unnkulia. In the world we live in, there’s no way that the flying rock would punch a perfect hole neatly through the middle of a bronze plate that happened to just be lying on the altar. Without something to hold it in place, the plate would, of course, simply be thrown into the air to come down elsewhere, still intact. The ironic thing is that this puzzle could so easily have been fixed, could have even become a pretty good one, with the addition of a set of grooves or notches of some sort on the altar to hold the plate in place. Somehow this seems emblematic of the Unnkulia series as a whole.

Like everyone else who dreamed of making a living from shareware text adventures, Leary and Baggett found it to be a dispiriting exercise, although one certainly can’t fault them for a lack of persistence. With some bitterness — “It’s disappointing that although there are so many IF enthusiasts out there, so few are willing to pay a fair price for such strong work,” said Baggett — they finally gave up in time to release their final game, 1994’s very interesting The Legend Lives! — more on that in a future article —  for free before exiting from the text-adventure scene entirely.

The same dispiriting lack of paying customers largely applied to makers of text-adventure languages as well. Mike Roberts estimates that his rate of TADS registrations peaked “on that same order” as David Malmberg’s pace of 100 AGT registrations per year, or “maybe a little lower. I’d remember if it had been much higher because I’d have been spending all day stuffing envelopes.” Whatever their respective rates of registration, far more AGT than TADS games continued to be released in the early 1990s. While that may have struck some — not least among them Mike Roberts — as disappointing, the reasons behind it aren’t hard to divine. AGT had a head start of several years, it had an annual competition to serve as an incentive for people to finish their games, and, perhaps most of all, it presented a much less daunting prospect for the non-programming beginner. Its kind and gentle manual was superb, and it was possible to get started making simple games using it without doing any programming at all, just by filling in fields representing rooms and objects. TADS, by contrast, offered a manual that was complete but much drier, and was on the whole a much more programmer-oriented experience. The initial learning curve undoubtedly put many people off who, had they persisted, would have found TADS a much better tool for realizing their dreams of adventures in text than AGT.

Some time after the Adventions guys and David Malmberg gave up on their respective shareware products, Roberts and his partner Steve McAdams also decided that they just weren’t making enough money from TADS to bother continuing to sell it. And so they made TADS as well free. And with those decisions, the brief-lived era of shareware interactive fiction passed into history.

But, despite the disappointments, Mike Roberts and TADS weren’t going anywhere. Unlike Leary, Baggett, and Malmberg, he stayed on the scene after giving up on the shareware thing, continuing to support TADS as open-source software. It took its place alongside a newer — and also free — language called Inform as one of the two great technical catalyzers of what some came to call, perhaps a little preciously, the Interactive Fiction Renaissance of the mid- to late-1990s. So, I’ll have much, much more to write about TADS and the games made using it in years to come. One might even say that the system wouldn’t really come into its own as a creative force until Roberts made that important decision to make it free.

Still, the importance of TADS’s arrival in September of 1990 shouldn’t be neglected. Somewhat underutilized though it may initially have been, it nevertheless remained the first development system that was capable of matching Infocom’s best games. If the amateur scene still largely failed to meet that lofty mark, they could no longer blame their technology. On a more personal note, the emergence of Mike Roberts on the scene marks the arrival of the first of the stalwarts who would go on to build the modern interactive-fiction community. We’re still in an era that will strike even most of the most dedicated fans of modern interactive fiction as murky prehistory, but some people and artifacts we recognize are beginning to emerge from the primordial ooze. More than a quarter of a century later, Mike Roberts and TADS are still with us.

(Sources: SynTax issues 17 and 36; SPAG issues 5 and 33; Mike Roberts’s interview for Jason Scott’s Get Lamp documentary, which Jason was kind of enough to share with me in its entirety. And my thanks to Mike Roberts himself, who answered many questions personally via email.

Ditch Day Drifter and Deep Space Drifter are available on the IF Archive for play via a TADS interpreter. The Adventions games are available there as well.)

 
 

Tags: , ,